上一篇 [《Agent 是什么，能干什么》](/posts/what-is-ai-agent/) 里，我把 Agent 写成了一个很简单的公式：[^previous-agent]

```text
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 通常长这样：

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

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

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

## Loop Engineering 主要解决什么问题

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

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

### 1. 每一轮输入什么

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

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

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

### 2. 工具怎么设计

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

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

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

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

### 3. 状态记录在哪里

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

状态至少要记录：

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

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

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

### 4. 怎么验证完成

这是 Loop 的核心。

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

代码场景里可以是：

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

数据场景里可以是：

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

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

### 5. 什么时候停止

Loop 必须有两个出口：

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

硬性上限包括：

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

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

### 6. 谁能说不

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

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

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

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

## 和上一篇 Agent 文章怎么接上

[《Agent 是什么，能干什么》](/posts/what-is-ai-agent/) 回答的是「什么算 Agent」。里面有四个判断问题：[^previous-agent]

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

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

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

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

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

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

## 什么时候值得做 Loop

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

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

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

适合做 Loop 的任务：

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

不太适合重型 Loop 的任务：

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

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

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

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

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

## 一个最小 coding loop

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

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

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

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

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

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

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

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

```text
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。

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

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

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

## 常见误解

### 误解一：Loop 就是多问几轮

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

### 误解二：Loop 越长越强

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

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

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

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

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

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

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

## 总结

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

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

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

```text
Agent = LLM + Tools + State + Loop

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

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

[^openai-agents]: [OpenAI Agents SDK - Agents](https://openai.github.io/openai-agents-python/agents/)
[^openai-tools]: [OpenAI Agents SDK - Tools](https://openai.github.io/openai-agents-python/tools/)
[^anthropic-agents]: [Anthropic - Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
[^langchain-agents]: [LangChain Docs - Agents](https://docs.langchain.com/oss/python/langchain/agents)
[^google-agents]: [Google Cloud - What is an AI agent?](https://cloud.google.com/discover/what-are-ai-agents)
[^aws-agents]: [AWS - What are AI Agents?](https://aws.amazon.com/what-is/ai-agents/)
[^microsoft-agents]: [Microsoft Learn - What is Microsoft Foundry Agent Service?](https://learn.microsoft.com/en-us/azure/foundry/agents/overview)
[^llamaindex-agents]: [LlamaIndex - Agents](https://developers.llamaindex.ai/python/framework/module_guides/deploying/agents/)
[^crewai-agents]: [CrewAI - Agents](https://docs.crewai.com/en/concepts/agents)
[^previous-agent]: [Agent 是什么，能干什么](/posts/what-is-ai-agent/)