Agent 核心组件有哪些?

这道题其实是在问，当我们想用大模型做自主任务时，大脑怎么分工，哪些部件必须得有。我会从四个核心组件来拆，分别是规划、记忆、工具调用，还有执行循环。先说规划。规划模块的核心是把一个复杂问题拆成可执行的子步骤，比如用户说“帮我查订单状态，如果超时了发起退款”，模型不能一步到位，得先查订单、判断状态、再决定下一步。典型的实现是 [[ReAct]] 循环，就是推理和行动交替，模型每输出一个思考就跟着一个动作，然后观察结果再继续。另一种是 [[Chain-of-Thought]]，让模型一步步推理，适合不需要外部动作的场景。但实际落地时，我倾向于把两者结合，比如先 CoT 拆出子任务，然后用 ReAct 去执行每个子任务，这样更可控。这里有个坑，就是规划不能太死板，如果第一步查询失败了，计划得能动态调整，否则整个流程就卡死了。所以我会给规划加一个重试和回退机制，最多重试三次，三次都失败就上报异常。再一个组件是记忆。记忆分短期和长期。短期记忆就是当前对话的上下文，比如用户刚才说了什么、中间结果是什么，实现上就是 [[Sliding Window]] 或者 [[KV Cache]]，把最近的几轮对话或者关键中间结果存下来。长期记忆则负责沉淀历史经验、领域知识、用户偏好，比如一个电商客服 [[Agent]]，需要记住某个用户是 VIP，他之前投诉过物流慢，那么下次对话就要避免再推荐慢的快递。长期记忆的典型实现是 [[Vector Database]]，比如用 Milvus 存向量，按语义检索。但这里要划清边界：如果知识是结构化且频繁更新的，比如商品库存和价格，直接查数据库比向量检索更可靠，别为了用向量而用向量。举个例子，客服场景里用户问“我的订单怎么还没到”，Agent 需要先查订单数据库得到物流单号和状态，然后查知识库里的物流政策，最后查向量库里的类似投诉处理记录。这三个来源缺一不可，不能只靠向量检索。第三个核心组件是工具调用。大模型本身只能生成文本，要执行外部操作必须通过工具。典型方式是 [[Function Calling]]，就是给模型定义一组工具 Schema，模型根据用户需求选择调用哪个工具，并填充参数。比如订单查询工具，参数是订单号，返回状态。但工具调用不是万能的，常见失败场景是模型[[幻觉]]参数，比如把“订单号”和“手机号”搞混。所以上线我会特别关注工具参数的校验，用正则或者枚举值做一层过滤，参数不对直接拒绝调用并让模型重新思考。另外，工具的数量不能太多，超过十来个模型就容易选错，所以我会对工具做分类和优先级排序，高频工具优先暴露。最后是行动执行，其实就是把规划、记忆、工具串起来的循环。模型先观察当前状态，然后思考下一步做什么，接着执行一个动作，拿到结果再观察，如此反复。这个循环的关键是终止条件，不能无限循环下去。我会设置最大步数，比如十步，超过就返回部分结果并提示用户。还有安全护栏，比如输出审核，防止模型生成违规内容。所以整体上，我会把 Agent 看成 一个由规划驱动、记忆辅助、工具执行的闭环系统，而不仅仅是 LLM 加几个插件。落地时最怕的是组件之间耦合太紧，比如规划模块直接硬编码了工具名称，那换场景就得重写。所以我会设计成松耦合的，规划模块只输出意图和参数，由调度模块去匹配工具，这样可扩展性好很多。其实还有一个容易被忽略的组件是监控和日志，没有它你根本不知道 Agent 在哪一步失败了，每次循环的输入输出都要落盘，方便事后复盘和优化。但这个可能更偏工程侧了。