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 的定义说得很清楚：
Graph engineering designs the topology of a multi-agent system... while loop engineering designs how each agentic node actually executes. （图工程设计的是多智能体系统的拓扑结构；循环工程设计的是每个智能体节点具体如何执行。） —— TrueFoundry, 2026
二、Loop Engineering：把“人肉 Prompt”变成一套自动系统
2.1 定义
这个词最早是 Peter Steinberger（OpenClaw 作者）在 2026 年 6 月的一条帖子里引爆的
随后 Addy Osmani、Boris Cherny（Anthropic Claude Code 负责人）等人把这个思路系统化，给出了一个公认度较高的定义：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. （循环工程，就是把“手动给 Agent 发 Prompt 的那个人”换成一套系统，让系统自己去发。）
一个 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 的说法最直接：
Representing agentic systems as graphs... allows you (as the builder) to impose your preconceptions of how the system should work into more constrained paths, not relying solely on the judgement of the LLM. ——LangChain, 2026
在图里：
- 节点（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 |
| 与本 wiki 已有页面 | [[loop-engineering]]、[[agent-loop]]、[[munk-ai]] | 目前无专页，散见于 [[agent-loop]] 的框架对比、[[job-2026-wiki-gap]] 的知识缺口清单 |
| 一句话关系 | 循环是最简单的图（一个有向的、带环的图） | 图是多个循环/节点编排出的拓扑，Graph 之内可以嵌套 Loop |
五、写在最后
如果只记一句话：Loop Engineering 解决"怎么让一个 Agent 自己把事情做完"，Graph Engineering 解决"怎么让多个 Agent / 步骤按你设计的路径协作"。
它们不是竞争关系，而是同一套"用工程化手段驯服不确定的 LLM"思路在不同颗粒度上的展开——LangChain 说得很准：这背后是同一个信念，就是把模型的推理能力放在真正需要它的地方，其余交给确定性代码。
