多智能体协作故障复盘应该留下什么多智能体系统发生故障时很容易得到一句没有帮助的结论“模型判断错了。”模型输出确实带有不确定性但事故往往是在不确定输出穿过了工程边界后才被放大任务状态没有退出条件工具错误被反复重试上下文在多个角色之间无限传递或者关键动作没有留下可关联的执行记录。复盘的目的不是证明某个模型不可靠也不是完整保存每一轮对话。它应还原一次任务怎样进入异常状态、系统为什么没有及时阻止、用户或业务受到什么影响、修复后如何证明同类问题不会再发生。只有把问题落在可修改的流程、权限、状态和观测上团队才能积累真正的经验。从影响和时间线开始而不是从猜测开始复盘先记录已确认事实异常何时被发现影响了哪些任务或用户自动化做了哪些动作何时恢复期间是否发生外部副作用。时间线不需要抄录所有日志但关键状态转换、工具调用、配置变更和人工介入应能对应到可追溯的来源。将事实与推测分开尤其重要。某个 Agent 在失败前输出了某段建议并不直接证明它是根因它可能只是在上游工具已返回异常后作出了错误响应。将“观察到的行为”“当前假设”和“支持证据”分别写下后续补充信息时不会把猜测逐渐变成既定事实。影响范围也应包含未受影响部分。是某类请求、某个租户、一个工具接口还是整个工作流受影响哪些安全门正常拦住了风险了解边界有助于决定修复优先级也能识别哪些既有控制值得保留。还原状态与工具调用的关系多智能体协作通常包含规划、执行、验证、等待输入、失败、取消和完成等状态。异常发生时应检查任务在每个状态下允许哪些动作、谁能够转换、重试和超时是否生效。许多看似模型导致的循环其实是状态机缺少终止分支或者不同执行器对同一任务状态产生了冲突更新。工具调用需要记录足够的元数据使用的工具和版本、操作类型、经过校验的参数摘要、开始结束时间、结果类别、错误分类和关联任务标识。没有必要保存完整敏感载荷也不应记录模型内部推理过程系统需要的是能够解释外部动作和状态变化的审计证据。当工具失败时复盘要判断系统是否正确区分了可重试与不可重试错误。超时、临时服务不可用和配额限制可能需要有限重试权限不足、参数错误和资源不存在通常应尽快停止并反馈。若所有错误都被包装成同一种异常智能体只能盲目地再试一次。检查上下文边界和输入可信度多个 Agent 之间传递上下文时可能把不必要的历史、外部文本或工具错误一同带入后续决策。内容过长会增加理解噪声未经处理的工具输出还可能携带与任务无关的指令。复盘应检查每个角色真正需要哪些字段是否有明确的结构化摘要外部数据是否被当作普通数据而非控制指令。上下文隔离不仅关乎质量也关乎权限。负责分析日志的角色不一定需要看到完整用户资料负责生成草稿的角色也不应拿到执行写操作的凭据。按任务最小化输入和工具权限能减少一次错误在角色间扩散的机会。若异常与某个提示模板、模型版本或知识库版本相关应记录版本关系和输入摘要而不是把完整用户内容复制进复盘文档。必要的原始材料可在受控存储中按权限保留并设置删除期限。让观测能够回答实际问题统一的任务或追踪标识应贯穿入口、Agent 节点、工具调用、异步消息和人工接管。这样出现异常时团队可以从一个任务找到相关步骤而不必在不同系统里按时间猜测关联。标识本身不能包含用户隐私或业务敏感信息格式也要稳定方便跨系统查询。观测事件的设计要服务于排障谁触发了任务当前状态是什么执行了什么受控动作是否重试、熔断或等待审批结果如何。记录每次模型原始文本不一定有帮助反而可能带来成本和隐私风险。对于高风险决策可以保存经过审查的理由摘要、规则命中情况和人工批准记录。事件量过大时应考虑采样与分级。正常低风险任务可以保留较少细节失败、人工接管或权限拒绝事件则保留更完整的技术上下文。无差别全量记录常会让真正重要的异常淹没在噪声中。修复要变成可验证的规则复盘如果只以“加强提示词”结束通常无法防止同类问题再次发生。更有价值的改动是补上明确的状态转换、工具参数校验、重试预算、超时取消、权限门或回退路径。改动应指出它覆盖哪个失败条件以及仍有哪些边界没有解决。失败样本可以进入回归测试但要先脱敏、最小化并确认可合法保存。测试不只验证模型是否输出某句文字还应验证系统在错误工具结果、空数据、重复任务和超时条件下是否停止在正确状态是否没有产生重复副作用。这样测试保护的是流程不是某个偶然的措辞。如果修复涉及模型、提示、工具或状态机版本也要保存对应版本。否则后续回归失败时无法判断是哪个变更重新引入了问题。发布前在低风险范围复测并观察实际任务结果才能确认规则真的起效。复盘结论需要可执行的后续结论中应区分立即修复、需要进一步调查和长期改进。每项有明确负责人、验证方式和状态避免停留在“优化协作”“提升智能”等宽泛表述。对尚未确认的假设应保留验证计划而不是强行定性。同时记录这次处置中有效的做法。某个审批门阻止了错误操作、某条追踪链加快了定位、某个重试上限避免了资源耗尽这些都值得作为后续设计的依据。复盘不只收集失败也要识别已经发挥作用的控制。多智能体故障的复杂不在于角色数量多而在于状态、工具、上下文和权限如何交织。留下可验证的时间线、受控的调用证据、明确的边界和可回归的修复下一次异常才不会再从零开始排查。