Graph Engineering：纯 Claude Code 实现
这篇写什么 Graph Engineering 的完整落地通常是：Python + LangGraph 当指挥官，Claude Code 当执行者，pytest 一类命令当 quality gate。有时不想额外起一个 Python 主控进程，只想在 Claude Code 里把一段有依赖关系的多阶段任务当图来管。 本文只写这条路径：控制流、节点隔离、跨节点状态都尽量落在 Claude Code 自带能力或手工骨架上，不接 LangGraph。图工程「为什么需要」以及三层分工的完整论述见母文；这里默认读者已经接受「用有向图拆专职节点、把控制流从 Prompt 里抽出来」这一目标。 能落地到两种深度，选哪种取决于要不要付节点隔离和显式状态的成本。 轻量方案：任务队列当 DAG DAG（Directed Acyclic Graph，有向无环图）说的是：节点之间有方向（A 依赖完成后才能做 B），但不能成环（不能出现 A → B → A，否则永远等不到起点）。任务列表里的「阻塞 / 被阻塞」关系正好就是这种结构——依赖边把阶段串成可调度的顺序，而不是随便挑一个未完成任务开干。 Claude Code 自带的任务系统（创建 / 更新 / 列出任务）可以把每个阶段建成一个节点，用「阻塞 / 被阻塞」关系显式建边，状态走 pending → in_progress → completed；某个节点的依赖没完成前，它不会出现在「可执行」列表里，相当于用依赖门控替代了「下一步该做什么」的临时判断。 执行仍然发生在同一个会话、同一段上下文里：Agent 顺着依赖关系挑下一个已解锁的节点，直接实现，完成后回写状态，再挑下一个。没有节点隔离，也没有单独的图执行器在跑——图的推进是模型手动读状态、手动调用更新接口完成的，不是由代码在每一步自动求值条件边。跨节点的「状态」也不是一个结构化的 state 对象，只是任务列表里的标题 / 描述 / 状态字段，加上还留在同一段对话历史里的实现细节。 适合依赖关系不复杂、能在一次会话内跑完、不需要严格隔离上下文的多阶段任务——比如按一份规格文档的实现顺序逐节点推进。 示意如下： Claude Code 单会话 +------------------------------------------+ | Task list (DAG) | | A ──► B ──► C | | pending / in_progress / completed | +------------------------------------------+ | | 同一对话上下文里依次执行 v 实现 → 回写任务状态 → 挑下一个已解锁节点 重量方案：子代理 + 独立工作树 + 显式状态文件 如果需要的是真正的节点隔离，通常要在 Claude Code 里手工搭三件东西： ...