青蛙小白

Graph Engineering

Graph Engineering 是 2026 年 7 月 AI Agent 社区快速扩散的新兴说法,尚无公认定义、标准架构或能证明其必然优于单循环的比较基准。中文社区也还没有稳定译名,因此本词条保留英文名。

当前讨论至少混合了两种相关但不同的含义:

  1. 显式工作流图:把 Agent、确定性函数、工具、评估器和人类视为节点,用边表达路由、权限、重试、并行、交接与停止,并让结构化状态在节点间流动。
  2. 改进循环之图:Carlos E. Perez 在《From Loop Engineering to Graph Engineering?》中采用的含义。每个节点本身是一个优化、监控、审计或治理循环;设计重点是哪些循环向谁提供信号、谁监督谁、谁能否决谁。

两者都把关注点从单个 Agent 的内部行为移到系统级关系,但不能直接画等号。本词条重点记录第二种含义,并把第一种作为术语边界保留。

为什么单个循环会失效

一个最小改进循环会选择变量和目标,测量差距,采取行动,再重复。这种结构简单有效,却无法从内部解决四类问题:

单循环失效结构原因图上的补偿机制
Goodhart’s Law(古德哈特定律)优化器只看代理指标,可能靠背叛指标原意的方式获胜给主指标配独立反指标,由监督循环检查廉价取胜路径
向上盲区循环能追目标,却不能判断目标本身是否正确由更慢的治理循环拥有和复审下层目标
循环冲突各循环局部正确,却优化互相矛盾的目标设置拥有取舍权和否决权的仲裁节点
测量衰减传感器、数据管道和指标定义会漂移,仪表盘仍可能保持绿色用独立审计循环定期验证指标是否仍接触真实世界

这里的核心不是“增加更多 Agent”,而是让边承担可靠性:边要明确证据从哪里来、谁可以修改目标、哪个检查能阻断发布,以及不同速度的循环如何避免互相震荡。

一个改进循环之图

成熟的模型发布流程已经具备这种形状:训练循环提出候选模型;champion-challenger 检查候选是否真的胜过线上基线;漂移监控观察部署后的输入与结果;回滚机制在指标越界时撤销发布;训练过程不可见的留出集负责捕捉对可见评估的过拟合。

flowchart LR
    H["人类拥有根目标\n定义什么值得优化"] --> T["训练 / 改进循环\n产生候选"]
    T --> C["Champion-Challenger\n候选对比线上基线"]
    C -->|"通过"| D["部署"]
    C -->|"失败"| T
    D --> M["漂移与结果监控"]
    M -->|"越界"| R["回滚"]
    R --> T
    F["冻结的留出集 / 规则"] --> A["独立审计循环"]
    A -->|"否决或反馈"| C
    M --> A

同样的结构也可用于 Agent:执行循环负责工作,独立 Evals(评估)负责测结果,安全规则限制合法路径,审计循环检查评估器本身,人在顶层负责不可由系统自行推出的价值判断。

图不等于现实锚定

更多节点和边只会增加结构复杂度,不会自动产生真实性。若运营、财务和审计循环都读取同一条已经失真的数据管道,它们可以彼此确认、逻辑一致,同时整体脱离现实。这是“循环之图”比单循环更隐蔽的失败:错误会在更多绿灯的掩护下持续更久。

因此,图中需要三类不能由优化器随意改写的锚点:

  • 外部结果:真实执行过的测试、实际到账的收入、真实留存的客户、与实物相符的盘点,而不是 Agent 的完成声明或另一张内部报表。
  • 冻结节点:优化循环不可见或不可修改的留出集、硬规则和安全边界,避免系统通过降低验收标准来“进步”。
  • 图外判断:根目标、允许牺牲什么、哪些规则必须冻结,最终由人类承担责任。图可以管理和修订下层目标,却不能从自身推出“什么值得变好”。

真正耐用的分界不是 loop 与 graph,而是未锚定与已锚定:系统的测量、监督者和规则是否持续接触它声称要改善的现实。

设计检查表

构建多个长期 Agent 循环时,至少要回答:

  • 每个优化指标对应哪个反指标,两个信号是否来自足够独立的证据链?
  • 谁拥有目标值,多久复审一次,快速执行循环能否自行改动它?
  • 两个局部目标冲突时,哪个节点拥有取舍、暂停和回滚权?
  • 哪些测试、规则和权限对优化器冻结,谁能修改这些冻结项?
  • 谁来审计传感器、grader、数据管道和指标定义本身?
  • 哪些结果直接来自环境状态,哪些只是系统对自身行为的叙述?
  • 哪些根目标必须由人确定,系统的权限边界在哪里?

与循环工程的关系

Loop Engineering(循环工程)没有被 Graph Engineering 淘汰。循环是图中的循环路径,或是某个节点内部持续运行的过程;图扩大的只是设计范围。前者关心一个持续工作系统如何触发、执行、验证、记录和停止,后者进一步关心多个循环之间的状态、监督、权限、节奏和冲突。

因此,“从循环到图”更准确地说是包含关系和视角扩展,不是技术代际替换。Prompt、Context、Harness 和 Loop 仍存在于图的节点与边中。这个标签是否会稳定下来尚不确定,但它指出的问题——跨循环治理、独立证据、否决权与现实锚定——已经是生产系统中的真实工程问题。

相关词条

参考来源
  1. 1. https://x.com/IntuitMachine/status/2078419526354378975
  2. 2. https://medium.com/intuitionmachine/from-loop-engineering-to-graph-engineering-d3ebeb08511c
  3. 3. https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase
  4. 4. https://smartscope.blog/en/blog/graph-engineering-loop-engineering-logic-review/
评论