5 天前，GitHub Blog 刊出一篇被技术社区反复转发的术语指南：Decoding the new AI lingo: Loops, harnesses, squads, hill climbing… oh my!。作者 Cassidy Williams 把 2026 年 agent 圈最热的一批新词打包做了解释。这批词里，loop engineering 和 harness engineering 的混淆率最高——Towards AI 在 7 月的对比文章 Loop Engineering vs. Harness Engineering 干脆把副标题定为 “why most teams confuse them”。
混淆情有可原：这两个词都涉及工具、验证器、状态管理和可观测性，单看组件清单几乎分不出差别。但它们描述的是 agent 系统的两个不同控制层——一个管 agent 内部怎么跑，一个管 agent 外部被什么框住。这篇文章拆开两大范式的起源和内部结构，解释 Squad 这类多 agent 编排层为什么恰好是两者的交汇点，最后给出一套可操作的选型策略。
两大范式的定义与起源
两个词的时间线都集中在 2026 年上半年，但走红路径截然不同。
Harness engineering 的出处相对清晰。这个词通常被归给 HashiCorp 联合创始人、Terraform 作者 Mitchell Hashimoto，出处是他 2026 年 2 月初的博客，核心原则后来被反复引用：agent 每犯一次错，工程师就应该构建一个机制，保证它永远不再犯同一个错。2026 年 2 月 11 日，OpenAI 工程师 Ryan Lopopolo 发表 Harness engineering: leveraging Codex in an agent-first world，用一个几乎零手写代码的生产应用验证了这个模型，口号是 “Humans steer. Agents execute.”（人类掌舵，agent 执行）。LangChain 后来把它压缩成一个公式：Agent = Model + Harness。
GitHub Blog 的比喻更直观：harness 一词来自马具。模型是马的原生力量，harness 是套在马身上、把力量安全导向有用方向的整套装备——工具、权限、记忆、上下文、编排。按这个定义，GitHub Copilot 本身就是一个 harness：它把模型接入代码库、编辑器、PR 和终端，模型离了这套装备什么都做不了。
Loop engineering 则是从一线实践里长出来的。Claude Code 的作者 Boris Cherny 的说法被引用得最多：
I don’t prompt Claude anymore. I have loops running that prompt Claude… my job is to write loops.
（我不再逐条给 Claude 写提示词了，有循环在替我提示它……我的工作是写循环。）
OpenClaw 作者 Peter Steinberger 表达过同样的意思：你应该设计的，是那些去驱动 agent 的循环。Addy Osmani 随后给这个模式正式命名，LangChain 在 2026 年 6 月的 The Art of Loop Engineering 里把它整理成四层循环栈。
一句话区分两者，比任何组件清单都准：**Harness Engineering 设计 agent 的约束框架，关注一次任务的受控执行；Loop Engineering 设计 agent 的运行时循环，关注任务如何持续进入系统、结果如何被测量、历史 trace 如何改进下一次运行。**前者是治理问题，后者是运转问题。
Loop Engineering：设计 agent 的运行时循环
四层循环栈：从 agent loop 到 hill climbing
LangChain 的四层拆解是当前最清晰的框架。
第一层是基础执行循环（agent loop）。模型接收上下文，决定调用哪个工具，读取工具结果，继续推理，直到任务完成或停止条件触发。LangChain 的表述很直接：agent 的本质就是模型在循环里调用工具，直到任务完成。LangChain 的 create_agent 和 OpenAI 的 function calling loop 都是这个层面的实现。
第二层是验证循环（verification loop）。在 agent loop 外面套一个 grader：测试、lint、CI、链接检查这类确定性工具，或者 LLM-as-judge。输出不达标，就把结构化反馈送回模型重新执行。LangChain 的文档 agent 例子里，grader 会检查链接是否有效、CI 是否通过、diff 是否越出了被要求的范围。这一层回答的问题是：这次输出到底达没达标。
第三层是事件驱动循环（event-driven loop）。到这里，agent 的入口变了：不再等人输入，而是响应 webhook、cron、Slack 消息、文档更新。GitHub Blog 描述的 “AI-native cron job”——定时拉取 issue 列表，让 agent 汇总，检查输出，异常时升级给人——在这一层才完整成立。agent 从”被调用的工具”变成”更大系统里持续运行的组件”。
第四层是轨迹改进循环（hill-climbing loop）。每次运行都会留下 trace：模型做了什么、调了哪些工具、grader 给了什么反馈。让一个分析 agent 读这些 trace，找出失败模式，改写 prompt、工具说明甚至 grader 本身。关键细节是：第四层的反馈箭头要伸进 agent loop 内部，直接改变下一次运行的方式，而不是只生成一份给人看的报告。
LangChain 的判断是：多数团队已经在前两层，增量空间在后两层。LangWatch 补了一个更冷峻的视角：verification loop 和 hill-climbing loop 本质上都是 measurement loop——在无人值守场景里，测量层的质量决定了你只能证明”agent 被触发过”，还是能证明”它正确运行了”。
PEV：被 harness 收编的循环
有意思的是，同一个”循环”概念，在 Augment Code 的 Harness Engineering 指南里被归到了 harness 名下：Plan-Execute-Verify（PEV）循环。PEV 把任务拆成三个阶段——先做显式分解并写下验收标准，再按计划执行，最后对照计划和外部质量标准做验证，阶段切换处全部设门禁。
PEV 和”生成完再检查”的区别是结构性的，不是修辞：
| 维度 | 生成后检查 | PEV 循环 |
|---|---|---|
| 计划 | 无，LLM 直接生成 | 显式分解，附验收标准 |
| 执行范围 | 不受约束 | 受计划约束，每次工具调用过门禁 |
| 验证时机 | 仅事后 | 执行前、运行中、执行后加计划对齐 |
| 反馈信号 | 二元通过/失败 | 带上下文的错误信息回灌给 agent |
| 人的角色 | 审查产物 | 维护 harness，在高杠杆决策点审批 |
注意最后一行：在 PEV 里，人的工作对象从”代码”变成了”harness”。这正是两大范式互相渗透的证据——循环设计到深处必然要固化成门禁，门禁设计到深处必然要闭环成循环。
Ralph loop 与成本边界
GitHub Blog 还提到一个更粗糙的变体：ralph loop。给它一份足够详细的 spec，让它持续工作直到完成——计划、行动、检查，反复循环。这对拆解大型任务有用，但每次重试都在烧 token，成本上限必须在设计时就写死，否则 loop 会变成账单上的黑洞。这也是 loop engineering 的第一设计律：停止条件不是可选项，它和目标本身同等重要。
Harness Engineering：设计 agent 的约束框架
从概率性遵从到确定性约束
为什么在 prompt 里写”遵守我们的编码规范”不够？Augment Code 的论证引用了两组数据。DORA 报告发现，AI 采纳度越高，交付吞吐和交付不稳定性同时上升——省下写代码的时间，很大一部分被重新花在审查代码上。Apiiro 的扫描分析发现，到 2025 年 6 月，AI 生成代码每月引入超过 10000 条新安全发现，比 2024 年 12 月涨了 10 倍。Spotify 的 Honk 系统自 2024 年年中以来合并了 1500 多个 AI 生成的 PR，靠的不是 prompt 写得好，而是验证循环。
根因是架构性的：在 prompt 里要求规范，得到的是概率性遵从；把 linter 接进 CI 阻断 PR，得到的是确定性约束。Harness engineering 的定义由此而来——设计环境、约束和反馈循环，让 AI coding agent 在规模上可靠的一门学科；工程师的工作从写代码，转移到设计”管理 agent 写代码的系统”。
三层结构：约束、反馈、门禁
Augment Code 把 harness 拆成三层，并建议从零起步的团队严格按顺序实施。
第一层，约束层（constraint harness，前馈控制）。在生成开始前收窄解空间：rules 文件、架构 lint、类型系统。OpenAI 的生产系统维护一组 taste invariants——编码约定和可靠性要求，全部作为硬性 CI 失败执行，不是警告。
第二层，反馈层（feedback loop，纠正控制）。把结构化错误信号回灌给 agent，让它自主修正。关键实现细节：lint 消息本身就是 prompt。“检测到违规”需要人来解读；“用 logger.info({event: 'name', ...data}) 而不是 console.log”agent 就能自己修。另一个容易被忽略的点：要禁用 // eslint-disable-next-line 这类行内豁免，否则 agent 学会的第一件事是关掉约束，而不是修复问题。
第三层，门禁层（quality gate，强制执行）。不合格的代码进不了主干。常规 CI 对 AI 代码不够用，一些团队加了 staleness gate，专门拦截与代码库当前策略不符的依赖选择。所有规则设为 error 而非 warn：
// 结构性约束：对 agent 生成的代码做解空间限制
module.exports = {
rules: {
complexity: ["error", { max: 10 }],
"max-depth": ["error", 4],
"max-lines-per-function": ["error", { max: 50 }],
"max-params": ["error", 4],
},
};一个适用于所有三层的警告：过度约束是真实的失败模式。复杂度上限压得太低会拦截合法的重构，拒绝有效模式的 lint 规则只会拖慢 agent。从窄开始，测量，再扩张。
Rules 文件：harness 的声明式接口
Rules 文件是持久化、仓库作用域的指令集，在会话开始时自动注入 agent 上下文。与普通 prompt 的机械区别在于：跨会话存活、由运行时自动注入、作用于整个目录树、支持父子目录层级组合。2025 年 8 月发布的 AGENTS.md 开放标准（OpenAI、Google、Cursor、Factory 等共同推动）让这套约定开始跨工具通用，OpenAI 自己的仓库里维护着 88 个 AGENTS.md 文件。
| 工具 | Rules 文件 | 作用域 |
|---|---|---|
| OpenAI Codex | AGENTS.md | 层级式，从 Git 根到当前目录 |
| Claude Code | CLAUDE.md | 项目根加用户全局 |
| Cursor | .cursor/rules/*.mdc | 项目级 |
| GitHub Copilot | .github/copilot-instructions.md | 仓库级加路径级 |
GitHub 对 2500 多个使用 AGENTS.md 的仓库做过分析，给出的最佳实践是三层边界模式——哪些事永远做、哪些事先问人、哪些事永远不做：
## Always
- 所有通知投递必须记录结构化日志
- 调度逻辑统一使用 UTC
## Ask First
- 新增通知渠道
- 修改重试间隔
## Never
- 未验证 opt-in 就发送通知
- 修改退订流程没有 “Ask First” 这一层，agent 做重试逻辑时就会自作主张选一个间隔。但要清醒：rules 文件只是 harness 的一层，不是全部。LLM 对指令的遵从是概率性的，必须配合 linter 和 CI 门禁这类确定性外层约束，才能在规模上可靠。
测量 harness 是否有效
没有测量的 harness 工程是玄学。Augment Code 列出的指标里最值得抄进周报的四个：任务解决率（agent 改完测试是否真过）、代码流失率（两周内被重写丢弃的比例）、验证税（从首次提交到 PR 批准的额外耗时）、Pass@1（不靠重试一次做对的比例）。基线数据同样值得记住：头部 agent 在 SWE-bench Verified 上的解决率约 65%-76.8%，但 METR 发现其中不少能通过 benchmark 的 PR，真实维护者根本不会合并。Vercel 还报告过一个反直觉的结果：减少 agent 可用的工具数量，任务成功率反而上升。这大概是 harness 哲学最好的注脚——约束不是能力的敌人。
两种范式，一张对照表
| 维度 | Loop Engineering | Harness Engineering |
|---|---|---|
| 关注层 | agent 运行时行为 | agent 外部约束框架 |
| 时间边界 | 任务全生命周期，持续运转 | 单次任务的受控执行 |
| 控制对象 | 触发、验证、停止、记忆、trace 改进 | 工具、权限、上下文、状态、门禁 |
| 表达风格 | 过程式：写成可执行的运行规则 | 声明式：写成规则和阈值 |
| 可观测性 | trace 驱动，事后可复盘 | 静态可审计，事前可检查 |
| 典型产物 | cron 接入、webhook、grader、trace 分析器 | rules 文件、lint 配置、CI 门禁 |
| 典型失败 | doom loop、事件洪流、健康误判 | 过度约束、规则被概率性无视 |
| 改进方式 | hill climbing 自动改写自身 | 人工维护，随错误累积演进 |
一个有参考价值的分析视角：LangChain 四层里的 L1、L2（执行、验证）更接近 harness 的能力范围，L3、L4（事件驱动、轨迹改进）才是 loop engineering 的真正增量。这也解释了为什么两者共享那么多组件——它们本来就在同一个系统的不同高度上。
Squad：一个 harness 管理多支 loop
GitHub Blog 的术语表里，squad 指按角色分工的一组 agent：一个规划、一个审查规划、一个构建、一个测试、一个做 code review——像一个真实的团队。fleet 则是并行运行的多个 agent，squad 可以在 fleet 里跑。分工的意义在于：把工作按角色切开，而不是让一个 agent 从头包到尾。
这个概念已经有具体的产品化样本。GitHub 今年 3 月发过一篇 How Squad runs coordinated AI agents inside your repository，介绍开源多 agent 框架 Squad——它跑在 GitHub Copilot CLI/SDK 之上：你描述一个小团队（一个 coordinator 加几个 specialist，每个带一份 charter），coordinator 分派任务，specialist 互相争论，最终交付结果。仓库里的 .squad/ 目录会被自动发现，加载团队 agent、skills、指令和 MCP 服务器。
Squad 的架构正好是两大范式的交汇点：
- 每个 specialist 有自己的 loop——自己的 charter、工具集和验证节奏；
- 整个团队跑在一个 harness 里——coordinator 统一管任务分配、冲突解决和质量控制；
- 团队还有一层自学习：决策被记进 ledger（“这个服务我们选了 Postgres 而不是 Cosmos”，记一次，以后所有 specialist 都遵守）；技能被提取成 skill 文件（第一次摸索出部署流程，第十次直接读文件执行）；人工纠正被固化为指令（说一次”我们不用那个库”，团队不会再推荐它）；
- 每次 specialist 被分派都产生一个 OpenTelemetry span（
squad.subagent），多 agent 扇出在追踪系统里全程可见。
把 LangChain 的公式扩展一下就是：Squad = Harness + N × Loop。这也回答了 squad 为什么容易和另外两个词混淆——它同时是两者的实例。多 agent 编排不是第三种范式，而是两种范式在更高一层的组合。
融合策略：什么时候用哪个
选型的第一判据不是团队规模，是任务的时间形态。
**一次任务、有明确验收点的场景，优先 harness。**改一个 bug、加一个 endpoint、生成一份报告——任务边界清晰，做完就该停。这类场景的可靠性来自约束：rules 文件划边界，lint 给反馈，CI 门禁兜底。Augment Code 建议的起步动作可以直接照抄：审计最近 5 个 agent 生成的 PR，找出反复出现的坏模式，选 3 个本可以拦住它们的约束，写成带修复指引的 lint error，CI 硬失败，然后测量审查时长和缺陷逃逸率的前后变化。
**持续运转、没有终点的场景，必须上 loop。**值守告警、依赖升级、文档同步、issue 分诊——任务会不断自己找上门。这时 harness 的静态约束不够用了：你要设计触发条件（哪些事件可以进来、哪些要合并、哪些只观察）、健康判断（不只是”这次达标吗”，还有”系统还好吗”）、显式停止规则、外部记忆（已完成和未完成的记录写在上下文之外，Markdown 或看板都行），以及分层的人工升级（低风险自动做、中风险给证据等审批、高风险停在建议）。
**多 agent 场景，harness 先于 loop。**在让多个 agent 并行之前，先把单个 agent 的约束框架做稳——否则 squad 里的每个角色都会以自己的方式失控。
按团队规模的粗略路线：3 人以下的团队先做 harness，rules 文件、pre-commit hooks、CI pipeline 的投入产出比远高于单 agent 场景下的 loop 调优；harness 稳定后再引入事件驱动循环；多团队共用 agent 时，才值得搭 squad 这类编排层，并把轨迹改进循环作为平台能力统一建设。
对生产系统，结论没有悬念：**Loop 是能力层，负责 agent 能完成任务；Harness 是治理层，负责 agent 完成任务的方式可靠。缺少 harness 的 loop 会失控，缺少 loop 的 harness 无法持续运转。**两者不是二选一，是分层建设。
结论
Cassidy Williams 在那篇术语指南的结尾提醒：这些词有的会留下来，有的会消失。比词更重要的是底下的四个问题——工作流能否可靠重复、输出如何验证、需要多少人类监督、系统如何持续改进。
2026 年的两条主线，其实是对这四个问题的两种回答。Harness engineering 把可靠性问题转化成工程问题：既然 agent 会犯错，就让每个错误只发生一次。Loop engineering 把人力成本问题转化成系统问题：既然逐轮提示不可扩展，就让循环替人提示。Squad 则证明两者在多 agent 层面可以干净地组合：harness 定边界，loop 干活，trace 驱动整个系统向上爬坡。
对正准备把 agent 推进生产的团队，顺序比站队重要：先约束，再反馈，再门禁；先单 agent，再循环，再多 agent。范式之争会随着下一个热词的到来而过去，但”能力层和治理层缺一不可”这个结构，会留下来。