当LLM智能体多到一支球队还配不上组织时：关于图工程的生存指南

2023年前后，很多人做了一个几乎一样的实验：给一个大语言模型配上工具、内存、循环反思，让它自己规划、自己执行、自己检查错误。结果发现，单个智能体确实能完成不少任务，但一旦任务变得复杂，比如需要同时处理好几个互相依赖的子任务，或者需要专业分工加交叉验证，这个单打独斗的智能体就开始露怯。

它会把本该并行处理的工作硬生生排成一条队,把不同性质的判断塞进同一个上下文窗口,把早期的一个小错误一路带到任务结束都没发现。

这不是模型不够聪明的问题。这是架构本身的问题。

这篇发表于2026年8月的综述论文《Graph Engineering in the Era of LLM Agents》,由吉林大学、厦门大学、香港理工大学等多所机构的三十多位研究者联合撰写,提出了一个核心判断：当任务复杂到一定程度，问题就不再是"这个模型够不够聪明"，而是"这个系统有没有把工作组织好"。作者们把后者命名为系统智能，并提出了一套叫图工程的方法论，用来把系统智能从口号变成可操作的工程实践。

一个人干不完的活，为什么加人也未必管用

先说清楚问题出在哪。

论文里举了一个很实在的例子：软件故障诊断。日志分析、故障复现、代码审查，这三件事其实可以同时进行，彼此独立；但修复和测试必须等前三者的结果出来才能开始。如果让一个智能体单独完成这整套流程，它只能按顺序一件件做，前面三个并行任务的效率优势完全浪费掉了。更麻烦的是，如果日志分析阶段出了一个小错误，这个错误会一路传导到修复阶段，而且很难说清楚到底是哪一步出的问题。

单个智能体的执行循环*：论文里把一个独立智能体描述成"模型加外部工具箱，再套一个循环"，公式写作 Loop(LLM + Harness)。这里的 Harness 指的是智能体调用的工具、记忆、知识库这些外部资源的集合，Loop 则是不断进行"计划、行动、观察、验证、调整"的循环过程。

这就好比让一个人同时当侦探、法医和审判官破一桩案子。侦探去现场取证、法医做尸检、审判官下判决，这三件事理论上侦探和法医可以同时开工，只有审判环节必须等前两者都完成。但如果只有一个人，他只能先勘察现场，再去做尸检,最后才轮到下判决,原本可以并行的工作被迫排成了一条队。如果侦探在勘察现场时看错了一个细节，这个错误会一路带到法医的报告里，最后审判时才发现，已经浪费了大量时间去回溯到底哪一步出了问题。

那多找几个智能体来分工不就行了？

论文里明确反驳了这个直觉。系统智能不是把智能体数量堆上去就能获得的能力。一堆能力很强的智能体凑在一起，如果没有清晰的责任划分、没有协调机制、没有统一的状态管理，照样是一盘散沙。作者们打了个比方：多智能体系统可能"包含多个能干的智能体，但仍然缺乏有效的工作组织、明确的职责边界、协调机制或一致的状态管理"。

这就像临时拼凑一支足球队，队员个个都是国家队水平的射手，但没有教练分配位置，没有人喊战术，球场上大家各自带球突破，结果反而互相干扰，进球效率还不如一支普通球队。真正决定比赛结果的从来不只是球员个人能力，而是整个球队有没有形成合力。

从模型智能到个体智能，再到系统智能

论文把整个演进过程拆成了三层，理解这三层是理解全文的关键。

第一层叫模型智能*：指的是一个大语言模型在给定上下文里，靠自己的知识和推理能力解决问题的水平。这一层的进步主要来自两条路径，一条是预训练和后训练，把知识和推理能力刻进模型参数里；另一条是提示工程和上下文工程，在推理阶段引导模型更好地发挥这些能力。

举个例子，GPT-3、LLaMA这些基础模型的能力提升，靠的是海量数据加合理的架构设计。DeepSeek-R1则展示了用可验证的奖励信号做强化学习,可以直接激发模型的深度推理能力,这条路径后来被称为"agentic RL",逐渐扩展到搜索、工具调用等更复杂的场景。

但模型智能有个天生的局限,它被困在一次推理过程里,没法维持持久状态,也没法真正对外部世界采取行动。

于是就有了第二层，个体智能*：指单个智能体通过外接工具、记忆、执行环境，再配合持续的循环控制，把模型的推理能力延伸成可以长期执行任务、能与环境交互、能自主追求目标的能力。

论文里区分了两种工程手段。Harness Engineering负责给模型接上外部能力，比如工具调用（连上API、执行代码）、记忆管理（记住之前发生的事）、技能组合（把成功的操作流程打包成可复用的技能）。Loop Engineering则负责组织这些能力，形成一个持续的执行闭环，包括感知、计划、行动、观察反馈、状态更新这几个环节不断循环。

这两者合起来，才能让一个语言模型从"回答一个问题"变成"持续追求一个目标"。

第三层就是本文的核心，系统智能*：指的是一个智能系统组织复杂目标、协调异构组件、在整个任务生命周期里维持一致运行状态的能力。它不是靠加模型或者加智能体数量堆出来的，而是靠明确的组织结构撑起来的。

三个核心问题，一套解决思路

论文提出，图工程要解决三个相互关联的问题。

第一个是任务组织，回答"要做什么，怎么安排"。

第二个是智能体协调，回答"谁来做，怎么协作"。

第三个是运行时状态管理，回答"系统现在处于什么状态，出了问题怎么办"。

这三者被称为图工程的三大支柱，接下来一个个拆开讲。

任务组织：把一句模糊的目标变成一张可调度的图

任务组织的第一步叫目标分解。

简单说,就是把一个笼统的用户需求，比如"帮我诊断这个服务为什么崩溃了"，拆解成一系列有依赖关系的子任务：分析日志、复现故障、检查代码变更、定位故障点、修复代码、跑测试、确认稳定性。这些子任务之间有的必须按顺序来，有的可以并行处理。

早期的代表性工作是HuggingGPT，它把多模态用户请求拆解成子任务，再路由给不同的专业模型处理。稍后的LLMCompiler把函数调用计划编译成一个数据流图，一旦某个节点的上游依赖满足，就可以立刻并行调度执行，不用等前面所有步骤都跑完。

这个思路后来进一步演化，TDAG 和 Flow 这类系统开始支持动态调整任务分解方式，允许根据执行过程中出现的新信息，实时重新规划剩余的任务结构，而不是一开始就锁死整张任务图。

有了任务分解，还要有实际可执行的操作单元，这就是工作流优化的工作。

工作流优化把语义层面的子目标编译成具体可执行的计算单元：调用哪个模型、用哪个工具、调用哪个验证器。GPTSwarm把整个智能体系统表示成一个可优化的计算图，节点行为和连接方式都可以被调整；AFlow更进一步，用大语言模型引导搜索来自动生成工作流代码，让"工作流应该长什么样"这个问题本身变成一个可以被优化的目标，而不是靠人工设计。

论文特别提到一个反例，很有警示意义。FlowSteer这项研究发现，操纵规划信号可以引导恶意的重新规划和依赖关系构造，把执行流程引向不理想甚至有害的路径。这说明，可以动态调整的工作流固然灵活，但如果这个"调整依据"本身可以被伪造或污染，整个系统的可靠性就会崩塌。灵活性和安全性,从一开始就是一对需要权衡的矛盾。

智能体协调：谁该做什么，怎么说话

智能体协调分三个层次：能力建模、团队组织、通信管理。

能力建模解决的是,系统怎么知道每个智能体擅长什么、能访问什么资源、可信度如何。这一层用图结构把智能体、技能、工具、模型这些要素连接起来，边上标注的是能力归属、资源访问权限、可信度这些关系。DyLAN会估计候选智能体对当前任务的贡献，保留更有用的那些；MasRouter则学习根据任务难度和成本，选择合适的协作模式、角色分工和底层模型。

团队组织决定的是具体的分工结构。

链式结构*：像流水线一样，一个角色的输出直接成为下一个角色的输入。MetaGPT把软件开发流程组织成一条标准作业程序驱动的装配线，需求分析、架构设计、编码、测试各司其职。

路由结构*：由一个协调者根据任务性质，把不同的工作分发给合适的专家智能体。Magentic-One用一个orchestrator（协调器）负责规划、委派、监控进度，出问题就重新规划。

扇出扇入结构*：把任务分发给多个智能体并行处理，再把结果汇总整合。Mixture-of-Agents用分层结构，多个智能体并行生成候选答案，下一层的智能体负责整合。

这三种结构可以组合使用，也可以随任务动态调整。像Puppeteer这样的系统，能够根据当前任务状态动态选择和排列智能体；AgentNet干脆去掉中心控制器，让智能体根据本地专业知识和上下文自行调整连接方式。

通信管理处理的是执行过程中信息怎么流动、错误怎么被发现和修正。这里有个特别值得说的发现：并不是连接越多越好。

论文引用了一项研究，发现盲目增加智能体之间的通信连接，并不能保证协作质量提升，反而可能让错误信息传播得更快更广。这就好比一个部门开会，人越多不代表决策越好，反而可能因为信息传递链条太长，一个错误的判断在传递过程中被反复强化，最后没人再去质疑它。于是AgentPrune、AgentDropout这类方法开始研究怎么剪掉那些低价值的通信连接，把带宽留给真正有用的信息交换。

运行时状态管理：记住发生了什么，出错了知道去哪修

这一部分是我认为整篇论文里最容易被低估、但实际上最关键的部分。

论文提出了一个很朴素但极其重要的观点：任务组织和智能体协调只解决了"应该发生什么"，但不解决"实际发生了什么"。

如果没有一套机制把执行过程中的每一个状态变化都记录下来，系统就没法维持一致的运行视图，出了问题也没法诊断，更别提恢复。这一部分被拆成三块：状态记录、故障定位、故障恢复。

状态记录负责把散落在不同智能体、不同工具里的信息，统一成一份可查询、可追溯的记录。论文提到几个值得注意的机制。Magentic-One用协调者维护的Task和Progress Ledger（任务与进度台账）把共享执行进度显式化。PatchBoard在提交任何修改前，会先检查是否符合模式定义、角色权限、运行时约束，只有验证通过才允许提交。MemTX把"暂定的写入"和"已确认的信念提交"区分开，一旦某个已提交的状态被撤销，会触发级联修复。

这一整套机制其实很像银行的转账系统。你把钱转给别人，这笔交易不会立刻生效，系统会先检查你的账户余额够不够、对方账户是否存在、这笔操作有没有权限限制，所有检查通过后才真正扣款到账。如果不这样做，任何一笔中途失败的转账都可能让账目对不上，整个银行系统的信任基础就崩了。智能体系统如果没有这套"先验证再提交"的机制，一个智能体写错的中间结果，可能直接污染另一个智能体正在依赖的共享状态，而且事后根本查不出问题出在哪一步。

故障定位要解决的问题是,一个错误可能在系统里传播了好几步，最后暴露出来的症状和真正的病因完全不在一个地方。论文里举的例子是长时间运行的编程任务，早期一个不起眼的小错误，可能要到任务快结束时才彻底暴露，这时候想回头找出问题根源已经非常困难。

Who&When这项研究专门研究怎么把失败归因到具体的智能体和具体的步骤；MAST把失败模式分成系统设计缺陷、智能体间协调失败、任务验证失败三大类。这种分类本身就说明一件事：失败原因是多样的，如果不做区分，笼统地说"系统出错了"对修复毫无帮助。

故障恢复则是在定位问题之后，怎么在不丢弃有效工作成果的前提下继续执行。这里有个很实用的设计思路，叫选择性修复，只重新执行受影响的部分，不必把整个任务推倒重来。MAGE这类系统会把执行过程表示成一棵层次化的状态树，一旦定位到出错分支，就能精确回滚到那个分支之前的有效状态,而不影响其他并行分支已经完成的工作。

这就像修一栋楼里漏水的水管，你不需要把整栋楼推倒重建，只需要找到漏水的那一段管道，切断它，修好再接上，其他楼层的电路、供暖系统完全不受影响。如果没有精确的状态划分，出了问题就只能推倒重来，代价太大了。

系统会不会自己变得更聪明：系统演化

论文里专门讨论了一个更进一步的问题：这套图结构能不能随着系统运行的经验，自己变得更好？

这就是系统演化这一节要谈的内容。作者把它拆成三个维度。任务组织的演化，让工作流和任务分解方式能根据历史表现调整；智能体协调的演化，让团队结构和通信模式随协作经验优化；运行时状态管理的演化，把执行历史提炼成可复用的经验，同时保证不可靠的更新能被验证、撤销或绕过。

QueenBee Planner这项工作，把执行痕迹和评估结果提炼成可复用的设计规则，供后续任务参考，很像一个团队做完项目后写复盘文档，把这次踩过的坑和摸索出的经验记录下来，下次遇到类似情况直接调用，不用从零试错。

不过论文也提醒了一件事，这种"运行时调整"要和"持久性系统演化"区分开。条件路由、临时的worker分配，这些只是改变了单次执行的轨迹，不代表系统组织结构本身发生了持久性的改变。真正的自我演化，需要一整套从执行观察、结构性归因、图结构修改、验证、最终提交或回滚的闭环流程。这个要求其实很高，目前大部分系统都还只停留在"单次调整"这个层次。

未来往哪走：本体工程

论文的第五部分抛出了一个更远的问题：如果图结构解决的是"关系怎么组织"，那"这些概念本身的含义有没有共识"这个问题谁来管？

比如说，什么算"任务完成"，什么算"充分的证据"，什么算"有效状态"，不同的智能体如果对这些基本概念理解不一致，即便图结构再清晰，整个系统照样会出乱子。

本体工程*：指建立一套共享的、机器可解释的模型，用来定义系统里的实体、关系和约束，让不同组件对同一个概念有一致的理解。

论文举了一个例子叫LAMP系统，里面的Planner、Builder、Verifier三个角色通过统一的协议访问同一份领域本体，而不是各自凭自己训练数据里学到的模糊理解去猜测某个概念的含义。这就像一个跨国公司的不同分部，如果对"季度业绩达标"这个词的定义各说各话，总部再怎么协调也没法把各地的报表汇总成一份有意义的报告。共同的定义，是协作的地基。

写在后面

读完这篇综述，最触动我的其实不是它提出了多少新概念，而是它把一个大家平时含糊带过的问题，逼着摊开来讲清楚了：为什么多加几个智能体不等于系统变聪明。

这个问题看起来简单，但仔细想想，其实和很多组织管理里的经验是相通的。一个团队人多不代表效率高，关键是有没有清晰的分工、可靠的信息流通、以及出了问题能不能快速定位。论文把这套朴素的组织学常识，翻译成了可以被工程实现的图结构，这个翻译本身是有价值的。

论文里还有一个细节我觉得值得单独说一说，就是它反复强调状态记录和故障恢复的重要性，甚至专门用了整整一节去谈"怎么记录执行过程中发生的一切"。这和大部分人对AI系统的直觉是相反的，很多人以为智能体系统的核心竞争力在于模型多聪明、推理链多长，但这篇论文提醒我们，一个系统真正稳不稳，往往取决于它有没有能力说清楚自己"刚刚做了什么、为什么这么做、出错了能不能追溯回去"。

这让我想起软件工程里一句老话，代码写得好不好，往往不看它跑得多快，而看它出问题时你能多快找到病灶。图工程要解决的核心问题，本质上和这句话是一致的。

至于图工程这套框架最终会不会成为构建下一代智能体系统的标准范式，这个问题现在下结论还太早。但至少它提出了一个足够具体、足够可操作的问题：当系统里有几十个智能体同时运转的时候，你有没有一张图能说清楚谁在做什么、彼此依赖什么、出了问题能追溯到哪一步。

这张图目前还没有人画出完整的版本。

Q&A

Q1：图工程和普通的多智能体系统有什么区别？

A：普通多智能体系统只是把多个智能体凑在一起工作，但没有明确的组织结构。图工程用图结构把任务分解、智能体协调、运行时状态这三方面都显式表示出来，让系统能被调度、优化和追溯，而不只是简单堆叠智能体数量。

Q2：系统智能和个体智能有什么本质不同？

A：个体智能指单个智能体通过工具和循环反思延伸出的持续执行能力，局限于一个执行循环内。系统智能指多个异构组件被组织成一个协调整体，能处理并行任务、专业分工和跨组件的状态一致性，这是单个智能体架构无法做到的。

Q3：为什么智能体之间通信连接越多不一定越好？

A：论文引用研究发现，盲目增加智能体间的通信连接不能保证协作质量提升，反而可能让错误信息传播得更快更广。因此像AgentPrune、AgentDropout这类方法专门研究如何剪除低价值通信连接，把带宽留给真正有效的信息交换。