最近我被一个问题反复轰炸：“你的Agent，能扛多大的事儿？”

起因是某个做零售系统的朋友找我复盘一次事故。他们内部把售后客服Agent从3步任务一路加到跨系统协同处理全流程，结果前几步跑得又快又准，到第9步就开始乱来——明明该走退款确认，它直接把订单标记成作废，差点造成线上库存错乱。复盘下来，问题不在模型笨，而在于整个Agent的设计从没考虑过“长链路任务下的承载力”。

这其实是很多团队的通病：Demo阶段跑得好，一上真实业务就露馅。我这一年多反复压测和重构过不少Agent应用，想把这套关于“Agent承载力”的经验完整讲一遍。这篇文章适合正在搭Agent的工程师、产品经理，也适合想知道“Agent到底能干到多大活儿”的技术决策者。不讲玄学，只讲方法和踩坑。

1. 先回答一个问题：Agent的“承载力”到底指什么

1.1 从一次压测事故说起

上面的售后事故不是孤例，我拆几个细节给大家看。

朋友的售后Agent最初只干三件事：查订单、看物流、改地址。这三步单步正确率很高，基本都在98%以上。后来业务方说“能不能把退款流程也接进来”，任务就变成了：查订单 → 判断是否在退换期 → 检查商品库存 → 生成退款单 → 通知财务 → 记录客服备注。看起来只是从3步加到6步，可Agent开始频繁出现“提前断言”：五步还没跑完，它先告诉客户“退款已成功”；还有步骤被跳过——它把“检查库存”压缩进了“生成退款单”这一个动作里，等于拿幻觉填了中间的空。

再往后，任务到9步时，问题开始变成“人物混淆”。系统里有客户、客服、财务三个角色，Agent在第八步之后会把财务的审批意见当成客户的诉求，然后对着错误对象做决策。这类错误在日志里极其隐蔽，因为单看每一步都像模像样，连起来看才发现逻辑断裂。

我把这类现象统称为“长链路崩溃”。它跟模型本身的单点智力没关系，而是当任务步数变多、状态变量变多、工具调用变多之后，Agent失去对全局的把控力。

1.2 承载力不是参数大小，是任务链的极限长度

很多人以为Agent能扛多大的事，取决于底层模型有多强。这个判断只对了一半。

模型强是基础条件，但“扛事”本质上是系统工程。我给承载力下过一个定义：

Agent承载力 = 在单步正确率、上下文占用、工具可信度、状态可恢复性这四个约束下，Agent能够可靠完成的最大任务复杂度。

用挑担子类比：一个人力气大（模型能力强），但如果路面坑坑洼洼（工具不稳定）、扁担老化（上下文管理差）、还不会中途换肩（无断点恢复），那他也担不了多少斤。

拆开来看，承载力由四个变量决定：

• 单步正确率：Agent每做一次推理、调一次工具的准确率。单步90%看起来很美好，十步下来整体成功率就只剩35%了，这是最简单的乘法效应。
• 上下文占用：任务越长，塞进上下文的历史记录和中间结果就越多。超过一定比例之后，新指令会被“淹没”。
• 工具可信度：工具返回的数据是否干净、格式是否稳定、调用是否高频失败，直接决定Agent的每一步是否踏实。
• 状态可恢复性：任务中断后能不能从失败点继续，而不是从头再来。

这四个变量里，前两个大家多少有感知，后两个往往被忽略。后面我会逐个展开，先给结论：大多数Agent扛不住大事，不是死于模型答辩，而是死于工具和状态这两根弹簧。

2. 把任务交给Agent前，先算清楚三笔账

2.1 上下文账：你的Agent能“记住”多少关键信息

上下文窗口是Agent最容易踩的第一道坎。

我在做某模拟项目X时，最初天真地以为“上下文够大就行”。实际上，窗口大不等于记得住。大模型对长上下文的注意力天然会衰减，中间位置的内容特别容易被遗忘——业内俗称“lost in the middle”。一个50步的任务，第20步产生的中间结论，很可能在第45步就被忽略了。

这个账怎么算？我一般用一句话估算：

单轮请求的上下文占用 = 历史对话摘要 + 当前任务状态 + 工具返回数据 + 指令/约束

每增加一个工具调用，返回的JSON动辄几百上千token，几轮下来轻松突破几万token。很多团队用的是4k/8k的窗口，实际可用空间更小。

应对方法有几个：

• 做摘要而不是堆原文：每完成几步，让Agent或单独的服务把关键结论压成结构化摘要，弃掉原始日志。
• 把工具返回瘦身：工具接口不要什么字段都返回，只返回当轮决策需要的字段。
• 用索引外置：关键业务数据不要塞进上下文，而是落到外部存储，按需检索。

我给过一个很粗暴的公式：任务设计时，估算每一轮平均新增token，再乘以预估轮数，必须小于窗口的三分之一。超过这个值，失败率会断崖式上升。这不算严谨的学术结论，但在我压测过的十几个场景里基本都是这么个趋势。

2.2 工具账：每个API调用都是风险敞口

第二笔账是工具调用。

Agent的每个动作几乎都对应一次API调用。而API调用意味着网络可能超时、接口可能改版、数据可能缺失、返回格式可能不标准。我把Agent当作一个“实习生”来看待：它本身不会亲眼看到业务系统的真实情况，全靠工具报告来认知世界。工具撒谎，它就撒谎；工具返回一个半截数据，它就基于半截数据做决策。

举一个很典型的例子。某场景里Agent要调用库存接口，正常情况下返回{"skus": [...]}，但有一次业务方接口在无库存时返回的不是空列表，而是{"error": "no data"}。Agent没有处理error分支，直接读字段，读不到就默认“没有库存”，于是把有货的商品标记成缺货，引导客户退货。这个错误持续了三个小时才被运营发现。

所以我在项目里养成了一个习惯：把工具接口当成外部服务来治理，而不是当作Agent的附属品。

具体做法：

• 每个工具必须有明确的失败返回协议，错误码和业务码分离；
• 工具返回前做一层schema校验，不通过就按异常处理；
• 重要决策类的工具调用，要求Agent输出“数据来源 + 调用时间 + 关键字段”的引用说明，方便回溯。

这背后的逻辑是：Agent的可靠性上限，不会超过它手里工具的可信度下限。工具不稳定，再聪明的模型也白搭。

2.3 状态账：多轮任务里最容易被遗忘的中间结果

第三笔账最容易被忽略——状态。

写单轮问答的人不会理解这个问题，但做多轮任务的人一定懂。Agent在执行长任务时，脑子里同时要维护的东西有：用户目标、已完成的步骤、当前步骤的输入输出、未来还要做的步骤。这些就是“状态”。

如果状态管理不好，最常见的现象是任务越走越偏。比如一个调研任务，Agent一开始要收集五个维度的信息，跑完前两个维度之后，第三个维度相关的信息被新内容冲掉了，它转头去研究第五个维度。等收尾时你说“还有第三维度呢”，它会一脸无辜地说“我好像没看到这个需求”。

解决思路有两种：

• 显式状态机：把任务流程固化成状态节点，Agent的每一轮输出都必须标注“当前状态 → 下一状态”，状态迁移不合法就把结果驳回去。
• 外部草稿板：把中间结果写进外部存储，每轮开始时把最新的状态草稿注入上下文，让Agent始终能看到“我干到哪了”。

我在压测里发现，加了外部草稿板之后，长链路任务的完成率能提升一倍以上。原因很简单：模型推理是概率性的，但外部状态是确定性的。用确定性去锚定概率性，才能把Agent从“自由发挥”拉回到轨道上。

3. 扛大活的关键设计：拆解、断点、校验、兜底

3.1 任务拆解：把“办好一件事”变成“干好一串小事”

这个道理跟带团队一样：没人能一口气把大项目做完，都是拆成里程碑和任务卡。

在Agent架构里，我始终推崇“规划器 + 执行器”的分层设计。规划器负责把用户的高层目标分解成一系列子任务，执行器负责逐项完成，每完成一个子任务都回传一个可验证的交付物，规划器再根据交付物决定下一步。

这里的难点在于子任务怎么拆。拆太粗，执行器一步做太多事，又会退化成“让大模型一口气写完整篇”的老路子，正确率上不去；拆太细，轮数爆炸，上下文和耗时都扛不住。

我的经验是三个原则：

• 子任务之间必须有明确的交付物边界。比如“查询用户信息”子任务的交付物是一份结构化用户数据，“生成退款单”子任务的交付物是退款单号和状态。
• 子任务粒度以“一个动作可验证”为准。执行器做完一步，能通过工具或数据直接确认对错，就不算拆细。
• 涉及外部写入的动作，一个子任务只允许一次关键写入。多个写入尽量拆开，避免一个步骤里“既改状态又发通知”，出错了难回滚。

从结果看，合理的任务拆解能显著降低单步推理压力。模型每次只决策一个小问题，正确率自然就上去了。

3.2 中途断点与恢复机制：应付掉线、超时和幻觉

第二个关键设计是断点与恢复。我刚开始做Agent时只顾着“往前跑”，后来才发现“跑到一半能停下来、能续上”才是真功夫。

长任务里，网络超时、API限流、模型请求失败都是家常便饭。没有断点机制的Agent，一旦中途失败就只能从头再来。我曾经见过一个12步的流程，在第8步失败后重新执行，结果因为第2步涉及重复扣费逻辑，直接产生了一条重复订单。这不是模型的问题，是系统设计没考虑幂等。

所以现在的做法是：

• 每个子任务执行前，先记录一个checkpoint，包含任务ID、当前节点、输入摘要、已完成动作列表。
• 每个涉及写入的动作，工具端做幂等设计，用任务ID作为幂等键，重复调用不会重复生效。
• 重试策略分级：网络类错误可以立即重试；幂等校验失败要进入人工复核；模型返回的JSON解析失败则重新生成一次。

这个设计的效果是：即使单步成功率不高，整体任务的“最终成功率”也能被兜住。因为Agent可以在任何中断点恢复，而不是全部推倒重来。

3.3 工具返回值的“二次校验”习惯

第三个习惯，是在Agent之外加一道“校验员”。

很多同学把工具返回直接交给Agent去理解，默认模型能正确处理。但实际上，工具返回的数据经常有字段缺失、类型错误、时间格式不一致等问题。模型看到残缺数据时，并不会报错，而是会用它强大的“脑补能力”把缺失部分填出来——这恰恰是最危险的地方。

我现在的工程规范是：工具返回结果在进入Agent上下文之前，必须先过一层校验器。

校验器分两层：

• 结构层校验：返回的JSON必须符合预定schema，必须字段一个都不能少，类型必须正确。这一步可以用传统代码完成，用不着模型。
• 业务层校验：数据是否符合业务常识。比如“退款金额大于订单金额”“库存数量小于零”这类明显异常，直接拦截。

实测效果非常明显。加了这层之后，Agent对工具数据的“幻觉率”下降了很多。因为大部分幻觉不是发生在Agent推理阶段，而是发生在“它读了一个残缺数据又不自知”的阶段。校验器就是帮它把这个漏洞补上。

3.4 人的兜底怎么埋，才不会变成摆设

最后一个关键设计是人工兜底。做过B端项目的人都知道，提“人机协同”容易，落地难。如果人工审核触点设计得不好，就会变成流程里的一道橡皮图章，既费人力又起不到作用。

我踩过几个坑，总结出的原则是：不要让人审全过程，只让人审关键节点。

• 风险分级：低风险动作（查询、推荐）全自动；高风险动作（退款、删除、改名、发信）必须人工确认。
• 关键节点可视化：人审的时候，不是甩一段对话日志让操作员猜，而是给一个结构化摘要：任务目标、已做动作、当前决策依据、风险点，一眼能看懂。
• 回滚路径：人工确认页面必须带“回滚到上一步”的入口，让操作员有纠错能力，不然审核只是形式。

我在多个项目里观察到一个规律：好的兜底设计不是给Agent兜底，而是给人兜底——让人在Agent的辅助下做决策，而不是让人熬夜对着一堆日志查问题。

4. 实测：模拟项目X从3步任务到25步任务

4.1 压测平台与评测口径

纸上谈兵没意思，聊一个我实际做过的压测案例。

我搭了一套模拟项目X，任务是“多轮售后工单处理”，从最简单的3步任务（查询订单 → 判断原因 → 回复客户），逐步加载到25步的复杂任务（涉及多个系统、多次审批、多轮信息核对）。压测环境是：本地起了一个模拟业务系统，提供订单、库存、退款、客服备注四类接口；Agent编排层用主流框架；底层模型固定用一个中等规模的推理模型，以便观察工程侧改进的贡献。

评测口径我定的是五个：

• 任务完成率：从开始到收尾，完全正确完成任务的比例。
• 平均轮数：完成任务实际消耗的Agent轮数，衡量效率。
• 工具调用成功率：所有API调用中成功且返回合法数据的比例。
• 人工介入率：需要人工接手或纠错的次数占总任务数的比例。
• 端到端耗时：从发起到结束的总时长。

这个口径不追求学术严谨，但能直观反映“扛事能力”的变化。

4.2 三层任务负载下的表现差异

结果分成三组：轻负载（3步）、中负载（10步）、重负载（25步）。

看这组数据，最扎心的不是完成率从96%掉到18%，而是掉得毫无悬念：每增加七个步骤，完成率大约砍半。这正是“单步正确率乘法效应”的直观体现。如果单步成功率是95%，10步就是60%，25步呢？0.95的25次方约28%，跟实测的18%接近，剩下的差距主要来自上下文膨胀和工具累积错误。

另一个值得注意的数据是人工介入率。25步任务里，几乎每两个任务就有一个需要人来纠错。这说明重负载下Agent不是“在控制中偶尔出错”，而是“大多数时候都在失控边缘”。

4.3 最让我意外的三种失败模式

压测过程中，有三种失败模式完全在我的意料之外，分享出来给大家避雷。

第一种：平行子任务被串行化，时间爆炸。任务里有两个互不依赖的子任务：一边查库存，一边查用户历史售后记录。Agent却老老实实地先查完库存，再查售后记录，硬生生把本可以并行的操作变成了串行，端到端耗时翻倍。解决方法是规划器显式标注“可并行节点”，执行器对这类节点做并发调度。

第二种：空结果被当成“任务完成”。工具返回了一个空列表，Agent就判断“该用户没有售后记录，不需要处理”，直接收尾。但真实情况是，接口因为权限问题返回了空列表，用户其实有三条未关闭的售后单。空结果不等于没有数据，必须通过接口状态码区分“查询成功但为空”和“查询失败返回空”。这个坑在真实业务里特别常见。

第三种：跨轮次的身份混淆。25步任务里有客户、客服、审批人三个角色，Agent在后期提交总结时，把审批人说过的话写到了客户名下，导致最终结论完全错位。这种错误在完全基于对话历史的架构里几乎无法根治，除非引入显式的实体绑定机制——把所有涉及角色的信息都结构化，标注“这句话是谁说的”，而不是依赖模型的记忆。

5. 面向“扛大事”的评估清单与调优顺序

5.1 一张能直接用的承载力检查表

根据上面的压测经验，我做了一个“承载力检查表”。每次接入新业务场景时，先照着打一遍分，基本就知道Agent能不能扛住。

这七个检查项，我建议在项目启动前就跑一遍，而不是等上线之后让用户帮你测。每项都可以做成自动化脚本，纳入CI。

5.2 按影响面排序的调优顺序

如果检查表跑下来发现一堆问题，先别乱，按影响面从大到小调优：

第一步，修工具层。工具返回不可信会带崩所有下游决策。先把错误协议、schema校验、空结果区分做掉。这是投入产出比最高的一项，通常能挽回大半的失败。

第二步，做状态外置。引入checkpoint和外部草稿板，让Agent的每一步都有据可溯。这一步能把完成率再往上拉一大截。

第三步，调任务拆解。把粗粒度子任务切细，给每个子任务明确可验证的交付物。注意别切过头，控制轮数膨胀。

第四步，再回来调提示词和模型。到这一步才轮到“提示词工程”的主场。这时候调提示词才有效，因为上下文干净了、工具可信了、状态稳定了，模型的注意力才能集中在真正的推理上。

第五步，最后做成本优化。在正确率稳定之后再压缩token、做模型降级，采用小模型处理简单子任务。

这个顺序我建议不要乱。很多团队一上来就调提示词，调了两个星期也没用——因为问题根本不在提示词，而在工具和状态。

5.3 什么时候该承认Agent扛不住

最后说一个反直觉的结论：不是所有事都应该让Agent扛。

在压测中我意识到，Agent适合的任务有共同特点：流程明确、边界清晰、反馈可验证。比如“查物流”“算价格”“生成报表”，每一步都有确定性的对错标准。不适合的任务也有共同特点：目标模糊、依赖复杂判断、需要长期人际关系维护。比如“跟客户谈续约”“协调多个团队的合作意愿”。

如果你发现某个任务压测到极限还是失败率高，别硬扛。更好的方案是把任务切成两半：Agent负责信息收集、整理、生成初稿；人负责判断、决策、拍板。这不是倒退，而是负责任的设计。

我在多个项目里的体会是：承认Agent的边界，不是认怂，而是让它在自己擅长的赛道里真正发光。

虽然说了这么多方法和数据，但最后想讲一个不那么“技术”的体会。

我见过太多团队把Agent当作“万能实习生”，恨不得所有事情都往里塞。但Agent真正擅长的，是在一条可验证的轨道上反复高速地执行，而不是在开放性决策里替人做主。每次压测完，我都会回到同一个问题：我们做Agent的目的，究竟是把人从确定性的重复劳动里解放出来，还是让人在不确定的决策里依赖一个更不确定的系统？

我的答案是前者。把承载力测清楚、把工程侧的稳定性补到位，它就能扛起那些烦琐、反复、耗人的事，把人的精力和判断力留到真正需要“人”的地方去。我自己手头的下一批实验，正在往“多Agent协作但共享同一份状态草稿板”的方向走，目前看起来，比单Agent硬扛要靠谱得多。这个话题等数据跑完再单独写一篇。