运维智能体的批准，必须经得起一次故障

2026年10月13日，DXC 宣布与 LangChain 合作，面向企业 IT 运维。这提供了一个值得深入的问题：人工批准智能体的操作之后，系统还必须保证什么？

三种记录不能混在一起

LangGraph 持久化文档区分单个线程的检查点与跨线程保存的信息。中断文档提醒，恢复被中断的节点时，中断之前的代码会重新执行。这是框架特性，不是对某个客户部署成效的独立验证。

我们的判断是，运维控制系统必须分别回答：什么获得了授权、什么已经尝试执行、外部系统究竟发生了什么。对话记录能说明意图，却不能证明目标系统接受了操作。反过来，目标系统返回成功，也不代表操作符合之前给出的授权范围。

故意制造一个难处理的验收场景

假设智能体被要求在维护窗口内重启一项服务。操作员批准了具体服务和环境。重启请求已经到达服务器，但连接在确认回执返回之前断开。智能体等待期间，另一名操作员又修改了维护计划。

此时不能默认再重启一次。有效的验收测试应要求智能体识别原操作、检查目标系统状态，并确认之前的批准是否仍然适用。如果无法确认结果，升级人工处理应被视为正确行为，而不是任务完成率上的失败。

这个例子是我们提出的测试，不是 DXC 发生过的事故。它揭示了采购验收的一个缺口：演示系统可以暂停等待批准，并没有覆盖从批准到外部结果得到确认之间的全部过程。网络故障或业务条件变化，恰恰可能在这个区间让原本合理的计划失去适用性。

不只统计完成了多少工单

采购方可以要求四项演示。批准后改变目标，检查旧批准是否被悄悄沿用；重复结果不明的请求，检查是否产生重复影响；在任务等待时撤回权限，检查执行前的权限边界；最后，让接班操作员只凭留存证据还原结果，不依赖智能体的口头解释。

这些是我们建议的评价标准，不是已经核验的产品功能。它们也有成本：证据留存需要访问控制，异常队列需要责任人，人工审核需要明确的响应时限。只增加批准弹窗，却不给这些流程配置资源，可能只是把瓶颈换了位置。

因此，更有意义的指标，是具有匹配授权、目标系统确认结果和明确恢复路径的重要操作比例。合作公告说明了产品方向；能否放心用于生产环境，需要观察这些记录互相矛盾时系统的实际表现。