Harness Engineering
定义
Harness Engineering 是面向 AI Agent 的工程控制学科，研究如何在真实软件系统中构建一个可治理的执行环境（harness），使 Agent 的行为满足以下三类目标：
- 可控：行为边界清晰，可授权、可限制、可追责
- 可验：产出质量可检验，结果能被确定性或高置信机制判断
- 可改进：失败可反馈、可修复、可持续提升成功率
核心公式
Agent = Model + Harness- Model：无状态的纯推理「大脑」
- Harness：把大脑武装成 Agent 的「身体」——包括运行时、工具系统、上下文管理、权限控制、状态持久化等全套基础设施
它不是单一工具，而是由约束、验证、反馈与纠错构成的系统能力。
核心组件架构
Harness 由六大核心模块构成（数量可伸缩，关键在于拆解的可理解性）：
| 组件 | 作用 | 工程意义 |
|---|---|---|
| Agentic Loop | 接收输入 → 循环（推理-行动-工具执行）→ 返回结果 | 心脏，是 Agent 复杂行为的涌现源头，源自 ReAct 论文 |
| Tool System | 提供 API 调用、外部工具接入能力 | 手脚，扩展 Model 的行动范围，从「说」到「做」 |
| Memory & Context Management | 上下文压缩、记忆存储与检索 | 大脑皮层，解决上下文爆炸问题，Claude Code 在此领域领先 |
| Guardrails | Allow/Deny/Ask 权限控制机制 | 缰绳，解决权限失控问题，将不可控变为可治理 |
| Hooks | 关键节点的前置/后置守卫（如防止 .env 提交） | 守门员，在危险操作前拦截、审计或阻断 |
| Session | 会话状态管理与运行时控制 | 连接器，保证跨轮次对话的连续性和状态持久化 |
组件关系
Inform (输入)
│
▼
┌─────────────┐
│ Agentic Loop │ ◄──────┐
└──────┬──────┘ │
│ │
┌───────────┼───────────┐ │
│ │ │ │
▼ ▼ ▼ │
Tool Memory Guardrails │
│ │ │ │
└───────────┴─────┬─────┘ │
Constrain │
│ │
▼ │
Verify ─────┤
│ │
▼ │
Feedback │
│ │
▼ │
Correct ────┘
│
▼
输出/升级人工研究对象与边界
Harness Engineering 关注的是 “Agent 如何在工程系统里被管理”，而不只是“Agent 如何生成内容”。
研究对象
- 任务输入与上下文供给方式
- 执行权限与操作边界
- 结果验证与质量门禁
- 失败反馈与自动/人工修正机制
- 全流程可观测性与审计能力
非目标
- 不等同于 Prompt Engineering（只优化提示词）
- 不等同于 CI/CD（只做发布流水线）
- 不替代业务架构设计（它作用于执行治理层）
核心控制闭环
Harness Engineering 的最小闭环可表达为：
Inform -> Constrain -> Verify -> Feedback -> Correct
1.Inform（输入治理）
将任务目标、上下文和约束条件组织为可执行输入。核心关注“给对上下文”，而不是“给更多上下文”。
2.Constrain（行为约束）
定义 Agent 可做与不可做的边界，包括权限、路径、工具与预算等限制。目标是降低高风险行为概率并控制爆炸半径。
3.Verify（结果验证）
对产出进行质量判定。验证可分为确定性验证（规则、测试、静态检查）与概率性验证（评审模型/人工审查）。
4.Feedback（结构化反馈）
将失败信息转为可执行的修复输入，至少应包含失败位置、期望与实际差异、修复方向。
5.Correct（受限纠错）
在既定边界内执行修复并再次验证；当达到风险阈值或重试上限时升级人工处理。
解决的五大落地难题
Harness Engineering 的设计直接针对 Agent 落地的五大卡点：
| 落地难题 | 对应 Harness 能力 | 解决方案 |
|---|---|---|
| 无限循环 | Agentic Loop | 提供可控的循环机制，通过重试上限、预算、时间约束防止死循环 |
| 上下文爆炸 | Memory & Context Management | 通过上下文压缩、相关性过滤、智能检索控制 Token 消耗 |
| 权限失控 | Guardrails + Hooks | Allow/Deny/Ask 机制 + 关键操作守卫，实现精细化权限控制 |
| 质量不可控 | Verify + Feedback | 验证层确保产出质量，结构化反馈驱动持续改进 |
| 成本不透明 | Session + Constrain | 会话级别的成本追踪，预算约束控制执行范围 |
基本原则
最小充分上下文
上下文应以完成任务所需的最小集合为目标，避免噪声信息稀释关键约束。
最小必要约束
约束应覆盖关键风险面，但避免过度限制导致能力退化。约束质量优先于约束数量。
验证先于信任
是否“看起来合理”不能替代“被验证通过”。验证链路是系统可靠性的主干。
反馈必须可执行
失败反馈若不可定位、不可复现、不可操作，纠错闭环会失效。
自动化有边界
自动纠错必须受重试、预算、范围与风险策略约束，不能无限循环。
能力分层（概念模型）
L1 规则层
通过规则文件或策略声明定义任务边界与基本行为规范。
L2 执行层
在运行时对关键动作进行许可、阻断或升级，实现实时行为治理。
L3 验证层
通过测试、检查、评审等手段对产出进行多维质量判定。
L4 协同层
将自动化与人工审查连接为统一决策链，处理高风险与高不确定任务。
成熟度判据（用于识别是否具备 Harness 能力）
一个系统可被认为具备基础 Harness Engineering 能力，通常需要同时满足：
- 边界可声明：能明确表达权限、范围与禁止行为
- 过程可观测：关键决策与操作有日志和可追溯记录
- 结果可验证：存在稳定可执行的质量门禁
- 失败可闭环：失败能转化为结构化反馈并驱动修复
- 风险可升级：高风险任务可自动转入人工审查
常见误区
- 把“更多上下文”当作通用解法，忽略上下文质量和相关性
- 把“更多规则”当作通用解法，忽略约束冲突与执行成本
- 以单次通过率替代系统可靠性指标
- 只有结果检查，没有失败结构化反馈
- 只有自动修复，没有升级机制与人工兜底
一句话定义（便于引用）
Harness Engineering 是把 AI Agent 从”会做事”提升为”可治理地做对事”的工程方法。
实践指引
可复现性
构建 Harness 系统并非高不可攀：
- Claude Code 已泄露部分源码，可作为参考实现
- OpenAI 有多个开源 Agent 框架可借鉴
- 核心是理解各组件的职责边界，而非盲目堆砌功能
学习路径
建议按以下顺序深入：
- Agentic Loop —— 理解 ReAct 模式，掌握推理-行动循环
- Tool System —— 学会如何定义和调用工具
- Guardrails + Hooks —— 理解权限控制和安全守卫
- Memory & Context —— 深入 Context Engineering（Claude Code 的强项）
- Verify + Feedback —— 构建质量门禁和改进闭环