如果 2025 年的关键词是"智能体"，那么 2026 年的关键词就是"驾驭"。模型不是瓶颈，驾驭模型的基础设施才是。本文系统梳理 Harness Engineering 的起源、核心架构、业界实践与前沿演进，试图回答一个根本性问题：当 AI 智能体真正进入生产环境，我们到底需要建造什么？

从一个根本性的困境说起

想象一个场景：你让一个 AI 智能体去构建一个完整的 Web 应用。它开始工作，写了几个小时的代码，然后——上下文窗口满了。

新的一轮对话开始了。这个智能体对之前发生的一切一无所知。它看到了一堆代码，但不知道哪些功能已经完成、哪些还在半途、哪些已经被测试过。它只能猜测，然后继续——很可能在错误的方向上继续。

这就是长任务智能体面临的核心困境：上下文窗口是有限的，而复杂任务是无限的。

Anthropic 在 2025 年 11 月发布的工程博客 Effective harnesses for long-running agents 中，将这个问题描述得非常形象：

想象一个软件项目由轮班工程师负责，每个新工程师到来时对上一班发生的事情毫无记忆。

这不是比喻，这就是当前所有 AI 智能体在跨越上下文窗口时的真实处境。

Harness Engineering 是什么

词源与定义

“Harness"这个词来自工程测试领域，原意是"测试框架"或"脚手架”——一套包裹在核心系统外部、用于控制和协调其行为的结构。在马术中，harness 是"挽具"——不是替马奔跑，而是让马在正确的方向上奔跑。

在智能体语境中，Agent Harness（智能体驾驭框架） 是一个外部软件层，它包裹在 LLM 之外，负责：

  • 工具调用的编排：决定智能体可以使用哪些工具、如何调用
  • 上下文的管理：决定每次会话开始时注入什么信息
  • 任务状态的维护：跟踪任务进度，在会话之间传递状态
  • 验证与约束：确保智能体的输出满足质量要求
  • 环境的初始化与清理：为每次运行准备好正确的工作环境

一个常见的类比是：上下文窗口是 RAM（易失性内存），Agent Harness 是操作系统。操作系统负责在程序切换时保存和恢复状态；Harness 负责在智能体会话切换时保存和恢复任务状态。

与 Prompt Engineering 的本质区别

Prompt Engineering 是在对话层面调参数，Harness Engineering 是在系统层面搭架构。一个是调音量旋钮，一个是设计整个音响系统。

更精确地说：

维度 Prompt Engineering Harness Engineering
作用对象 单次模型调用 整个智能体生命周期
关注点 “说什么” “在什么环境中说”
持久性 会话内有效 跨会话持久化
可验证性 依赖人工判断 可机械化验证
失败模式 输出质量下降 任务无法接力

Harrison Chase（LangChain CEO）将 Harness Engineering 描述为 Context Engineering 的自然延伸——Context Engineering 关注如何构造提示词、检索和系统上下文，而 Harness Engineering 关注如何在系统层面优化任务性能、token 效率和安全性。

为什么 Harness 是长任务的必备解法

答案是：这已经是业界共识。

Anthropic 的实验证据

Anthropic 让 Claude Opus 4.5 在没有 Harness 的情况下，仅凭一个高层提示（“构建一个 claude.ai 的克隆”）跨多个上下文窗口工作。结果出现了两种典型失败模式：

失败模式一：一次性尝试（One-shotting）。智能体试图在一个会话内完成所有工作，导致上下文在实现到一半时耗尽。下一个会话的智能体面对半成品代码，不得不花大量时间猜测发生了什么，然后试图修复——往往越修越乱。

失败模式二：过早宣告完成。在某些功能已经实现之后，后续的智能体实例环顾四周，看到"进展已经取得"，就宣布任务完成了。

这两种失败模式都不是模型能力的问题，而是架构问题：没有任何机制告诉智能体"还有什么没做"和"已经做到哪一步了"。

OpenAI 的百万行代码验证

OpenAI 的 Codex 团队在《Harness engineering: leveraging Codex in an agent-first world》中给出了更震撼的验证。他们在五个月内用三名工程师、零人工编码的方式构建了一个百万行代码的产品，其核心方法论就是：将代码仓库本身作为记录系统，通过结构化的文档、执行计划和进度日志，让每一次智能体运行都能快速定位当前状态。

这篇文章的核心洞察是：工程师的角色从"写代码的人"变成了"设计环境的人"。工程师不再实现功能，而是指定意图、设计约束、提供结构化反馈。

Philipp Schmid 的 2026 论断

Google DeepMind 的 Philipp Schmid 在 2026 年初提出了一个被广泛引用的判断：

如果 2025 年是智能体的开端，2026 年将围绕 Agent Harness 展开。

他指出 Agent Harness 之所以关键，有三个原因：

  1. 验证真实世界的进展：让用户能够测试和比较智能体在不同任务上的表现
  2. 实现可靠的自主性：通过结构化的约束和反馈循环，让智能体在人类设定的边界内自主工作
  3. 支持持续改进：提供可观测的指标和可调优的旋钮，让系统能够随时间变得更好

Harness 的核心架构

两阶段设计：Anthropic 方案

Anthropic 提出的 Harness 架构有一个优雅的两阶段设计：

阶段一：初始化智能体（Initializer Agent）。第一次运行时，使用专门的提示词，让智能体完成以下工作：

  • 生成 init.sh（如何启动开发环境）
  • 生成 feature_list.json（完整的功能需求清单，所有功能初始标记为 failing）
  • 创建初始 Git 提交（建立基线）
  • 生成 claude-progress.txt（进度日志的起点）

阶段二：编码智能体（Coding Agent）。每次后续运行时，使用另一套提示词，要求智能体：

  1. 运行 pwd 确认工作目录
  2. 读取 claude-progress.txt 和 Git 日志，了解当前状态
  3. 读取 feature_list.json，选择优先级最高的未完成功能
  4. 实现该功能，进行端到端测试
  5. 将功能标记为 passing，提交代码，更新进度日志

这个设计的精妙之处在于：每次会话的开始都有明确的"上下文恢复"步骤，每次会话的结束都有明确的"状态保存"步骤。 智能体不需要猜测，只需要按照协议执行。

六层模型：社区共识

综合 OpenAI、Anthropic、LangChain 和社区的实践，一个成熟的 Agent Harness 可以分解为六个层次：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────┐
│  第六层：约束层（Constraints）                        │
│  安全边界、权限控制、成本限制                          │
├─────────────────────────────────────────────────────┤
│  第五层：验证层（Verification）                       │
│  测试执行、Fitness Function、Hard Gate               │
├─────────────────────────────────────────────────────┤
│  第四层：持久化层（Persistence）                      │
│  进度日志、功能清单、Git 历史、外部记忆               │
├─────────────────────────────────────────────────────┤
│  第三层：上下文管理层（Context Management）            │
│  上下文压缩、选择性注入、知识库索引                    │
├─────────────────────────────────────────────────────┤
│  第二层：工具层（Tools）                              │
│  Shell、文件系统、浏览器、API 调用                     │
├─────────────────────────────────────────────────────┤
│  第一层：循环层（Loop）                               │
│  Agent Loop、消息处理、工具调用编排                    │
└─────────────────────────────────────────────────────┘

每一层都有独立的工程挑战，但它们之间的协作决定了整个系统的可靠性。

OpenAI Codex 的 App Server 架构

OpenAI 在 2026 年 3 月发布的《Unlocking the Codex harness: how we built the App Server》中，进一步揭示了他们的 Harness 架构细节。Codex 的 App Server 是一个完整的智能体运行时，它管理：

  • 沙箱环境：每个智能体任务在隔离的容器中运行
  • 工具注册与路由：统一的工具调用接口，支持跨提供商的智能体协议
  • 状态快照与恢复：在任务中断时能够从最近的检查点恢复
  • 可观测性：完整的执行轨迹记录，支持事后审计和调试

这个架构的关键洞察是：Harness 不是一个配置文件，而是一个运行时系统。它需要像操作系统一样被设计和维护。

LangChain 的实证：Harness 调优的威力

LangChain 团队在 2026 年 3 月发布的《Improving Deep Agents with harness engineering》中，提供了目前最具说服力的量化证据。

他们的编码智能体在 Terminal Bench 2.0 基准测试上，仅通过调优 Harness 而不更换模型，就从 Top 30 跃升到 Top 5。

LangChain 识别出的关键"调优旋钮"包括：

系统提示词的结构化

不是简单地告诉智能体"写好代码"，而是精确地规定：

  • 在什么条件下应该读取文件
  • 在什么条件下应该运行测试
  • 如何处理测试失败
  • 何时应该提交代码

工具选择与配置

哪些工具可用、工具的调用方式、工具输出的格式化——这些看似琐碎的决策，对智能体的表现有巨大影响。LangChain 发现，限制工具集反而比提供更多工具效果更好，因为过多的选择会导致智能体在工具选择上浪费 token。

上下文压缩策略

当对话历史变长时，如何压缩上下文而不丢失关键信息？LangChain 实验了多种策略，发现保留最近的工具调用结果和错误信息比保留完整对话历史更有效。

重试与恢复机制

当智能体遇到错误时，是立即重试、回退到上一个检查点，还是换一种策略？不同的恢复策略在不同类型的错误上表现差异巨大。

Harrison Chase 总结道：

Harness Engineering 是关于系统的。你在围绕模型构建工具，以优化任务性能、token 效率和安全性等目标。更好的模型本身不会让你的智能体达到顶级水平——你需要更好的 Harness。

Fitness Function：重新定义"完成"

Harness Engineering 解决了"如何让智能体持续工作"的问题，但还有一个更深层的问题：系统如何判断智能体已经完成了任务？

Phodal（黄峰达）在《Harness Engineering 的下一步：Fitness Function 定义 AI Agent 的完成条件》中，提出了一个深刻的洞察：

真正困难的问题不是"Agent 能不能写出代码"，而是：系统究竟如何判断，这个 Agent 已经完成了任务。

从经验判断到工程信号

在传统软件工程中，"完成"是一种被团队经验默契支撑的判断。开发者写完代码、跑过测试、提交 PR、经过 code review，团队逐渐形成共识。但在 Agent Loop 中，这个默认前提不再成立。

Agent 可以很快生成代码、修掉报错，但它同样很容易制造另一类结果：代码看起来已经完成，实际上只是完成了一半。功能路径可以跑通，但负向路径没有覆盖；接口已经修改，但契约没有同步；测试数量增加了，但关键不变量并没有被验证。

如果系统没有明确的完成条件，Agent Loop 很容易在"看起来差不多了"的状态下提前结束。

Fitness Function 的角色转变

Fitness Function 最早来自演进式架构（Evolutionary Architecture），用于持续验证系统是否满足某些架构特征。但在 AI Agent 参与开发之后，这个概念的角色正在发生变化——从"架构质量检查"变成了"完成条件机制"。

AI Agent 并不天然理解"真正完成"意味着什么。它往往依赖局部信号来判断进度：命令执行成功、测试通过、报错消失。这些信号在单次操作中是有效的，但它们从来不等价于系统层面的完成。

Fitness Function 在这里的价值，是把隐性的工程条件编码成系统可执行的规则：哪些信号必须出现，哪些条件必须满足，否则任务就不能被视为完成。

Routa 项目的实践

Phodal 在 Routa 项目中构建了一套完整的 Fitness 架构。一个关键原则是：Fitness 规则必须成为仓库的一部分，而不是 CI 系统的附属配置。 只有当规则存在于代码库中，它才能被 Agent 读取、被脚本执行、被 CI 消费，并在失败时真正阻断流程。

项目中的 Fitness 目录结构如下：

1
2
3
4
5
6
7
8
9
docs/fitness/
├── README.md              # 规则手册
├── unit-test.md           # 测试证据
├── api-contract.md        # 契约证据
├── rust-api-test.md       # API 测试矩阵
├── security.md            # 安全扫描规则
├── code-quality.md        # 代码质量规则
└── scripts/
    └── fitness.py         # 统一执行器

规则被写进 Markdown 的 frontmatter 中，既是文档的一部分，也是一种结构化声明：

1
2
3
4
5
6
7
8
9
10
11
12
---
dimension: testability
weight: 14
threshold:
  pass: 80
  warn: 70
metrics:
  - name: ts_test_pass
    command: npm run test:run 2>&1
    pattern: "Tests\\s+(\\d+)\\s+passed"
    hard_gate: true
---

Hard Gate：Agent 时代的 Definition of Done

在 AI Agent 场景中，单纯的评分体系往往不够。Agent 很容易把"还不错"误解为"可以结束"。因此，Fitness 系统最终必须具备一个更直接的机制：Hard Gate。

Gate 命令 阈值
ts_test_pass npm run test:run 100%
rust_test_pass cargo test --workspace 100%
api_contract_parity npm run api:check pass
lint_pass npm run lint 0 errors

Hard Gate 失败会直接阻断流程，而不是进入评分体系。它把"质量折损"和"流程终止"明确区分开来。

Hard Gate 就是 Agent 时代的 Definition of Done：它明确规定，在什么条件下，这个自动化参与者才被允许退出循环。

契约一致性：防止语义漂移

在多后端系统中（如 Routa 的 Next.js + Rust/Axum 架构），AI Agent 最容易制造的问题不是语法错误，而是语义漂移：每个局部修改看起来都是合理的，但多个实现之间逐渐失去同构关系。

将 API 契约一致性纳入 Fitness 规则，用 OpenAPI 文件作为单一事实来源（Single Source of Truth），本质上是在为 Agent 提供一个不容易漂移的重心。

可观测性驱动的 Harness：Datadog 的视角

Datadog 在 2026 年 3 月发布的《Closing the verification loop: Observability-driven harnesses for building with agents》中，从可观测性的角度重新审视了 Harness Engineering。

他们的核心论点是：验证闭环（Verification Loop）是 Harness 的灵魂。一个没有验证闭环的 Harness，就像一个没有仪表盘的飞机——你可以起飞，但你不知道自己飞向哪里。

Datadog 提出的验证闭环包含三个环节：

  1. 执行追踪：记录智能体的每一步操作，包括工具调用、文件修改、命令执行
  2. 结果验证：对每一步操作的结果进行自动化验证，而不是依赖智能体的自我报告
  3. 偏差检测：当智能体的行为偏离预期轨迹时，自动触发纠正或人工介入

这个视角的深刻之处在于：它把 Harness 从"控制系统"升级为"观测系统"。你不仅要告诉智能体做什么，还要能够看到它实际做了什么，并在出问题时及时干预。

工程师角色的根本转变

Harness Engineering 带来的最深远影响，不是技术架构的变化，而是工程师角色的根本转变。

从实现者到设计者

OpenAI 的 Codex 团队在文章中明确指出：

工程师的角色从"写代码的人"变成了"设计环境的人"。

在传统软件开发中，工程师的核心技能是实现——把需求转化为代码。在 Harness Engineering 范式下，工程师的核心技能变成了：

  • 意图规格化：将模糊的需求转化为精确的、可机器验证的规格
  • 环境设计：构建让智能体能够高效工作的工具、约束和反馈循环
  • 品味编码：将人类的审美判断和工程直觉编码为可执行的规则
  • 失败分析：当智能体产出不符合预期时，判断是模型问题、提示词问题还是 Harness 问题

从"写代码"到"监督代码"

HumanLayer 在《Skill Issue: Harness Engineering for Coding Agents》中提出了一个尖锐的观点：当你的智能体表现不佳时，这不是模型的问题，而是你的 Harness 的问题——这是一个"技能问题"（Skill Issue）。

这个观点的潜台词是：在 Harness Engineering 范式下，工程师的能力不再体现在写出多优雅的代码，而是体现在能否设计出让智能体持续产出高质量代码的系统。

这与 Phodal 的观察一致：

AI 时代的软件工程，需要重新发明"完成"。

实践指南：构建你的第一个 Harness

综合各方实践，以下是构建 Agent Harness 的关键步骤：

第一步：定义外部记忆结构

创建 AGENTS.md（或 CLAUDE.md）作为智能体的入口文件，但保持它精简——约 100 行，作为目录指向详细文档。Codex 团队的教训是：一个巨大的指令文件会挤占任务、代码和相关文档的空间，过多的指导反而失效。

第二步：设计任务状态协议

选择一种任务状态的持久化方式：

  • 进度日志（如 claude-progress.txt）：适合线性任务
  • 功能清单（如 feature_list.json）：适合可并行的功能开发
  • 执行计划（如 exec-plans/）：适合复杂的多阶段项目

关键原则：写给下一个智能体实例读，而不是写给人读。 因此它需要足够结构化，让智能体能快速定位关键信息。

第三步：建立验证闭环

为每个关键质量维度定义 Fitness Function：

  • 测试通过率
  • 代码规范检查
  • API 契约一致性
  • 安全扫描

将这些规则编码为可执行的脚本，并通过 Hard Gate 机制阻断不合格的提交。

第四步：实现上下文恢复协议

每次智能体会话开始时，执行固定的"上下文恢复"序列：

  1. 读取进度日志
  2. 查看最近的 Git 提交
  3. 检查功能清单的当前状态
  4. 确定下一个要处理的任务

每次会话结束时，执行固定的"状态保存"序列：

  1. 提交代码并写清楚提交信息
  2. 更新进度日志
  3. 更新功能清单状态

第五步：设置可观测性

记录智能体的执行轨迹，包括：

  • 每次工具调用的输入和输出
  • 每次文件修改的 diff
  • 每次测试运行的结果
  • token 消耗和成本

这些数据是持续优化 Harness 的基础。

Harness Engineering 的未来方向

方向一：自适应 Harness

当前的 Harness 大多是静态配置的——规则写好后，智能体按规则执行。未来的方向是自适应 Harness：系统根据智能体的历史表现，动态调整约束的松紧度、工具的可用性、上下文的注入策略。

方向二：多智能体 Harness

当多个专业化智能体需要协同工作时，Harness 需要从"管理一个智能体"升级为"编排一个智能体团队"。这涉及任务分配、状态同步、冲突解决等更复杂的工程挑战。

方向三：Harness 即平台

随着 Harness Engineering 的成熟，它可能会从"每个团队自建"演进为"平台化服务"。就像 CI/CD 从自建脚本演进为 GitHub Actions 和 GitLab CI 一样，Agent Harness 也可能会出现标准化的平台和协议。

MCP（Model Context Protocol）、A2A（Agent-to-Agent）、ACP（Agent Communication Protocol）等协议的出现，已经在为这个方向铺路。

方向四：从编码扩展到更广泛的领域

Anthropic 在其 Harness 工程博客中提到，他们相信这些经验"可以应用到科学研究或金融建模等领域所需的长期智能体任务类型"。Harness Engineering 的核心原则——状态持久化、验证闭环、约束编码——并不局限于编码场景。

小结

问题 答案
Harness Engineering 是什么？ 包裹在 LLM 外部的控制与协调系统，负责工具编排、上下文管理、状态持久化、验证约束
它为什么重要？ 模型不是瓶颈，驾驭模型的基础设施才是。LangChain 仅通过调优 Harness 就从 Top 30 跃升到 Top 5
核心架构是什么？ 六层模型：循环 → 工具 → 上下文管理 → 持久化 → 验证 → 约束
如何定义"完成"？ Fitness Function + Hard Gate：将隐性的工程条件编码为可执行的规则，阻断不合格的输出
工程师的角色如何变化？ 从实现者到设计者：不再写代码，而是设计让智能体高效工作的环境
未来方向是什么？ 自适应 Harness、多智能体编排、平台化服务、跨领域扩展

Harness Engineering 不是一个临时的技术热点，而是 AI 智能体从"演示"走向"生产"的必经之路。当我们不再问"AI 能不能写代码"，而是问"如何让 AI 持续、可靠、可验证地写代码"时，答案就是 Harness Engineering。

正如 Phodal 所说：

当自动化参与者越来越多时，软件工程必须重新定义"完成"的含义。

而 Harness Engineering，正是这个重新定义的工程实践。

参考资料