从提示词工程到上下文工程，再到工具编排和循环反思，LLM 智能体的发展一直在扩大单个模型的行动能力。但当任务变得复杂、周期变长，问题可能已经不再是“如何让一个智能体更强”，而是“如何让多个智能组件形成一个能共同工作的系统”。Hugging Face Daily Papers 收录的这篇论文提出，下一阶段的关键范式可能是 Graph Engineering，即图工程。
单体能力的架构边界
论文将近年来的智能体实践概括为几类工程范式：Prompt Engineering 用于激发模型能力，Context Engineering 负责管理信息访问，Harness Engineering 组织外部工具与资源，Loop Engineering 则支持持续反思和自我改进。这些方法主要围绕单个模型或单个智能体展开，目标是改善交互、信息利用和执行过程。
但复杂任务往往包含异质专业能力、相互依赖的子任务、并行执行、独立验证以及需要长期保存的状态。这些要求超出了单个智能体的组织能力。论文特别强调，单纯增加一个智能体的能力或上下文，并不能解决这种架构上的不匹配。此时，智能必须分布在多个专门化智能体之间，并在系统层面被重新组织。
从多智能体到系统智能
论文将这种能力称为 System Intelligence，即一个智能体系统把多个智能组件组织、协调成统一且可适应整体，并围绕共同目标推进工作的能力。这里的重点不只是增加智能体数量，而是建立明确的工作结构，协调不同类型的智能体，并维护不断变化的执行状态。
Graph Engineering 的核心设想，是构建显式、动态、持续演化的图结构，用来表示任务、智能体以及系统状态。相比主要优化单次交互或单个智能体行为的既有范式，图工程把关注点提升到系统组织层面。它试图回答的不只是“哪个模型来完成任务”，还包括任务如何拆分、组件如何连接、执行如何推进，以及状态如何在过程中被保留和更新。材料并未给出具体实现、评测结果或适用任务的量化结论，因此这些主张仍应理解为一种架构方向。
我的判断
这篇论文的价值，在于把多智能体系统中的核心难题从“模型能力不足”转向“组织能力不足”。对于需要专业分工、并行处理、交叉验证和长期状态管理的任务，显式图结构确实提供了比线性调用链更值得研究的抽象。不过，图工程并不自动带来更好的结果：系统还需要解决任务划分、协调开销、状态一致性和错误传播等问题。当前材料没有展示其具体机制与实验验证，因此更适合作为理解下一代智能体架构的概念框架，而不是已经被充分证明的通用方案。