Loop & Graph Engineering 浅析

📅 2026-08-15⏱ 19 min read📝 3635 words

最近整理 Claude Code 的新能力时，我反复遇到两个词：Loop Engineering 和 Graph Engineering。

第一次看到它们，很容易把它们归入新一轮 Agent 黑话。Prompt Engineering 还没讲完，Context Engineering 刚刚流行，又来了 Loop、Graph、Harness、Eval——仿佛只要不断给 Engineering 前面换一个名词，就能证明 AI 又进入了一个新时代。

但把术语拆开后，我意识到它们描述的并不是新魔法，而是两个非常传统的工程问题：

一个系统做错以后，怎样利用反馈逐步改对？
一个复杂任务被拆开以后，多个执行单元怎样按照依赖关系协作？

前者是 Loop，后者是 Graph。

我曾在《从 Vibe Coding 到 BMAD》里写过：AI 编程工具正在趋同，真正拉开差距的是方法论。当 Claude Code 已经能够读写代码、调用工具、管理记忆、启动子 Agent，新的瓶颈确实不再是“怎样让模型写一段代码”，而是：

怎样让错误在闭环中被淘汰，让正确的工作在图中被组织。

从 Prompt 到 Context，再到 Loop 与 Graph

这四个概念解决的是四个不同层次的问题。

方法	关注的问题	典型产物
Prompt Engineering	这一轮怎样问，模型才容易答对？	提示词、示例、输出格式
Context Engineering	Agent 开始工作前，已经知道什么？	`CLAUDE.md`、Memory、检索结果、工具说明
Loop Engineering	第一次没做对，怎样根据反馈逐步收敛？	评价器、重试策略、退出条件、人工闸门
Graph Engineering	多个任务怎样拆分、并行、等待和汇合？	节点、依赖边、分支、屏障、工作流

Prompt 优化一次生成，Context 优化一次决策的输入，Loop 优化多轮行为的收敛，Graph 优化多个行为之间的组织。

它们不是互相替代的关系。没有 Prompt，节点不知道要做什么；没有 Context，节点每次都从失忆开始；没有 Loop，错误得不到纠正；没有 Graph，复杂任务只能串行堆在一个对话里。

如果把 AI Agent 看成一个新员工：Prompt 是当前任务说明，Context 是入职手册和项目资料，Loop 是绩效反馈与返工机制，Graph 则是整个团队的组织结构。

Loop Engineering：不是简单地“再跑一次”

一个真正的闭环至少包含五个部分：状态、行动、观察、评价和决策。

State → Action → Observation → Evaluation → Decision
  ↑                                         │
  └──────────── revise / retry ─────────────┘
                              │
                              └── pass / stop

以修复一个 API Bug 为例：

State：当前代码、失败测试、已尝试过的方案
Action：修改实现、增加日志、运行命令
Observation：测试输出、HTTP 响应、浏览器行为
Evaluation：是否满足验收条件，是否引入回归
Decision：通过、继续修正、换一种策略，或者停止并请求人工输入

这里最容易被忽略的是最后两个环节。

很多所谓“自动修复循环”只有行动和观察：Agent 改一次，测试失败；再改一次，测试仍然失败；然后继续修改。它确实在循环，却没有收敛。因为系统没有定义什么证据足以改变判断，也没有定义何时应该停止。

重复不是闭环。带有评价器和退出条件的重复，才是闭环。

一个最小但完整的编码闭环

在 Claude Code 中，不需要先搭建框架。一个写清楚边界的任务提示就能形成最小闭环：

Implement this change with a bounded verification loop:

1. Make the smallest viable change.
2. Run the most targeted relevant test.
3. If it fails, classify the root cause before editing again.
4. After targeted tests pass, run lint and the broader test suite.
5. Ask an independent verifier to try to break the implementation.
6. Repeat for at most five implementation rounds.
7. Stop early if the same failure appears twice without new evidence.
8. Do not claim completion unless the verification evidence passes.
9. If blocked, report the exact command and output.

这段提示词真正重要的不是“最多五轮”，而是把不同失败转换成了不同决策：

测试失败，不是立即重写，而是先分类原因；
同一失败重复出现，说明当前策略没有产生新信息；
实现者的测试通过，还要接受独立验证；
没有证据时，不能用“看起来没问题”代替完成。

它把 Agent 从一个连续生成器，变成了一个有停止条件的控制系统。

`/loop` 是 Loop Engineering 吗？

不是。至少不完全是。

Claude Code 的 /loop 是时间调度工具。它可以每隔五分钟检查 CI，也可以让 Claude 根据部署状态动态决定下次检查时间：

/loop 5m check whether CI passed
/loop monitor the deployment and stop once it is healthy
/loop 20m /review-pr 1234

这解决的是“什么时候再次执行”，而 Loop Engineering 还必须回答“根据什么反馈改变下一步”。

如果每五分钟执行同一句提示、读取同一份状态、做出同一种错误判断，那只是定时重播。只有当每轮结果进入状态、评价器改变决策、结束条件能够终止任务时，它才成为完整的工程闭环。

因此，更准确的关系是：

/loop 提供时钟，测试和工具提供观察，Evaluator 提供判断，状态与停止条件共同构成 Loop Engineering。

Claude Code 中还有几块同样重要的积木：

Hooks：在工具调用、任务完成、Worktree 创建、上下文压缩等节点确定性地执行检查；
Skills：把“实现—测试—诊断—再验证”的流程固化为可复用方法；
Subagents：把独立验证放进干净的上下文，避免实现者自己证明自己；
Task List：保存任务状态、依赖和完成条件；
Worktrees：隔离并行修改，为失败方案保留可回滚边界；
Agent SDK：在生产环境中设置最大轮数、费用预算、中断和结构化结果。

其中，Hooks 很像闭环里的传感器和保险丝。它不依赖模型“记得”运行格式化或安全检查，而是在特定事件发生时必定执行。对于任何关键验证，确定性 Hook 都比一句“记得检查”更可靠。

Graph Engineering：复杂任务不是清单，而是图

当一个任务无法由单个循环完成，就进入 Graph Engineering 的范围。

Graph 的节点可以是 Agent、工具调用、测试、人工审批或部署任务；边则表达依赖、数据传递、条件分支和失败回退。

例如，一次多维代码审查不是四个 reviewer 的简单清单，而是一张有分叉与汇合的图：

Correctness、Security、Performance、Tests 四路并行；
每一路输出 findings；
findings 进入独立的对抗验证；
被证伪的问题淘汰；
剩余问题统一排序、去重和综合。

这里有两个关键词：

Fan-out：把独立工作散开

不同维度、不同文件、不同候选方案之间没有依赖，就应该并行。串行执行不仅慢，还会让后一个 Agent 被前一个 Agent 的判断锚定。

Fan-in：在真正需要全局信息时汇合

去重、统一排序、跨模块一致性检查，需要看到所有上游结果，才值得设置 barrier。过早汇合会浪费并行度；没有汇合又会让重复和冲突一直传到最终答案。

Graph Engineering 的关键不是多开几个 Agent，而是设计信息什么时候分开、什么时候重新相遇。

Claude Code 里的三种执行图

Claude Code 已经提供了三种不同强度的图结构。

1. Task Dependencies：适合小型显式 DAG

Task 可以声明 blockedBy 和 blocks。例如数据库 Schema 完成后，后端和前端并行；二者都完成后，端到端测试才能开始。

这种图最适合十几个以内、依赖关系清楚、需要人类随时查看状态的任务。它的优势不是自动化程度最高，而是可解释：哪个节点被谁阻塞，一眼就能看见。

2. Dynamic Workflows：适合大规模确定性编排

Claude Code 的 Dynamic Workflows 用 JavaScript 描述编排逻辑，支持 agent()、pipeline()、parallel()、阶段、结构化输出、预算和恢复。它从 v2.1.154 起提供，是当前最接近原生 Graph Engineering 的能力。

下面是一张“审查—反驳—综合”工作图的简化骨架：

export const meta = {
  name: "review-and-refute",
  description: "Review changes from independent lenses and verify each result",
  phases: [
    { title: "Review", detail: "Find issues independently" },
    { title: "Verify", detail: "Try to refute each review" },
    { title: "Synthesize", detail: "Merge verified findings" },
  ],
}

const dimensions = [
  { key: "correctness", prompt: "Review the current diff for correctness bugs." },
  { key: "security", prompt: "Review the current diff for security issues." },
  { key: "performance", prompt: "Review the current diff for performance regressions." },
  { key: "tests", prompt: "Review the current diff for missing test coverage." },
]

const verified = await pipeline(
  dimensions,
  dimension => agent(dimension.prompt, {
    label: `review:${dimension.key}`,
    phase: "Review",
  }),
  (review, dimension) => agent(
    `Try to refute this ${dimension.key} review with concrete code evidence:\n${review}`,
    {
      label: `verify:${dimension.key}`,
      phase: "Verify",
    },
  ),
)

return agent(
  `Deduplicate, rank, and synthesize only the findings that survived verification:\n${JSON.stringify(verified)}`,
  { label: "synthesize", phase: "Synthesize" },
)

这里使用 pipeline() 而不是在每一阶段都设置全局 parallel() barrier。某个 reviewer 完成后，它可以立刻进入验证，不必等待最慢的 reviewer。只有最终综合需要完整结果，因此 fan-in 放在最后。

生产工作流还应该为 Agent 输出增加 JSON Schema，避免靠自然语言解析 findings；修改文件的并行节点则应使用独立 Worktree，避免多个 Agent 同时写入同一工作副本。

3. Agent Teams：适合需要讨论的通信图

Agent Teams 让多个完整 Claude Code 会话共享任务并直接互发消息。它适合竞争性假设、架构辩论、跨模块协作这类“节点之间必须持续交流”的任务。

但 Agent Teams 目前仍是实验性功能，需要显式开启 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1，而且每个成员都是完整 Claude 实例，token 成本明显高于 Subagents。

因此推荐非常明确：

只需要结果返回主线程：用 Subagent；
需要几十个节点按脚本执行：用 Dynamic Workflow；
节点必须持续互相讨论和协调：才用 Agent Teams。

不要因为“三个 Agent 看起来更高级”，就把一个 Grep 能解决的问题变成团队会议。

Loop 与 Graph 不是两套系统

一张成熟的执行图，节点内部往往是 Loop；一条成熟的 Loop，也可能在某轮动态展开新的 Graph。

例如一次大型迁移：

Graph 按文件或模块 fan-out；
每个节点内部执行“修改—测试—修正”的 bounded loop；
节点通过后进入集成测试；
集成失败时，根据错误类型只回退相关节点；
最终由独立 reviewer 做全局验证。

因此，真正的 Agent 系统更像一张“带环的图”，而不是纯 DAG。DAG 适合表达明确依赖，Loop 适合表达反馈控制，二者共同组成运行时拓扑。

这也解释了为什么 Graph Engineering 不等于 LangGraph，Loop Engineering 也不等于某个 /loop 命令。框架只是表达方式，核心问题仍然是：

状态存在哪里？
观察是否可信？
哪个节点有权改变状态？
失败应该重试、回退，还是升级给人？
怎样证明整个图已经完成，而不是所有节点都“自称完成”？

五个最常见的失败模式

1. 无限循环：把坚持误当成智能

没有最大轮数、预算和熔断条件的 Agent，可能只是更昂贵地重复同一个错误。每个 Loop 都应同时具备质量上限和资源上限。

2. 自证循环：实现者也是唯一评价者

同一个 Agent 写代码、写测试、解释测试并宣布成功，容易共享同一盲点。高价值变更应由独立上下文中的 verifier 尝试反驳。

3. 共识幻觉：多个 Agent 共享同一锚点

如果后续 Agent 先读到第一个结论，它们很可能只是换一种措辞表示赞同。需要独立判断时，应先并行生成，再汇合比较。

4. Barrier 泛滥：每一步都等待全员

Graph 不是把每个阶段排成整齐队列。只要下一阶段不需要全部上游结果，就应让快节点继续前进。否则多 Agent 只增加成本，不增加吞吐。

5. 完成条件写成一句感觉

“代码质量良好”“报告足够全面”“界面看起来不错”都无法稳定评价。退出条件应该可观察：测试命令通过、响应 Schema 正确、指定文件存在、关键路径完成、独立验证无阻断项。

一条足够实用的升级路线

不需要一开始就搭建复杂多 Agent 系统。最稳妥的顺序是：

先给单 Agent 加一个 bounded loop：实现、测试、诊断、重试、停止；
把独立调查交给 Subagents：减少主上下文污染，也降低相互锚定；
用 Task Dependencies 表达小型依赖图：先让阻塞关系可见；
独立节点超过五个，或者需要重复运行时，升级为 Dynamic Workflow；
只有节点之间必须持续讨论时，才启用 Agent Teams；
跨天运行、关键业务、严格 SLA 和持久状态，交给 Agent SDK、Managed Agents 或 Temporal 一类外部编排器。

这条路线的原则是：先增加反馈，再增加并行；先证明一个节点能可靠收敛，再复制更多节点。

一个不会验证自己的 Agent，复制十份不会变成团队，只会变成十个同时犯错的人。

结语：从生成答案，到设计收敛

Prompt Engineering 教会我们怎样开口，Context Engineering 教会 Agent 在行动前先理解世界。Loop Engineering 再往前一步：第一次答案不重要，重要的是系统能否利用真实反馈，持续淘汰错误。Graph Engineering 则让这种能力跨越一个 Agent，扩展到一组有依赖、有分工、也有汇合点的执行单元。

这也是 AI 编程正在发生的变化。

过去，我们盯着模型第一次写出了什么；现在，更值得设计的是它写完以后会检查什么、失败以后会改变什么、何时应该停下，以及不同 Agent 的判断会在哪里相遇。

代码不是一次生成出来的。它是在回环中被修正，在图中被组织，最后从一批可能答案里被筛出来的。