最近 AI 编程圈有两个词特别热：Harness Engineering 和 Loop Engineering。
前者听起来像一套新工程方法，后者听起来像又一个新范式。再加上 Skills、MCP、Sub-agent、Worktree、Memory 这些词一起出现，很多文章越写越长，最后给人的感觉是：如果不把这一堆概念都学完，自己好像马上就要被 AI 编程时代淘汰了。
我觉得没必要这么焦虑。
这篇文章想讲清楚一件事：Harness Engineering 和 Loop Engineering 都有价值，但它们不是一栋新的高楼大厦。更准确地说，Harness 是把 AI 编码 Agent 关进真实工程流程的一套“马具”，Loop 是在 Harness 上方加的一层调度和评估。
真正值得研发工程师关心的，不是又多了几个英文名词，而是我们的工作重心正在变：从亲手写每一行代码，变成设计一套能持续产出可信代码的系统。
先把两个概念放回正确位置
如果只用一句话解释：
Harness Engineering 解决的是“怎么让 AI 在工程约束里干活”；Loop Engineering 解决的是“怎么让这个干活循环自己启动，并且有东西检查结果”。
这里最容易混淆的是：很多人会把 Skills、MCP、Sub-agent、Worktree、Memory 都塞进 Loop Engineering 里，然后说 Loop 是一个全新的体系。
但仔细拆开看，这些东西本来就是 Agent 系统里的能力。
| 概念 | 更准确的位置 | 它解决什么 |
|---|---|---|
Skills | Context Engineering | 把团队经验、流程、模板按需喂给模型 |
MCP | Tool System | 让 Agent 连接日志、监控、数据库、设计稿等外部工具 |
Sub-agent | Multi-Agent | 把复杂任务拆给多个角色协作 |
Worktree | 多 Agent 隔离策略 | 让多个任务并行改代码时互不污染 |
Memory | Memory System | 把长期上下文、决策和经验留存下来 |
Harness | 工程约束层 | 让 Agent 在规范、验证和权限里行动 |
Loop | 调度与评估层 | 让 Agent 自动醒来，并判断产出是否合格 |
所以，当你看到一篇文章把这些全都叫作 Loop Engineering 的组成部分时，要稍微警惕一下。不是它们不重要，而是边界被拉得太宽了。边界一宽，概念就容易变成筐，什么都能往里装。
Harness 到底解决什么问题
我们先从最熟悉的场景说起。
假设你直接给 AI 一个需求：“帮我做一个活动页”。传统 Prompt 工程里，最常见的翻车路径大概是这样：
第一轮，意图没讲清楚，AI 写出来的页面和你想象的不一样。
第二轮，你来回补充了很多细节，页面终于能看了，但代码结构很散，文件很大，状态逻辑绕来绕去，后面谁维护谁头疼。
第三轮，为了赶进度，你先合进去。结果下次产品要改规则、加埋点、接灰度，发现这坨代码根本没有可迭代性。
这个问题的本质不是模型不会写代码，而是模型没有被放进一个工程系统里。
Harness 这个词本来有“马具”的意思。如果把 AI 看成一匹马，Harness 就是缰绳、嚼子、脚镫和鞍具。它不会让马突然变聪明，但能决定马往哪里跑、以什么节奏跑、什么时候停下来。
放到 AI 编码里，Harness 至少包括这几层：
| 问题 | Harness 应该怎么做 |
|---|---|
| 意图不清 | 用结构化需求模板，让 AI 先反述用户故事、验收标准和影响面 |
| 代码不可维护 | 固化 lint、type check、模块边界、测试覆盖率等门控 |
| 不复用既有架构 | 让 AI 先读项目结构、依赖图、组件约定和接口契约 |
| 输出不可验证 | 写完后自动跑测试、截图、回归用例和 Review |
| 出错后难恢复 | 保留执行日志、失败上下文、回滚点和修复循环 |
也就是说，Harness 的核心不是“写一个更强的 prompt”，而是把提示词、工具、上下文、验证和恢复机制组合成一个可重复的工程流程。
一个成熟一点的需求落地流程，可能长这样：
Plan：把 PRD 拆成用户故事、验收标准、边界条件、影响面。Design：读取项目里的组件库、包结构、状态管理方式、设计规范。Build：按既有抽象写代码，每写一段就跑局部检查。Verify：用单测、类型检查、端到端测试、截图比对验证主链路。Review：让独立 reviewer 或 evaluator 检查代码、事实和风险。
这时候 AI 不再是“聊天框里的代码生成器”，而更像一个被工程体系约束的协作者。它可以很快，但不能乱跑；它可以自动修，但必须留下证据。
那 Loop Engineering 又是什么
Loop Engineering 这波热度，大致来自 2026 年 6 月初的一组讨论。Peter Steinberger 在 X 上聊到工程师的工作越来越像设计循环，Boris Cherny 跟进说自己的工作就是写循环，Addy Osmani 后来写文章把这个概念系统化，提出 Loop 位于 Harness 上方一层。
这个命名是有价值的，因为它把一个以前经常被忽略的位置单独拎了出来：Agent Loop 的边缘。
什么叫边缘？
Agent Loop 内部，是模型在一轮一轮地思考、调工具、看结果、决定下一步。Skills 在里面，MCP 在里面，Sub-agent 也在里面。
Loop Engineering 真正处理的是外面两件事。
第一，怎么让 Loop 启动。
以前是人启动：你打开终端，输入一句话，按回车，Agent 才开始干活。现在可以是定时任务、Webhook、CI、告警、IM 消息、工单状态变化。比如每天凌晨自动扫描失败测试，或者线上告警触发一次 incident workflow。
第二，怎么验证 Loop 的产出。
以前也是人验证：Agent 干完以后，你看一眼结果，觉得行就合，不行再让它改。现在可以用独立的 Evaluator Agent、测试流水线、质量门禁、回归截图和审计日志来判断结果是否达标。
所以，Loop Engineering 没有那么神秘。它不是把整个 Agent 体系重新发明一遍，而是在问两个很工程化的问题：
- 这个循环什么时候自动开始？
- 这个循环结束后，谁来判断它有没有做好？
这两件事以前由人站在旁边完成，现在被自动化了。
一个真实一点的例子：线上告警怎么变成修复 PR
我们把 Harness 和 Loop 放在一起看，会更清楚。
假设线上突然出现一个订单状态异常告警。过去的流程通常是：告警响了，研发被叫醒，打开监控，看日志，查订单，翻最近发版记录，猜根因，写修复，跑测试，提 PR，灰度上线。
如果用 Agent 系统来做，大概可以分成两层。
Loop Engineering 负责让事情自动开始：告警系统通过 Webhook 触发 incident workflow，或者 IM 群里有人问“为什么这个订单状态变了”，机器人识别到这是一个可处理的问题，于是启动一次调查循环。
Harness Engineering 负责约束这次调查怎么做：Agent 必须先拉错误堆栈、错误率曲线、最近发版记录；再通过 MCP 查询监控、日志和订单系统；然后对照 Runbook 和历史故障；最后只能在有证据的情况下给出根因假设。对于 P0/P1 问题，它可以生成修复 PR，但合并、回滚和发布仍然要走人工确认。
这套流程里，AI 确实替代了很多低价值动作：查日志、拼上下文、找相似故障、生成第一版修复。
但它没有替代责任。
谁定义了告警等级？谁决定哪些工具能被调用？谁设置了自动修复的边界？谁批准发布？谁为错误修复负责？
还是人。
这也是为什么我不太认同“有了 Harness，就不需要研发工程师了”这种说法。更准确地说，研发工程师不会消失，但工作重心会被抬高。
研发工程师真正该补的能力
如果代码的边际生产成本越来越低，研发工程师最值钱的部分就不再是“我能不能亲手写完这个模块”。
当然，代码能力仍然重要。你看不懂代码，就很难判断 AI 写得对不对。但真正拉开差距的，会变成下面几类能力。
1. 把模糊需求翻译成可执行规格
AI 最怕的不是需求复杂，而是需求含糊。
“做一个营销活动页”这种需求，对人来说可以边聊边猜；对 Agent 来说，如果没有结构化规格，很容易生成一个看起来能跑但完全不贴业务的页面。
未来研发工程师要更擅长把模糊需求拆成：
- 用户故事：谁在什么场景下需要什么能力。
- 验收标准：怎样算完成，异常态怎么处理。
- 影响面：会不会影响登录、支付、分享、埋点、AB 实验。
- 约束条件：哪些组件必须复用，哪些接口不能改，哪些风险必须拦住。
这不是产品经理一个人的事。因为只有懂工程的人，才知道哪些需求描述会在实现里变成坑。
2. 设计 Harness，而不是只使用 Harness
很多人会把 Harness 理解成“给 AI 准备几条规则”。这太浅了。
真正有价值的是设计一套别人也能复用的工作系统。比如：
- 什么时候必须先写计划，什么时候可以直接修小 Bug。
- 哪些项目上下文应该放进
Skills，哪些应该用 MCP 实时查询。 - 哪些检查放在本地，哪些检查放在 CI。
- 哪些任务允许 Agent 自动开 PR，哪些必须只给建议。
- 哪些失败可以自动重试，哪些失败必须升级给真人。
过去我们常说 talk is cheap, show me the code。但在 AI 编程越来越便宜以后，这句话会发生一点变化：code is cheap, show me the system。
你能不能写出一段代码，当然还重要；但你能不能设计一套让 AI 稳定地产出好代码的系统，会更重要。
3. 建立验证意识
AI 编程最危险的地方，不是它写错，而是它把没验证过的东西说得像真的。
所以 Harness 时代最值得优先建设的，不一定是更复杂的生成流程，而是更扎实的验证流程。
比如：
- 改 UI 后必须跑 Playwright，并保存截图。
- 改接口后必须跑契约测试。
- 改数据口径后必须给出 SQL、样本和边界说明。
- 引入新依赖前必须查项目包管理和许可证约束。
- 总结里不能写“测试已通过”，除非命令真的跑过并有输出。
这类东西看起来不酷，但它决定 AI 结果能不能进生产。
当模型越来越会生成，工程师要越来越会要求证据。
4. 做责任链路的守门人
有些事情不是 AI 做不到，而是 AI 不应该被允许单独做。
比如权限变更、生产发布、数据删除、安全策略调整、财务相关操作。哪怕 Agent 已经能给出很合理的建议，最终也需要一个自然人来承担责任。
这也是 human-in-the-loop 不会消失的原因。不是因为人类永远比 AI 强，而是因为责任、授权和问责必须有明确主体。
研发工程师未来会更像一个系统守门人：上接业务，把模糊目标变成可执行规格；中间设计 Harness，让 Agent 在边界内行动；下接工程现实，用测试、监控、审计和发布机制守住底线。
别被概念吓到，先从一个小 Harness 开始
如果你现在还没有团队级 Harness，不用一下子搭完整体系。最小版本可以很简单：
- 为项目写一份 AI 协作规则，明确目录结构、命名、验证命令和禁止事项。
- 把最常重复解释的流程做成一个
Skill，比如“如何新增一个页面”或“如何排查支付失败”。 - 给关键任务加一个验证门控，比如
npm run typecheck、核心单测或 Playwright 主链路。 - 让 Agent 在总结里必须写清楚：改了什么、跑了什么、哪些没验证。
- 对高风险动作加人工确认，尤其是发布、删除、权限和生产数据操作。
这就是一个很小但有效的 Harness。
等这层跑稳，再考虑 Loop：哪些任务可以被定时触发？哪些告警可以自动调查？哪些 PR 可以让 evaluator 先看一遍？哪些重复问答可以交给 oncall bot？
顺序不要反。
先有 Harness，再谈 Loop。没有 Harness 的 Loop，只是让一个不受约束的 Agent 更频繁地自动跑起来。那不是自动化，是把风险放大。
最后
Harness Engineering 不是研发工程师的替代品，Loop Engineering 也不是一个需要重新学习的大而全范式。
更朴素地说，Harness 是把 AI 放进工程约束里，Loop 是让这个工程循环能自动启动、自动评估。它们真正改变的，是研发工程师的工作重心：少一点重复编码，多一点规格设计、系统设计、验证设计和责任设计。
所以以后再看到一个新概念火起来，可以先问自己三个问题：
- 它在 Agent 系统里到底属于哪一层？
- 它解决的是生成问题、工具问题、上下文问题、记忆问题、协作问题、约束问题，还是调度评估问题？
- 它是新能力，还是旧能力被重新命名？
能把这三个问题想清楚，就不容易被热词带着跑。
AI 是马力，Harness 是马具，Loop 是让马按时出发并回场验收的机制。但要决定往哪跑、跑多远、什么时候停，还是需要那个坐在马背上的人。
这也是研发工程师接下来最值得升级的方向：不是跟 AI 比谁写代码更快，而是学会设计一套让 AI 稳定、可控、可验证地工作的系统。
参考资料
- Addy Osmani：Agent Harness Engineering
- Addy Osmani：Loop Engineering
- Peter Steinberger 关于 Loop Engineering 的 X 讨论：X 原帖
- Boris Cherny 关于“写循环”的讨论：X 原帖
- OpenAI Agents SDK 文档：Agents
- Anthropic：Model Context Protocol
- Anthropic Claude Code 文档：Skills