AI Agent 出错先查哪里：一份按业务结果排查的运行手册

收集任务标识、用户或业务组、对象编号、时间和可见症状。不要让用户在群里粘贴完整订单、token 或客户聊天记录。诊断人员通过受控入口查看必要证据，普通通知只说明影响范围和当前处理。

若发现越权读取、重复业务写入或持续发送错误消息，先关闭相关动作或队列。保留只读查询能力有助于核对结果，但也要确认查询权限本身正常。不要在尚未了解影响时扩大重试或解除限制。

AWS 的重试指导强调限制重试、避免多层放大，以及非幂等调用的重复副作用。运行手册必须把可重试与需要人工处理的情况分开，不能只有一个通用“重新执行”按钮。

从用户输入到最终业务结果，至少能定位检索、模型调用、工具调用和外部服务这几个阶段。记录时长、状态、版本以及必要的业务标识，判断是模型等待、检索失败还是工具重试占用了时间。

OpenTelemetry 的 GenAI 介绍说明可记录模型、token 和时长等信息，并提醒完整输入与工具参数可能包含敏感资料。本文建议默认记录结构化元数据，必要内容经过脱敏与授权后查看。不要把私密推理过程当作运维必须采集的字段。

同一个任务要能关联多个调用，但任务标识不是授权凭证。维护人员拿到一个标识，也要按权限查看；跨租户的记录不能因为进入同一追踪系统就互相可见。

演练中，创建工单接口已经提交数据库，返回包在网络中丢失。Agent 认为失败，又创建了一次。排查先按业务请求标识查询工单，确认存在两条结果，再检查调用记录中是否复用了同一个幂等标识。

若工具每次重试都生成新标识，问题在意图与重试的绑定；若相同标识仍重复写入，问题在服务端一致性；若服务正确去重但页面显示两次，问题可能在回调或界面事件处理。分别修复，不能把三类问题统一归因于模型。

已经重复创建的记录由业务规则决定合并、取消或保留审计，恢复脚本不应擅自删除真实对象。这个场景是教学演练，应在隔离环境中复现。

恢复不是一定回到原来的路径。若来源资料已撤回或业务条件已改变，任务应该停止并重新确认。保持旧计划继续执行，可能比失败本身更危险。

记录触发输入、影响、原因、处置、版本和复测结果。把复现样本加入回归集，必要时更新工具错误说明、字段约定和告警。保持对真实业务结果的检查，避免修复后只验证 HTTP 返回成功。

告警要指向能处理的人。只报告“模型出错”很难行动；报告“退款查询结果未知，任务已暂停，需核对支付交易状态”更容易接手。保留去重和升级规则，避免同一故障连续通知拖垮值班人员。

未找到根因时如实记为未知，说明采取了什么限制以及还需什么证据。不要把恢复运行等同于原因已经解决。

复盘还要检查当时的告警是否到达正确的人、是否提供了可查询的任务入口，以及暂停动作之后旧队列是否仍继续执行。仅修复一条请求不能证明影响已经结束；负责人应核对受影响时间段的业务对象，按企业流程处理遗漏或重复结果。

先选系统最重要的三类任务，列出失败阶段、查询入口、暂停方式、负责人和恢复前提。让一位非原作者按手册处理模拟异常，找到缺失步骤，再逐步扩充。

本文适合有工具与业务服务的 Agent。只读问答也需要排查检索、版本和权限，但恢复动作可以更轻。手册不能替代底层系统的专业事故响应，应该明确何时升级到接口或安全负责人。