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