Agent能扛多大的事？四维承重设计与压测实战

你的Agent，能扛多大的事儿？这个问题我最近被问得最多，不是来自那种刚看完发布会的新手，而是来自已经折腾过几轮 prompt、堆过不少工具、把 demo 跑得飞起、但一碰真实业务就崩盘的中级玩家。大家手里都会有个能聊天、能查资料、能调接口的 Agent，但一旦任务从“帮我写一封邮件”升级成“帮我把这个月的售后工单全部处理掉，分类、回复、标重点、还要汇总报告”，它就开始掉链子。

这个现象非常典型。我一直强调，Agent 的能力不等于模型的智商，也不等于上下文的长度。它真正的水平，是你能不能把一个复杂的、多步骤的、环境会变化的真实任务拆成一个它扛得住的“体力活”。这篇就来聊聊，怎么判断你的 Agent 能扛多大事儿，它扛不住的时候会有什么信号，以及怎么一步步把它练成大块头。适合已经过了入门阶段、正在把 Agent 往生产环境里推的开发者、技术负责人和自动化爱好者。

1. 先别急着上强度——Agent到底扛的是什么事

很多朋友对 Agent 的认知，还停留在“一个对话机器人，只不过聪明一点”。但真正到了工作现场，Agent 本质是一个“任务执行体”：给它一个目标，它得自己拆解计划、调用工具、处理异常、拿回结果。这跟人接活是一个道理，一个人能同时管三条流水线，不代表他能管三十条；能处理两个小时的深度任务，不代表能连续跑二十个小时不崩。

所以，“能扛多大的事儿”并不是用 token 长度或者对话轮数来衡量的，而应该是用任务复杂度、并发压力、环境不确定性、失败恢复成本这四样东西来衡量。你在开发环境里测的每一次单轮问答，都只是热身，压不了真实负载。

拿我常用的例子来说。你让 Agent 帮你做一份行业调研报告，它只要搜几个网页、总结一下、排个版，这属于“轻体力活”。但如果你让它全自动盯一周竞品动态，每天抓取数据、识别变化、生成简报、有重大更新还要发给你并触发后续动作，这就不一样了：数据源会变动、网页结构会改、文本会缺失、接口会超时。Agent 要能自己发现“这次的采集结果不对劲”，还要能决定是重试、换源，还是停下来报错。

这才是真正的工作负载。理解了这件事，后面的所有讨论才有基础。

1.1 任务规模不等于模型上下文长度

我先泼一盆冷水：把 Agent 扛事儿的希望押在大上下文窗口上，是最常见的误区。我见过不止一个团队，觉得把模型换成 200K 上下文版本就万事大吉，结果任务跑到一半照样滑向混乱。

为什么？因为上下文越长，模型对早期信息的关注度会逐渐衰减，这是所有当前主流模型都存在的注意力漂移现象。上下文窗口变大，只是“座位变多”，不代表模型记性变好。让 Agent 扛大量任务，真正的问题在于它能不能把关键信息随时捞回来、保持优先级、不让垃圾细节淹没决策。这就跟你坐在一个有一万本档案的办公室里，档案多不等于你能更快找到需要的那一份。

举个我实际遇到的例子。某次压测中，我让 Agent 连续处理八十多份 PDF 发票，把关键字段提取后汇总成表。初始设置很简单：把所有文件路径塞进上下文，让它一个个读。结果前二十份挺好，到了第五十份左右，开始偶尔漏字段，甚至把不同供应商的数据混到一行。不是模型变笨了，而是后面每处理一份新文件，前面信息的权重就被冲淡，它渐渐“忘了”自己最早收到的字段格式约束。后来改成外部状态表、每次只加载单份文件再回填结果，准确率就稳定在接近满分。

这就是第一课：局部任务的承载能力，取决于你对信息流的控制，而不是模型的窗口大小。

1.2 Agent 扛事儿的四个真实维度

既然任务规模不是单看上下文，那应该看什么？我根据多年实践，把 Agent 的“承重指标”拆成四个维度。

第一是任务深度。一个任务从头到尾，需要经过多少步才能完成？会不会有分支？会不会有需要回溯改做的节点？比如“生成一个网站”比“生成一个网站页头”深度高得多，因为前者涉及需求梳理、结构设计、代码生成、样式调整、测试反馈多轮迭代。

第二是并发宽度。Agent 同时要维护多少条独立的执行线？比如批量处理一百个客服工单，最粗暴的方案是循环一个 Agent 串行处理，那速度会慢得没法看；好的方案是并发分成多个子任务并行跑，但这就引入了新的问题——资源竞争、结果顺序错乱、共享状态冲突。

第三是工具链复杂度。Agent 要调用多少个不同接口？这些接口返回的数据结构是否统一？有没有需要多个工具配合才能完成的操作步骤？工具越多，幻觉攻击面越大，Agent 越容易在“调用哪个工具”这件事上犯糊涂。

第四是状态一致性要求。如果任务中断了，重跑一遍会不会重复扣款、重复发消息、覆盖掉已有数据？这决定了你能不能让 Agent 鲁莽地往前冲，还是必须给它加一堆确认点和幂等保护。

把这四个维度装在脑子里，再去评估你自己的 Agent，你会发现它“该练哪里”一目了然。后面我会逐个展开。

2. 拆解Agent的“体力”：四个维度的承载上限

每一个维度单独拿出来，都有值得讲清楚的设计逻辑和关键参数。下面这部分，是我在搭建各种模拟项目 X 的 Agent 时，沉淀下来的核心心得。

2.1 单次任务深度：规划链到底能走多长

单次任务深度，是最容易理解、也最容易低估的维度。日常 demo 里，Agent 往往只需要“理解指令 → 搜索 → 回答”三步循环，但真实业务任务动辄需要十几步、甚至几十步。

一个典型的深度任务流程可能是这样的：用户报障 → 提取工单号 → 查询订单系统 → 拿到物流轨迹 → 判断异常类型 → 查找补偿规则 → 计算补偿金额 → 起草回复话术 → 送审 → 记录结果。这十步里还要包含几个条件分支：物流轨迹正常就走 A 方案，异常就走 B 方案；补偿金额超过阈值要人工复核。

Agent 要扛住这种深度，关键在于几点：

第一，任务规划要显式化，不能靠模型每次临场发挥。我给 Agent 配任务流的时候，一定是先让它输出一个结构化计划，再逐步推进。计划里要包含目标、当前步骤、关键输入输出、退出条件。自己写个极简版：

{ "goal": "处理售后工单 WS-10086", "status": "running", "steps": [ {"id": 1, "action": "fetch_order", "args": {"order_id": "from_ticket"}, "next_on_success": 2, "next_on_failure": "notify_human"}, {"id": 2, "action": "fetch_logistics", "args": {"order_id": "step1.result.order_id"}, "next_on_success": 3} ], "context": {"current_step": 2, "accumulated_results": {}} }

用这个结构，Agent 每次执行下一步前，先去状态文件里读“我在哪、做过什么、下一步是什么”。而不是让大模型凭记忆自己往下接。实测下来，显式计划能把成功率和稳定性都拉上一个台阶。

第二，要预设“环路保险”。深度任务最常见的翻车点是陷入无效循环——某个步骤没达到预期，Agent 反复重试同一个动作，次数不设上限。比如调一个接口超时，它连续重试十几次，耗时耗钱且没有任何收益。我通常会在计划节点上加 max_attempts 参数，超过次数就跳转到降级策略。

第三，中间结果要持续沉淀。深度任务里，后续步骤往往依赖前面步骤的输出。如果所有中间结果都丢在模型上下文里，靠记忆接力，那上文说的注意力漂移问题就会在长任务中出现。所以，我在每个步骤完成后都会把关键结果写入外部存储，第二步读取时直接访问存储，而不是依赖模型的“回忆”。

实际压测数据是：三段式浅任务，成功率轻松超过 98%；同样模型跑十五步以上的深任务，不做显式规划时成功率可能掉到 85% 以下。别小看这十几个百分点，放到生产环境里，就是每天几十次莫名其妙的失败。

2.2 并行度与并发能力：一个Agent能同时管几路

串行处理一切，是最可靠的，也是最慢的。真实场景里，你不可能让一个 Agent 一份一份地读完了三千封邮件你才下班。想提速，就要上并行。

但并行有个坑：Agent 不像线程池，塞给它一百个任务，它不会自动均衡调度。你需要自己设计并发模型。我在项目里比较推荐的，不是“一个 Agent 内部并发”，而是“一个编排器 + 多个 Worker Agent”的结构。

编排器负责拆任务、分发、回收结果、汇总状态。每个 Worker Agent 只干一个原子子任务。举个例子，批量处理一百份合同摘要，我不让一个 Agent 读一百份文件，而是让编排器循环启动十个 Worker，每个 Worker 分配十份文件，各自独立运行、独立写结果。最后编排器再统一汇总。

这时候有几个关键参数要调：

• 并发数：不是越大越好。超过一定数量，API 限流会让成功率断崖下跌，同时每个 Worker 的上下文如果塞太多文件，单个 Worker 也会开始出错。我一般从 3 到 5 个并发起步，观察误差率和耗时曲线，再逐渐往上加，找到一个“吞吐/质量”的甜点区。
• 结果合并策略：并行 Worker 各自返回结果，如果格式不统一，汇总阶段就是灾难。我要求在分发任务时，给每个 Worker 附带一个标准 JSON Schema，要求它严格按这个格式输出，否则算失败重跑。
• 状态隔离：每个 Worker 是否操作同一个数据库？会不会同时修改同一条记录？这个问题不解决，并行跑着跑着就会出现互相覆盖的脏数据。我在设计中会让每个 Worker 只操作分配给它的记录 ID 范围，写操作加锁。

别被“并行”两个字迷惑，真正的并行是体系化的工程，不是简单地在 for 循环里多个 promise 一起发请求。我以前犯过这种错，结果就是跑了十分钟出来，一半结果字段错位，排查到凌晨。

2.3 工具与环境交互的复杂度

工欲善其事，必先利其器。Agent 能调用多少个工具，决定了它能干多少活；但工具越多，它犯迷糊的概率也越大。这中间需要平衡。

我认为工具数量的安全线，在单个 Agent 内部最好控制在 8 到 12 个以内。超过这个数，模型在每一步“选哪个工具”时就开始犹豫，偶尔会拿错工具或者给工具传错参数。这不是模型商不够，而是注意力被分散了。解决办法是分层：编排器层的工具少而精，只负责分发和状态管理；下层 Worker 各自只挂四个五个专用工具，比如一个 Worker 只挂“读取本地文件”和“调用解析接口”两个工具，它能选错吗？很难。

工具命名也非常关键。我给工具起名，从来不用含糊的通用词，比如“处理数据”，而是起得尽量像按钮标签：“extract_invoice_fields”“translate_to_en”“send_slack_message”，让 Agent 一看就知道这玩意儿是干嘛的。工具描述里写清楚适用场景、输入输出格式、可能的异常。别小看描述，很多 Agent 出错是因为工具描述太简略，它根本不知道这个工具在什么情况下该用。

还有个实操细节：工具返回结果的截断策略。有些接口返回一个巨大的 JSON，Agent 读的时候读到一半就晕了。我通常会在工具返回层做预处理，只保留关键字段拼成简洁字符串再喂给模型。比如数据库查询工具，我可以设一个 max_rows=20，超出的部分统计后返回“共返回 500 行，已截断显示前 20 行，最后更新时间 ...”，这样模型既拿到了全貌，又不会被刷屏。

这一步做得越细，Agent 的“外表看起来”越聪明，其实这就是工程设计给它托的底。

2.4 长期记忆与状态一致性

最后一个维度，也是生产环境里最难搞的：长期记忆和状态一致性。

很多 Agent 的“记忆”是会话级别的，聊完就忘。但真实业务任务，经常要跨越几天甚至几周。比如一个运营 Agent 帮你盯营销活动效果，它需要记得上周制定的策略目标，接着这周的数据继续分析。如果每次会话都从零开始，那就等于每周都换一个新员工，没有任何连续性。

长期记忆的常见实现方法有两种：一是把关键决策和中间结果写入外部数据库，下次任务启动时先加载；二是做一个“摘要记忆”，每次会话结束，把本次的要点总结成几条固定格式的文本存下来，下次作为前置信息注入提示词。

我用的是第二种，因为它对模型的干扰最小。每条记忆格式类似：“[决策] 7月第三周，A/B 测试中绿色按钮版本转化率高 12%，后续活动默认使用绿色按钮。”这样的条目，一旦超过二十条就做二次摘要，避免信息膨胀。稳定性和可解释性都好很多。

状态一致性方面，重点其实是三层：

• 幂等性：一个动作执行多次，结果必须一样。尤其是涉及扣钱、发消息、改数据的操作，配置操作前必须查一次是否已经做过。
• 确认点：在关键副作用动作之前，插入人工确认或者规则校验。比如“当补偿金额超过 500 元时，不自动执行，转人工”。
• 恢复策略：任务中断后，重新拉起时能不能接着断点走，而不是从头再来？这就需要上面提到的显式计划文件持续更新，让新会话一启动就知道该从第几步继续。

如果这三点没做好，你的 Agent 就跟一个记性差又喜欢自作主张的新员工一样，你根本不敢把重要事交给它。

3. 一个实际案例：模拟项目X的“一小时任务压力测试”

前面说了这么多理论，来个实际案例。我给某公司内部搭建过一个自动化工单处理 Agent，这里叫它“模拟项目 X”。任务很简单：每个工作日，把前一天的售后工单全部处理完，包括分类、初步诊断、回复建议、标记紧急程度。平均每天几百份。

第一版我直接搞了个超级单体 Agent：把工单数据全读进去，让模型一个一个处理完再统一输出。结果跑起来又慢又容易崩。后来我痛定思痛，重构为分层结构。下面把压测方案和核心实现同步一下。

3.1 压测环境与任务定义

我设定了一个标准压测脚本，模拟真实工作流。环境很简单：一台普通开发机、一个开源大模型的 API、一个轻量数据库存状态。任务定义如下：

• 输入：一百条脱敏后的售后工单，字段包括工单号、用户描述、产品类别、购买时间、是否 VIP。
• 目标输出：结构化处理结果，包含：(1) 问题分类（五类：物流/质量/退换/咨询/投诉）；(2) 严重程度（高中低）；(3) 回复建议草稿；(4) 是否需要人工介入。
• 约束：单次压测时间不超过 60 分钟；成功率不低于 95%；不允许出现不同工单结果互相串线的数据污染。

这个任务深度大约 6 到 8 步：读取工单 → 分类 → 判断严重性 → 生成回复 → 写入结果 → 更新状态。

3.2 关键配置和代码骨架

整个系统分三层：编排器、Worker Agent、工具层。编排器的核心逻辑大致是这个思路：

async def run_batch(tickets): # 1. 初始化批次状态，记录每个工单的处理状态 state = initialize_batch_state(tickets) # 2. 拆分成 N 个并发批次，每个批次交给一个 Worker batches = chunk_tickets(tickets, size=10) results = await asyncio.gather(*[ process_batch(batch, worker_name=f"worker_{i}") for i, batch in enumerate(batches) ]) # 3. 汇总结果，校验字段完整性，写回数据库 final_result = merge_results(results) validate_and_save(final_result) return final_result

Worker Agent 内部则严格按“先读计划 → 执行工具 → 写中间结果 → 进入下一步”的循环。它每次只处理一份工单，手里的工具只有两个：fetch_full_ticket_detail(ticket_id)和write_result(ticket_id, result_json)。工具少到没有选错的可能。

为了让模型稳定输出，我给 Worker 的提示词里写死了一个 JSON 模板，并声明“你只需要返回这个 JSON，不要回答任何多余内容”。为了让结果可校验，我在系统提示词外加了一个正则解析兜底：如果模型返回的内容不是合法 JSON，就自动重试一次，再失败就标记为需要人工处理。

3.3 实测结果和观察

我先不加并发，串行跑了一百条，耗时 80 分钟——太慢，而且到后半段开始出现分类模糊。然后改成 5 个并发 Worker，每个 Worker 处理 20 条，总耗时骤降到 22 分钟，成功率从串行的 96% 升到了 98.5%。

这个结果很有意思：为什么并发之后成功率反而更高？我的分析是，每个 Worker 分到的任务更少，上下文更干净，注意力不会被一百份工单的嘈杂内容干扰。也就是说，减小单任务粒度，本身就是一种提质的优化，并不仅仅是提速的手段。

后来我把并发数加到 10，成功率掉回 96%，耗时只比 5 并发少了 3 分钟。这就是前面说“并发不是越大越好”的实证。最后我把 5 并发定为默认值，留给 20% 的余量给突发高峰。

那次压测给我最大的收获是一句话：“想把 Agent 扛大事，先学会把大事分成一箩筐小事，再让一群小 Agent 分别扛。”

4. 扛不住的时候，会出现哪些典型崩溃信号

你不需要等到 Agent 彻底跑挂了才发现它扛不住。它在濒临崩溃的时候，会发出一系列特征信号。我总结成了一份“崩溃前兆清单”，你可以在日常监控里设置对应的告警项。

4.1 上下文漂移：做着做着就“忘本”了

最典型的信号，就是 Agent 处理任务到后期，开始偏离初始指令。比如你让它处理工单并严格输出 JSON，它却突然开始输出大段解释性文字；或者你设定分类只有五类，它在第七十份时凭空造出个第六类。这就是我之前说的注意力漂移在高压力下的显性表现。

怎么识别的？我每次压测都会统计输出格式合规率。如果某个 Agent 的合规率曲线是前高后低——开始接近 100%，往后逐渐下滑——那基本可以断定它到了承载临界点。这时候不是骂模型笨，而是你要降载了：拆小批次、减少上下文累积、加外部存储。

4.2 工具调用空转：忙了半天啥也没干

第二个信号是工具调用次数暴增，但有效结果没增加。Agent 可能在反复查询同一个 ID、反复调用同一个接口，或者调用了工具却不使用返回值，就当完成了一次操作。

我见过的极端案例：一个 Agent 在五分钟内调用了同一个搜索接口七次，每次返回结果一样，它也照样点下一轮。原因通常是它的计划文件里没有“某步骤已经达成目标”的判定，它不知道什么时候算完，只知道自己“应该继续干活”。

应对方案很实在：给工具调用加结果缓存——同一参数在短时间内重复调用，直接返回上一次的结果，并且告诉 Agent“该查询已执行过，结果未变化”。这一招能把空转速降下来一大半。更进一步，可以在编排层设置工具调用预算，比如“单个任务最多调用 30 次工具”，超过就强制停下来让 Agent 重新规划，避免空转烧经费。

4.3 放弃效应：遇到一点阻碍就转人工

还有一种崩溃，不是跑飞，而是“躺平”。Agent 遇到一个稍微复杂的异常，比如字段缺失、接口报错、返回格式不符，就直接判定“处理不了”，把任务踢回人工队列。这可能看起来安全，但也意味着你的自动化覆盖率虚高，实际上不少单子都悄悄漏到人那边去了。

我处理过的最夸张情况里，Agent 会因为一条工单里没有“购买时间”字段，就放弃处理整份工单。后来我在工具层加了默认值填充逻辑，缺失字段标记为“unknown”，并允许 Agent 在部分信息缺失时依据剩余信息做降级判断，放弃率立刻大幅下降。

这里要强调：不是所有任务都必须硬扛，但在设计上，应该让 Agent 在放弃之前至少尝试一条替代路径。如果每次都是一碰壁就转人工，那你的 Agent 只能扛十成中的一成。

4.4 结果污染：上一单的数据跑到下一单

最后也是最可怕的信号：结果串线。A 工单的回复建议跑到了 B 工单里面，或者 A 数据的分类结果写进了 B 的存储记录。这在人工处理时不太会发生的事，在并行 Agent 系统里却时有发生。

原因一般是两类。一类是共享变量被并发覆盖，比如多个 Worker 同时读写同一个内存对象。另一类是模型上下文里的实体混淆，当一份工单和另一份工单高度相似，且上下文里同时存在多个未闭合的对话片段时，模型可能把两个实体的信息拼接在一起。

我的预防手段很简单：

• 每个任务的结果文件独立，命名带 ticket_id，禁止写公共文件。
• 输出校验时做字段级交叉检查，比如回复建议里的用户姓名是否和当前工单匹配。
• 并发的 Worker 之间尽量物理隔离上下文，不共享记忆。

结果污染是隐蔽性最高的坑，往往在数据已经入库、影响已经扩散之后才被发现。所以校验逻辑一定不能省。

5. 一套可落地的“增肌”方案：从能用到扛得住

发现 Agent 扛不住不可怕，可怕的是不知道从哪开始练。这一节给出一套我反复使用、真实跑通过的系统化加固方案，从能用到扛得住，分四步走。

5.1 编排层加装限流与熔断

第一个要动刀的地方，是编排层。很多人以为加并发就是写个 async，结果一压就限流。我建议在编排器和上游接口之间放一层“流量阀”。

class RateLimiter: def __init__(self, max_per_minute=60): self.tokens = max_per_minute self.last_refill = time.time() self.capacity = max_per_minute async def acquire(self): # 按照固定速率补充令牌，超过容量则等待 pass # 实现略：实际上线用 Redis 令牌桶更稳

限流之外，熔断也必须有。如果上游接口连续返回错误超过阈值，编排器要能立刻降级，改成串行、减小并发、或者切换到备用模型源。这跟服务治理里常见的熔断是同一个思路，但很多人做 Agent 时忘了这层，默认 API 永远可用。

有一次线上故障就是因为上游模型服务波动，Agent 还保持满并发地不断重试，结果把配额直接打光，整个系统卡死了一下午。有熔断的话，错误率一飙，编排器自动把并发降到 1，至少还能以慢速维持服务。

5.2 给Agent配“体外记忆”：外部状态库

除了把中间结果放在外部存储，我强烈建议把 Agent 的“记忆”做成一个可读写的状态库，而不是藏在提示词里。最简单的实现，就是一张数据表：

每次 Agent 执行步骤前，先来状态库读取 current_step 和 accumulated_json；执行完一个步骤，立刻把新结果写回去。这样即使进程崩溃重启、或者换一台机器继续跑，也能精准地接着断点走。

这同时也是可观测性的基础。你随时可以查一个任务卡在哪个步骤上，而不是靠猜。

5.3 任务分解器的升级路径

任务分解质量直接决定 Agent 的承载上限。低级分解是“把任务切成同粒度的一块块”，高级分解是“识别任务内部的依赖关系，再做拓扑排序”。

打个比方：你要让 Agent 完成“上线一个营销页面”。幼稚的做法是把任务切成“写文案”“做设计”“写代码”三块，然后用三个并行 Agent 分别跑。但跑起来就会发现，代码要依赖文案成品才能嵌入，设计图要依赖文案长短才能定排版，没有依赖关系分析的分解，并行就是在制造混乱。

升级后的分解器应该输出一个 DAG，标注哪些步骤可以并行、哪些必须串行、哪些需要回环。可以参考一个简化的配置：

{ "stages": [ {"id": "copywriting", "depends_on": [], "parallel": true}, {"id": "visual_design", "depends_on": ["copywriting"], "parallel": false}, {"id": "frontend_dev", "depends_on": ["copywriting", "visual_design"], "parallel": false}, {"id": "qa_review", "depends_on": ["frontend_dev"], "parallel": false} ] }

用这套 DAG，编排器能精准知道哪几步可以塞进同一批并发的 Worker，哪几步必须等上游完成才能开始。任务分解从“拍脑袋”变成“按依赖算”，Agent 的利用率才会有质的提升。

5.4 用多Agent协作分摊压力

最后一个增肌大招，是放弃“一个全能 Agent”的执念，改为“一队专职 Agent”协作。这和大型组织一个道理，全公司如果只有一个“全能员工”，他必然什么都做不好；分设客服部、技术部、运营部，各管一摊，整体效率才高。

比如前面说的模拟项目 X，最终形态就不是一个 Agent 处理所有工单，而是三个专职 Agent 协作：

• 分类 Agent：只负责读取工单标题和描述，输出问题分类。
• 诊断 Agent：拿到分类结果，结合订单数据做初步诊断。
• 回复 Agent：根据诊断结果生成回复话术。

这三个 Agent 之间通过状态库传递数据，彼此语言不通都没关系，因为靠的就是结构化的数据接口，而不靠模型的自然语言理解。这样分工之后，每个 Agent 的任务深度、工具数量、上下文长度都大幅降低，整体稳定性和可调试性反而大幅提升。

代价是系统复杂度上升、调用次数变多，但换来的却是“能扛事儿”。当你确实有批量任务要处理的时候，多 Agent 协作几乎是绕不开的一步。

6. 验收与压测：怎么知道你的Agent扛住了

系统改造完之后，不能靠自我感觉良好，得有一个可重复的验收流程。这一节说说我是怎么做压测和验收的，照着抄即可。

6.1 先定义你业务的“最大承重”

压测之前，先明确你的生产场景最重的一个任务长什么样。比如你是电商客服场景，最重任务可能是“双十一当天每小时涌入一千个工单”，每个工单平均处理时长不能超过两分钟。那就把这两个数字当作压测目标。

我给模拟项目 X 定的目标就很具体：一千条工单，四小时内处理完，成功率不低于 95%，人工介入率不超过 20%。所有压测都围绕这个目标展开。

6.2 搭建压测套件与评估指标

压测不是写死一个脚本跑一遍就完事，而应该做成一个可持续回归的测试套件。我一般准备三类数据：

• 黄金测试集：一百条覆盖各种正常情况的工单，结果已由人工标注为“标准答案”。
• 边界测试集：二十条带缺失字段、异常格式、极端长度的工单，看 Agent 的降级处理能力。
• 压力测试集：一千条混合数据，模拟高峰流量，测试整体吞吐和稳定性。

核心评估指标，我用四个就够：

• 成功率：完成且结果格式合法、字段无串线的工单占比。
• 人工介入率：Agent 主动转人工的比例，越低越好。
• 平均完成时间：从任务到达到写入结果的时间。
• 预算消耗：总 token 消耗、工具调用次数，确保后续上线掐住成本。

每次压测跑完，把四个指标连同 Agent 版本号一起记到测试报告里。这样你能看到改动前后的趋势，而不是“感觉好像稳定了”。

6.3 通过阈值判断：能扛与不能扛的边界

判断 Agent 能不能扛住，我给一个相对严格的经验阈值，供参考：

• 成功率不低于 95%，黄金测试集上不低于 97%。
• 人工介入率不高于 30%，且转人工的任务都能给出明确的理由说明。
• 平均完成时间在生产目标的一半以内，预留出波动空间。
• 在高并发下，工具空转率不超过 10%。

如果四个指标全部达标，基本可以放心让这套 Agent 进入更接近真实的生产压力；如果有一项不达标，回到上一节看是哪个维度出了问题。

有一件事必须说：压测不是一锤子买卖。你的数据分布会变、上游接口会变、模型版本会变，这个月扛得住的配置，下个月不一定扛得住。把压测脚本加入发布流程，每次上线改动都跑一遍，才是负责任的做法。

7. 收尾：一点踩坑体会

最后说点纯个人经验。我踩过最大的坑，是早期为了让 Agent “聪明”，把所有逻辑全塞给大模型临场发挥，结果系统像个天才实习生：状态好时惊艳，状态不好时一塌糊涂。后来我越来越体会到，Agent 能扛多大事儿，九成靠工程，一成才靠模型。

你的规划器够不够清楚、状态存得够不够稳、工具层有没有兜底、并发控制有没有熔断，这些才是决定它能扛一百条还是一万条任务的根本因素。ChatGPT 级别的智能只是发动机，发动机再猛，没有变速箱和刹车，它就不敢上高速。

再分享一个小技巧：每次升级完系统，我都会拿上个月真实的数据回放一遍，和旧的 Agent 版本做 A/B 对比，而不是只看单元测试的假数据。因为真实数据里的脏乱差，才是锻炼 Agent 承重能力的健身房。你的 Agent 迟早要面对这些，早点用真实场景练它，后面才不会被突然出现的生产事故打懵。

就聊到这儿。如果你正被某个“一跑就崩”的 Agent 项目折磨，回去第一件事，先把它的任务做一次分解梳理，再把状态管理加上，八成的问题都能缓解。