Harness vs Loop Engineering：2025 DevOps工具深度对比

六月初，AI 圈被一句话点燃了

2026 年 6 月 7 日，OpenClaw 作者 Peter Steinberger 在 X 上发了一条帖子。短短一句话，浏览量直接飙到了 820 万。Tech Twitter 上，有人把它称为「六月最短的争议句」——支持和质疑的帖子刷了一屏又一屏。Firecrawl 的博客写得很直白：A six-word sentence has tech Twitter in a chokehold this month.

争议还在发酵，Google 工程师 Addy Osmani 第二天就发表了长文 Loop Engineering，把这个正在发酵的概念正式命名、拆解成可落地的框架。随后一周里，MindStudio、AlphaMatch、Firecrawl 等团队相继发文解读——一个新术语，几乎在一夜之间从「大佬语录」变成了「2026 年 AI 编程的方法论」。

Steinberger 那句话，并非空xue来风。早在 6 月 2 日，Anthropic Claude Code 负责人 Boris Cherny 在 WorkOS 的 Unplugged 活动上说了几乎一模一样的话——这段发言随后被剪成短视频，在 X 上广泛传播：

到 2026 年 3 月，Claude Code 项目本身已 100% 由 Claude Code 自主维护。据他披露，当时已有约 4% 的公开 GitHub commit 来自 Claude Code。这样的工作流，从「手写代码」→「Prompt Agent 写代码」→「写 Loop 让 Agent 自己 Prompt 自己」——三次抽象层级跃迁，全部发生在不到一年的时间里。

Osmani 在博客里引用了上述两位的话，并给出了自己的定义：Loop 是一个递归目标：你定义目的和停止条件，系统自动迭代，直到完成为止。你设计的是「发现工作 → 分发 → 执行 → 检查 → 记录 → 决定下一轮」——而不是坐在 Chat 窗口里，一个 turn 接一个 turn 地打字。

Cherny 说得很清楚：工作并没有变轻松，变的是杠杆点。过去比的是谁 Prompt 写得好；现在比的是谁 Loop 设计得巧。Osmani 也提醒：这还早，Token 成本可以差几个数量级，Verification 比以往任何时候都更依赖工程师本人——但 Codex 的 Automations、/goal，Claude Code 的 /loop、hooks、Sub-agents，骨架已经长进产品里了。一旦看清这个形状，争论该用哪个工具反而次要；关键是你的 Loop 能不能转起来。

什么是 Loop Engineering？

如果你刚在社区里刷过 Harness Engineering——给 Agent 搭环境、定规矩、建反馈——先别慌：很多团队还没完全吃透，Loop 的概念又火了。

Osmani 有个比喻很贴切：Harness 是跑道；Loop 是跑道上的调度系统。 前者管单个 Agent 怎么安全地跑；后者管谁去找活、谁去干、谁去验收、什么条件下收工。

Osmani 把一套能转起来的 Loop 拆成五块积木，加一块外部记忆。不必记工具名，先理解分工。

Automations——Loop 的心跳。 没有定时触发，Loop 就只是你手动跑过一次的脚本。Automations 负责按节奏自动发现工作：CI 昨晚红了、Issue 堆了、某个模块上周刚改过。Codex 有 Automations 面板，Claude Code 有 /loop 和 cron；本质一样——让 Loop 自己去找活干，而不是你每天早上打开 IDE 想「今天让 Agent 干啥」。

Worktrees——并行时不踩脚。 两个 Agent 同时改同一个文件，和两个人没沟通就 commit 同一行一样麻烦。Git worktree 给每个任务独立的 checkout 和分支；Codex 内置了 per-thread worktree，Claude Code 也支持 --worktree 和 subagent 级隔离。并行是 Loop 的乘数，worktree 是并行的前提。

Skills——项目知识外置。 Agent 每次 Session 都是冷启动，Context 里的空洞会被它用自信的错误填满。Skill（SKILL.md）把约定、构建步骤、踩坑记录写进磁盘，Loop 每一轮都能读到。Intent 写一次，Loop 每一轮复用，而不是反复从头解释项目。

Connectors——Loop 碰到真实世界。 只会读文件系统的 Loop 很小。MCP 和各类 Connector 让 Loop 能查 Issue、读 CI 日志、发 Slack、调 staging API。差一步开 PR、差一步更新 ticket，Loop 就还是半成品。

Sub-agents——写的人不要自己判卷。 让同一个模型写完代码再宣布「没问题」，它几乎一定会偏袒自己。Loop 里常见的拆法是：一个 Agent 探索、一个实现、一个审查。Claude Code 的 Task subagents、Codex 的 .codex/agents/ 都是这个思路。Maker 和 Checker 分离，是 Loop 无人值守时还能信得过结果的前提。

State / Memory——Agent 会忘，磁盘不会。 进度、试过的方案、哪些过了哪些没过，必须落在外部——Markdown 文件、Linear board、AGENTS.md，任何形式都行。模型跨 Session 失忆；Loop 能接力，靠的是 State，不是聊天记录。

拼起来：一个晨间 Triage Loop

Osmani 给了一个很具体的例子。每天早上，Automation 自动跑一轮：读昨天的 CI 失败、新开的 Issue、近期 commit，把值得处理的事项分拣出来。每一项开独立 worktree，Sub-agent A 起草修复，Sub-agent B 对照 Skill 和现有测试做审查。Connector 负责开 PR、更新 ticket。Loop 处理不了的，进 Triage inbox 等人看。State 文件记下「试过什么、过了什么、还剩什么」——明天 Automation 醒来，从同一页接着干。

到这一步，Loop 已经能发现工作、写代码、审代码、开 PR、记状态。听起来闭环了。但仔细想一个问题：它怎么知道「做完了」？

Loop 的「完成条件」，通常停在哪里

Codex 和 Claude Code 里的 /goal，是最接近「Loop 自己收工」的机制：写一条机器能检查的停止条件，Loop 一轮轮跑，直到成立——常见是 lint 干净、单测全绿、类型检查通过，Sub-agent 再补一层 diff 审查。对后端、CLI、纯库，这往往够用。

但对 App、Web、跨端 UI，「命令 exit 0」不等于「产品没问题」：界面对不对、真机能不能跑、流程通不通，都不在源码和终端日志里。于是多数 Coding Loop 实际停在代码可合并；验产品这一步，还是人编译、安装、点点点。Loop 名义上在转，验证这条支路往往仍是开环的。

产品验没验过，谁来干？ 做 App、做 Web 的团队，会先撞上这个问题。

Coding Agent 看不见屏幕

团队通常会试三条路，但都很难形成验证子 Loop——Coding Agent 旁边那条能自己转、能判定、能把证据送回去的自动化支路：

1. 人肉测试。 代码 Loop 转得飞起，产品还是你挨个验。人不是 Connector，没法被 /goal 调度，瓶颈只是从 Prompt 挪到了点屏幕。

2. 让 Coding Agent 写 Playwright、XPath。 脚本能进 CI，但 UI 一改就挂，维护成本不低。更致命的是：写测试和判测试往往是同一个 Agent——前面强调「写的人不要自己判卷」，这里恰恰是自己考自己，进了 CI 也不等于 Loop 可信。

3. 上云端视觉大模型逐帧看。 理论上说得通，一次完整回归的截图量，就足以让 Token 账单在 Loop 转完之前叫停——验证太贵，Loop 转不起，又回到 Cherny 那条规律。

三条路要么把你嵌回 Loop，要么让 Agent 同源判卷，要么贵到无法日常运转。

我们缺的不是一个简单的测试框架，而是验证子 Loop。 它至少要具备三件事——也就是前面讲的 Connector、Sub-agents、State，在「验产品」时各自该干什么：

• Connector——连得上真机/浏览器，验完自动把结果送回 Coding Agent，不用人截图粘贴
• Sub-agents——点的和判的不是同一个 Agent，不能自己说自己过了
• State——验过什么、哪一步挂了，写进文件；别只留在聊天记录里

换句话说，要实现 AI 研发的 Loop 闭环，就必须让 AI 实现 E2E 测试。这一点在移动端领域尤为重要。

拼起来：一条带「验产品」的功能交付 Loop

从几个月前开始做 Munk AI，功能很简单：让 AI 控制 Android 和 iOS，去做真机 E2E 测试。 它能接到 Cursor、Claude Code、Trae 的日常开发流程，跑在你本机。

还是用一个例子来说明——开发「删除账号」功能，lint、单测、真机验证都过，才开 PR。

1. 你先用自然语言把需求说清楚，比如：「用户可以在设置页删除账号，确认后回到登录页，再次登录时旧数据不可见。」
2. Coding Agent 据此写代码，把 App 装到手机或浏览器上——这一步和平时一样。
3. 接下来交给 Munk。 它先看需求，再看代码 Diff 摘要，再在设备上按用户路径操作一遍：设置 → 账号 → 删除 → 确认。然后将操作记录交给另一个 Agent 来判定：测试是否通过。
4. 第一次可能过不了。比如确认弹窗被键盘挡住，点不到「确认」。这时候，判定的 Agent 不会只丢一句「失败了」：它把卡在哪一步、当时屏幕长什么样打包送回 Coding Agent。Agent 改代码、重新安装，自动接着验——条件没满足，就不停。
5. 第二次通过了，Coding Agent 再去开 PR。

整条链路就是：你说清要什么 → 系统自动跑 → 搞不定的带着证据回来 → 下一轮接着干。差别在于，收工条件里多了一条——产品在真机上真的验过了。

写在最后

不管是 Harness Engineering 还是 Loop Engineering，最终目标都是为了：让 AI 工作表现更稳定，让 AI 工作时间更持久，让 AI 工作能更自主。

Munk AI 的目标，就是：打通移动端 AI 真机测试这条链路。Loop Engineering 要在移动端更稳地落地，就离不开 AI 真机测试。

Munk AI 是我们做「移动端 AI 测试」这条支路的开源尝试，还在早期。如果你也在用 AI 写代码、苦于总要自己点点点，欢迎一起来试：

• 安装体验、文档与更新：munk.sh
• Star 开源仓库：github.com/chaxiu/munk…
• 关注 X / Twitter，看后续实践与更新：x.com/iBoyCoder
• 关注公众号「朱涛的自习室」：Loop Engineering、AI 测试与 Munk 的落地笔记会陆续更新