同一个模型，不同的 Harness ，SWE-bench 上差了 17 题。当模型能力趋于同质化，真正决定 AI Agent 表现上限的，不是它有多聪明，而是它被放在什么样的环境里工作。
2026 年，AI 工程领域达成了一个共识：Harness 比模型重要。Claude Code 、Codex 、Cursor 已经为 agent 构建了成熟的代码执行 harness 。但当 agent 从"写一个函数"升级到"做一个项目"，它还缺一层东西——一个覆盖从想法细化到任务验收的项目管理 harness。
这篇文章聊两件事：为什么 harness 已经成为 agent 表现的决定性因素，以及 Chorus( https://github.com/Chorus-AIDLC/Chorus) 在这个方向上的实践——如何让 agent 拥有完整的迭代环境，而不只是一个代码编辑器。
2026 年初，一组 SWE-bench Verified 的评测数据引起了广泛讨论：Augment 、Cursor 、Claude Code 三个产品，都跑的 Claude Opus 4.5 ，731 道题，成绩差了 17 题。
模型完全一样。差异来自哪里？Harness——包裹在模型外面的那层系统：工具定义、上下文管理、错误恢复、验证循环、子任务编排。
这不是个例。整个行业都在讲同一个故事：模型是 CPU ，Harness 是操作系统。没有操作系统，CPU 再快也只是一块芯片。
| 阶段 | 时间 | 核心问题 |
|---|---|---|
| Prompt Engineering | 2022–2024 | 怎么写好一条指令 |
| Context Engineering | 2025 | 怎么策展所有相关信息（ RAG 、Memory 、工具描述） |
| Harness Engineering | 2026 | 怎么设计环境、约束和反馈循环 |
Mitchell Hashimoto （ HashiCorp 创始人）在 2026 年 2 月首次明确了"Harness Engineering"这个概念：
"Every time the agent makes a mistake, don't just hope it does better next time. Engineer the environment so it can't make that specific mistake the same way again."
每次 agent 犯错，不要寄希望于"下次做对"。改造环境，让它不可能再用同样的方式犯错。
这句话精准地定义了 harness 的本质：不是教 agent 做什么，而是让环境保证 agent 只能做对的事。
2026 年 2 月起，这个认知从个人观点变成了行业共识——而且大家从不同方向抵达了同一个终点。
有人关注可靠性：OpenAI 用 Codex agent 从空 repo 构建完整产品，零行人写代码，发现 harness 的工程设计决定了 agent 能否长时间可靠运行。有人关注学科定位：Martin Fowler 撰文将 Harness Engineering 定位为软件工程实践的新分支——不是 AI 研究的分支，是工程实践的分支。有人关注评估能力：Anthropic 提出 GAN 式 Generator/Evaluator 架构，核心发现是模型不能可靠地评估自己的工作，必须由 harness 提供外部验证环。
还有人把话说得更绝。Stripe 的 Minions 团队——"The Walls Matter More Than the Model"，围墙比引擎重要。Philipp Schmid 从数据视角补了一刀——"The Harness is the Dataset"，harness 捕获的工作轨迹本身就是竞争壁垒。
"2025 Was Agents. 2026 Is Agent Harnesses." — Aakash Gupta
GitHub 上甚至已经有了专门的 awesome-agent-harness 合集( https://github.com/AutoJunjie/awesome-agent-harness)，收录各家关于 harness 的文章、工具和实践。
当前主流的 agent harness 都聚焦在代码执行层：
Claude Code 构建了最完整的六层架构：
Codex 走的是云沙箱路线：
Cursor 是 IDE 原生集成：
这些 harness 各有所长，但解决的问题是同一类：agent 怎么写代码。包括怎么读文件、怎么调工具、怎么跑测试、出错了怎么恢复、上下文满了怎么压缩。
当 agent 从单任务（修一个 bug ）升级到多任务（做一个 feature ），从单 agent 升级到多 agent 团队协作，代码级 harness 就不够用了。
缺失的环节：
类比一下：现有的 harness 给了 agent 一个配置齐全的工位——双屏显示器、机械键盘、IDE 全装好。但没有给它一个项目部——没有需求评审、没有任务看板、没有 Sprint 节奏、没有验收标准。
Agent 知道怎么敲键盘，但不知道为什么敲、敲完给谁看、下一步做什么。
Chorus 的定位不是替代 Claude Code 或 Codex——它在这些代码级 harness 之上，提供项目级 harness，让 agent 拥有从想法到验收的完整迭代环。
| 阶段 | 谁在做 | 做什么 |
|---|---|---|
| Idea | 人类 | 抛出一个想法，可以很粗糙 |
| Elaboration | PM Agent → 人类 | AI 不直接开干，而是向人类提问："目标用户规模？""需要离线支持吗？"人类回答，AI 验证自洽性，有矛盾就追问，直到共识 |
| Proposal | PM Agent | 产出文档草案 + 任务依赖图（ DAG ） |
| Approval | Admin / 人类 | 审批方案，通过后任务才实体化 |
| Execute | Developer Agent | 认领任务，在 Claude Code 中执行，自检验收标准后提交 |
| Verify | Admin / 人类 | 逐条验证验收标准，通过或打回。下游任务自动 unblock ，下一波开始 |
这不是一个"任务管理看板"。这是一个让 agent 知道自己在整个项目中处于什么位置的运行时环境。
每个阶段的边界都是 harness 级别的约束，不是"建议 agent 遵守的最佳实践"：
这就是 Hashimoto 说的那件事：不是教 agent "你应该先理解需求再动手"——环境保证了它必须先理解需求才能动手。
传统工作流的信息流向是单向的：
人写 Prompt → AI 执行 → 人检查结果 → 不满意改 Prompt → AI 重来
这个模式的致命问题：agent 在错误的理解上高效执行。它可能写了 500 行完美的代码，但解决的是错误的问题。然后你改 prompt 让它重来，它又写了 500 行完美的代码，解决的是另一个错误的问题。
Chorus 的 Elaboration 机制反转了对话方向：
人提想法 → AI 提问 → 人回答 → AI 验证答案自洽性 → 有矛盾就追问 → 共识 → 再开干
PM Agent 读完一个 Idea 后，不是直接开干，而是生成一组结构化问题。比如人说"我要用户认证"，PM 会问：
如果人回答了"需要离线支持"但又说"要实时同步"，PM 会追问——因为这两个需求在某些场景下是矛盾的。
Harness 的价值不只是"让 agent 做得快"，更是"让 agent 做对的事"。Elaboration 是 Chorus 在 harness 层面对需求质量的保障：不是靠 agent 的"理解力"，而是靠结构化问答的流程约束。
当一个 Proposal 产出 8 个任务、3 层依赖时，Chorus 构建 Task DAG （有向无环图），并用 Wave 模型管理执行节奏：
Wave 1: [Task A] [Task B] [Task C] ← 无依赖，可并行
↓ ↓
Wave 2: [Task D] [Task E] ← 依赖 Wave 1 的任务
↓
Wave 3: [Task F] ← 依赖 Task E
关键设计决策：不是在执行时强制阻塞，而是在验证时卡住——上游没验收，下游就不会开放。
这正是 Stripe 说的 "The Walls Matter More Than the Model"：DAG 就是墙。Agent 不需要"理解"依赖关系——环境本身阻止了乱序执行。
Anthropic 的工程博客指出：模型不能可靠地评估自己的工作。这是他们提出 GAN 式 Generator/Evaluator 架构的核心前提。
Chorus 在项目层面实现了这个原则：
Agent 说"做完了"，和 Admin 验证过"确实做完了"，是两件完全不同的事。Chorus 把这个区分编码成了 harness 的一部分，不依赖任何人"记得去检查"。
回到最初的问题：行业已经证明 harness 比模型重要。SWE-bench 17 题的差距，来自代码执行层的 harness 差异。
那在项目层面呢？
想象一下：10 个能力相同的 agent 组成一个团队。一组在没有项目 harness 的情况下协作——Team Lead 用自然语言分配任务，agent 自己决定执行顺序，做完自己汇报，没有验收环节。另一组使用项目 harness——需求经过结构化细化，任务按 DAG 编排，执行有 session 追踪，完成有验收闭环。
哪组的产出更可靠？
人类软件团队几十年的工程实践早就给出了答案：个人能力 × 协作效率 = 团队产出。再优秀的工程师，在没有 Jira/Linear 、没有 Sprint 、没有 Code Review 的环境里远程协作，也会陷入混乱。
Agent 团队没有理由例外。Chorus 做的事情，本质上就是给 agent 团队一个 agent-native 的 Jira——不是把人类的项目管理工具套在 agent 身上，而是从 agent 的工作方式出发，重新设计需求细化、任务编排和验收闭环。
代码级 harness 解决了 **"每个 agent 单独工作时的表现"**。项目级 harness 解决了 **"一群 agent 一起工作时的表现"**。前者的价值已被 SWE-bench 证实，后者的价值只会更大——因为协作的复杂度远高于单任务执行。
"2025 Was Agents. 2026 Is Agent Harnesses." — Aakash Gupta
这句话需要一个补充：
2026 年的 Harness Engineering 有两层。第一层是代码级 harness——Claude Code 、Codex 、Cursor 已经做得很好。第二层是项目级 harness——从想法细化到任务验收的完整迭代环境——这是正在被填补的空白。
| 层次 | 解决的问题 | 代表 |
|---|---|---|
| 代码级 Harness | Agent 怎么写代码 | Claude Code, Codex, Cursor |
| 项目级 Harness | Agent 怎么做项目 | Chorus |
两层结合，agent 才拥有完整的工作环境：知道做什么（ Idea + Elaboration ）、怎么做（ Code Harness ）、做完给谁看（ Verify ）、下一步是什么（ DAG unblock ）。
当模型能力越来越强、越来越同质化，决定 agent 上限的不再是它有多聪明，而是它被放在什么样的环境里工作。
Harness 不是辅助。Harness 是上限。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。