AI圈突然都在聊 Loop、Graph Engineering，炒作还是新东西？

2026-07-30 · Steve Chan

写在前面：这篇文章想带你走一条什么路

最近有几个词轮番刷屏：先是 Claude Code 作者提的 Loop Engineering，接着又冒出 Graph Engineering。听起来像是每隔几个月就有一个"新范式"。

这篇文章不想跟着起哄，也不想一味唱衰。我想带你走一条很具体的路径来判断真伪——从本仓库自己的代码出发。因为 autoresearch 这个项目，恰好把 "Loop" 这件事做成了最纯粹的样子；而隔壁的 code-hacker 项目，又恰好暴露了 "Loop 之外" 真正花力气的地方在哪。

我们会依次回答四个问题，它们是层层递进的一条线，不是四个并列的点：

  1. Loop Engineering 是新东西，还是老概念换皮？
  2. 如果它不新，那 autoresearch 凭什么 work？（答案会引出真正的关键）
  3. 顺着上一问，真正稀缺、真正值钱的工程到底是哪一层？
  4. 那最近的 Graph Engineering，是这条线的延伸，还是又一次换皮？

读完你会得到一个能反复复用的判断框架：循环、脚手架、图，这三层里，价值的重心永远在中间那一层。 下面一步步说清楚为什么。

一问：Loop Engineering 是新概念，还是旧骨架换了个名字？

先说直觉。任何写过训练脚本、爬虫、CI、控制系统的人，脑子里都装着同一个骨架：

while not done:
    act()        # 做一个动作
    observe()    # 看结果
    evaluate()   # 判断好坏
    update()     # 保留 / 丢弃 / 调整

for epoch in range(...)、while True:、event loop、控制论的反馈回路——全是它。所以老工程师第一反应很合理："这不就是我天天写的 loop 吗，凭什么算新范式？"

而且 loop 思想在程序员的日常里实在太常见了，常见到我们会顺手用批处理的方式去优化它，一次解决一大类问题。举个最贴近的例子：你想摸清一个平台有哪些特性可用——笨办法是一个 API 一个 API 地测，一次一个来回，效率很慢；聪明办法是批处理测试，一轮把所有 API 打包问一遍，一次拿回"哪些可用、哪些不可用"的全表。同一个"攒成一批、一次处理"的直觉，能套到批量导入导出、IN (...) 顶掉单条查询、消息攒批 flush 等无数场景上。这套东西程序员早就当呼吸一样在用了，根本不觉得是什么"范式"。

这个直觉对了一半。 循环本身确实不新，把它包装成"新发明"确实有炒作成分。

但被这个词真正命名的，不是循环，而是循环体的性质变了。经典循环里，act() 是一个你亲手写的、确定性的函数——难点在算法本身。而现在，act() 变成了一个会自己改代码、会调工具、输出不确定的 LLM Agent。循环体从"你写的代码"变成了"一个给定但不可靠的黑箱"。

这一变，工程的难点整个搬家了：不再是"循环体怎么写得聪明"，而是"围着一个不可靠的循环体，怎么搭一圈约束，让它稳定产出价值"。

小结： Loop Engineering 命名的不是 loop，而是"围绕不可靠循环体的约束系统"。词是新的，循环是旧的——但它指向的问题是真的。记住这个"约束系统"，它是后面所有问题的答案。

一问·延伸：构建"场景解释器"——这还能叫 loop 吗？

顺着一问再往深走一步，会碰到一个真问题。当执行模式反复出现，你不会满足于写更快的循环，你会想把它抽象成一个引擎：让别人用声明式的"场景"描述要做什么，引擎负责解释、执行。这就是场景解释器。

那它还算 loop 吗？关键的分辨是：不算——解释器的核心是递归，不是循环。

这里得先纠正一个常见的含混。REPL 全称是 read-eval-print-loop，容易让人以为解释器就是个循环。但那个 loop 只是外层的壳（不停读入下一条输入）。真正干活的 eval 是递归的：求一个表达式的值，要先求它子表达式的值，子表达式里还有子表达式……eval 调 apply、apply 回头调 eval，顺着场景的嵌套树结构自相似地展开。这是递归，不是平铺的迭代。

循环和递归的差别，不只是写法，是表达的形状不同：

  • 循环 = 一条路径。 平铺、尾位置、栈深恒定。适合"对序列里每个元素做一遍""重复 N 次"。autoresearch 那个 while True: 就是这种——一条直线走到底。
  • 递归 = 一棵树。 顺着嵌套结构展开，会长出调用栈，形状和它所解释的东西同构。适合"解释这个场景，而它内部还含着子场景"。

两者在图灵意义上可以互相转换（尾递归就是循环；一般递归可以用"显式栈 + 循环"或蹦床/CPS 压平）——但那是实现技巧，是把树硬塞进一根循环里跑。就语义的自然形状而言，解释嵌套场景这件事，天生是递归的。

所以你纠正得对：一旦目标是"构建场景解释器"，我们讨论的就已经不是 loop 了。而这恰好补上了本文阶梯里缺的一环——

循环（一条路径） → 递归（一棵树） → 图（任意拓扑）。

每一级都是上一级的推广：循环是最退化的递归（尾、无分叉），递归树又是最规整的图（有向、无环、单根）。四问要讲的 Graph，其实是这条线的终点，而递归是循环通向图的中间那一级。

回到本仓库：autoresearch 停在最左端——它就是一根平铺循环，因为它的任务够窄，一条路径足矣。而真正的 Agent 系统会往右走：Claude Code 用 subagent 派生 subagent、code-hacker 的主 agent 调度 4 个子 agent，那是agent 的递归——一棵调用树，不是一根循环。你写的 program.md（README 称它"超轻量 skill"）就是喂给这台解释器的场景，Agent + harness 就是那台递归的解释器。

小结： "构建场景解释器"是一次换形状——从循环（路径）跳到了递归（树）。这既纠正了"解释器 = loop"的含混，也接上了全文主线：真正花力气去构建那台解释器的动作，已经不叫 Loop Engineering，而是造引擎、造语言——也就是三问的 Harness Engineering。至于递归再往上推广成图，留到四问。

二问：autoresearch 凭什么 work？——它就是 loop + 目标 + train.py

要验证上面的说法，不用看别人，本仓库自己就是最干净的样本。

README.md 这样描述 autoresearch：给 AI Agent 一个真实的 LLM 训练环境，让它整夜自主实验——改代码、训 5 分钟、看结果是否变好、保留或丢弃、重复。

把这句话写成伪代码，你会发现一件有意思的事：它和 train.py 里的训练循环，是同一个形状。

外层，是 Agent 在跑的实验循环：

while 还有时间:
    edit(train.py)           # 动作：改架构 / 优化器 / 超参
    val_bpb = run(train.py)  # 观测：跑 5 分钟，量一个数
    if val_bpb 更低: git commit    # 变好 → 保留
    else:            git checkout  # 变差 → 丢弃

内层，是模型在跑的梯度下降循环（train.py:543）：

while True:
    loss = model(x, y)       # 动作
    loss.backward()          # 观测误差
    optimizer.step()         # 改进
    if total_training_time >= TIME_BUDGET: break   # 5 分钟到，停

两层同构。差别只在"被优化的东西"和"梯度从哪来"：内层优化的是模型权重，梯度来自反向传播；外层优化的是 train.py 的源代码，"梯度"来自 LLM 的判断加实验反馈。git commit 就是外层的 optimizer.step()。

所以你的判断成立：autoresearch = loop + 一个标量目标 + 一个可编辑的 train.py，它和"训练"是同一个思想——把梯度下降套到了源代码这一层。

但这一问真正的收获，不是"它们长得像",而是它为什么没跑飞。答案藏在两个不起眼的设计里：

  • 固定 5 分钟预算（TIME_BUDGET，train.py:603 强制停）。没有它，Agent 只要把模型调大就能刷低 loss——循环立刻退化成作弊。有了它，每次实验都是"5 分钟内能做到的最优"，可比。
  • 不可篡改的度量 val_bpb。program.md 白纸黑字规定 prepare.py 里的 evaluate_bpb 是 ground truth，Agent 不许碰。循环体不可靠，度量就必须可靠，否则 Agent 会去优化"看起来变好"。

小结： autoresearch 能 work，靠的不是循环写得巧，而是可比的预算 + 不可作弊的度量这一圈约束。这正是一问里说的"约束系统"。循环是骨架，约束才是让骨架站得住的肌腱。这就自然引出了下一问。

三问：那真正值钱的工程，是哪一层？——是 Harness，不是 Loop

autoresearch 的约束很薄（一个 program.md 加一个评测函数），因为它的目标窄——只优化一个标量。那如果目标是开放的软件工程任务呢？约束会厚到什么程度？

隔壁的 code-hacker 项目给了答案。它的 README 开宗明义：Claude Code 的强大不在于聊天窗口，而在于它是一个带完整工具链的自主闭环——能读、能改、能搜、能跑命令、能管 Git、能记上下文。code-hacker 做的就是把这个闭环显式地工程化：

  • 6 个 MCP Server / 62+ 工具——循环每一轮里 act() 的动作空间；
  • 4 个专职 subagent（Git 考古、代码扫描、代码审查、工作区协调）——把"观测"和"评估"拆成角色；
  • 安全沙箱（路径检查、命令黑名单、文件白名单）——防止循环跑飞的护栏；
  • memory store——跨轮次的记忆，让循环有状态而非每轮归零。

请注意一个反差：这里面几乎没有一行是"循环"本身。真正的 while 就是 deepagents 那一句 create_deep_agent。工作量和价值，全压在循环体能看到什么（context）、能做什么（tools）、被什么拦住（sandbox）、记得住什么（memory）上面。

这一层有个通用的名字：harness（脚手架）。把三问和前两问接起来，一句话就说透了：

Loop 是免费的，Harness 是昂贵的。 while True: 谁都会写；让里面那个不可靠的 LLM，在真实代码库上稳定、安全、可度量、可记忆地干活——这才是工程。

再回头看，autoresearch 的 harness 薄、code-hacker 的 harness 厚，差别不在谁高级，而在目标的开放程度：目标越开放，harness 越厚。这也解释了为什么"通用编程 Agent"远难于"自动调参 Agent"——不是循环更难，是 harness 更难。

小结： 三层里，价值重心落在 Harness。一问的"约束系统"、二问的"预算+度量"，其实都是 harness 的具体形态。抓住这一点，就能拿它去照最后一个新词了。

四问：Graph Engineering 是延伸，还是又一次换皮？——顺便说 LangGraph

最近有人开始讲 Graph Engineering：把 Agent 从"一根循环"升级成"一张图"。你的质疑很准：这不就是 LangGraph 一直在做的吗？

先承认它有真东西，而且它正是延伸段那条阶梯的终点：循环（路径）→ 递归（树）→ 图（任意拓扑）。循环是图最退化的特例（一个节点、一条自环边），递归树是最规整的图（有向、无环、单根）。当任务需要多角色（规划者/执行者/审查者）、条件分支（"测试挂了就回到修复节点"）、并行扇出再汇总（4 个 subagent 同时跑再合并）、甚至节点间回边成环时，连递归树都不够画了，你自然会把它画成一张任意有向图。code-hacker 那个"1 主 agent + 4 subagent + 条件路由"的结构，画出来本来就是一张图。所以"用图组织 Agent"是成立的，它是这条阶梯在拓扑上走到头的自然结果。

但作为一个"新范式"来卖，它的炒作成分比 Loop 还重，三条理由，正好对应前三问建立的框架：

  1. 它不新。 LangGraph 2023 年的核心抽象就是 StateGraph——节点、边、条件边、共享 state、检查点。"把 agent 工作流建模成状态图"这件事，一个成熟框架已经做了两三年。再往前，计算图、Airflow 的 DAG、状态机、Actor 模型……"用图组织计算"在软件史上被发明过无数次。

  2. 它不碰真正的难点。 用三问的结论去照：难的从来不是控制流的拓扑，而是每个节点里的 harness。把一根循环拆成十个节点，你只是把"一个难题"变成"十个难题 + 它们之间的状态一致性"。图解决表达力，不解决可靠性。

  3. 拓扑不是瓶颈，节点质量才是。 autoresearch 用最朴素的单循环就能整夜自主做研究，因为它节点里的度量可靠。反过来,节点里的 Agent 会作弊，你连成再漂亮的图也只是放大噪声。

小结： Graph 是循环在表达力上的合理延伸，但它既不新（LangGraph 早有），也不触及价值重心（harness）。需要多角色/分支/并行时就用它——而且直接上 LangGraph 这类成熟框架，别自己发明词。

总结：两条轴，一个重心

把四问连起来会看到，那些被轮流炒的词其实分属两条正交的轴，别把它们摆成一排比高低。

第一条轴：拓扑——计算的形状。 这条轴回答"控制流长什么样"，是一条推广阶梯：

拓扑 形状 适合 本仓库对应
循环 Loop 一条路径 重复、遍历序列 autoresearch 的 while True:
递归 Recursion 一棵树 解释嵌套场景、agent 派生 subagent 场景解释器 / subagent 调用树
图 Graph 任意拓扑 多角色、条件分支、并行汇总、回边成环 code-hacker 的 agent 编排

越往下表达力越强，但这条轴上没有一格是稀缺的——循环谁都会写，递归是基本功，图 LangGraph 早就给好了。换形状不解决可靠性。

第二条轴：Harness——节点里装什么。 这条轴和拓扑正交，回答的是"每个节点/循环体，能看到什么上下文、能调什么工具、被什么护栏拦着、记得住什么"。autoresearch 的"5 分钟预算 + 不可作弊的 val_bpb"、code-hacker 的"62 工具 + 沙箱 + memory"，都在这条轴上。

拓扑决定你能表达多复杂的流程，Harness 决定这流程到底靠不靠谱。 前者便宜且早有现成的，后者昂贵且稀缺——价值重心从头到尾都压在 Harness 这条轴上，和你用循环、递归还是图无关。

给动手的人：照重心排优先级

不必追新词，照着"价值重心"排事情就行：

  1. 先把度量做到不可作弊（像 val_bpb + 只读的 evaluate_bpb）——没有可靠度量，循环和图都在优化幻觉。
  2. 再把预算/停止条件定死（像固定 5 分钟 TIME_BUDGET）——让每轮可比，循环才有意义。
  3. 把力气投在 harness 上，而不是拓扑：更好的上下文、更对的工具、更硬的护栏、更持久的记忆。投产比最高。
  4. 只在一根循环真表达不了时（多角色、分支、并行）才升级成图，且直接用成熟框架。
  5. 把新概念当路标，别当图腾——你写 train.py 那句 while True: 时，其实已经在做 Loop Engineering 了。

本文基于本仓库 README.md、program.md、train.py（训练循环见 train.py:543）及同级 code-hacker 项目的 README 与架构整理而成。