什么是循环工程 Loop Engineering？loop 比 prompt 难 10 倍

Shadow：很多人连Agentic Loop都还没理解透彻，就已经进入到了Loop Engineering时代了。一个是内循环，一个是外循环。2种方式，让Agent可以长时间干活不间断。但驾驭难度上升了，一般人控制不好，需要深刻理解每个环节的底层原理，才能驾驭好这辆“Agent”座驾。

---

Claude Code 之父 和 OpenClaw 创始人 同喊"别写 prompt 了"，但 47 轮 loop 跑偏时，你能 5 秒看出来吗？

判断力从人手里交到 Harness 手里，放大的是能力，也是错误。

未来不是"谁会写 loop"，而是"谁的 Token 撑得起 loop 失控的代价"。

Claude Code 之父和 OpenClaw 创始人在 36 小时内连续发声，告诉全世界"别写 prompt 了，去设计 loop"。

工程师睡觉时 loop 在跑

这话对。但只对一半。

另一半没人讲：当一个 loop 已经跑 47 轮、出 bug 后 prompt 工程师根本查不出来错在哪一轮，这时候，写 loop 不是能力升级，是把自己变成一个新工种。

这是判断力外包到 Harness 之后，谁来为放大后的错误买单的问题。

不是 prompt 升级到 loop，是判断权从人手里交到 Harness 手里

不是「提示词工程师」被淘汰，是「判断的容器」换了。

Prompt工程时代，你守着 Agent。每一次调用，你都在场。Agent 是工具，你是守着它的人。

Loop Engineering 时代，你不守着 Agent。Agent 在一个你设计的循环里自我迭代；它在跑，你在睡。

"我有一堆循环在运行，它们在提示 Claude 并判断接下来该做什么。我的工作变成了写循环。"

"你不该再给编程 Agent 写提示词了。你应该设计一套循环机制，让这些循环去提示你的 Agent。"

你的活儿从"问 AI 答什么"，变成"建一个能问 AI、能检查 AI、能决定 AI 下一步做什么"的系统。

但系统归系统，判断还是你的。

Anthropic的 Harness 博文里写得最清楚：他们做生成器 / 评估器 / 规划器

Agent 的关键设计，是让评估器有独立上下文窗口 + 独立的系统提示（system prompt） —— "防止自己评自己"。

Loop 是新的能力放大器，也是新的错误放大器

"所有人都在一窝蜂地冲去做 loop，但调试一个已经跑了 47 轮的状态机，比修一个单次 prompt 难 10 倍，而大多数人甚至连一个可靠的一次性 prompt 都写不出来。"

调试 47 轮 loop 状态机

loop 的难度不是写，是控。

不是"loop 让 Agent 更强"，是"loop 让 Agent 的失败路径更长"。

不是"loop 解放了人"，是"loop 把人从操作工变成了审计员"。

审计员比操作工更稀缺，也更累。

你愿不愿意为这个角色付代价，决定了 loop 时代你能不能活。

差异

在近期关于 AI Agent 开发模式的讨论中，Claude Code之父与OpenClaw之父展现了截然不同的立场与实践方式。

Claude Code之父，夜间运行数千个 Agent，背后有“近乎无限”的 token 配额加上 Claude 旗舰模型的支持。递归自我改进是主要安全风险。在过去 8 个月中“没有亲手写过一行代码”，完全依赖 Agent 完成工作

而OpenClaw之父，日常并行运行 5 到 6 个 Codex Agent（最多时曾有 10 个），并受限于个人每月 200 美元的使用上限，同时通过 OpenClaw 来监视 Codex 的行为。偶尔会发生 Agent 把代码全部清空的情况。仍然亲自审查代码和结果。

普通人听到"别写 prompt 了"会以为这是技术普惠。

真相是：这是一份特定Token成本结构下的工程师劝退书。

Boris 与 Peter 的Token反差

Loop 永远替不了你做的三件事

第一，验证。
Anthropic 评估器用 Playwright MCP（让 AI 操作浏览器的协议）真打开网页、点击、截图、调用接口（API）、查数据库（DB）。这不是技术选择，是底层原理决定的 —— 验证必须独立于生成。

人对自己的 Agent 输出的标准一样：你是真的在看，还是在"看了一个假装的合理"？

第二，理解。
"模型每次运行都失忆，记忆必须放在磁盘而不是上下文"：不要把判断写在对话上下文里，要写在 Stop hook（停止条件）的契约里。

Stop hook 是 loop 时代唯一不丢的判断。

第三，判断。
YC CEO Garry Tan 警告："不要把 Agent 变成富士康工厂式的重复劳动机器。"这话很准。

Loop 设计的真正分水岭是：你把 Agent 当富士康流水线工人，还是当一个有判断的协作者？

你把它当谁，决定了它活成谁。

机长思维与三件不可替代的事

你该不该写 loop？

自检清单，请逐项确认以下条件是否满足：

•  / [ ] 任务有明确验收标准吗？
  确保每个任务在启动前已定义可量化的完成条件。

•  / [ ] 你的 token 预算能撑住 100 轮迭代吗？
  评估最坏情况下的 token 消耗，避免循环中途耗尽预算。

•  / [ ] 你能在 5 秒内判断 Agent 的输出对不对吗？
  输出验证应快速、直观，无需深度分析即可判断正确性。

•  / [ ] loop 跑偏时你能在 1 小时内回滚吗？
  准备快速回滚机制，确保异常行为发生后能迅速恢复到稳定状态。

•  / [ ] Stop hook 条件写到字段级了吗？
  终止条件应细化到具体字段或参数，而非仅靠整体判断。

•  / [ ] 你有独立的验证通道（人 / 另一只 Agent）吗？
  设置独立于主 loop 的验证机制，避免自检盲区。

•  / [ ] 你愿意为这套 loop 写一份《崩溃自检指南》吗？
  提前准备故障排查文档，减少崩溃时的混乱和修复时间。

•  / [ ] 你的组织允许“Agent 失误一次”是常态吗？
  确保团队文化和流程能容忍 Agent 的偶发错误，并视其为正常迭代的一部分。

8 项问到底，核心是 1 个问题：

你的判断密度够不够撑起这套 loop？

判断密度 = 你的时间 × 你的认知 × 你的回滚速度。

普通开发者用什么撑？

还是这个：判断力。

训练判断力最好的方式就是“共学+费曼学习法” ，欢迎查看N30期

最后

别被新范式推着上 loop。

先盘点你的Token成本结构，再决定要不要设计循环。