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把暂定的写入和已确认的信念提交区分开一旦某个已提交的状态被撤销会触发级联修复。这一整套机制其实很像银行的转账系统。你把钱转给别人这笔交易不会立刻生效系统会先检查你的账户余额够不够、对方账户是否存在、这笔操作有没有权限限制所有检查通过后才真正扣款到账。如果不这样做任何一笔中途失败的转账都可能让账目对不上整个银行系统的信任基础就崩了。智能体系统如果没有这套先验证再提交的机制一个智能体写错的中间结果可能直接污染另一个智能体正在依赖的共享状态而且事后根本查不出问题出在哪一步。故障定位要解决的问题是,一个错误可能在系统里传播了好几步最后暴露出来的症状和真正的病因完全不在一个地方。论文里举的例子是长时间运行的编程任务早期一个不起眼的小错误可能要到任务快结束时才彻底暴露这时候想回头找出问题根源已经非常困难。WhoWhen这项研究专门研究怎么把失败归因到具体的智能体和具体的步骤MAST把失败模式分成系统设计缺陷、智能体间协调失败、任务验证失败三大类。这种分类本身就说明一件事失败原因是多样的如果不做区分笼统地说系统出错了对修复毫无帮助。故障恢复则是在定位问题之后怎么在不丢弃有效工作成果的前提下继续执行。这里有个很实用的设计思路叫选择性修复只重新执行受影响的部分不必把整个任务推倒重来。MAGE这类系统会把执行过程表示成一棵层次化的状态树一旦定位到出错分支就能精确回滚到那个分支之前的有效状态,而不影响其他并行分支已经完成的工作。这就像修一栋楼里漏水的水管你不需要把整栋楼推倒重建只需要找到漏水的那一段管道切断它修好再接上其他楼层的电路、供暖系统完全不受影响。如果没有精确的状态划分出了问题就只能推倒重来代价太大了。系统会不会自己变得更聪明系统演化论文里专门讨论了一个更进一步的问题这套图结构能不能随着系统运行的经验自己变得更好这就是系统演化这一节要谈的内容。作者把它拆成三个维度。任务组织的演化让工作流和任务分解方式能根据历史表现调整智能体协调的演化让团队结构和通信模式随协作经验优化运行时状态管理的演化把执行历史提炼成可复用的经验同时保证不可靠的更新能被验证、撤销或绕过。QueenBee Planner这项工作把执行痕迹和评估结果提炼成可复用的设计规则供后续任务参考很像一个团队做完项目后写复盘文档把这次踩过的坑和摸索出的经验记录下来下次遇到类似情况直接调用不用从零试错。不过论文也提醒了一件事这种运行时调整要和持久性系统演化区分开。条件路由、临时的worker分配这些只是改变了单次执行的轨迹不代表系统组织结构本身发生了持久性的改变。真正的自我演化需要一整套从执行观察、结构性归因、图结构修改、验证、最终提交或回滚的闭环流程。这个要求其实很高目前大部分系统都还只停留在单次调整这个层次。未来往哪走本体工程论文的第五部分抛出了一个更远的问题如果图结构解决的是关系怎么组织那这些概念本身的含义有没有共识这个问题谁来管比如说什么算任务完成什么算充分的证据什么算有效状态不同的智能体如果对这些基本概念理解不一致即便图结构再清晰整个系统照样会出乱子。本体工程*指建立一套共享的、机器可解释的模型用来定义系统里的实体、关系和约束让不同组件对同一个概念有一致的理解。论文举了一个例子叫LAMP系统里面的Planner、Builder、Verifier三个角色通过统一的协议访问同一份领域本体而不是各自凭自己训练数据里学到的模糊理解去猜测某个概念的含义。这就像一个跨国公司的不同分部如果对季度业绩达标这个词的定义各说各话总部再怎么协调也没法把各地的报表汇总成一份有意义的报告。共同的定义是协作的地基。写在后面读完这篇综述最触动我的其实不是它提出了多少新概念而是它把一个大家平时含糊带过的问题逼着摊开来讲清楚了为什么多加几个智能体不等于系统变聪明。这个问题看起来简单但仔细想想其实和很多组织管理里的经验是相通的。一个团队人多不代表效率高关键是有没有清晰的分工、可靠的信息流通、以及出了问题能不能快速定位。论文把这套朴素的组织学常识翻译成了可以被工程实现的图结构这个翻译本身是有价值的。论文里还有一个细节我觉得值得单独说一说就是它反复强调状态记录和故障恢复的重要性甚至专门用了整整一节去谈怎么记录执行过程中发生的一切。这和大部分人对AI系统的直觉是相反的很多人以为智能体系统的核心竞争力在于模型多聪明、推理链多长但这篇论文提醒我们一个系统真正稳不稳往往取决于它有没有能力说清楚自己刚刚做了什么、为什么这么做、出错了能不能追溯回去。这让我想起软件工程里一句老话代码写得好不好往往不看它跑得多快而看它出问题时你能多快找到病灶。图工程要解决的核心问题本质上和这句话是一致的。至于图工程这套框架最终会不会成为构建下一代智能体系统的标准范式这个问题现在下结论还太早。但至少它提出了一个足够具体、足够可操作的问题当系统里有几十个智能体同时运转的时候你有没有一张图能说清楚谁在做什么、彼此依赖什么、出了问题能追溯到哪一步。这张图目前还没有人画出完整的版本。QAQ1图工程和普通的多智能体系统有什么区别A普通多智能体系统只是把多个智能体凑在一起工作但没有明确的组织结构。图工程用图结构把任务分解、智能体协调、运行时状态这三方面都显式表示出来让系统能被调度、优化和追溯而不只是简单堆叠智能体数量。Q2系统智能和个体智能有什么本质不同A个体智能指单个智能体通过工具和循环反思延伸出的持续执行能力局限于一个执行循环内。系统智能指多个异构组件被组织成一个协调整体能处理并行任务、专业分工和跨组件的状态一致性这是单个智能体架构无法做到的。Q3为什么智能体之间通信连接越多不一定越好A论文引用研究发现盲目增加智能体间的通信连接不能保证协作质量提升反而可能让错误信息传播得更快更广。因此像AgentPrune、AgentDropout这类方法专门研究如何剪除低价值通信连接把带宽留给真正有效的信息交换。