第 4 章：当一个 Loop 不够用——进入 Graph Engineering

本章解锁：你能识别单 Agent Loop 力不从心的信号，理解 Graph 的三要素（节点、边、共享状态），并区分 Loop、Graph、Harness 各自的定位。
预计时间：20 分钟

起点与环境

前置章节：第 3 章（设计你的第一个 Agent Loop）

你已经能设计包含四步骨架、停止条件和 Maker-Checker 模式的 Agent Loop 了。在你的代码审查 Loop 中，explorer、reviewer、verifier 三个 sub-agent 在一个 loop 内部协同工作，由主 agent 统一调度。

但这里有一个重要的限制：这三个 sub-agent 不是独立的 agent，它们是主 agent 的"手臂"。它们没有自己的循环，没有自己的记忆，没有自己的判断权——一切由主 agent 说了算。

当场景进一步复杂，这种"中心化调度"模式会遇到墙。

为什么现在做

想象这样一个场景：你的团队要做一次技术方案评审。

架构师 Agent 需要评估方案的系统设计是否合理
安全专家 Agent 需要检查是否有安全隐患
性能专家 Agent 需要评估是否有性能瓶颈
产品经理 Agent 需要判断方案是否满足产品需求

这四个 Agent 各自有独立的知识体系、独立的评审标准、独立的执行逻辑。架构师关心模块划分和接口设计，安全专家关心认证授权和数据流转，性能专家关心热路径和资源占用——它们的"观察-规划-执行-验证"完全不同。

你能把这四个角色塞进一个 Loop 的 sub-agent 里吗？技术上可以。但你会遇到几个问题：

上下文爆炸：主 agent 需要同时理解四个领域的上下文，上下文窗口很快不够用
调度僵化：主 agent 必须决定四个 sub-agent 的执行顺序，但实际上架构评审和安全评审可以并行
结论冲突：架构师说"用微服务"，性能专家说"微服务增加延迟不可接受"——谁来仲裁？sub-agent 模式下只有主 agent 能仲裁，但主 agent 可能不具备仲裁的专业能力
记忆隔离：每个专家的评审经验应该独立积累。安全专家积累的漏洞模式库对性能专家没有意义，反而会干扰

这就是从 Loop 到 Graph 的跃迁点。

动手实践

4.1 识别"需要 Graph"的四个信号

通过上面的场景，我们可以提炼出四个信号。当它们出现时，说明单 Loop 不够用了：

信号	描述	Loop 中的症状
角色独立性	不同角色需要独立的知识体系和决策权	主 agent 的 prompt 变得极长，试图同时扮演多个专家
并行需求	多个任务可以同时进行，不需要串行等待	明显可以并行的步骤被迫排队
结论冲突	不同角色可能产生矛盾的结论，需要仲裁	主 agent 在矛盾面前随机选择，或者总是偏向某一方
记忆分化	不同角色的经验积累应该独立	Memory 文件变成了各种不相关信息的大杂烩

你的实践任务：回顾你在第 3 章设计的代码审查 Loop，判断它是否出现了上述信号。大多数情况下，简单的代码审查 Loop 不会出现这些信号——这恰恰说明它不需要 Graph。

4.2 Peter Steinberger 的那个问题

2026 年 7 月 18 日，PSPDFKit 创始人 Peter Steinberger 在推特上发了一句简短的话：

"Are we still talking loops or did we shift to graphs yet?"
— Peter Steinberger, 290 万浏览量

这句话之所以引爆讨论，是因为它精准地捕捉到了社区的集体困惑：当 Agent 系统变得越来越复杂，Loop 这个抽象够用吗？

Josh Simmons 随后发文回应，把演进阶梯讲得更清楚：

每一层都是更高的抽象，更少的"whispering"，更多的"architecture"。
— Josh Simmons

"Whispering"——低声耳语——是一个精准的比喻。Prompt Engineering 是你对着模型耳语；Loop Engineering 是你设计系统让系统对着模型耳语；Graph Engineering 是你不再关心谁对谁耳语，你设计的是整个对话的拓扑结构。

4.3 Graph 的三要素

Graph Engineering 的核心思想可以用三个要素概括：

要素 1：节点（Nodes）

节点是 Graph 中的执行单元。每个节点可以是：

一个独立的 Agent（有自己的 prompt、工具和记忆）
一个功能模块（非 LLM，如代码编译器、测试运行器）
一个人工确认点（Human-in-the-loop）

关键区别：Graph 中的节点是独立的。它们有自己的执行循环（可能就是一个完整的 Loop）、自己的记忆、自己的专业知识。这和 Loop 中的 sub-agent 根本不同——sub-agent 是主 agent 的延伸，节点是独立的实体。

要素 2：边（Edges）

边定义了节点之间的任务流转逻辑——谁把什么传给谁、什么条件下触发下游节点。

边不只是"连线"。边上传递的内容至关重要。我们在第 5 章会详细展开，这里先建立一个关键认知：

边上需要传递结构化产物，而不是无差别转发全部对话。
— Josh Simmons, Graph Engineering 讨论

一个好的边传递的是：节点的结论、依据和置信度。而不是把节点内部所有的思考过程和中间对话全部转发给下游。

要素 3：共享状态（Shared State）

共享状态是 Graph 中所有节点都可以读写的全局数据。它独立于任何单个节点的聊天记录。

共享状态包含什么：

任务的原始输入（如被评审的方案文档）
各节点已确认的决策
尚未解决的争议
证据链（谁基于什么做了什么判断）

为什么需要独立的共享状态？ 因为节点之间的对话是断裂的。架构师 Agent 和安全专家 Agent 各自有自己的对话历史，它们不能直接看到对方"想了什么"。共享状态是它们的公共白板。

4.3.1 用代码感受 Graph 的结构

三要素讲完了，现在把它们写成代码。先定义共享状态——Graph 中所有节点读写的"公共白板"：

python

# shared_state.py — Graph 共享状态定义
from dataclasses import dataclass, field

@dataclass
class ReviewState:
    """方案评审 Graph 的共享状态，所有节点可读写。"""
    proposal: str = ""                        # 待评审的方案原文
    reports: dict[str, str] = field(default_factory=dict)  # 各节点的评审报告
    conflicts: list[str] = field(default_factory=list)     # 尚未解决的争议
    final_verdict: str = ""                   # 仲裁节点的最终结论

然后用 Python 字典定义 Graph 的拓扑——节点、边、以及它们如何连接到共享状态：

python

# review_graph.py — 最小 Graph 定义
review_graph = {
    "name": "proposal-review",
    "shared_state": "ReviewState",           # 引用上面的共享状态类

    "nodes": {
        "arch_review":  {"agent": "架构评审专家", "writes": "reports.arch"},
        "sec_review":   {"agent": "安全评审专家", "writes": "reports.security"},
        "perf_review":  {"agent": "性能评审专家", "writes": "reports.performance"},
        "arbitrator":   {"agent": "综合仲裁者",   "writes": "final_verdict"},
    },

    "edges": [
        # 三个评审节点可以并行执行
        {"from": "arch_review",  "to": "arbitrator", "artifact": "reports.arch"},
        {"from": "sec_review",   "to": "arbitrator", "artifact": "reports.security"},
        {"from": "perf_review",  "to": "arbitrator", "artifact": "reports.performance"},
    ],
}

对比第 3 章的 Loop 配置：Loop 只有"步骤的顺序"（观察 -> 规划 -> 执行 -> 验证），所有 sub-agent 共用主 agent 的上下文；而 Graph 多了两个关键维度——边上定义了传递什么产物（不是转发全部对话），共享状态独立于任何节点的聊天记录。这正是 Graph 能处理"独立角色 + 结论冲突"场景的结构基础。

4.4 Loop、Graph、Harness 的定位辨析

现在让我们厘清三个容易混淆的概念：

Loop 是时间结构：一个 Agent 如何持续推进任务
Graph 是组织结构：多个 Agent 如何分工、交接、审核和收敛
Harness 是运行系统：怎样让 Loop 和 Graph 在真实环境中可靠运行

用建筑来类比（注意，类比只用于建立直觉，不要过度延伸）：

Harness 是建筑工地的基础设施——脚手架、安全网、供电供水
Loop 是单个工人的工作流程——砌一层砖、检查水平、不平就调整、继续砌
Graph 是整个工程的组织结构——哪些工种先进场、谁的工作完成了才能交给下一个工种、出了分歧谁来协调

三者缺一不可，也不存在"用 Graph 就不需要 Loop"的说法——Graph 中的每个节点，内部可能就是一个完整的 Loop。

4.5 一个关键判断：你的任务需要 Graph 吗？

在进入第 5 章（设计 Graph）之前，先做一个冷静的判断。因为 Graph 也可能是过度设计。

你的实践任务：用下面的决策树判断你手头的某个任务是否需要 Graph。

你的任务需要多个独立角色吗？
├── 否 → 不需要 Graph，一个 Loop 足够
└── 是 → 这些角色需要各自独立的知识体系和记忆吗？
    ├── 否 → 不需要 Graph，在 Loop 中用 sub-agent 即可
    └── 是 → 角色之间需要交接、仲裁或审批流程吗？
        ├── 否 → 不需要 Graph，多个独立 Loop 并行即可
        └── 是 → 考虑使用 Graph

注意最后一个判断：如果多个角色完全独立、互不依赖，那你需要的只是多个并行的 Loop，不是 Graph。Graph 的价值在于处理角色之间的交互——交接、冲突解决和收敛。

理解检查

辨析题：Loop 中的 sub-agent 和 Graph 中的节点，最本质的区别是什么？（提示：不是数量多少的问题）
判断题：以下哪个场景适合用 Graph？
- A. 一个 Agent 每天自动更新项目依赖并提交 PR
- B. 三个 Agent 分别负责代码质量、安全审计和性能测试，最终需要综合出一个"是否可以上线"的结论
- C. 一个 Agent 写代码，另一个 Agent 审查代码
应用题：Peter Steinberger 的推文获得 290 万浏览量，说明社区对 Graph Engineering 有强烈兴趣。但 Josh Simmons 也指出"何时不该用 Graph"。描述一个看起来像需要 Graph 但实际上不需要的场景。

参考答案：

独立性。Sub-agent 没有自己的执行循环和决策权，由主 agent 调度和控制；Graph 节点是独立的实体，有自己的循环、记忆和决策权。打个比方：sub-agent 是你的手（你指挥它动），Graph 节点是你的同事（你只能和它协商）。
B。A 是单 Agent 的 Loop 任务（只需要一个角色）。C 是 Maker-Checker 模式，可以在 Loop 内用 sub-agent 解决。B 需要三个独立专业领域的 Agent 各自做判断，然后交给一个仲裁者综合——有独立角色、有交接流程、有结论冲突可能，符合 Graph 的使用条件。
典型例子：一个"微服务风格"的 AI 系统，把翻译、摘要、格式化三个步骤分给三个 Agent。这看起来像 Graph（三个节点，串行连接），但实际上三个步骤之间没有冲突、没有仲裁需求、没有共享状态——这只是一个串行 pipeline，用一个 Agent 的三步 prompt 就能解决，或者用 Loop 的三步执行即可。拆成 Graph 只增加了延迟和复杂性。

发生了什么

这一章你建立了从 Loop 到 Graph 的认知桥梁。

核心概念回顾：

四个需要 Graph 的信号：角色独立性、并行需求、结论冲突、记忆分化
Graph 三要素：节点（独立执行单元）、边（任务流转逻辑）、共享状态（公共白板）
三者定位：Loop 是时间结构，Graph 是组织结构，Harness 是运行系统
Graph 中的节点可能就是一个完整的 Loop
不是所有多 Agent 场景都需要 Graph——没有交互需求的多角色，多个独立 Loop 就够了

常见误区

误区	纠正
"多个 Agent = Graph"	不是。多个 Agent 并行运行但互不依赖，不是 Graph。Graph 的核心是节点之间的交互和协调。
"Graph 比 Loop 高级"	不是"高级"，是解决不同的问题。简单任务用 Graph 是过度设计。
"Graph Engineering 是全新的技术"	Josh Simmons 明确指出："名字是新的，问题早就存在。"微服务编排、工作流引擎、分布式系统协调——这些问题计算机科学讨论了几十年。Graph Engineering 是把这些思想应用到 Agent 协作领域。
"有了 Graph 就不需要 Loop 了"	Graph 的每个节点内部可能就是一个 Loop。Graph 不替代 Loop，而是在 Loop 之上增加了一层组织结构。
"共享状态 = 把所有对话历史合并"	共享状态应该是结构化的、有意义的信息（决策、结论、证据），不是对话历史的无差别堆砌。

本章检查点

完成以下清单后，你可以进入下一章：

[ ] 我能说出四个"需要 Graph"的信号
[ ] 我能画出 Graph 的三要素关系图
[ ] 我能区分 Loop、Graph、Harness 各自的定位
[ ] 我能用决策树判断一个任务是否需要 Graph
[ ] 我理解"Graph 中的节点可能就是一个 Loop"

下一章预告：你已经知道什么时候需要 Graph 了。下一章我们深入到 Graph 的设计细节——边上传递什么、共享状态怎么设计、节点失败怎么处理、人工确认节点怎么嵌入。我们会设计一个完整的多 Agent 方案评审系统的 Graph 拓扑。

← 上一章：设计你的第一个 Agent Loop | 下一章：设计可靠的 Agent Graph →

第 4 章：当一个 Loop 不够用——进入 Graph Engineering ​

起点与环境 ​

为什么现在做 ​

动手实践 ​

4.1 识别"需要 Graph"的四个信号 ​

4.2 Peter Steinberger 的那个问题 ​

4.3 Graph 的三要素 ​

要素 1：节点（Nodes） ​

要素 2：边（Edges） ​

要素 3：共享状态（Shared State） ​

4.3.1 用代码感受 Graph 的结构 ​

4.4 Loop、Graph、Harness 的定位辨析 ​

4.5 一个关键判断：你的任务需要 Graph 吗？ ​

理解检查 ​

发生了什么 ​

常见误区 ​

本章检查点 ​