Harness Engineering（驾驭工程）

来源： wiki/sources/wechat-batch-a-agent-dev-tools
相关概念： wiki/concepts/spec-driven-development, wiki/concepts/harness-architecture, wiki/concepts/context-environment-engineering, wiki/concepts/ai-coding-agent

Harness Engineering（驾驭工程/脚手架工程）是 AI Agent 开发中构建包裹模型的执行外壳的工程学科。它不是某条提示词或某个工具，而是一整套把大模型纳入工程体系的控制面。

定义

"决定一个智能体到底能不能在真实世界打工的，其实早就不是模型本身，而是包在模型外面的那层壳。"

Harness 是为了把一台"聪明但没有工程常识的非确定性引擎"嵌进"确定的业务流水线"而设计的物理控制面。与传统软件工程的本质区别：传统软件工程管的是「确定性」，Harness Engineering 管的是「非确定性」。

三代工程范式演进

阶段	时期	聚焦点	核心问题
Prompt Engineering	2022-2024	如何说	"怎么写好一条指令"
Context Engineering	2025	让 AI 看什么	"怎么提供足够且精准的上下文"
Harness Engineering	2026+	构建怎样的运行环境	"怎么构建系统性框架来约束和驱动 AI"

ETCLOVG 七层架构

由 CMU、耶鲁、亚马逊等联合提出的系统化框架，从 170+ 开源项目中提炼：

结构核心（前四层）

Execution（执行环境与沙箱） — 物理执行空间，确保可复现性和安全性
通用托管沙盒：Daytona、E2B
计算机使用：Anthropic Computer Use
代码专用：OpenAI Code Interpreter
Tools（工具发现与调用） — 协议标准、工具描述、增强训练
MCP（工具接入）、A2A（Agent 间通信）、OpenAPI（API 合约）
关键洞察：工具不是越多越好，少而精胜过大而全
Context（上下文管理） — 决定 Agent 每一步能看到什么
短期（活动窗口/内存）：系统提示词 + KV 缓存
中期（会话状态/休眠文件）：结构化笔记
长期（持久记忆/硬盘）：Mem0、向量数据库
挑战：注意力成本 O(n²)，上下文腐烂
Lifecycle（生命周期编排） — 管理多次调用、重试和崩溃中的执行流
单 Agent 内循环（ReAct）
多 Agent 编排（分层、图组合）
全生命周期流水线（提需求→合并代码）

控制平面（后三层）

Observability（可观测性） — 追踪、监控、排错
基于 OpenTelemetry 的 Langfuse、Arize Phoenix
成本追踪：每个子任务可能触发几十次调用
解耦架构：Anthropic Managed Agents "大脑与双手分离"
Verification（验证评测） — 评测模型+Harness 整体组合
五阶段生命周期：环境准备→前置验证→受控执行→多级判断→回归反馈
核心：不能只看结果，要评估工具调用是否合理
Governance（治理安全） — 权限管理、生命周期钩子、审计
四个拦截点：输入前防注入、执行前防越权、返回后污点追踪、关键动作前人工审批
声明式宪法：安全规则写成配置文件

约束绑定假说

在多步骤、工具密集的长任务中，系统表现不再主要由模型本身决定，而是由模型外部的 Harness 决定。

验证数据：
- 仅修改编辑工具格式和周边 Harness，多模型编码基准提升高达 10 倍
- 固定 GPT-5.2-Codex，仅通过 Harness 优化，Terminal-Bench 2.0 从 52.8% 升至 66.5%
- Meta-Harness 自动优化达到 76.4%，超越手工方案

架构坐标系

两个维度界定 Harness 边界：
- X 轴（执行流路由）：静态预设 vs. 动态自主
- Y 轴（状态与上下文）：隐式内部 vs. 显式外部

四象限：
| 象限 | 特征 | 适用场景 |
|------|------|---------|
| ① Harness Engineering | 动态+显式 | 长任务、团队维护 |
| ② 提示词驱动 | 动态+隐式 | 探索性任务、短链路 |
| ③ 无状态链 | 静态+隐式 | 高并发、一次性调用 |
| ④ 传统管道 | 静态+显式 | 固定流程、LLM 做处理节点 |

好 Harness vs 伪 Harness

伪 Harness（软约束陷阱）：
- Prompt 里写 5000 字 DO NOT — 是"口头嘱咐"，不是物理约束
- 塞 20 个 API 让 Agent 自己挑 — 没有边界约束

劣质 Harness：
- 暴力死循环重试 — 模型可能为修语法错把核心架构删了
- 强制重型文档流 — 浪费 Token，现实一变文档就废

好的 Harness：
- 前置验证（Evaluator 沙盒）
- 最小真相源（Spec is Truth）
- 物理门禁（Checkpoint Before Execute）
- 后置断言（闭环回写，外部证据交叉验证）

开发者角色转变

Harness Engineering 不只是"把模型管住"，也在重塑工程师角色：
- 从执行者→控盘者
- 从"写代码的人"→"定义目标、卡住边界、掌控节奏、验收结果的人"
- 关键能力：知道什么时候不必盯细节，什么时候必须下潜检查

"要完成身份迁移，就必须学会放权；要安全放权，就必须先建 Harness。"

落地路径

先搭真相源：建立 Spec 和状态文档机制
约束执行边界：引入 Checkpoint 和 Approval
构建最小能力目录：明确可用 Tool 和接口边界
前置验证闭环：尽早接入单测、回归和日志检索
完善恢复机制：任务中断能随时重载继续
逐步释放自由度：先铺轨道，再追求速度

创建于：2026-06-16 | 基于微信公众号文章合集批次 A