Loop Engineering 实战：我如何在一个 ARR 百万级的商业化项目中，让 AI 自己干活

2025 年初，我刚开始做 MewDesign AI 设计 Agent 时，用的还是 Cursor。

那时候，我和 AI 的工作量大概是五五开。它帮我补代码、改文件，我负责确认需求、检查结果、处理它做不好的部分，再亲自把测试、提交和发布接起来。AI 已经很好用，但研发流程仍然牢牢握在我手里。

差不多到了 5 月，有朋友推荐我试试 Claude Code。那是我第一次把持续 Coding 的主工作流从 IDE 搬到 CLI。刚开始并不习惯，但适应以后，我打开 IDE 的次数越来越少。

再后来，我开始高频使用 Codex。Agent 能连续调查一个真实项目、跨文件修改、运行测试、检查 Git 状态、处理 PR，甚至跟踪发布结果。直到今天，我已经很少再自己回去改动代码。

这句话听起来很像「AI 把程序员替代了」，但我的真实感受恰好相反：我并没有退出研发，只是把时间从亲自完成每一步，转向决定什么值得做、怎样做、什么不能做，以及用什么证据证明它真的做完了。

回头看，从 Cursor 到 Claude Code，再到 Codex，真正发生的变化不是模型一次能写多少代码，而是我和 AI 之间的责任边界不断上移。

前段时间，我写过一篇文章解释 Loop Engineering 到底是什么。那篇文章里，我把它概括成一句话：不要再用一轮轮 Prompt 驱动 Coding Agent，而是设计一套系统，让系统去驱动 Agent。

最近，我真的把它做进了 MewDesign。它不是为了验证概念搭出来的 Demo，而是一个 ARR 百万级、持续服务真实用户并产生真实收入的商业化产品。关于产品为什么会出现、想解决什么问题，可以看 MewDesign 的产品故事。

我把原来的研发流程拆成了 5 个 Agent Loop。它们会自己发现工作、调查问题、写方案、开发、Review、发布测试环境，再把证据交回给我。

但这五个 Agent 不会在群聊里互相开会。承载它们的也不是一个新的 Agent 框架，而是一套由 GitHub、Skills 和 Harness 共同组成的工程系统。

这篇文章不公开内部实现，也不记开发流水账。我更想分享的是，这套系统为什么会变成现在这样，以及怎样从零搭出第一个真正能在商业项目里工作的 Agent Loop。

01 - 从帮我写代码，到替我推进研发

在 Cursor 阶段，AI 主要负责代码里的 Inner Loop：理解当前文件、生成修改、修复局部错误。我则负责代码之外的 Outer Loop：发现任务、确认需求、控制范围、判断结果、推进测试和发布。

Claude Code 和 Codex 把 Inner Loop 做得越来越长，但只要每一次状态变化仍然需要我回来回复一句「好的，继续」，我本质上仍然是整套流程的人工调度器。

真正卡住研发效率的，也逐渐不再是代码生成，而是下面这些问题：

• Agent 应该从哪里发现下一项工作？
• 哪些需求已经确认，哪些还只是一种猜测？
• 修改到什么程度才算完成？
• 代码发生变化以后，旧的 Review 和授权是否仍然有效？
• 任务中断后，下一次怎样恢复，而不是从头再来？
• 哪些动作可以自动执行，哪些必须重新交还给人？

这些问题共同组成了代码之外的 Outer Loop：需求、状态、权限、验证、发布和反馈。

所以我做 Loop Engineering，不是为了让 Codex 一次写更多代码，而是为了不再由我亲自推动每一个步骤。系统应该知道当前处于什么状态、下一步允许做什么、需要调用哪一种 Skill，以及凭什么继续。

02 - 很多 Multi-Agent，本质上只是角色扮演

常见的 Multi-Agent 系统大概是这样的：

Planner Agent 负责规划
→ Coder Agent 负责写代码
→ Reviewer Agent 负责检查
→ Manager Agent 负责决定是否完成

看起来分工明确，实际上经常有几个问题。

第一个问题：角色不同，不代表判断独立

如果几个 Agent 使用相同的模型、相似的上下文和同一份错误前提，那么 Reviewer 很可能只是换一种语气重复 Coder 的结论。

给模型加一句「你现在是一个严格的 Reviewer」，不会自动产生真正独立的验证。

真正的独立来自不同的证据来源：代码 Diff、测试结果、真实页面、运行日志、权限边界和用户验收，而不是 System Prompt 里的不同职位名称。

第二个问题：Agent 互相传话，会不断损失上下文

很多 Multi-Agent 编排喜欢让 Agent A 总结给 Agent B，Agent B 再总结给 Agent C。

每一次转述都在压缩信息，也在加入新的解释。最后执行者拿到的可能已经不是原始需求，而是第三手摘要。

如果原始 Issue、决策记录、代码状态和验证证据本来就存在于一个公共系统里，Agent 为什么不能直接读取事实，而要听另一个 Agent 转述？

第三个问题：多 Agent 会把不确定性放大成共识

一个 Agent 猜错了，另一个 Agent 沿着它的前提继续推导，第三个 Agent 再对结果做形式上的 Review。最后三个 Agent 得到了「一致结论」，看起来很可靠。

但这不是共识，只是一条错误被传了三遍。

第四个问题：Agent 数量不是系统能力

增加 Agent 很容易，增加以后也很容易做出一张复杂的架构图。

但更多 Agent 同样意味着更多 Token、更多延迟、更多重复上下文，以及更多需要协调的中间状态。如果任务本身没有明确的权限隔离、并行价值或独立验证需求，一个 Agent 完全可以做完，就没有必要为了 Multi-Agent 而 Multi-Agent。

所以我现在判断一套 Multi-Agent 设计是否合理，不会先问「用了几个 Agent」，而会先问：

这些角色是否拥有不同的触发条件、上下文、权限、完成标准和停止条件？

如果答案是否定的，那它们大概率只是几个不同名字的对话窗口。

03 - 我的 5 个 Agent 彼此不聊天

MewDesign 的 5 个 Agent Loop，大致对应研发过程中的 5 种责任：

这里的 Loop 不是五个常驻在线、轮流发言的 Agent，而是五个会被特定状态唤醒、完成一段工作后停止的独立循环。

这五个角色不是因为我喜欢数字 5，而是因为它们之间恰好存在清晰的权限边界。

Planner 可以读很多，但不能写代码；Builder 可以写代码，但只能执行确认过的范围；Guardian 可以否决，但不能借 Review 之名重做产品；Test Controller 可以操作测试环境，却不能碰生产；Reconciler 只负责证明事情已经收尾，不能把「看起来做完」变成「自动宣布完成」。

它们之间也不需要直接对话。

Planner 不会打开另一个 Agent 会话，对 Builder 说：「我分析完了，现在轮到你。」它只会把方案和状态写回 GitHub。

Builder 醒来以后，也不会相信 Planner 的一段口头总结。它会重新读取 Issue、方案版本、当前代码和最新 Master，再判断方案是否仍然成立。

Guardian 不会相信 Builder 说「测试都过了」。它读取的是当前 PR Head、实际 Diff、CI 和测试证据。

每个 Agent 都面向同一个外部事实系统工作，而不是面向另一个 Agent 的记忆工作。

这也是我认为更合理的 Multi-Agent 形态：

Agent 之间不交换信念，只交换经过持久化的状态和证据。

所以我只会在不同阶段确实需要不同上下文、权限、独立证据或异步等待时，才把任务拆成多个 Agent。没有这些边界时，一个 Agent 完全可以做完，增加角色只会增加上下文转发和协调成本。

04 - 为什么我最后选择 GitHub

设计这套系统时，我可以新建一个数据库，设计一套工作流表，再做一个 Agent 调度后台。

但我最后没有这么做。

因为对于软件研发，GitHub 本身就是一个非常成熟的人机协作系统。

Issue 是天然的上下文容器

一个好的 Issue 里，本来就应该包含：

• 为什么要做；
• 当前有什么问题；
• 用户受到什么影响；
• 讨论过哪些方案；
• 哪些事情不在本次范围；
• 最后做了什么决定。

这些信息同时适合人和 Agent 阅读。

对团队成员来说，Issue 是协作入口；对 Agent 来说，Issue 是一份会持续更新、不会随着对话结束而消失的任务上下文。

相比把所有背景塞进一次 Prompt，Issue 还有一个很大的优势：它允许人随时介入、纠正和补充，而且每一次变化都有记录。

GitHub 已经具备状态机的骨架

Issue 不只是需求文档。

Label、Project Status、Comment、PR、Review、Commit SHA 和 Actions 共同描述了一个任务现在处于什么状态；再加上明确的转移规则，它们就能构成一套研发状态机：

待处理
→ 方案待确认
→ 开发中
→ Review 中
→ 等待测试授权
→ 测试已验证
→ 等待正式发布
→ 完成

状态转移也天然伴随着事件：有人确认了方案、PR 有了新提交、CI 通过、Review 出现 Blocker、测试环境完成验证。

Agent 不需要自己「记住」任务走到了哪里。它只需要在每次运行时重新读取 GitHub 的真实状态，再按照明确的转移规则，判断有没有自己可以处理的下一步。

GitHub 同时适合人与 Agent 协同

如果状态只放在 Agent 专用数据库里，人就很难理解它为什么做出某个决定；如果状态只存在聊天记录里，其他团队成员又无法参与。

GitHub 正好位于中间：

• 人可以在熟悉的 Issue 和 PR 里讨论、确认、否决；
• Agent 可以通过结构化接口读取和写入；
• 评论和 Review 天然形成审计记录；
• Commit SHA 可以精确绑定一版代码；
• Actions 可以提供机器验证证据；
• 通知、权限和团队协作能力都已经存在。

我不需要为了 Agent 重新发明一套研发协作方式。更合理的做法，是让 Agent 学会进入人类已经在使用的系统。

GitHub 让任务可以恢复

Agent 任务会中断，模型会忘记，上下文也会被压缩。

但只要关键状态已经写回 Issue、PR 和 Commit，下一次运行就可以重新构建现场：方案是否确认、代码在哪个分支、当前 Head 是什么、哪些问题已经修复、测试环境是否验证过。

这比「让 Agent 拥有更长的 Memory」可靠得多。

我一直很认同一句话：Agent 会忘，但工程记录不会忘。

现在我觉得还可以再加一句：对研发 Agent 来说，GitHub 就是它和人类共同拥有的长期记忆。

05 - Skills 和 Harness 是怎么在真实项目里工作的

如果只有 GitHub 状态和几个定时触发器，这套系统最多算一个任务调度器。

MewDesign 是一个持续在线的商业化产品。它的研发不只有「写代码」：一个需求会经过调查、方案确认、实现、Review、测试、构建、发布、运行验证和团队同步；线上问题还可能继续进入日志、数据或 Agent 运行轨迹的调查。

这些环节面对的上下文、工具、权限和风险完全不同。把它们全部塞给一个拥有所有权限的 Agent，再配上一份巨大的 System Prompt，并不会得到一个全能工程师，只会得到一个很难知道自己何时越界的模型。

所以我没有写一个万能 Skill，而是把长期经验拆成了很多职责单一的 Skills：协作 Skill 管 Issue、PR 和任务状态；测试 Skill 负责根据改动选择验证方式；发布 Skill 只处理发布前提、授权和执行；运维 Skill 默认只读取运行状态；日志、数据库和 Agent 运行时也各有自己的调查边界。

一次任务怎样在 Skills 之间接力

以测试发布为例。「把这个版本发到测试环境」听起来只是一条命令，在我的 Harness 里却会被拆给几个不同的 Skills。

协作 Skill 先确认需求、PR、准确版本和影响范围，并检查 Review、测试与 CI。随后发布 Skill 才接手环境确认和执行授权，而且授权只绑定当前版本；代码再次变化，旧授权就自动失效。

发布入口返回成功也不是终点，它只能证明请求被接受。运维 Skill 还要以只读方式确认实际运行版本、服务健康和外部接口；出现异常时，再把限定好的时间窗口和问题范围交给日志或数据库 Skill，而不是由发布 Agent 临时越权调查。

只有这些证据都通过，协作 Skill 才会更新 GitHub 状态并同步结果。没有任何一个 Agent 可以凭一句「我觉得完成了」跳过下一层验证。

Skill 固化的不是知识，而是操作契约

我这里说的 Skill，不是一段写着「你是一位资深工程师」的角色设定，而是一份可以被反复调用、持续修改的操作契约。

它们通常都会回答六类问题：适用范围、必读上下文、允许使用的工具、权限边界、完成证据和停止条件。

但真正重要的是，规则会随着事故不断升级。

• 我遇到过发布请求已经成功返回，但运行环境还没有完成更新，于是「请求成功不等于结果成功」成为发布 Skill 的强制验证链。
• 我遇到过授权以后代码继续变化，于是授权必须绑定具体版本，版本漂移后自动作废。
• 我遇到过任务中断后重新运行，于是所有关键动作都要可恢复、可判重，不能重复创建、重复发布或重复通知。
• 我也遇到过调查问题时证据面不断扩大，于是日志和数据库默认从聚合、只读、最小范围开始，而不是先把所有原始信息交给 Agent。

踩过一次的坑，如果只留在我的记忆里，下一个 Agent 还会再踩；把它写进 Skill，并配上可以验证它的工具和测试，它才会变成系统能够复用的工程经验。

Harness 不是工具箱，而是责任路由器

只有 Skills 仍然不够。文档里写着「不要碰生产」，不代表一个拥有全部权限的 Agent 就天然安全。

Harness 一方面为 Agent 提供代码库、GitHub、测试、浏览器、日志、数据和发布能力；另一方面也决定当前任务只能加载哪些能力，谁有权改变哪一类状态，以及什么时候必须切换到另一个专业 Skill。

发布 Skill 不应该自己写 SQL，数据 Skill 不应该顺手重启服务，运维 Skill 不应该替协作 Skill 合并代码。职责分开以后，每个 Skill 才能拥有更小的权限、更清楚的输入输出，以及真正独立的停止条件。

我现在会用下面四层来理解整套系统：

GitHub：保存任务现在处于什么状态
Loop：决定什么时候运行、什么时候停止
Skill：规定这类工作应该怎么做
Harness：提供工具和环境，并把权限、验证、恢复做成硬边界

每个 Loop 唤醒后，不是从一份巨大的万能 Prompt 开始，而是根据当前状态加载对应的 Skills。Harness 负责把任务路由给正确的能力，让它在允许的范围内行动，再把结果和证据写回 GitHub。

这也是为什么同一个模型，放在普通聊天框里和放进一套成熟 Harness 里，会像两个完全不同的执行者。模型能力决定它能想到多远，Skills 和 Harness 决定它能不能在真实项目里稳定地把事情做完。

五个 Agent Loop 是最容易被看见的外壳。真正需要长期积累的资产，是下面那些不断被修正、被版本化、被真实事故检验过的 Skills、工具和约束规则。

06 - 手把手搭建第一个 Agent Loop

如果你也想搭一套 Loop Engineering 系统，我不建议一开始就复制五个 Agent。

先挑一段边界最清楚、结果最容易验证的工作，只搭一个 Loop。等它能够稳定运行，再沿着真实的责任边界拆出下一个。

以前，我通过聊天推动 Codex：

你先分析一下
→ 好的，开始改
→ 再 Review 一下
→ 修复这个问题
→ 可以发布测试环境了

要把这段对话变成一个可以反复运行的 Loop，至少要完成下面六步。

第一步：定义 Trigger

先写清楚什么变化会唤醒 Agent。触发条件应该是机器可以读取的事实，例如 Issue 进入某个状态、PR 出现新的 Commit，或者测试授权绑定到了当前版本。

不要把「有空时看看」或「觉得差不多了就继续」当成 Trigger。无法准确判断的触发条件，只会把人的犹豫搬进自动化系统。

第二步：指定 Context

列出 Agent 每次启动都必须重新读取的事实来源。它不应该依赖上一次对话还记得什么，而应该从 Issue、方案版本、代码、PR、CI 和最新验证记录中恢复现场。

这里最重要的不是塞进更多上下文，而是确定谁才是事实来源。相同信息如果在聊天记录、文档和 Issue 里各有一版，Agent 只会更困惑。

对代码任务来说，Context 还包括 Base、Head 和分支来源。文件 Diff 只能说明改了什么，不能说明这组修改从哪里来、准备进入哪里。

第三步：划定 Authority

明确 Agent 可以改变什么，也要明确它绝对不能改变什么。

例如，Review Loop 可以读取整个 PR、提交 Review、更新问题状态，但不能顺手修改开发分支；测试发布 Loop 可以操作测试环境，却不能因为测试通过就继续发布生产。

我会要求方案同时写清 Scope 和 Non-scope。否则 Agent 很容易为每一项额外修改找到合理解释，最后却把一个小需求做成跨模块改造。

第四步：设计 Verifier

为每个动作指定可以验证结果的外部证据。测试命令退出为零、CI 绿色、页面实际可用和线上版本完成切换，是四种不同层次的证据，不能互相替代。

Verifier 最好使用执行者没有用来得出结论的证据。否则所谓验证，很可能只是让 Agent 再肯定自己一次。

第五步：定义 Stop

提前列出必须停止并交还给人的情况，例如需求存在歧义、方案版本已经变化、PR Head 与授权版本不一致、修改越过 Non-scope，或者任务触及生产数据和资金逻辑。

一个可靠的 Loop 不只是知道什么时候继续，也必须知道什么时候闭嘴。

第六步：约定 Write-back

最后规定 Agent 要把结果写回哪里，以及至少留下哪些证据。下一次运行应该只依靠这些持久化记录，就能判断上一次做了什么、做到哪一步、为什么停下。

在 MewDesign 里，它们会变成可以被系统读取的状态变化：

• 一个符合条件的 Issue 进入待处理，Planner 才会开始调查；
• 我确认了某个方案版本，Builder 才获得实现权限；
• PR Head 发生变化，Guardian 才重新 Review；
• 当前版本通过 Review 和 CI，并获得精确授权，Test Controller 才能发布；
• 正式分支被人工合并以后，Reconciler 才能做收尾。

每个 Agent Loop 都可以抽象成同一个结构：

Trigger：什么状态变化会唤醒我？
Context：我必须重新读取哪些事实？
Authority：我被允许改变什么？
Verifier：什么证据说明动作成功？
Stop：出现什么情况必须停止？
Write-back：结果写回哪里？

例如，一个最小的 PR Review Loop 可以这样定义：

Trigger：PR Head 发生变化，并进入待 Review 状态
Context：原始 Issue、已确认方案、Scope / Non-scope、Base、Head、Diff、CI
Authority：提交 Review、标记 Blocker、更新 Review 状态；不能修改开发分支
Verifier：结论绑定当前 Commit SHA，并引用代码、测试或页面证据
Stop：需求不清、Head 再次变化、出现超出权限的高风险问题
Write-back：把结论写回 PR，并同步 Issue 状态

这已经是一个完整的 Loop。它不需要另一个 Agent 给它派活，也不需要永远保持一段对话。每当触发条件成立，它重新读取事实、在权限内行动、留下证据，然后停止。

这六个问题，比给 Agent 写一段很有气势的角色 Prompt 更重要。

因为 Prompt 解决的是「它应该怎么想」，状态机解决的是「它现在能不能做」。驱动系统的也不再是人的下一句话，而是共享状态发生了变化。

07 - 人不是退出 Loop，而是从执行者变成授权者

做自动化时，经常有人把 Human in the Loop 理解为「Agent 做完以后让人点一下确认」。

我觉得这还是太粗了。

人的价值不是给 Agent 的结果盖章，而是在高后果的状态转移上拥有最终决定权。

在 MewDesign 里，我保留了几类明确的人类 Gate。

方案 Gate

Agent 可以调查和提出方案，但只有我确认了某一个具体版本，Builder 才能开始实现。

如果方案后来被修改，旧授权自动失效。这样可以防止 Agent 拿着一句模糊的「可以」去执行已经变化的需求。

代码版本 Gate

测试授权会绑定到具体的 Commit SHA，而不是一句宽泛的「这个 PR 可以发」。

只要 PR 又有新提交，代码已经不是我确认过的那一版，旧授权就不能继续使用。

生产 Gate

测试环境可以在边界清楚、证据充分时自动推进，但正式环境仍然需要独立确认。

支付、权限、数据库迁移、生产数据和流量切换等高风险工作，也不会因为 Planner 判断方案清楚就自动进入实现。

同样的边界也适用于整套 V1。它不会自动决定存在产品歧义的需求，不会自动执行数据库迁移、生产数据写入或流量切换，也不会自动合并正式分支、发布生产环境，或者在证据不足时宣布完成。

这些不是系统暂时遗漏的功能，而是我有意保留的责任边界。它们只会随着验证能力逐步开放，不会因为模型能力变强就一次性交出去。

这套设计并没有减少人的权力，而是减少了人必须亲自执行的步骤。

我不需要守在终端前告诉 Agent 下一条命令是什么，但我仍然决定：什么值得做、哪一版可以进入共享环境、什么时候可以承担生产后果。

Agent 的权限应该来自长期可靠性，而不是一次漂亮 Demo。

08 - Loop Engineering 的核心不是循环，而是闭环

表面上看，这套系统自动化的是 Issue、代码、PR 和发布。

但我觉得更准确的说法是：它自动化了状态和证据的流动。

Planner 把需求证据写回 GitHub；Builder 从共享状态中重新读取它，再把实现证据写回去；Guardian 和 Test Controller 也遵循同样的方式。没有 Agent 直接把结论交给下一个 Agent，所有交接都先变成可读取、可核验的工程记录。

每个角色只完成自己的一小段，却共同形成了一个可以持续运行、可以中断、可以恢复、也可以追责的闭环。

所以现在如果让我重新解释 Loop Engineering，我会这样说：

Loop Engineering 不是让 Agent 一直跑，而是把目标、状态、权限、证据和停止条件设计成一个可以反复运行的系统。

以前我常说：AI 做执行，人做判断。

现在我觉得还要补一句：

GitHub 保存共同上下文，状态机决定谁可以继续，证据决定事情是否完成。

MewDesign 的这套实践不是一个通用答案，但它至少让我确认了一件事：

未来的软件工程不会只是「一个人带着一个更强的编码 Agent」。它更像是人和多个受约束的 Agent，共同工作在同一套共享、持久、可审计的工程状态上。

而真正值得设计的，也从来不是 Agent 之间该聊什么。

是它们各自该负责什么，以及什么时候必须闭嘴。

如果你想看看这套工程系统最终支撑的产品，可以直接体验 MewDesign AI 设计 Agent，或者查看 MewDesign 使用文档。