智能体平台POC中，一次正常工具调用成功只能证明最窄路径可走。生产故障更复杂：工具明确拒绝、短暂失败、超时但其实已经执行、返回成功而业务状态未完成，都会让Agent做出不同决定。若平台把它们统一处理为“重试”，一个局部错误可能演变成重复写入、调用风暴或错误补偿。

失败压力测试的目标不是把系统压到崩溃，而是观察错误如何被分类、影响如何被限制、状态如何恢复、人工何时取得控制。本文提供故障注入思路，不规定统一并发或性能阈值。

先给工具动作标注可逆性和重复风险

测试前先盘点目标Agent会调用的动作。只读查询通常可以有限重试；生成草稿需要防止重复输出；创建或修改业务记录要考虑幂等；付款、通知或外部发布等动作可能不可逆，需要更严格审批和人工确认。

每个动作记录目标对象、调用身份、参数边界、预期结果、幂等标识、可否查询状态、补偿方式和最大重试。没有这些信息，平台无法在超时后判断下一步，POC也无法设计有意义的失败场景。

正常样本与失败样本使用同一业务任务，便于比较。第一时间跑通基线并保存完整时间线，再只改变工具响应或网络条件。不要同时换模型、Prompt和权限，否则无法确认恢复缺口来自哪里。

故障注入至少区分四类返回

明确拒绝表示工具收到请求并因权限、参数或业务规则不执行。平台应把拒绝反馈给计划，不自动扩大权限或盲目重试。快速失败表示请求未完成且状态明确，可以按动作风险和策略有限重试。

超时未知最危险：调用方没有结果，但工具可能已经执行。平台应先查询状态或交给人工判断，不能假设失败。业务失败则是接口返回成功，但后续业务未完成，例如创建请求成功却被下游流程拒绝，需要补偿或业务处理。

POC必须证明平台能区分“没执行”“可能执行”“已执行但业务失败”，否则任何自动恢复都可能扩大影响。

压力波形观察失败如何被吸收

下图展示正常调用、故障注入、恢复与人工接管的压力波形。阅读时关注故障出现后的波峰是否被重试、熔断或停止收敛，以及人工接管时上下文是否完整。

波形不是要求某种固定实现。平台可以采用队列、限流、熔断、暂停或其他机制，但应避免错误调用无上限增长，并让值守人员看见当前任务、受影响工具和待处理动作。

测试记录可以包含调用次数、状态分布、等待任务、工具端实际结果、Agent计划变化和人工动作。数字用于解释恢复过程，不应被包装成跨环境性能承诺。

重试测试要防止请求放大

将某个工具设置为短暂失败，观察平台的重试间隔、次数和并发。多个Agent同时遇到失败时，重试是否同步爆发，是否对工具和下游系统造成更大压力。恢复后，积压任务是继续、过期还是需要人工确认，也要明确。

对写入动作，重复请求应有业务级幂等或状态查询。平台侧请求ID如果无法被目标系统识别，仍可能重复执行。POC需要同时查看平台记录和工具实际状态，不能只看Agent认为自己调用了几次。

取消也是重试的邻居。用户终止任务后，排队中的调用、正在执行的工具和后续补偿如何处理？取消按钮若只停止页面显示，后台继续动作，会产生严重体验与治理问题。

恢复链要从业务状态结束

服务恢复在线不代表任务恢复。一个工具重新可用后，Agent需要知道之前步骤是否完成，是否应继续计划，业务对象是否处于中间状态，用户是否需要确认。恢复检查要从工具状态走到最终业务结果。

可设计一个含两步写入的任务，在第二步失败。观察第一步是否保留、是否需要补偿、恢复后是否重复第一步、人工如何选择继续或撤销。对不可逆动作，应预先限制测试在隔离环境或使用模拟工具。

故障恢复证据应包括任务计划、每次调用、工具端状态、重试或补偿、权限与审批、人工决定和最后业务结果。敏感参数可脱敏，但不能删除决定是否重复执行的关键信息。

人工接管用“陌生值守者”检验

让未参与流程搭建的值守人员接手一次未知结果。平台应提供用户目标、当前步骤、已执行动作、调用身份、参数摘要、工具响应、重试历史和推荐选项。值守者还要知道自己有权执行哪些动作。

接管不是简单重跑。可能需要查询目标系统、修改参数、补审批、执行补偿、终止任务或通知业务。每项人工动作应回写时间线，并把最终状态反馈给用户。

若值守者必须向开发者口头询问“刚才发生了什么”，说明平台没有提供运营上下文。可以在POC中补文档或流程，但要重新演练，不能只记录培训已完成。

压测边界由动作后果决定

低风险只读工具可以测试更高并发和故障比例；高风险写入应限制对象、次数和环境。测试前定义最大调用、最大持续时间、停止开关、影响对象和恢复负责人。任何可能触及真实敏感数据或不可逆业务的场景都应转到隔离环境。

故障注入的顺利获得不是“系统完全无错误”，而是错误被限制、状态可解释、恢复可执行。平台若在压力下选择拒绝新任务，只要拒绝清楚且保护了业务，也可能比继续接受后失控更合理。

无法立即停止的重复写入、越权恢复、未知结果盲重试和无上下文接管，应作为上线阻断，而不是普通性能缺陷。

用故障矩阵形成POC结论

对每种工具动作，选择最相关的拒绝、失败、未知与业务异常，记录预期处置和实际结果。结论按动作风险限定使用范围：只读场景可先上线，写入场景在幂等、审批和接管补齐后再放行。

相关Agent平台与治理内容可浏览 AI基础设施分类；整体AI方案信息可在核验后查看 AI解决方案。下一轮应复跑失败样本，而不是只重复正常演示。

放行规则要由工具所有者、Agent团队和运维共同确认，避免平台团队独自决定业务重试和补偿后果。

测试结束后还要让业务所有者确认实际动作和补偿后果，确保平台的恢复策略没有与目标系统规则冲突。

工具所有者还需确认故障样本覆盖真实业务语义，而不是只有网关层技术错误。

常见问题

工具正常调用顺利获得后为什么还要做失败压力？

因为正常调用只覆盖工具可用、参数正确和网络稳定的窄条件。生产会出现拒绝、超时、部分成功、重复请求和下游业务失败，Agent若无法区分，就可能错误重试、继续计划或给用户错误状态。

• 明确拒绝时检查是否停止并保留原因
• 超时未知时检查是否先查状态而非盲重试
• 重复请求时核对平台与工具端的幂等结果
• 业务失败时检查补偿、接管和用户反馈

失败压力揭示的是控制与恢复，不是追求破坏。测试可在隔离环境用模拟工具完成机制验证，正式系统的权限和业务语义仍需另行核对。

复核时要关联具体工具动作、调用次数、幂等状态、补偿和接管现场，确保失败压力结论能转成该工具的放行规则。

失败恢复测试要压到什么程度？

程度由工具动作的风险和生产规模决定。只读查询可提高故障比例和并发，观察重试是否收敛；写入和不可逆动作应限制在少量测试对象，重点验证幂等、状态查询、停止和人工接管。

• 先定义允许影响、最大调用、持续时间和终止开关
• 从单任务单故障开始，再观察多任务是否造成重试放大
• 恢复后检查积压、过期任务和业务最终状态
• 不在未授权的生产数据或真实高风险动作上做破坏性测试

没有统一的“压到多少”数字。POC要证明平台在企业预期负载和失败条件下保持可控，并清楚列出未覆盖规模。

POC中如何验证人工接管真的有效？

让未参与搭建的未来值守者处理一次具有未知结果的故障。接管页面或记录必须提供任务目标、执行历史、工具状态、身份与审批、重试、已完成动作和可选处置。值守者无需重复危险动作即可判断。

完成接管后，检查人工操作是否写回时间线，业务对象是否处于一致状态，用户是否收到最终结果，后续同类事件是否有可复用剧本。如果接管依赖开发者口头解释或直接访问底层高权限，说明机制尚未成熟。

人工接管完成后还要把处置结论沉淀为规则或剧本，减少同类未知状态重复升级。

复核时要关联具体工具动作、调用次数、幂等状态、补偿和接管现场，确保失败压力结论能转成该工具的放行规则。