2026 年 AI 工程新范式：Harness Engineering 深度解析

2026 年 AI 工程新范式：Harness Engineering 深度解析

受众假设：你已经写过 Prompt，了解 RAG/动态上下文注入，并对 Agent 的“推理-行动-观察”循环不陌生。

本文聚焦：工程机制与可靠性直觉（而不是“某个模型有多强”）。

TL;DR（先看结论）

• Harness Engineering 关注的不是“怎么把模型训练得更强”，而是“怎么设计模型运行系统，让模型在机制里把事稳定做成”。
• 它可理解为 AI 工程的第三阶段：Prompt → Context → Harness，且是包含关系：Prompt ⊂ Context ⊂ Harness。
• 之所以在 2025 年底到 2026 年初快速升温，核心是 4 件事：模型能力到临界点、长任务暴露系统性失败模式、多步链路的累积误差导致端到端可靠性崩塌、模型商品化后竞争焦点转向系统（Harness）。
• 多步 Agent 的关键问题通常不是“95% 单步成功率不够高”，而是“缺少验证与恢复机制”，因为 0.95^20 ≈ 36%（成功率会指数衰减）。
• 成熟 Harness 常见 6 个模块：上下文/知识、工具/权限、验证/约束、状态/记忆、可观测性/反馈、人类接管/生命周期。
• 它同时带来创新与争议：工程约束对象从“确定性代码”转向“概率推理系统”；风险来自概念膨胀、过度工程化、证据与可复现性不足，以及多 Agent 带来的风险放大。

快速导航（按困惑定位）

1. 关键概念：Harness 是什么

这里说的 Harness Engineering（下文简称 Harness），指的是：设计模型运行系统的工程方法论，而不是直接优化模型本身。

一句话定义：Harness = “把模型能力接到真实世界任务上，并且用机制保证可控、可验、可恢复”的系统工程。

可以用一个直观隐喻来理解角色分工：

• 模型是马匹：强大但无方向
• 人类是骑手：提供方向
• Harness 是马具：控制与引导工具

更工程化的定义：Harness 处理模型外部的完整运行系统，包括任务拆解、上下文管理、工具编排、权限设定、状态交接、结果验证、失败恢复，以及人类控制权交接等系统性设计。

2. 三阶段演进：Prompt → Context → Harness

可以把 AI 工程演进粗分为三阶段，并用“关注点”来对比差异：

包含关系：Harness 包含 Context，Context 包含 Prompt。换句话说，你可以把前者当作后者的“上层装配”。

Prompt ⊂ Context ⊂ Harness
（从“怎么说”→“给它看什么”→“让它在什么机制里干活并确保干成”）

（一个更贴近工程直觉的对照）

Prompt：写一句话，让模型“想清楚”
Context：把资料塞进去，让模型“看得到”
Harness：把流程/工具/验证/恢复都配齐，让系统“交付得出来”

3. 为什么会爆发：四个驱动因素

2025 年底至 2026 年初 Harness Engineering 升温，常见可以归因到 4 个驱动因素：

4. 可靠性直觉：为什么 95% 仍然会在真实任务里失败

这里有一个关键数学直觉：

• 多步 Agent 流水线单步成功率 95%
• 串联 20 步后端到端成功率约 36%

可以用最小模型表达这个现象：

端到端成功率 ≈ p^n

p = 单步成功率（例如 0.95）
n = 步数（例如 20）

0.95^20 ≈ 0.358

结论不是“95% 太差”，而是：当任务必须拆成多步时，系统设计的重心要放在“验证、恢复与状态治理”，否则失败会在长链条里被放大。

给一个更直观的表（p=0.95）：

（多步 Agent 端到端成功率的直觉图）

Step1 Step2 Step3 Step20
95% × 95% × 95% × … × 95%
│ │ │ │
└──────┴──────┴────── … ──┘
端到端 ≈ 36%

因此：需要 Harness 来做
– 结果验证（不是“自我觉得完成了”）
– 失败恢复（重试/回滚/换路）
– 状态交接（跨窗口/跨 session 不丢进度）

5. Harness 的六大核心模块

成熟 Harness 常见可以拆为 6 个模块。这里的读法建议是：先看“它解决什么失败模式”，再看“它实现成什么模块”。

用一个“目标导向”的图把它们放在同一个框架里：

┌──────────────────────────────┐
│ Agent Loop │
│ 推理 → 行动 → 观察 │
└──────────────┬───────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ Harness（把“能做”变成“能稳定做对”） │
│ │
│ 1) 上下文/知识：信息可达性 2) 工具/权限：动作可执行性 │
│ 3) 验证/约束：结果可验证性 4) 状态/记忆：跨步可持续性 │
│ 5) 可观测/反馈：问题可定位性 6) 人类接管：关键决策可控性 │
└───────────────────────────────────────────────────────────────┘

6. 头部实践：共同收敛到哪些模式

把不同公司的实现细节放在一起看，表面上各叫各的名字，但底层收敛点很一致：把“生成”和“验证”分离、把记忆外部化成可审计制品、把关键约束做成确定性门禁（而不是靠模型自觉）。

6.1 Anthropic：从双 Agent 到三 Agent（生成-评估分离）

一种常见的演进路线是从“生成”与“执行”分工，进一步走向“生成-评估分离”：

• 2025 年 11 月：双 Agent（初始化 Agent + 编码 Agent）
  • 初始化 Agent：建环境、创建脚本、生成可测试需求清单（JSON）
  • 编码 Agent：读取进度文件、审查需求、执行测试
  • 关键点：通过外部制品（进度文件、Git 历史、需求清单）实现跨 session 记忆
• 2026 年 3 月：三 Agent（Planner + Generator + Evaluator）
  • Planner：扩展需求
  • Generator：实现功能
  • Evaluator：独立验证（解决自评估缺陷）

（三 Agent 的最小结构）

Planner → Generator → Evaluator
扩展需求 产出实现 独立验证

关键：Evaluator 不是 Generator 的“自我批评”，而是独立角色。

6.2 OpenAI：Codex Agent（高吞吐 + 约束 + 自我改进闭环）

常见做法可以概括为“高吞吐 + 强约束 + 自我改进闭环”：

• 3-7 人团队 5 个月生成约百万行代码，合并 1500 个 PR
• 人均日吞吐量 3.5 个 PR，且随团队扩大而上升
• 约束：零手写代码，逻辑/测试/CI/文档均由 Codex 生成

Harness 三个常见支柱：

核心模式：遇到困难时不“更努力”，而是反问“缺少什么能力？如何让该能力可执行？”，把改进落在系统机制上，形成自我改进闭环。

6.3 Google DeepMind：Alethia（Generator/Verifier/Revisor）

一种经典的三组件结构与效果边界是：

• Generator：提出解法与证明策略
• Verifier：检查逻辑缺陷与幻觉
• Revisor：修正错误

结果：在 IMO Proof Bench Advance 达到 95.1% 准确率，但更广泛问题集错误率 68.5%，体现 Harness 在特定场景的强大与泛化局限。

7. 创新本质、争议与风险

7.1 创新本质

可以从 4 个维度理解它的创新点：

7.2 主要争议与风险

常见的 5 类风险是：

8. 结论与行动路径

核心结论可以用三段式区分来记：

• Prompt Engineering 解决“怎么说”
• Context Engineering 解决“给模型看什么”
• Harness Engineering 解决“让模型在什么机制里干活并确保干成”

务实行动路径（按时间尺度整理）：

• 立即：创建 agents.md，记录 Agent 重复性错误及规则
• 中期：构建确定性验证层（Linter、结构测试、可观测性）
• 长期：设计模块化可替换 Harness 架构，支持模型升级平滑迁移

开放性问题：Harness Engineering 会成为 AI 时代的 DevOps，还是会被下一代模型压缩系统复杂度后边缘化？