Loop Engineering 和 Graph Engineering

上周突然听到一个新的名词--Loop Engineering。趁着周末我研究了一下，结果一研究我懵逼了，又搜到Graph Engineering。

Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering。

半年不到冒出来 5 个Engineering。但每一个都对应着一个真实的工程难题。

这篇整理一下 Loop Engineering 和 Graph Engineering 到底在说什么，以及能在哪些工具里找到对应的实战落地。

一、为什么会冒出这么多“XX Engineering”

LangChain 官方在总结 LangGraph 三年经验时说得很直白：这些词本质都是同一件事的不同侧面——LLM 是一种新型的、不那么可靠、不确定性很强的软件。

我们一直在找办法让它稳定干活。每找到一种新策略，就会诞生一个新名词（LangChain, 2026）。

然后就催生了：

• Prompt Engineering 优化单条消息
• Context Engineering 优化单次 LLM 调用能看到的信息
• Harness Engineering 优化 Agent 运行的整套基础设施（工具门控、上下文管理、熵管理）
• Loop Engineering 优化“谁来一轮一轮地推进 Agent”这件事本身
• Graph Engineering 优化“多个 Loop / 多个 Agent 之间如何编排、谁能和谁通信、状态怎么流转”

回到我们的主线--Loop Engineering & Graph Engineering。

Loop 和 Graph 不是竞争关系，而是颗粒度不同的两层。

• Loop 关心一个 Agent 节点内部怎么把事情做完
• Graph 关心多个节点之间怎么连起来

这些节点可能是 Agent，也可能是普通函数、路由器、人工审批点。TrueFoundry 的定义说得很清楚。

二、Loop Engineering：把“人肉 Prompt”变成一套自动系统

2.1 定义

这个词最早是 Peter Steinberger（OpenClaw 作者）在 2026 年 6 月的一条帖子里引爆的。

随后 Addy Osmani、Boris Cherny（Anthropic Claude Code 负责人）等人把这个思路系统化，给出了一个公认度较高的定义。

一个 Loop 最基础的构件是四样东西：

• Agent
• Verifier（验证器）
• 反馈路径
• 停止条件（迭代上限 / 预算上限 / 成功退出）

这四个要素缺一不可。

• 没有 Verifier，Agent 会自我感觉“看起来做完了”就停下
• 没有停止条件，Loop 可能无限空转烧 token

2.2 简单实践

只要你学的够慢你就不用学=。=，我本来以为是新知识。结果，各个厂商都实现完了。

kiro：goal 功能

kiro，claude code 已经实现了 goal 功能。

kiro goal 功能介绍：kiro.dev/docs/cli/ch…

Peter Steinberger的样例

这是一个简单的循环流程：让 Codex 负责维护你的代码仓库，每隔 5 分钟唤醒一次，然后把工作分配给不同的线程（任务线程）。

这样就很容易根据需要进行并行化处理，并随时调整任务方向。

我使用了一个「编排器（orchestrator）技能」，结合我的「任务分诊（triage）+ 自动代码审查（autoreview）+ 计算机操作（computer use）」技能，因此有一些工作可以自主完成并自动合并上线。

2.3 适用于什么场景

• 有明确、机器可判定的"完成"标准的重复性工作：修 lint 报错、批量升级依赖版本、补充测试覆盖率、按固定模板生成 CRUD 代码
• 可以完全在沙箱/隔离环境里验证的任务：有现成 CI、有 staging 环境、有自动化测试，Agent 犯错的代价可控
• 任务时长本身在拉长、值得无人值守跑一段时间的场景："长任务"正是 Loop 最该发挥价值的地方
• 写的人和判的人可以分离的场景：有独立的 Evaluator（另一个模型评审）或 Sub-agent 专职检查，不依赖 Agent 自己给自己打分

三、Graph Engineering：把多个 Loop 连成拓扑图

又是这个人！！！

3.1 定义

Graph Engineering 的核心动作，是把“Agent 之间/步骤之间怎么走”从隐式变成显式。

• 隐式：丢给 LLM 自己判断“接下来该干什么”
• 显式：画一张图，规定哪些路径合法

LangChain 的说法最直接。

在图里：

• 节点（Node）：可以是确定性代码、单次 LLM 调用、工具调用，也可以是一个完整的、带自己内部 Loop 的 Agent
• 边（Edge）：可以是确定性的（固定顺序），也可以是条件边（根据节点结果 / 当前状态 / 外部信号动态决定下一步）
• 整体可以看成一个状态机：图定义工作流，状态在图中流动，边定义状态转移

TrueFoundry 补充了一个更细的区分：图里的节点未必都是 Agent。

• 也可能是路由器（Router）
• 也可能是汇聚点（Join）
• 也可能是人工审批检查点（Human Checkpoint）

图工程管的是这些异构节点之间的拓扑、通信和委派关系。

是不是每个节点都自主思考不重要，重要的是拓扑本身是不是一个可编程、可版本化的显式产物。

3.2 什么时候该用图，什么时候不该用

LangChain 给出了一个很实用的判断标准，值得直接摘录改写（Content was rephrased for compliance with licensing restrictions）：

• 该用图的场景：真实业务流程往往有可预测的结构——客服 Agent 先分类再回答或升级、编码 Agent 先看仓库再提改动、合规流程需要审批后才能对外执行。这类场景里，你想要的是代码兜底 + 模型只在真正需要判断的地方发挥作用，图能把"哪里该固定、哪里该交给模型"直接写进拓扑
• 不该用图的场景：任务本身就是高度自主、步骤很难提前定死的（比如 Deep Research：规划、委派、检索、阅读、综合都要动态展开）。硬把它塞进确定性路径反而是错误方向，这种情况下更适合直接用 Agent Harness（比如 Deep Agents 这类框架），让规划和上下文管理在 harness 内部涌现，而不是写死在图里

LangChain 团队在实现 Deep Research 功能时，也经历过一次关键架构调整。

最初采用的是预定义的 LangGraph 工作流。但随着实践推进，他们发现研究类任务的动态变化远超预期，于是进一步切换到更具 agentic 特征的核心循环方案。

这个过程说明，Graph 与 Loop——更准确地说，是由 Harness 约束和封装的自由 Loop——本质上是两种需要结合具体场景做选择的范式，并不是简单的替代关系。

LangChain 还特别指出了一个在工程实践中很容易被忽视、甚至有些反直觉的事实：真正落到生产环境的 Agent 流程图，绝大多数并不是 DAG（有向无环图）。

原因并不复杂：

• 系统需要处理失败后的工具重试
• 需要向用户补齐缺失信息
• 需要先验证再回退修改答案
• 需要持续多轮调用工具直到上下文充分
• 需要中途暂停并等待人工输入

因此，这类 Agent 图更准确的描述不是无环流程，而是带环的执行图，其本质应当理解为有向有环图（Directed Cyclic Graph）。

3.3 简单实践

LangGraph

这个似乎各个厂商还没有现成的实现方式（如果有人知道可以评论下），但是graph 已经存在很久了，比如上文提到的 LangGraph。

虽然已经存在 3 年之久了，但是目前它是最佳实践之一。我也还在看，就先不献丑了。

LangGraph:docs.langchain.com/oss/python/…

偶然发现

真正的 graph engineering。直接喂图...

四、放一起看：一张对照表

维度	Loop Engineering	Graph Engineering
关心什么	一个 Agent 节点内部怎么被自动驱动完成任务	多个节点（Agent/函数/路由器/人工检查点）之间怎么连接、怎么流转
核心构件	Agent + Verifier + 反馈路径 + 停止条件	节点（Node）+ 边（Edge，含条件边）+ 共享状态
典型问题	谁来一轮一轮推进？什么时候算做完？	谁能和谁通信？哪条路径是合法的？状态怎么在节点间传递？
代表工具/概念	Kiro Autopilot、Claude Code Hooks、Munk AI 验证子 Loop	LangGraph、Spring AI Alibaba Graph
一句话关系	循环是最简单的图（一个有向的、带环的图）	图是多个循环/节点编排出的拓扑，Graph 之内可以嵌套 Loop

五、写在最后

如果只记一句话：

Loop Engineering 解决"怎么让一个 Agent 自己把事情做完"，Graph Engineering 解决"怎么让多个 Agent / 步骤按你设计的路径协作"。

它们不是竞争关系，而是同一套"用工程化手段驯服不确定的 LLM"思路在不同颗粒度上的展开。

LangChain 说得很准：这背后是同一个信念，就是 把模型的推理能力放在真正需要它的地方，其余交给确定性代码。

参考来源

• Peter Steinberger 原贴
• LangChain, "3 Years of Graph Engineering with LangGraph"