设想一次询盘排查：表单提示提交完成，销售却没有收到通知。第一次排查认为是邮件通道延迟，后来又发现队列积压，Agent便在同一段对话里改写结论。到复盘时，团队只看见最后那份报告，不清楚早先判断依据是什么，也不知道它为什么被放弃。问题不只在于有没有找到原因，还在于调查过程能否解释得清楚。

AWS在10月2日的DevOps Agent更新中加入调查分支：可以从时间线中的一条消息开始，继承此前历史，再沿另一方向调查，而不改变原调查。对外贸网站的询盘链路，这提供了一个有用的工作方式：当解释开始分叉，先保留共同事实，再分别验证，不必让新猜测覆盖旧分析。

从共同事实处分开，而不是复制最终结论

分支起点应选在双方都认可的证据之后。例如已经确认表单产生了请求记录，但尚未确认该请求是否进入通知队列。此时一条分支检查接收与排队，另一条检查通知投递，比复制一份已经认定“邮件故障”的总结更合适。后者可能把待验证判断当作前提带进所有支线。

每条支线只需写清一个待回答问题，以及什么观察会推翻它。假设请求没有进入队列，就应寻找对应请求的队列记录；若记录存在，应修正这条假设，而不是继续搜集与它一致的零散错误。Agent输出的语气再笃定，也不能代替这一步。

调查时还应标注证据的时间。分支继承的是起点之前的历史，不会因为保留了上下文，就自动知道后来系统发生的变化。故障已经恢复后读到的健康状态，应记为后续观察；不能拿它否认故障发生时的异常。需要时重新读取相关记录，并说明观察窗口。

两份报告最终要回答同一件事

合并结果时，先列出哪些解释被排除，依据是什么，再说明仍成立的解释与缺口。不要按报告长短或措辞强弱选一个“胜出者”。如果两条支线都缺少同一段日志，结论应该保留未知，而不是让其中一个Agent替缺失证据做决定。

对中国外贸团队，业务终点也必须一致：是否确认买家的那次请求进入了正确业务记录，通知发给了谁，还有没有待处理项。只证明服务器恢复或测试邮件可达，不足以说明原请求已经完成交接。询盘故障时间线讨论的是先重建事实顺序；调查分支则用于在这条共同时间线上比较不同解释。

分支调查本身不应扩大执行权限。为了验证猜测而重提买家表单、重复发送跟单邮件，可能制造另一笔真实业务动作。能先查已有记录就先查；必须做测试时，使用已批准的测试身份和清晰标记。生产修复仍需单独明确范围、确认和恢复安排。

一份可交接的故障报告，最好能让下一位同事沿着问题走回证据，而不是只接受最后一句判断。保留原分析与替代分支，是为了减少“刚才为什么这么改”的猜测；只有验证过的解释才进入修复依据，尚未查明的部分继续留在问题清单里。

参考来源