AI Agent的下一站：一文读懂Graph Engineering
当前，围绕自主 LLM Agent 的工程实践，已经逐渐形成了一套较为清晰的技术体系：
Prompt Engineering 激发模型能力；Context Engineering 组织信息访问；Harness Engineering 连接工具、记忆与外部资源；Loop Engineering 则通过规划、行动、观察和反馈让 Agent 能够持续执行任务。
然而，软件工程、科学发现、医疗决策和企业流程，往往同时涉及异构专业知识、相互依赖的子任务、可并行执行的分支、独立的验证环节，以及需要跨越较长时间持续维护的运行状态。将这些复杂性全部压缩进单一上下文和单一控制循环，难以有效应对任务本身的组织复杂性。
为应对这一结构性瓶颈，来自吉林大学、厦门大学等 15 个研究机构的学者介绍了“图工程”（Graph Engineering），一个将图结构作为构建下一代 Agent 系统的核心工程基础。
论文链接：https://arxiv.org/pdf/2608.21156
与以往主要优化个体交互或 Agent 层级行为的范式不同，Graph Engineering 构建了明确、动态且不断演化的图结构，用于表示任务、Agent 和系统状态。这些抽象为组织复杂目标、协调异构 Agent、建模系统动态以及实现可扩展的 Agent 演化提供了统一的基础。
在论文中，研究团队系统性地回顾了 Graph Engineering 在 LLM Agent 中的原理、方法论；同时还详细探讨了其在软件工程与 IT 运维、科学发现与实验室自动化、医疗保健与临床决策支持、企业流程与数字组织、通用数字 Agent 与个人自动化、社会与经济模拟、跨领域发现等领域的潜在应用。
从“个体智能”走向“系统智能”
在单个模型层面，预训练、后训练将知识、推理和决策能力编码进参数；Prompt Engineering 和 Context Engineering 再根据任务要求，要求模型应该做什么、可以使用哪些信息；进一步地，Harness Engineering 将模型接入工具、知识库、记忆、技能和执行环境，Loop Engineering 则把这些能力组织成一个持续运行的过程。
因此，一个能够自主完成任务的 Agent，可以被理解为由 LLM、Harness 和 Loop 共同构成的系统。Harness 决定 Agent 能够访问哪些资源、执行哪些操作；Loop 决定它如何在规划、行动、观察、验证和调整之间循环。
尽管个体智能（Individual Intelligence）已经取得了持续进展，但这一基本单元在调度并行且相互依赖的任务、整合异构能力以及维护运行时状态方面，仍然存在固有局限。这推动智能向下一阶段演进，即系统智能（System Intelligence），使得多个具备互补能力的 Agent 围绕共同目标形成一个自适应的整体。
Graph Engineering如何组织系统智能？
系统智能并非简单地聚合多个 Agent 及其他智能组件即可产生，其关键取决于如何对任务、组件与运行时状态之间的关系进行显式表示、约束与优化。
从本质上看，系统智能要求对任务、组件与运行时状态之间的关系进行系统化治理，而图（graph）为建模系统层面的关系提供了一种自然的结构。
首先，图可以通过目标分解、依赖关系建模和工作流细化来组织任务，将复杂目标转化为可调度、可执行的操作；其次，图可以通过表示操作拓扑与通信模式来协调智能组件，使异构组件能够实现有效协作；此外，图可以通过记录事件、依赖关系与状态转换来支持运行时状态管理，将散落在不同上下文与日志中的运行信息转化为可审计、可恢复的系统状态。
基于此，他们提出了 Graph Engineering，其核心思想是把原本隐藏在上下文和控制逻辑中的关系外显为可操作的图结构，划分为三个相互连接的层面：任务组织（Task Organization）、智能体协调（Agent Coordination）和运行时状态管理（Runtime State Management）。
1.Task Organization：把复杂目标转化为可执行结构
Task Organization 负责明确系统要完成什么，以及这些工作应当如何组织。面对包含前后依赖、并行分支、验证环节和动态调整的复杂任务，仅靠 Agent 上下文很难维持清晰的全局结构。Graph Engineering 将任务分解与执行流程显式表示为图，使其成为可调度、可优化、可修改的系统结构。
这一过程包含两个紧密关联的部分。其中，Goal Decomposition 将高层目标展开为子目标图：节点表示子任务或中间目标，边表示先后顺序、数据依赖或逻辑关系。随后，Workflow Optimization 将语义子目标进一步编译为由 LLM、专业 Agent、检索模块、工具、记忆操作、聚合器和验证器组成的可执行图。
因此，Task Organization 不是一次性制定计划，而是在目标分解、流程编译和执行反馈之间持续迭代：既决定需要完成哪些工作，也决定这些工作如何被实际执行。
2.Agent Coordination：让合适的Agent以合适的方式协作
Agent Coordination 负责明确谁来完成工作、责任如何划分，以及信息如何在系统中流动。多个 Agent 的简单叠加并不会自动产生 System Intelligence。系统还需要了解不同 Agent 的能力与权限，建立清晰的协作关系，并根据任务状态调整交互方式。
Graph Engineering 首先将 Agent、技能、工具、模型和资源表示为节点，用带类型的边记录能力归属、资源访问、权限和可靠性。这样，系统可以根据任务需求分配合适的 Agent，并在能力或资源发生变化时寻找替代者。随后，系统需要通过团队图规定任务归属、委派路径、输出交接和审查责任。不同结构分别适合顺序执行、专业路由和并行协作，但也会带来不同的协调与计算成本。
通信关系则描述执行过程中谁需要与谁交换信息，以及反馈如何影响后续行动。更多连接不一定意味着更好协作，冗余通信还可能增加成本或放大错误。对于高风险任务，人类也可以作为图中的显式参与者，承担澄清、审批、纠错和接管职责。
3.Runtime State Management：让执行过程可追踪、可诊断、可恢复
多 Agent 执行会产生分散的任务进度、共享事实、角色绑定、资源变化和外部影响。如果这些信息只保存在各自的上下文或日志中，Agent 可能基于不一致的状态行动，故障也难以定位和恢复。
Runtime State Management 首先需要记录每次状态变化的内容、来源和版本，并对共享状态更新进行约束。
当任务出现异常时，系统还需要根据执行记录、依赖关系和外部证据定位最早的无效状态，并判断哪些后续步骤受到影响。这里的图关系可以缩小排查范围，但不能直接证明因果关系。
完成故障定位后，系统应选择明确的恢复边界，在保留有效工作的同时修复受影响部分。恢复方式可以包括回放计算、撤销无效状态、切换执行分支，或补偿无法直接回滚的外部操作。由此，状态记录、故障定位和失败恢复共同构成一个可审计的运行循环，使系统能够从经过验证的状态继续执行。
当然，除了上述三点，在长期运行的开放环境中，系统也应该具备从非固定结构开始的能力。执行结果可以揭示哪些任务分解有效、哪些通信关系成本过高、哪些 Agent 更适合承担特定角色，以及哪些状态更新容易引发连锁故障。因此，System Evolution 被用来改进任务组织，调整 Agent 团队与通信模式，以及把执行历史沉淀为可复用经验。
然而，研究团队区分了“运行时适应”和“持久化系统演化”。一次执行中的临时路由、恢复或任务重分配，并不意味着系统在后续任务中已经改变了组织方式。真正的自演化图系统，需要完成从执行、观察、结构归因，到图修改、验证，再到提交或回滚的完整过程。
Graph Engineering的挑战与机遇
研究团队表示，当前的 Graph Engineering 依然面临以下问题：
1.图原生能力底座
当前的记忆库、技能库、工具注册表和模型服务通常彼此分离。随着能力数量增长，系统选择某项能力时，不仅要看它“能不能做”，还要考虑它依赖什么、能否被替代、如何组合、需要哪些权限，以及在当前运行条件下是否适用。
他们提出构建统一的能力图，把模型、工具、技能、记忆、数据源、验证器和执行环境表示为带类型的节点，用边描述依赖、兼容、组合、替代、授权、成本和可靠性。更重要的是，能力图需要与任务图、Agent 图和状态图连接起来：任务分解应暴露能力需求，Agent 分配应考虑可用能力子图，执行结果还应更新能力的可靠性与适用范围。
2.自演化图系统
图结构正在成为可优化变量，但临时改路由与真正的系统进化仍有距离。未来系统需要回答：哪条任务依赖、哪种 Agent 关系或哪项能力分配导致了成功或失败，这种结构变化是否能迁移到其他任务，以及它是否会影响其他图中的权限、通信和运行状态。
因此，结构演化必须配套来源记录、版本控制、验证、回放和回滚。目标不是让系统无限制地自我修改，而是让它能够积累组织经验，同时阻止不可靠的结构变化跨任务传播。
3.图原生Agent操作系统
现有技术栈将模型服务、Harness、工作流引擎、记忆系统、多 Agent 框架和状态存储拆分开来，各自使用不同的任务、工具、消息、事件和状态抽象。MCP 改善了外部能力访问，LangGraph 提供了显式工作流和状态表示，AIOS 则从操作系统角度提供调度、上下文、记忆、存储、工具和访问控制服务，但它们还没有形成一个组织完整 Agent 系统的共同结构底座。
研究团队设想的“图原生 Agent 操作系统”会把任务、Agent、能力和运行状态作为一等系统对象，并通过类型化、版本化的图来表示。共享运行时可以提供图调度、能力发现、状态存储、事件与来源记录、结构化事务、权限执行、检查点、回放、回滚和图级可观测性。
4.隐私与伦理
系统智能会协调更多 Agent、工具、记忆和共享状态，也会扩大隐私与伦理风险。敏感信息可能在多个组件间复制、沿工作流传播，并长期保存在运行轨迹中。分布式决策还会让偏见、错误推理或对抗性输入在组件间放大，导致责任归属更加困难。
因此，长期运行的 Agent 系统需要隐私保护的状态管理、范围明确的权限、带来源的日志记录，以及有实质作用的人类监督。自治能力不能以牺牲隐私、公平性和可控性为代价。
Graph Engineering之后是什么？
Graph Engineering 让任务、Agent 和状态之间的关系变得明确，但“明确表示”不等于“统一理解”。不同组件可能对任务完成、有效证据、合法状态和授权行动有不同定义。
Ontology Engineering 试图建立一套机器可解释的共享模型，规定系统中有哪些实体、实体之间的关系意味着什么、哪些约束必须成立，以及哪些结论可以从已有信息中推导出来。它不是简单给图添加语义标签，而是为整个系统建立共同概念基础。
研究团队建议采用分层、模块化的本体结构。核心本体定义不同系统都需要的基本概念，专业模块再描述目标与价值、Agent 与能力、观察与证据、行动与状态、评估标准等内容，领域本体则服务于具体应用。这样可以形成对 Goals、Agents、Capabilities、Evidence、Policies、States 和 Outcomes 的一致定义，而不要求所有系统使用一个庞大且不可调整的单一模型。
在“目标设定与价值对齐”方面，本体可以记录目标的来源、优先级、授权范围、完成标准和约束，帮助系统发现目标冲突、识别未经授权的修改，并判断完成目标需要哪些证据。但本体本身不能决定系统应该采用什么价值观，它只能让目标和规范约束变得明确、可检查。
在“共享语义与世界Grounding”方面，本体还需要连接工具输出、环境观察、时间戳、来源和验证结果。语义一致并不自动意味着事实正确。OntoCodex、CoA-Text2OWL 等工作展示了多 Agent 参与本体构建和扩展的可能性，但新概念和新关系仍需要来源核验、结构约束和人类监督。
Ontology Engineering 也可以帮助测量 System Intelligence。通过统一任务成功、失败、Agent 贡献、恢复、状态一致性和运行成本的定义，系统之间的执行轨迹才更容易比较。未来的评估还应区分：性能提升究竟来自更强的基础模型，还是来自更高效的任务组织、能力分配、协作机制和状态管理。
本文来自微信公众号 “学术头条”（ID：SciTouTiao），作者：学术君，36氪经授权发布。
