AutoDev 09：系统失败时，别只留下一句“它不行了”¶

某次任务失败后，日志只留下六个字：“Agent 执行异常。”这句话信息密度和“车坏了”相当。 值班同学不知道失败在哪个阶段、哪一版代码、哪个命令，也不知道重试会不会再创建一个 MR。

一个能自动写代码的系统，如果失败时只会耸肩，多少有点角色塑造不完整。

记录事件，不倾倒现场¶

AutoDev 为阶段开始、完成、失败和状态转换记录结构化事件，并关联 task、run、revision、 provider 和 SHA。命令证据保留必要的命令标识、退出码和有限输出，而不是把整个 CI 日志 原封不动塞进状态文件。

日志越多不等于越可观测。真正有用的是能回答：什么任务、在哪个阶段、基于哪版代码、 观察到什么事实、系统因此做了什么决定。

脱敏发生在保存和送模之前¶

Webhook、仓库文件和 CI 日志都视为不可信；命令输出可能意外打印 Token。证据在持久化、 写报告或交给 Repair Agent 前必须经过裁剪和脱敏。Secret 不进入 Prompt、Transcript、 fixture 或报告。

“日志平台会控制权限”不能替代源头脱敏。秘密一旦被写出来，就已经开始了一段不必要的 职业冒险。

测试不只覆盖大团圆结局¶

AutoDev 将配置、Webhook、SCM、Admission、Gates、State、Lease、CI 和安全逻辑分别 测试，并用集成测试覆盖 Workspace、Workflow 与 Publish。新的工作流行为需要成功、失败、 取消和 replay 测试。

Replay 尤其关键：它验证重复事件、进程恢复和远端副作用不会制造第二份结果。失败测试则 确认系统能进入明确终态、释放租约并留下有限证据，而不是卡在“processing”直到后人把它 当成历史遗迹。

可观测性不是给系统装一个漂亮仪表盘，而是建立一条可追问的证据链。AutoDev 没有 UI， 但它必须能清楚回答自己做过什么。

下一篇，我们把这九篇里散落的选择收起来，变成一套可以带到其他 Agent 工程的方法。