1. 从"能聊天"到"能干活"：AI代理到底跨过了哪道分水岭
大多数人第一次接触AI代理这个概念时，脑子里浮现的画面无非是一个更聪明的聊天窗口——你问它答，偶尔帮你写封邮件、改段代码。但如果只是这样，它根本不配叫"代理"。代理这个词本身就带着授权和执行的意味：你把一件事交给它，它自己拆解目标、规划路径、调用工具、检查结果，最后把成品放到你面前。这中间你不需要盯着它一步步走。
我真正意识到这个变化，是在一次内部工具链的改造里。当时团队要处理一批格式混乱的运营数据，过去要么写脚本硬编码，要么人工一条条清洗。我试着把任务描述丢给一个带工具调用能力的代理框架，它自己决定先做字段识别，再调用正则清洗，遇到拿不准的记录就标记出来问我。整个过程它调了四次不同的工具，中间还因为一次正则匹配失败自己换了策略。那一刻我才确认，这东西和聊天机器人是两个物种。
核心分水岭在于"闭环能力"。聊天机器人是开环的：你给输入，它给输出，对不对它不管。代理是闭环的：它有目标，有执行，有对执行结果的观察，还能根据观察调整下一步。这个"观察-调整"的循环，才是代理的灵魂。没有这个循环，再强的模型也只是个高级复读机。
那这个循环具体由什么支撑？拆开看是四块能力：
- 任务分解：把"帮我整理这份报告"拆成"读取文件→提取关键数据→按主题归类→生成摘要→排版输出"这样的子步骤。
- 工具调用：每一步需要什么能力就去调什么工具，读文件用文件接口，算数用计算器，查资料用检索。
- 记忆管理：记住前面做过什么、结果是什么，避免重复劳动，也避免前后矛盾。
- 自我校验：做完一步回头看看对不对，不对就回退重来。
这四块里，最容易被低估的是记忆管理。我见过不少代理跑着跑着就"失忆"了，前面明明已经确认过的参数，后面又用错。这不是模型笨，是上下文管理没做好。代理的上下文不像聊天那样线性增长就行，它需要区分哪些是长期事实、哪些是临时中间结果、哪些该丢弃。这块做不好，代理越跑越乱。
理解了这层，你就能明白为什么"AI代理"这个词在最近一两年被反复提起。不是模型突然变强了那么简单，而是工具调用协议标准化和上下文窗口扩大这两件事同时成熟，让闭环从理论变成了工程上可落地的东西。以前你想让模型调个外部接口，得写一堆胶水代码，现在有统一的调用格式，模型自己就能生成调用请求。这个基础设施的变化，比模型参数涨了多少更关键。
2. 拆开一个代理的骨架：规划、执行、反思三件套怎么配合
要真正用好代理，光知道它能干活不够，得知道它内部是怎么运转的。我把一个典型代理的工作流拆成三个阶段：规划、执行、反思。这三个阶段不是严格串行的，实际跑起来经常交错，但理解它们各自的职责，对排查问题特别有用。
2.1 规划阶段：目标怎么变成可执行的步骤清单
规划阶段干的事，是把一个模糊的人类指令翻译成机器能一步步走的计划。这里有个常见的误解：很多人以为规划就是让模型列个to-do list。其实远不止。好的规划要解决三个问题——步骤之间的依赖关系、每步的成功标准、以及失败后的备选路径。
举个例子，你让代理"分析这份销售数据并给出下季度建议"。一个粗糙的规划是：读数据→分析→写建议。但这样的规划一执行就卡壳，因为"分析"太笼统，代理不知道从哪下手。好的规划会拆成：先确认数据字段含义→检查数据完整性→按区域和时间维度聚合→识别异常值→对比历史同期→生成趋势判断→结合业务规则给建议。每一步都有明确的输入和输出，代理执行时才知道自己有没有做完。
我在实际项目里总结出一个经验：规划粒度控制在"单步可验证"这个级别最合适。太粗了执行不下去，太细了规划本身的开销就超过执行。怎么判断？如果一步做完，你能明确说"这步成了"或"这步没成"，那粒度就对了。如果做完之后你只能说"好像做了点什么"，那就是太粗。
规划阶段还有一个容易被忽略的点：约束条件的显式化。人类下指令时经常省略约束，比如"尽快给我结果"，但代理不知道"尽快"是五分钟还是五小时。所以规划阶段要把这些隐含约束挖出来，变成明确的判断条件。我通常会在系统提示里强制代理先复述一遍它理解的约束，确认无误再开始规划。这一步多花几秒，能省掉后面大量的返工。
2.2 执行阶段：工具调用的顺序与容错
执行阶段是代理真正动手的部分。这里最核心的机制是工具调用，但工具调用不是简单地"需要什么调什么"，它涉及顺序、参数传递和容错。
先说顺序。有些步骤有严格的先后依赖，比如必须先读文件才能分析内容。有些步骤则可以并行，比如同时查三个不同来源的数据。代理如果分不清依赖关系，要么串行得太慢，要么并行得乱了套。我的做法是在规划阶段就给每步标注依赖，执行时按依赖图调度。这个依赖图不需要多复杂，一个简单的有向无环图就够用。
再说参数传递。这是实际跑起来最容易出问题的地方。上一步的输出要作为下一步的输入，但格式往往对不上。比如上一步返回的是一段自然语言描述，下一步的工具却需要一个结构化的JSON。这时候就需要一个"参数适配"的环节，把上一步的输出转换成下一步能吃的格式。我见过太多代理在这里翻车，明明每步单独看都对，连起来就报错，问题就出在参数没对齐。
容错是执行阶段的重头戏。工具调用失败是常态，网络超时、接口限流、参数格式错误，什么都有可能。代理不能一遇错就整个崩掉，它需要有重试、降级和上报三种应对。重试适用于临时性错误，比如超时；降级适用于某个工具不可用时换一个替代方案；上报适用于自己搞不定的情况，把问题抛回给人。这三种应对的触发条件要提前定义好，不能等出错了再临时判断。
实操心得：我在给代理配工具时，会给每个工具写一份"使用说明"，包括它适合什么场景、参数怎么填、常见错误有哪些。这份说明会作为上下文的一部分喂给代理。别小看这个，它能让代理的工具调用成功率提升一大截，因为代理不用靠猜来填参数了。
2.3 反思阶段：代理怎么知道自己做错了
反思阶段是代理和普通脚本最本质的区别。脚本执行完就完了，对错由外部判断。代理要自己判断自己做得对不对，不对就改。
反思的触发点通常有三个：一是每步执行完后的即时检查，看输出是否符合预期格式和范围；二是整个任务完成后的整体检查，看最终结果是否满足原始目标；三是遇到异常时的诊断，搞清楚为什么出错。
即时检查相对简单，主要是格式校验和范围校验。比如要求输出数字，结果出来是文字，那就标记异常。整体检查复杂一些，需要代理回头对照原始目标，看有没有遗漏或偏差。诊断最难，需要代理理解错误的性质，是参数错了、工具选错了、还是规划本身就有问题。
我踩过的一个坑是：反思不能太频繁，否则代理会陷入"检查-怀疑-再检查"的死循环。有次我设了个很严格的校验规则，结果代理每做一步都要反复确认，效率低得离谱。后来我把校验分成两级：轻量级的格式检查每步都做，重量级的逻辑检查只在关键节点做。这样既保证了质量，又不至于拖垮速度。
反思还有一个高级用法：把反思结果沉淀成经验。代理这次在某类任务上犯了错，下次遇到类似任务时应该能避开。这需要代理有某种形式的长期记忆，把"什么情况下容易出错"记下来。这块目前还在探索阶段，但方向是明确的——代理不能每次都从零开始，它得越用越聪明。
3. 工具调用：代理的"手"到底该怎么接
代理再聪明，没有工具也只能空想。工具调用是代理从"想"到"做"的桥梁，这座桥修得好不好，直接决定代理能不能干活。这一章我把工具调用拆成几个层面来讲，从接口设计到错误处理，都是实际项目里绕不开的。
3.1 工具接口的设计原则：给代理用的API和给人用的有什么不同
给人用的API，文档写清楚就行，人会自己看文档、自己试错。给代理用的工具接口，要求高得多。因为代理不会"看文档"，它只能从上下文里理解这个工具是干什么的。所以工具接口的设计要遵循几个原则。
第一，描述要自解释。工具的名称和参数说明要能让代理一眼看懂用途。比如一个查天气的工具，叫get_weather就比叫query_data好得多。参数名也一样，city_name比param1清晰太多。代理理解工具靠的是语义，语义模糊它就会用错。
第二，参数要少而精。人用的API可以有几十个可选参数，代理用的工具最好控制在三五个必填参数以内。参数太多，代理填错的概率直线上升。如果确实需要很多配置，可以拆成多个专用工具，而不是一个万能工具。
第三，返回值要结构化。代理需要从返回值里提取信息做下一步决策，所以返回值最好是结构化的，比如JSON。如果返回一大段自然语言，代理还得先解析一遍，既慢又容易出错。我通常要求工具返回一个包含状态码、数据和错误信息的三段式结构，代理一看就知道成没成、结果是什么、错在哪。
第四，要有明确的失败信号。工具执行失败时，不能只返回一个空值或者一句"出错了"，要返回具体的错误类型和原因。代理需要根据错误类型决定是重试、降级还是上报。错误信息越具体，代理的应对就越准确。
下面这张表对比了给人用的接口和给代理用的工具在设计上的差异：
| 维度 | 给人用的API | 给代理用的工具 |
|---|---|---|
| 文档形式 | 详细文档，人主动查阅 | 内嵌描述，随上下文提供 |
| 参数数量 | 可多可少，灵活 | 尽量精简，必填为主 |
| 返回值 | 可读性优先 | 结构化优先 |
| 错误处理 | 错误码+文档说明 | 错误类型+原因+建议 |
| 幂等性 | 建议支持 | 必须支持，代理会重试 |
幂等性这点特别重要。代理在不确定上一步是否成功时，会倾向于重试。如果工具不幂等，重试就会产生副作用，比如重复下单、重复发送。所以给代理用的工具，写操作必须设计成幂等的，或者至少要有去重机制。
3.2 多工具协同：代理怎么决定先调哪个后调哪个
单个工具用好不难，难的是多个工具协同。代理面对一个任务，手里有七八个工具，它怎么决定用哪个、按什么顺序用？
这个决策过程本质上是规划的一部分，但执行时会动态调整。我的经验是给代理一个"工具选择策略"，而不是让它每次从零判断。策略可以很简单，比如"先查后写"、"先粗后细"、"先本地后远程"。这些策略作为默认规则，代理在大多数情况下照着走就行，遇到特殊情况再灵活处理。
工具之间的数据传递是另一个难点。A工具的输出要喂给B工具，但两者的数据格式可能不兼容。这时候需要一个"适配层"，把A的输出转换成B能接受的格式。适配层可以是一个专门的转换工具，也可以是在调用B之前插入一个格式化步骤。我倾向于后者，因为格式化步骤本身也是可复用的。
还有一种情况是工具之间有冲突。比如两个工具都能完成同一个子任务，但一个快一个准。代理需要根据当前任务的优先级来选。如果任务对时间敏感，选快的；如果对准确性要求高，选准的。这种权衡逻辑要提前告诉代理，不能指望它自己悟。
注意：多工具协同最容易出的问题是"工具打架"。两个工具的输出格式不一致，或者一个工具的输出被另一个工具误读。排查这类问题时，我会把每个工具的输入输出都打日志，然后一步步对照，看是哪一步的数据变了形。这个笨办法虽然土，但最快定位问题。
3.3 工具调用的失败模式与兜底策略
工具调用失败是必然的，不是偶然的。网络会抖、接口会限流、参数会填错、返回会超时。代理必须有完整的兜底策略，否则一个工具挂掉整个任务就崩了。
我把失败模式分成四类，每类对应不同的兜底策略：
- 临时性失败：超时、限流、网络抖动。这类失败重试通常能解决。策略是等待一段时间后重试，重试次数控制在三次以内，每次间隔递增。
- 参数性失败：参数格式错、必填项缺失、值超出范围。这类失败重试没用，需要修正参数。策略是让代理根据错误信息调整参数，重新调用。
- 工具性失败：工具本身不可用、接口变更、权限不足。这类失败需要换工具或上报。策略是查找替代工具，没有替代就上报给人。
- 逻辑性失败：工具执行成功但结果不符合预期。这类失败最隐蔽，需要代理有校验机制。策略是触发反思，检查是规划错了还是工具选错了。
这四类失败的区分很重要，因为用错兜底策略会浪费时间。比如参数错了却去重试，重试一百次也没用。我在系统里会给每个工具标注它可能出现的失败类型，代理遇到失败时先对照类型，再选策略。
兜底策略里还有一个"熔断"机制值得说。如果某个工具连续失败多次，代理应该暂时停止调用它，避免把时间浪费在一个明显不可用的工具上。熔断后可以定期探测，恢复了再重新启用。这个机制在依赖外部服务的场景里特别有用。
4. 记忆与上下文：代理跑着跑着就"失忆"怎么办
代理执行长任务时，最让人头疼的问题就是"失忆"。前面明明确认过的信息，后面又搞错了；前面已经排除的方案，后面又捡起来了。这不是模型能力问题，是记忆管理没做好。这一章专门讲代理的记忆机制和上下文管理。
4.1 短期记忆与长期记忆的分工
代理的记忆分两层：短期记忆和长期记忆。短期记忆是当前任务的上下文，记录这次任务里发生了什么。长期记忆是跨任务的经验，记录代理在以往任务里学到的东西。
短期记忆的管理核心是"压缩"。任务跑得越久，上下文越长，但模型的上下文窗口是有限的。不能把所有历史都塞进去，得挑重要的留。怎么挑？我的做法是保留三类信息：当前目标、已确认的事实、未解决的疑问。其余的中间过程可以压缩成摘要，或者干脆丢弃。
长期记忆的管理核心是"提炼"。不是把所有历史任务都存下来，而是提炼出可复用的经验。比如"处理这类数据时，先检查编码格式"这样的规则，就是从多次任务里提炼出来的。长期记忆的存储形式可以是规则库、案例库或者向量数据库，关键是能快速检索到相关的经验。
两层记忆之间的桥梁是"沉淀"。短期记忆里的成功经验和失败教训，定期沉淀到长期记忆里。这个沉淀过程可以是自动的，也可以是半自动的——代理提出候选经验，人确认后入库。我倾向于半自动，因为代理自己判断哪些经验值得记，有时候会跑偏。
4.2 上下文窗口的取舍：什么该留，什么该丢
上下文窗口是代理最宝贵的资源。窗口里塞什么，直接决定代理的表现。我见过不少代理因为上下文里塞了太多无关信息，导致关键信息被淹没，决策质量直线下降。
取舍的原则是"相关性优先，时效性其次"。和当前子任务最相关的信息优先保留，最近产生的信息其次。具体操作上，我会把上下文分成几个区块：系统指令区、任务目标区、当前状态区、历史摘要区、工具结果区。每个区块有固定的大小配额，超了就压缩或丢弃。
系统指令区放代理的行为准则和约束，这部分基本不变，常驻。任务目标区放原始目标和当前子目标，也是常驻。当前状态区放正在处理的步骤和中间结果，动态更新。历史摘要区放已完成步骤的摘要，定期压缩。工具结果区放最近几次工具调用的结果，用完就清。
这个分区管理的好处是，代理随时知道哪部分信息在哪，不会因为上下文混乱而迷失。而且每个区块的大小可控，不会出现某个区块无限膨胀把其他区块挤没的情况。
实操心得：我在上下文里会给关键信息打"标签"，比如
[已确认]、[待验证]、[已排除]。代理看到标签就知道这条信息的可信度，不会把待验证的当成已确认的用。这个小技巧能显著减少代理的逻辑错误。
4.3 记忆检索：怎么在需要的时候找到该用的信息
长期记忆存了很多经验，但代理怎么在需要的时候找到对的那条？这就涉及检索机制。检索做得好，代理能快速调用相关经验；检索做得差，代理要么找不到，要么找到一堆不相关的。
检索的核心是"匹配"。匹配可以基于关键词，也可以基于语义。关键词匹配快但不够灵活，语义匹配灵活但慢。我的做法是先用关键词粗筛，再用语义精排。粗筛把候选范围缩小到几十条，精排从中选出最相关的几条。这样兼顾了速度和准确度。
检索的另一个要点是"时效加权"。越近的经验权重越高，因为环境在变，老经验可能过时了。但也不能完全忽略老经验，有些基础规则是长期有效的。所以时效加权要有个下限，不能衰减到零。
检索结果的使用也要讲究。不是检索到什么就直接用什么，而是要把检索结果作为参考，结合当前情况判断。代理需要有能力区分"这条经验适用于当前情况"和"这条经验不适用"。这个判断能力，是代理成熟度的体现。
5. 从单代理到多代理：什么时候该拆，什么时候不该拆
单个代理能力有限，任务复杂到一定程度，就需要多个代理协作。但多代理不是银弹，拆得不好反而添乱。这一章讲多代理的适用场景、协作模式和常见陷阱。
5.1 多代理的适用边界：不是所有任务都值得拆
多代理的第一个问题是：什么时候该拆？我的判断标准是看任务能不能被清晰地切成独立的子任务，且子任务之间的耦合度低。如果两个子任务需要频繁交换中间结果，那拆开反而增加通信开销，不如放在一个代理里做。
适合拆的场景通常有这几个特征：子任务专业性强，需要不同的工具集；子任务可以并行，拆开能提速；子任务需要不同的角色视角，比如一个负责生成一个负责审核。不适合拆的场景则是：子任务高度依赖，必须串行；子任务共享大量状态；任务本身就不大，拆了纯属折腾。
我见过一个反面案例：有人把"写一篇文档"拆成"写标题代理"、"写正文代理"、"写结尾代理"，结果三个代理互相等对方的输出，通信开销比写文档本身还大。这就是典型的过度拆分。拆分的收益必须大于通信成本，否则不如不拆。
5.2 协作模式：主从、对等还是流水线
多代理的协作模式主要有三种：主从模式、对等模式和流水线模式。
主从模式是一个主代理负责任务分解和结果汇总，多个从代理负责执行子任务。这种模式适合任务可以清晰分解且子任务相对独立的场景。主代理是大脑，从代理是手脚。优点是控制集中，不容易乱；缺点是主代理容易成为瓶颈。
对等模式是多个代理地位平等，通过协商来协作。这种模式适合需要多视角讨论的场景，比如一个代理提方案，另一个代理挑毛病，来回几轮打磨出更好的结果。优点是可以互相纠错；缺点是协商过程可能很长，效率不稳定。
流水线模式是多个代理按顺序接力，每个代理处理一道工序。这种模式适合工序明确的场景，比如数据处理流水线。优点是流程清晰；缺点是任何一道工序出问题都会卡住整条线。
选择哪种模式，取决于任务的性质。我的经验是：任务能清晰分解用主从，需要质量打磨用对等，工序固定用流水线。实际项目里经常是混合使用，比如主从模式里某个子任务用对等模式来打磨。
5.3 通信开销与一致性：多代理最容易翻车的地方
多代理协作最大的坑是通信开销和状态一致性。代理之间传递信息需要成本，传递得越多，开销越大。而且信息在传递过程中可能失真，导致代理之间的理解不一致。
控制通信开销的办法是"最小必要通信"。代理之间只传必要的信息，不传冗余的。比如从代理执行完子任务，只需要把结果和状态传回主代理，不需要把中间过程也传回去。中间过程留在从代理本地就行。
保证一致性的办法是"单一事实来源"。关键状态只存一份，所有代理都从这里读。比如任务的整体进度存在一个共享的状态存储里，代理需要时去读，而不是各自维护一份。这样避免了状态不一致的问题。
还有一个实用技巧是"版本号"。每次状态更新都递增版本号，代理在更新状态前先检查版本号，如果自己手里的版本号落后了，就先拉取最新状态再更新。这个机制能有效避免并发更新导致的状态覆盖。
6. 落地一个代理系统：从选型到上线的完整路径
前面讲的都是原理和机制，这一章讲落地。从零开始搭一个代理系统，要经过哪些步骤，每个步骤的关键决策是什么。
6.1 模型选型：能力、成本、延迟的三角权衡
选模型是第一个决策。模型的能力、成本、延迟三者不可兼得，必须权衡。能力强的模型贵且慢，便宜的模型能力弱。怎么选，取决于你的任务对这三者的敏感度。
如果任务对准确性要求极高，比如涉及金额计算或法律条款，那就选能力最强的，成本和延迟可以妥协。如果任务量大且对实时性要求高，比如客服自动回复，那就选快且便宜的，准确性通过其他手段兜底。如果任务介于两者之间，可以考虑混合方案：关键步骤用强模型，辅助步骤用弱模型。
我的经验是不要一上来就追求最强模型。先用中等模型跑通流程，看看瓶颈在哪。如果瓶颈在模型能力，再升级；如果瓶颈在别处，升级模型也没用。很多团队一上来就用最贵的模型，结果发现大部分开销花在了简单任务上，纯属浪费。
还有一个考虑是模型的稳定性。有些模型能力强但输出不稳定，同样的输入两次结果差很多。代理系统对稳定性要求高，因为代理的决策依赖模型的输出。所以选模型时，稳定性要和能力一起评估。
6.2 框架选择：自研还是用现成的
代理框架的选择，本质上是自研和用现成的之间的权衡。现成框架上手快，但灵活性差；自研灵活，但工作量大。
现成框架适合快速验证想法。它们通常提供了工具调用、记忆管理、多代理协作的基础设施，你只需要配置和扩展。缺点是框架的抽象可能和你的需求不完全匹配，遇到框架不支持的功能就得绕路。
自研适合需求明确且特殊的场景。你可以完全按自己的需求设计架构，不受框架限制。缺点是所有基础设施都要自己搭，包括工具调用协议、上下文管理、错误处理等，工作量不小。
我的建议是：先用现成框架跑通一个最小可用版本，验证核心流程。如果框架能满足需求，就继续用；如果发现框架的限制成了瓶颈，再考虑自研。不要一上来就自研，那容易陷入造轮子的泥潭。
6.3 上线前的检查清单：那些容易忽略的细节
代理系统上线前，有些细节容易被忽略，但上线后可能引发大问题。我整理了一份检查清单：
- 权限控制：代理能调用的工具是否都经过了权限审核？有没有代理能访问它不该访问的数据？
- 速率限制：代理调用外部接口的频率是否在限制范围内？有没有防止代理疯狂重试的机制？
- 日志记录：代理的每一步决策和工具调用是否都有日志？出问题时能不能追溯？
- 人工兜底：代理搞不定的时候，有没有顺畅的渠道把问题转给人？
- 成本监控：代理的模型调用和工具调用成本是否在预算内？有没有异常增长的告警？
- 回滚机制：代理上线后如果表现不佳，能不能快速回滚到之前的版本？
这些细节看起来琐碎，但每一个出问题都可能让整个系统不可用。我见过因为没做速率限制导致代理把外部接口打挂的，也见过因为没做成本监控导致账单爆掉的。上线前多花半天检查，能省掉上线后几天的救火。
7. 代理系统的评估：怎么判断它到底行不行
代理系统做出来了，怎么判断它好不好？不能只看它能不能跑通，得有一套评估方法。这一章讲评估的维度和方法。
7.1 评估维度：成功率、效率、成本、稳定性
评估代理系统，我通常看四个维度：成功率、效率、成本和稳定性。
成功率是最直观的，任务完成的比例。但成功率要定义清楚：什么算完成？是代理自己说完成就算，还是结果经过验证才算？我倾向于后者，代理自己说完成不算数，得结果确实符合要求才算。
效率是完成任务的平均时间和步骤数。同样的任务，用的步骤越少、时间越短，效率越高。效率低往往意味着代理在绕路或者反复试错，需要优化。
成本是完成任务的平均开销，包括模型调用和工具调用。成本要和成功率一起看，不能为了省钱牺牲成功率，也不能为了成功率不计成本。
稳定性是多次运行结果的一致性。同样的任务跑十次，结果差异大不大？差异大说明代理的行为不稳定，可能是模型输出波动大，也可能是流程设计有问题。
7.2 评估方法：离线测试与在线监控
评估方法分离线测试和在线监控。离线测试是在上线前，用一批标准任务跑代理，看各项指标。在线监控是上线后，持续跟踪代理在真实任务上的表现。
离线测试的关键是测试集的设计。测试集要覆盖各种情况：简单任务、复杂任务、边界情况、异常情况。不能只测简单任务，那测不出问题。我通常会设计一个测试集，包含百分之六十的常规任务、百分之三十的困难任务、百分之十的异常任务。
在线监控的关键是指标的实时性。代理出问题时，要能及时发现。所以监控指标要实时更新，异常要实时告警。我通常会监控成功率、平均步骤数、平均成本这几个核心指标，任何一个偏离正常范围就告警。
7.3 持续迭代：从评估结果到优化动作
评估的目的是优化。评估结果出来后，要分析问题出在哪，然后针对性优化。
如果成功率低，看是哪些任务失败，失败的原因是什么。是规划不合理，还是工具调用出错，还是模型能力不够。定位到原因后，针对性改进。
如果效率低，看代理在哪些步骤上花的时间多。是某个工具响应慢，还是代理在反复试错。找到瓶颈后优化。
如果成本高，看成本花在哪。是模型调用太频繁，还是用了太贵的模型。找到大头后调整。
如果稳定性差，看结果差异在哪。是模型输出波动，还是流程有随机性。找到来源后控制。
迭代是个持续的过程，不是一次性的。代理系统上线后，要持续监控、持续评估、持续优化。我见过不少团队上线后就不管了，结果代理的表现慢慢退化，因为环境在变，代理没跟着变。
8. 我踩过的那些坑：代理系统落地中的真实教训
理论讲完了，讲点实在的。这一章分享我在代理系统落地过程中踩过的坑，都是真金白银换来的教训。
8.1 规划过度与规划不足：两个极端都翻过车
规划过度是我早期常犯的错。那时候我觉得规划越细越好，把任务拆成几十个小步骤，结果代理执行时被这么多步骤压垮了，光是在步骤之间切换就耗尽了上下文。后来我学乖了，规划粒度控制在"单步可验证"就行，不要过度拆分。
规划不足则是另一个极端。有次我让代理处理一个数据分析任务，规划只写了"读数据、分析、输出"三步。结果代理在执行"分析"时完全不知道从哪下手，试了好几种方法都不对，最后随便给了个结果。这就是规划太粗的后果。后来我在规划阶段强制代理把每步的输入输出和成功标准都写清楚，问题就少了。
8.2 工具描述不清导致的连环错误
工具描述不清是我见过最隐蔽的坑。有次我给代理配了一个"发送通知"的工具，描述写的是"发送消息"。代理以为这个工具可以发任何消息，结果在需要发邮件的时候也调了它，当然失败了。更糟的是，失败后代理以为是网络问题，反复重试，浪费了大量时间。
后来我给每个工具的描述都加上了明确的适用范围和限制条件。比如"发送通知"的描述改成"向指定用户发送站内通知，不支持邮件和短信"。这样代理就不会用错了。工具描述要精确到"能做什么"和"不能做什么"都写清楚，不能有歧义。
8.3 上下文污染：一个不起眼的日志把代理带偏了
上下文污染这个坑很隐蔽。有次代理执行任务时，上下文里混进了一段无关的日志，日志里提到了一个不存在的文件路径。代理看到这个路径后，以为任务涉及这个文件，就去尝试读取，结果当然读不到，然后就开始各种折腾。
排查这个问题花了我很久，因为代理的行为看起来毫无道理。后来我把上下文完整打出来看，才发现是那段日志惹的祸。从那以后，我在往上下文里放信息时都会过滤一遍，确保放进去的都是和当前任务相关的。无关信息宁可丢掉，也不要放进去干扰代理。
8.4 重试机制设计不当引发的雪崩
重试机制设计不当，后果可能很严重。有次我给代理配了个简单的重试逻辑：工具调用失败就重试，最多三次。看起来没问题，但实际跑起来，当外部接口整体不可用时，所有代理都在重试，把接口彻底打挂了。这就是重试引发的雪崩。
后来我加了熔断机制：某个工具连续失败超过阈值，就暂时停止调用它，过一段时间再探测。这样避免了在工具不可用时还疯狂重试。重试机制一定要配熔断，否则重试就成了帮凶。
8.5 人工兜底渠道不畅导致的任务堆积
人工兜底渠道不畅，是我见过最影响体验的坑。代理搞不定的任务需要转给人处理，但如果转交渠道不顺畅，任务就会堆积。有次我们的代理系统上线后，转人工的任务没有明确的通知机制，结果任务堆在队列里没人管，用户等了好久才发现。
后来我们做了几件事：转人工的任务实时通知到值班人员；任务在队列里超过一定时间自动升级提醒；每天统计转人工的任务量和处理时长。这些措施保证了转人工的任务能被及时处理。代理系统不是全自动的，人工兜底是必要的一环，这一环不能掉链子。
9. 代理技术的下一步：几个值得关注的方向
代理技术还在快速演进，有几个方向值得关注。这一章聊聊我观察到的趋势，以及这些趋势可能带来的变化。
9.1 从通用代理到垂直代理的收敛
早期的代理追求通用，什么任务都能接。但实际用下来，通用代理在专业任务上的表现往往不如垂直代理。垂直代理针对特定领域优化，工具集更精准，提示词更专业，表现更稳定。
我预计未来会出现更多垂直代理，比如专门处理财务的、专门处理法务的、专门处理运维的。这些代理不追求什么都会，而是在自己的领域里做到最好。通用代理则退居幕后，负责调度和协调这些垂直代理。
9.2 代理之间的标准化协议
多代理协作目前最大的障碍是缺乏标准化协议。不同框架的代理之间很难直接通信，得写适配层。这限制了代理生态的发展。
我期待看到代理通信的标准化协议出现，就像HTTP之于Web。有了标准协议，代理之间就能像搭积木一样组合，生态会繁荣起来。这个方向目前有一些探索，但还没形成共识，值得持续关注。
9.3 代理的可解释性与可控性
代理越自主，可解释性和可控性就越重要。用户需要知道代理为什么做某个决策，也需要在必要时干预代理的行为。目前代理的决策过程还是个黑盒，出了问题时很难说清楚为什么。
可解释性方面，我期待看到代理能输出决策依据，比如"我选择这个工具是因为……"。可控性方面，我期待看到更细粒度的干预机制，比如用户可以在代理执行到某一步时暂停、修改、继续。这两个方向做好了，代理才能真正被信任和广泛采用。
9.4 代理与人的协作模式演进
代理和人的关系，从"人指挥代理"到"人和代理协作"再到"代理主动建议"，这个演进正在进行。早期是人给代理下指令，代理执行。现在有些场景下，代理会主动提出建议，人来决定采不采纳。
未来代理可能会更主动，在察觉到问题时主动介入，而不是等人来指挥。这要求代理有更强的环境感知和判断能力。同时，人也需要适应和代理共事的方式，学会什么时候信任代理、什么时候干预。这种协作模式的演进，可能比技术本身的进步影响更深远。
10. 给准备入局的团队几句实在话
如果你正在考虑引入代理技术，或者已经开始动手，我有几句实在话想说。
第一，从具体问题入手，不要为了用代理而用代理。代理是解决问题的工具，不是目的。先找到确实需要代理的场景，再考虑用代理。我见过不少团队为了追概念而引入代理，结果发现原来的方案更简单有效。
第二，先跑通最小闭环，再逐步扩展。不要一上来就设计一个大而全的系统，那容易陷入过度设计。先做一个能完成单个简单任务的代理，跑通了再增加工具、增加任务、增加协作。小步快跑比大步慢走更靠谱。
第三，重视评估和监控，不要凭感觉判断。代理系统好不好，要用数据说话。建立评估指标，持续监控，用数据驱动优化。凭感觉判断容易自我感觉良好，实际问题一堆。
第四，人工兜底不是失败，是必要设计。代理不可能百分之百可靠，人工兜底是保证体验的底线。不要觉得转人工是代理能力不足的表现，这是负责任的设计。
第五，保持耐心，代理技术还在早期。现在的代理系统还有很多不完善的地方，会遇到各种意想不到的问题。保持耐心，持续迭代，别指望一步到位。这个领域变化很快，今天的坑明天可能就被填上了，但新的坑也会出现。持续学习是常态。
我在这个领域摸索了一段时间，最大的体会是：代理技术的核心不是模型有多强，而是工程做得多扎实。模型能力是基础，但决定代理能不能真正干活的，是工具设计、上下文管理、错误处理这些工程细节。这些细节没有捷径，只能一个个踩坑、一个个填。但每填一个坑，代理就可靠一分，这种进步是实实在在的。
