[🤖] AI 的中间结果一旦出错，我就先挡住后续任务

✨ GPT-5.6 Sol 的总结

“检查全都通过”的报告掩盖了错误的信息结构，它继续扩散到后续页面和 backend。于是我规定，review 之前不能开始下一项工作。

报告说“检查全都通过”，我信了，打开的页面却还是一堆垃圾。但这篇文章要抓的问题，发生在那个最终页面出现之前。

最初跑偏的信息结构没人拦住，后续页面和 backend 便继续叠在上面。于是我让错误的中间结果先关掉后续任务。

PASS 报告把错误页面养了16小时

Codex 每次交出中间结果时，我并没有亲自看。实现会话自己宣告完成，其他会话就在它上面继续做页面与 backend。错误的信息结构还没经过验证，就扩散到多个页面。等我最后打开 UI，16小时的工作已经全压在错误方向上。

我需要的不是让 AI 跑得更久。

中间结果错了，就必须阻止下一项工作开始。

追查这个问题时，我遇到了 Graph Engineering：不把长 loop 全交给一个 Agent，而是把可审查的结果与前进条件设计成明确的 graph。¹ 我并不需要宏大的 graph runtime，只需要一件事：未经验证的结果不能打开下一条 edge。

“是不是又搞得没必要地复杂了？”

我一提 Graph Engineering，AI 就拿出 Coordinator、Worker、Auditor、合同 version、durable ledger、dashboard 与全量复审。每一样都听着有道理。但要是为了防止16小时浪费，先把管理系统做得更大，那很可能只是同一种失败。

我的第一张 graph 只有工作会话与审计会话。工作会话完成一个可审查结果后停止。审计会话只看冻结的结果与原始要求，不看旧对话气氛和工作者自评。需要修改就只改同一个结果一次；方向错了就回到计划，不继续打 patch。审计结束前，直接后续任务保持关闭。

反驳也补上了这个小设计的漏洞。工作者不能自己制定有利的审计标准；Runtime 或候选结果改变后，旧 verdict 作废。Gate 也不用于错字或一个 test 就能判断的 bug，只放在错误结果可能污染多个后续任务的位置。

我把这些做成 custom-graph-engineering-gate Skill，没有另建 DB 或 dashboard。它冻结一个结果，再根据 PASS、CHANGES_REQUESTED、REPLAN_REQUIRED 或 NOT_VERIFIABLE 限制下一步。Codex Skill 与 subagent 已经足够。²³

第一道 Gate 真的挡住了后续任务

Skill 创建完成不代表有效。我把多个功能都会依赖的权限转换合同冻结为第一个真实结果，交给没有旧对话的审计会话。

第一次 verdict 不是 PASS，而是 CHANGES_REQUESTED。合同没有讲清楚权限以哪个时间点判断、委托权限从哪里来又如何撤回，以及用户、权限、目标公司是否属于同一 scope。如果它继续扩散，日后要拆掉整个权限模型。

工作会话只修改了这个结果一次；同一审计会话复查后才给出 PASS。期间后续实现与部署都没开放。这正是我要的效果：工作者说“够了”的地方，下一条 edge 真的被关上了。

一次权限合同审查不能证明它能避免下一次16小时 UI 失败。人的视觉判断更难设 Gate，使用相同模型与 Working Tree 的审计者也可能共享同一个错误前提。Skill 也不是强制执行引擎。

但这次我没有因为听到新名词就先装巨大 framework。我只留下这次失败真正需要的 graph，并把它缩到下一次长任务还能再次试验的大小。

为了不再等16小时才发现整个方向都错了。

参考资料

1. LangChain，“3 Years of Graph Engineering with LangGraph”，介绍 Graph Engineering 这一新近用语，以及把 Agent workflow 设计成显式 graph 的视角。 ↩

2. OpenAI，“Build skills”，介绍把可复用 workflow 保存为 Codex Skill 的官方方式。 ↩

3. OpenAI，“Subagents”，介绍主 Agent 创建独立 subagent 并收回结果的结构。 ↩