为什么顶级团队开始重押 Harness Engineering？AI Agent 时代的底层答案来了

一百万行代码，没有一行是人写的

2026 年 2 月，OpenAI 公开了一个令整个行业瞩目的内部实验：一个最初只有 3 名工程师的团队，在 5 个月内从零交付了一款拥有内部日活用户和外部测试者的软件产品。这款产品的代码量超过 100 万行，累计合并了约 1500 个 Pull Request，开发耗时仅为传统人类团队的十分之一。最关键的一点是 —— 从应用逻辑、测试代码、CI 配置到文档和监控工具，没有一行代码是人手写的，全部由 AI Agent 完成。

这不是魔法，也不是因为他们用了一个多么逆天的大模型。真正的秘密在于：他们为 AI 搭建了一个极其精良、完备的 “工作环境”。设计这种环境的工程，有一个正式的名字，叫做 Harness Engineering（驾驭工程）。这个概念正在重塑全球最优秀工程团队的工作方式，而大多数人甚至还没听说过它。

先打个比方：烈马、缰绳与骑手

在解释任何技术术语之前，我们先用一个最直觉的画面来理解这件事。

想象一匹未经驯服的烈马。它有惊人的速度和力量，但没有方向 —— 它可能狂奔向悬崖，也可能原地打转。今天的 AI 大模型就像这样一匹烈马：GPT、Claude、Gemini，它们的推理能力已经非常强大，但如果你直接让它们 “去写一个完整的软件系统”，结果大概率是一团混乱。更好的马不等于更好的结果，一匹更快的马如果没有缰绳，只会更快地跑向错误的方向。Harness 就是那套缰绳 —— 它不是 AI 模型本身，而是围绕模型搭建的一整套约束、引导和反馈系统，负责把 AI 的能力上限真正转化为可控的、有用的产出。

2026 年 2 月，软件工程领域的权威人物和思想领袖 Martin Fowler 正式将这套方法论命名为 “Harness Engineering”，定义它为 “构建用于管控 AI Agent 的工具与实践组合”。另一位技术专家 Phil Schmid 则给出了一个更具技术感的类比：如果说 AI 模型是 CPU（提供原始算力），上下文窗口是 RAM（有限的工作内存），那么 Harness 就是操作系统 —— 它负责调度资源、管理进程、处理错误，让上层的 Agent 应用能够稳定运行。换句话说，Harness Engineering 不是在造更强的发动机，而是在造更好的公路和交通规则，让发动机的力量真正跑到终点。

理解了这一层，你就能明白为什么顶级团队纷纷押注这个方向：当模型能力达到一定水平后，决定 AI 表现的瓶颈不再是模型本身，而是它运行环境的设计质量。

四个团队，四种证明

说到这里，你可能会想：这听起来很有道理，但真的管用吗？我们来看四个真实案例，每一个都从不同角度证明了同一个结论 —— Harness 的质量决定 AI 的表现。

Vercel：删掉 80% 的工具，反而更强了

Vercel是全球知名的前端部署平台。他们的团队曾为内部的一个文本转SQL的AI Agent精心打造了15个专用工具，投入了大量的提示工程和上下文管理。结果呢？系统脆弱、速度慢，成功率只有80%，而且需要持续维护。

后来团队做了一个大胆的实验：砍掉 80% 的工具，只保留一个 “精准执行 bash 命令” 的通用工具，让 AI 直接用 ls、grep、cat 这些最基本的 Unix 命令来完成任务。结果如下所示：

旧架构的最差表现是耗时 724 秒、走了 100 步、烧掉 14.5 万个 token 后失败；而新架构处理同样的查询，141 秒、19 步、6.7 万 token 就搞定了。Vercel 团队总结出三条关键教训：第一，文件系统本身就是一个非常强大的抽象，不要重复造轮子；第二，要信任模型自身的推理能力，过度限制有可能是负担；第三，这一切的前提是你的数据层本身就是清晰、有序的。

LangChain：不换模型，只优化环境，排名从第 30 飙到第 5

LangChain 的案例更加 “纯粹”。他们的编码 Agent 在 Terminal Bench 2.0 基准测试中最初得分 52.8%，排名第 30 位。随后团队完全没有更换底层模型，只是优化了 Harness —— 包括添加自我验证回路、改进上下文工程、引入循环检测和推理优化等中间件。

优化完成后，得分跃升至 66.5%，排名从第 30 位直接冲到第 5 位。这个案例干净利落地证明了 Martin Fowler 的判断：模型能力只是地基，Harness 质量才是真正的竞争壁垒。

Stripe：一个工程师同时驾驭六七个 AI

Stripe 是全球顶级的支付公司，代码库庞大而成熟。他们自研了一套名叫 Minions 的编码 Agent 系统，每周自动合并超过 1000 个 Pull Request。工作流程非常丝滑：工程师在 Slack 里 @一下 Minion，用自然语言描述任务，Minion 就会在一个隔离的开发环境中自动启动，完成编码、运行测试、提交 PR，整个过程无需人工介入。工程师只在最后做代码审查和合并决策。

在 Stripe，一个工程师可以同时跑六七个 Minion 处理不同任务。这意味着什么？一个人的产出相当于过去一个小团队的。而让这一切成为可能的，正是 Harness 为每个 Minion 提供的隔离环境、完整工具链和端到端自动化流程。

OpenAI：回到那个百万行代码的故事

现在让我们回到开头那个震撼人心的案例，补全它背后的完整故事。OpenAI 团队最初只有 3 名工程师，后来扩展到 7 名。他们给自己定了一条铁律：不手动编写任何代码，所有工作重心放在 “设计环境、明确意图和提供结构化反馈” 上。早期进展其实非常缓慢，但原因不是 AI 模型能力不足，而是环境规范不够明确 —— Agent 缺乏完成高级目标所需的工具、抽象层和内部结构。团队的核心工作因此变成了 “帮助 Agent 完成工作”：把大目标拆成小模块，搭建清晰的代码仓库结构，编写精确的架构文档。当这些 Harness 基础设施逐渐完善后，AI Agent 的产出速度和质量发生了质的飞跃，最终在 5 个月内交付了超过 100 万行代码的产品。这个案例的核心启示是：你以为瓶颈是 AI 的智商，其实瓶颈是你给它搭的舞台。

这四个案例，从不同维度拼出了同一幅图景：在 AI Agent 时代，工程师的核心战场已经从 “编写代码实现” 转移到了 “设计 Agent 的运行环境”。

从写代码到设计世界：一场正在发生的范式转变

如果你只把 Harness Engineering 看作一种新工具或新技巧，那就低估了它 —— 它其实代表的是软件工程领域一次范式级的转变。

软件工程奠基人之一 Grady Booch 在 2026 年初指出，软件工程正进入 “第三个黄金时代”：

• 第一个黄金时代（1940 — 1970 年代）以 算法 为核心，聚焦数学逻辑与计算效率；
• 第二个黄金时代（1970 — 2000 年代）以 面向对象编程 为核心，推动软件设计从过程式思维走向模块化、可复用的对象模型；
• 第三个黄金时代则以 系统 为核心，要求工程师从单组件视角跃迁至完整系统视角，理解并驾驭大规模复杂性。

Booch 特别提醒，这种 “生存危机感” 并非首次出现 —— 当年编译器和高级语言诞生时，程序员也曾恐慌被淘汰，但最终职业并未消亡，而是进化。AI 工具同样如此：它不是工程的终结，而是抽象层次的又一次跃升。

这一跃升的本质，是工程焦点从 “实现” 转向 “意图”。传统软件工程的核心问题是 “如何实现这个功能”，工程师通过逐行编码将人类意图翻译为机器指令；而在 AI Agent 时代，这一逻辑被翻转：工程师的职责变成 “如何清晰表达意图，并设计一个让 AI 能正确执行该意图的环境”。打个比方，这就像从 “亲自开车” 转变为 “设计自动驾驶系统的交通规则” —— 你不再需要精湛的驾驶技术，却需要更深的系统思维，来确保整个交通系统安全、高效地运转。

McKinsey 在 2025 年的研究中也印证了这一点：企业正迈向 “智能体组织”，人类与 AI Agent 的关系不再是 “工具使用者与工具”，而是在价值创造过程中协同参与的伙伴。

三根支柱撑起整个系统

在理解 Harness Engineering 的宏观图景后，我们来看它的具体运作方式。整个体系建立在三根支柱之上：上下文工程、架构约束和熵管理。这三个术语看似高深，逻辑却十分直白。

第一根支柱：上下文工程 —— 让 Agent 在正确的时间看到正确的信息。

核心原则很简单：Agent 在上下文中看不到的信息，等同于不存在。架构决策写在 Confluence 里？Agent 看不见；设计思路散落在 Slack 群聊中？Agent 不知道；你脑中的命名规范？对 Agent 而言只是黑洞。因此，Harness Engineering 要求将所有关键信息 “推送” 到代码仓库，让仓库成为唯一的真实信息源。OpenAI 团队曾尝试把所有指导塞进一个巨大的 AGENTS.md 文件，结果因文件过长、信息过时、难以校验而失败。后来他们将 AGENTS.md 精简到约 100 行，仅作为 “目录” 指向仓库中的深层文档，实现了 “渐进式披露”。Anthropic 则在长周期任务中使用结构化的 JSON 功能列表和进度文件，确保 Agent 即使跨会话也能精确定位当前状态。上下文工程的目标不是给 Agent “更多” 信息，而是在每一步给予 “刚好需要” 的信息 —— 既不缺失，也不过载。

第二根支柱：架构约束——用机制强制执行质量标准，而非“拜托”模型写出好代码。

传统 AI 开发中，我们习惯在提示词里写 “写出干净、可维护的代码，遵循 SOLID 原则”。但这种 “口头约定” 的效果完全取决于模型状态与提示措辞，毫无保障。Harness Engineering 的做法是将质量标准从自然语言转化为可机械执行的规则。OpenAI 团队制定了严格的依赖分层规则：类型 → 配置 → 仓库 → 服务 → 运行时 → UI，每一层只能引用左侧层级的内容。这条规则通过自定义 linter 和结构测试强制执行，违规代码根本无法提交。这里有一个反直觉却至关重要的洞见：限制 AI 的选择空间，反而让它更高效。当 AI 可以 “随便写” 时，会浪费大量算力在无效路径上；而一旦 Harness 画好清晰的边界，AI 就能更快收敛到正确方案。就像为棋手缩小棋盘，虽限制了自由度，却提升了每一步的质量。

第三根支柱：熵管理 —— 给代码库装上 “自动清洁系统”。

这是最容易被忽视、长期却最致命的一根支柱。AI Agent 在写代码时会模仿库中已有的模式 —— 包括那些不太好的模式。久而久之，代码库会悄然退化：命名不一致、文档与代码脱节、无效代码堆积。OpenAI 团队最初尝试手动清理这些 “AI 残渣”，但很快发现这种方式难以扩展。于是他们建立了自动化的循环清理流程：定期运行后台 Agent 扫描偏差、更新质量等级、发起重构 PR，持续偿还技术债务。Martin Fowler 将此比作编程语言中的垃圾回收（Garbage Collection，简称 GC）—— 程序员无需手动管理内存，GC 自动回收；同理，Harness Engineer 也无需手动维护代码质量，清理 Agent 自动巡检。

这三根支柱并非各自独立，而是相互增强的系统：好的上下文让约束更易执行，约束减少了混乱，熵管理又让上下文保持准确。三者实际缺一不可。

为什么不能像信任人类代码那样信任 AI 代码？

这里就引出一个关键问题：Harness 设计得再好，AI 写的代码就一定可靠吗？这背后其实是 信任机制的差异。

人类代码的信任建立在一条清晰的积累曲线上：代码审查、单元测试、集成测试层层递进，可信度随时间稳步提升。而 AI 生成的代码则呈现出 “尖峰状” 的可靠性 —— 可能一次表现完美，下一次却在某个微妙的边界条件上彻底出错。如果沿用老方法逐行审查，效率极低，几乎等同于自己重写。

Harness Engineering 的解决思路非常巧妙：它不去验证 AI 产出的每一行代码，而是验证 AI 所处运行环境的正确性。只要约束条件到位、上下文准确、反馈循环通畅、工具设计合理，AI 在这一环境下的行为就是可预期的。这好比化学实验 —— 无需控制每一个分子的运动，只需严格控制温度、浓度、催化剂等实验条件，反应便会自然发生。

以 Anthropic 为例，在处理跨度数小时甚至数天的长周期 Agent 任务时，他们设计了一套两阶段 Harness：第一阶段由 “初始化代理” 搭建环境并生成结构化任务清单；第二阶段由 “编码智能体” 在各会话中逐步推进，完成后留下清晰的工件供下一会话接力。这样一来，信任不再取决于 “模型有多聪明”，而是取决于 “Harness 设计得有多扎实”。

从今天开始：三级 Harness 实践路径

讲完理论和案例，你最关心的可能是：我能不能用上 Harness Engineering？答案是：今天就能开始。

第一级：个人开发者，1-2 小时搭建

如果你在用 Claude Code、Cursor 或 Codex 做个人项目，最基础的 Harness 只需几步：

• 在项目根目录配置 CLAUDE.md 或 .cursorrules，明确项目约定与代码风格
• 设置 pre-commit 钩子，自动执行代码检查与格式化
• 搭建一套 Agent 可自主运行的测试用例
• 保持清晰的目录结构和统一的命名规范

核心原则是 “仓库优先的文档” —— 所有架构决策、命名规范、部署流程都存放在代码仓库中，而非散落在 Slack 或 Google Docs。仅此一步，就能避免绝大多数 Agent 常见错误。

第二级：小型团队，1-2 天搭建

当 3 到 10 名开发者共享同一代码库时，需要在第一级基础上增加团队层面的 Harness：

• 编写 AGENTS.md，记录团队通用约定
• 通过 CI 流水线强制执行架构约束
• 建立通用任务的共享提示模板
• 为 Agent 生成的 PR 制定专门的代码审查清单

关键原则是 “渐进式构建约束” —— 从最基本的代码检查入手，随着团队对 AI 工作方式理解的加深，再逐步增加更复杂的架构约束，不必一开始就设计出完美的 Harness。

第三级：工程组织，1-2 周搭建

当组织需要同时运行数十个并发 Agent 时，Harness 需升级为生产级：

• 搭建自定义中间件层，处理循环检测与推理优化
• 接入可观测性系统，让 Agent 能读取日志和性能指标
• 部署按周期运行的熵管理 Agent，自动清理代码库
• 建立 Harness 的版本控制与 A/B 测试机制
• 搭建 Agent 性能监控仪表盘

重要原则是 “多提供商设计” —— Harness 应兼容 Claude、GPT、Gemini 等不同模型，确保切换模型时无需重建整套系统。

四个最常见的踩坑姿势

Harness Engineering 虽好，但踩坑者众。以下四个常见错误，许多团队都为此交过学费。

第一坑：过度设计控制流

AI 模型迭代极快 —— 2024 年还需复杂流水线实现的功能，2026 年或许只需一个简洁的上下文窗口提示。若 Harness 设计得过于 “刚性”，最终只会沦为拆不掉的脚手架。Manus 在六个月内五次重构 Harness 以剔除过时假设，LangChain 一年内三次重写其 Research Agent，Vercel 则直接删掉了 80% 的工具。

正确的做法是让 Harness “可剥离”：当模型足够聪明、不再需要某个约束时，能够干净利落地将其移除。永远为六个月后的模型能力留出进化空间。

第二坑：忽视熵管理

许多团队只看到 AI 能快速生成代码，却忽略了代码库的长期健康。没有清理机制的 Harness，终将被自己生成的代码淹没 —— 文档过时、命名混乱、僵尸代码堆积，直到整个代码库变得无法维护。定期运行的清理 Agent 不是锦上添花，而是必需品。

第三坑：没有反馈循环

缺乏反馈机制的 Harness，不是在 “引导”，而是在 “禁锢”。Agent 需要知道自己的对错，才能在后续任务中持续改进。OpenAI 团队将 “迭代原则” 作为核心方法：当 Agent 遇到困难时，不是简单地换一种提示，而是将其视为信号 —— 识别缺失的工具、约束或文档，然后让 Agent 自行编写修复方案并反馈回代码库。

第四坑：只有人能看懂的文档

如果架构决策只存在于工程师脑中，或放在 Agent 无法访问的 Confluence 页面里，你的 Harness 就留下了一道隐形的缺口。Agent 所需的所有信息必须存储在代码仓库内，且最好是机器可读的格式（Markdown 或 JSON）。

从码农到驯马师：你的新角色

如果你是一名程序员，看到这里，可能会有两种感受：兴奋，或者恐慌。但我想告诉你，你完全有理由感到兴奋。

Harness Engineering 并非要淘汰工程师，恰恰相反，它正在重新定义工程师的角色 —— 让你从 “代码实现者” 升级为 “AI 系统设计者”。这一转变并未降低技术门槛，反而提出了更高的要求。你不再需要花费大量时间编写增删改查之类的代码，而是需要更深入地思考系统架构、约束设计与反馈机制。具体来说，你的工作内容将发生如下变化：

在新范式下，工程师需掌握五项核心技能：系统思维——理解约束、反馈与文档之间的交互关系；架构设计 —— 定义可执行且高效的边界；规范编写 —— 精准表达意图，使 Agent 可执行；可观测性 —— 搭建能揭示 Agent 行为模式的监控系统；迭代速度 —— 快速测试并优化 Harness 工程。

更令人兴奋的是 “并行工程” 的兴起。传统开发中，工程师一次只能处理一个任务；而在 Harness 支持下，你可以像 Stripe 的工程师那样同时管理六七个 Agent，让它们并行处理不同任务。角色从 “单线程执行者” 转变为 “多线程调度者”，个人产出能力成倍提升。

下一个五年的底层能力

展望未来，Harness Engineering 的演进正在加速。技术专家 Phil Schmid 预测，Harness 将成为应对 “模型漂移” 的关键工具 —— 训练团队可借助它检测模型在长任务中何时开始 “走神”，并将这些信号反馈至训练流程，从而构建在长程任务中不易 “疲劳 / 摆烂” 的模型。Martin Fowler 网站的文章则提出 “Harness 即服务”（HaaS）的概念，未来团队可像选用服务模板一样，以预制 Harness 为起点，显著降低入门门槛。与此同时，OpenAI 团队坦言，当前最棘手的挑战之一，是在完全由 Agent 生成的系统中，如何确保架构连贯性随时间健康演化，而非让 Harness 本身演变为新的技术债务。

无论技术细节如何演变，Harness Engineering 的核心洞见已清晰：当 AI 足够聪明时，人类工程师最大的价值或许不再是 “写出正确的代码”，而是 “设计出让 Agent 能可靠运行的世界”。掌握这门学科的工程师，将定义下一个五年的软件工程。不论你是在校学生、初入职场的新人，还是拥有十年经验的老将，现在正是理解并拥抱 Harness Engineering 的最佳时机 —— 因为在 AI Agent 时代，驯马师远比骑手更稀缺，也更珍贵。