Xiaopeng Xu
About Research Publications Awards Notes
Xiaopeng Xu

Contents

图工程（Graph Engineering）：剥离炒作，重构 AI 智能体的组织拓扑

Xiaopeng Xu included in Technology
   7207 words   15 minutes 

“The hype is in the name, not in the problem. 当 AI 从一个 Agent 变成多个自主计算单元时，如何组织它们？这是一个真实的问题。”

—— 2026 年 8 月，社区对 Graph Engineering 的反思

引言：当一个循环不再足够

如果你一直在追踪 AI Agent 的架构演进，你会发现我们正在经历一场快速的范式推演。从优化单次提示的 Prompt Engineering，到组装上下文窗口的 Context Engineering；从构建模型运行环境的 Harness Engineering，到设计单一 Agent 自我纠错周期的 Loop Engineering。

但在 2026 年中，当开发者们试图将 Agent 系统推向真实的生产环境时，他们撞上了一堵墙。当一个任务复杂到需要研究、编码、安全审查和测试时，如果把这些全都塞进一个 Agent 的循环（Loop）里，上下文会迅速沦为充满 HTML 碎片和废弃草稿的"沼泽（Context Swamp）" [1]。Agent 会在同一个上下文里既写代码又做代码审查，最终陷入"自我肯定"的幻觉，或者在无尽的重试中烧光 Token 预算 [2]。

社区意识到：单体循环（Loop）已经到达了它的认知极限。

2026 年 7 月，OpenClaw 的创建者 Peter Steinberger 在 X 上抛出了一个引发全网共鸣的问题：“我们还在谈论 Loops 吗，还是已经转向 Graphs 了？” [3]。一时间，Graph Engineering（图工程） 成为最热门的架构词汇。

但当炒作退去，我们发现 Graph Engineering 并不是什么凭空出现的魔法。它在本质上是将组织行为学、分布式系统与图论结合，把多智能体协作当成可编程的组织（Programmable Organization）来设计 [4]。

本文将作为《Harness Engineering》与《Loop Engineering》的递进篇，深入剖析 Graph Engineering 的底层逻辑。我们将剥离概念炒作，探讨它与组织架构的同构性，它与 Harness 中 DAG（有向无环图）的本质差异，并给出真实的实用性判断与最佳实践。

一、什么是 Graph Engineering？

1.1 从"单兵作战"到"组织架构"

最简单的理解是：Loop Engineering 解决的是"一个 Agent 如何反复工作直到完成"；Graph Engineering 解决的是"多个 Agent/步骤如何分工、并行、交接、验证和汇合"。 [5]

一个典型的 Loop 是这样的：

Goal → Plan → Act → Observe/Verify → (Fail) → Retry

而一个 Graph 更可能长这样：

                    ┌→ Research Agent A ─┐
Goal → Planner ─────┼→ Research Agent B ─┼→ Synthesizer
                    └→ Research Agent C ─┘
                                        ↓
                                     Reviewer
                                      ↙     ↘
                                  Reject    Pass
                                    ↓         ↓
                                Synthesizer  Done

在 Graph Engineering 的视角下，系统被拆解为三个一等工程对象（First-class Artifacts） [6]：

  • 节点（Nodes）：执行具体工作的单元。可以是运行 Loop 的 LLM Agent（如研究员）、确定性的函数（如单元测试），或者是人工介入的审批点。
  • 边（Edges）：节点之间的控制流与数据流向。定义了许可的转移路径，包括顺序执行、条件分支路由、并行扇出（Fan-out）、扇入汇聚（Fan-in）以及重新回溯（Loop-back）。
  • 共享状态（Shared State）：沿着边在节点间流转的数据契约。确保下一节点仅接收其完成任务所需的最精简上下文，实现严格的上下文隔离。

社区中最精准的隐喻是：Agent 从 while-loop 毕业，变成了 org chart（组织架构图） [3]。你不再是给一个全能 Agent 下达指令，而是设计一个包含专业角色、审批门控和汇报路线的微型公司。

1.2 它与 Harness、Loop 的关系：不是替代，而是正交

很多营销文章将技术发展描述为"一代取代一代"：Harness 1.0 → Loop 2.0 → Graph 3.0。这在工程上是极不准确的。

https://xux-zotero-img.oss-cn-beijing.aliyuncs.com/img/20260811133455855.png?x-oss-process=image/resize,w_1600/format,webp

它们解决的是三个正交（Orthogonal）的问题 [5]：

维度Harness Engineering（环境基座）Loop Engineering（单点闭环）Graph Engineering（多点拓扑）
核心问题Agent 靠什么工作？Agent 如何持续工作？多个工作单元 如何协作？
设计对象运行时 / 环境 (Environment)反馈周期 (Feedback Cycle)拓扑 / 组织 (Topology)
核心元素工具、沙箱、权限、可观测性目标、执行、观察、验证、重试节点、边、状态、路由、并发
类比给员工办公环境和工具给员工 PDCA 工作机制设计整个公司的组织结构

更准确的心智模型是：Graph 的每一个节点本身就是一个 Loop，而整个 Graph 运行在同一个 Harness 之上。

Harness 是执行基底（Execution Substrate），Loop 是时序控制（Temporal Control），Graph 是结构控制（Structural Control） [5]。

二、康威定律的再现：Graph Engineering 与组织架构设计

Graph Engineering 与组织架构设计不仅是隐喻上的相似，它们在底层逻辑上是同构的。

2.1 为什么必须是 Graph，而不是 Tree？

传统的企业组织架构图通常被画成一棵树（Tree）——自上而下的层级汇报线，每个节点只有一个父节点。如果我们把 Agent 当作员工，为什么不能用 Tree 来组织它们？

如果完全照搬树状结构去搭建多智能体系统，会迅速陷入困局 [7]：

  1. 信息瓶颈与层层衰减：跨部门交流（如研发与测试）必须向上汇报到共同的祖先节点，导致上下文被严重抹平或幻觉化。
  2. 顶层节点的上下文沼泽：根节点必须处理所有分支的汇报，导致上下文窗口极度污染，推理成本呈指数级上升。
  3. 缺乏反馈回路（No Cycles）：树状结构在数学定义上禁止循环，这意味着下级无法向指令来源提供结构化的修正反馈。

事实上，人类组织在理想状态下画在纸上的是树，但在实际高效运转时，本质上也是一个图（Network） [4]。跨部门的 Task Force、矩阵式架构、非正式的沟通，这些都是打破树状层级的"横向边（Cross-Edges）"。

Graph Engineering 允许 多父节点（Fan-in） 和 越级直连（测试节点直接将错误反馈给代码节点），这才是匹配真实协作的结构 [4]。

2.2 逆康威策略（Inverse Conway Maneuver）

软件工程中著名的康威定律指出：“任何设计系统的组织，其产生的设计等同于该组织的沟通结构。” [8]

在 Agentic AI 时代，这演变为：Agent 系统的拓扑结构将不可避免地模仿构建它的企业组织架构 [8]。为了避免构建出孤立的 Agent 系统，现代组织设计提倡在 Agent 系统中采用逆康威策略： 不要让 Agent 意外地反映出你破碎的组织架构，而是先设计你理想中的 Agent Graph（跨部门价值流、并行节点、人类在环审批），然后重组人类团队来支持和治理这个架构 [8]。

三、认知循环的必然：与 Harness 中 DAG 的本质差异

在 Harness Engineering 和传统数据工程（如 Apache Airflow）中，最常用的工作流抽象是 DAG（Directed Acyclic Graph，有向无环图）。

那么，Graph Engineering 与 Harness 中的 DAG 有何差异？为什么 Agent 工作流不能是 DAG？

3.1 维度的差异：基础设施 vs. 业务拓扑

  • Harness 的 DAG 处于运行时/环境层。它关注的是基础设施级依赖调度、工具权限边界和安全可观测性。目标是让模型"能安全地做事" [4]。
  • Graph Engineering 处于工作流拓扑/编排层。它关注的是节点职责、边路由、状态传递和业务协作结构。目标是让多个专业化单元"按正确组织协作" [4]。

3.2 为什么必须有环（Cycles）？

DAG 的核心特性是"无环（Acyclic）"。在 DAG 中，执行路径是单向的，如果一个步骤运行两次，那通常意味着一个 Bug。

然而，Agent 的核心特征是基于反馈的试错与自我修正。一个典型的 Agent 工作流是：生成代码 → 运行测试 → 测试失败 → 返回修改代码。

这种"测试-修复"的循环是无界的（Unbounded），它在本质上是一个状态机（State Machine）中的循环（Cycle） [9]。如果用 DAG 来强行实现这种逻辑，开发者只能在单个节点内部写死 while 循环（导致执行过程不可观测），或者硬编码最大重试次数的节点复制（极其笨拙） [9]。

有向图（允许受控环）使得以下高级 Agent 模式成为可能 [10]：

  • 自我反思（Self-Reflection）：Agent 批评自己的输出，沿着环路退回并重新生成。
  • 动态重试（Conditional Retries）：基于语义评估失败的重试。
  • 人类在环（Human-in-the-loop）：人工审批拒绝后，沿着环路退回修订状态重新提交。

正如一位架构师所言：“DAG 中的循环是死循环；而 Agent Graph 中的循环是认知迭代。” [11]

四、剥离炒作：Graph Engineering 的阴暗面与真实代价

2026 年 7 月的"命名热潮"制造了大量噪音。我们需要将"Graph Engineering 概念的炒作"与"Graph-based Orchestration 的真实价值"分开评价 [12]。

在生产环境中贸然引入图工程，常会引发以下负面效应 [12] [13]：

  1. 过度工程化（Over-engineering） 本来一个 Agent + 强验证器就能解决的问题，被硬拆成 Planner、Researcher、Writer、Reviewer 五个节点。图并不自带"智商"，给一个平庸的模型套上复杂的拓扑，只会让系统变得极度难调试。
  2. Token 与成本爆炸（Token Inflation） Anthropic 坦承，其基于 Graph 的多智能体深度研究系统虽然任务质量提升了 90%，但 Token 消耗量暴涨了 15 倍 [14]。如果节点缺乏严格的边界，图中的重试和回溯循环会瞬间演变成"Token 黑洞"。
  3. “图结构"僵化了模型的推理能力 随着基座模型（如 Claude 3.7 / GPT-5 等）推理能力的跨越式提升，人工预设的图拓扑可能会成为绊脚石。硬性的节点跳转阻止了模型根据具体语境灵活选择最优路径，形成了"用低智商的图结构限制高智商模型"的尴尬局面 [13]。
  4. 多智能体 ≠ 集体智慧 实证研究表明，多智能体团队有时甚至无法利用最强专家 Agent 的能力，团队倾向于把专家和弱者的意见"平均掉”，导致整体表现下降 37.6% [15]。组织越复杂，并不意味着组织越聪明。

五、实用性判断与真实落地案例

答案其实很简单：平均任务，价值有限；复杂高价值任务，非常有价值。 [12]

适合用 Graph 的信号（满足多个才值得） [12] [13]：

  • 任务有真正可并行的独立分支（Fan-out 能显著缩短墙钟时间）。
  • 需要干净、隔离的上下文（避免自审 Rubber-stamp）。
  • 确定性阻断与权限隔离（如财务系统必须经过专有 Audit 节点）。
  • 长流程可恢复性（Checkpointing & Replay）。

真实的优秀落地案例

案例 1：Anthropic 官方 Multi-Agent Research System [14]

  • 场景：自动完成复杂主题的深度研究报告。
  • 架构：Lead Agent（Opus）接收 Prompt 并分解子方向；并行派生多个 Researcher Subagents（Sonnet）独立抓取数据；最后由 Synthesizer 汇总，并经过 Citation Check 节点强制校验来源。
  • 价值：打破了单 Agent 上下文爆掉的问题，复杂研究准确率提升 90.2%。这是并行探索与独立上下文窗口的最佳实践。

案例 2：GitLab Duo Agent Platform [16]

  • 场景：将 AI 嵌入真实的 DevSecOps 业务流程。
  • 架构：Issue → 分析需求 → Plan → 修改代码 → 测试 → 提交 PR → Human Review。
  • 价值：Graph Engineering 不是为了"模拟一家公司"，而是把 AI 嵌入已经存在的业务 Workflow。这比"5 个 Agent 开会讨论"实用得多。

案例 3：金融/保险理赔自动化（高合规工作流） [13]

  • 场景：处理复杂的保险理赔单。
  • 架构：Document Extractor 提取 JSON → 确定性规则引擎路由 → 小额直通 Payout 节点 / 大额路由至 Fraud Detection 节点与 Human Checkpoint。
  • 价值：满足了严肃业务的可追溯性（Auditability）。Graph 记录了 State 在哪个节点被谁修改过，形成了明确的决策树轨迹。

六、最佳实践：如何构建健康的 Agent Graph？

综合 Anthropic、LangGraph 以及社区的实践，落地 Graph Engineering 应遵循以下原则 [5] [13]：

  1. Loop First, Graph Second：先把单节点 Loop（自我纠错机制）做扎实。大多数日常任务用单 Loop 更便宜、更快、更好调试。复杂度应该被任务"逼出来"，而不是主动加进去。
  2. 按依赖拆分，而非按"步骤"拆分：A 后面写了 B，并不意味着 B 必须依赖 A。真正没有数据依赖的任务应该 Fan-out 并行。
  3. 节点职责单一（Single-purpose）：研究、编码、安全审查应由不同节点负责，以实现严格的上下文隔离。
  4. 边（Edge）必须契约化：节点间不要只传一段自然语言，而应传递结构化的 State / Schema（如 {finding, evidence, confidence}）。
  5. 验证器（Verifier）独立于生产者：一个 Writer 自己说"我写得很好"价值有限。更好的拓扑是 Producer → independent Reviewer → conditional edge → Producer。
  6. 能确定性（Deterministic）就不要 Agentic：路由、去重、Schema 校验、单元测试这些最好用代码 Hook 作为硬性边；真正需要语义判断的地方再放 LLM。
  7. 引入外部锚点（Anchors）：防止图系统形成自我认可的"回音室效应（Echo Chamber）"。必须有硬性的单元测试、真实 API 校验或物理数据比对作为外部锚点。

七、统一框架：PDCA 如何贯穿三个工程层次

在管理学中，PDCA（Plan-Do-Check-Act，戴明环）是最经典的组织学习模型。它与 Agent 工程三层架构之间的关系，是理解整个系统设计哲学最深刻的切入点。

7.1 PDCA 与 Loop Engineering 的同构性

PDCA 的四个环节与 Agent Loop 的执行周期几乎是同一种控制论逻辑：

PDCA：     Plan  →  Do  →  Check  →  Act
                 ↑                      ↓
                 └──────────────────────┘

Agent Loop：Plan  →  Act  →  Observe  →  Reflect
                 ↑                           ↓
                 └───────────────────────────┘

两者的本质都是：Action → Environment → Feedback → Update → Action。区别主要在时间尺度：Agent Loop 以秒/分钟为单位，团队协作 Loop 以小时/天为单位，组织级 PDCA 以周/月/季度为单位。因此，PDCA 是 Loop Engineering 的管理学前身——它描述的是组织如何学习（Dynamics），而不是组织如何结构（Structure）。

7.2 三层 PDCA 与三个工程层次的映射

PDCA 实际上存在三个层次，分别对应不同的工程问题：

PDCA 层次时间尺度工程映射核心问题
Level 1：Agent 级 PDCA秒 / 分钟Loop Engineering单个 Agent 如何自我纠错？
Level 2：团队 / 工作流级 PDCA小时 / 天Loop + Graph Engineering多个专业角色如何协同完成一轮 PDCA？
Level 3：组织级 PDCA周 / 月 / 季度Outer Loop → 优化 Graph组织能否通过 PDCA 重构自身的组织架构？

Level 1（Agent 级） 是最典型的 Loop Engineering：一个 Agent 执行 Plan → Act → Observe → Reflect，直到满足终止条件。

Level 2（团队级） 是 Loop 与 Graph 的叠加。PDCA 的时序结构（Loop）决定了"如何学习"，而 Graph 的拓扑结构决定了"由谁来执行"：

              PLAN（Orchestrator 节点）
                        ↓
           ┌────────────┼────────────┐
           ↓            ↓            ↓
        Agent A      Agent B      Agent C      ← DO（Fan-out 并行执行）
           └────────────┼────────────┘
                        ↓
                  Reviewer 节点                ← CHECK（独立验证器）
                        ↓
             ┌──────────┴──────────┐
             ↓ (未达标)             ↓ (达标)
         Loop-back 边           System Update 节点  ← ACT（条件路由）
       （带 Failure Analysis）   （固化 SOP / 更新知识库）

这里，PDCA = Loop（时间维度上的闭环），Graph = 执行 PDCA 的组织结构（空间维度上的协作拓扑）。两者是正交的，缺一不可。

7.3 最高层次：用 Loop 优化 Graph 本身

Level 3（组织级） 是最深刻也最前沿的层次。在这一层，PDCA 的 Act 阶段不再只是修改 Prompt 或策略，而是修改组织架构本身。

例如，Check 阶段发现 R&D → Manager → Product 的沟通存在瓶颈，Act 的结果是将中间层删除，建立 R&D 与 Product 的直连边。这意味着 PDCA Loop 的优化目标（Optimization Target）是 Graph 本身：

设计 Graph₁ → 执行 → 评估性能 → 诊断瓶颈 → 修改拓扑 → Graph₂ → 执行 ...

用数学语言表达：

$$G_{t+1} = f(G_t,\ \text{performance}_t,\ \text{feedback}_t)$$

此时，状态不再只是 {draft, code, answer}，而包括 {nodes, roles, edges, permissions, models, routing, verification topology}。这就是所谓的 Adaptive Graph Engineering，也是目前 AI Agent 系统里最值得深入研究的方向：用 Loop 来优化 Graph。

7.4 统一的心智模型

综合以上分析，Harness / Loop / Graph 与 PDCA 的完整对应关系如下：

管理学概念Agent Engineering 对应
组织架构图（Org Chart）Graph（结构）
PDCA 戴明环Loop（动力学）
IT 系统、流程制度、权限Harness（能力边界）
KPI / 审计Verifier（验证节点）
部门职责Nodes（节点定义）
汇报 / 协作关系Edges（边）
战略迭代Outer Loop（元循环）

最终的统一框架是：

                         SYSTEM
                           │
          ┌────────────────┼────────────────┐
          │                │                │
       HARNESS           GRAPH             LOOP
          │                │                │
     Capabilities       Structure        Dynamics
     Constraints        Organization     Learning
     Environment        Coordination     Feedback

PDCA 不是一种组织架构，而是组织如何学习。Graph 是组织如何组织。Harness 是组织靠什么条件运行。 真正高级的组织学习，是通过 PDCA，不仅改进工作，还改进组织本身。

结语：复杂度的最终归宿

让我们用管理学的语言重新审视这一系列博客的演进脉络：

  • Harness Engineering 是组织运行的条件（IT 系统、流程制度、权限边界）。
  • Loop Engineering 是组织如何学习（PDCA 戴明环，反馈与迭代）。
  • Graph Engineering 是组织如何组织（架构图、职责分工、协作拓扑）。

而最高层次的目标，是让组织通过 PDCA Loop 不断优化 Graph 本身——Adaptive Graph Engineering。这才是 AI Agent 系统向"真正的组织学习"进化的最终归宿。

但请始终记住：多智能体 ≠ 集体智慧，多智能体 = 更多潜在计算能力 + 更多潜在协调成本。最优秀的 Graph Engineer 不是画出最复杂网络的人，而是知道何时只需一个简单的 Loop 就能解决问题的人。

参考文献

[1] Reynders, C. (2025). How organizations shape their agentic systems. reynders.co. https://reynders.co/blog/how-organizations-shape-their-agentic-systems/

[2] AI Builder Club. (2026). Graph Engineering with Claude Code: Subagents as an Agent Graph. aibuilderclub.com. https://www.aibuilderclub.com/blog/graph-engineering-with-claude-code

[3] Flowtivity. (2026). From Loops to Graphs: The Next Paradigm in AI Agent Engineering. flowtivity.ai. https://flowtivity.ai/blog/graph-engineering-2026-guide-openclaw-codex/

[4] AI Builder Club. (2026). Is Graph Engineering Just LangGraph?. aibuilderclub.com. https://www.aibuilderclub.com/blog/is-graph-engineering-just-langgraph

[5] AI Builder Club. (2026). Graph Engineering Guide (2026). aibuilderclub.com. https://www.aibuilderclub.com/blog/graph-engineering-guide-2026

[6] LangChain Docs. (2026). Graph API overview. docs.langchain.com. https://docs.langchain.com/oss/python/langgraph/graph-api

[7] Curry, B. J. (2026). Nodes and Edges: Architecting the Human–AI Organization. Medium. https://medium.com/@brian-curry-research/nodes-and-edges-architecting-the-human-ai-organization-43cb3f84118a

[8] TrueFoundry. (2026). Graph Engineering for Multi-Agent Systems: Architecture, Governance, and Observability. truefoundry.com. https://www.truefoundry.com/blog/graph-engineering-enterprise-guide

[9] CalibreOS. (2026). Agent State Machine Design: DAGs, Cyclic Graphs, and Dynamic Workflows. calibreos.com. https://www.calibreos.com/learn/genai-agent-state-machines

[10] Creative AI Ninja. (2026). LangGraph: Why the Future of AI Agents Looks Like a State Machine, Not a Chatbot. Medium. https://medium.com/@creativeaininja/langgraph-why-the-future-of-ai-agents-looks-like-a-state-machine-not-a-chatbot-c4562fa148cb

[11] Reddit r/AI_Agents. (2026). The move from agent loops to structured graphs, with the research behind it. reddit.com. https://www.reddit.com/r/AI_Agents/comments/1v8ueiu/the_move_from_agent_loops_to_structured_graphs/

[12] Eigent AI. (2026). Graph Engineering for AI Agents: Hype vs. Reality. eigent.ai. https://www.eigent.ai/blog/graph-engineering-ai-agents

[13] AI Builder Club. (2026). Graph Engineering with Claude Code. aibuilderclub.com. https://www.aibuilderclub.com/blog/graph-engineering-with-claude-code

[14] Anthropic. (2026). How we built our multi-agent research system. anthropic.com. https://www.anthropic.com/engineering/multi-agent-research-system

[15] arXiv:2602.01011. (2026). Multi-Agent Teams Hold Experts Back. arXiv. https://arxiv.org/abs/2602.01011

[16] GitLab. (2026). GitLab Announces the General Availability of GitLab Duo Agent Platform. about.gitlab.com. https://about.gitlab.com/press/releases/2026-01-15-gitlab-announces-duo-agent-platform-general-availability/

[17] IntuitionMachine. (2026). From Loop Engineering to Graph Engineering?. Medium. https://medium.com/intuitionmachine/from-loop-engineering-to-graph-engineering

Updated on Aug 11, 2026
 Graph Engineering, Loop Engineering, Harness Engineering, Agentic AI, Software Engineering
Back | Home