Harness 工程：围绕 AI Agent 构建系统 (2026)

TL;DR

什么是 Harness 工程？

Harness 工程（Harness Engineering）是一门围绕 AI 编程 Agent 构建系统、工具、约束和反馈循环，以使其变得可靠且高效的学科。

该术语由 Mitchell Hashimoto（HashiCorp 联合创始人）提出，并在 2026 年初 OpenAI 发布关于 Codex 的文章探讨该话题时获得了主流关注。

核心理念很简单：

Agent = Model + Harness

模型提供智能。Harness 让这种智能变得有用。一个优秀的 Harness 往往比一个更好的模型更重要。

为什么它在当下至关重要

在 2025 年，每个团队都采用了 AI 编程 Agent。到 2026 年，胜出的团队是那些工程化其 Agent 环境的团队——而不仅仅是选择了最好的模型。

Mitchell Hashimoto 的指导原则是：

“每当你发现 Agent 出错时，就花时间设计一个工程化方案，使该 Agent 永远不会再犯同样的错误。”

这不是提示词工程 (Prompt engineering)。这是针对 AI 的系统工程 (Systems engineering)。

证据：Harness > 模型

LangChain 在 Terminal Bench 2.0 上进行了一项对照实验。在不改变底层模型的情况下，他们仅通过优化 Harness，将编程 Agent 的准确率从 52.8% 提升至 66.5%——实现了 26% 的提升。

这些改进包括：

• 更好的上下文文件 (AGENTS.md)


• 结构化的输出约束


• 自我验证循环


• 工具优化

Harness 的 7 个核心组件

1. 上下文工程 (Context Engineering)

上下文工程是基础。这是你向 Agent 提供代码库地图、规范和约束的地方。

• 在仓库根目录下放置 CLAUDE.md / AGENTS.md 文件
• 目录映射和架构概览
• 代码风格规则和命名规范

# CLAUDE.md example
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. 架构约束 (Architectural Constraints)

不要寄希望于 Agent 选择正确的架构，而是要强制执行它。

• 通过 Linter 验证的严格分层架构
• 违反模式即报错的结构化测试
• 通过 ESLint 规则或自定义脚本限制导入

3. 工具与 MCP 服务端

Agent 需要工具才能生效。优秀的 Harness 会通过以下方式暴露内部工具：

• CLI 封装 —— 优先使用众所周知的 CLI (git, docker, npm) 而非自定义工具
• MCP (Model Context Protocol) 服务端 —— 让 Agent 调用你的内部 API、数据库和服务
• 文件系统访问 —— 作用域限制在特定目录以防止意外损坏

4. 子 Agent 与上下文防火墙

长时间运行的 Agent 会话会累积上下文，最终导致性能下降——这被称为上下文腐烂 (Context rot)。

解决方案：带有上下文防火墙的子 Agent。

• 将复杂任务分解为离散的子任务
• 每个子任务在拥有新鲜上下文的独立会话中运行
• 仅在 Agent 之间传递结构化结果，而非原始对话

1. 初始化 Agent (Initializer Agent) —— 规划工作，创建功能列表
2. 编程 Agent (Coding Agent) —— 独立执行每个功能

5. 钩子与背压 (Hooks & Back-Pressure)

在错误复合之前捕获它们的自动化反馈循环：

• Pre-commit 钩子 —— 类型检查、Linting、格式化
• 测试运行器 —— Agent 应在每次更改后运行测试
• 构建验证 —— 构建失败时快速报错

6. 自我验证循环 (Self-Verification Loops)

在标记任务完成之前，强制 Agent 验证自己的工作：

• 更改后运行测试套件
• 检查构建是否通过
• 验证输出是否符合规范
• 截图并进行对比（针对 UI 工作）

7. 进度记录 (Progress Documentation)

对于运行时间较长（30 分钟以上）的任务：

• 维护一个记录已完成步骤的进度文件
• 频繁提交代码，以便后续会话可以继续
• 使用结构化的任务列表，而非随意记录

现实世界的成果

OpenAI Codex 团队

3 名工程师在 5 个月内产出了一个百万行规模的代码库，且没有一行手动编写的代码。他们平均每人每天合并 3.5 个 PR——如果没有成熟的 Harness，这种吞吐量是不可能的。

他们的 Harness 包括：严格的提交规范、每个 PR 的自动化测试，以及 Agent 感知的 CI/CD 流水线。

Stripe 的 "Minions"

Stripe 的内部系统每周通过 AI Agent 产出 1,000 多个合并的 PR。他们的 Harness 包括：

• 严格限制任务定义的作用域
• 强制的人工代码审查
• 自动化回归测试
• 回滚自动化

Anthropic 的双 Agent 架构

Anthropic 发布了他们针对长时间运行 Agent 的有效 Harness 构建方法：

• 使用结构化功能列表作为 Agent 之间的交接格式
• 基于 Git 的进度追踪，使 Agent 在中断后可以恢复
• 明确的退出标准，让 Agent 知道何时停止

如何开始构建你的 Harness

第一步：创建你的上下文文件

在项目根目录添加 CLAUDE.md (或 AGENTS.md)：

# Project: [Your Project]

## Stack
[Framework, language, database, hosting]

## Architecture
[Directory structure with one-line descriptions]

## Rules
[5-10 hard rules the agent must follow]

## Common Tasks
[How to run tests, build, deploy]

第二步：添加结构约束

# Example: ESLint rule preventing direct DB imports in components
# .eslintrc — no-restricted-imports rule

设置自动执行规则的 pre-commit 钩子。

第三步：构建验证循环

确保你的 Agent 可以：

1. 运行测试 (npm test, pytest 等)


2. 检查类型 (tsc --noEmit, mypy)


3. Lint 检查 (eslint ., ruff check)

第四步：限制 Agent 会话范围

不要把整个待办列表交给一个 Agent。相反：

• 每个会话只负责一个功能
• 每个会话只修复一个 Bug
• 为每个任务提供明确的验收标准

第五步：迭代 Harness

每当 Agent 出错时：

1. 确定根本原因
2. 添加一条规则、约束或钩子来防止该错误
3. 测试该修复方案

Harness 工程 vs. 提示词工程

提示词工程依然有用，但它只是冰山一角。Harness 工程才是杠杆。

新兴角色：Harness 工程师

工程工作正拆分为两半：

1. 环境构建 —— 创建结构、工具、约束和反馈循环
2. 工作管理 —— 规划、评审和编排并行 Agent 会话

请勿混淆：Harness.io

如果你搜索 “Harness Engineering” 是为了寻找 DevOps 平台 —— Harness.io 完全是另一回事。它是一个估值为 55 亿美元（截至 2025 年 12 月）的 AI 驱动 CI/CD 平台，提供持续集成、交付、特性标志、云成本管理和安全测试。

虽然 Harness.io 和 Harness 工程同名，但它们解决的是不同的问题。尽管二者存在有趣的交集：Harness.io 的 AI 驱动 DevOps 可以被视为 Harness 工程原则在部署流水线中的一种应用。

总结

模型是引擎，Harness 是汽车。没有人能仅靠引擎赢得比赛。

如果你在 2026 年使用 AI 编程 Agent 却不对 Harness 进行投入，那么你并没有发挥出它的真正价值。从上下文文件开始，添加约束，构建验证循环，并在出现问题时不断迭代。

交付最快的团队并不是使用了更好的模型，而是使用了更好的 Harness。