Loop Engineering：让AI Agent自己转起来的工程方法论GREEN BOOK · PROGRAMMER AI CODING · 课时 01

1.1 先讲一个故事

回想一下你平时怎么用 AI 的。

"帮我把这些截图转成 WebP。""帮我把这个 issue 分类一下。""看看 npm 依赖有没有更新。"

你有没有发现，你在做一件事：你发现问题，然后告诉 AI 去解决。

你发现截图要转格式，你告诉 AI。你发现 issue 没人处理，你告诉 AI。你发现依赖该更新了，你告诉 AI。你像是一个"问题搬运工"——把现实世界里的问题，一条条搬进对话框里。

这个模式有个隐藏的成本：你得一直在场。

你不在，AI 不会自己发现"哦，今天有新 issue 了"。你没想到，AI 不会主动说"哎，依赖该升了"。你跟 AI 的关系，本质上是你在驱动它——你发现问题，它解决问题。

那能不能反过来？

不是"你发现问题，告诉 AI 去解决"，而是让 AI 自己去发现问题、决定优先级、动手解决、最后告诉你结果。

你给它一个角色，而不是一个任务：

你的工作是维护这个项目的健康度。 每天早上 9 点，你自己去看 GitHub 上有没有新 issue，判断要不要处理。 每 4 小时，检查依赖有没有更新，小版本补丁自己升，大版本升之前问我。 每次有人提 PR，你自己去跑测试，过不了就打回去，过了就告诉我一声。 你不确定的事，记在日志里，我每天看一次。

看到了吗？区别在于——你没有告诉它"今天要干什么"，而是告诉它"你的工作是什么"。 它自己决定今天该干什么。你不需要发现问题了再告诉它，因为发现问题本来就是它的工作。

Loop Engineering 就是给 AI 定义"岗位职责"，而不是给它下"任务指令"。

1.2 谁点燃了这把火

2026 年 6 月，两个背景完全不同的人，几乎同时说了同一件事。

Peter Steinberger，奥地利开发者，PSPDFKit 创始人（2021 年出售），2026 年初加入 OpenAI。他在 X 上发了一条帖子："你不应该再亲自给 coding agent 写 prompt 了。你应该设计 loop，让 loop 去 prompt agent。"这条帖子迅速引爆了开发者社区 来源：Addy Osmani 博客引用。

Boris Cherny，Anthropic 公司 Claude Code 的负责人，在同一周接受采访时说了类似的话："我已经不亲自 prompt Claude 了。我有一堆 loop 在跑，它们自己 prompt Claude，自己决定要干什么。我的工作是写 loop。"[来源同上]

两个人，一个在 OpenAI，一个在 Anthropic，做的产品不同，却得出了同一个结论——最会用 Agent 的人，已经不跟 Agent 直接对话了。 他们写"剧本"，Agent 按剧本自己演。

这个想法很快有了工程实现。就在同一时期，Cobus Greyling 在 GitHub 上创建了 loop-engineering 仓库，把这套理念变成了可用的 CLI 工具。而 Addy Osmani（Google Chrome 工程总监，后任 Google Cloud AI 总监）也写了博客详细介绍了这个思路，让 Loop Engineering 进入了更多开发者的视野。

但听完这些来龙去脉，你可能更关心一个实际的问题：它到底能解决什么？

1.3 它在解决什么问题

现在的用法有什么问题

现在大多数人用 AI Agent 还是这样的：

你: "帮我看一下这个 GitHub issue，分类一下"
Agent: 看了，是个 bug 报告，优先级 P1
你: "检查一下 npm 依赖有没有更新"
Agent: 检查了，lodash 有一个安全更新
你: "PR #42 的测试跑过了吗？帮我 review 一下"
...

你有没有发现，每一次都是你先发现问题，再告诉 AI 去解决。你发现 issue 来了，你告诉 AI。你想到该检查依赖了，你告诉 AI。你看到 PR 了，你告诉 AI。你仍然是那个"发现问题的人"，AI 只是"执行工具"，而你实质上是一个"问题搬运工"，你的价值还不如一个 AI。因为 AI 实质性的解决了问题，而你就是在做机械而无意义的问题搬运。

这个过程有三个问题。

第一，你被绑住了。 你得不停的在各种任务间切换，把问题复制给 Agent。

第二，无价值。 人会很累。如果工作是高价值的，问题不大。关键在于搬运问题是一种极其无价值的工作。模型能力越强，这一点就越突出。以前的模型能力不够，你可能还需要辅助模型分析下，现在 Agent 能力越来越强，你几乎就是纯搬运。

第三，规模不经济。 一个项目你还能盯着，三个项目呢？十个项目呢？你盯不过来的。你越依赖 AI，就越发现瓶颈不在 AI 执行的速度，而在你发现问题、分配任务的能力。

Loop Engineering 怎么解决

Loop Engineering 的思路是：把"发现问题"这件事，也从你手上交给 AI。

不是"你发现问题，告诉 AI 去解决"，而是"告诉 AI 你的岗位是什么，它自己去发现问题、决定优先级、动手解决"。

假设你维护一个开源项目，你可以这样写一份 LOOP.md：

你的工作是管理开发团队的日常任务分发。

每天早上9:00，你去看 GitHub Issues 上新进来的任务。
带 @her 标签的直接认领——读完需求，做完，提 PR。
没有 @her 标签的，你自己判断：
- 简单 bug 修复、文档更新——直接做。
- 涉及架构或数据库变动——标记"待审批"，等我确认。
- 拿不准的——记下来，每日报告里问我。

每次提交 PR 后，自动触发三重验证，
全过才能合并到 staging 分支，不会直接上生产：

1. CI 测试——单元测试、集成测试、lint，全部通过。
2. Verifier Agent（独立的审核 Agent）从头 review 你的代码。
   它和你是不同模型、不同上下文，不信任你的代码。
   它会跑额外的测试、检查边界情况、看有没有遗漏。
3. loop-gate 机械检查——基于规则的安全门，触犯禁区就自动退回。

三重验证都过了，PR 进 staging。
你通知我"任务完成，PR 在 staging 等审批"，
我确认后才会合入 main。

如果连续 3 次被 Verifier Agent 打回，自动暂停你的任务分配。

这个 LOOP.md 和我们平时使用 Agent 有什么不同？最大的区别是：

这个版本，你给 AI 的是"岗位职责"——你的工作是什么、什么能做、什么不能做、做完了怎么验收。AI 自己决定今天做什么、怎么做、做到什么程度算"做完"。

注意这里最关键的设计：验证不是一个人说了算。 写代码的 Agent 和检查的 Agent 是分开的（Maker/Checker 分离），而且最底层的检查是机械的（loop-gate），不需要 AI 参与。这在 Loop Engineering 里叫"Verifier Ladder"（验证阶梯）来源：Subhadip Mitra 博客——从 CI 自动化测试到独立 Agent 审核到机械安全检查，每一层都比上一层更可靠、更严格。

只有最顶层的"合并到生产环境"这一步，需要你亲自确认。 其他所有事情——发现问题、判断优先级、动手解决、提交代码、跑测试、代码审查、安全检查——全都是 AI 自己在做。

这才是 Loop Engineering 的核心：把 AI 从一个"等指令的执行者"，变成一个"自己找活干的成员"。

1.4 Loop Gate——最后一道机械防线

用一个实际场景来理解。

假设你维护一个电商网站。你想让 Agent 每天自动检查依赖更新、修一些小 bug、更新文档。但有些东西你绝对不能让它碰——.env 文件里有数据库密码和支付密钥，数据库迁移脚本改错了会崩线上数据，支付模块的代码也不能乱动。

你不可能对 Agent 说一句"别碰重要的文件"就放心了。Agent 再聪明，也有概率犯错。你需要一个程序硬性拦住它。

Loop Gate 的做法是：写一个 gate.yaml 文件，把禁区写清楚。

关键是怎么定义这个文件。你不需要一开始就想得很完美，从最简单的开始：

第一层：想清楚绝对不能碰什么。

对于电商网站，禁区可能是这样：

• .env——所有密钥都在这里，碰了等于泄露凭据
• migrations/——数据库迁移脚本，改错了数据就没了
• payments/——支付模块，出 Bug 等于丢钱
• auth/——认证模块，出 Bug 等于用户登不进来

把这些写进 denylist。Agent 只要试图改这些路径的文件，gate 直接拦住，连提 PR 的机会都没有。

第二层：想清楚什么可以放心让 Agent 自动干。

• 文档文件（docs/、**/*.md）——改错了也没事
• 测试文件（tests/）——Agent 帮你补测试，求之不得
• 依赖配置文件（package.json、requirements.txt）——日常升级，风险低

这些写进 autoMergeAllowlist。Agent 改了这些文件，gate 自动放行并合并，不需要你过目。

第三层：剩下的，就是灰色地带。

Agent 改了一个 API 路由的代码——gate 不拦也不放，标记为"待人工审批"。你第二天早上看到，花 30 秒扫一眼，没问题就点通过。

三层规则定好之后，效果是这样的：

Agent 晚上跑了一次 Loop。第二天你打开电脑，看到三条消息：

• "依赖 lodash 已从 4.17.21 升级到 4.17.22，已自动合并。"（自动放行，安全区）
• "docs/api.md 已同步最新接口信息，已自动合并。"（自动放行，安全区）
• "payments/checkout.js 的修改已暂停，等你审批。"（触犯禁区，暂停）

你没有检查所有代码——大部分 Agent 自己处理了。你只需要关注那几件真正重要的事。这才是 Loop Gate 存在的意义：让 Agent 放手干活，同时你知道底线不会破。

为什么强调"机械"两个字？因为这一切不是 AI 判断的——是程序硬性对照规则文件做检查。Agent 绕不过去，它自己也没法改 gate.yaml（因为 gate.yaml 本身就在 denylist 里）。这和 Verifier Ladder 的思路一脉相承：最底层用机械规则兜底，确保上层出问题时安全底线也不会破。

以上说的都是"为什么"和"理念是什么"。但一套能真正跑起来的 Loop 体系，还需要更具体的工程构件——六个积木块怎么组合、三个核心文件各有什么用。下一节就来拆解这些。

1.5 ■ 学点英语