Loop Engineering：别再写 Prompt 了，设计一个会自己提问的系统

2026 年 6 月，硅谷 AI 圈被两句话彻底点燃。

Anthropic 工程师、Claude Code 负责人 Boris Cherny 在 Acquired Unplugged 访谈中说：

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

几乎同时，OpenAI 的 Peter Steinberger（PSPDFKit 作者，人称"龙虾之父"）发推：

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

这条推文获得 150 万浏览量。接着，Google Chrome 工程总监 Addy Osmani 发表长文，正式为这个新范式命名——Loop Engineering。

黄仁勋紧接着划出新重点："Nobody writes prompts anymore. The new job is to write and handle loops." 吴恩达更是断言：三到六个月后，prompt 将消亡。

发生了什么？

过去两年，我们与编程 Agent 的协作方式是这样的：

人提出任务 → Agent 执行 → 人检查结果 → 人指出问题 → Agent 修改 → 人再次检查

人类承担了一个关键角色：人工调度器。我们不断判断下一步做什么、Agent 是否理解需求、当前结果是否正确、需要补充哪些上下文、什么时候可以停止。

问题在于：一个人的注意力是有限资源。一天能写的 prompt 数量有上限，但一个定时循环可以无限运行。

Loop Engineering 的底层逻辑就是这句话：杠杆点从"写更好的 prompt"转移到了"设计更好的 prompt 生成系统"。

Loop Engineering 的五块基石

Addy Osmani 将 Loop Engineering 拆解为五个构建块，外加一个持久化内存：

1. 自动化调度（Automations）—— 循环的心跳

没有调度，就只是一次性运行。形式包括：Claude Code 的 /loop 命令和 scheduled tasks、Codex 的 Automations 面板、GitHub Actions cron 等。你定义节奏，系统自动触发——发现工作、分诊、执行。

2. 工作隔离（Worktrees）—— 并行不碰撞

两个 Agent 同时编辑同一份代码就是灾难。Git worktrees 让每个 Agent 拥有独立的工作目录和分支，互不干扰。Codex 内置了 worktree 支持，Claude Code 提供了 --worktree 标志。

3. 技能（Skills）—— 停止每次从零解释项目

一个 SKILL.md 文件编码了项目约定、构建命令、代码规范和领域知识。没有 skills，loop 每次从零推导整个项目——这就是 Addy 所说的"意图债务"（Intent Debt）。有 skills，知识和约定只写一次，循环自动累积。

4. 连接器（Plugins & Connectors）—— 让 Loop 真正做事

只读文件系统不够。MCP 连接器让 loop 读写 Linear tickets、发送 Slack 通知、查询数据库、创建 GitHub PR。Codex 和 Claude Code 都支持 MCP 协议，Connector 写一次就能通用。

5. 子 Agent 分离（Sub-agents）—— 制造者与检查者分开

这是最重要的结构性模式。写代码的 Agent 不能评判自己的工作。第二个 Agent（不同的 prompt，有时用更强的模型）负责验证。这种分离是 unattended loop 能让你安心走开的唯一保障。

+ 持久状态（Memory/State）

模型没有跨会话长期记忆。Loop 必须读写持久化的东西：一个 STATE.md 文件、一个 Linear board。好的状态文件回答三个问题：当前在做什么？上次尝试了什么、结果如何？什么在等人工处理？

7 个经过生产验证的 Loop 模式

Cobus Greyling 发起了 GitHub 仓库 cobusgreyling/loop-engineering，整理出 7 个真实生产级别的 loop 模式，每个都附带失败案例和成本估算：

模式	节奏	成本	核心功能
Daily Triage	每日	低（~50k tokens）	每天早上自动生成"当前需要关注什么"的报告
PR Babysitter	5-15 分钟	高（~250k tokens）	监测新 review comment 并自动回应修复
CI Sweeper	5-15 分钟	极高（~500k tokens）	发现 CI 变红 → 定位 root cause → 生成修复
Dependency Sweeper	6 小时-1 天	中	自动检测过时依赖，生成安全补丁 PR
Changelog Drafter	每天	低	汇总 commit 和 PR，自动生成更新日志草稿
Post-Merge Cleanup	6 小时-1 天	低	Merge 后清理分支、检查遗留 TODO
Issue Triage	2 小时-1 天	低	自动分类新 issue、打标签、分配 reviewer

真实翻车案例

仓库里记录了不止一个翻车故事，比成功案例更有价值：

CI Sweeper — 第 4 天就关停。 跳过 L1 报告期直接上自动修复、没有分支 allowlist、没有预算限制——48 小时内烧了约 800 万 tokens。教训：永远从仅报告开始，逐步开放权限。

PR Babysitter — 无限修复循环。 对 flaky e2e 测试连续 4 次试图通过修改代码"修复"环境问题。解决方案：硬上限 3 次尝试 + flake 分类隔离。

Verifier Theater — 检查者说"过了"，CI 却红了。 原因：verifier prompt 太模糊、没有实际跑测试、和 implementer 用同一模型。解决方案：verifier 必须跑测试并报告输出，prompt 写"找理由拒绝"而非"确认通过"。

三个需要警惕的概念

Loop Engineering 不是银弹。Addy Osmani 提出了三个需要持续警觉的问题：

意图债务（Intent Debt） — 任何你没说清楚的意图，Agent 会用自信的猜测来填补。Skills 是唯一的还债方式。

理解债务（Comprehension Debt） — Loop 越快产代码，你就越落后于自己的代码库。自动化把认知负担从"写"转移到了"读"。

认知投降（Cognitive Surrender） — 最危险的陷阱。Loop 自己运行，你就停止发表意见了。Addy 的警示："设计 loop 时的判断力是解药，用 loop 来逃避思考是催化剂——同样的动作，相反的结果。"

分阶段上线：L1 → L2 → L3

所有 loop 模式都推荐渐进式部署：

• L1（报告期）：仅观察、仅报告，不动手。跑 1 周，校准准确率。
• L2（辅助期）：可以提议修复，但不自动操作。信任建立后再进入。
• L3（自助期）：经过 allowlist 验证后，处理低风险自动化操作。

每个 loop 必须有明确的停止条件、预算上限和 kill switch。

结语

2023 年我们在学怎么写好 Prompt，2024 年我们在学怎么编排多个 Agent，2025 年我们在学怎么用 Harness 配置 Agent 的工作环境。

2026 年，我们开始设计让 Agent 自主持续工作的闭环系统。

Addy Osmani 结尾那句话值得铭记：

"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

自动化程度越高，你需要的工程判断力就越强。Loop Engineering 不是让你躺平——恰恰相反，它要求你投入更多的人工程度。