一、Agent 不是一个模型，而是一套执行系统

很多人一讲 Agent，就容易只想到“大模型 + 工具调用”。这个说法没错，但太浅薄。真正能跑长任务、能查资料、能改状态、能复盘经验的 Agent，至少要有四个核心组件：LLM 核心、工具系统、记忆系统、规划模块。

如果只有 LLM，它更像一个会说话的大脑：能理解问题，也能生成答案，但它本身不能联网、不能读业务数据库、不能执行代码，也不会天然记住跨任务的长期经验。把工具、记忆、规划接上之后，它才从“问答模型”变成“任务执行者”。

二、四个组件分别负责什么？

可以把 Agent 类比成一个小团队：LLM 像老板，负责判断方向；规划模块像项目经理，负责拆任务；工具系统像外包执行团队，负责真正干活；记忆系统像档案室，负责保存历史和经验。

这张图最重要的不是记住名词，而是记住分工。模型不应该直接拥有无限执行权限，工具不应该脱离鉴权和审计，记忆不应该什么都存，规划也不应该一次生成后永远不改。

三、组件一：LLM 核心，Agent 的“大脑”

LLM 核心负责理解用户目标、读取上下文、选择下一步动作、组织最终答案。它会综合用户输入、系统提示词、工具返回结果、短期记忆和长期记忆，再决定下一步是继续调用工具、追问用户，还是输出最终结果。

这里有一个容易被低估的点：System Prompt。它不是随便写几句角色设定，而是 Agent 的岗位说明书。它定义这个 Agent 能做什么、不能做什么、遇到不确定信息怎么处理、输出格式要遵守什么规范、哪些场景必须转人工。

模型选型也不是越贵越好。复杂规划和关键判断可以交给推理能力强的模型；主循环可以用能力均衡的通用模型；意图分类、参数抽取、格式修复这些小活，可以交给更快更便宜的小模型。

LLM 核心的工程要点

• 系统提示词要写清楚边界：角色、任务范围、禁止行为、失败处理、输出格式。

• 关键输出尽量结构化：比如 JSON、枚举、状态码，降低后端解析难度。

• 模型调用要可观测：记录 prompt 版本、输入摘要、工具决策、延迟、token、错误原因。

• 不要让一个模型承担所有事情：复杂思考、普通问答、小任务抽取，最好分层处理。

四、组件二：工具系统，让 Agent 接入真实世界

LLM 本身只是语言模型，它不会真的去查数据库，也不会真的调用接口。工具系统做的事，就是把外部能力封装成模型能理解的“工具说明书”：工具名是什么、什么时候用、需要哪些参数、返回什么结果。

这也是 Function Calling / Tool Calling 的核心思路：模型根据工具描述输出结构化调用请求，业务代码负责鉴权、执行、重试和记录日志。模型负责“决定调哪个工具”，程序负责“真正执行工具”。

一个典型工具定义可以长这样：

工具描述写得含糊，模型就会误判。比如只写“查询数据”，模型可能把天气、新闻、订单都当成可查询范围；如果写成“查询公司内部销售数据库，只支持日期、产品类别、区域筛选”，模型就更容易在正确场景调用正确工具。

工具系统上线时，重点看五件事

• 权限：不是模型想调就能调，必须有白名单、用户身份、业务权限。

• 参数：必须做 schema 校验、必填校验、枚举限制、危险参数拦截。

• 可靠性：要有超时、重试、熔断、降级，不能让 Agent 卡死。

• 幂等：发邮件、建工单、退款、下单这类动作必须避免重复执行。

• 审计：每次工具调用都要记录调用原因、参数、结果、耗时和操作者上下文。

五、从工具到协议：MCP 和 A2A 为什么重要？

当工具数量少时，手写几个函数就够了；当工具来自很多团队、很多系统、很多供应商时，适配成本会快速膨胀。MCP 的目标，是给 AI 应用连接外部系统提供统一接口，把工具、资源和提示模板标准化。

MCP 里可以把能力分成三类：Tools 表示会改变外部世界的动作，Resources 表示只读数据源，Prompts 表示预定义提示模板。它常被类比成 AI 应用的 USB-C：只要接口标准一致，应用就能发现和连接不同服务。

另一个方向是 A2A。MCP 解决“Agent 怎么接工具”，A2A 更关注“Agent 怎么和另一个 Agent 协作”。在企业里，客服 Agent、销售 Agent、财务 Agent、代码 Agent 往往分属不同系统，A2A 这种协议能让它们用统一方式交换任务、消息和结果。

六、组件三：记忆系统，让 Agent 不会中途失忆

没有记忆的 Agent，很难完成长任务。因为每一步工具返回、用户补充、计划变化，都需要被保存下来。否则执行到一半，它就不知道前面做过什么、哪些信息已经确认、哪些方案已经失败。

记忆至少分两层：短期记忆和长期记忆。短期记忆一般放在当前上下文或运行状态里，负责当前任务；长期记忆通常放在数据库、向量库、文档库里，负责跨任务保留知识、偏好、经验和历史记录。

长期记忆又可以用三种类型来理解：语义记忆存事实，比如“用户是企业客户”；情景记忆存经历，比如“上次这个订单查到物流异常”；程序性记忆存做事方法，比如“退款问题先查订单状态，再查支付渠道，再判断规则”。

但记忆不是越多越好。什么都往向量库里塞，会导致检索噪音变大，过期信息还可能误导模型。更好的做法是：存入前做重要性评估，检索时按语义、时间、权限、业务类型过滤，使用后再更新或衰减。

记忆系统的常见设计

• 短期记忆：保存当前任务步骤、最近对话、工具观察结果，可以用状态对象、Redis、会话表实现。

• 长期记忆：保存跨任务知识，可以用向量数据库 + metadata 过滤，也可以用关系库保存结构化事实。

• 摘要压缩：长任务中把早期步骤压缩成“任务摘要”，避免撑爆上下文窗口。

• 滑动窗口：只保留最近几轮详细内容，早期内容改用摘要或检索补回。

• 记忆衰减：越久远、越低价值、越低可信的记忆，检索权重越低。

七、组件四：规划模块，决定 Agent 能不能处理复杂目标

简单问题可以一步回答，复杂任务必须拆解。比如“帮我写一份竞品分析报告”，Agent 不能直接写，它应该先拆成：明确目标、收集资料、提取关键数据、对比分析、撰写报告、检查质量。

规划模块常见有三种模式。第一种是 Plan-and-Execute：先列完整计划，再按顺序执行。第二种是 ReAct：边思考、边行动、边观察，根据反馈动态调整。第三种是 Tree of Thoughts：展开多条候选路径，评估后选择更优分支。

实际工程里，经常不是三选一，而是组合使用：先用一个粗计划确定方向，再用 ReAct 在执行过程中动态修正；遇到高风险或强约束问题，再加入候选方案评估、人工确认和回滚机制。

规划模块要避免两个坑

• 只规划不执行：计划看起来漂亮，但没有工具、状态和失败处理，落不了地。

• 只循环不收敛：每一步都临时决策，容易反复搜索、反复调用工具，最后走偏或超时。

八、四组件跑起来，核心就是一个循环

把四个组件连起来后，Agent 的运行节奏并不神秘：用户给目标，规划模块拆步骤；LLM 读取记忆并判断下一步；工具系统执行动作；结果写回记忆；如果结果和预期不一致，就重新规划或调整策略；直到完成任务或触发人工接管。

可以用一段伪代码理解这个循环：

这段伪代码里最关键的是“控制权”。模型可以建议下一步动作，但真正的执行、权限、限流、审计、失败恢复，都应该由业务系统掌控。生产级 Agent 不是让模型自由发挥，而是把模型放进一个可控的执行框架里。

九、案例：客服 Agent 可以这样设计

以客服 Agent 为例，用户可能会问退款、物流、发票、账户、优惠券。一个靠谱的客服 Agent 不应该只靠模型直接回答，而应该把四组件都接起来。

这个例子也能迁移到投研 Agent、代码 Agent、运维 Agent、销售 Agent。区别只是工具不同、记忆不同、风险边界不同。投研 Agent 的工具可能是公告、行情、研报、财务数据；代码 Agent 的工具可能是文件系统、Git、测试框架、CI；运维 Agent 的工具可能是日志、监控、告警、发布平台。

十、面试和工程里最容易踩的 5 个坑

1. 只说 LLM 和工具，漏掉记忆和规划。没有记忆，长任务会失忆；没有规划，复杂任务会乱走。

2. 把记忆等同于上下文。上下文只是短期记忆，长期记忆需要外部存储、检索、更新和衰减。

3. 以为模型真的执行工具。模型只输出调用意图，真正执行必须由业务代码完成。

4. 工具越多越好。工具过多且描述不清，会增加误调用、上下文膨胀和安全风险。

5. 计划一次生成后不再调整。真实任务经常遇到搜索失败、接口超时、数据缺失，必须支持重规划。

十一、总结

LLM 是大脑，工具是手脚，记忆是档案室，规划是项目经理。四个组件合在一起，Agent 才能完成多步任务：先拆目标，再做决策，再调用工具，再保存结果，再根据反馈调整。

真正的工程重点，不是把 Demo 跑起来，而是让这个循环稳定、可控、可观测、可恢复。能做到这些，Agent 才不是玩具，而是可以接业务的生产系统。