【AI】Harness Engineering：让 AI Agent 可靠完成任务的工程范式

AI
,

一句话解释

Harness Engineering（驾驭工程） 是一种 AI 工程新范式。其核心是：在不改动大模型本身参数的前提下，为 AI Agent 构建一套外部管控系统——管它的输出、管它的行为、管它的安全——把它从横冲直撞的「天才」变成企业能用、能靠得住的「可靠员工」。

为什么会出现这个概念？

AI Agent 的「天才病」

用过大模型写代码的人都有类似体验：让它写一个函数，强；让它写一个有 15 个文件的项目，崩。它会忘记前面文件的接口定义，会重复定义同一个变量，会在「修复」一个 bug 时引入三个新 bug，会在任务跑到一半时突然停下来问你要不要喝咖啡。

这不是因为模型不够聪明，而是因为模型缺乏工程化运行环境。

从「调模型」到「搭环境」

行业经历了三个阶段：

阶段 核心问题 解法
Prompt Engineering（提示词工程） 怎么问模型才答得好 写更好的 prompt
Context Engineering（上下文工程） 怎么给模型足够的信息上下文 RAG、文档注入
Harness Engineering（驾驭工程） 如何让 Agent 在长程任务中稳定可靠 构建完整运行控制系统

核心公式

LangChain 给出了最精准的技术定义：

Agent = Model + Harness

模型提供智能，Harness 让这个智能能用起来。

类比来说：

  • 如果把 AI Agent 比作一辆马车
  • Model（模型） = 那匹力大无穷、智力超群的马
  • Harness（驾驭系统） = 连接马与车厢、控制方向、调节速度的缰绳和装具

Harness 的六大核心组件

一个完整的 Harness 通常包含以下六大组件：

1. 约束（Constraints）

Agent 能做什么、不能做什么的边界定义。

  • 架构边界（如禁止跨层依赖）
  • 权限控制（如禁止删除文件）
  • 依赖规则（如只能 import 哪些包）

2. 上下文架构（Context Architecture）

Agent 需要知道什么才能做好任务。

  • 项目结构文档（AGENTS.md）
  • 编码规范与风格指南
  • 业务领域知识库

3. 验证回路（Self-Validation Loop）

Agent 做完了怎么知道做得对不对。

  • Linter 自动检测代码规范违规
  • 单元测试 / 集成测试自动运行
  • 截图对比（UI 类任务的视觉回归）

4. 修复机制（Error Recovery）

Agent 做错了怎么纠正，同样的错不犯第二次。

  • 错误信息含修复指令（而非仅报错）
  • 规则沉淀（同类错误写入 Harness 规则库）
  • 自动回滚机制

5. 状态管理（State Management）

Agent 在长程任务中如何维护进度和上下文。

  • 持久化知识记录
  • 任务进度追踪
  • 多轮对话中的记忆管理

6. 生命周期与协作（Lifecycle & Collaboration）

Agent 怎么启动、怎么交接、怎么与人协作。

  • 审批流（人工复核节点）
  • 子 Agent 派发策略
  • 与外部系统的交互协议

落地三阶段：不要一步到位

Harness Engineering 的落地不是「一把梭」，而是渐进式的：

Phase 1：信息层（1-2 天）

1
2
3
4
5
6
7
目标：让 Agent 输出一致

AGENTS.md 模式
    ↓
结构化文档 + 编码规范文档化
    ↓
收益：Agent 输出一致性 ↑

Phase 2：约束层（3-5 天）

1
2
3
4
5
6
7
目标：让代码质量可控

分层架构 + Linter
    ↓
CI 约束检查 + 错误信息含修复指令
    ↓
收益：代码质量可控 ↑

Phase 3：自动化层（1-2 周）

1
2
3
4
5
6
7
目标：减少人工审查量

Agent 自验证闭环
    ↓
CDP/截图自动验证 + 后台清理
    ↓
收益：人工审查量 ↓↓↓

反模式：七个常见误区

实施 Harness Engineering 时，以下七个误区需要特别警惕：

  1. 层级混淆：把太多东西塞进一个 AGENTS.md，挤占上下文窗口
  2. 过度工具化：让 Agent 过度依赖工具，失去自主判断能力
  3. 过早追求自治：在约束和验证体系不完善时追求 Agent 完全自主
  4. 一次性搭完所有基础设施：Phase 1 做扎实，Phase 2 是质变
  5. 规则过密：约束太多反而限制了 Agent 的创造力
  6. 缺乏 Human-in-the-Loop：关键节点没有人工复核机制
  7. 忽视可维护性：Harness 本身也需要版本管理和持续迭代

与 SDD（Spec-Driven Development）的关系

Harness Engineering 并不是替代 SDD，而是 SDD 的执行层：

  • SDD（Spec-Driven Development，规范驱动开发） 解决的是「做什么」和「怎么验证」——以规格文档（spec.md / spec.yaml）作为单一事实来源，规范驱动设计、实现与验证的全流程
  • Harness Engineering 解决的是「Agent 怎么可靠地执行 SDD 定义的方案」——提供 Agent 的约束、上下文、验证闭环与状态管理

没有 SDD，Harness 是盲目的；没有 Harness，SDD 是无法落地的。二者是互补关系。

未来方向：Meta-Harness

斯坦福、MIT 等机构提出了 Meta-Harness 框架，核心思路是：

不再只优化单条 prompt，而是把完整 harness 程序作为优化对象。让 coding agent 自主检索历史失败原因并改写 harness，把原本依赖人工试错的系统优化过程自动化。

实验数据显示，Meta-Harness 在在线文本分类任务上相比 ACE 基准平均准确率从 40.9% 提升到 48.6%，同时上下文开销从 50.8K tokens 降到 11.4K。

总结

维度 结论
本质 在模型之外，给 Agent 搭建「可读、可控、可验证、可恢复」的运行环境
核心公式 Agent = Model + Harness
解决的问题 AI 在长程任务中的稳定性、可靠性、可维护性
不需要做 微调模型、换模型
关键动作 约束设计 + 上下文注入 + 验证闭环 + 状态管理
落地策略 渐进式三阶段（信息层 → 约束层 → 自动化层）