什么是循环工程 Loop Engineering？loop 比 prompt 难 10 倍
Claude 之父疾呼“别写 prompt 了”，但你真的准备好驾驭这辆复杂得多的“Agent 座驾”了吗？ 核心内容： 1. 从 Prompt 工程到 Loop 工程的范式转变与风险 2. 调试失控循环的惊人难度与关键挑战 3. 未来竞争力的核心：掌控循环而非仅仅编写循环
有观点认为，很多人连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 时代，你
不
"我有一堆循环在运行，它们在提示 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？
判断密度 = 你的时间 × 你的认知 × 你的回滚速度。
普通开发者用什么撑
还是这个：
判断力
最后
别被新范式推着上 loop。
