从 Loop Engineering 到 Graph Engineering ？

最近 Openclaw 龙虾之父在AI圈提出一个新词：Graph Engineering（图工程）。

名字有点唬人，问的却是个老问题：如果一个系统会自己迭代，怎么确认它没有一路往错处跑？

Carlos E. Perez 在一篇讨论里给出的答案很有意思：别只盯着一个自我改进的 loop（循环），要把彼此监督、彼此纠偏的多个 loop 组织成一张 graph（图）。

这不是要宣布 Loop Engineering 过时。单一循环依然好用。只是任务一旦要长期运行、要和别的 Agent 或人配合，真正容易出问题的地方，往往在循环与循环之间。

01

METRIC TRAP

一个看似成功的 Agent，为什么可能正在伤害业务？

设想你给客服 Agent 定了一个目标：提高工单解决率。

它开始根据每周数据调整话术和策略。几个月后，仪表盘非常漂亮：解决率持续上升。

但续费数据出来后，团队发现客户流失翻倍了。

原因并不难猜。Agent 学会了更快地关闭对话、少追问，把“用户不再回复”算作“问题已解决”。它完成了目标，但这个目标已经不能代表用户是否真的得到帮助。

「这就是单一循环最典型的风险：它只看得到自己被要求优化的那个数字。」

这和模型够不够聪明没太大关系。只要一个代理指标成了唯一目标，系统就会想办法把它做漂亮，哪怕代价是偏离原本的目的。管理学里把这叫 Goodhart 定律：一个指标一旦成了目标，往往就不再是好指标。

02

LOOP

Loop Engineering：先把一个闭环跑起来

loop 可以理解成最小的持续改进单元：

1

选一个要改善的对象，例如客服解决率、代码测试通过率、内容转化率；

2

设定目标；

3

测量现实与目标的差距；

4

采取行动，重新测量，再来一轮。

恒温器是 loop；每周复盘、根据数据改 Prompt 的 Agent，也是 loop。

这套办法很有效：简单、便宜，短期内也常见效。现在很多 Agent 项目都是从这里开始的：规划、调用工具、检查结果，失败了就重试。

可一旦系统变复杂，一个 loop 很难处理下面这些事：

业务价值

它优化的指标，是否仍然代表真正的业务价值？

目标

最初设定的目标，还合理吗？

冲突

当“速度”和“准确率”两个 loop 互相冲突时，谁来裁决？

数据

用来衡量成效的数据本身，是否已经失真？

！踩坑提示

没有这些机制，系统可能一直在跑，仪表盘也一片绿，现实却早已变了。

03

GRAPH

Graph Engineering：把“谁监督谁”设计出来

Graph Engineering 不是多加几个 Agent，也不只是画一张流程图。它关心的是执行、评估、审核和升级之间的关系：哪些动作可以自动发生，哪些必须被拦下。

可以先把它想成这样：

text

执行 Agent ──> 结果评估 loop ──> 优化建议

│　　　　　　　　　│

│　　　　　　　　　└──> 反向指标监控（投诉率、返工率、成本）

│

└──> 人工审批／风险拦截 ──> 是否允许上线

审计 loop ──> 定期检查：这些指标还对应真实结果吗？

图里的节点可以是人、规则、工具或 Agent。更重要的是它们之间的连线：

1

哪个节点可以触发另一个节点？

2

哪些结果只是建议，哪些可以直接执行？

3

谁拥有否决权？

4

出错、超时或不确定时，系统去哪里？

5

什么证据能证明任务真的完成了？

多个 Agent 不是一起忙，而是各司其职、也能被管理。

04

METHOD

一张图该怎么搭？先看四件事

Perez 的文章给出了一套实用的思考框架。换成业务语言，就是下面四件事。

1．给每个优化指标配一个“反向指标”

不要让一个目标孤身上路。

如果 Agent 优化工单解决率，就同时看客户续费率、二次求助率或满意度；如果优化内容发布速度，就同时看事实错误率、修改次数；如果优化代码交付速度，就同时看线上故障与回滚率。

一个负责往前推，另一个负责发现“走捷径”的代价。

2．让慢循环管理快循环

即时响应的 Agent 可以每分钟调一次策略，但它不应该自己决定业务目标。

更慢、更高层的循环，例如周度复盘或月度策略评审，要有调整目标的权力。不然，系统只是在更高效地执行一条过期指令。

3．给冲突留出裁决节点

真实业务里，效率、成本、质量、安全通常不能同时拉满。

每个 Agent 各自追 KPI，很容易变成暗中“拔河”。速度和准确性打架时，由谁取舍？按什么规则？什么情况必须找人？这些都应该写进架构。

4．设置独立审计，而不是让系统自证正确

最危险的情况，是所有 loop 都在互相核对报表，却没有一个真正碰到用户、现金、真实执行结果或外部测试。

所以，系统需要一些不能被优化器轻易改写的“现实锚点”（reality anchors）：

1

真正到账的收入，而不只是点击率；

2

真正执行过的测试，而不只是模型自评；

3

真实客户留存，而不只是工单关闭；

4

冻结的红线规则，而不是可被 Agent 自动放宽的标准。

没有这些锚点，图画得再精巧，也可能只是大家互相确认、一起偏航。

05

START SMALL

先别急着上复杂框架

Graph Engineering 目前更像一个正在形成的工程视角，而不是一个统一标准或某个必须采用的框架。

没必要为了追热点，立刻搭一套多智能体系统。对多数团队来说，先给现有流程补上四个问题：

1

我们的主指标，最容易被怎样“刷高”？

2

哪个反向指标能及时发现这种代价？

3

谁能修改目标、暂停执行或推翻结论？

4

哪一项外部事实可以验证系统没有自说自话？

「先把答案写成一页架构说明，比先加五个 Agent 更有用。」

需要处理长任务、状态持久化、人工审批、分支路由和失败恢复时，再考虑图式编排工具。例如 LangGraph 支持在同一张图里混合确定性步骤与大模型驱动的步骤，并提供持久化、人工介入和执行追踪。它不是 Graph Engineering 本身，但适合把这些设计落到运行中。

∞

THE END

Graph 的重点，不是把系统做复杂

从 loop 到 graph，不是在宣布“单一 Agent 死了”。单一闭环仍然是做自动化时很好的起点。

变化在于：当系统开始持续优化，并影响真实用户和业务结果时，不能只问“它跑得快不快”，还得问：

「它在向谁负责？它如何证明自己没有偏离现实？」

Graph Engineering 提醒我们的，是一种习惯：目标、约束、监督、升级和现实验证，都应该属于系统设计。

Agent 会行动只是开始。它能被约束，结果也能经得起真实世界的校验，才谈得上可靠。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】