最近 Agent 圈又火了一个词：Graph Engineering。

很多人的第一反应可能是：这是不是又要学一套新框架，画一堆节点，最后再写一个复杂的调度器？

我先把结果摆出来：

我利用 Codex 现有的机制，一个提示词实现了轻量的Graph Engineering。

我没有写 Agent 编排代码，只给 Codex 准备了阶段文档、一个总目标和一段提示词。

它真的创建了一个负责等待、审核和继续派工的包工头，还有3个可以单独打开的任务，依次处理三个阶段。

这篇文章我会向你展示我的做法，给你能直接运行的提示词

耐心看完，小白也能直接上手

包工头正在盯着小弟们干活

1.Graph Engineering 到底在做什么

Graph Engineering 是 2026 年 7 月突然进入 Agent 圈讨论的新标签。Peter Steinberger 当时在 X 问了一句：[“我们还在讨论循环，还是已经转向图了？”](

https://x.com/steipete/status/2078277297791189132

)

这个词目前没有统一的行业标准，也不是 2026 年才突然出现的一项新技术。LangChain 在 2024 年发布 LangGraph 时，已经用节点、边和状态来组织循环工作流与多 Agent 协作。

最近的讨论只是把一个越来越常见的问题推到了台前：

当你让多个 Agent共同完成一个长期目标时，工作应该怎样连接？

用最简单的话解释：

  • 节点：谁负责这一步，可以是 Agent、测试程序，也可以是人；
  • 边：这一步结束后去哪里；
  • 状态：现在完成到哪，留下了什么结果；
  • 门禁：凭什么进入下一阶段；
  • 返工：审核不通过时回到哪里；
  • 人工介入：什么决定必须交还给人。

Graph Engineering 概念图：不同工作节点共享状态，并通过分支、审核与人工确认形成输出

2.我是怎么做的

这次任务是一个 Windows 桌面产品化项目，我已经提前写好了三个版本的阶段文档：

v1.0.0 桌面入口迁移👉v1.1.0 安装与数据管理👉v1.2.0 首位外部测试者交付

我给 Codex 安排了两类角色：

  • T0 总包：看总目标、等待进度、独立审核、决定返工还是进入下一阶段；
  • T1/T2/T3 Worker：一个任务只负责一个版本，在自己的上下文里实施和验证。

**项目的状态用进度文档来传递。**Worker 不需要继承上一阶段的全部聊天，只需要知道已经通过的结果、当前阶段的要求和工作区现状。

实际使用的 Codex Agent 工作图：上层是用户、定时唤醒、共享状态与 T0，下层是三个阶段子图

整个过程最终留下三个可以单独打开的任务，而不是一个任务里的三段回复。

某一阶段出问题时，我可以直接打开对应任务，查看它做了什么、为什么没通过、后来怎样修复，不需要重读前面所有聊天。

Codex 侧边栏中留下的三个独立阶段任务

3.让总包来审核小弟的工作

总包只执行三条核心规则：

  1. 阶段任务完成实施和验证后，由他检查实际产物、测试和真实运行结果；
  2. 审核不通过，就在原任务中追加修复，等待完成后重新审核；
  3. 审核通过后，先更新进度文档，再创建下一阶段任务。

下面是我的实测：

T1 worker出现了两轮问题，总包两次都没有放行，也没有提前创建 T2。修复完成后，T1 的报告测试、验收和两轮复审都记录下来了。T0 查证据后才给出 v1.0.0 通过结论。

T1 完成修复并通过 v1.0.0 审核

4.运行中仍然可以介入

T1 运行期间，我告诉总包：从 T2 开始，新建任务统一使用 luna 的最高推理模式。

总包回复收到后，继续去监视小弟们干活了

5.设置个定时任务让总包偶尔看看进度

本次实测主要使用事件等待：

总包派发后通过 Wait threads 等待小弟们的状态变化，不进行高频查询。

如果项目会跨越几个小时或几天，可以在总包所在会话设置定时任务，让 Codex 按固定间隔回到同一会话检查进度。

会话内定时任务会保留已有上下文；独立定时任务每次从保存的提示词开始，更适合互不相关的周期性检查。

6.先复制这个最小模板⭐⭐

使用前先准备好每个阶段的目标、验收标准和进度文档，然后替换三个变量：

plaintext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/goal

总目标：[项目或总目标]
阶段清单：[阶段一 → 阶段二 → 阶段三]
阶段文档位置：[需求、验收标准和进度文档所在位置]

你是总包任务 T0，持续管理整个任务链，直到全部阶段完成。

按照阶段顺序执行：
1. 为当前阶段创建一个独立执行任务；
2. 执行任务按照阶段文档完成实施和验证；
3. 完成后由 T0 检查实际产物、测试、运行结果和验收条目；
4. 不通过就在原任务中追加修复，等待完成后重新审核；
5. 通过后先更新进度文档，再创建下一阶段任务。

每次派发后进入事件等待，不要频繁查询。
未经我明确要求，不得因为等待超时而结束或归档任务。
只有全部阶段通过并完成最终进度更新，整个 Goal 才能结束。

收到后直接创建第一个阶段任务。

这段最小模板规定了阶段顺序、审核证据、返工路径和结束条件。

模型选择和定时唤醒可以根据你的需要加入提示词。

7.什么时候值得这样做

我会把它用于这些任务：

  • 分阶段的软件开发；
  • 论文的“结构修改 → 内容重写 → 格式与引用检查”；
  • 课程的“设计 → 制作 → 录制与发布”；
  • 产品的“原型 → 开发 → 测试 → 交付”；
  • 数据项目的“采集 → 清洗 → 分析 → 报告”。

前提是你已经写清每个阶段的完成标准。

如果标准仍然模糊，多开几个 Agent 只会让它们更快地朝不同方向努力。Agent 越多，还会带来更多成本、文件冲突和共同盲点。

8.Goal、独立阶段任务和 Subagent 各管一层

方式 主要作用 适合的场景
Goal 模式 让总包持续记住最终完成标准 一个长期但连贯的目标
多阶段模板＋独立任务 管理阶段顺序、审核、返工和记录 严格串行、分别验收的项目
Subagent 在当前任务内部并行处理小工作 查资料、跑测试、代码审查

Goal 模式负责维持长期目标，可以使用 /goal 启动，并在同一任务中继续调整约束。

Subagent工作流是中，主 Agent 可以委派多个 subagent 结统一汇总。它适合并行探索和审查，但主要有两个问题：

  1. subagent的上下文只存在于当前对话
  2. subagent可能会因为运行过被截断

因此我的组合是：

  • 总包使用 Goal 模式持续运行和监管
  • 小弟负责需要分别验收的阶段
  • Subagent 只处理小弟内部可以并行的小工作。

一个复杂 Bug 或一份连续报告，直接使用 Goal 更省事。多个有严格依赖的长期阶段，才需要增加独立任务和审核门。

附录：我的模型与等待配置

如果要复现我这次的角配置，可以把下面规则追加到最小模板：

plaintext

1
2
3
4
5
6
7
8
9
10
等待与模型规则：

- 总包、模块负责人和最终审核使用 gpt-5.6-sol，推理强度 xhigh；
- 常规执行代理使用 gpt-5.6-luna，推理强度 max；
- 如果指定模型不可用，重试一次；仍不可用时，使用当前环境可用的模型和允许的最高推理挡位，并记录降级情况；
- 严格依赖或会修改同一批文件的阶段不得并行；
- 如果任务跨越数小时或数天，可在 T0 会话设置定时唤醒；每次唤醒只检查状态并继续原流程，不得创建新的总包；
- 运行中收到新指令时，只修改尚未开始的后续任务；已经运行的任务保持当前配置，除非用户明确要求改变；
- 除非需要改变目标、超出文档范围、执行破坏性操作或进行人工验收，否则自动继续；
- 未经用户明确要求，不得归档总包任务或执行任务。

写在最后

Graph Engineering 要处理的是工作关系：

谁负责、凭什么前进、失败回到哪里，以及谁有最终决定权。

你不需要先开发一套调度框架。先用一个总包、几个独立 Worker 和一道审核门，把第一张工作图跑通。

先把工作关系跑通，再决定要不要写框架。