信任多智能体编码工作流前,先测这五个失败场景

matimatthews · reddit · 2026-10-09

作者(正在开发 Backplane)提出一份多智能体编码工作流的设计检查清单,指出 happy-path demo 只能证明 agent 能完成任务,不能说明需求变化、worker 掉线或外部操作结果不确定时会发生什么。

建议测试的五个失败场景:

评审后改需求:代码和测试可能还是绿的,旧评审也还是 approved,但已不满足新需求。完成记录应同时标识代码版本和需求版本,识别哪些检查需要重跑。
worker 失去认领后又回来:agent A 停止汇报、认领过期、B 接管后 A 重连并提交结果。过期机制利于恢复,但系统需要拒绝 A 的过期写入,不能让它悄悄覆盖 B 的工作。
外部写入的响应丢失:创建 release 但响应超时。「未收到确认」和「创建失败」是不同状态;应使用幂等机制或对可识别操作做对账,结果不确定时明确暴露不确定性,而不是让模型编造成功或盲目重试。
批准一个动作后改范围:人批准了 preview 部署,下一步却试图上生产。转录里的批准不够,动作边界应校验实际目标与范围是否与批准一致,还要防绕过路径。
不带原始对话重启:只给下一个 worker 保存的项目记录,看它能否识别当前需求、最新产物、已完成检查和下一步被允许的动作,从已知检查点恢复或提出具体问题。

「编程与Agent」频道最新