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