Loop Engineering 的坑：无限循环、烧 Token、越改越差

安逸Ai2026/7/16大约 15 分钟Loop EngineeringAgent

Loop Engineering 的坑：无限循环、烧 Token、越改越差

一句话核心：Loop Engineering 不是设计循环，而是设计"何时停止"的判断能力——真正的坑在于评测体系缺失导致无限循环和 Token 浪费

核心概念（术语表）

Loop Engineering：围绕 Agent 设计可持续运行的反馈循环系统，核心是触发、目标、上下文、行动、观察、状态、停止7大要素
Agent Loop（内层循环）：Agent 自己的"思考→调用工具→观察结果→继续下一步"循环，停止条件是"不再需要工具"
Engineering Loop（外层循环）：调度系统或工程师写的流程负责"唤醒Agent→分配任务→验证结果→记录状态"，停止条件是"达成目标/超预算/失败转人工"
ReAct 模式：Reasoning 和 Acting 交替进行，模型走一步看一步，拿到外部反馈后再决定下一步
上下文管理：决定每轮给 Agent 看哪些文件、规则、历史状态、工具结果，项目知识固化占 67.6% 的 token 消耗
评测体系：判断"任务是否完成"的标准系统，需要对业务有深入理解，区分"机器能判断的"和"必须由人判断的"
Token 成本：单 Agent Loop 比标准对话多烧 4 倍 token，多 Agent 系统是 15 倍，缓存 token 与非缓存 token 价差达 10 倍
停止条件判断：核心矛盾不是循环设计，是"凭什么决定循环该停"，制造者与检查者需分离

阅读全文

Loop Engineering 概念在 2026 年 6 月上旬突然火热。Google 工程总监 Addy Osmani 在 2026 年 6 月 7 日发布近 5000 字文章，为这个概念安上正式名字。OpenClaw 创始人 Peter Steinberger 最早提出"设计循环来提示 Agent"，Anthropic Claude Code 负责人 Boris Cherny 实践了"写循环让循环去提示 Claude"的工作模式。概念的核心洞察来自 Oracle 技术博文和 Codex 的 /goal 机制设计，强调"制造者与检查者分离"——判断任务是否完成的模型不是写代码的那个模型。

工作原理 / 核心机制

整体思路

Loop Engineering 的本质是外层循环系统，核心不是循环代码本身（6行while循环就能跑），而是循环外面的判断能力、上下文管理和成本控制。

核心组件

Loop Engineering 包含 7 大工程组件：

触发：启动任务的事件来源
- 输入：手动命令、定时任务、CI 失败、PR 创建、Issue 更新、消息事件
- 输出：唤醒 Agent 并传入初始上下文
- 数据：Claude Code 的 /loop 命令、Codex 的 Automations
目标：任务完成的标准定义
- 输入：业务需求描述
- 输出：可验证的完成条件（全部测试通过、CI green、覆盖率达标）
- 关键：目标必须具体可测，不能模糊
上下文：每轮给 Agent 看的材料
- 输入：项目文件、规则、历史状态、工具结果
- 处理：过滤、分块、优先级排序
- 输出：精炼的上下文给 LLM
- 数据：工具响应占 67.6% token，系统提示词只占 3.4%
行动：Agent 能做什么
- 输入：明确的工具权限
- 处理：调用工具、修改代码、跑测试
- 输出：代码变更、PR、报告
观察：判断上一步是否正确
- 输入：测试输出、lint 结果、类型检查、日志
- 处理：解析、比对、决策
- 输出：继续/停止/转人工的判断
状态：记录循环进度
- 输入：当前试过的方案、失败点
- 处理：持久化到文件/数据库
- 输出：Issue、Linear 卡片、状态文件
停止：退出条件
- 输入：目标达成、超预算、失败转人工
- 处理：评估是否满足退出条件
- 输出：结束循环或继续

关键知识点

mini-SWE-agent 仅 100 行 Python 代码就给模型一个 bash 工具，在 SWE-bench Verified 上跑出 76.8% 成绩，说明 loop 本身不是瓶颈
完整版 SWE-agent 经过一年多工程优化，也只高了几个百分点，边际效益极低
工具响应占 Agent 看到的 token 的 67.6%，系统提示词只占 3.4%，上下文管理是真正的工程重点
单 Agent Loop 比标准对话多烧 4 倍 token，多 Agent 系统是 15 倍，成本控制是必须的
缓存 token 和非缓存 token 的价差是 10 倍，保持上下文前缀不变比优化提示词省钱得多
连续三次相同工具调用就强制中断是基础护栏，有团队在日志里发现 Agent 把同一个错误答案重复了 58 次
Faros AI 报告显示：代码变更量增加 861%，每 PR 事故率增加 242.7%，PR 审查时间中位数延长 5 倍
"加速鞭打效应"：AI 产出速度远超人类审查速度，验证端带宽没有随生成端指数级提升
Kent Beck 评论"打字变快了，思考没有前移"精准概括根本矛盾
判断任务是否完成的模型要独立于写代码的模型，Osmani 称"制造者与检查者分离"
模型停止生成工具调用不代表用户目标被满足，把"模型不说话了"当成"任务完成了"是最隐蔽的 bug
评测能力不可外包，它需要组织对业务的深入理解和质量标准的清晰定义
Claude Code 和 Codex 的 /loop、/goal、Automations、Skills、Sub-agent、工作区隔离、MCP 已经原生支持大部分能力
Loop Engineering 大概率像 Webpack→Vite 的演进，被工具消化成基础设施

应用场景

SWE-bench 任务自动化：mini-SWE-agent 用 100 行代码在 SWE-bench Verified 取得 76.8% 分数，处理不确定路径的代码修改和测试运行任务
数据分析与报表生成：团队用 AI 半小时生成 5 个分析维度，但花两天验证方向正确性、数据口径一致性、结论可靠性
业务异动检测：AI 快速生成检测结果，但需要人工建立"什么叫异常"的清晰定义才能有效验证
PR 审查加速：Claude Code/Codex 自动处理 PR 评论、代码审查、CI 失败响应，但需要独立检查者模型判断任务是否真正完成
定时任务自动化：通过 /loop 命令设置定时任务，Agent 自主读材料、跑命令、写状态，卡住时再抛回人工

常见误区 / 踩坑

❌ 误区1：Loop 本身是核心
✅ 正解：Loop 本身只有6行 while 循环代码，100 行 agent 就能做到 95% 的效果，真正的工程重点在上下文管理、成本控制、安全护栏
❌ 误区2：模型不调用工具=任务完成
✅ 正解：模型停止生成工具调用不代表用户目标被满足，这是 Agent 设计里最隐蔽的 bug，需要独立的检查者模型
❌ 误区3：目标写模糊点没关系
✅ 正解：目标是可验证的完成条件，必须具体到"全部测试通过""CI green""覆盖率达标"，模糊目标导致无限循环
❌ 误区4：Agent 自评可以当验收
✅ 正解：写代码的 Agent 不能同时当检查者，制造者与检查者必须分离，需要独立的评测系统
❌ 误区5：忘了设置成本上限
✅ 正解：单 Agent Loop 多烧 4 倍 token，多 Agent 系统是 15 倍，必须设置最大迭代次数、挂钟超时
❌ 误区6：权限给得越大越好
✅ 正解：Agent 需要边界（工作区隔离），权限过大导致危险操作，建议权限给到"生成草稿待确认"

性能 / 复杂度

Loop Engineering 的性能损耗主要来自 token 消耗和循环次数：

Token 消耗倍数：单 Agent Loop 比标准对话多 4 倍，多 Agent 系统多 15 倍
上下文 token 分布：工具响应占 67.6%，系统提示词只占 3.4%，文档占 15.2%
缓存收益：保持上下文前缀不变 vs 优化提示词，前者更省钱，缓存 vs 非缓存价差 10 倍
Faros AI 实际数据：PR 审查时间中位数延长 5 倍，未经审查合并的 PR 增加 31%，代码变更量增加 861%

与相关概念的区别

vs Prompt Engineering：
- Prompt Engineering 门槛极低，会自然语言就能上手；Loop Engineering 门槛高，需要设计调度逻辑、理解并行隔离、处理动态上下文
- Prompt Engineering 是一对一交互；Loop Engineering 是多轮自动化系统
- 怎么选：简单任务用 Prompt Engineering，复杂多步骤任务用 Loop Engineering
vs Harness Engineering：
- Harness 是模型外面的执行环境（沙箱、工具、内存）；Loop 是调度这些 Harness 的循环逻辑
- Harness 关注"能不能做"；Loop 关注"什么时候做、做什么"
- 怎么选：先搭 Harness，再设计 Loop
vs Context Engineering：
- Context Engineering 决定每轮给 Agent 看什么；Loop Engineering 决定循环什么时候停
- Context Engineering 是 Loop 的输入层；Loop Engineering 是调度层
- 怎么选：两者配合使用，Context 为 Loop 提供高质量输入

进阶 / 面试加分项

最新进展：Claude Code 和 Codex 的 /loop、/goal 命令已经将 Loop Engineering 能力工具原生化，未来会更自动化
业界争议：Loop Engineering 是否会像 prompt engineering 那样普及？作者认为不会，它更可能被工具吸收成基础设施，就像 Webpack→Vite 的演进
一句话送给候选人：真正的 loop engineer 不是学会设计循环的那个人，是知道什么时候该停下来、并且有底气说"停在这里是对的"的那个人。Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

面试如何回答

🟢 Loop Engineering 和 Prompt Engineering 的核心区别是什么？为什么 Loop Engineering 门槛更高？

回答要点：

Loop Engineering 不是 Prompt Engineering 的升级版，而是不同层面的工作。Prompt Engineering 是一对一交互，门槛极低，会自然语言就能上手。Loop Engineering 是设计多轮自动化系统，需要设计调度逻辑、理解并行隔离原理、处理上下文窗口动态变化、建立成本监控体系、检测循环退化模式。

具体来说，Claude Code 和 Codex 的实践表明：一个 6 行的 while 循环就能跑起来，真正的功夫全在 loop 外面——上下文管理（工具响应占 67.6% 的 token）、成本控制（单 agent loop 多烧 4 倍 token）、安全护栏（连续三次相同工具调用强制中断）。这些不是"写提示词"的延伸，这是 DevOps 或平台工程层面的工作。

类比：Prompt Engineering 像骑自行车，人人都能学；Loop Engineering 像设计自动化生产线，需要系统工程能力。

🟡 为什么说"模型停止生成工具调用"不等于"任务完成了"？这会导致什么问题？

回答要点：

这是 Agent 设计里最隐蔽的 bug。模型停止生成工具调用只代表"模型不打算再调用工具了"，不代表"用户的目标被满足了"。

举个例子：用户让 Agent 修复一个 bug，Agent 可能修复了代码但测试还是挂的，模型觉得自己完成任务了（不再调用工具），但实际 bug 还没修好。Osmani 在描述 Codex 的 /goal 机制时专门强调：判断任务是否完成的模型，必须是独立于写代码的那个模型，这叫"制造者与检查者分离"。

有团队在日志里发现 Agent 把同一个错误答案重复了 58 次，连续三次相同工具调用就强制中断才能避免。真正的问题不是循环设计，是停止条件的判断确定性高不高。

🟡 Loop Engineering 的 token 成本有多高？如何控制成本？

回答要点：

Token 成本是 Loop Engineering 必须正视的问题。Anthropic 内部数据显示：单 agent loop 比标准对话多烧 4 倍 token，多 agent 系统是 15 倍。更关键的是，缓存 token 和非缓存 token 的价差是 10 倍。

成本控制策略：1）保持上下文前缀不变，比优化提示词更省钱；2）设置最大迭代次数和挂钟超时；3）工作区隔离限制权限；4）把"生成草稿待人工确认"作为默认模式。

Faros AI 报告显示：代码变更量增加 861%，每 PR 事故率增加 242.7%。这说明没有成本控制的 loop 会疯狂烧 token，产出大量需要人工审查的代码，最终反而降低效率。

🟡 一个 100 行的 mini-SWE-agent 就能在 SWE-bench 上取得 76.8% 的分数，这说明了什么？

回答要点：

这个数据来自 SWE-bench Verified 测试集，非常有说服力。它说明两件事：

第一，loop 本身不是瓶颈。核心逻辑就是一个 6 行的 while 循环：模型产生工具调用、执行工具、把结果塞回上下文、模型再看结果再决定下一步，直到不再要求调用工具。100 行代码就能把事情做到 95% 的水平，花再多时间优化 loop 结构，回报也是递减的。

第二，真正的功夫全在 loop 外面。上下文管理、缓存策略、成本控制、安全护栏才是决定系统可靠性的关键。有团队在日志里发现 Agent 把同一个错误答案重复了 58 次，连续三次相同工具调用就强制中断的设计就能解决这个问题。

🟡 如何判断一个场景是否值得做 Loop Engineering？有哪些判断标准？

回答要点：

判断标准有三个维度：

第一，任务复杂度。简单的一轮交互用 Prompt Engineering 就够了，需要多步骤、有回退、分阶段的任务才值得做 Loop。

第二，重复频率。高频重复的任务值得投入工程成本，比如每天的报表生成、定期的代码审查、持续集成流程。一次性任务不值得。

第三，停止条件是否可定义。Loop Engineering 的核心问题是"何时停止"，如果你的任务无法清晰定义"完成"的标准，做 Loop 只会陷入无限循环。

实际案例：数据分析任务 AI 半小时生成 5 个维度，但团队花两天验证正确性，说明"什么叫好的分析"没有系统化定义，做 Loop 只会加速产出垃圾。

🔴 Faros AI 的"加速鞭打效应"是什么？Kent Beck 的评论"打字变快了，思考没有前移"如何理解？

回答要点：

Faros AI 在 2026 年 6 月发布的工程效能报告覆盖 22000 名开发者、2 年遥测数据。关键数字：AI 让 PR 合并率提升 16.2%，epics 完成量增加 66%，但代码变更量增加 861%，每 PR 事故率增加 242.7%，bug 数增加 54%，PR 审查时间中位数延长 5 倍，未经审查就合并的 PR 增加 31%。

"加速鞭打效应"：AI 向一个围绕人类速度和人类质量的开发流程中倾注了大量输出，而这个流程的设计从来没有考虑过要吸收这么多、这么快。

Kent Beck 的评论精准概括了根本矛盾：loop 让"打字"变快了——代码产生的速度、测试运行的频率、PR 提交的节奏都被加速了。但"思考"——判断代码是否正确、设计是否合理、质量是否达标——并没有自动加速。审查是线性的人类认知行为，无法像代码生成那样被无限制加速。

🔴 Loop Engineering 的评测体系为什么不可外包？它和组织认知沉淀有什么关系？

回答要点：

评测不是"测试是否通过"那么简单。评测是一套关于"什么叫好"的清晰定义和可验证标准，它需要：

对业务的深入理解——什么叫"正确的"报表？什么叫"合理的"推荐？
积累真实的失败案例——不能只靠合成的测试数据
持续维护——业务变了标准要跟着变
区分"机器能判断的"和"必须由人判断的"

这些都不是技术问题，是组织对工作质量的认知沉淀问题。你能把"好"定义得多清楚，你的 agent 就能跑得多可靠。你定义不了，loop 再漂亮也是盲跑。

实际教训：团队用 AI 做数据分析，AI 半小时生成 5 个分析维度，花两天验证这些方向对不对、数据口径一致不一致、结论可不可靠——这是因为之前对"什么叫好的分析"没有做过系统化定义。

🟢 Claude Code 和 Codex 的 /loop、/goal 命令解决了什么问题？Loop Engineering 会像 Prompt Engineering 那样普及吗？

回答要点：

/loop、/goal 命令是 Loop Engineering 的工具原生实现：

/loop 设置循环模式，让 Agent 持续工作
/goal 定义目标，让独立的检查者模型判断任务是否完成
Automations 实现定时自动化
Skills 固化项目知识
Sub-agent 实现任务分工
工作区隔离确保安全

这些能力正在被工具原生吸收，未来会成为默认行为，你不需要手动设计。

Loop Engineering 大概率走上和 Prompt Engineering 不同的路：Prompt Engineering 因为门槛极低，人人都在用；Loop Engineering 门槛高，更可能被工具消化成基础设施——就像十年前需要手动配置 Webpack 和 Babel，现在 Vite 一行配置都不用写。

作者判断：Loop Engineering 会作为独立概念热一阵，然后被工具消化，不会在每个开发者中普及。