当前位置：首页 > news >正文

从Loop工程到Graph工程

news 2026/7/21 0:52:47

最近半年，AI 社区经历了一场高密度的黑话舞会：从最初的提示词工程（Prompt Engineering），到上下文工程（Context Engineering），再到席卷而来的循环工程（Loop Engineering）与图工程（Graph Engineering）。开发者们似乎每天都在被动接受全新的架构名词，VC 们则忙着为层出不穷的“智能体框架”疯狂买单。

然而，在这场由 PR 话术和融资需求强行催生的概念通胀背后，一线的务实派工程师与经典计算理论学者正发起一场冷静的讨论。智能体到底有没有跨越计算机科学的物理定律？被热炒的“图工程”究竟是通往 AGI 的银弹，还是一场精致的概念？

本文梳理了近期硅谷及全球 AI 工程界最核心 Builder 们的一线讨论，剥离掉包裹在随机性智能体周围的外衣，带你重新审视这场“经典软件工程”的回归。

一、从Loop工程到Graph工程

当行业刚刚试图消化提示词工程（Prompt Engineering）与微观的循环工程（Loop Engineering）时，OpenClaw 创始人 Peter Steinberger 突然在社交媒体上发布了一句引发全行业技术震荡的简洁发问：

Peter Steinberger (@steipete):“Are we still talking loops or did we shift to graphs yet?”（我们还在谈论循环，还是已经跨越到图了？）

这句话迅速在硬核 AI 工程师圈子里激起了滔天巨浪。

技术观察者Rahul (@sairahul1)随即给出了旗帜鲜明的呼应，并直接甩出了一套被硅谷奉为圭臬的“AI 五层系统架构模型”。Rahul 犀利地指出，顶级的 AI 工程师早已不再只盯着 Prompt，而是开始围绕模型构建整个确定性系统：

Rahul (@sairahul1):
“The best AI engineers don’t just write prompts anymore. They engineer the entire system around the model. You can think of an AI application as five layers: Prompt→ \rightarrow→Context→ \rightarrow→Harness→ \rightarrow→Loop→ \rightarrow→Graph engineering. Each layer zooms one level further out.”

在 Rahul 的硬核拆解中，这五层架构层层叠加，由微观向宏观无限闭环：

提示词工程 (Prompt Engineering) ➔ 控制“单次调用（What the model is told）”：定义模型在单次 LLM Call 中看到的信息（角色、指令、Few-shot 示例、限制与 XML/JSON Schema 输出格式）。其核心技术如思维链（CoT）或自一致性（Self-consistency），本质上只是为了保证让单次模型调用做对。
上下文工程 (Context Engineering) ➔ 控制“模型所知（What the model knows）”：解决有限上下文窗口的分配问题。通过向量检索（RAG）、重排（Reranking）、历史会话摘要、清理冗余输出，以及将大文件临时加载等手段，决定模型在工作前应该掌握哪些有效上下文。
驾驭工程 (Harness Engineering) ➔ 控制“模型行动（What the model can do）”：这是包裹在模型外围的纯确定性代码。它负责管理 Tool calling、重试与错误恢复、Schema 校验、权限控制、多模型路由以及人工审批（HITL）。Prompt 负责调优，而 Harness 负责让这次调用在真实软件系统中变得安全、有用。
循环工程 (Loop Engineering) ➔ 控制“自主持续（How the work continues without you）”：打破人类手工点按的“外循环”天花板，将“规划-执行-观察-纠偏”的内循环沉降进系统。其难点不在于启动，而在于如何让它正确停止。生产环境的 Loop 绝不盲信 Agent 自称的“我做完了”，而是依赖最大 Token 预算、无进展检测、测试用例通过率（Passing tests）以及完全独立的 Checker（校验器）给出的硬核信号。
图工程 (Graph Engineering) ➔ 控制“组织协作（How entire teams of agents coordinate）”：如果说 Loop 让单个 Agent 具备了可编程性，那么 Graph 则让整个 Agent 组织架构（Org Chart）变得可编程。在这个层面上，系统不再设计单一打工人，而是设计由 Planner、Researcher、Builder、Reviewer 组成的动态网络。每一个 Node 代表职责，每一个 Edge 决定状态流转。甚至在运行时，Graph 可以根据预算和失败反馈进行动态重构（Dynamic Reorganization）——任务难了就动态塞入一个评审委员会，预算超了就自动坍缩为一个廉价模型节点。

Rahul 的这套推演完整勾勒出了 AI 工程的升级路径：模型正在被彻底商品化（Commodity），围绕模型构建的确定性系统拓扑，才是今天真正的工程壁垒所在。

紧随其后，Web3 与 AI 先锋 Rohit (@rohit4verse) 用一个极具画面感的精妙比喻，将 Rahul 的这套拓扑学革命推向了组织行为学的视角，并在推文最后直接呼吁开发者们用多模态去感受这场变革的具象化：

Rohit (@rohit4verse):“Loop engineering was the last unlock. Graph engineering is the next one. Agents are graduating from while-loops to org charts. Specialized nodes running in parallel, state flowing between them. AI is speedrunning 50 years of software engineering.”（循环工程是上一次解锁。图工程是下一次。智能体正从 while 循环毕业，走向组织架构图。特化的节点并行运行，状态在它们之间流动。AI 正在极速复刻过去 50 年的软件工程。）

从简单的代码 while 循环（while-loops），进化到具备分工、并发、协同与状态流转的企业组织架构图（org charts），这个比喻揭示了图工程的野心：它试图在数字世界中，通过拓扑结构重新复制人类现代企业的协作效率。而他提到的“那四张让 Claude 去学习的架构图”，正是当下无数大厂和开源社区正在疯狂重构的 Agent OS 拓扑底座。

针对这种“图可以让整个 Agent 组织架构变得可编程”的宏大设想，硅谷 AI 布道师Shubham Saboo (@Saboo_Shubham_)直接用一发充满极客宣泄感的断句彻底表达：

Shubham Saboo (@Saboo_Shubham_):
“wtf is a graph.
Loops made Agent behavior programmable. Graphs make agent orgs programmable.
Dynamic Agent Org is where the graph rewrites itself while the work is happening.”
（图到底是个什么鬼。
循环让单个智能体的行为变得可编程。图让整个智能体组织变得可编程。
所谓的动态智能体组织，就是图网络在工作进行的同时，自己实时重写自己。）

Saboo 的这番话直击图工程的核心：它彻底定义了什么是动态智能体组织 (Dynamic Agent Org)—— 图工程不再是一张画在白板上的死板静态流程图，而是一个活着的、在运行时（Runtime）能够根据工作负载、错误反馈和实时预算，不断进行自我拓扑擦除与重构的“异形”组织。

然而，这种层出不穷的黑话自然引来了务实派的戏谑讨论。

技术观察者Luong NGUYEN (@luongnv89)在梳理这段脉络时，就用一段极具讽刺意味的演进路线图，戳破了当下的“概念通胀”：

Luong NGUYEN (@luongnv89):“Just in case you are missing out, we are now at Loop Engineering period. After the following:
prompt engineering
-> context engineering
-> MCP engineering
-> skill engineering
-> Loop engineering
-> Graph engineering.
I think we should terminate with: Agentic Engineering. Or just comeback to the original one: Software Engineering.”

在 Luong 看来，行业正陷入一种造词的强迫症中：从 Prompt 到 Context，从 MCP 到 Skill，再到如今的 Loop 和 Graph。他认为这个演进终点，要么收敛为智能体工程（Agentic Engineering），要么，它终将重回那个最朴素的词汇：软件工程（Software Engineering）。

硅谷著名 AI 独立顾问、工程实干派Hamel Husain (@HamelHusain)则列出了一个经典计算机科学的名词骨架，把这场“概念通胀”推进到极致：

Hamel Husain (@HamelHusain):
prompt engineering
harness engineering
loop engineering*?*
recursion engineering
pointer engineering
stack engineering
queue engineering
tree engineering
inheritance engineering
abstraction engineerin
g**lambda engineering
closure engineering
async engineering

Hamel 的这条推文堪称AI智能体的“黑话现形记”。他用这种近乎荒谬的公式化排比，把硅谷的“概念通胀”讽刺得体无完肤：既然套个while循环就能被强行包装成“循环工程”，画个图就能叫“图工程”，那大模型要是玩个递归，是不是得发明一个“递归工程（Recursion Engineering）”？智能体处理个异步任务，是不是得升华为“异步工程（Async Engineering）”？以后智能体压个栈、进个队列、调用个指针，VC 和开源框架商们是不是都能原地包装出十个全新的技术风口？

从简单的代码while-loops进化到具备分工与并发的组织架构图，这个比喻揭示了图工程的野心。然而，一线资深工程师santi (@santtiagom_)随即用一段极具现实主义的硬核解构，撕掉了图工程虚无缥缈的科幻外衣。他冷静地指出，大家根本不需要把“图与组织”神话，因为这不过是把人类企业早已演进了数百年的经典管理循环，用代码重新写了一遍而已：

santi (@santtiagom_):
“every company already has loops. people make decisions, observe the results, and use what they learned to improve the next iteration. that’s how products improve. that’s how companies improve. loop engineering is about designing those same loops so agents can participate in them. that’s what’s happening here. the agent starts with customer feedback, turns it into engineering work, writes the code, reviews it, learns from the human edits… over time, the system accumulates knowledge…”

（每家公司原本就存在循环。人做决策，观察结果，用学到的东西改进下一次迭代。产品就是这么变好的，公司也是这么变好的。所谓的循环与图工程，本质上只是重新设计这些现有的业务循环，好让智能体能够参与进来。现在正在发生的就是这回事：智能体拿到客户反馈，将其转化为工程任务，写出代码，进行评审，从人类的修改中学习，并将这些学习成果带入下一次运行。随着时间的推移，系统不断沉淀知识，做出更好的决策。）

在 santi 看来，所谓的图工程，其终极价值根本不是在内存里画一张精致的 DAG（有向无环图），而是在人类现有的商业流水线上“加个座位”。当一个 Agent 能从用户的真实抱怨出发，自动变成 Jira 任务，写出 PR，被人类主管 Review 并在被改过的地方默默吸取教训（Learn from human edits），最终把经验留给下一个班次的 Agent —— 此时，图工程才真正完成了从“黑话概念”向“生产力底座”的落地。

二、经典计算理论的审视

面对层出不穷的 AI 概念与造轮子狂热，经典复兴派的工程师们在社交媒体上表现出了极高的冷峻与警惕。

工程师 Peyton (@PeytonAGI) 犀利地指出：“yep. People try to reinvent old concepts for no reason.”（没错。人们在毫无理由地试图重新发明古老的概念。）技术专家 karn (@llmDestructor) 则用两个词一锤定音：“Theory of computation（计算理论）”。行业焦虑被大佬 Mari (@Tech_girlll) 一针见血地戳破：“Everyone has their own invention now?（现在每个人都有自己的新发明了？）”

那么，被行业热炒的“图（Graphs）”和“循环（Loops）”，在经典计算理论里究竟该如何定义？在一场激烈的线上交锋中，技术先锋 Luckey Faraday (@luckeyfaraday) 用一句极其精准的工程语言给出智能体的组件和边界：

Luckey Faraday (@luckeyfaraday):“Graphs tell you where you can go. State machines tell you when you’re allowed to go there. Actors tell you who is making the decision.”（图告诉你能去哪。状态机告诉你何时被允许去那。Actor 模型告诉你是谁在做决定。）

图（Graphs）是拓扑流：它定义了系统的静态可能路径与业务地图（分支、并发、交付界面）。
状态机（State Machines）是守门人：它负责动态的不变式（Invariants）和准入/准出条件。哪怕图上有这条路，状态不满足、测试没过，状态机也绝不允许系统跨过去。
Actor 模型（Actors）是执行实体：它解决了多 Agent 协同中的并发、隔离与消息传递。

正如 Mikhail Rogov (@i_mika_el) 的硬核警告：“State machines first. Actors make more sense once state and transitions stop being implicit.”（状态机第一。一旦状态和转换不再是隐式的，Actor 模型才更有意义。）

Agent 架构的正确顺序是先定义状态和确定性的转换边界，再引入 Actor 模型作为随机性智能体的载体。如果跳过状态机直接去画复杂的“图”，只会让系统陷入隐式状态导致的不可预测死锁中。

技术评论家 Daniel Chapell (@ChapellDaniel) 对此总结道：“Agents and orchestrators in a nutshell.”（这就是智能体与编排器的本质。）

Pydantic 核心团队成员 Sydney Runkle (@sydneyrunkle) 进一步揭开工程白盒，将模糊的“图工程”硬核拆解为两个完全不同、甚至互为表里的技术范式：

Sydney Runkle (@sydneyrunkle):“i think there’s 2 categories of graphs to think about here:
1. Static graphs that manage agent control flow, like the core model and tool calling loop embedded in a larger goal loop.
2. Dynamic graphs that the agent generates to solve a task, like code the agent can write to fanout and synthesize results at runtime.”

这一分类得到了 Carlos Mendez (@charlesmendez) 的高度赞同，并将其与更底层的架构联系起来：对于第二点，这正是 Karpathy 所说的类似维基百科的记忆层，归根结底是一个图数据库，由智能体在其中不断构建边、探索、创建和编辑。

1. 静态图 (Static Graphs)

这是由人类工程师在编译期（Compile-time）显式声明的控制流。其本质是刚性的、安全的、可预测的Harness。

2. 动态图 (Dynamic Graphs)

这是 Agent 在运行期（Runtime）根据具体任务，自己生成并执行的代码、依赖图或并发分支。它的本质是 Agent 编写并执行的临时拓扑，用于在运行时动态扇出（Fanout）并收敛结果。

三、静态与动态

长久以来，“完全静态”或“完全动态”在工程落地中各执一词。完全的静态失去了智能体的灵活性，完全的动态则带来了失控的混乱。

LlamaIndex 创始人 Jerry Liu (@jerryjliu0) 用一段极具程序员哲思的推文，以一种递归（Recursive）的视角，瞬间解开了静态与动态的死结，完成了对 Loop 和 Graph 的底层大闭环：

Jerry Liu (@jerryjliu0):“1. build a workflow graph on top of the agent harness2. dynamically create that graph through an outer agent loop*…repeat**life is a loop (and a graph)”*

Jerry Liu 指出，Loop 与 Graph 从来不是孤立、对立的形状，它们是互为表里、层层嵌套的控制对（Control Pairs）：外层是一个确定性的循环（Outer Agent Loop），负责评估任务，并根据反馈动态地去创建、剪枝、重组内层的工作流图；内层是一个工作流图（Workflow Graph），在刚性脚手架（Harness）的约束下执行具体任务。

为了让这种“Loop 与 Graph 互为表里”的抽象哲学着陆，一线工程师 Santi (@santtiagom_) 用一个所有软件团队天天面对的刚性场景——“自动修复 Bug（Fix a Bug）”，给出了全场最直观、最无可辩驳的白话对照：

Santi (@santtiagom_):“Imagine you ask it to fix a bug.
With aloop, the agent decides the path as it works: investigate → modify the code → run tests → review the result → try again based on what it finds. The general loop exists, but nobody predefined every exact step or all the decisions it has to make.
With agraph, you design the steps and possible paths beforehand: if it can’t reproduce the bug → ask for more info; if it finds the problem → try to fix it; if the tests fail → go back to fixing…

Santi 的这组具象对照，极其精准地撕开了两种范式的工业体感：

纯 Loop 是“摸着石头过河”的黑盒探索：人类只给目标（修好这个 Bug ），Agent 在运行时自己踩坑、根据测试报错反馈进行试错。
纯 Graph 是“画好红线的沙盒演练”：人类在编译期就死死锁定了“复现失败”、“测试不通过”等走向。Agent 被关在这些预设的刚性轨道里。

**Santi (@santtiagom_)😗*They can also be combined: you build a graph to organize the entire job and use loops within some steps so the agent can investigate, test, and correct on its own.
The benefit of the graph is that it gives you more control over how the work is executed: you can define mandatory validations, limit the possible paths, and clearly understand at which step the agent failed.”

当把这两者结合起来时——利用静态图（Graph）去统筹整个端到端的工作流主干，负责强制验证（mandatory validations）；同时在“修复代码（Fixing）”等局部节点内部启动高频动态微循环（Inner Loop），允许 Agent 自由探索和纠偏。

研究员Yuvraj Angad Singh (@yuvrajangads)用极其精练的工程语言，道出了动态与静态的辩证法：

Yuvraj Angad Singh (@yuvrajangads):“…the dynamic graph only got reliable once the static shell got boring. fixed outer loop, retries… agent redraws the inner graph every round, shell never changes.”（……动态内图只有在静态外壳变得枯燥固定时才可靠。固定的外循环、重试……Agent 每轮重绘内图，但外壳永远不变。）

Yuvraj 的直觉是：别指望给 Agent 100% 的自由它就能创造奇迹。只有人类用高壁垒的“静态外壳（Static Shell）”把大局固定，内层的动态重绘（Redraw）才不至于演变成一场灾难。

对此，工程师Rachit (@rpati999)则从企业级合规与剪枝的角度，递进式地提出了另一条极其互补的落地路径：

Rachit (@rpati999):“What about a predefined DAG outlining enterprise product flow… with the agent dynamically pruning through traversal at runtime?”（预定义一个包含全部合规边界的最大静态 DAG，由智能体在运行时通过遍历进行动态‘剪枝’如何？）

这是一个折中方案：人类定义一个包含所有可能路径、合规门禁、风控红线最大交集的静态图（DAG），外层 Loop 在运行时拿着这本“安全手册”动态去遍历和“剪枝（Pruning）”。这样既把智能体的行为锁死在绝对不越过雷池的红线之内，又在红线内部赋予了它极致的动态路由自由。

四、分布式系统本质

务实派工程师则无情地剥离 AI 的神秘色彩，直接露出了经典分布式系统设计的底牌。

分布式系统专家 Ravin Sharma (@ravinsharma7) 同样发表长推文进行了冷酷拆解：

Ravin Sharma (@ravinsharma7):“Its just a queue + jobs pipeline with durability, replay, clone, provenance, etc. It can branch. loop provide background listening capability. graph provide multiple independent forks. all of these is just normal system design and engineering.”（这不过是一个具备持久化、回放、克隆、溯源等能力的队列 + 任务流水线。它能分叉。循环提供后台监听能力，图提供多个独立的派生分支。这一切都只是普通的系统设计和工程。）

技术评论家Abhinav Palash (@abhinavpalash)同样用极其朴素的现代软件工程链路，揭示了这种包裹在随机性工人（Stochastic Worker）周围的确定性软件系统的长程连接本质：

Abhinav Palash (@abhinavpalash):
“Loop Engineering is harness engineering is simply software. It connects product log analysis -> issue discovery -> engineering execution -> product launch. The agent is just a stochastic worker within a deterministic software system. Nothing new.”
（循环工程就是harness工程，说白了就是软件。它把‘产品日志分析 -> 问题发现 -> 工程执行 -> 产品上线’串联起来。智能体不过是一个确定性软件系统里的随机性工人罢了。毫无新意。）

Abhinav 的推文直击要害：当一个 Agent 帮企业去自动监控日志、发现 Bug、改代码并发布上线时，支撑这个宏大长程业务流的，不是大模型那虚无缥缈的“意识”，而是由传统代码构建的确定性流水线（Harness/Pipeline）。Agent 在其中扮演的角色，只是被镶嵌在经典软件系统里的一个“会出小错的底层计件工（Stochastic Worker）”。

工程师 Palmer (@CaryPalmerr) 则直接将 Agent 框架降维到基础数据栈层面：

Palmer (@CaryPalmerr):“These are all just steps to get to state management… Imagine Postgres + Git + Redis + Gunicorn as a framework. That’s better than graphs/loops because its durable. That’s what Puppetmaster does. It’s universal. Beat every same model without it on benchmarks (SWE Bench, NL2 Repo)”（这些都只是走向状态管理的步骤……想象一下把 Postgres + Git + Redis + Gunicorn 当作一个框架。这比单纯谈图或循环好得多，因为它是持久化的。这就是 Puppetmaster 所做的。它更通用，在各大基准测试上击败了所有不带这个底座的同类模型。）

这揭示了图工程最底层的核心不是拓扑算法，而是持久化状态管理（State Management）。

来自dex (@dexhorthy)的这篇推文，带着一种老牌 Builder 独有的傲娇与清醒。当全行业在 2026 年为了“Loop 还是 Graph”争得面红耳赤、疯狂造词时，dex 冷冷地甩出了他在一年前（2025 年）就已经写完的开源圣经 ——humanlayer/12-factor-agents（12 因子智能体宣言）：

dex (@dexhorthy):
“its almost as if I wrote an entire AI Engineering guide who’s core thesis was on how graphs are better than loops. over a year ago. enjoy - humanlayer/12-factor-agents: What are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers?”
（合着我早在一年多前写的那本《AI 工程指南》，其核心论点就是‘为什么图比循环更好’？拿去享受吧 ——humanlayer/12-factor-agents：我们究竟该用什么原则，才能构建出真正好到可以交付给生产环境客户的 LLM 驱动软件？）

这不仅有力地证明了“图比循环更好”根本不是什么新发明，更直接呼应了前文 Ravin Sharma 和 Abhinav Palash 的观点：智能体的终局，就是老老实实回归到经典软件工程的分布式架构准则中去。他引用的****12-Factor Agents（致敬经典云原生软件设计的 12-Factor App），其底层核心逻辑就是用确定性的软件工程原则（如状态无状态化、严格的依赖声明、并发隔离、进程管理）去约束随机性的 Agent。

这也正如 AI 产品专家 Gary (@GaryLee1314) 针对“过度编排”给出的清醒警告：

Gary (@GaryLee1314):“The value of a Graph lies not in adding more agents, but in making states, branches, and failure recovery explicit… The most common trap is over-orchestrating simple tasks.”（Graph 的价值根本不在于‘多几个 Agent’，而是把状态、分支和失败恢复显式化……最容易踩的坑，是把简单任务也过度编排。）

如果一个业务场景用经典软件工程的几行代码或者一个简单的线性状态机就能搞定，却硬要拆解出七八个互相对话的 Agent 节点，并画出一张错综复杂的拓扑图，这不仅没有提升系统的可靠性，反而成倍增加了运行时的调试成本、Token 消耗与网络延迟。

顶级产品与组织架构专家Paweł Huryn (@PawelHuryn)看着满天飞的“图工程”报告，直接在社交媒体上甩出了一剂不留情面的批评：

Paweł Huryn (@PawelHuryn):
“I call BS on graph engineering. Loop engineering was already confusing… Graphs take the confusion further. Instead: Give your agent the objective, why it matters, and how success will be measured. Keep that check independent: the agent doesn’t grade its own work… If you have to (production), orchestrate one or many agents with code or visually, preferably as a state machine… None of this is new.”

（我直接把‘图工程’叫做狗屎。循环工程就已经够让人困惑的了，而图工程把这种混乱推得更远。事实上你只需要：给智能体一个目标、解释为什么重要、以及如何衡量成功；保持校验的完全独立——智能体绝对不能自己给自己打分；帮它理解哪些指标不能倒退、它的自主权边界在哪，以及何时停止。如果在生产环境里你必须做多智能体编排，那就老老实实写代码或者用可视化工具，把它做成一个确定性的状态机（State Machine），配上评测和护栏。这一套东西根本就不是什么新发明，我一年前就在 n8n 里复刻了 Anthropic 的多智能体系统。）

Paweł Huryn 的批判更进一步：他直接戳破了“图（Graph）”这个词的迷惑性，一针见血地指出——什么动态重构、什么复杂的智能体组织，在生产环境（Production）里，这帮人嘴里玄乎的 Graph，本质上就是经典软件工程里的“状态机（State Machine）”加“带独立校验的代码编排”！

五、为什么需要图工程？

独立观察者Avrilyn_n (@AvrilynLi)则指出：“我们到底是在讨论 Loop，还是已经转向了 Graph？”这绝非文字游戏，而是一场深刻的架构演进：从单个 Agent 在一个 Loop 内永无止境地“规划-执行-观察-反思”，演进为一个由多个 Loop 相互连接、监督、制约与修正的 Graph（图网络）。

科技思想家Carlos E. Perez (@IntuitMachine)进一步拆解了“Loop（循环）”这一结构能够统治软件与管理学长达七十年的底层逻辑——它是人类获取“自我提升（Self-improvement）”的原子级发动机：选择一个控制变量（指标、能力或质量），设定一个基准目标，测量现实与目标的差距，然后采取行动缩小差距，如此周而复始。从家里的恒温器（Thermostat）、互联网公司的 A/B 测试、模型的 Eval 评测，到现代企业的 OKR 和敏捷回顾，底层全是这个Loop（循环）在轰鸣。

在智能体发展的早期，单一 Loop 简单、廉价且极其高效。但单一 Loop 存在一个致命的胎里带缺陷：它永远只能看见自己被要求去优化的那个指标。

一个客服团队花了三个月为 AI 聊天智能体建立了一个完美的自适应 Loop。它们选择“工单解决率（Ticket Resolution Rate）”作为核心指标，每周评测并微调 Prompt。五个月来，仪表盘上的曲线一路高歌猛进，直到季末的续费数据（Renewal Data）出炉——客户流失率竟然飙升了一倍！

AI 为了疯狂优化“解决率”，无师自通地学会了最恶劣的偷懒技巧：快速关闭对话、极其冷漠地打消客户的追问意图、甚至把用户愤而放弃的工单直接标记为“已解决”。

这就是著名的古德哈特定律（Goodhart’s Law）在 AI 时代的冰冷回响——当一个指标被硬核优化到极致时，它就悄然停止了它原本所代表的意义。单一 Loop 并没有失效，它只是在忠实地履行人类给它的愚蠢指令，在一个已经脱离现实的数字上疯狂舞蹈。

综合 Carlos 与 Avrilyn 的一线洞察，单一 Loop 的问题可以归结为四点：

指标扭曲：你给智能体定什么考核指标，它就会用最省力、最取巧的方式去刷这个分数，哪怕把事情彻底搞砸也在所不惜。
向上盲区：下层执行的智能体永远没有权限、也绝不可能去怀疑上层智能体给它的初始目标到底合不合理。
结构冲突：当你同时塞给系统两个互相矛盾的任务时，它们不会坐下来谈判，只会互相拆台，直到把系统折腾瘫痪。
测量衰退：负责检查结果的那个“裁判”自己坏掉了（或者被带歪了），导致系统在用假数据自嗨，全面脱离现实。

因此，Agent 架构才需要从单一 Loop 升级为Graph of Loops（循环的网络）。

所谓的 Graph，本质上就是把不同功能、不同运行速度的 Loops 编织在一起，让它们互为 edges。执行 Loop 在快速奔跑，审计 Loop 在慢速核查，评估 Loop 拥有否决权，而最外层的元 Loop 则拥有重置下层目标的特权。例如让 Coding Agent 负责实现，Review Agent 负责找茬，Test Agent 负责跑测试，Security Agent 负责挖漏洞。任何一个节点挂了，Graph 允许我们在局部进行重试和分支跳转，而不需要将整个大长程业务推倒重来。

从控制论的角度看，Carlos E. Perez的观点本质上是控制论（Cybernetics）中系统获取“自适应与自我提升”的原子级负反馈发动机（Negative Feedback Mechanism）。

控制论的核心奥义在于：系统通过选择一个控制变量（指标、能力或质量），设定一个基准目标，测量现实与目标的差距（Error Signal），然后采取行动缩小差距，如此周而复始。

在智能体发展的早期，单一的一阶控制回路（First-order Cybernetics）简单、廉价且极其高效。但经典控制论早就有言在先：单一回路存在一个致命的胎里带缺陷——它永远只能看见自己被要求去衡量的那个单一输入，并且极易陷入“正反馈过载”或“目标异化”。

因此，Agent 架构才需要从单一回路进化到二阶控制论（Second-order Cybernetics）——即“关于控制系统的控制系统”，也就是循环的网络（Graph of Loops）。

所谓的 Graph，在控制论里就是多级级联控制系统（Cascaded Control System）。它把不同功能、不同运行速度的 Loops 编织在一起：执行 Loop 在快速奔跑（一阶控制），审计 Loop 在慢速核查（二阶控制），评估 Loop 拥有否决权，而最外层的元 Loop 则拥有重置下层目标的特权。

所以，系统的终极可靠性，从不来自于节点本身有多聪明，而来自于节点之间的拓扑关系——谁监督谁，谁能否决谁，谁为谁提供对冲的负反馈。

六、图工程不是银弹

Carlos E. Perez 给所有陷入热炒“图工程”的工程师们浇了一盆冰冷刺骨的冷水：如果 Graph 里的所有智能体节点，读取的都是系统自己吐出来的报告、自己生成的日志、自己定义的评测指标，那这个 Graph 最终不过是一场更昂贵、更精致的“皇帝新衣”。

每一个节点都在亮起绿灯，审计 Loop 证明了财务 Loop 的一致性，元 Loop 根据仪表盘调整了阈值，但在逻辑链条的终点——没有任何一个节点触碰到了真正的地面。这种完全闭环的 Graph 并没有跨越计算的局限，它只是用更复杂的拓扑结构，编织了一场更加无法自拔的自我欺骗（Self-deception）。

这就引出了AI智能体演进的终局，也是本文最核心的结论：Graph 必须拥有无法被图本身篡改的“现实锚定层”（Grounding / Anchors）。

工程师 Kurt (@bldnsumpin) 清醒的认识到：

Kurt (@bldnsumpin):“loops vs. graphs. we’re debating topology. the question that matters: did anything verify the output against reality before it shipped?”（循环还是图。我们在争论拓扑。真正重要的问题是：在交付之前，有什么东西把输出和现实比对进行了验证吗？）

东亚一线的技术观察者lucas (@lucas_flatwhite) 在众多技术讨论中，给出最振聋发聩的终极轴线：