点·线·环·图:从 Loop Engineering 到 Graph Engineering 及更远

点·线·环·图:从 Loop Engineering 到 Graph Engineering 及更远

起因

事情的起点有点讽刺。先是看到一篇 X 上的《Graph Engineering: 11-Step Roadmap…》,通篇引流腔、模糊背书(“one real build”)、零代码零数据, 还冒名 Boris Cherny(Boris亲自转发辟谣，笑了)。但是graph这个发展趋势又比较符合我对agent编排的期望发展，所以带着好奇找到一篇 Graph Engineering 的英文长文(引用 Anthropic 官方 + Peter Steinheimer / Mario Zechner / Carlos E. Perez / Hanako,承认底层不新)，阅读后记录一下自己的一些想法。

把思考沉淀下来, 免得过两周又跟着新名字打转。

共同目的

prompt / context / harness / loop / graph engineering, 贯穿始终的目标只有一个:

规范 LLM 的输出, 让它不只是"输出了", 而是可信、可用、可行。

拆开说:

• 可信(credible): 输出有依据、可溯源, 不是一本正经地编。
• 可用(usable): 能稳定复现、能集成进真实系统、失败有可控的降级。
• 可行(viable): 成本扛得住、能跑得起、可规模化。

Loop 和 Graph 是为同一个目标服务的两套结构手段, 不是换代。

演进:点 — 线 — 环 — 图

从数学/拓扑看, 这就是"特例到一般化":

• 点: 单次 prompt 调用。一问一答。
• 线(chain): prompt chaining, 上一步喂下一步，线性流水线。
• 环(loop): 引入反馈回路。输出被外部验证器检查, 不达标回去重做, 迭代收敛。与此相关的模型内的ReAct, 工程上的Loop Engineering。
• 图(graph): 多节点多边。并行 fan-out、条件分支、多回路、跨节点依赖、maker/checker 拓扑。环是图的退化情形(单回路、无分支、无并行)。

链 ⊂ 环 ⊂ 图, 都是图的特例。所以"Loop 之后是 Graph"比较合理, 是把单回路一般化成多节点多边。这跟软件架构的老路子一样: goto(任意图,乱) -> 结构化编程(顺序+循环+分支,安全但表达力受限) -> DAG / 状态机 / 工作流引擎(把"受控的图"请回来)。在我看来Agent 工程在重走这条路。

Loop Engineering: 让 agent 持续干活

期望：不手动 prompt agent, 设计一个 loop 去 prompt 它、检查结果、决定下一步, 直到工作通过为止。

5 个阶段: Discover → Plan → Execute → Verify → Iterate。过了就交付,不过就送回 loop。

三个硬条件:

1. 外部验证器: 测试过没过、build 编没编过。同一个 agent 既写又判对错, 就是花钱跟自己达成共识。
2. 对话外的状态: loop 要记得试过什么、什么失败了、哪些产物变了(所以个人感觉memory也是loop中很重要的一环)。
3. 退出条件: 成功是一个出口, 硬上限是另一个。

Loop engineering 给 agent 一份带指引的工作任务, 而不只是一条指令。

Graph Engineering:设计过程之间的关系

当一个 loop 不够用了 — — 多个 agent、检查、分支、重试、人工决策要协同——那个更大的结构就是图。

三件套:

• nodes: 工作单元。一个 agent、一个测试套件、一个 reviewer、一个审批步骤、一个存储产物、甚至一段普通确定性脚本。
• edges: 下一步可能发生什么。传数据、表依赖、满足条件才激活。
• state: 系统在图的哪个位置、发生过什么。哪些任务完成、各 agent 产了什么、哪些检查挂了、人批了没。

三段层次(我见过最干净的定义，来源于开头说的那篇读到的文章):

• Prompt engineering:跟模型沟通意图。
• Loop engineering:建一个持续追求该意图的过程。
• Graph engineering:设计这些过程之间的关系。

关键认知: "loop vs graph"是伪命题。Graph 包含 loop——loop 只是图里 fixer ↔ test 那条重试路径。Graph 是整个系统, loop 其中一条回路。

而且要分清两层: 底层不是新的(workflow 引擎、DAG 调度器、状态机、分布式系统)。变的是节点内部——以前一个 workflow step 跟固定规则, 现在节点里是 agent, 会误解、会变。所以要把关系逼到明面上, 不能让一个巨大 context window 同时当数据库、调度器、日志和项目经理。

Graph 的形态: 常见拓扑模式

停在"多节点多边"太抽象。落到具体形态, graph 常见这么几种拼法:

• 串行链(linear chain): A 给 B, B 给 C。依赖明确, 最简单。
• 并行 fan-out / fan-in: 一个任务拆 N 份并行跑, 再汇聚。省时, 但子任务需要独立无交错无冲突。
• pipeline 无 barrier: 每项流过多个 stage, 不等齐——某项在 stage3 时另一项还在 stage1。比"每阶段全齐再下一步"省时。
• orchestrator + specialist(fleet): 主 agent 拆活派给 specialist, specialist 还能套更小 subagent。比较重，观测麻烦, 但能分治。
• 条件分支(routing): 输出决定走哪条边, 不只"过/不过"二分。
• 嵌套子图(subgraph): 一个图模式当子图复用, 不重复画。

这些其实就是 Anthropic《Building effective agents》里那几个 workflow patterns, 也是 [[多 Agent 协作与编排]] 讲过的配合模式。graph engineering 把它们画在同一张图上、并管好它们之间的状态和边界。

DAG vs 含环图: graph 的核心区分

工程区分:

• DAG(有向无环图): 工作只前进, 每阶段跑一次, 不回退。研究类流水线常是 DAG–每个 stage 跑一遍, 没东西往回走。
• 含环图: 一旦加了 verifier 会拒绝并回退, 就有了 cycle, 也就有了 retry。环引入 DAG 没有的三件事: 成本(重试烧 token)、状态(要记得哪步重跑过)、停止条件(重复失败何时收手)。

所以 graph 不光是"谁连谁", 还得看: 哪些工作能复用(交叉点)、哪些分支必须重跑(环)、重复失败到几次该停。这是 DAG 不用操心、含环图绕不开的问题。

一张拓扑示意

拿 code review 举例, 一个含 loop 的 graph 长这样:

新 PR
  │
  ├─ fan-out ─┬─ 审计 agent(安全)
  │           ├─ 审计 agent(风格)    ┐
  │           └─ 审计 agent(正确性)  ┴─ fan-in ─ verifier
  │                                              │
                                   ┌─────────────┴─────────────┐
                                 通过                         拒绝
                                   │                          │
                                 发布                     fixer ◀──┐
                                                            │       │
                                                      test suite    │ ← retry
                                                            │       │   (这条回路 = loop)
                                                        失败 └───────┘
                                                        通过 ──→ 发布

整张图是 graph; fixer ↔ test suite 那条重试回路是 loop。能直观看到"graph 包含 loop", 也能看到 fan-out / fan-in / 条件分支 / retry 怎么共存于一张图。

当然这是一个几乎简单到不能再简单的graph了，我个人也在探索我个人工作与生活中是否有哪些场景适合上graph。

Graph engineer 要回答的设计决策

把 graph 从概念落到设计, 就是逼着自己回答这串问题(源自读到的那篇英文长文):

• 哪些工作能并行?
• 什么状态跨节点传递?
• 什么结果算证据?
• 谁能拒绝结果?
• 哪些失败该重试?
• 什么能在重启后存活?
• 人工审批放在哪?
• 系统最多花多少就该停?

这张清单其实跟后面 Agent Mesh 表里"该剥离的治理"是同一组问题, 只是一个在 graph 内部答, 一个抽到基础设施答。

state: graph 的"内存"

三件套里的 state 值得单独展开。它是 graph 的"内存"–checkpoint、断点恢复、state schema(任务完成状态、各 agent 产出内容、哪些检查失败、人批了没)决定 graph 能不能在中断后续跑, 而不是从头来。loop 的状态是"这一轮试了什么", graph 的状态包含"整张图走到哪了"——后者复杂得多, 也是 graph 比 loop 难管的核心原因之一。

执行侧 vs 控制侧: 一个 graph 的两面

graph 不只管"什么跑下一步"(执行侧: 分支/并行/review/retry/handoff), 还该管"这些工作是否还朝对的目标走"(控制侧)。Goodhart 定律和 reality anchors(下一节)讲的就是控制侧——loop 循环的判断依据是"验证器过没过", graph 的把loop关联起来的一个输入是"验证器本身量的对不对"。

说这个是为了说明，reality anchors 不是 graph 之外的可选深水区, 而是 graph 设计的固有组成。好的 graph engineering 把执行侧和控制侧连在同一张图上。

一个值得记的深水区:reality anchors(主观上的reality，有时候现在我也不知道怎么判断reality输入到模型后还能不能当成reality看待)

Graph 也可能产出 “组织良好的废话”: 20 个 agent 用同一个模型、读同一份有缺陷的上下文、查同一个坏指标, 可能会规模化地互相同意错误。更甚: agent A 查 agent B 的报告,审计 agent 查两者对仪表盘, 而仪表盘来自同一份底层数据——每个节点都同意。图看着治理完善(到处是 reviewer), 其实错误满地。

所以需要有来自 agent 系统外的锚点:真跑过的测试、到账的钱、留下的客户、物理测量、优化器改不了的规则、人对"更好"的判断。

还有 Goodhart 定律: 客服 agent 被奖励"快速关单", 关单速度上去了,客户却流失了——agent 学会了关掉难对话而非解决。loop 工作了, 但指标是坏的。graph 的控制侧应把关单速度连到留存、重开工单等信号,冲突就上浮人工(兜底链设计)。

这一段是 loop 单独讲不出来的: loop 问"验证器过没过", graph 问"验证器本身量的对不对"。——但是这个应该是graph的低层级简单应用，graph可以更复杂。

Loop vs Graph:太阳系 vs 银河系

我觉得比较贴切的一个比喻:

• Loop 像太阳系: 一颗恒星(目标)+ 几颗行星(各阶段)在固定轨道上循环。引力就是验证器——行星跑偏了被拉回来重跑,就是 retry。
• Graph 像银河系: 千亿恒星(多 node)各自运动,恒星间的引力(边 / 依赖)交织成网。有旋臂(并行分支)、有暗区(条件分支不激活)、有黑洞(人工审批吞掉失败链路)、整体在转但内部结构极其复杂。

关键:太阳系是银河系里的一小撮。银河系不是替代太阳系, 它包含无数个太阳系——每一个 loop 都是银河系里某颗恒星周围的循环轨道。你从太阳系"升级"到银河系, 不是把行星扔了, 而是看到原来那条孤零零的轨道, 只是更大引力网里的一条回路。

所以 graph engineering 不是"抛弃 loop",是给 loop 加了邻居、监督、和诚实汇报失败的地方。

但是还有个好奇的问题我自己还没有想明白的，就是每个loop内部，可以通过memory去进行每一轮后的复盘以及优化，但是memory在graph中是否也应该存在，用来记忆、优化、复盘graph中的node编排以及loop之间的配合。但是这可能会是个优化验证地狱，并且针对graph的变动变更可能会比loop中某个节点的变更更加复杂。引入过高的复杂度可能会使维护成本以及系统稳定走向崩溃。

(顺带标个边界: 银河系里恒星间引力近似对称、动态; graph 里的边常常是有向的、人设计的。我的这个比喻抓的是"包含关系"和"从单中心到多体复杂结构"这两点，其他点就不硬套了。)

别被命名忽悠

命名问题是这一路的噪音:

1. Graph Engineering 名字是新的,硬问题是旧的。读到的那篇文章中作者说"at least until someone gives it a new name next week"。prompt → context → harness → loop → graph, 每个名字大概半年就被宣布"死了"或被新词取代。抓结构关系, 别抓名字。
2. 有冒名假文钻空子。前面那篇 unicode 的《Graph Engineering 11-Step Roadmap》被证明是冒名 Boris Cherny 的 AI 营销文。它蹭的"graph 是 loop 之后"这个方向本身成立, 但那篇文章不是可信来源并且把graph engineering里面的graph与另一个方向(RAG)混淆。需要区分"概念方向"和"具体某篇宣称代表它的文章"。

微服务类比:agent 的下一步推测

因为最近针对AI，LLM，Agent的发展方向的讨论还挺热的，如果仅对比点、线、面，点 – 线 – 图这个拓扑关系，后续还会怎么发展好像有点模糊了(因为现在已经讨论到图了)，数学层面:图之后有几个候选,但多数不是"宏观跃迁" —— 还在图的范围内，比如图论里比图更一般的结构:

• 超图(hypergraph): 一条超边可连多个节点(普通边只连两个)。在"一次编排动作同时涉及多个 agent"时自然出现。
• 动态/时变图(temporal graph): 拓扑随时间变, 边有生效时间。
• 异构图(heterogeneous graph): 节点/边多类型(agent/checker/工具/人 是不同类型节点)。
• 高阶结构(simplicial complex): 范畴论里超越图的高阶拓扑。

但这些都是图内部的精细化, 不是"图之后的宏观跃迁"。异构图、超图其实现在的 agent graph 已经隐含在用(节点本就分类型)。真正的跃迁可能不在数学推广里, 而在工程治理里——就像微服务演进也不是靠图论推广驱动的, 是"服务多了之后治理不过来"驱动的。

把微服务路线的内核拎出来:把治理关注点从应用代码一层层剥离,下沉到基础设施。

• 单体: 业务 + 通信 + 治理全在一起
• 微服务: 业务拆开了,但发现 / 熔断 / 限流 / 可观测还耦合在每个服务里
• service mesh: 治理抽到 sidecar(数据面)+ control plane(控制面), 业务只管业务

Agent 这边现在在"微服务阶段": 工作流建模成图了, 但编排、状态、重试、验证、预算、可观测跟每个具体 graph 耦合。

做个个人意见的对照映射:

Agent Mesh 该剥离的(对应 service mesh 能力项):

个人臆想:
MCP ≈ 服务发现 + 连接治理雏形;
Workflow runtime ≈ 数据面;
Langfuse / LangSmith ≈ 可观测面;
LiteLLM / OpenRouter ≈ 模型路由 + 预算;
hooks / scheduled_tasks ≈ 触发自动化。
跟 service mesh 出现前的微服务生态类似 —— 各管一段,就差整合成统一的数据面 + 控制面。Agent 这边缺的就是这一跳, graph 的复杂度可能会逼它发生。

再远两步:

1. 类比Agent OS / 平台工程:类比分布式操作系统。统一资源调度、隔离、多租户、持久化、命名空间。mesh 之上的平台层。
2. 动态自适应图:现在 graph 是"工程师设计、运行时执行"; 下一步是图拓扑由元系统(orchestrator agent)根据任务动态生成调整。Claude Code 的 dynamic workflow(模型把计划写成 JS 程序 = 写图)已是雏形——从"静态画图"到"运行时生图"。

诚实声明:以上是推演、臆想, 不是已成共识。Graph Engineering 这名字本身才刚冒头,Agent Mesh 也只是按规律推的, 业界可能给它起个完全不同的名字或者甚至不往这个方向走。只是根据微服务那回的剧本的推测。并且这个推测跟Agent/LLM本身进化路线相关性不高，更多的是Agent工程化的一个臆测。

最后再劝自己一次

如无必要,勿增实体。

别一上来建几十个 agent graph。从一个循环任务起步, 给真实验证器、可检视状态、硬停止, 跑够次数搞清楚它怎么失败, 再画周围需要什么——第二个 reviewer、几条并行分支、安全一票否决、局部重试、webhook 触发。能用单 agent 别加 subagent, 能用工作流别上 loop, 能用单次 loop 别上持续 loop, 能用简单图别造系统。

为了用上新结构而硬找适用场景,是这条路最容易犯的病。用重型编排去处理本可一行脚本解决的简单任务, 技术上能跑, 但成本提升、失败面扩大、可观测性降低, 收益降低。

架构的重量, 永远跟着需求走 —— 不是反过来用一堆结构论证"我需要更复杂的结构"。