Loop Engineering 是什么

2026-06-28 · 714 words · ~ 4 min read

上一篇《Agent 是什么，能干什么》里，我把 Agent 写成了一个很简单的公式：¹

1

Agent = LLM + Tools（工具） + State（状态） + Loop（循环控制）

最近很多人讨论的 Loop Engineering，讲的其实就是这个公式里的最后一项：Loop 怎么设计。

它不是一个新模型，也不是某个固定框架。更准确地说，Loop Engineering 是围绕 Agent 执行循环做工程设计：让模型可以围绕目标持续调用工具、读取结果、更新状态、验证进展，并在成功、失败或达到预算时停下来。

如果说「Agent 是什么」回答的是一个系统算不算智能体，那么「Loop Engineering 是什么」回答的是另一个问题：

既然 Agent 靠循环工作，这个循环怎么设计才不会空转、跑偏、过早宣布完成，或者把成本烧穿？

先把术语边界说清楚

现在还没有一个被所有公司共同采用的正式术语叫 Loop Engineering。各家公司和框架更多使用的是这些词：

agent loop
model/tool calling loop
harness
runtime
orchestration
workflow
guardrails
human-in-the-loop

所以本文里的 Loop Engineering 不是在介绍一个标准化产品名，而是把这些材料背后的共同工程问题抽出来讲。

一个最小 Agent loop 通常长这样：

1
2
3
4
5
6
7


Goal
  -> Model decides next action
  -> Tool call
  -> Observation
  -> State update
  -> Verification
  -> Continue or stop

直接问模型一句话，它回答一句话，这不是 Loop。模型调用一次工具，也不一定是 Loop。Loop 的关键在于：每一轮的工具结果会改变下一轮决策，并且系统有明确的完成标准和停止条件。

各家公司和框架怎么定义

不同公司说法不完全一样，但共同点很明显：Agent 不是单次回答，而是一个带工具、状态、运行时和多步决策的系统。

来源	他们强调什么	对 Loop Engineering 的启发
OpenAI Agents SDK	Agent 是配置了 instructions、tools，并可带 handoffs、guardrails、structured outputs 等运行时行为的 LLM。SDK 的 Runner 会管理 turns、tools、guardrails、handoffs 和 sessions。²	Loop 不只是 while 循环，还包括运行时对工具调用、会话状态、护栏和交接的管理。
OpenAI Tools	Tools 让 Agent 可以获取数据、运行代码、调用 API、使用计算机，也可以把另一个 Agent 暴露成工具。³	Loop 的行动能力来自工具。工具越危险，越需要幂等、权限、错误处理和审批。
Anthropic	Anthropic 把 workflow 和 agent 区分开：workflow 是预定义代码路径；agent 是 LLM 动态决定流程和工具使用方式。它也提醒：能不用复杂 agentic system 时，就先用简单方案。⁴	Loop Engineering 不是「越自动越好」，而是判断什么时候需要模型参与控制流，什么时候固定 workflow 更可靠。
LangChain	Agent 是模型在循环中调用工具，直到任务完成；同时提出 Agent = Model + Harness，harness 负责把正确上下文在正确时间交给模型。⁵	竞争点不只在模型，而在 harness：上下文、工具、中间件、容错、guardrails、状态管理。
Google Cloud	AI agent 是代表用户追求目标、完成任务的软件系统，具备 reasoning、acting、observing、planning、collaborating、self-refining 等能力。⁶	Loop 需要把「观察 - 推理 - 行动 - 反馈」串起来，不能只做文本生成。
AWS	AI agent 会与环境交互、收集数据，并执行自导向任务以满足预设目标；它会根据数据选择下一步动作。AWS 也把 planning、memory、tool integration、learning/reflection 放进架构组件。⁷	Loop 要有目标分解、环境感知、记忆、工具集成和反馈，而不是只靠一次 prompt。
Microsoft Foundry Agent Service	Agent 是使用模型推理用户请求并采取自主行动的 AI 应用；可以调用工具、访问外部数据，并跨多个步骤完成任务。Agent Runtime 管理 conversation、tool calls 和 lifecycle。⁸	生产里的 Loop 往往需要托管运行时、身份、安全、观测和生命周期管理。
LlamaIndex	Agent 是使用 LLM、memory 和 tools 处理外部输入的系统。它明确描述了调用 agent 后的循环：发送消息和工具 schema，模型返回直接答案或工具调用，执行工具，把结果加回历史，再次调用模型。⁹	这是最接近代码层面的 loop 描述：消息历史、工具 schema、工具结果和下一轮模型调用构成核心循环。
CrewAI	Agent 是可以执行特定任务、基于角色和目标做决策、使用工具、协作、维护记忆、在允许时委派任务的自治单元。它还把 max iterations 作为 Agent 属性。¹⁰	多 Agent 场景里，Loop 还要处理职责边界、协作、委派和最大迭代次数。

这些定义合起来，基本可以得到一个稳定判断：

1
2
3


Agent 是系统形态。
Loop 是 Agent 推进任务的执行机制。
Loop Engineering 是把这个执行机制做可靠。

Loop Engineering 主要解决什么问题

很多文章会把 Loop 讲成「让 AI 自己反复干活」。这个说法太粗。真正难的不是让它重复，而是让重复带来进展。

一个有用的 Loop 至少要回答六个问题。

1. 每一轮输入什么

模型不是在真空里行动。每一轮要给它：

目标和成功标准。
当前状态。
可用工具。
上一轮观察结果。
已经失败过的路径。
当前预算和剩余轮数。

上下文不是越多越好。长循环里，大量历史输出、失败尝试和无关日志会污染判断。Loop 设计里需要把上下文当预算管理：该摘要就摘要，该丢弃就丢弃，大输出放文件，只把关键片段放回上下文。

2. 工具怎么设计

工具是 Agent 接触外部世界的方式。工具设计差，Loop 会放大问题。

好的工具一般有几个特点：

职责单一，名字和参数清楚。
错误信息能指导下一步。
写操作尽量幂等，重复调用不会制造重复资源。
高风险操作需要审批或 dry-run。
输出可被模型稳定解析，不要把无关日志全部塞回上下文。

这也解释了为什么《Agent 工具该用 MCP 还是 CLI》里的工具选择很重要。Loop 不关心工具叫什么协议，关心的是工具能不能被安全、稳定、可验证地反复调用。

3. 状态记录在哪里

没有状态，Loop 很容易原地打转。

状态至少要记录：

已完成什么。
哪些尝试失败了。
失败原因是什么。
当前假设是什么。
下一步打算验证什么。

在代码 Agent 里，这可能是任务摘要、测试失败列表、patch diff、命令输出摘要。在业务 Agent 里，可能是订单状态、用户授权、已联系对象、待确认字段。

状态不一定都要塞进 prompt。复杂系统里，状态可以在数据库、文件、队列、trace 或 session store 里，模型每轮只读取必要切片。

4. 怎么验证完成

这是 Loop 的核心。

Agent 停止输出，不等于任务完成。模型说「完成了」，也不等于任务完成。完成必须落到可检查条件上。

代码场景里可以是：

测试通过。
lint 通过。
type check 通过。
构建成功。
PR diff 符合范围。

数据场景里可以是：

查询结果行数符合预期。
指标超过阈值。
生成文件通过 schema 校验。
报表数字能和来源对上。

写作和研究场景更难，因为结果有主观性。这时也可以设计较弱的 verifier：引用是否存在、是否只引用官方来源、是否覆盖指定问题、是否没有编造命令和版本。但如果好坏主要靠审美判断，人类仍然要在关键节点把关。

5. 什么时候停止

Loop 必须有两个出口：

成功，停止。
达到硬性上限，停止并汇报。

硬性上限包括：

最大迭代次数。
最大 token。
最大费用。
最大运行时间。
连续无进展次数。
连续同类错误次数。

没有停止条件的 Loop 不是自治，而是失控。

6. 谁能说不

一个常见失败模式是：执行者自己检查自己，最后自我说服。

更稳的结构是把 maker 和 checker 分开：

一个 Agent 负责实现。
另一个 Agent 或确定性脚本负责检查。
高风险动作交给人确认。

在代码里，测试和类型检查就是最便宜、最可靠的 checker。在复杂场景里，可以再加 reviewer agent、policy guardrail、审批流或人工复核。

和上一篇 Agent 文章怎么接上

《Agent 是什么，能干什么》回答的是「什么算 Agent」。里面有四个判断问题：¹

有没有明确目标，而不只是回答问题？
能不能调用外部工具？
会不会根据工具结果调整下一步？
有没有停止条件和安全边界？

Loop Engineering 其实就是把第 3、4 点展开：

根据工具结果调整下一步，就是 loop 的推进机制。
停止条件和安全边界，就是 loop 的刹车和护栏。

所以两篇文章可以连起来看：

1
2


Agent 是带工具、状态和执行循环的大模型应用。
Loop Engineering 是让这个执行循环变得可控、可验证、可维护。

换句话说，Agent 不是因为名字叫 Agent 才有价值，而是因为它能在清楚边界内，把一个多步任务推进到可验证结果。Loop Engineering 关注的就是「推进到可验证结果」这件事。

什么时候值得做 Loop

不是所有任务都值得做 Loop。一个实用判断是看四个条件：

任务会高频重复，至少每周都会出现。
结果可以被机器拒绝：测试、构建、lint、schema、硬规则，至少要有一个能说「不通过」的检查。
Agent 能把任务端到端推进完，而不是做一半又把关键步骤交还给人。
done 有客观定义，并且失败成本可控。

这四条缺任何一条，都先不要做重型 Loop。一次性问题用一个好 prompt 往往更便宜；没有机器检查的问题，Loop 只是把判断压力推迟给人；结果主要靠审美判断的问题，可以让 Agent 辅助起草和检查，但不要急着全自动；高风险生产动作即使可以自动执行，也应该先有人类确认和回滚路径。

适合做 Loop 的任务：

修复测试失败。
跟踪 CI 并定位失败原因。
早晨自动归类昨晚失败的测试，能修的小问题先开分支修掉，不能修的留下短报告。
依赖更新 watchdog：一次只升一个依赖，测试通过才开 PR，失败就记录原因。
批量迁移代码。
定期生成带来源的报告。
检查文档和代码是否一致。
在 PR 里检查相关文档是否过期，必要时附带文档修改，但仍交给 reviewer 判断。
监控告警初步归因。

不太适合重型 Loop 的任务：

一次性问题。
没有明确成功标准的问题。
主要靠审美判断的任务。
高风险生产变更。
失败后很难回滚的业务操作。

这些任务仍然可以用 Agent 辅助，但不应该急着全自动循环。

还有一个容易被忽略的指标：不要只看 loop 跑了多少轮、花了多少 token，而要看每个被接受结果的成本。

1
2


cost per accepted change =
  loop 总成本 / 最终被接受的有效改动数

如果一个 Loop 产出 10 个结果，其中 6 个都要被人丢掉，那它没有真正省下审核成本，只是把人工判断推迟了。Loop 的目标不是让 Agent 看起来很忙，而是用更低的总成本得到可接受结果。

一个最小 coding loop

以修测试为例，一个最小可用 Loop 可以写成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


GOAL:
让 ./tests/auth 下所有测试通过。

EACH ITERATION:
1. 运行测试。
2. 读取失败信息。
3. 选择影响最大的一个失败点。
4. 做最小代码修改。
5. 重新运行测试。

VERIFY:
目标测试全绿，并且 lint/type check 没有新增错误。

STOP WHEN:
验证通过，或者达到 8 次迭代上限。

ON STOP:
如果成功，总结修改。
如果失败，列出仍然失败的测试、已尝试路径和下一步建议。

这里的重点不是 prompt 写得多漂亮，而是每个环节都可以检查。目标、动作、验证和停止条件都清楚，Agent 才有机会持续推进。

再往下看，底层机制并不神秘。一个 coding loop 往往就是：

1
2
3
4
5
6


while not verified and budget remains:
  run checker
  if checker passes:
    stop
  call agent once with the current failure
  apply the smallest change

关键是 checker 的结果最好来自退出码，而不是来自模型自评。go test、npm test、pytest、ruff、tsc 这类命令返回 0，就说明这一轮的机器检查通过；返回非 0，就把失败信息交给下一轮。模型可以解释失败、修改代码，但不要让它自己决定「测试已经通过」。

状态也不一定要都放进上下文。代码、patch、测试输出、git diff、临时文件，本身就是状态。很多稳定的 Loop 会让每一轮尽量干净地开始，只把最新失败和必要上下文交给模型，避免把前几轮的长日志、错误假设和无关推理一起塞回 prompt。

实际落地时，顺序也很重要：

先手动跑通一次，确认任务本身能被 Agent 完成。
再把稳定步骤写成 Skill、脚本或 runbook。
然后加 Loop、Verifier、预算和停止条件。
最后再放到定时任务、队列、GitHub Actions 或后台 runner 里。

跳过前两步，直接把还不稳定的任务放进定时 loop，最容易得到一个「晚上自动运行、早上留下一堆半成品和账单」的系统。

常见误解

误解一：Loop 就是多问几轮

多轮聊天不等于 Loop。用户每次手动追问，本质上还是人类在控制循环。Loop 是系统自己根据观察结果决定下一步。

误解二：Loop 越长越强

长 Loop 往往更贵、更慢，也更容易上下文污染。好的 Loop 应该尽快收敛，而不是证明自己能跑很多轮。

误解三：加一堆工具就更像 Agent

工具太多会增加选择难度。更好的做法是给当前任务提供少量、边界清楚、输出稳定的工具。

误解四：有 verifier 就能完全无人值守

Verifier 只能覆盖它能检查的东西。测试能证明某些行为没坏，但不能证明需求理解一定正确。高风险场景仍然需要人类确认。

误解五：自我评分就是验证

让模型自己起草、打分、修改，可以作为轻量文本任务里的弱 Loop。但自我评分不是强 verifier。代码、生产、资金、权限、公开发布这类任务，必须有测试、类型检查、规则校验、审批或外部检查者。否则只是让同一个模型更有仪式感地相信自己。

总结

Loop Engineering 可以理解为 Agent 工程里的执行控制问题。

模型负责推理和生成下一步动作，工具负责接触外部世界，状态负责让系统记住进展，verifier 负责判断是否达标，stop condition 负责防止失控。把这些拼起来，才是一个能工作的 Agent loop。

所以它和上一篇文章里的 Agent 定义关系很直接：

1
2
3
4


Agent = LLM + Tools + State + Loop

Loop Engineering = 设计这个 Loop：
输入什么、调用什么、记住什么、怎么验证、何时停止、谁能否决。

这也是为什么最近大家开始少谈「怎么写一个神奇 prompt」，多谈「怎么设计一个可靠的 loop」。Prompt 仍然重要，但它只是循环里的一部分。真正决定 Agent 能不能稳定工作的，是 prompt 外面的系统。

#AI Agent #Loop Engineering #LLM #OpenAI #Anthropic #LangChain #工程实践

Loop Engineering 是什么

Related posts