一篇综述想回答的问题
arXiv 上的一篇综述《Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence》（arXiv:2608.21156v2，作者 Yuyuan Feng 等）提出了一个颇具概括力的判断：智能体工程已经走过提示词工程（Prompt Engineering）、上下文工程（Context Engineering）、Harness 工程（Harness Engineering）与循环工程（Loop Engineering），正在进入以显式图结构组织多智能体的「图工程」（Graph Engineering）阶段。
这个判断之所以值得关注，是因为它把过去两年散落的各种实践收拢到了一条演进线上，并给出了一个清晰的因果：当任务变复杂，瓶颈就从「单个智能体的能力」转移到「多个智能组件如何在长周期、并行、有依赖的任务中协作，并完成独立验证与持久状态管理」。
三层智能：模型、个体、系统
综述把智能划分为三层。模型智能（Model Intelligence）指预训练、后训练与提示词、上下文工程；个体智能（Individual Intelligence）在此基础上增加了 Harness（工具、记忆、技能、执行环境）与 Loop（感知—推理—行动—反馈—状态更新），并被形式化表达为「Loop(基础模型, Harness; 运行时状态)」；系统智能（System Intelligence）则通过显式图结构组织多个智能体，也就是图工程。
这个划分的价值在于责任清晰：模型智能解决「想得对不对」，个体智能解决「单个智能体干得稳不稳」，系统智能解决「一群智能体怎么不打架」。三者是叠加关系，不是替代关系。这也解释了一个常见困惑——为什么换了更强的模型，多智能体系统的表现并没有同步提升：因为瓶颈可能根本不在模型层。
任务组织：把计划从上下文里搬出来
综述观察到的一个结构性变化，是计划的外置化。过去，智能体把计划保存在上下文里，模型自己记着「接下来做什么」；现在，越来越多系统把计划外化为动态图：节点是子任务，边表达依赖、顺序、并发与验证约束。
综述列举了一批代表工作。LLMCompiler 把函数调用计划编译成数据流 DAG，就绪节点并行执行；Plan-over-Graph 直接从任务依赖图生成并行智能体调度；TDAG 与 Flow 支持运行时修改图结构，包括拆分任务、调整依赖、根据中间结果生成新智能体；GPTSwarm、ADAS、AutoFlow、AFlow 把智能体工作流当作搜索或优化对象；DyFlow、EvoFlow、QualityFlow 则用运行时反馈继续执行、澄清、调试、回滚或重写计划。综述把最终形态概括为一种混合模式：模型提出或修改结构，运行时负责约束、调度、验证与记录。
这个转变的工程意义很大。计划一旦外化为图，就变得可检查、可版本化、可回放——而藏在上下文里的计划，既看不见也无法审计。
运行时状态：不只是「记忆」
综述强调，状态记录必须捕获每一次转换的证据、来源与版本，而不只是存一段「记忆」。它列举了几种做法：Magentic-One 维护 Task Ledger 与 Progress Ledger；Graph of States 使用结构化信念状态、因果图与状态机约束；PatchBoard 在提交前对智能体生成的补丁做 schema、角色权限与运行时不变量的校验；MemTX 区分「试探性写入」与「事务性信念提交」，保留来源与修复语义。
由此综述提炼出一个关键概念：提议—验证—提交（proposal–validation–commit）边界。被观察到或提议的变更，必须经过验证才能成为权威状态。并发场景还需要隔离、因果序与冲突消解；只追加的历史与事件溯源（event sourcing）则让系统能够重建、回放与分支。综述也坦言，统一的图原生事务实现仍是开放问题。
故障定位与恢复：错误往往离源头很远
多智能体系统的一个典型困境是：错误出现的位置与产生的原因相隔很远。综述给出的对策是保留执行者、转换、依赖与验证证据，以便推断根因。它提到的工具包括 MAGE（用层级状态树定位故障分支）、Who & When（把失败归因到具体智能体与步骤）、MAST（把失败分为系统设计、智能体协作、任务验证三类）、TraceElephant（纳入执行轨迹、中间上下文与完整输入）。
恢复比定位更难，因为需要确定「恢复边界」：哪些状态要撤销、哪些内部计算要重放、哪些外部副作用需要补偿——外部副作用往往是无法回滚的。综述提到的支撑机制包括事件溯源、AgentGit、Shepherd（支持重放、回滚、分支）、DART（恢复到语义有效的边界）、SagaLLM 与 RAC（把检查点与补偿结合）、Atomix（协调可逆与不可逆的外部操作）。它还指出一个容易被忽略的差别：恢复之后，模型可能需要重新规划后续任务，而不是机械地从断点继续执行。
协作：走向一层「控制平面」
综述把协作拆成能力建模、团队组织与通信三部分。能力建模把技能、资源、模型、权限、可靠性与任务匹配度显式表达为带类型的图节点与边（Agent、Skill、Tool、Model），从而实现「能力感知路由」。代表工作有 DyLAN（估计候选贡献度）、MasRouter（按难度与成本选择协作模式、角色与模型）、SkillGraph（用技能关系引导通信拓扑）、MaAS（在智能体超级网中搜索多智能体结构）。
团队组织则归纳出四种模式：链式（MetaGPT、ChatDev）、编排器式（Magentic-One）、并行聚合（Mixture-of-Agents、MacNet）、动态重构（Puppeteer、AgentNet）。综述提醒，通信图需要在信息价值、调用成本与错误传播风险之间取得平衡——连得越多不等于越好，因为错误也会沿着边扩散。
最后，综述提出了「图原生智能体操作系统」的构想：把任务、智能体、能力与运行时状态提升为用带类型、带版本的图统一表达的一等对象，并配套图调度、能力发现、状态存储、事件与来源日志、结构事务、权限执行、检查点与回滚、图级可观测性等共享运行时服务。它把 MCP（外部能力接入）、LangGraph（显式工作流与状态）、AIOS（操作系统级调度、上下文、记忆、存储、工具与访问控制）视为先行者，同时指出它们尚缺少一套统一的结构化底座。
中立思辨
需要理性看待这篇综述。其一，它是综述而非实证研究，梳理的框架与机制来自不同论文，彼此之间的可比性有限，不能简单理解为「越靠后的阶段越先进」。其二，文中列举的大量系统多数在学术或小规模环境中验证，在生产环境下的稳定性、成本与运维负担缺少统一数据。其三，图工程并非万能。当任务短、步骤少、依赖简单时，显式建图会带来不必要的复杂度，反而增加调试成本。其四，能力建模依赖对技能与权限的显式声明，这对组织治理水平有要求，声明不准会让路由失效。其五，事务性状态管理在分布式环境下的成本不容忽视，综述也承认统一实现仍是开放问题。其六，把「操作系统」作为终局形态是一种有启发性的框架，但也可能过度拔高——智能体系统的分层方式未必会复制传统操作系统的演化路径。其七，MCP 与 LangGraph 等先行者仍在快速演进，综述对其「缺少统一底座」的判断会随时间变化。
趋势研判
短期，最可能被广泛采纳的是「计划外化为 DAG」与「提议—验证—提交边界」这两条原则，因为它们直接解决了可审计与可回放问题，落地成本相对可控；中期，能力建模与运行时状态管理可能从研究概念沉淀为框架的标准组件，团队选型时会开始关心「这个框架的状态是否可回放、权限是否可声明」；长期，如果图原生运行时真的成型，智能体系统的评价标准会从「单任务成功率」扩展到「故障可定位性、恢复正确性与并发安全性」。
对工程团队来说，这篇综述最实用的一点不是某个具体框架，而是它提供了一张检查清单：你的计划在哪里、状态存在哪里、每次变更是否经过验证、失败能否定位到具体步骤、恢复边界是否明确。能回答这五个问题的系统，才有资格谈规模化。