📢 Gate 广场认证创作者招募中，入驻瓜分每月 $20,000 创作大奖！
📌 参与方式
站内创作者： 成功申请“创作者认证徽章”即可自动参与。
新入驻创作者： 需填写入驻表单申请 👉️ https://www.gate.com/questionnaire/7698
🎁 创作者福利
1️⃣ 首帖见面礼： 新入驻/回归创作者发首帖，即得 $50U 奖励！
2️⃣ 周度发帖奖： 完成周发帖任务，轻松瓜分 $10,000 奖池！
3️⃣ 月度创作奖： 赛道更多样，完成月度任务瓜分 $1,600 GT 奖池！
4️⃣ 专属推广任务：进入专属创作者社群，享专属推广任务和节日礼包！
让您的优质内容被更多人看到，携手共建高质量创作者社区！
活动细节：https://www.gate.com/announcements/article/51536
为什么你必须学习Harness Engineering？5个产物、3个学派、5条普世原则全解析
系统拆解 Harness Engineering 5 个产物、3 个学派（OpenAI / Anthropic / ThoughtWorks）、5 条普世原则，以及为什么「Harness 衰退」逼你每 6 个月就得砍掉一半的设计。本文源自 @sairahul1 所著 X 文章，动区整理、编译。
（前情提要：Harness Engineering(AI 驾驭工程)入门篇:OpenAI 最新程序设计标准,教你轻松做到 Lv.1）
（背景补充：YC 执行长分享 AI 秘诀:未来属于会搭建资讯复利系统的人）
本文目录
Toggle
2026 年 2 月，OpenAI 一个小团队出了 100 万行生产级程序码。
他们一行手写的都没有。
AI agent 写的。
人类设计的，是让 agent 可靠的那套系统。
这套系统现在有名字了——Harness Engineering。
几周内，Anthropic 发了 3 篇相关论文。ThoughtWorks 把它整理成框架。Hugging Face 的 Philipp Schmid 直接称它是「2026 年最重要的学科」。
90 天内，一个新工程学科就成形了。而 AI infra 团队之外，几乎没人看懂。
这篇文章就是把它讲清楚。没有废话、没有学术术语，只有你真的拿来用会需要的心智模型。
1. Harness 的定义
ThoughtWorks 给的最简定义：
Harness 就是模型以外的所有东西。
剥掉 harness → 一个在你 codebase 里瞎猜的原始语言模型。
加上对的 harness → 一个能产出生产级程序码的系统。
这个名字来自马具。Harness 是韁绳、马鞍、马銜——把一头力量强大但难以预料的动物导向有用的方向。
你不是把马变聪明，你是设计一套装备，让牠的力量变得有用。
2. OS 比喻
Philipp Schmid 给的最好的技术比喻是：把它想成一台电脑。
| 角色 | | --- | | 对应 | | --- | --- | | Model | CPU（原始算力） | | Context window | RAM（有限、易挥发的工作记忆） | | Harness | OS（管理 CPU 看到什么、什么时候看到） | | Agent | 跑在上的 App |
你的模型很强。但没有 OS 来管记忆体、排程任务、执行规则——它就只是一块硅。
大多数人是在「没有操作系统」的情况下跑 app。所以他们的 agent 一上生产线就坏。
3. 2026 年到底变了什么
LangChain 用同一个模型，在 Terminal Bench 2.0 上跑了两次：
| Harness | | --- | 分数 | | --- | --- | | 旧 harness | 52.8% | | 新 harness | 66.5% |
同样的模型。不同的 harness。差 13.7 个百分点。
Vercel 反过来做——砍掉 agent 80% 的工具。结果？更好，不是更差。
2026 年最不舒服的真相：
如果 2025 是 AI agent 证明自己会写程序的一年，2026 就是发现「环境」比「模型」更重要的一年。
4. AGENT.md / CLAUDE.md 文件
最通用的 harness 产物。
散落在 codebase 各处的 markdown 文件。Agent 每次 session 一开始就读——像新工程师到职的 onboarding 文件。
里面写什么？
OpenAI 叫它 AGENT.md。 Anthropic 叫它 CLAUDE.md。 Cursor 用 .cursorrules。
不同名字，同一原则。每个主要模块一份。随项目演进更新。
没有它：agent 每次 session 都是盲开机。有了它：agent 每次 session 都带着情报上工。
5. JSON Feature Lists（进度追踪器）
当 agent 跨多个 session 盖一个完整 app 时，每次 session 的 context window 都是空的。它怎么知道哪些已经做完了？
一个 JSON 文件。
每一笔写：
Agent session 一开始就读它——挑最高优先级的 fail → 实作 → 标 pass → commit → 重复。
为什么是 JSON 不是 Markdown？
Anthropic 发现：agent 不小心覆写 JSON 的机率比覆写 Markdown 低。
细节很小，但在 6 小时自主跑的场景里很关键。
6. Session 初始化常规
每一次 session 都用同样方式开机。每一次。
Anthropic 的 7 步开机程序：
没有它：agent 前 20 分钟都在搞清楚现有状态，每个 session 都在重复造轮子。有了它：agent 一开始就带着情报直接干活。
7. Sprint Contracts（冲刺契约）
写任何一行程序码之前——两个 agent 先谈判。
Generator agent 提案：
Evaluator agent 审查：
两边都同意，实作才开始。
是设计审查。只是两边都是 AI。
为什么重要
在同一轮里同时规划和执行的 agent，产出不可靠。「规划」这一步——即使是 AI 做的——也会大幅提升输出品质。
8. Structured Task Templates（结构化任务样板）
写任何程序码之前，harness 先分析真正的 codebase。
它产出一份接地的冲击地图（grounded impact map）：
然后实作才开始。
听起来理所当然。但大多数团队都跳过这一步。
Agent 猜档案结构、发明根本不存在的 API、做一个跟 codebase 不搭的东西。
先有接地的 context，再执行 → 输出品质会差非常多。
9. OpenAI 的学派：环境优先
OpenAI 的 Codex 团队有个荒谬的问题：
在那个规模，你不可能逐行 code review。所以他们不做。
取而代之——他们把环境设计得彻底到一个程度，让 agent 从一开始就产出「可被审查的输出」。
他们的做法
哲学：设计环境。然后放 agent 去跑。
证据
Sora Android app。4 个工程师。28 天。Play Store #1。99.9% crash-free。
Codex 每周处理内部 70% 的 PR。
10. Anthropic 的学派：把「做」和「审」分开
Anthropic 遇到的是另一个问题：
当他们叫 agent 评估自己的输出时，它会自信地称赞自己的作品——即使在人类观察者眼里品质明显平庸。
自评不行。 Agent 同时是学生跟老师，然后给自己打全 A。
他们的解法：3 个专责 agent
| Agent | | --- | | 工作 | | --- | --- | | Planner | 把 2 句话的 prompt 变成完整产品规格 | | Generator | 一次一个 sprint 实作 | | Evaluator | 用浏览器自动化测试，像真实使用者一样操作 |
洞察：让「独立的 evaluator」变得挑剔，比让 generator 对自己的作品变得挑剔容易得多。
结果（A/B 测试）
| 设置 | | --- | 成本 | 时间 | 结果 | | --- | --- | --- | --- | | 单 agent（无 harness） | $9 | 20 分钟 | 坏掉的 app | | 完整 harness | $200 | 6 小时 | 可运作软体 + 精致 UI |
11. ThoughtWorks 的学派：2×2 框架
ThoughtWorks 从不同角度切入——他们不是在做产品，而是在看 50+ 个工程团队在同样的地方失败。
他们的洞察：用两个轴分类每一个 harness 控制
轴 1：什么时候运作？
轴 2：怎么运作？
2×2 矩阵
| | | --- | | Feedforward（指引） | | Feedback（感测） | | --- | --- | --- | | Computational | type system、linter、架构规则 | test suite、coverage、mutation test | | Inferential | spec 文件、约束描述 | LLM code reviewer、行为验证器 |
Feedforward 和 feedback 哪一边单独用都不行。两边都要有。
12. 原则 1：Context 胜过 Instruction
不同团队，同一发现：
接地在真实档案路径 → 适配 codebase 的程式码。 从含糊描述出发 → 幻觉路径与发明 API。
在 agent 打字之前，先确保它知道自己在哪里。
13. 原则 2：规划与执行必须分离
每一个阵营都独立发现：让 agent 在同一轮里规划和执行，输出不可靠。
规划这一步不一定要人类做，但必须是分开的一步，且输出要被审过才能开工。
14. 原则 3：Feedback 迴路不可妥协
三个学派同一原则的三种做法：
| 学派 | | --- | feedback 来源 | | --- | --- | | OpenAI | 自动化测试 + CI | | Anthropic | 另一个 LLM | | ThoughtWorks | 两者叠用 |
他们在「谁提供 feedback」上有分歧。但他们在「你需不需要 feedback」上没有分歧。
15. 原则 4：一次只做一件事
一次想做太多的 agent 会：
Anthropic 的常规：读进度 → 挑 ONE feature → 实作 → commit → 重复。
「强制渐进主义」是所有成功 harness 的共通点。
16. 原则 5：Codebase 本身就是文件
没人会帮 agent 另外维护一份知识库。Repo 就是唯一真相。
如果一个惯例、约束、架构决策不在 codebase 里 → agent 就不会知道。
实务含义
17. Harness 衰退（Harness Decay）是真的
Anthropic 从 Opus 4.5 升到 Opus 4.6 时——Sprint 拆解（原本是必备的）变成了死重。
模型的规划能力进步了，让那块变多余。
3 月还在承重的 harness 组件，到 4 月已变成 overhead。
然后 Opus 4.7 上线——模型开始验证自己的输出，Evaluator agent 的职责又缩水了。
这就是 Harness 衰退
| 模型版本 | | --- | Harness 样态 | | --- | --- | | Opus 4.5 | 冲解拆解 + 每冲评估 | | Opus 4.6 | 没有冲解拆解 + 单次评估（省 38% 成本） | | Opus 4.7 | 模型自验 → evaluator 角色再缩 |
18. 为删除而建（Build to Delete）
Philipp Schmid 的建议：「Build to delete.」
设计每个 harness 组件时，就设计成可被移除。
定期测试每个组件——把它关掉，量输出品质有没有差。没差 → 删掉。
| 团队 | | --- | 6 个月内的重构 | | --- | --- | | Manus | 重构 harness 5 次 | | LangChain | 1 年内重整 3 次 | | Vercel | 砍掉 80% 工具 → 表现变更更好 |
这些不是坏工程的征兆。是「在快速进步的模型上盖东西」的自然后果。
19. 成本现实
Anthropic A/B 测试的诚实数字：
| 设置 | | --- | 成本 | 时间 | 结果 | | --- | --- | --- | --- | | 单 agent（无 harness） | $9 | 20 分钟 | UI 动了，核心坏 | | 完整 harness（Opus 4.5） | $200 | 6 小时 | 可运作软体，精致 UI，正确物理 |
22 倍成本——换到一个真的能跑的产品，而不是「螢幕截图才对」的 demo。
值不值得？取决于坏掉的 release 对你的团队代价多大。
但这里是没人讲的部分
Harness + 模型的组合是会演化的。
$200 的 harness，升一个模型版本后变 $124。
| 趋势线 | | --- | | 更好的模型 = 更简单的 harness = 更便宜的跑一次 = 更快的输出 |
全文浓缩
什么是 harness
5 个 harness 产物
3 个学派
5 条普世原则
异端之处
2026 年赢的工程师，不是写最好程序码的。他们是设计最好约束的人——而且愿意在那些约束停止赚钱的瞬间，把它们扔掉。