图工程：同一个 agent 写代码又当评审，错到结尾才暴露

同一个 agent 写代码又当评审：单智能体到底卡在哪？

先看一个本该荒谬、却天天在发生的场景。你给一个编程 agent 派了活：写一段代码，然后让它自己评审、自己测试、自己验收。它跑一遍，报"通过"，爽快交差。可这个"通过"是谁说的？是写代码的那个人，也是评代码的那个人。它把自己对正确性的判断，当成了正确本身。评审没有引入任何新的视角，只是同一个模型换个 prompt 再点一次头。

论文在分析个体智能的局限时，把这个例子当成了典型失败模式：角色混淆与确认偏误（confirmation bias）。复杂工作流的不同阶段需要不同的专长、工具、访问权限和验证程序，可单个 agent 在同一个控制回路里包办一切，没有人能对它的结论说不。更隐蔽的是第三条：长任务里早早就犯下的一个小错不会立刻暴露，它被一路带进后面每一步，直到任务临近结束、整体失败的那一刻才显现，到那时错误出自哪一步，已经很难追溯了。

这三条不是偶发失误，论文把它们写成个体智能的三条结构性瓶颈：调度并行与相互依赖的任务，整合专门化专长与独立验证，维护持久状态并处理失败恢复。想想软件故障诊断：日志分析、故障复现、代码检查完全能并行推进，修复和测试则依赖它们的结果。一个单智能体的串行循环把所有并行可能性压成一条线，并行效率被浪费掉；更要命的是错误传播，论文的原话是，错误的时间结果会被一路带到后续步骤，坏掉的那一步因此难以定位。想让多个异构专家各管一段、互相验证，想让系统状态跨步骤持久存在、错了能定位能恢复，一条循环装不下其中任何一件 Graph Engineering。

注意关键词是"结构性"。论文的原话是：仅仅增强单个 agent 的能力或上下文，无法解决这个架构失配（architectural mismatch）。换更大的模型、加更长的上下文窗口，都绕不开这三条。因为单智能体的组织形式本身，就是把所有事情压进一条循环。论文把这条循环形式化成一句话：Agent = Loop(LLM + Harness)。模型负责想，harness（执行外壳）负责接进工具与行动能力，循环让"想、做、看结果"一遍遍滚动。论文给个体智能下的定义，落点也在这条循环上：单个 agent 把模型层的推理，通过资源编排与环境的迭代交互，延伸为持久、目标导向的执行。定义里每个词都指向同一种组织形态，一条串行 loop。它很强，但强在个体层面。

这条循环的顶点形态，是 2022 年的 ReAct。它把推理轨迹与行动交错生成，Thought、Action、Observation 三步循环，让模型一边推理一边调用工具、根据观察修正计划，论文把它当作个体智能顶点的代表来定位 ReAct。

图注：ReAct 论文的对照示意。上方四路解法里，只有最右的 ReAct 同时出现思考（Thought）与行动（Action）的交错；下方文本游戏里，纯行动的路径一路失败，插入关键思考的路径在重新组织后走到了答案。ReAct

但这条循环就是个体智能的天花板。论文专门用一节拆解它的局限：想让单个 agent 更聪明，该试的路都已经试到顶了；要实现并行、分工、独立验证、持久状态，只能换一个组织层面，让多个 agent 以某种结构协作。问题来了：是什么结构？

图抽象早就出现过，为什么如今才叫 Graph Engineering？

单智能体这一路的进化，其实有一根清晰的谱系。论文把它排成五个范式：Prompt、Context、Harness、Loop，最后是 Graph Engineering。值得注意的恰恰是前四个的共性，它们都在干同一件事：把单个 agent 做得更强。每个范式都有自己的答案，也都有自己的盲区，而盲区全都指向同一个方向。

Prompt Engineering 让同一个模型换着法子想问题。Chain-of-Thought 让它把推理写下来，Tree of Thoughts 让它在多条思路里搜索。到 2023 年的 Graph of Thoughts（GoT），图抽象第一次登场：thought 是顶点，thought 之间的依赖是边，多个想法能聚合、也能发散。但关键在这里：它组织的是推理步骤，改变的是 prompt 里的思考方式，模型本身纹丝不动 GoT。

Context Engineering 管信息的调配。MemGPT 把固定窗口的模型改造成有"主记忆"和"外部存储"的两级结构，用类似操作系统的分页机制在上下文窗口内外搬数据，在有限窗口里"假装"有无限上下文 MemGPT。Harness Engineering 把工具接进来，Loop Engineering 让"思考、行动、观察"循环滚动，ReAct 就是后面两者的组合。把这几代叠在一起，终极产物是一个更强的单 agent：能干更长的活、记得更多、调用更多工具 Graph Engineering。

图注：论文的范式全景。底部是基础模型；Prompt 与 Context Engineering 在其上实现模型智能，Harness 与 Loop Engineering 再叠一层实现个体智能，最上层的 Graph Engineering 用任务组织、智能体协调、运行时状态管理三根支柱撑起系统智能。图的叙事是"叠加"而非"替换"。Graph Engineering

这里有个反直觉的点值得停下来。图抽象不是 Graph Engineering 的发明，GoT 早就把推理画成图了。论文自己还用过一套考试的比喻来排这五个范式：闭卷是基础模型独闯；开卷带笔记，对应 prompt 与 context 把外部知识放进来；带工具，对应 harness 接上外部能力；边做边改，对应 loop 用反馈调方向；最后的团队协作，就是 graph。差别从来不在"用不用图"，而在"图组织的是什么"。GoT 组织的是 thought，一条推理流里的节点；Graph Engineering 要组织的是任务、智能体、运行状态，是系统层面的结构。组织对象的升级，才是那一步真正的跃迁：把"组织"从个体内部的隐式推理，外化成系统层面可以被读写、被调度、被修改的显式结构。

为什么组织层偏偏在这几年被提出来？看时间表就明白了：被论文收进这张图的代表系统，MetaGPT、DyLAN、GPTSwarm、ADAS、Magentic-One，集中在 2023 下半年到 2024 年密集出现，恰好是大家开始让 agent 去跑真实长任务的时期。真实任务从来不是单线程的：要分工决策、要并行执行、要互相验收、出了事故要能回溯。单条循环再长，也长不出这些结构。前四个范式恰恰都缺这一层，它们优化的始终是同一台机器，而不是机器与机器之间的组织。下一章进入正题：这台组织机器长什么样。

把"组织"画成图：任务、队友、状态三张视图

论文给 Graph Engineering 的官方定义可以一句话拆完：用图结构作为核心基座，把任务、组件、运行时状态之间的关系外部化，从而支撑系统层面的组织、协调、监控、恢复与优化。"外部化"是这里最重的词，它意味着组织信息不再只存在于某个 agent 的上下文里，而是落在纸面上，谁都能读、谁都能改。

具体落成三张视图。任务组织（Task Organization）回答"要做什么"：全局目标怎么分解成可执行单元，单元之间的依赖、顺序、并发、验证约束怎么表示。智能体协调（Agent Coordination）回答"由谁做、谁跟谁说"：工作怎么映射到异构 agent 和计算组件，通信、委派、同步、结果整合怎么结构化。运行时状态管理（Runtime State Management）回答"系统现在走到哪"：执行状态怎么记录和维护，如何跟踪进度、隔离故障、按需恢复 Graph Engineering。

想抓住三张图的配合方式，最贴近的比方是一支工程队的作战看板。任务图是墙上的待办与依赖板：哪些事能同时干，哪些事必须等上游完成。智能体图是人员分工与沟通表：谁负责哪块，谁和谁之间有接口。状态图是现场进度与事故日志：现在干到哪了，刚才哪里出过问题。看板最要紧的特性是它是活的：每天收工，根据现场实际发生的情况，把看板本身改一改。任务图、智能体图、状态图不是三个独立模块，而是一套耦合结构，运行时证据会一路回写，反过来修订任务图和智能体图。论文最重要的那张总图画的就是这件事。

图注：论文 Figure 4，Graph Engineering 三视图总览。左列任务组织生成工作结构，中列智能体协调匹配能力并路由通信，右列运行时状态管理记录执行、定位故障、支持恢复；底部一条反馈回路把运行时证据回写到任务图与智能体图，体现三张视图的耦合关系。Graph Engineering

论文还给这套系统一个形式化：$S^t = (A^t, R^t, E^t, \Pi^t, x^t)$。五个符号依次是智能体团队、共享资源、外部环境、协调机制和系统状态。共享资源指工具、模型服务、内存、知识库、验证器，经由每个 agent 的 harness 访问；环境会随 agent 的行动演化并回馈观察；而系统状态不同于单个 agent 的局部状态，它记录任务进度、共享结果、资源状况和失败记录。论文特意强调：系统行为不只取决于个体能力，还取决于共享资源怎么用、智能体怎么协调、系统状态怎么演化 Graph Engineering。论文还维护了一个持续更新的官方资源中心 Awesome-Graph-Engineering，按这套三层架构把收录的论文、基准、开源库整理成索引，想按图索骥的读者可以从那里入手 Awesome-Graph-Engineering。

三张视图是这个范式的骨架。接下来的三章，分别钻进每一张图看落地。

任务图：要做什么画成图之后，连图本身都能被优化

任务组织在论文里分两层。第一层是目标分解（Goal Decomposition）：把高层目标切成子任务，节点是子任务，边是依赖。依赖一旦被画出来，可调度性就暴露了：哪些子任务互不依赖、可以并行派发，哪些必须等上游完成，一目了然。第二层是工作流优化（Workflow Optimization）：把语义子目标编译成可执行的算子图，节点是 LLM 调用、检索模块、工具、验证器，边是控制流与数据流。目标分解回答"要做什么"，工作流优化回答"怎么把它跑起来"，两层合起来就是任务图 Graph Engineering。

回到开头的软件故障诊断。日志分析、故障复现、代码检查是三个独立分支，可以同时开工；修复和测试必须等它们的结果。画成 DAG（有向无环图，directed acyclic graph）之后，调度不再是 agent 脑子里隐式的临场判断，而是图上明确的结构：所有"就绪"节点并行派发，一个分支失败，失败定位也有图可循。

图立起来之后，更激进的事发生了：连图本身都能被优化。GPTSwarm 把语言智能体直接建模成可优化计算图：节点是 LLM 推理或工具调用这类基本操作，边是信息流。图组合还能递归：单个 agent 图描述它内部的执行拓扑，跨图边就是 agent 之间的通信通道，通道一接上，几个 agent 就组成了 swarm GPTSwarm。优化分两头。边优化用 REINFORCE，一种策略梯度强化学习算法，直接在连接关系上学：哪些通信该保留、哪些该剪掉。节点优化则按节点分解 prompt，一点一点调每个操作节点的行为，避免一次优化整张图带来的组合爆炸。任务组织第一次从"上下文里的隐式推理"，变成"可被外部调度、可被算法学习"的对象。

图注：GPTSwarm 三层结构示意。内层是 LLM 推理、工具调用等基本操作节点；中层是节点组合成的单个 agent 图；外层是多个 agent 图通过跨图通信通道连成的复合图（swarm）。节点与边都可以通过提示词、演化或强化学习方法优化。GPTSwarm

在已有图上优化还不够，ADAS 把层级又推高一层：让一个 meta agent 在代码空间里迭代地"发明"新的 agent。meta agent 生成的新 agent 要先过两轮自我反思，确认它不是已有结构的简单变体；在验证集上评估，报错就最多再修五轮；合格才写进一个持续增长的档案库（archive），档案库再反哺下一轮搜索 ADAS。换句话说，任务图的模板本身不再由人手写出，而是被自动发现、自动沉淀。在已有图上优化，与让结构本身被发现，是两层不同的事，前者考验算法，后者考验的是搜索空间的表达能力。

任务图到这里说完了，"要做什么"有了清晰的落点。可"活派给谁、谁跟谁说话"，是下一张图的事。

智能体图：派活给谁，写死的装配线还是每次现组队？

智能体协调同样分三层。能力层描述每个 agent 会什么、能访问哪些资源；团队层决定把哪些 agent 组织成一个协作结构；通信层决定信息在谁和谁之间流动 Graph Engineering。

在团队和通信这两层上，业界天然分成两派。一派把组织图画死。MetaGPT 把软件工程的标准作业流程（SOP）直接编码成一条装配线：产品经理产出 PRD，架构师产出设计，项目经理拆任务，工程师写代码，QA 评审，五个角色按固定顺序接力，节点之间还有"Anything Unclear?"的反馈回环，让上游可以被打回。除了装配线主流程，它还用一个共享消息池让各角色发布结构化消息、按自己的 profile 订阅感兴趣的部分，信息怎么流和流程怎么走被解耦。但它的团队拓扑在运行前就定型了，运行中不变 MetaGPT。

另一派让组织图每次现画。DyLAN 分两个阶段：先离线做团队优化，用无监督的 Agent Importance Score（智能体贡献分）在候选池里给每个智能体打分，选出贡献最高的组成团队；再在线做任务求解，每一步执行后由 LLM Ranker 对上一轮的响应排序，下一轮只让表现最好的几个继续通信。贡献分是在时间层网络上做反向传播算出来的，思路源自神经元重要性打分；求解阶段还有一招早停，当一层里超过三分之二的 agent 给出相同答案就收手，通信长度随问题难度自动伸缩。下一位该谁发言，由查询内容实时决定，每个问题的通信结构都不一样 DyLAN。

图注：DyLAN 两阶段示意。左半"团队优化"把智能体池收敛为选中团队，中间以贡献分完成打分排序；右半"任务求解"里，LLM Ranker 在相邻时间步之间挑选表现最好的节点，下一时间步的通信对象只来自被选中的响应。DyLAN

这两派之间其实还有第三个位置：GPTSwarm 不写死拓扑，也不靠启发式现选，而是在固定节点集合上让算法自动优化边。静态、动态、可学习，智能体图的设计谱系至此齐了：一端是画死的工程设计图，一端是按查询实时调线的路由图，中间是被机器学习调优的图。

活派下去了，谁跟谁说话也定了。可系统运行到一半，怎么知道自己现在走到哪、刚才谁错了、下一步怎么补救？还没有一张图来回答。这就是状态图的入口。

状态图与演化：错是怎样被定位的，结构怎样自己长出来

运行时状态管理给出三件套。状态记录（State Recording）把每次状态迁移的证据、来源、版本都存下来，要求结构化的表示、受限的更新和一致的版本管理；故障定位（Fault Localization）从执行证据里找出那个决定性的错误，沿着依赖把传染范围圈出来；失败恢复（Failure Recovery）只修补受影响的局部，而不是整条工作流推倒重来。论文特别强调一点：故障定位是把"因果"当作假设来检验，时间先后和结构相邻都不等于因果 Graph Engineering。

这套机制在 Magentic-One 里长得非常具体。它由一个 Orchestrator 统筹、四个专职 worker 干活：WebSurfer 管浏览器，FileSurfer 管文件，Coder 写代码，ComputerTerminal 跑命令。Orchestrator 维护两个账本：外层循环记任务账（task ledger），存事实、猜测和计划；内层循环记进度账（progress ledger），存当前进展和任务分派。只要还在产出有效进展就继续派活；一旦停滞计数器（stall counter）超过阈值，就跳出内层循环，反思之后重新规划，把修订写回任务账本，再开新一轮。这套架构还是可插拔的：worker 可以增删，不需要重新训练或改 prompt，团队规模跟着任务走 Magentic-One。

图注：Magentic-One 架构。居中 Orchestrator，四周是 FileSurfer、WebSurfer、Coder、ComputerTerminal 四个 worker。浅色外层回路管理任务账本（事实、猜测、计划），深色内层回路管理进度账本（当前进度、任务分派），并包含"停滞则反思重规划"的回环。Magentic-One

把 ReAct 的单智能体循环和这套双账本对照一下就清楚了：思考、行动、观察的循环被搬到了整个系统的编排层，而"系统现在在哪"第一次成为可读写、可回写的显式结构，不再散落在某个上下文窗口里。这个概念其实有前史：单智能体时代，MemGPT 就已经用"主记忆加外部存储"的分页结构把记忆层级化；状态图是这个思路从个体内存走向系统组织的延伸。

再往外看一层，就是演化。论文指出，任务图与智能体图定义的是潜在的工作与协作结构而非执行产生的实际状态；长程系统还缺一环：把执行历史沉淀成可复用经验，回写并改进未来的图结构，论文管这叫 Experience-driven Evolution Graph Engineering。ADAS 的档案库是这条线的一个例证：每次搜索发现的 agent 结构进入档案库，成为下一轮搜索的起点。整个闭环长这样：

图注：Experience-driven Evolution 的闭环示意。执行历史沉淀为可复用经验，经验回写并改进任务图与智能体图，改进后的结构进入下一次执行。

到这里可以收口了。论文的结论句值得记住：系统级的智能，更少取决于简单地堆更多模型或 agent，更多取决于把工作、行动者、状态之间的关系显式地组织起来。从同一个 agent 写代码又当评审的个体天花板，到三张显式图，再到图可以被优化、被自动发现、自己演化，变化的只有一件事：组织关系被外部化的程度 Graph Engineering。

同时要看清边界。这篇论文是综述性质，没有带来新的量化实验，它的证据来自对既收录代表系统的整合，比如已在 GAIA 等基准上做过验证的 Magentic-One，具体数字这里不展开。论文还把评测资源按智力层级而非任务领域来组织，分成 Benchmark、Dataset、可执行环境三类；对 LangGraph、AutoGen、CrewAI 这些开源框架，则把它们映射到工作、团队、状态、演化这一张表上，作为图原生基础设施的早期雏形 Graph Engineering。而且不是所有"用图"都算 Graph Engineering：只把知识图谱当外部检索源用的 GraphRAG，如果图不影响任务组织、智能体协调或运行时行为，就不在论文的定义之内。论文自己承认，评估、语义对齐、治理、隐私、安全的自改进，都还是空地。

论文把下一波基础设施的战场也划出来了：图原生的能力基座，把模型、工具、技能、记忆、验证器连成统一的能力图；自演化图系统，让执行证据闭环地转成持久的结构改进；图原生的 Agent 操作系统，由共享运行时提供图调度、状态存储、事务、回滚、可观测性；本体工程作为横切的语义层；以及随之而来的隐私与治理问题。判断已经摆在桌面上了：单个智能体的天花板不在"笨"，而在组织方式；而组织方式一旦被画成图，它就能被调度、被优化、被自动发现，甚至自己长出新的样子。

想深入可以读原文：Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence（arXiv:2608.21156）

参考文献

1. Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence（arXiv preprint）：https://arxiv.org/abs/2608.21156
2. Awesome-Graph-Engineering（论文官方配套资源中心）：https://github.com/DEEP-JLU/Awesome-Graph-Engineering
3. Graph of Thoughts: Solving Elaborate Problems with Large Language Models：https://arxiv.org/abs/2308.09687
4. ReAct: Synergizing Reasoning and Acting in Language Models：https://arxiv.org/abs/2210.03629
5. MemGPT: Towards LLMs as Operating Systems：https://arxiv.org/abs/2310.08560
6. GPTSwarm: Language Agents as Optimizable Graphs：https://arxiv.org/abs/2402.16823
7. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework：https://arxiv.org/abs/2308.00352
8. DyLAN: A Dynamic LLM-Powered Agent Network for Task-Oriented Agent Collaboration：https://arxiv.org/abs/2310.02170
9. Automated Design of Agentic Systems (ADAS)：https://arxiv.org/abs/2408.08435
10. Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks：https://arxiv.org/abs/2411.04468