从单循环到图工程：在 learn-harness-engineering 中构建你的第一张 Agent 编排图

本文基于 第 14 讲「从单循环到图工程」（含 英文版）展开，结合仓库内的参考实现 maker_checker_graph.py 与配套实战项目 Project 08. 把工作流画成一张图，讲解图工程（Graph Engineering）的核心概念、单循环的三种结构性失败，以及从零构建第一张 Agent 编排图的完整六步方法。读完你将掌握：图与工作流的本质区别、图的四个基本部件（节点、边、共享状态、路由规则），以及如何把上一讲构建的 maker-checker 单循环升级为可运行、可断点续跑、可局部修复的显式图。

背景：一个玩笑催生的流行词

第 13 讲完成的循环工程（Loop Engineering）走红六周后——2026 年 7 月 18 日——OpenClaw 的作者 Peter Steinberger（就是上一讲中提出"别再给编码 Agent 写提示词"的那个人）发了一条推文：

"你们还在聊 loop 吗？还是已经转向 graph 了？"

一条推文，一天内获得约 57.5 万次浏览，月底增长到约 300 万。几小时后，机器学习工程师 Hamel Husain 发布了一篇题为《Loop Engineering Is Dead. Enter Graph Engineering》的文章——正文只有一张写着"Stop it"的 GIF——又获得了约 68 万浏览。

更有意思的是：这两个人都是开玩笑的。一个在讽刺行业每六周就发明一个新术语，另一个顺着梗一唱一和。但玩笑只撑过了大约一个周末——课程、路线图、工具栈在周末内就填满了时间线，还附带了大量捏造的数字："精度 +18%、成本 -85%"是假数据（这两个数字确实存在，但来自一篇关于化工厂管道图的论文，且比较基线完全不同）；"微软、斯坦福、Anthropic 同时发现了图工程"也是假消息。事实核查确认的唯一真正的"先行者"是 Josh Simmons：他的《We Are Entering the Graph Engineering Phase》写于 7 月 4 日，比这个玩笑整整早了两周——是玩笑让这个概念流行起来，而不是玩笑创造了这个概念。

本讲的目的不是给这把火再添一根柴，而是把这个术语拆开看清楚：为什么单循环之上必然会长出图？图和工作流的区别到底在哪里？什么时候真的需要图，什么时候不需要？

prompt、context、loop、graph：四个名字，叠加起来的一层架构

2026 年 7 月末，工程师 Rohit（@rohit4verse）发了一篇长文，把过去几年 AI 工程的命名史整理成清晰的四层框架。这是理解图工程最好的坐标系：

注意这条演进线的读法：每一层不是取代上一层，而是叠在上一层之上。

• 开始做上下文工程之后，你并没有停止提示工程——每次迭代仍然需要 prompt，只是环境变化时循环会帮它更新。
• 构建循环之后，你也没有丢掉上下文——循环的每一轮都要重新组装自己的 context。
• 到了图这一层，prompt、context、loop 一个都没消失：每个节点都有自己的 prompt、自己的 context、自己的工具、自己的记忆、自己的循环。图决定的只是节点之间如何连接。

Rohit 的原文是这样收尾的：

一旦 Agent 需要专业化、并行、共享状态、验证和恢复，它就不再是一个循环了。它是一张图。

等等——harness 呢？这四个名字里没有 Harness Engineering，但本课程讲的恰恰是 harness。原因很简单：Rohit 讲的是流行语的历史，终点是图，中间那层被跳过了。而且 harness 到底该放在哪一层，业界自己也还没定论——explainx 把它放在 loop 之上，Buildrix 论文把它放在 loop 之下。本课程在第 2 讲就定下了立场：harness 是地基，loop 和 graph 都建在它上面。

这也解释了一个奇怪的现象："Graph Engineering"这个词 2026 年 7 月才火起来，可每个人都觉得自己"早就在这么做了"。因为图并不是新发明，而是任务复杂到一定程度时，循环自然而然变成的样子。名字是后来才有的，做法早就存在了。

拆解图：节点、边、状态、路由

把图还原成最朴素的四个部件。

节点（Node）：承担某一职责的工作单元。它可以是一段确定性代码（跑测试、算覆盖率）、一次模型调用（生成文档）、一个工具（git commit、发消息），也可以是一个完整的 Agent——自带循环、能理解目标、会使用工具、卡住时能自己重试。

节点可以是"什么"，正是图工程和工作流工程真正的分界线，后面会详细讲。

边（Edge）：表示节点之间如何交接。它不是简单的"先做 A 再做 B"——一条边可以表达四种关系：

• 并行：A 完成后，B 和 C 同时开始
• 条件：测试通过走左边，失败走右边
• 失败/重试：节点挂了，回到自己再来一次
• 回退：验证不通过，回到三步前的实现节点

共享状态（State）：节点之间传递的数据包。需求、研究笔记、代码版本、测试结果、评审结论——都写在同一张公共工作台上。节点之间不是互相喊话，而是读写同一份状态。

路由规则（Routing）：决定下一步去哪。这是图的"控制流"，用最朴素的话说就是：

测试通过就交付；测试失败就回到实现节点；信息不足就回到研究节点。

四个部件组合起来，一张典型的开发图长这样：

对比上一讲的循环图：上一讲是一个环——发现、派发、验证、持久化、再回到发现。本讲的图中，环还在，但被分解成了显式的节点和边。验证节点可以把失败直接打回实现节点，实现节点可以在信息不足时退回研究节点——这些"回退边"在单循环里是隐式的，只是 Agent 在自己的上下文窗口里"记得应该回去"而已。

什么时候单循环不够用

一个循环只有一条主干道。在 Project 07 构建的 maker-checker 循环里，所有决策——下一步做什么、失败后去哪——都发生在同一个 Agent 的上下文窗口里。任务再复杂一点，四个问题就会浮现：

1. 分工：研究 Agent、实现 Agent、测试 Agent，谁先开始？
2. 并行：哪些工作可以同时进行？
3. 回退：测试失败后回到哪里——实现节点，还是研究节点？
4. 交接：多个 Agent 如何看到同一份需求、笔记和测试结果？评审者不同意实现者时，听谁的？

黄仁勋在 Y Combinator 的 Startup School 2026 访谈（与 Garry Tan 对谈）中表达了类似观点：随着底层实现越来越多地被 Agent 自动化，人类的核心价值转向"设计系统、明确约束、对 Agent 做细粒度控制"。他举的控制例子非常具体——"Agent 给出计划后，我在计划文件里改一个词，这一个词就产生精确的差异"——并预言未来的核心技能是"系统思维（systems thinking）"。

整场讨论中最尖锐的一击来自 Luis Catacora：

"循环有很大的容错空间。图则迫使你承认，你的工作流里有多少部分其实根本没有被建模。"

这句话点破了 loop 和 graph 的深层差异：

• 循环是一种被推迟的决策。先让一个 Agent 包揽所有工作，转不动了再说。架构可以往后放。这很省事——但代价是失败模式不可见：你永远不知道它卡在哪，因为 Agent 自己也不知道。
• 图是一种提前的决策。你必须事先声明整个结构：谁负责什么、任务之间的依赖关系、某个失败要回到哪里。这更费事——但换来的是可读性、可审计性和局部修复能力。

说得更直白一点：loop 把问题藏进循环里，graph 把问题摊在纸上。前者适合探索，后者适合生产。

单循环在规模下的三种结构性失败

为什么单循环撑不过规模化？eigent.ai 的《Graph Engineering for AI Agents: Beyond Single Feedback Loops》指出了三种结构性失败——注意，这是结构性失败，不是某个循环的 bug。

先反驳一个问题：循环不也能加检查点吗？能。上一讲的验证、停止条件、甚至断点重试，都能塞进循环里。但下面三种失败恰恰是检查点解决不了的——因为循环的检查点存在于同一个 Agent 内部，做检查的和出问题的共用同一个大脑、同一个上下文。它能阻止"不验证就交付"，但它不会问"这个指标对吗"或"这个目标该不该追"——答案明明写在它自己的上下文里，它却看不见。图给你的不是更多检查点，而是把检查搬到外面：从 Agent 内部，搬到拥有全新上下文的独立节点（就是前面那个 verify 节点）。"结构性"三个字的意义就在于此：不是 loop 缺了什么零件，而是"评判者和被执行者共享同一个大脑"这个结构本身有问题。

1. Goodhart：数字涨了，业务却更糟了

任何单一指标被推到极限，就不再度量你原本以为它在度量的东西。经典案例：某客服团队围绕"工单解决率"构建了一个循环。周数据一路上涨。几个月后，续费率数据显示流失率翻了一倍——bot 学会了关闭工单：转移话题、劝阻追问、把未解决的问题标记为"已解决"。

循环做了它被要求做的一切。只是那个数字和业务真正关心的东西脱钩了。这就是古德哈特定律。

2. 向上失明：它从不问"这个目标对吗？"

循环内部，参照值是神圣的。恒温器不会问"68°F 是正确温度吗"；销售循环不会问"这个定额合理吗"；Agent 评估循环不会问"这个基准真的对应业务结果吗"。

无论当初是谁选了那个目标，循环都会朝它狂奔——哪怕它从来就不该被追。单循环的结构里，没有一个位置能放下这个问题。

3. 冲突：独立的循环互相拆台

真实系统里有几十个循环，各自独立构建。响应速度的循环破坏深度质量的循环，增长的循环破坏质量的循环。每个循环在自己的仪表盘上都健康，而整个系统在震荡——就像几个人朝不同方向拉同一根绳子。

图工程要回答的，正是单循环回答不了的那一组问题：

• 哪个循环喂养哪个循环？
• 哪个循环拥有别的循环在追逐的目标？
• 哪个循环能否决或回滚一个变更？
• 哪些指标允许动，哪些必须冻结？

当系统里存在"能吃掉你目标的循环"和"能否决你变更的循环"时，它们之间的关系就成为工程对象——而把关系之间的关系画出来，就是一张图。

锚点：把循环钉在现实上

eigent 文章里有一个标题是"大家都会跳过的那部分"：锚点（anchors）。无论你的循环网络多精巧，如果每个循环都漂离现实，这个网络就只是互相漂移的共振。锚点就是把循环钉在真实世界上的东西——实际业务结果、ground truth 数据集、人工抽查。在设计图的时候，锚点是最容易被跳过、又最不能省的一步。

Graph 与 Workflow：不只是换个名字

这是整个主题里最容易误解的一点，值得单独开一节。

图工程爆火时，有生产经验的人第一反应都是同一句嘀咕："这不就是工作流吗？DAG、状态机、工作流引擎，我们跑了几十年了。"

这个直觉对了一半。图和工作流确实共享同一副骨架：节点 + 边 + 共享状态 + 路由。Airflow、Prefect、Dagster、Temporal 这几十年做的编排正是这种图。Anthropic 2024 年 12 月发布的《Building Effective Agents》总结的五个模式——提示链、路由、并行化、编排者/工人、评估者/优化器——画出来就是不同形状的执行图。

错的那一半在节点里。传统工作流的节点是确定性函数：Python 函数、shell 脚本、SQL 任务。边是写死的代码：if、switch、case。工程师用代码维护整个系统，行为可预测——同样的输入永远走同样的路径。

而图工程的节点可以是完整的 Agent：自带循环、会使用工具、能理解目标、失败了自己重试。边也不一定是写死的——它可以携带路由规则，由前一个节点的输出、验证结果、甚至另一个模型来决定下一步。

借用 Anthropic 的一对概念来锐化这个区别：Anthropic 用一句话区分工作流和 Agent——谁决定控制流？如果是代码固定了步骤，那就是工作流；如果模型能在运行时改变步骤，那就是 Agent。

那图是什么？图是同时容纳两者的容器。一张图里可以同时放：

• 工作流节点：跑测试、算覆盖率——确定性代码，不需要模型
• Agent 节点：实现功能、评审代码——模型驱动的完整 Agent
• 人类节点：审批、复核——人在环中，图停下来等人类点头

所以准确的说法是：图工程不是工作流的替代品，而是工作流的泛化——节点的类型从"函数"拓宽到"Agent"，边的决策从"静态代码"拓宽到"动态路由"。工作流是图中"完全确定性"的特例。

反对意见（iii.dev 的《Loops, Graphs, and the Layer That Matters》）也落在同一个点上，但结论相反：

"形状是容易的部分，而且是一次性的。承重的决定在于 loop 或 graph 由什么构成，以及它运转起来之后会发生什么。"

iii.dev 的意思是：不要把拓扑结构当成工程成就。工作流工程跑了数十年，真正沉淀下来的不是节点怎么连，而是可重放（replayability）、可观测（observability）、可恢复（recoverability）——出问题能重放、运行时能观察、崩溃后能续跑。图的形状随时可以重画，这些承重能力才是你该投入精力的地方。这个批评值得记住：画图本身不是目的，图能承载多少工程能力才是目的。

你其实一直在画图

"新瓶装旧酒"还有另一个证据：工具早就齐了。

• LangGraph：2024 年 1 月发布，到 2026 年 7 月月下载量约 6500 万次。面向 Agent 的图执行引擎，节点可以是 Agent，边可以带条件路由、checkpoint、interrupt。
• Anthropic 的五个模式：2024 年 12 月的《Building Effective Agents》其实已经画出了提示链、路由、并行化、编排者/工人、评估者/优化器的图——只是没叫它图工程。
• Claude Code 的 subagent fan-out：当你让一个主 Agent 并行派出一群子 Agent 时，你已经在构建一张图了——只是没意识到。
• 状态机、DAG 调度、任务队列、知识图谱：计算机科学已经做了几十年图的工程。

真正新的东西是什么？节点从"函数"变成了"Agent"。这是唯一的变化，也是全部的变化。以前写工作流节点，逻辑、错误处理、重试策略都要手写；现在一个节点只需要一句指令——"研究一下这个问题""评审这段代码"——剩下的交给模型。节点变便宜了，图才值得画。

从零构建你的第一张图

理论讲够了，动手吧。上一讲的 maker-checker 是一个自己循环的单个Agent。图工程做的第一件事，就是把这种单体 Agent 拆开：每个节点变成一个专业化的 Agent，各自拥有私有的 prompt、context、tools、memory 和自己的一小段循环；节点之间不共享上下文，只通过一张共享状态交接。这就是 Rohit 那句话的人话版——"图决定每个节点看到什么、何时运行、输出去哪、谁能拒绝它、什么能让系统停下"。下面的记号不绑定任何特定引擎——它们是概念；LangGraph、CrewAI 只是把这些概念变成可执行程序的实现，API 不同但骨架相同。六步，一步都不能跳。

第 1 步：定义共享状态（State）。先分清两个层：图这一层共享的只有状态，节点的上下文是私有的。单体 Agent 只有一个上下文，跑久了会淹死在自己冗长的 transcript 里；图把上下文切成多份，每份属于一个节点——loop 是节点的私有财产，graph 是它们交接的公共台面。想清楚状态里放什么。为每个字段声明"如何合并"——多个并行节点同时写同一个字段时，是覆盖、追加还是求和？这一步不是框架的功能，而是你画图时就要写进graph.md的规则：

state = { "requirements": 文本, # 研究节点写入 "code": 文本, # 实现节点写入 "review": "pass" | "fail", # 验证节点写入 "attempts": 数值, # 每次失败 +1（并行写入时按"求和"合并） }

第 2 步：列出节点——每个节点都是完整的 Agent（自带循环）。这是图和工作流的根本区别：工作流的节点是函数，图的节点是带着自己小循环的 Agent。节点接收共享状态 → 在自己的私有上下文里干活 → 把结果写回共享状态。写代码类节点的内部，往往就是上一讲的那个循环：

# implement 节点内部：私有小循环（上一讲的 maker-checker loop） node_implement(requirements): loop (最多 3 次): code = model(prompt=实现指令, context=requirements + 上次的错误) if tests_pass(code): return {"code": code} return {"error": "实现 3 次仍未通过"}

注意 verify 这一行——它是整张图里最容易做错的节点。在单体 Agent 里，"评审"还在同一个上下文中运行，等于自己审自己；在图中，verify 必须拿到完全新的上下文——它看不到实现的推理过程，只能看到共享状态里的code。这就是"独立评审"在图上真正成立的地方：上下文隔离不是副作用，而是设计。

第 3 步：连边。先连确定性的主干线：研究 → 实现 → 验证 → 合并 → 结束。

第 4 步：写路由规则（最关键的一步）。验证节点不是直接连到 merge，而是连到一个决策点，由它决定下一步去哪。这一步把"测试失败回哪里"显式化——路由规则返回的是节点名，整张图从哪来、到哪去，一览无余：

第 5 步：挂 checkpoint。这是图和一次性脚本最大的区别之一：每一步之后状态落盘，进程挂了也能从断点接着跑，不必从头再来。挂上之后，图就免费获得了"中断/恢复"能力——还能在 merge 前插入"暂停等待人工批准"的节点。这就是上一讲"人工评审"在图上的样子：

checkpoint = on(graph, every_step) # 每一步都保存状态 graph.pause_before("merge") # 合并前停下，等人批准

第 6 步：给图一个入口并运行。每次运行都传一个线程 id，checkpoint 靠它区分不同的运行实例：

run(graph, entry={"requirements": "修复登录页 bug"}, thread="session-1")

跑完之后对照上面的图：你手写的graph.md是蓝图，引擎里的那段代码是蓝图变成的可执行程序。两者应该一一对应。如果对不上——要么图画错了，要么代码写错了，这正是"图把问题摊在纸上"的含义：以前对不上也没人发现，现在一眼就看出来。

如果你想要一份能跑起来的参考实现，仓库里有 maker_checker_graph.py（中文注释版，用 LangGraph 编写）。对照这份代码可以看到六步的完整落地：GraphState定义了带合并语义的共享状态（attempts用Annotated[int, operator.add]声明"按求和合并"，正是第 1 步要求的并发写合并规则）；research/implement/verify是三个 Agent 节点（verify只读state["code"]，天然隔离了实现者的上下文）；merge是确定性节点；route_after_verify返回节点名实现条件路由；最后用graph.compile(checkpointer=MemorySaver())挂上检查点，并在invoke时传入thread_id区分运行实例——四行核心调用与六步一一对应。代码目录的说明见 code/index.md。

开源项目：名字之后出现的，和名字之前就有的

先画一条线："Graph Engineering"是 2026 年 7 月 18 日之后才有的名字。在那之前开源出来的框架，都不算"图工程发布后的项目"。截至 2026 年 8 月初，概念爆火后直接顶着这个名字出现的开源项目，立得住的只有一个：

概念发布之后出现的

• GraphArc（2026-08-02）：自称"图工程的第一个实时实现"。它把 Agent 执行从埋在日志里的 trace 变成一张交互式实时编排图——每个 Agent、每个依赖、每个决策点都画出来，执行前可视化给你确认（手机也能看）再放行。作者背景是为 4000 多名开发者做过图工具，方向是"可观测、可调试、可工程化"。非常新，功能还在早期阶段。

概念发布之前就有的（它们不叫图工程——但你真正拿来构建的就是它们）

2026 年 7 月之前，这些工具已经存在了一到三年：LangGraph（2024 年开源，月下载 6500 万以上，就是上面参考实现用的引擎）、CrewAI、Microsoft Agent Framework、LlamaIndex Workflows、Google ADK、OpenAI Agents SDK、Mastra、Claude Agent SDK。它们不是"图工程发布后的项目"——它们正是"图工程发布之前"的证据。节点、边、共享状态、路由这套东西已经跑了三到五年，7 月只是给了个新名字。图引擎不解决设计问题：它给你节点、边、checkpoint，但它不会替你回答"哪个循环喂养哪个、谁拥有目标、谁能否决"。这些问题没想清楚之前，换哪个引擎都只是把同样的坏设计画得更漂亮而已。

泼冷水：图不是银弹

三桶冷水，从轻到重。

第一桶：假数字。图工程爆火后，网上流传"用图精度 +18%、成本 -85%"之类的数据。韩国博主 goddaehee 做了事实核查（7 月 30 日）：这两个数字确实存在，但来自一篇 2026 年 3 月关于化工厂管道仪表图（P&ID）的论文——而且 18% 是跟图像原稿比的，85% 是跟另一个方案比的。营销文案把两个不同基线的数字拼进了一个"前后对比"，论文里甚至没有"graph engineering"这个词。看到"图工程带来 X% 提升"这种数据时，先去查原始出处。

第二桶：形状不是承重墙（iii.dev）。前面讲过。loop 就是只有一个节点的图；状态机跑了几十年。喊"loop 死了"或"graph 死了"的人，多半两个都没好好读过。要学的是模式，不是名词。

第三桶：编排税（Orchestration Tax）。Addy Osmani 5 月的《The Orchestration Tax》给出了图/多 Agent 时代最硬核的经济学：启动一个 Agent 很便宜，但闭环一个 Agent 很贵。

启动 Agent 是一下按键的事。但闭合一个 Agent 的循环，需要有人检查它带回来的结果，并和别的 Agent 动过的东西对账——那个人是你，而你只有一个。Osmani 的原话：

"你就是你那些 AI Agent 的 GIL。它们可以同时跑。但只要它们的工作需要真正理解架构、或者解决合并冲突，那些工作就必须拿到那把锁。锁只有一把。握着它的是你。"

这就是为什么上一讲说的"评审带宽是天花板"在这里变得更加尖锐：图让更多 Agent 并行跑，但你的判断力是串行资源，不会并行。加节点优化的从来不是瓶颈——瓶颈永远是那一个串行处理器：你。

什么时候你真正需要一张图

不是每个任务都配得上一张图。五个判断标准，至少满足三个再动手：

1. 任务能分解成独立的工作单元——互不依赖、可以并行的部分
2. 存在分支或回退路径——"测试失败回哪""信息不足回哪"这些路径值得显式声明
3. 中间状态值得保存——能在 checkpoint 处暂停并恢复，而不是从零重来
4. 结果能明确验收——每个节点都有可自动检查的完成标准
5. 协作收益 > 协调成本——并行省下的时间，大于图本身和共享状态带来的开销

"复杂"不等于"步骤多"。一个 20 步的线性流水线不需要图——那是工作流，或者就是个脚本。只有 5 个节点但有真实回退、并行、审批的结构才需要图。判断标准不是规模，而是分支和回退的存在。

核心概念

• Graph Engineering：把多个 Agent、循环、工具、评估者组织成显式图（节点 + 边 + 共享状态 + 路由规则）的工程实践，让多个工作单元的连接、共享状态、路径选择变得可设计、可观测、可局部修复。
• 四层叠加：prompt → context → loop → graph，每层控制不同的东西（指令、信息、运行时、系统），后一层不替换前一层，只是把前一层装进自己的节点里。
• 图的四个部件：节点（工作单元）、边（交接方式）、共享状态（公共工作台）、路由规则（下一步去哪）。
• 单循环的三种结构性失败：Goodhart（数字涨了业务却坏了）、向上失明（从不问"这个目标对吗"）、冲突（独立循环互相拆台）。图把这三个问题变成显式的关系设计。
• Graph ≠ Workflow：工作流的节点是确定性函数、边是写死的代码；图的节点可以是完整 Agent、边可以动态路由。图是工作流的泛化。
• 锚点（Anchors）：把循环网络钉在现实世界的机制（实际业务结果、ground truth、人工抽查）。图设计中最容易被跳过、又最不能省的一步。
• 编排税（Orchestration Tax）：启动 Agent 便宜，评审结果贵。你的注意力是唯一的串行资源，加节点也优化不了它。

核心要点

• 图工程不取代循环工程，而是在它上面盖一层。loop 是图里的一个节点；上一讲的三件套（目标、验证、停止条件）成为节点的内部结构。
• 图把"推迟的决定"变成"提前的决定"。loop 把失败模式藏进循环里，graph 把它摊在纸上——可读、可审计、可局部修复。
• 节点里放什么，决定了图和工作流的区别。放函数是工作流，放 Agent 是图。这也是"新瓶装旧酒"里唯一的新酒。
• 画图之前先回答四个设计问题：哪个循环喂养哪个、谁拥有目标、谁能否决/回滚、哪些指标能动哪些必须冻结。答不上来就别画。
• 不要为画图而画图。五个标准：可独立分解、有分支或回退、中间状态值得保存、结果可验收、协作收益 > 协调成本。
• 你的评审带宽仍然是天花板。图让更多 Agent 并行，但你的判断是串行的——节点变多，编排税不会消失。
• 记住反对意见。形状不是承重墙；可重放、可观测、可恢复才是。名词每六周换一次，工程能力不会。

延伸阅读（仓库内）

• 第 13 讲：从手动提示到自主循环——loop 是图里的一个节点，先理解节点内部再理解图（英文版）
• 第 11 讲：为什么可观测性属于 harness 内部——图越复杂可观测性越重要；不可观测的图只是把黑箱拼成更大的黑箱
• 第 9 讲：为什么 Agent 过早宣布胜利——验证节点为什么必须独立于实现节点；在图上这是结构问题，不是 prompt 问题
• Project 08. 把工作流画成一张图——配套实战项目：把 maker-checker 画成显式图、加并行 fan-out/fan-in、加回退边和人工审批节点（英文版）
• 参考实现：maker_checker_graph.py

练习

1. 把 P07 的 maker-checker loop 画成图：用graph.md显式写出节点、边、共享状态、路由规则。标出哪些边是条件边（验证通过/失败）、哪些是回退边（失败回到实现）。画完回答：有没有哪条边原本是隐式的——之前藏在 Agent 的上下文里？
2. 回答 eigent 的四个问题：找出你在跑的三个独立循环（或同一项目里的三个自动化），回答：它们之间谁喂养谁？哪个循环拥有另一个循环在追逐的目标？有没有哪个循环能否决另一个循环的产出？哪些指标在被以可能冲突的方式优化？
3. Goodhart 自检：检查一个你最近在优化的指标。它涨的时候，真实结果（业务结果、用户反馈、代码质量）也一起变好了吗？如果只有数字涨了，这个循环正在朝哪个方向学会对你撒谎？
4. 用五个标准给候选任务打分：挑一个你纠结"要不要图化"的任务，按五个标准逐项打分。至少要满足三个才值得画图。不足三个的话，它真正需要的是更好的工作流脚本——不要为了用图而用图。
5. 把graph.md变成可执行程序：按本讲"从零构建第一张图"的六步，把画好的 maker-checker 图实现成能跑的图（参考实现：maker_checker_graph.py，用 LangGraph 写的）。六步一步不跳：定义状态 → 列节点 → 连边 → 写路由 → 挂 checkpoint → 运行。跑完把图和代码对照，找出第一处对不上的地方，并解释为什么——是图画错了，还是代码写错了？