「AI学习笔记」Loop Engineering 和 Graph Engineering

「AI学习笔记」Loop Engineering 和 Graph Engineering需要先看清适用场景和关键步骤，避免只记结论却忽略实际限制。

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）。

然后就催生了：

1. Prompt Engineering 优化单条消息
2. Context Engineering 优化单次 LLM 调用能看到的信息
3. Harness Engineering 优化 Agent 运行的整套基础设施（工具门控、上下文管理、熵管理）
4. Loop Engineering 优化“谁来一轮一轮地推进 Agent”这件事本身
5. 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 适用于什么场景

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

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

又是这个人！！！

3.1 定义

Graph Engineering 的核心动作，是把“Agent 之间/步骤之间怎么走”从隐式（丢给 LLM 自己判断“接下来该干什么”）变成显式（画一张图，规定哪些路径合法）。

LangChain 的说法最直接：

在图里：

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

TrueFoundry 补充了一个更细的区分：图里的节点未必都是 Agent，也可能是路由器（Router）、汇聚点（Join）、人工审批检查点（Human Checkpoint）——图工程管的是这些异构节点之间的拓扑、通信和委派关系，是不是每个节点都自主思考不重要，重要的是拓扑本身是不是一个可编程、可版本化的显式产物。

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

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

1. 该用图的场景：真实业务流程往往有可预测的结构——客服 Agent 先分类再回答或升级、编码 Agent 先看仓库再提改动、合规流程需要审批后才能对外执行。这类场景里，你想要的是代码兜底 + 模型只在真正需要判断的地方发挥作用，图能把"哪里该固定、哪里该交给模型"直接写进拓扑
2. 不该用图的场景：任务本身就是高度自主、步骤很难提前定死的（比如 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 解决"怎么让一个 Agent 自己把事情做完"，Graph Engineering 解决"怎么让多个 Agent / 步骤按你设计的路径协作"。

它们不是竞争关系，而是同一套"用工程化手段驯服不确定的 LLM"思路在不同颗粒度上的展开——LangChain 说得很准：这背后是同一个信念，就是把模型的推理能力放在真正需要它的地方，其余交给确定性代码。

参考来源

1. Peter Steinberger 原贴
2. LangChain, "3 Years of Graph Engineering with LangGraph"