最近我被一个问题反复轰炸“你的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步。指标3步任务10步任务25步任务任务完成率96%61%18%平均轮数41538工具调用成功率99%92%83%人工介入率2%19%47%端到端耗时约12秒约90秒约8分钟看这组数据最扎心的不是完成率从96%掉到18%而是掉得毫无悬念每增加七个步骤完成率大约砍半。这正是“单步正确率乘法效应”的直观体现。如果单步成功率是95%10步就是60%25步呢0.95的25次方约28%跟实测的18%接近剩下的差距主要来自上下文膨胀和工具累积错误。另一个值得注意的数据是人工介入率。25步任务里几乎每两个任务就有一个需要人来纠错。这说明重负载下Agent不是“在控制中偶尔出错”而是“大多数时候都在失控边缘”。4.3 最让我意外的三种失败模式压测过程中有三种失败模式完全在我的意料之外分享出来给大家避雷。第一种平行子任务被串行化时间爆炸。任务里有两个互不依赖的子任务一边查库存一边查用户历史售后记录。Agent却老老实实地先查完库存再查售后记录硬生生把本可以并行的操作变成了串行端到端耗时翻倍。解决方法是规划器显式标注“可并行节点”执行器对这类节点做并发调度。第二种空结果被当成“任务完成”。工具返回了一个空列表Agent就判断“该用户没有售后记录不需要处理”直接收尾。但真实情况是接口因为权限问题返回了空列表用户其实有三条未关闭的售后单。空结果不等于没有数据必须通过接口状态码区分“查询成功但为空”和“查询失败返回空”。这个坑在真实业务里特别常见。第三种跨轮次的身份混淆。25步任务里有客户、客服、审批人三个角色Agent在后期提交总结时把审批人说过的话写到了客户名下导致最终结论完全错位。这种错误在完全基于对话历史的架构里几乎无法根治除非引入显式的实体绑定机制——把所有涉及角色的信息都结构化标注“这句话是谁说的”而不是依赖模型的记忆。5. 面向“扛大事”的评估清单与调优顺序5.1 一张能直接用的承载力检查表根据上面的压测经验我做了一个“承载力检查表”。每次接入新业务场景时先照着打一遍分基本就知道Agent能不能扛住。检查项理想状态危险信号测试方法最大任务步数明确知道极限设计留有冗余不知道极限靠运气从3步/10步/25步逐级压测单步成功率核心步骤大于98%出现跳跃、幻觉、角色混淆记录每一步的推理和工具调用人工复查上下文占用率峰值小于窗口的三分之一日志里频繁截断、摘要缺失统计平均每轮token和峰值工具失败处理全部有错误分支失败时Agent直接“脑补”故意让接口超时、返回残缺数据状态可恢复任意步骤可续跑失败只能从头开始在50%位置注入超时观察恢复幂等保障所有写操作都幂等重复执行会产生重复数据同一任务重复调用两次比对结果人工兜底关键节点有审核甩整段日志让人猜模拟高风险动作检查审查页面这七个检查项我建议在项目启动前就跑一遍而不是等上线之后让用户帮你测。每项都可以做成自动化脚本纳入CI。5.2 按影响面排序的调优顺序如果检查表跑下来发现一堆问题先别乱按影响面从大到小调优第一步修工具层。工具返回不可信会带崩所有下游决策。先把错误协议、schema校验、空结果区分做掉。这是投入产出比最高的一项通常能挽回大半的失败。第二步做状态外置。引入checkpoint和外部草稿板让Agent的每一步都有据可溯。这一步能把完成率再往上拉一大截。第三步调任务拆解。把粗粒度子任务切细给每个子任务明确可验证的交付物。注意别切过头控制轮数膨胀。第四步再回来调提示词和模型。到这一步才轮到“提示词工程”的主场。这时候调提示词才有效因为上下文干净了、工具可信了、状态稳定了模型的注意力才能集中在真正的推理上。第五步最后做成本优化。在正确率稳定之后再压缩token、做模型降级采用小模型处理简单子任务。这个顺序我建议不要乱。很多团队一上来就调提示词调了两个星期也没用——因为问题根本不在提示词而在工具和状态。5.3 什么时候该承认Agent扛不住最后说一个反直觉的结论不是所有事都应该让Agent扛。在压测中我意识到Agent适合的任务有共同特点流程明确、边界清晰、反馈可验证。比如“查物流”“算价格”“生成报表”每一步都有确定性的对错标准。不适合的任务也有共同特点目标模糊、依赖复杂判断、需要长期人际关系维护。比如“跟客户谈续约”“协调多个团队的合作意愿”。如果你发现某个任务压测到极限还是失败率高别硬扛。更好的方案是把任务切成两半Agent负责信息收集、整理、生成初稿人负责判断、决策、拍板。这不是倒退而是负责任的设计。我在多个项目里的体会是承认Agent的边界不是认怂而是让它在自己擅长的赛道里真正发光。虽然说了这么多方法和数据但最后想讲一个不那么“技术”的体会。我见过太多团队把Agent当作“万能实习生”恨不得所有事情都往里塞。但Agent真正擅长的是在一条可验证的轨道上反复高速地执行而不是在开放性决策里替人做主。每次压测完我都会回到同一个问题我们做Agent的目的究竟是把人从确定性的重复劳动里解放出来还是让人在不确定的决策里依赖一个更不确定的系统我的答案是前者。把承载力测清楚、把工程侧的稳定性补到位它就能扛起那些烦琐、反复、耗人的事把人的精力和判断力留到真正需要“人”的地方去。我自己手头的下一批实验正在往“多Agent协作但共享同一份状态草稿板”的方向走目前看起来比单Agent硬扛要靠谱得多。这个话题等数据跑完再单独写一篇。