“1年前我写代码的方式，是在 IDE 里配合某种自动补全。去年 11 月，我彻底卸载了 IDE。那时候我可能同时跑着 5 到 10 个 Claude，我所谓的‘写代码’就是提示 Claude 去写。”

Anthropic 工程师、Claude Code 创建者 Boris Cherny 在最近的一次分享中语出惊人：

“现在，我觉得技术又到了下一个层级：我不再提示 Claude 了，我有一堆循环（loops）在运行，它们才是在提示 Claude 并判断接下来该做什么。我的工作变成了写循环。 我认为，这是接下来几个月甚至今年剩余时间里，我们会看到的下一次转变。”

无独有偶。就在今天，现任职于 OpenAI 的知名开发者、“龙虾之父” Peter Steinberger 也发推赞同：“你不该再给编程 Agent 写提示词了。你应该设计一套循环机制，让这些循环去提示你的 Agent。” 该贴迅速斩获超 150 万浏览量，在开发者社区掀起轩然大波。

什么是 Loop Engineering（循环工程）？

Boris 和 Peter 的公开表态，正在将一个全新的编程范式推向台前：Loop Engineering（循环工程）。

简单来说，开发者不再是那个手动向 Agent 输入 Prompt 的人，而是变成了“循环系统”的设计师，负责搭建能够持续提示、调度和约束 Agent 的自动化链路。

有网友神预言：LinkedIn 上很快就会掀起一波“Loop Engineer”的头衔变迁潮。社区已经开始把“写 Loop”视为继“写 Prompt”之后的下一层抽象，有人将其概括为从 Prompt Engineer（提示词工程）向 Meta-Prompt Engineer（元提示词工程）的跃迁。

真正的 Loop，绝不是机械的“重复劳动”

“这不就是一个高级点的 Cron Job（定时任务）吗？难道只是反复告诉模型‘把应用做更好’？”面对社区的疑问，硬核开发者们给出了否定答案。

要让 Loop 真正产生生产力，核心在于引入反馈闭环（Feedback Loop）。

就像管理一个真实的开发团队一样，自动化循环需要清晰的目标（OKR）和验证机制：

• 明确边界与目标： 如果是内部工具，目标是降低错误率、简化流转；如果是电商，目标则是优化转化漏斗。

• 多维度的反馈： Loop 不仅要能读写数据，还要能自主生成测试、做 A/B 测试、增加监控、甚至模拟用户行为。

• 说“不”的机制： 优秀的 Loop 必须包含测试、类型检查和错误拦截。否则，一个没有反馈的循环，只会让 Agent 在盲目自信中不断堆砌垃圾代码。Peter 透露，他在项目中会专门使用一个 VISION.md 文件来充当这种约束哨兵。

YC CEO Garry Tan 在转发讨论时也发出警告：不要把 Agent 变成“富士康工厂”式的重复劳动机器。 开发者应该给 Agent 提供清晰的上下文、可信的工具和安全的停止条件，让它们自主且安全地运行，而不是陷入失控的“影子自动化”。

目前，业界已经开始将这一理念产品化。例如 Claude Code 原生内置了 /loops 和 Routines 功能：

• /loops： 在持续存在的会话中运行，保留上下文窗口、工具权限和 MCP 连接，彻底解决了过去用 Shell 脚本外包模型时每次调用都是“冷启动”的痛点。

• Routines： 运行在服务器端，即使用户合上笔记本电脑，AI 依然在不知疲倦地全天候工作。

理想很丰满，Token 很骨感

然而，这场技术狂欢背后，现实的骨感也让不少独立开发者和初创团队感到肉疼。

1. 吞金兽：账单飞快跑飞

“每一次 Loop 迭代，都是一次完整的提示词执行。”如果设置每分钟执行一次、连续运行 8 小时，就会产生 480 次 API 调用。 有开发者大吐苦水：“配置终于调顺了，但字符膨胀（Character Bloat）把我的额度烧得飞快！”面对网友“20美元套餐根本玩不起”的质疑，Peter Steinberger 的回应非常扎心：“没错。可难道你的时间真不值钱吗？”

社区里流传着一个新段子：“Token 充裕的大厂可以随意使用 while 循环；Token 紧张的初创公司只能用 for 循环限制次数，拿时间换空间。”

2. 调试地狱：比修 Prompt 难 10 倍

“所有人都在冲向 loops，但调试一个已经跑了 47 轮的状态机，比修好一个 Prompt 难 10 倍。” 很多团队甚至还没摸索出如何写好一个高胜率的一次性 Prompt，就盲目接入了 Loop，结果导致后期的数据迁移和架构解耦痛苦不堪。

Anthropic 内部的最佳实践：“生成-评估-规划”三驾马车

为了让 Agent 在长时运行中不跑偏、不掉链子，Anthropic 应用 AI 团队分享了他们将 Claude Code 的连续运行时间从 20 分钟延长至数天的底层逻辑。

他们发现，长时运行有三大天敌：上下文腐烂（Context Rot）（模型接近窗口末尾时产生的“结束焦虑”）、缺乏长期规划、以及自我盲目乐观（前端搭好了就以为全做完了，实际后端还是空的）。

为了解决这些痛点，Anthropic 祭出了类似 GAN（生成对抗网络）的 “生成器—评估器—规划器” 架构：

       ┌──────────────┐       │   规划器     │ (拆解需求、制定契约)       └──────┬───────┘              │              ▼  ┌───────────────────────┐  │                       │  ▼                       ▼┌───────────┐           ┌───────────┐│  生成器   │ ◄───────► │  评估器   │ (独立上下文、严苛审计、│(编写代码) │ (对抗博弈)│(测试、截图)│  甚至注入“审美量规”)└───────────┘           └───────────┘

• 规划器（Planner）： 不负责具体代码，只负责将模糊的需求拆解为高层规格和阶段冲刺。在动工前，强迫生成器和评估器达成“什么叫完成”的契约契约（Contract）。

• 生成器（Generator）与评估器（Evaluator）分离： 这是一个关键陷阱——模型很难对自己手写的代码进行客观评估。Anthropic 选择将两者剥离，让评估器拥有独立的上下文窗口和更严苛的系统提示词。评估器会真正调起 Playwright 打开浏览器点击、截图、跑测试，甚至被注入了可量化的“审美与工艺指标”，专门拦截那些带有“紫色渐变、满纸 AI 味”的及格线作品。

随着 Opus 4.6 和 Sonnet 4.6 等新一代模型的进化，服务器端压缩和百万级上下文让模型在单一会话中的连贯性大增，外部脚手架（Harness）正在变得越来越轻量。

从“学会写代码”，到“学会写 Prompt”，再到如今的“学会编写那个能自动写代码的循环系统”。

正如社区网友所言：“不知为什么，这听起来既像巨大的进步，又像一场套娃式的金字塔骗局。” 但不可否认的是，暗夜里成千上万个 AI Agent 并行交织、自主进化的“外挂时代”，已经轰然来临。