AI Agent 的核心技术是什么？是工程还是算法？还是说要等新的 LLM？
AI Agent 的核心技术是什么？是工程还是算法？还是说要等新的 LLM？
先说结论：现阶段 Agent 的核心瓶颈是工程，不是算法，也不需要等新的 LLM。
但这个"工程"不是你理解的那种写写 CRUD 调调接口的工程，它难在另一个地方。
先把 Agent 拆开看，到底有几层技术
一个能用的 Agent 系统，粗略分三层：
- 底座层：LLM 本身的能力——理解指令、推理、生成结构化输出
- 编排层：怎么让 LLM 跟外部世界交互——工具调用、记忆管理、多步规划、错误恢复
- 应用层：针对具体场景的适配——Prompt 工程、知识接入、业务流程集成、用户交互设计
大家讨论"核心技术"的时候经常把这三层混在一起说，所以才会有"到底是工程还是算法"的困惑。实际上每一层的瓶颈不一样。
底座层：LLM 的能力已经够用了，但不是什么都够
GPT-4o、Claude Sonnet/Opus、Gemini 2.5 这些模型，在指令跟随、推理、结构化输出方面已经很强了。你让它做 function calling、输出 JSON、根据上下文选择合适的工具，成功率能到 95% 以上。
这意味着什么？意味着"LLM 不够聪明所以 Agent 做不好"这个说法，在大多数场景下已经不成立了。
当然，在一些特别复杂的场景里——比如需要跨越十几个步骤的长链推理、需要在大量信息中精确定位关键细节、需要处理极度模糊的指令——当前模型确实还不够好。但这些场景是少数。大部分企业想做的 Agent 应用，比如智能客服、数据分析助手、自动化运维、代码生成，现有模型的能力是完全够的。
做不好的原因不是模型不行，是你上面那两层没搞好。
编排层：这才是目前最难的部分
编排层要解决的核心问题是：怎么让一个"只会聊天"的 LLM 变成一个"能干活"的系统。
这里面的技术挑战，不是单个问题多难，而是它们组合在一起形成的工程复杂度。逐个拆开来看：
工具调用的可靠性。 LLM 调用工具不像程序调函数那样确定性执行，它是"猜"出来的——猜该调哪个工具、猜参数是什么。这个"猜"的准确率在简单场景下很高，但工具一多、参数一复杂就开始出错。你有 30 个工具，每个工具有五六个参数，LLM 选错工具或填错参数的概率就不低了。怎么设计工具的描述让 LLM 更容易选对？怎么做参数校验和自动修正？怎么在工具调用失败的时候优雅降级？这些全是工程问题。
多步规划和执行。 Agent 跟普通聊天机器人的核心区别是：它要自己规划执行步骤，而不是人类一步一步喂指令。但 LLM 的规划能力是有限的——它可以大致想出一个方向，但具体的执行路径经常需要根据中间结果动态调整。你让它"帮我分析上个月的销售数据并生成报告"，它要先搞清楚数据在哪、用什么工具查、查出来的数据怎么处理、报告的格式是什么。中间任何一步出了问题，它需要能意识到问题并调整计划。这种"走一步看一步"的执行模式，工程上怎么设计状态管理和流程控制，是非常实际的难题。
记忆和上下文管理。 LLM 有上下文窗口限制，即使现在有 100K、200K token 的窗口，在复杂 Agent 场景里也很容易用完。Agent 执行过程中产生的中间结果、调用过的工具返回值、用户的历史对话，全部塞进上下文里是不现实的。什么信息保留、什么信息压缩、什么信息扔掉，这个取舍直接决定 Agent 的效果。做得好，Agent 能持续执行复杂任务；做得差，Agent 几步之后就"忘了"之前在干什么。
错误处理和自愈。 这是最被低估的部分。在演示环境里跑 Agent，一切都很顺畅。但到了生产环境，你会发现：API 超时了怎么办？工具返回了意外格式的数据怎么办？LLM 产生了幻觉给出了不存在的工具名怎么办？用户中途改变了需求怎么办？一个健壮的 Agent 系统要处理的异常情况比正常流程多得多。这不是什么前沿算法问题，这就是纯粹的工程经验。
应用层：被严重低估的"最后一公里"
很多团队在底座和编排上花了大量精力，但在应用层上草草了事，结果产品体验很差。
Prompt 工程比你想的重要得多。 同一个模型、同一个编排框架，Prompt 写得好和写得差，效果可能天差地别。怎么描述工具让 LLM 更准确地使用？怎么设计系统 Prompt 让 Agent 的行为更稳定可控？怎么处理边界情况的兜底？这些看起来是"调参"，但实际上需要对 LLM 的行为模式有很深的理解，以及大量的试错和迭代。
知识接入的质量。 Agent 要用好领域知识，RAG 的质量至关重要——文档怎么切分、Embedding 用哪个、检索策略怎么设计、检索结果怎么排序和过滤。这每一步做不好，Agent 就会用错误的知识去执行任务，结果就是一本正经地胡说八道。
用户体验设计。 Agent 不是一次性给个结果就完事的，它的执行过程往往需要跟用户交互——确认中间结果、处理歧义、展示进度、允许用户纠偏。这个交互体验设计得好不好，直接决定用户愿不愿意用。
那算法真的不重要吗？
不是不重要，而是现阶段不是瓶颈。
算法方面确实有一些值得关注的研究方向：
- 更好的规划能力：比如 Tree of Thoughts、ReAct 这些让 LLM 做更结构化推理的方法
- 自我反思和纠错：让 Agent 能评估自己的执行结果并自动修正
- 多 Agent 协作：让多个专业化的 Agent 协同完成复杂任务
- 长期记忆：超越上下文窗口的记忆方案
但这些方向目前更多是在学术探索阶段，离生产可用还有距离。而且很多时候，一个好的工程方案能达到跟复杂算法差不多的效果。比如"自我反思"这个能力，你不需要什么花哨的算法，让 Agent 执行完一步后加一个 Prompt 让它自己检查结果是否合理，用工程手段就能实现 80% 的效果。
那需要等新的 LLM 吗？
不需要等。
这个想法的问题在于，它假设"有了更强的 LLM，Agent 的问题就自动解决了"。不会的。更强的 LLM 确实能让 Agent 的基础能力更强——推理更准确、工具调用更可靠、处理更复杂的指令。但编排层和应用层的那些工程问题，不会因为模型变强就消失。
你用 GPT-3.5 做 Agent 遇到的工具选择错误问题，换成 GPT-4o 可能错误率从 15% 降到 3%，但那 3% 依然需要你用工程手段去处理——参数校验、重试、降级、兜底。你不可能等到模型 100% 不出错再去做这些。
而且从商业角度看，等是最大的浪费。Agent 的应用场景已经很清晰了，技术栈也基本成熟了，现在入场做的团队能积累工程经验、理解用户需求、打磨产品体验。等到"完美模型"出来再开始，你就比别人晚了一两年。
说回核心
如果非要用一句话总结 Agent 的核心技术：是在不确定性中构建确定性的工程能力。
LLM 本质上是一个概率模型，它的每一次输出都有不确定性。而用户需要的是确定性的结果——这个任务要么完成了，要么告诉我为什么完不成。Agent 的核心挑战就是用工程手段——类型约束、状态管理、错误恢复、人机交互——把 LLM 的不确定性控制在可接受的范围内。
这不是什么高深的算法问题，但也绝不是简单的"套个框架调调 API"能搞定的。它需要对 LLM 的能力边界有清晰的认知，对复杂系统的工程设计有扎实的经验，以及对具体业务场景有深入的理解。
这三样东西，没有一样是等新模型能等来的。