1. 从零拆解一个 Agent 到底由什么构成很多人第一次接触 Agent 这个概念脑子里浮现的画面要么是科幻电影里的机器人要么是 ChatGPT 套了个壳。但真到动手搭一个能跑起来的 Agent 系统时你会发现事情没那么玄乎也没那么简单。我前后搭过七八个不同形态的 Agent 项目从最简单的问答机器人到带工具调用和长期记忆的复杂系统踩过的坑足够写一本小册子。今天就把我对 Agent 核心组件的理解完整拆一遍用“大脑、记忆、手脚、心跳”这四个词来串这个比喻我觉得比任何学术定义都好用。先说清楚这个内容适合谁看。如果你是完全没接触过 Agent 开发的小白这篇能帮你建立完整的认知框架知道一个 Agent 从概念到落地需要哪些模块如果你已经写过一些调用大模型 API 的代码但总觉得自己的 Agent “不够聪明”或者“记不住事”那这篇能帮你定位问题出在哪个环节如果你是做技术选型的产品或架构角色这篇也能帮你判断哪些能力是必须自建的哪些可以直接用现成方案。核心关键词先摆出来Agent、LLM、规划、记忆、工具。这五个词基本覆盖了 Agent 系统的全部核心。LLM 是大脑的引擎规划是大脑的思考方式记忆是大脑的存储系统工具是手脚的延伸而心跳是整个系统的运转节律。下面我会逐个拆开讲每个部分都会说清楚“为什么这么设计”以及“实际怎么做”。需要提前说明的是Agent 这个领域变化极快今天的最佳实践可能三个月后就被推翻。所以我不会给你一套“标准答案”而是给你一套思考框架和实操方法让你能根据自己的场景做判断。文章里涉及的具体参数和代码示例都是基于我实际项目中的经验总结你可以直接参考但一定要结合自己的业务做调整。2. 大脑LLM 选型与规划能力的工程实现2.1 为什么 LLM 是大脑而不是整个 Agent很多人会把 Agent 和 LLM 画等号觉得用了 GPT-4 或者某个开源大模型就是在做 Agent 了。这个认知偏差会导致一个严重后果把所有希望寄托在模型能力上忽略了工程层面的设计。我早期就犯过这个错以为换个更强的模型Agent 就能自己变聪明结果发现该出错还是出错该绕圈子还是绕圈子。LLM 在 Agent 里的角色准确说是“推理引擎”它负责理解输入、生成思考过程、决定下一步动作。但它不负责记忆存储、不负责工具执行、不负责状态管理。打个比方LLM 就像公司里的首席分析师脑子好使但手不能动、记性也有限你得给他配秘书记忆系统、配执行团队工具层、配一个调度中心心跳机制他才能发挥最大价值。选型的时候我一般从三个维度评估推理能力、响应延迟、成本。推理能力决定 Agent 能不能处理复杂任务延迟决定用户体验成本决定你能不能规模化。这三个维度往往是互相矛盾的能力强的模型通常更慢更贵所以关键是找到适合你场景的平衡点。2.2 规划能力的三种实现路径与选型建议规划是大脑最核心的能力说白了就是“把一个大任务拆成小步骤然后一步步执行”。目前主流有三种实现路径我分别说说各自的适用场景和坑。第一种是ReAct 模式也就是 Reasoning Acting 交替进行。模型先输出一段思考然后决定调用哪个工具拿到结果后再思考下一步。这种模式实现简单适合步骤数不多、逻辑相对线性的任务。但它的缺点是容易“绕圈子”尤其是在任务复杂的时候模型可能反复调用同一个工具却得不到进展。我实测下来ReAct 在 5 步以内的任务上表现很好超过 10 步就很容易失控。第二种是Plan-and-Execute 模式先让模型制定完整计划再逐步执行。这种模式的好处是全局观更强不容易迷路。但缺点是计划一旦制定就很难调整如果中间某一步的结果和预期不符整个计划可能就废了。我的经验是这种模式适合流程相对固定的场景比如数据处理流水线不太适合需要灵活应变的交互式任务。第三种是多 Agent 协作模式把不同职责分配给不同的 Agent 实例比如一个负责规划、一个负责执行、一个负责审核。这种模式理论上最强大但工程复杂度也最高。我目前只在少数复杂项目里用过效果确实好但调试成本很高不建议新手一上来就搞。实操心得不管你选哪种规划模式一定要给模型设定“最大步数限制”和“超时退出机制”。我见过太多 Agent 因为陷入死循环而烧掉大量 token 的案例这个坑一定要提前防。2.3 提示词工程在 Agent 场景下的特殊技巧Agent 场景下的提示词和普通对话完全不同核心区别在于你需要让模型输出结构化的、可解析的内容。我一般会用 JSON 格式约束输出比如要求模型返回{thought: ..., action: ..., action_input: ...}这样的结构。这样做的好处是程序可以稳定解析不会因为模型自由发挥导致解析失败。另一个技巧是少样本示例。在系统提示词里放 2-3 个完整的思考-行动-观察循环示例能显著提升模型输出格式的稳定性。我试过不放示例和放示例的对比格式错误率能从 30% 降到 5% 以下。还有一个容易被忽略的点是错误处理提示。你需要在提示词里明确告诉模型如果工具调用失败该怎么办、如果信息不足该怎么处理、如果任务无法完成该怎么回复。这些边界情况的处理逻辑如果不提前约定模型的行为会非常随机。3. 记忆让 Agent 不再“金鱼脑”的完整方案3.1 短期记忆与长期记忆的分层设计Agent 的记忆问题本质上是“上下文窗口有限”和“任务需要历史信息”之间的矛盾。解决方案就是分层短期记忆放在上下文窗口里长期记忆存在外部存储中需要的时候再检索回来。短期记忆我一般用对话缓冲区来实现就是维护一个最近 N 轮对话的列表。N 的取值很关键太小了模型记不住上下文太大了浪费 token 还容易让模型分心。我的经验值是保留最近 10-20 轮具体看任务复杂度。如果单轮内容很长可能只保留 5 轮就够了。长期记忆的实现方式就多了最简单的是向量数据库把历史信息做 embedding 后存进去需要的时候做相似度检索。我常用的是 Chroma 或 FAISS轻量够用。复杂一点的可以用知识图谱把实体和关系结构化存储检索精度更高但构建成本也更高。还有一种我最近在尝试的方案是分层摘要把久远的对话压缩成摘要存储既保留了关键信息又节省了空间。这个方案在长对话场景下效果不错但摘要的质量很依赖模型的总结能力。3.2 记忆检索的触发时机与相关性排序存记忆容易取记忆难。什么时候该去检索长期记忆、检索回来的内容怎么排序、怎么决定哪些记忆该放进上下文这些都是工程上的关键决策点。触发时机我一般设两种一种是每轮都检索适合对历史信息依赖强的场景比如客服 Agent另一种是按需检索让模型自己判断是否需要查记忆适合任务导向的场景。前者更稳定但开销大后者更经济但可能漏掉关键信息。相关性排序不能只看向量相似度还要考虑时间衰减和重要性权重。我的做法是给每条记忆打两个分相似度分和时间新鲜度分加权求和后排序。权重比例根据场景调比如新闻类 Agent 时间权重高一些知识类 Agent 相似度权重高一些。注意事项记忆检索一定要设 top-k 限制我一般取 3-5 条。检索太多会稀释关键信息反而让模型抓不住重点。这个坑我在早期项目里踩过检索了 20 条记忆塞进上下文结果模型完全忽略了最相关的那条。3.3 记忆的写入策略与去重机制记忆写入的策略直接影响长期记忆的质量。我的原则是不是所有对话都值得记。如果每轮对话都往长期记忆里塞很快就会被噪音淹没。我一般会设几个写入触发条件用户明确表达了偏好或事实、任务产生了重要结果、模型判断这条信息未来可能有用。具体实现上可以让模型在每轮对话后输出一个“是否值得记忆”的判断或者用规则引擎做初筛。去重也很重要。用户可能反复说同一件事如果每次都存一条检索的时候就会返回一堆重复内容。我的做法是在写入前先做一次相似度检查如果和已有记忆的相似度超过阈值我一般设 0.9就更新已有记忆而不是新增。4. 手脚工具调用的设计与工程落地4.1 工具的定义规范与描述技巧工具是 Agent 与外部世界交互的桥梁。没有工具的 Agent 只能聊天有了工具才能查数据、发请求、操作文件、控制设备。但工具不是随便定义的定义得好不好直接决定 Agent 能不能正确使用。每个工具我一般包含这几个要素名称、功能描述、参数列表、参数类型和约束、返回值格式。名称要简洁明确用动词开头比如search_weather而不是weather_tool。功能描述要写清楚“什么时候该用这个工具”而不只是“这个工具能做什么”。这一点很关键模型判断是否调用工具主要看的是使用场景的描述。参数定义要尽量严格能用枚举就不用自由文本能加约束就加约束。我见过太多因为参数定义模糊导致模型传错值的案例。比如一个查询天气的工具城市参数如果只写“string”模型可能传“北京”也可能传“北京市朝阳区”最好在描述里明确格式要求。4.2 工具调用的错误处理与重试机制工具调用失败是常态网络超时、参数错误、服务不可用各种情况都会遇到。如果 Agent 没有错误处理能力一次失败就整个任务卡住体验会非常差。我的做法是给每个工具调用包一层重试逻辑一般重试 2-3 次每次间隔递增。重试仍然失败的话把错误信息返回给模型让模型决定是换个工具、换个参数、还是放弃这个步骤。这里的关键是错误信息要足够清晰模型才能做出正确判断。我一般会把错误类型、错误原因、建议的处理方式都返回给模型。还有一种情况是工具返回了结果但结果不符合预期。比如查询数据库返回空结果这时候不能简单地把空结果丢给模型而要明确告诉它“查询成功但无数据”否则模型可能误以为是工具坏了。4.3 工具编排与并行调用的优化当 Agent 需要调用多个工具时编排方式直接影响效率。最简单的串行调用一个接一个执行逻辑清晰但速度慢。如果多个工具之间没有依赖关系完全可以并行调用。我一般会先分析工具之间的依赖关系构建一个依赖图然后对没有依赖关系的工具做并行执行。实测下来在需要调用 5 个以上工具的场景里并行能把总耗时降低 60% 以上。但并行也有坑主要是结果合并的问题。多个工具同时返回结果怎么组织这些结果放进上下文需要仔细设计。我的做法是给每个工具结果加一个标识符然后在上下文里按标识符分组呈现避免模型混淆。实操心得工具的数量不是越多越好。我建议单个 Agent 的工具数量控制在 10-15 个以内。工具太多会导致模型选择困难调用准确率明显下降。如果确实需要很多工具可以考虑分组用路由机制先选组再选工具。5. 心跳Agent 的运转节律与状态管理5.1 主循环的设计与退出条件心跳是 Agent 的主循环决定了整个系统怎么运转。一个典型的主循环是这样的接收输入、调用模型思考、解析输出、执行动作、更新状态、判断是否结束、进入下一轮。退出条件的设计很关键。我一般设三种退出任务完成模型输出最终答案、达到最大步数防止死循环、超时防止卡死。这三个条件缺一不可我早期只设了任务完成条件结果遇到模型绕圈子的时候整个系统就挂在那里了。最大步数的设置需要根据任务复杂度调整。简单问答 3-5 步够了复杂任务可能需要 20-30 步。我的经验是设一个稍大的值然后在提示词里也告诉模型“你最多有 N 步”双重保险。5.2 状态管理与上下文压缩策略Agent 的状态包括当前任务进度、已执行的动作、已获取的信息、待处理的事项等。这些状态需要在整个循环中保持一致不能丢失也不能混乱。我一般用一个状态对象来管理每轮循环结束后更新。状态对象的结构要设计好既要包含所有必要信息又要方便序列化和反序列化因为可能需要持久化存储。上下文压缩是另一个关键问题。随着循环进行上下文会越来越长最终超出模型窗口限制。我的做法是定期压缩比如每 5 轮做一次摘要把之前的详细对话压缩成一段总结。压缩的时机和粒度需要根据任务特点调整太频繁会丢失细节太少会超出限制。5.3 异常恢复与断点续跑机制Agent 运行过程中可能因为各种原因中断网络问题、服务重启、人为干预等。如果没有恢复机制中断后只能从头再来体验很差。我的做法是定期保存检查点把当前状态序列化后存到持久化存储里。恢复的时候从最近的检查点加载继续执行。检查点的保存频率需要权衡太频繁影响性能太少可能丢失较多进度。我一般每轮循环结束都保存一次因为状态对象通常不大保存开销可以接受。断点续跑还有一个细节是幂等性。恢复后重新执行的动作不能产生副作用比如重复发送邮件、重复扣款等。这个需要在工具层面做保证给每个动作加唯一标识执行前先检查是否已经执行过。6. 常见问题与排查技巧实录6.1 Agent 陷入死循环怎么办这是最常见的问题表现为 Agent 反复调用同一个工具或者反复输出相似的思考。排查思路分三步先看提示词里有没有明确的最大步数限制和退出条件再看工具返回的结果是不是让模型产生了误解最后看任务本身是不是超出了模型能力范围。我的解决经验是在提示词里加一句“如果你发现自己重复了之前的动作请换一种方式或直接给出当前最优答案”。这句话能解决大部分轻度死循环。如果还不行就需要在代码层面加检测逻辑发现连续 N 轮动作相同时强制退出。6.2 记忆检索不准确怎么调记忆检索不准通常有三个原因embedding 模型不适合你的领域、检索策略太单一、记忆本身质量不高。我的排查顺序是先看记忆内容如果存进去的就是垃圾检索出来自然也是垃圾再看 embedding 模型通用模型在专业领域表现可能不好需要考虑微调或换专用模型最后看检索策略是不是只用了向量相似度有没有加时间衰减和重要性权重。6.3 工具调用参数错误频发怎么解参数错误一般是因为工具描述不够清晰。我的改进方法是在参数描述里加示例值明确格式要求能枚举就枚举。另外可以在提示词里加一段“调用工具前请检查参数格式”的提醒。如果某个工具特别容易出错可以考虑在代码层面加参数校验和自动修正逻辑。常见问题典型表现排查方向解决手段死循环重复调用同一工具检查退出条件加最大步数限制和重复检测记忆不准检索结果不相关检查记忆质量和检索策略优化 embedding 和加权排序参数错误工具调用失败检查工具描述加示例值和格式约束上下文超限模型报错或截断检查上下文长度加定期压缩机制响应太慢用户等待时间长检查串行调用改并行调用和缓存结果6.4 性能优化的几个实用技巧性能优化我一般从三个层面入手。模型层面简单任务用小模型复杂任务用大模型不要一刀切。工具层面能并行就并行能缓存就缓存减少不必要的调用。上下文层面定期压缩及时清理无用信息保持上下文精简。还有一个容易被忽略的点是流式输出。Agent 的思考过程如果等全部完成再返回用户会觉得等待很久。改成流式输出让用户看到 Agent 正在思考体验会好很多。7. 从原型到生产我的落地经验总结把 Agent 从 demo 做到生产可用中间有一条很长的路。我踩过的最大坑是过度依赖模型能力总觉得换个更强的模型就能解决问题。后来发现工程层面的设计才是决定 Agent 稳定性的关键。提示词的边界处理、工具的错误重试、记忆的质量控制、心跳的异常恢复这些看起来不酷的东西才是让 Agent 真正能用的基础。另一个体会是可观测性的重要性。Agent 的决策过程是个黑盒出了问题很难排查。我后来在项目里加了完整的日志记录每轮循环的输入输出、工具调用详情、状态变化都记下来排查问题的效率提升了好几倍。最后分享一个小技巧给 Agent 加一个“自我反思”环节。在任务完成后让模型回顾整个过程总结哪些做得好、哪些可以改进。这个反思结果可以存进长期记忆下次遇到类似任务时参考。我实测下来这个机制能让 Agent 在重复任务上的表现逐步提升。这个框架后续还可以扩展的方向很多比如多 Agent 协作的通信协议、工具的动态注册与发现、记忆的跨会话共享等。但核心的四组件模型是不变的大脑负责思考记忆负责存储手脚负责执行心跳负责运转。把这四个部分都做扎实了Agent 的稳定性和实用性自然就上来了。