Harness Engineering：AI Agent 的工程化之道

摘要

随着大语言模型（LLM）能力的快速提升，AI Agent 已从实验性工具演进为能够执行复杂任务的生产力系统。然而，Agent 的"有用性"与"可靠性"之间存在显著鸿沟——它们足够强大以至于可以被委以重任，却也足够不可预测以至于可能产生灾难性后果。Harness Engineering（约束工程） 正是在这一背景下应运而生的工程方法论，它标志着 AI 工程化从"如何与模型对话"向"如何构建可靠的 Agent 系统"的根本性转变。

本文将系统性地介绍 Harness Engineering 的概念内涵、核心原理、技术框架及实践方法，为构建可靠的 AI Agent 系统提供理论指导与实践参考。

1. 引言：从 Prompt 到 Harness 的演进

1.1 AI 工程能力的三次跃迁

AI 与人类协作的工程化实践经历了三个阶段的演进：

阶段 核心概念 解决的问题 局限性
第一阶段 Prompt Engineering 如何写出更好的指令，让模型一次性给出预期结果 依赖单次交互，缺乏上下文持续性
第二阶段 Context Engineering 如何管理上下文窗口，优化信息检索与组织 仍聚焦于"模型看到什么"，而非"系统如何行为"
第三阶段 Harness Engineering 如何构建可靠的 Agent 运行环境与约束机制 —

1.2 为什么需要 Harness Engineering？

Anthropic 在其长期运行 Agent 的研究中揭示了核心问题：Agent 需要跨会话工作，但模型本身没有持久记忆。解决方案是将记忆外部化为结构化产物——功能列表、进度日志、Git 提交、初始化脚本等。

OpenAI 的实践更具说服力：他们构建了一个约百万行代码的内部产品，零手动编写源代码。关键不在于模型本身，而在于围绕 Agent 构建的基础设施：

  • 结构化的仓库文档作为真实信息源
  • AGENTS.md 作为导航地图
  • 通过 Linter 和测试强制执行的分层架构
  • 合并前的 Agent 间审查循环
  • 后台清理 Agent 修复代码漂移

这不再是写提示词，而是基础设施设计。

2. 核心概念

2.1 定义

Harness（约束层） 是 AI Agent 中除模型本身之外的所有组成部分。

Agent = Model + Harness

在 Coding Agent 的上下文中，Harness 包含：

  • 系统提示词（System Prompt）
  • 代码检索机制
  • 编排系统（Orchestration System）
  • 用户自定义的外部约束层

2.2 与相关概念的区别

1
2
3
4
5
6
7
8
9
┌─────────────────────────────────────────────────────────┐
│                    Harness Engineering                   │
│  ┌─────────────────────────────────────────────────┐   │
│  │              Context Engineering                  │   │
│  │  ┌─────────────────────────────────────────┐    │   │
│  │  │           Prompt Engineering              │    │   │
│  │  └─────────────────────────────────────────┘    │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘
概念 关注点 典型问题
Prompt Engineering 单次交互质量 “如何写出更好的指令？”
Context Engineering 信息呈现优化 “模型应该看到什么信息？何时检索？如何摘要？”
Harness Engineering 系统行为约束 “何时加载上下文？允许哪些工具？如何处理失败？什么才算完成？”

Context Engineering 决定模型看到什么，Harness Engineering 决定系统如何行为。

3. 技术框架

3.1 前馈控制与反馈控制

Harness 通过两类机制约束 Agent 行为：

3.1.1 前馈控制（Guides）

定义：预判 Agent 行为并尝试在行动前进行引导。

目标：提高 Agent 首次生成正确结果的概率。

类型：

  • 计算型（Computational）：确定性、快速，由 CPU 执行

    • 代码转换工具（Codemods）
    • 结构化模板
    • 静态分析规则

  • 推理型（Inferential）：语义分析，由 GPU/NPU 执行

    • AGENTS.md 规则
    • Skills（技能模块）
    • 项目引导说明

3.1.2 反馈控制（Sensors）

定义：在 Agent 行动后进行观察，帮助其自我修正。

目标：检测问题并触发修正循环。

类型：

  • 计算型：

    • Linter（ESLint、Semgrep）
    • 类型检查器
    • 测试覆盖率报告
    • 依赖分析工具

  • 推理型：

    • AI 代码审查
    • 架构审查
    • “LLM as Judge” 质量评估

3.2 控制矩阵

控制类型 方向 执行方式 示例实现
编码规范 前馈 推理型 AGENTS.md、Skills
项目初始化指南 前馈 混合型 Skill + 引导脚本
代码转换 前馈 计算型 OpenRewrite 集成工具
结构测试 反馈 计算型 ArchUnit 模块边界检查
审查指导 反馈 推理型 Review Skills

4. 调控类别

4.1 可维护性约束（Maintainability Harness）

目标：调控代码的内部质量和可维护性。

特点：

  • 最成熟的约束类型
  • 可复用大量现有工具生态

实现示例：

  • 编码风格 Linter
  • 代码复杂度分析
  • 测试覆盖率阈值
  • 依赖版本检查

4.2 架构适配约束（Architecture Fitness Harness）

目标：确保代码符合架构设计原则和模块边界。

实现方式：

  • 模块依赖检查（如 ArchUnit）
  • API 契约测试
  • 分层架构验证
  • 端口适配器模式检查

4.3 行为约束（Behaviour Harness）

目标：验证系统的外部可观察行为是否符合预期。

挑战：

  • 需要运行时环境
  • 测试成本较高
  • 非确定性因素更多

实现方式：

  • 端到端测试
  • 集成测试
  • 契约测试
  • 运行时监控

5. 实践方法

5.1 质量左移（Keep Quality Left）

将检查尽可能前置到开发流程的早期阶段：

1
2
3
4
5
6
7
8
9
┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│ 编码前  │ → │ 提交前  │ → │ 合并前  │ → │ 部署后  │
├─────────┤   ├─────────┤   ├─────────┤   ├─────────┤
│ LSP     │   │ Linter  │   │ 全面测试│   │ 监控    │
│ 架构文档│   │ 快速测试│   │ 架构审查│   │ SLO 检查│
│ Skills  │   │ 覆盖率  │   │ 安全扫描│   │ 日志分析│
└─────────┘   └─────────┘   └─────────┘   └─────────┘
    ↑             ↑             ↑             ↑
  毫秒级        秒级          分钟级        持续

5.2 渐进式信息披露（Progressive Disclosure）

问题：将所有信息一次性注入上下文窗口会导致信息过载和上下文腐化。

解决方案：

  • 前置简短导航地图
  • 按需拉取深层信息源
  • 避免将上下文窗口当作"垃圾填埋场"

5.3 驾驶循环（The Steering Loop）

人的角色从"编写每一行代码"转变为"通过迭代 Harness 来引导 Agent"：

1
2
3
4
5
6
7
8
9
10
┌─────────────────────────────────────────────────────┐
│                                                     │
│   ┌─────────┐      ┌─────────┐      ┌─────────┐   │
│   │  问题   │  →   │ 改进    │  →   │  更少   │   │
│   │  发生   │      │ Harness │      │  问题   │   │
│   └─────────┘      └─────────┘      └─────────┘   │
│        ↑                                    │     │
│        └────────────────────────────────────┘     │
│                   持续迭代                        │
└─────────────────────────────────────────────────────┘

当问题多次发生时，改进前馈和反馈控制，使其在未来更不可能发生。

6. 行业实践案例

6.1 LangChain：仅改 Harness 提升 25 名

在 Terminal Bench 2.0 基准测试中，LangChain 通过仅改变 Harness（不更换模型），将 Coding Agent 的排名从 30 名开外提升至前 5 名。

关键改进：

  • 更好的工具编排
  • 更严格的输出验证
  • 更智能的上下文管理

6.2 Stripe：千级 PR 合并

据报道，Stripe 每周有超过 1000 个由 Agent 生成的 PR 被合并。

关键机制：

  • 隔离的沙箱环境
  • 硬性 CI 限制
  • 明确的升级规则
  • 人工介入触发条件

6.3 Datadog：生产遥测作为 Harness

Datadog 将生产环境遥测数据纳入 Harness 组成部分：

  • 性能回归信号反馈到 Agent 循环
  • 实时监控驱动自动修复建议
  • 从"生成代码"到"生成-验证-修复"的闭环

7. 挑战与展望

7.1 当前挑战

挑战 描述
记忆断裂 Agent 的记忆机制仍不可靠，跨会话状态管理困难
验证盲区 自动化验证无法覆盖所有场景
工具安全 工具调用带来安全风险
Harness 债务 Harness 本身成为需要维护的产品，存在 bug 和漂移
注意力稀缺 Agent 输出速度远超人类审查能力

7.2 未来展望

程序员的角色转变：

  • 更少时间手动编写每一行代码
  • 更多时间设计 Agent 可以安全工作的"栖息地"
  • 更多机器可读文档、评估系统、沙箱、权限边界、结构化测试

核心洞察：

提示词是最简单的部分，可靠性才是真正的工作。

8. 结论

Harness Engineering 标志着 AI 工程化的新阶段。它不是 Prompt Engineering 的时髦重命名，而是当我们停止演示智能、开始尝试交付智能时所必需的工程方法论。

核心要点：

  1. Agent = Model + Harness：模型是引擎，Harness 是汽车的其他所有部分。
  2. 前馈 + 反馈：两者结合才能构建可靠的自我修正系统。
  3. 质量左移：将检查尽可能前置，降低修复成本。
  4. 渐进披露：避免上下文过载，按需加载信息。
  5. 持续迭代：通过驾驶循环不断改进 Harness。

未来的 AI 系统将更多是"模型在精心设计的环境中运行"，而非"一个天才模型做所有事情"。Harness Engineering 正是构建这些环境的关键方法论。

参考文献

  1. Böckeler, B. (2026). Harness engineering for coding agent users. Martin Fowler’s Blog.
  2. Bouchard, L. (2026). Harness Engineering: The Missing Layer Behind AI Agents.
  3. Anthropic. (2025). Building effective agents for long-running tasks.
  4. OpenAI. (2025). AI-assisted development at scale.
  5. Siemens. (2023). An exploration of wire harness engineering.

本文撰写于 2026 年 3 月，基于当时的技术发展状态整理。