为什么现在大家都在讨论“Loop”？
AI Agent 最大的问题，从来不是“不会写代码”。
而是：
它很难稳定地把一件复杂的事情做完。
你可能经历过这样的场景：
让 Agent 修一个 Bug，它找到了问题；
让它补一个测试，它开始修改无关代码；
让它继续执行，它忘了前面做过什么；
让它运行测试，它看到一堆报错后，告诉你：
“任务已经完成。”
但实际上，测试全挂。
于是我们开始不断优化 Prompt：
写得更详细，补充更多上下文，增加更多约束。
但慢慢会发现：
Prompt 写得越多，Agent 不一定做得越对。
问题可能不在 Prompt，而在于我们一直把 Agent 当成“执行一次指令的聊天机器人”。
实际上，Agent 更像一个需要不断观察、行动、验证和修正的执行系统。
这也是 Loop Engineering 开始受到关注的原因。
一、从“提示 Agent”到“设计循环”
Peter Steinberger 曾经发过一条很有代表性的观点：
You shouldn’t be prompting coding agents anymore.
You should be designing loops that prompt your agents.
简单翻译就是：
你不应该再手动提示编码 Agent，
而应该设计能够提示 Agent 的循环。
这句话的重点，不是说 Prompt 不重要了。
而是说：
当 Agent 需要连续完成任务时，Prompt 只是系统中的一个环节。
真正影响结果的，是整个循环如何工作：
如何分配任务；
如何提供上下文；
如何调用工具；
如何验证结果；
如何保存状态；
如何处理失败；
如何决定继续还是停止。
Anthropic 的 Boris Cherny 也表达过类似判断：
Loops are the future.
这两种表达之所以引起广泛讨论，是因为它们共同指向了一个变化：
AI 编程的重点，正在从“如何写好 Prompt”，转向“如何设计一个能够持续运行的 Agent Loop”。
二、什么是 Agent Loop Engineering？
传统软件通常是：
输入 → 处理 → 输出Agent 的工作方式则更像：
观察 → 判断 → 行动 → 获取反馈 → 修正一个完整的 Agent Loop 通常包括：
Observe
↓
Orient
↓
Plan
↓
Act
↓
Verify
↓
Reflect
↓
Persist
↺具体来说：
Observe：观察代码、文件、日志和任务状态；
Orient：理解当前处境和限制；
Plan：决定下一步行动；
Act：调用工具或修改环境；
Verify：检查行动是否成功；
Reflect：根据反馈调整策略；
Persist：保存进度，供下一轮恢复。
所以，Agent Loop Engineering 解决的不是：
如何让模型生成更长的答案。
而是：
如何让 Agent 在反馈中持续修正，直到目标真正完成。
三、Ralph Loop：目前最常见的实践
目前最简单、最容易理解的 Agent Loop 实践之一，就是 Ralph Loop。
它最初甚至可以简单到：
while :; do
cat PROMPT.md | claude-code
done表面上看，这只是让 Agent 不断重复执行。
但 Ralph Loop 的真正价值，不是“无限循环”，而是三个设计原则：
每一轮使用一个相对新鲜的上下文；
通过文件、代码、测试和 Git 保存状态；
每一轮只推进一个可验证的任务。
它的基本流程是：
启动 Agent
↓
读取任务说明和项目状态
↓
选择最重要的一件事
↓
完成这件事
↓
运行测试或其他验证
↓
更新计划、代码和检查点
↓
退出当前上下文
↺ 启动下一轮 AgentRalph Loop 解决了一个非常现实的问题：
上下文越长，Agent 不一定越聪明。
很多时候，上下文越长，Agent 越容易：
忘记真正目标；
混淆已经完成和未完成的事项；
重复修改同一个地方；
在错误方向上越走越远。
Ralph Loop 的做法是：
不让一次对话承担整个项目的记忆。
而是把记忆放到 Agent 之外：
PROMPT.md 工作规则
fix_plan.md 任务计划
specs/ 技术规格
progress.md 进度记录
tests/ 验收标准
.git/ 检查点和恢复机制
四、一轮只做一件事
Ralph Loop 最重要的一条实践是：
One item per loop：一轮只做一个事项。
注意，是一个事项，不是一个大目标。
“完成支付系统”不是一个事项。
下面这些才是：
添加支付订单状态枚举；
实现订单创建接口；
为重复支付增加幂等校验；
增加支付失败测试；
修复金额四舍五入问题。
每一轮只推进其中一个。
为什么？
因为如果一轮同时修改十个地方，测试失败时，Agent 很难判断到底是哪一处导致了问题。
而如果一轮只做一件事，反馈会清晰很多：
修改一个目标
↓
运行相关验证
↓
成功：标记完成
失败：分析这一件事为什么失败一个好的 fix_plan.md可能是这样的：
# Fix Plan
- [x] Add order status enum
- [x] Implement order creation API
- [ ] Add idempotency check
- [ ] Add payment failure tests
- [ ] Run full regression tests每一轮开始时，Agent 读取这份计划，选择最重要的一个未完成事项。
完成后更新计划，再进入下一轮。
这就是 Ralph Loop 的“渐进式收敛”。
五、Harness Engineering 和 Loop Engineering 是什么关系？
这是最容易混淆的地方。
一句话概括：
Harness Engineering 负责设计 Agent 的工作环境，Loop Engineering 负责设计 Agent 的工作循环。
可以把 Agent 想象成一名在工厂里工作的工程师：
Harness 是工厂：提供工具、权限、记录系统和安全规则；
Loop 是工作流程：检查任务、选择动作、执行、验收、返工；
LLM 是操作员：根据当前信息决定下一步。
两者的关系可以表示为：
Harness Engineering
↓
提供工具、状态、上下文、权限和验证器
Ralph Loop
↓
反复启动 Agent，分配一个最重要的事项
Agent Loop
↓
观察、行动、验证、修正
外部状态
↺
代码、测试、计划、日志、Git更具体地说：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ralph Loop 可以看作 Loop Engineering 的一种具体实践。
而 Harness Engineering 则是让 Ralph Loop 可靠运行的基础设施。
没有 Harness，Ralph Loop 可能只是：
无限重复执行 Agent有了 Harness，它才会变成：
受控执行
↓
可靠验证
↓
状态保存
↓
失败恢复
↓
必要时人工接管六、Harness 如何支撑 Ralph Loop？
1. 上下文治理
每一轮 Agent 都需要读取相关信息，但不能把整个项目全部塞进上下文。
Harness 可以提供：
当前待办；
相关规格；
目标文件；
最近一次变更；
测试失败日志；
项目编码规则。
这就是渐进式披露：
让 Agent 每轮看到“足够完成当前事项”的信息。
2. 工具编排
Agent 想运行测试时，Harness 负责：
检查命令
↓
确认权限
↓
在沙箱中执行
↓
提取退出码
↓
结构化返回失败用例Agent 想修改生产配置时，Harness 可以直接拒绝，或者要求人工确认。
3. 状态持久化
Ralph Loop 的记忆不在对话里，而在环境里：
fix_plan.md
progress.md
specs/
tests/
.git/即使 Agent 崩溃、上下文耗尽或会话结束，下一轮仍然可以从上一次状态继续。
4. 验证与终止
Harness 提供客观验证器：
单元测试；
类型检查；
Lint；
构建；
集成测试；
安全扫描。
Ralph Loop 根据这些结果决定：
继续
重试
换策略
暂停
完成七、Ralph Loop 不是无限自动化
很多人看到 Ralph Loop，第一反应是：
“是不是只要把 Agent 放进 while 循环，就可以让它自己写完整个项目？”
当然不是。
Ralph Loop 的本质是“最终一致性”，而不是“一次正确”。
它允许 Agent 在多轮中逐渐修正，但必须配合明确边界。
至少需要设置：
最大迭代次数；
单轮任务范围；
单个任务的最大失败次数；
测试和验收条件；
高风险操作的人工确认；
每轮的日志和检查点；
明确的完成信号。
例如：
连续失败 3 次 → 暂停
修改生产配置 → 请求确认
全量测试失败 → 不得输出完成
超过 20 轮 → 停止并生成报告
所有验收项通过 → 输出 COMPLETE否则，Ralph Loop 很可能陷入：
修改
↓
测试失败
↓
继续修改
↓
引入更多问题
↓
重复循环所以，Ralph Loop 的关键不是“循环”。
而是：
每一轮是否产生了可验证的进展。
八、什么时候适合使用 Ralph Loop？
Ralph Loop 特别适合：
规格相对清晰的绿地项目；
有较好测试覆盖的代码库；
可以拆成多个独立事项的任务；
能够通过工具验证结果的工作；
允许异步执行和人工抽查的流程；
代码迁移、测试补全、文档生成、批量重构等任务。
它不适合直接用于：
没有验收标准的开放式任务；
没有测试、无法验证结果的核心逻辑；
生产数据库迁移；
高风险基础设施变更；
涉及权限、资金或隐私的自动操作；
必须一次性正确完成的任务。
一句话：
越容易验证，越适合循环自动化。
九、从“写更好的 Prompt”转向“设计更好的 Loop”
Agent 的能力当然重要。
但在真实系统里，可靠性通常来自：
可靠性
= 决策能力
× 反馈质量
× 循环设计
× 环境约束如果没有反馈，再强的模型也只能猜。
如果没有循环设计，Agent 会反复犯错。
如果没有 Harness 约束，错误可能直接影响外部系统。
所以，构建 Agent 时，更应该问：
目标是否可以被验证？
每轮是否只做一件事？
Agent 是否拥有新鲜上下文？
状态是否保存在外部？
失败原因是否可识别？
是否有最大重试次数？
是否可以随时恢复？
什么时候必须停止？
人工应该在哪里接管？
这些问题，比“Prompt 要不要再长一点”重要得多。
十、最后用一句话讲清楚
Ralph Loop 是一种实践方法：
用新鲜上下文反复启动 Agent，让它每轮只完成一个事项，并通过代码、文件、测试和 Git 持续传递状态。
Agent Loop Engineering 解决的是：
Agent 如何观察、行动、验证、修正和停止。
Harness Engineering 解决的是：
Agent 在什么环境里工作，以及哪些事情可以被安全地执行。
三者的关系是：
Harness Engineering
提供可靠的工作环境
Agent Loop Engineering
设计稳定的执行闭环
Ralph Loop
用外层循环反复驱动 Agent，
让任务在多轮中逐渐收敛真正成熟的 Agent 系统，不是一个永远不犯错的模型。
而是一个：
犯错能发现，发现能修正，失败能暂停，暂停能恢复，完成有证据。
这才是 Agent Loop Engineering 的核心。