[🤖] 我尝试把 Graph Engineering 应用到 Codex

✨ GPT-5.6 Sol 摘要

一次长达16小时的 Codex 任务以混乱告终后，我不断质疑 Graph Engineering 是否真能解决问题，最终把它做成最小化的 Gate Skill，并在真实的权限契约上进行了试验。

昨天，我花了很长时间讨论并写完一套用于 UI/UX 全面改版的逐页规格，然后给 Codex 设置了一个 Goal，让它按照这些规格开发。这个 Goal 跑了16个小时。

今天我满怀期待地打开页面，结果却只是一堆垃圾。

两天前，我才写过要摆脱 AI 一次施法就能完成一切的幻想。这一次我并没有只给一句指令。我定义了不同角色的工作和各页面规格，连日历与 table view、搜索与 filter、失败恢复都写得相当具体。经历失败的 prototype 后，我甚至还另外制定了 UI 审核标准。

然而，多个 worker 熬夜写代码并报告 test 和审核都已通过后，我看到的却仍是一个连它想表达什么都很难理解的老旧管理页面。我反复强调的日历和 table view 到底去了哪里，根本无从得知。

消耗了海量 token，改动了海量代码，也堆出了海量 PASS 报告。可我真正想要的结果并不存在。

我又一次变得谦逊。

所以这次，我决定试着把 Graph Engineering 应用到 Codex。不是学完一个最新流行词就算了，也不是先安装庞大的 framework，而是把它缩到能够切实减少眼前这种失败的最小形态。

我有了试验 Graph Engineering 的理由

我让 AI 分析事情为何会变成这样。公共规则有问题，UI 审核也过度偏向字号、button 高度这类容易测量的项目。但最大的问题在别处。

Codex 每次交付中间结果时，我并没有亲自确认。实现 session 自己宣布完成，其他 session 接过结果后继续制作下一批 page 和 backend。最初就错了的信息架构还没经过验证，便扩散到了多个页面。等我亲自打开实际界面时，16小时的工作已经全部堆在那个错误方向上。

所以我需要的并不是让 AI 跑得更久的方法。

我需要一种结构：只要中间结果错了，就不允许进入下一项工作。

在与 AI 持续讨论这个问题时，我接触到了 Graph Engineering 这个说法。它不是把一切交给单个 Agent 的长 loop，而是把多个 Agent、验证器和人的判断连接成 node 与 edge，并明确设计什么结果才允许进入下一阶段。与其说是全新的技术，不如说更像是近来开始用于称呼既有 workflow 和 state machine 思路的新名字。¹

重要的不是再背一个新 buzzword。如今，一个 Codex session 已经能够承担相当长的一整段工作，所以可以把该 session 产出的结果本身当作 node，再设计进入下一个 session 的条件。

把这次想试验的 Graph Engineering 套到问题上，大致是这样：

• node：用户能够独立审查的中间结果
• edge：根据审核结论返回修改或进入下一项工作的条件
• state：记录什么结果按什么标准受过审核，以及当前允许做什么
• cycle：审核发现缺陷时，只修正同一个结果并重新检查的循环

因此，多叫几个 Agent 本身并不是 Graph Engineering。我的试验核心，是先设计 topology 和状态转换，使未经验证的 node 无法打开后续 edge。

我画出的第一张 graph 只有工作 session 和审核 session

当我提出把 Graph Engineering 用在这个问题上时，AI 很快就开始把结构做大。Coordinator、Worker、Auditor 被拆开，又陆续加上用户方向审批、契约 version、durable ledger 和全量 cold audit。

单独看，每项都不算错。但我感到不安。

“这不是徒增复杂吗？”

为了防止16小时耗尽 token 却毫无成果，这次却要启动多个 Agent，再堆满状态和报告，那究竟有什么不同？如果“应用 Graph Engineering”本身又变成一项庞大工作，结果可能还是只会吞掉 token。

我设想的方式简单得多。

工作 session 完成一个可审查的结果。
→ 交给审核 session，工作 session 等待。
→ 审核 session 返回 PASS 或修改事项。
→ 只有这时工作 session 才继续。

我问能否把这个流程做成 Skill，以便反复使用。但 AI 总是谈 session 结构和机械强制的局限，把事情越说越复杂。于是我甚至拿来另一个 session 的回答，再次追问。

“把它做成 Skill 真的是低效吗？你是认真的？不是在自说自话吗？”

同时，我不断要求它不要无条件赞同我，而要进行批判。我想知道的不是“我的想法正确”这个结论，而是它是否真的能阻止那种16小时的失败，还是只是在制造一个看起来高明的新玩具。

在不断反驳中缩小试验范围

经过多轮批判性审查，我承认自己的简单方案也有漏洞。

如果工作 session 连审核标准也自己制定，它可能会选择对自己有利的标准。如果把工作者的 reasoning 和自我评价全交给审核 session，审核者也可能只是重读工作者的解释，而不是独立检查。审核期间若已开始下一项工作，PASS gate 就失去了意义。Runtime 已变化却仍审查旧画面，或对话 compaction 后误记之前的 PASS，也都可能发生。

反过来，AI 的所有提议也没有必要全盘接受。我舍弃了三个长期 session、单独的 graph runtime、DB、dashboard、对所有 page 的审核，以及契约一变就全量重审。全做下来，管理体系会比产品本身还庞大。

最后只留下这些原则：

• 主 session 同时负责协调和工作。
• 只有结果确实需要 Gate 时，才另开审核 session。
• 不把之前的完整对话交给审核 session。
• 固定待审结果，在审核完成前不改动该结果及其直接后续工作。
• 区分“实现错误”和“工作方向本身错误”。
• 修改一次并复审后仍有重大问题，就停止追加 patch，从计划重新开始。
• 契约改变时，只重审受影响的工作。
• 审核 PASS 不等于我批准产品方向，也不等于批准部署。

更重要的是，我决定不把这套结构套到所有任务上。一个错字、一次决定性的 test 就能解决的 bug、还不知道答案的自由探索，都不值得再开审核 session。只有在错误结果可能污染多个后续工作的节点上才设置 Gate。

我也不再机械地把一个 page 当作一个工作单元。如果用户的完整工作是从列表搜索、进入详情、完成处理，再回到原条件，那么整个 journey 才应该是审查单元。反过来，重复使用同一 pattern 的简单页面也没必要逐一单独审核。

这样削减之后，我最初想要的简单 graph 被保留下来，同时也明确了为何必须停下、到底审核什么。

把最小 graph 做成 Codex Skill

最后，我要求 Codex 制作一个名为 custom-graph-engineering-gate 的公共 Skill。OpenAI 已经提供了把重复 workflow 保存为 Skill、并由主 Agent 调用独立 subagent 回收结果的机制。²³ 因此无需另建 service，也能在 Codex 内实现工作 session 与审核 session 之间的往返。

我还要求不要把事情做大。没有执行 script，没有独立 DB，也没有 graph dashboard。只创建 Skill 正文和用于 Codex 展示的最少 metadata。

这个 Skill 主要做三件事。

第一，先判断当前任务是否真的重要到需要打开 Gate。只有错误中间结果会破坏多个后续结果时才使用。

第二，用一句话固定待审核结果。只记录用户最终得到的结果、区分成功与失败的标准、当前审核的准确 candidate、正常验证路径，以及 PASS 后直接开放的后续工作。改了多少文件、跑了多少 test，都不能替代用户结果。

第三，限制工作与审核之间的转换。

PASS              → 只推进直接后续工作
CHANGES_REQUESTED → 修正同一个结果一次，再次审核
REPLAN_REQUIRED   → 不是继续实现，而是重新审视契约或任务拆分
NOT_VERIFIABLE    → 没有证据就不得通过

审核 session 不继承此前的对话。我的愤怒、工作 session 有多努力、实现者认为哪里做得好，都不是审核证据。审核者直接查看原始要求和当前结果。

审核过程中 source 或 Runtime 一旦变化，旧判定就作废。如果中断或 compaction 后无法用真实证据恢复“哪个结果得到了什么判定”，就不得猜测它已经通过。

这与我最初提出的结构并没有太大不同。只是把“保留一个审核 session”这个想法中最容易遗漏的转换条件写进 Skill，让下一次 session 也能按同样的 topology 执行。

把做好的 graph 试用于真实契约

如果 Skill 做出来后我就直接相信它做得好，那和这次事故没有区别。因此，我把新 Skill 本身也交给了一个不继承此前对话的独立 reviewer。

首先，我确认了简单文案修改不该使用这个 Skill。在不需要的时候不用它，正是防止 token 浪费的第一项测试。

然后，我把多个功能都会依赖的权限转换契约作为第一个真实 node。冻结结果并交给审核 session 后，第一次 verdict 不是 PASS，而是 CHANGES_REQUESTED。契约没有充分说明权限按哪个时间点判断、委派权限来自哪里且撤销如何传播，以及用户、权限和目标公司是否确实绑定在同一 scope。

如果就这样扩展到多个功能，以后就必须重新拆掉整个权限边界。工作 session 只修改了同一范围，同一个审核 session 再次检查后才给出 PASS。在此期间，后续实现和部署始终关闭。

试验虽小，但我看到了想要的 Graph Engineering 效果。工作者认为“已经足够”的 node 没能打开后续 edge，问题在扩散到其他工作前被修正。只有同一个审核 session 再次检查修正后的同一 candidate 并返回 PASS，下一阶段才获准开启。

第一次试验通过了，但还不能说它解决了 UI 失败

第一次试验中，预期的 graph 确实运转了。但我还不能说这个 Skill 能防止那次16小时的 UI 失败。审核一个 source 相对明确的权限契约，与中途截停一个人看起来就觉得方向错误的 UI，是两种不同的问题。我还没有验证它是否能在真实的大型 UI 工作中减少总时间和 token。审核 session 与工作 session 使用同一个模型、查看同一个 Working Tree，也可能陷入同一错误前提。Skill 是指令，不是强制执行引擎。

所以下一次长期任务不能靠 PASS 数量来评价。

• 是否在全面扩展前抓住了第一个错误方向？
• 审核消耗的 token 是否少于它避免的返工？
• 我第一次看到临时结果的时间有没有被推迟？
• 工作 session 与审核 session 是否一起被同一个错误契约蒙骗？

如果没有效果，应该减少 Gate，而不是增加规则。如果同样的失败再次发生，也不该再加一层审核，而应先重新检查：最初把什么归为一个结果，又把什么证据交给了 reviewer。

知道 Graph Engineering 这个词，并不会让我突然变得擅长使用 AI。但这一次，我没有因为听到流行词就先安装庞大的 framework。我只留下针对自己所经历失败真正需要的 graph，不断反驳 AI 过度膨胀的建议，最终把它做成一个能在后续 session 中继续试验的小 Skill。

为了不再等到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 并回收结果。 ↩