Harness Engineering：AI Agent 时代的新工程范式
本文发布于 2026-05：基于公开工程博客、学术论文和基准测试，系统阐述 Harness Engineering 的定义、六大核心组件、关键数据验证与落地指南。适合 AI PM 快速理解这一新兴范式，并将其转化为产品决策参考。
执行摘要
随着大型语言模型能力的日益同质化，将模型智能转化为可靠、规模化产出的工程系统——Harness Engineering（驾驭工程）——已成为新的竞争壁垒。
数据佐证：LangChain Terminal Bench 2.0 实验显示，在模型固定为 GPT-5.2-Codex 的情况下，仅通过优化 Harness 的中间件管道，得分从 52.8% 跃升至 66.5%，提升 13.7 个百分点。同一时期，单纯升级模型带来的提升通常仅为个位数百分点。
结论先行：模型是商品，Harness 是护城河。
对于 AI PM 而言，这一趋势需要关注三类问题：
- 产品架构上：应该投入多少资源建设 Harness 层，而不是追逐最新模型？
- 能力规划上：PM 需要理解 Harness 各组件，才能与工程师有效协作。
- 竞品分析上：对手的护城河可能在「怎么让模型工作」，而不是「用了什么模型」。
一、从 Prompt 到 Harness：范式的演进
AI Agent 的开发范式在过去几年经历了清晰的演进路径，关注点从模型本身逐渐转向其运行环境：
| 阶段 | 时间 | 核心关注点 | 核心问题 | 代表性技术 |
|---|---|---|---|---|
| Prompt Engineering | ~2023 | "说什么" | 如何通过指令获得理想的单次输出 | 提示词调优、思维链 |
| Context Engineering | ~2025 | "知道什么" | 如何为模型提供精准、充足的信息 | RAG、动态上下文管理 |
| Harness Engineering | 2026 | "在什么环境做事" | 如何让 Agent 在复杂环境中可靠、持续地执行 | 任务编排、验证过滤、自我修正 |
核心类比
- 🐴 马与马具：模型是马，Harness 是缰绳、马鞍与蹄铁。同一匹马，配以不同的马具，其表现、耐力和可控性天差地别。
- 💻 CPU 与操作系统：原始 LLM 如同没有内存管理、I/O 驱动和进程调度的 CPU。Harness 则扮演了操作系统的角色，为"计算核心"提供运行所需的全套基础设施。
PM 视角：这一演进意味着产品团队的关注重点在迁移——从「优化模型输入」转向「构建模型运行的系统环境」。理解 Harness 的六大组件，是评估 Agent 产品成熟度的基础。
二、六大核心组件
Harness Engineering 是一个系统工程，由六个相互协作的组件构成，共同为 AI Agent 构建"工作环境"。
1. 🛠️ 工具层 — 赋予 Agent "四肢与感官"
Agent 与外部世界交互的接口层。关键不在于提供工具，而在于标准化调用协议、权限控制与沙箱隔离。
赋予 Agent 在沙箱中运行 Bash 的能力，本质上是赋予其代码自验证的能力——这是实现自主闭环的关键一步。
PM 视角：工具层的设计决定了 Agent 的能力边界。哪些工具开放给 Agent？哪些需要人工授权？工具数量多不代表好——工具选择的准确率更重要。
2. 🧠 记忆层 — 构建 Agent 的"长期记忆"
核心功能是解决上下文窗口限制和实现跨会话状态保持。OpenAI 的实践是创建一个名为 AGENTS.md 的动态知识库——不是一个冗长的操作手册，而是一个约 100 行的"索引"或"地图"，指向更详细的架构、设计决策和质量标准文档。
Agent 在每次会话开始时读取它，并在任务失败或获得新知识时更新它，形成一个动态反馈循环。
PM 视角：记忆设计是 Agent 产品的核心用户体验问题。AI PM Playbook 的 记忆设计 一文详细讨论了短期/中期/长期记忆的取舍。
3. 📋 上下文管理 — 对抗"信息腐烂"
随着对话进行，原始上下文会被冗余、矛盾的信息污染，导致信噪比下降和推理质量退化，即 Context Rot（上下文腐烂）。应对策略包括：
- 压缩：定期将长对话历史摘要成精炼要点
- 工具输出卸载：将大段代码或日志输出到文件，上下文中仅保留摘要和路径
- 渐进加载：根据任务阶段，动态加载相关知识模块
PM 视角：上下文管理直接影响 Agent 的长任务稳定性。如果用户的 Agent 在对话进行到 50 轮后开始"犯低级错误"，大概率是上下文腐烂而非模型问题。
4. 🔄 任务编排 — 智能的"任务调度器"
管理和协调多个 Agent 或复杂任务的子步骤。实现了声明式任务定义——让工程师描述"要做什么"而非"一步步怎么做"。
LangChain 的中间件管道通过「环境扫描 → 循环检测 → 推理分配 → 提交验证」的流程，智能地分配计算资源。其核心发现是：推理预算的分配比推理预算的总量更重要。
PM 视角：任务编排决定了 Agent 的效率和可靠性。AI PM Playbook 中 多 Agent 工作流 讨论了层级式/管道式/市场式三种编排模式的选择。
5. ✅ 验证过滤 — 自动化的"质量门禁"
这是将人类工程经验编码化而非文档化的关键环节。包括：
- 架构约束编码化：将"分层架构必须单向依赖"的规则写入自定义 Linter，在 CI 阶段自动拦截违规
- 智能体对智能体评审（Ralph Wiggum 循环）：Agent 完成代码后，先在本地自我评审，再请求云端另一个独立 Agent 评审，根据反馈迭代，直至通过所有自动化检查后才提交 PR
PM 视角：验证过滤是评估体系在 Agent 系统中的应用延伸。详见 AI PM Playbook 的 Agent 评估指标 和 可观测性。
6. 🛡️ 自我修正 — 系统的"免疫系统"
完全自主的 Agent 会模仿代码库中所有现有模式，包括不良模式，导致 "AI 废料"积累。自我修正组件通过定义并守护**"黄金原则"**来对抗系统腐化。
定期运行的"重构智能体"会扫描代码库与黄金原则的偏差，并自动发起修复 PR，实现系统的自我净化。
PM 视角：自我修正是最容易被忽视的组件。没有它，Agent 系统的质量会随时间自然下降。设计这个机制需要 PM 定义哪些是"黄金原则"——这本质上是产品价值观的工程化。
三、标志性案例：OpenAI 的百万行代码实验
2025 年 8 月至 2026 年 1 月，OpenAI 进行了一项标志性实验：由 3 名工程师主导，在 5 个月内，遵循"零手动编码"原则，完全依靠 Codex Agent 及其 Harness 系统进行开发。
核心实践
- AGENTS.md 动态知识库：项目的"活地图"，引导 Agent 按需获取知识，并在每次交互后更新
- 约束编码化：分层领域架构（Types → Config → Repo → Service → Runtime → UI）等设计规则直接写入 CI/CD 流程
- 端到端自主工作流：Agent 可独立完成从问题复现、编码、测试到发起 PR 的全流程，单个会话可持续长达 6 小时
- 智能体对智能体评审：本地自评 + 云端独立评审的双重机制，人类仅在最后环节进行整体性 Review
- 后台自动化清理：定期扫描代码库，自动发起重构任务，像"垃圾回收器"一样维护代码健康度
关键成果
| 指标 | 数值 |
|---|---|
| 累计合并 PR 数 | 1,500 个 |
| 产出代码量 | ~100 万行 |
| 每人日均审查/合并 PR 数 | ~3.5 个 |
| 效率对比（vs 传统开发） | 约 10 倍 |
PM 视角：这个案例证明了 Harness 的质量直接决定了 Agent 产出的规模和质量边界。对 AI PM 的关键启示：Harness 不是纯工程问题，而是产品架构的核心组成部分。
四、数据验证：Harness 优化 vs 模型升级
LangChain 的 Terminal Bench 2.0 提供了一个完美的对照实验：
实验设计：模型固定为 GPT-5.2-Codex，仅优化 Harness——引入中间件管道（环境扫描 → 循环检测 → 推理分配 → 提交验证）。
实验结果：
- 优化前：52.8%（约 Top 30 水平）
- 优化后：66.5%（进入 Top 5）
- 提升：+13.7 个百分点
相比之下，在 SWE Benchmark 等测试中，仅升级模型版本带来的提升通常仅为个位数百分点。
这清晰地证明：对于生产环境的可靠性和效能，Harness 工程的质量往往是比模型能力更关键的决定性因素。
五、落地指南
最小可行三步法
如果团队资源有限，建议优先完成以下三件事，快速建立 Harness 的核心价值循环：
- 📝 编写项目专属的 AGENTS.md：100-200 行内容，清晰定义项目结构、核心规范、常用命令和绝对禁止项。这是 Harness 的"宪法"。
- 🔧 将验收标准自动化："代码要整洁" →
npm run lint通过；"功能要正确" →npm test通过。让验证过程无需人工判断。 - 🔄 建立失败反馈循环：每次 Agent 执行失败或产出不符合预期，必须将根本原因和修正方案记录并更新到 AGENTS.md 中，使系统越用越聪明。
目标-验证矩阵
Harness 设计的本质，是推动任务在以下矩阵中向右上角迁移：
| ↓ | 目标模糊 | 目标明确 |
|---|---|---|
| 验证人工 | ❌ 最糟糕状态 — 多数 AI 项目起步于此 | ⚠️ 过渡状态 — 人工验证成为瓶颈 |
| 验证自动 | ⚠️ 过渡状态 — Agent 无所适从 | ✅ 理想状态 — 高效可靠的自主运行 |
核心原则：优化一个系统的能力，与验证其输出的容易度成正比。
六、跨模块关联
本文与 AI PM Playbook 的以下模块深度关联：
| 相关模块 | 关联点 |
|---|---|
| Agent 循环设计 | Harness 是 Agent 循环的工程化实现 |
| 记忆设计 | 记忆层是 Harness 六大组件之一 |
| 多 Agent 工作流 | 任务编排的核心场景 |
| 可观测性 | 验证过滤的基石 |
| Agent 评估指标 | 验证过滤的输出标准 |
| AI 产品画布 | Harness 策略可纳入产品画布的"系统设计"板块 |
| 产品生命周期指南 | Harness 建设应融入从 0 到 1 流程 |
| 大模型与 Harness 的未来轨迹 | 姊妹篇 — 探讨 BigModel vs BigHarness 争论 |
七、边界说明
- 本文主要引用的数据来自公开 benchmark（Terminal Bench 2.0, SWE Benchmark），其任务域偏 coding / knowledge work，对线下运营、客服等任务的外推有限；
- OpenAI Codex 实验的具体细节来自公开工程博客，部分数据未经第三方独立验证；
- Harness 各组件在不同场景下的权重不同，实际建设应结合产品类型（Coding Agent vs 客服 Agent vs 数据 Agent）裁剪；
- 随着模型原生 runtime 能力的提升（如 Anthropic 的 improved tool use、OpenAI Structured Outputs 的进化），部分认知型 harness 组件可能会被模型内生化。
八、参考来源
| 来源 | 用途 |
|---|---|
| OpenAI — Harness engineering: leveraging Codex in an agent-first world | 核心概念与案例 |
| LangChain — Terminal Bench 2.0 | 数据验证 |
| AGENTS.md 项目 | 项目级 agent 指令约定 |
| Anthropic — Building effective agents | 工具设计与 agent 实践 |
| AI PM Playbook — 大模型与 Harness 的未来轨迹 | 延伸分析与框架对比 |
维护建议：Harness 领域变化快，建议按季度复核本文中的 benchmark 数据、模型名称和厂商案例。核心概念和框架相对稳定，可不定期更新。
本文是 AI PM Playbook「📡 研究方向」系列的一部分。更多研究文章请访问 AI PM Playbook。