Agent 出故障时，客户怎样给开发方一份可复现的问题包

Agent 出故障时，客户给开发方最有用的材料是一个能定位且可安全复现的问题包：什么时候、哪个版本、做什么、预期怎样、实际怎样。整段聊天截图或一句“又不行了”都不足以定位，直接发全部客户资料又会扩大暴露。本文提供业务 Agent 的脱敏工单模板，使用三条合成问题，不涉及任何真实故障实测。

先描述业务影响，再写技术现象

开头写受影响任务、对象范围、是否有业务副作用和当前处置。例如“合成工单创建超时，可能已建单，已暂停重复提交”，比“接口报错”更能指导排障。写明是否仅一人发生、是否持续、最近一次正常时间与是否已有临时替代流程。未知的影响直接标未知，不为了完整而编造受影响人数、成功率或损失金额。

时间记录带时区，保留业务任务号、执行号与目标请求号之间的关系。不同系统的编号分列，不把截图中的任意数字当作统一追踪号。若问题涉及权限，记录合成角色与授权范围，不发送真实会话令牌。开发方可以凭追踪号到获准系统查看必要记录，不能因为收到故障包就获得无限制访问客户环境的权利。

固定版本与最小输入

记录应用、工作流、模型配置、知识资料和工具适配的版本，以及发生前最近一次变更。模型只写供应商名称不够，资料也不能只写“最新文件”，应能指向具体受控版本。最小输入保留触发条件与字段类型，去掉与故障无关的隐私。订单号、姓名与附件内容可以替换为合成值，但要维持长度、编码或格式特征，避免脱敏以后问题消失。

下载故障交接与复现模板。三条合成问题分别是查询无结果、确认后写入未知和文档引用版本错误。每条包含重现步骤、预期、实际、已尝试措施和禁止动作。模板实际结果留空，由演练人员填写，不把想象结果当观察。原始证据与合成复现分开保存，脱敏方法、映射持有人与访问期限写清，必要时由授权人员进行原始核对。

步骤应让接手者无需猜测

按用户动作顺序写输入、选择的对象、是否确认、返回内容与等待时长，不只写技术人员想当然的节点链。只读问题可在隔离环境重复；有副作用的问题先替换为模拟目标，并说明原动作是否已经发出。开发方不得为了复现反复提交真实订单、发消息或删除数据，任何真实写入需要明确授权和具备权限的人确认具体参数。

失败结果也要有结构化信息。RFC 9457定义 HTTP API 问题详情的机器可读格式，可作为适配层错误输出的参考。它不要求客户把内部堆栈全部公开，也不保证每个现有平台都采用该格式。故障包可记录错误类别、受控问题编号和可重试判断，详细诊断留在受限位置，通过追踪号关联。

写操作未知时先冻结重试

接口超时、页面断开或机器人没有回复，可能只是回执丢失。问题包标明原请求号、确认摘要与最后已知阶段，要求先查询目标状态，不得生成新业务号直接重发。若后续人工已处理，登记处理时间与目标单号，避免开发方复现时又做一次。回退流程配置也不能撤销已经完成的业务动作，补偿需要独立预览与批准。

把已尝试的措施写成事实：重启哪一层、改了哪个配置、何时恢复到原值、结果是否改变。不要只写“都试过了”。每次变更固定一个变量并保留版本，多个同时改动会让复现难以解释。临时放宽权限、开启详细日志或扩大通知范围，都应有批准与到期清理，不能为了排障留下长期高权限后门。

交接后要有明确接收与关闭条件

指定客户侧业务联系人、技术联系人与开发方处理角色，故障等级与响应时限按实际业务约定，不编造行业统一标准。开发方先确认已收到哪些材料、哪些依赖仍缺失，再给出复现或无法复现的证据。无法复现不代表问题不存在，可能来自权限、数据版本、并发或时间窗口，应把下一项需要的观察写清，而不是要求再发一遍完整隐私数据。

修复完成后使用原失败样例和一条正常基线复测，涉及授权、重复写入与未知结果的边界也要检查。关闭条件是业务结果与故障记录一致，遗留影响得到处置，临时诊断配置已撤销。问题包本身按期限清理，第三方附件和邮件副本也盘点，避免每次排障都积累一份长期无人管理的客户资料。

附件也要可识别版本与完整性。问题包保存生成时间、文件清单与摘要，避免多个同名截图和日志混在一起。开发方收到后确认能够打开且标识相符，缺文件时点名缺少哪一项。对话中讨论的推测与已经观察到的事实分列，根因尚未证实时不把猜测写进最终结论。

相关背景见流程自动化专题和项目运维问题，未知结果可读超时核对与补偿。需要梳理已交付 Agent 的故障交接方式，可通过定制咨询提交脱敏任务描述与组件范围，建立能由双方复核的问题包。