听到 Graph Engineering，很多人的第一反应是又要学习一套框架：画节点、写边、定义状态，再做一个复杂调度器。其实，长期多 Agent 项目最先缺的通常不是编排代码，而是工作关系没有写清楚。谁负责当前阶段？什么证据证明可以前进？失败回到哪里？谁有权决定结束？
这篇文章给出一条新手能照着搭的路线：用一个 Goal 或总包任务记住最终目标，用独立任务承载每个阶段，用进度文档传递状态，再用审核门控制阶段切换。整个流程不需要先开发 Agent 框架，也不要求每个 Worker 继承前面所有聊天记录。先把第一张工作图跑通，再决定是否值得工程化。
一、Graph Engineering 实际在管理什么
这里的 Graph Engineering 可以先理解成“把长期工作拆成有状态、有门禁的工作图”。它不是某个必须安装的产品名称，也不要求所有节点都是模型。
一张最小工作图包含六种元素：
| 元素 | 在项目里代表什么 | 需要写清的内容 |
|---|---|---|
| 节点 | 一个 Agent、测试程序或人工步骤 | 谁负责、输入是什么、交付什么 |
| 边 | 阶段完成后的下一条路径 | 通过后去哪里，失败回哪里 |
| 状态 | 项目当前进度和已有证据 | 已完成、未完成、阻塞和版本 |
| 门禁 | 允许进入下一阶段的条件 | 测试、验收、运行结果和审批 |
| 返工 | 审核不通过后的修复路径 | 在原任务修复还是重新开任务 |
| 人工介入 | 必须交还给人的决定 | 外部写入、破坏性操作、价值判断 |
如果一个提示词只有“请把项目做完”，它没有图。它只有一个愿望。加上阶段、状态、门禁和返工路径后，模型才知道下一步不能靠猜。
二、用总包和 Worker 分开上下文
可以安排两类角色。
总包任务 T0 负责长期目标、阶段顺序、进度等待、独立审核和派发下一阶段。它不应该亲自把所有代码和文档都重做一遍，而是检查实际产物和证据。
Worker 任务只负责一个阶段。比如一个桌面产品可以拆成：
每个 Worker 有自己的上下文，可以打开自己的任务查看细节。它不需要知道前面所有对话，只需要拿到四类状态：上一阶段已经通过的结论、当前阶段文档、工作区现状和不能破坏的约束。
这会带来一个很实用的好处：某个阶段失败时，你能直接进入对应任务看它做了什么、执行了哪些测试、为什么没有通过、后来怎样修复。状态不靠一条越来越长的聊天记录维持，而是靠进度文档和任务结果交接。
三、先写阶段文档，再开 Agent
多 Agent 不能替你补齐模糊需求。每个阶段至少准备一份文档，包含：
阶段文档的重点不是写得长，而是让“完成”可以被别人检查。比如“完成安装功能”不够具体；“在干净环境安装，启动应用，创建一条数据，重启后数据仍存在，并保存日志”才是可验收的交付。
四、直接创建总包任务
准备好目标和阶段文档后，在 Codex 中创建一个总包任务，粘贴下面的最小模板。路径、阶段名和验收文件换成自己的项目内容。
这个模板有四个关键点。第一，阶段顺序写死，避免 T0 先创建还没有前置条件的任务。第二，审核由 T0 独立执行，Worker 不能用自己的口头结论替代证据。第三，不通过时回到原任务修复，保留问题上下文。第四，进度文档必须在创建下一阶段前更新，避免并行状态和真实状态脱节。
五、总包怎样审核 Worker
Worker 报告“已完成”后，T0 不要只读报告。至少检查四层证据：
审核结果建议写成结构化记录：
如果 T1 连续两轮出问题，T0 应该两次都不放行，也不要提前创建 T2。严格串行的价值，就是把“下一阶段依赖已经通过”变成事实，而不是一种乐观推断。修复完成后重新审核，保留第一次失败、修复内容和复审结果，未来才能知道门禁为什么存在。
六、运行中怎样介入
总包任务运行期间，你仍然可以改变尚未开始阶段的约束。例如告诉 T0：“从 T2 开始，新任务使用当前可用的高质量推理配置，并把降级情况写入进度文档。”
这条指令不应该回头改变已经运行的 T1，除非你明确要求重新执行。T0 需要把新约束标记为“后续阶段规则”，在创建 T2 时传入，并在进度文档记录生效点。这样可以避免一个阶段中途换配置，最后无法解释结果差异。
人工介入的边界也要提前写清：外部发布、破坏性操作、购买、修改权限、上传真实数据和最终产品决策，不能因为 Agent 正在持续执行就自动放行。安全的本地读取、编辑范围内文件和非破坏性测试，可以按授权继续。
七、等待与定时唤醒怎么配
派发任务后，T0 不需要每隔几十秒查询。使用事件等待，等 Worker 的状态变化、完成报告或失败消息出现，再进行下一次审核。高频轮询既浪费上下文，也容易让总包在没有新证据时重复下判断。
如果项目只运行几十分钟，事件等待通常足够。如果会跨越几小时或几天，可以在 T0 会话设置定时唤醒，让它按固定间隔回到同一上下文检查进度。定时唤醒的提示只需要说“检查当前阶段状态，若有新证据就审核或继续派工”，不要每次创建新的总包。
定时任务也可能遇到会话过期、权限变化、Worker 失败或外部环境不可用。每次唤醒都要先读进度文档和任务状态，再决定等待、修复、升级还是请求人工。不要因为一次唤醒没有看到变化，就把项目标记为完成。
八、Goal、独立任务和 Subagent 各管一层
这三个概念经常被混在一起，但职责不同：
| 机制 | 主要作用 | 适合场景 |
|---|---|---|
| Goal | 保持长期目标、完成标准和当前约束 | 一个长期但连贯的目标 |
| 独立阶段任务 | 管理严格顺序、阶段审核、返工和记录 | 有依赖的产品、论文或课程项目 |
| Subagent | 在当前任务内部并行做小工作 | 查资料、跑测试、局部审查 |
Goal 负责“最终要完成什么”，独立任务负责“这一阶段由谁完成和如何验收”，Subagent 负责“当前阶段内部如何加速”。一个复杂 Bug 往往只需要一个 Goal 和一个任务；多个互不依赖的资料检索可以由一个 Worker 派 Subagent 并行完成。
进度文档可以只保留一份简洁状态，而不是复制所有聊天：
状态文件的每一行都应该能指向一个任务或证据。它不是新的长篇日报，而是让总包在等待结束、定时唤醒或新任务打开时迅速恢复判断所需的最小上下文。
每次阶段通过、返工或规则变化时更新它，避免总包只凭旧聊天记忆继续派工。
不要用 Subagent 替代严格依赖的阶段。Subagent 的上下文和生命周期受当前任务影响，适合短小、可汇总的工作；如果它们要分别验收、分别返工、跨越较长时间，就应该提升为独立任务。Agent 越多，成本、文件冲突和共同盲点也会增加。
九、什么时候值得搭这张工作图
适合使用这套轻量 Graph Engineering 的任务，通常有明确阶段和可验证交付：
- 分阶段的软件开发；
- 论文的结构修改、内容重写和引用检查；
- 课程的设计、制作、录制和发布；
- 产品的原型、开发、测试和交付；
- 数据项目的采集、清洗、分析和报告。
不适合的情况也很明确：目标仍在探索，阶段边界不断变化，验收标准无法写出，或者每个阶段都需要实时共享同一份不稳定状态。此时先做一个短任务和人工检查，不要为了“看起来像图”而增加总包和多个 Worker。
十、限制与结论
轻量 Graph Engineering 处理的是工作关系：谁负责、凭什么前进、失败回到哪里，以及谁拥有最终决定权。它不是把模型数量越堆越多，也不是用一个提示词假装拥有完整调度器。
新手可以从一张阶段文档、一个 T0 总包和一个 T1 Worker 开始。等第一阶段真的经历一次失败、返工、复审和通过，再决定是否增加 T2、定时唤醒或内部 Subagent。先把状态和门禁跑通，再考虑框架化；否则只是更快地把模糊目标分发给更多 Agent。
