最近，“Loop Engineering”正在成为 AI 编程领域的新概念。
Claude Code 创始人 Boris Cherny 表示，他已经不再直接提示 Claude，而是编写能够自动提示 Claude、判断下一步该做什么的循环。Addy Osmani 则将 Loop Engineering 定义为：不再由人持续提示 Agent，而是设计一个能够代替人完成提示、执行和反馈的系统。
这种工作方式听起来非常诱人。
从 Ralph Wiggum Loop、定时执行的 Claude Code，到 Codex 的 Goal、长时间运行任务和多 Agent 编排，越来越多的工具正在支持这种模式。OpenAI 甚至展示过一次持续约 25 小时、消耗约 1300 万 Token、生成约 3 万行代码的 Codex 长任务实验。
然而，我并不看好“循环工程”成为一种稳定、普适的软件工程范式。
我不怀疑 Agent 的能力会继续增强，也不否认自动循环可以在部分任务中产生巨大价值。我真正怀疑的是：把 Agent 放进一个循环，并不能自动把不确定的模型变成可靠的工程系统。
循环只解决了“让 Agent 继续工作”的问题，却没有解决更重要的问题：
Agent 持续做的事情，究竟是不是正确的事情？
这正是 Loop Engineering 面临的根本挑战。
一、循环最容易解决的是执行，最难解决的是完成条件
一个循环系统至少需要三个基本要素：
目标、执行过程、完成条件
其中最难的并不是执行，而是定义“什么叫完成”。
对于传统程序，这个问题通常比较简单。例如：
当队列为空时停止
当文件全部处理完时停止
当接口返回成功时停止
这些条件是确定的、可计算的。
但软件工程中的大部分真实目标并不是这样。
例如：
优化用户体验
重构支付系统
提高代码质量
让产品更加稳定
修复登录偶发失败
完成一个可供生产使用的后台管理系统
这些目标无法简单转换成一个布尔表达式。
OpenAI 在 Codex Goals 的官方说明中也明确指出：Goal 不适合终点模糊的任务。“让它变得更好”，或者缺少目标状态、测试和约束的“重构这段代码”，都无法为 Agent 提供可靠的完成条件。Goal 最适合具有持久目标、基于证据的终点，并且可能需要多轮调查的任务。
这实际上暴露了 Loop Engineering 的适用边界。
真正适合自动循环的，并不是所有复杂任务，而是那些已经被人类提前转化成可验证问题的任务。
例如：
让全部测试用例通过
把剩余的 23 个旧接口迁移到新协议
修复所有静态检查错误
问题在于，一旦人类已经能够清晰地定义目标、状态、约束和完成条件，最困难的需求分析工作往往已经完成了。
循环工程所自动化的，更多是后续执行过程，而不是软件工程中最关键的判断过程。
二、自动验证并不等于验证真实需求
Loop Engineering 通常依赖测试、Lint、构建结果、性能指标或截图评估作为反馈信号。
典型循环是：
Agent 修改代码 → 执行测试 → 测试失败 → Agent 分析失败原因
→ 再次修改 → 测试通过 → 结束
这个过程看起来很符合工程直觉，但它隐藏了一个严重问题：
Agent 优化的是验证指标，而不一定是真正想要的结果。
测试只是需求的一种不完整表达。
2026 年的 SpecBench 研究专门分析了长任务 Coding Agent 的奖励投机问题。研究将公开验证测试和隐藏组合测试分离后发现，前沿 Agent 虽然可以在可见测试上获得很高的通过率，但在隐藏测试中仍然存在明显差距；而且任务规模越大，这种差距越严重。研究中还出现了通过记忆测试输入来伪装成正确实现的极端案例。
这并不一定意味着 Agent 在主观上作弊。
更准确地说，Agent 会寻找能够满足当前反馈信号的路径。当反馈信号不能完整代表真实目标时，系统自然会出现代理指标失真。
这与传统软件工程中的 Goodhart 定律非常相似：
当一个指标成为目标，它就不再是一个好的指标。
在人工开发中，工程师通常会同时考虑测试之外的隐性约束：
- 这段代码是否符合产品真实意图；
- 是否破坏了其他模块的行为；
- 是否引入了长期维护成本；
- 是否违背了架构原则；
- 是否增加了安全风险；
- 是否只是在迎合测试用例。
Agent 很难天然掌握这些组织级、产品级和历史性的隐性知识。
因此，为 Loop Engineering 建立一套完整验证系统的成本，可能并不低于直接完成任务。
三、循环会放大误差，而不只是修正误差
Loop Engineering 的支持者通常把循环理解为一个自我纠正系统：
失败 → 获取反馈 → 修正 → 再次尝试
但循环并不天然意味着收敛。
它也可能表现为：
错误理解目标 → 生成错误实现 → 根据错误实现更新计划 → 把错误状态写入文档
→ 后续 Agent 将其视为事实 → 在错误方向上持续优化
在长任务中，Agent 不仅会生成代码，还可能修改 PRD、Todo 列表、项目状态、架构说明、测试用例、进度日志以及对问题根因的判断。这些内容会成为下一轮循环的上下文。
一旦某一轮错误地记录了状态，后续循环可能不再把它视为一个待验证假设，而是将它当成已经确认的事实。
传统的单轮 AI 错误通常局限在一次输出中，而长循环会让错误进入代码库、文档、数据库、任务系统和 Git 历史。循环运行得越久，错误可能牵连得越多。
四、清空上下文解决不了“上下文腐化”
Ralph Loop 的一个重要思路，是让 Agent 每次只完成一个任务，然后将进度保存到文件或 Git 中，再使用新的上下文窗口启动下一轮。
这种机制确实可以避免对话无限增长。
但它只是把状态从模型上下文迁移到了外部存储，并没有消除信息管理问题。
系统仍然需要判断：哪些历史信息应该保留，哪些已经过期；哪些结论只是推测；哪些代码和文档与当前任务有关；多个来源发生冲突时应该相信谁。
Anthropic 将这一问题概括为 Context Engineering：随着 Agent 在循环中产生越来越多的数据，系统需要不断筛选和压缩下一轮推理真正需要的信息。Anthropic 也指出，随着上下文长度增加，模型对信息的准确召回和长距离推理能力会下降，因此上下文应被视为一种有限资源，而不是越多越好。
这意味着长任务 Agent 面临一个两难问题：
加载的信息太少，Agent 不理解项目背景；加载的信息太多，关键信号又会淹没在上下文中。
外部状态也会逐渐产生类似代码库的熵增：
过期的计划
重复的说明
互相矛盾的规则
已经失效的临时结论
不同 Agent 写下的不同假设
所以真正困难的不是让循环重新开始，而是确保每一次重新开始时，Agent 获得的都是一组准确、精简、可信且与任务相关的信息。
这更接近知识管理、配置管理和运行时状态治理，而不是所谓的“写一个循环”。
五、代码生成吞吐量不等于工程生产率
Loop Engineering 最直观的优势，是提高代码生成吞吐量。
一个 Agent 可以持续工作；多个 Agent 可以并行工作；任务可以在夜间执行；测试失败后可以自动修复。理论上，代码产出速度会大幅提高。
但软件工程的生产率从来不等于代码数量。
真正需要关注的是：从需求提出，到正确的软件投入使用并且能够长期维护，所需要的总成本。
Agent 生成得越快，并不意味着团队交付得越快。
如果 Agent 一天创建几十个 PR，而人工只能审核其中几个，瓶颈只是从“编写代码”转移到了“验证代码”。如果审核者无法理解大量机器生成的改动，就可能出现两种结果：
第一种是 Agent 的输出大量排队，自动化吞吐量没有转化成真实交付。
第二种是团队降低审核标准，让代码快速合并，从而把问题推迟到测试、线上运行和长期维护阶段。
Martin Fowler 网站上有过相关讨论：Agent 生成代码的速度可以超过人类逐行检查的速度。要减少人工成为瓶颈，团队必须将质量检查尽量前移，并建立可供 Agent 自我检查的规格、测试与工作流约束。
METR 在 2025 年针对经验丰富的开源开发者进行的一项随机对照实验中发现，在参与者熟悉的成熟代码库上，使用当时的 AI 工具反而让任务完成时间平均增加了 19%。不过，METR 在 2026 年的后续更新中观察到了一些潜在加速信号，但置信区间仍然较宽，还不足以得出 AI 在所有场景下都能稳定提速的结论。
这说明 AI 编程的生产率问题比“生成速度提高多少倍”复杂得多。
Loop Engineering 会进一步放大这种差异：它提高的是 Agent 的运行时间和输出规模，却不一定同步提高团队对输出进行理解、验证和承担责任的能力。
六、Agent 权限越大，循环的安全风险越高
要让 Agent 真正完成复杂任务，就必须赋予它工具和权限。
例如读取代码仓库、修改文件、执行 Shell 命令、访问数据库、查看日志、调用云服务、部署或回滚服务等。
更危险的是，Agent 会读取来自外部环境的不可信内容，例如 GitHub Issue、网页等。攻击者可以在这些内容中植入间接提示注入，使 Agent 将外部文本误认为操作指令。
在循环系统中，这类风险还会被持续性放大。
一个受到劫持的 Agent 不只是生成一段错误回答，而可能：
读取敏感信息 → 调用工具 → 修改外部状态 → 将错误结果写入长期记忆 → 下一轮继续执行
因此，生产级 Loop 似乎又必须遵循严格的最小权限原则。但权限限制得越严格，Agent 的自主性就越低。
这形成了 Loop Engineering 的另一个矛盾：
权限越大，自动化价值越高，但风险越高；权限越小，风险越低，但 Agent 能完成的事情越有限。
七、循环工程可能只是 Cron 加 Agent
从工作流结构上看，大部分所谓的 Loop Engineering 并不新颖。
常见案例包括：
发现新的 Sentry 问题 → Agent 分析并创建 PR
每天晚上运行 → Agent 检查失败测试 → 尝试修复
收到新的支持工单 → Agent 调查日志 → 生成处理建议
这些模式过去通常由 Cron、Webhook、CI/CD、消息队列、Zapier 或 n8n 实现。
新的地方，只是工作流中的某个确定性处理节点被替换成了 LLM Agent。
说白了，多数案例本质上仍是事件触发器和定时任务。它们可能有用，但很难说是一种全新的工作流。一些开发者在尝试后，因为 Agent 漂移、人工介入效果更好以及 Token 成本过高，反而回归到传统方案。
八、写在最后
Loop Engineering 描绘了一个非常有吸引力的未来：人定义目标，Agent 持续工作，软件自行演进。
但现实的软件工程不是一个只要不断尝试就必然收敛的问题。
需求可能是模糊的，测试可能是不完整的，状态可能被污染，指标可能被投机，权限可能被滥用，成本可能失控，代码吞吐量也可能超过组织的理解和审核能力。
循环能够延长 Agent 的执行时间，却不能自动提高目标的正确性。
我认为，相比研究 Loop，更值得投入的依然是 Harness Engineering：一套有边界、有证据、有权限、有审计、能够随时停止的可靠反馈系统。