117 lines
5.4 KiB
Markdown
Executable File
117 lines
5.4 KiB
Markdown
Executable File
---
|
||
created: 2026-04-28
|
||
type: concept
|
||
tags: [Harness-Engineering, AI-Agent, 驾驭工程, 智能体环境]
|
||
---
|
||
|
||
# Harness Engineering（驾驭工程）
|
||
|
||
> 基于 11 篇原始资料整理（OpenAI、Anthropic、Thoughtworks、LangChain 等）
|
||
|
||
## 核心公式
|
||
|
||
```
|
||
AI Agent = Model（模型）+ Harness（挽具/环境）
|
||
```
|
||
|
||
**Harness** 是围绕 AI 模型构建的一切——工具、指令、状态管理、验证机制、运行时基础设施——它让模型的智能变得"可用"。
|
||
|
||
> "The model contains the intelligence and the harness is the system that makes that intelligence useful." —— LangChain
|
||
|
||
## 各机构定义对比
|
||
|
||
| 机构 | 定义侧重点 | 主要比喻 | 关键差异 |
|
||
|------|-----------|---------|---------|
|
||
| **LangChain** | Harness = 除模型外的一切 | 工作引擎 | 定义范围最广 |
|
||
| **Anthropic** | 多上下文窗口持续任务的环境脚手架 | 环境脚手架 | 聚焦长期运行的连续性与状态管理 |
|
||
| **OpenAI** | 结构化文档库、架构约束、可观测性栈 | 代码仓库即知识系统 | 术语使用不明确，强调"零人工代码" |
|
||
| **Thoughtworks** | 内层（工具内置）+ 外层（用户自建） | 赛博内廷 | 唯一区分"构建者"与"用户"挽具 |
|
||
| **HumanLayer** | 上下文工程的子集 | 配置即杠杆 | 最关注防止"上下文腐烂" |
|
||
| **Inngest** | 持久化事件驱动基础设施 | 布线挽具/安全带 | 唯一来自 DevOps 视角 |
|
||
| **学术界 (CAR)** | Control-Agency-Runtime 三维度 | CAR 框架 | 提出 HarnessCard 报告格式 |
|
||
|
||
## 五大子系统
|
||
|
||
```
|
||
┌─────────────────────────────────────┐
|
||
│ THE HARNESS │
|
||
│ Instructions │ State │ Verification│
|
||
│ AGENTS.md │progress│ tests+lint │
|
||
│ CLAUDE.md │feature │ type-check │
|
||
│ docs/ │git log │ e2e pipeline│
|
||
│ │
|
||
│ Scope │ Session Lifecycle │
|
||
│ one feature │ init.sh at start │
|
||
│ at a time │ clean state at end │
|
||
│ │ handoff note │
|
||
└─────────────────────────────────────┘
|
||
```
|
||
|
||
1. **Instructions（指令）**：Agent 的初始上下文
|
||
2. **State（状态）**：跨会话跟踪
|
||
3. **Verification（验证）**：测试、lint、类型检查
|
||
4. **Scope（范围）**：限定任务边界
|
||
5. **Session Lifecycle（会话生命周期）**：初始化、移交、清理
|
||
|
||
## 三维挽具分类
|
||
|
||
| 类型 | 调控对象 | 示例 |
|
||
|------|---------|------|
|
||
| **Velocity Harness** | 开发速度 | PR 大小、周期时间、合并阻塞 |
|
||
| **Sustainability Harness** | 代码质量 | 重复代码、圈复杂度、测试覆盖率 |
|
||
| **Architecture Fitness** | 架构特征 | 性能要求、可观测性、依赖方向 |
|
||
| **Behaviour Harness** | 功能正确性 | 规格说明、测试套件、端到端验证 |
|
||
|
||
## 优势 ✅
|
||
|
||
- **显著提升任务质量**：Anthropic 实验，同一模型无 Harness 产出无法运行，有 Harness 产出可实际游玩
|
||
- **突破上下文窗口限制**：通过会话移交文件跨多窗口工作数小时至数天
|
||
- **减少人工监督**：自动捕获修正问题，降低审查负担
|
||
- **工程化可复制**：最佳实践编码为 Harness，团队共享复用
|
||
- **架构约束自动化**：linter 和结构测试自动执行规范
|
||
- **防止上下文腐烂**：子智能体作为"上下文防火墙"
|
||
- **提高信任度**：静态分析、测试运行、架构检查提供质量保证
|
||
|
||
## 劣势 ⚠️
|
||
|
||
- **前期构建成本高**：编写 AGENTS.md、init.sh、验证脚本等初期更慢
|
||
- **运行成本显著增加**：多 Agent 架构成本提升 20 倍以上（$9 vs $200）
|
||
- **维护与漂移**：Harness 文件会过时，需要持续的"文档园艺"
|
||
- **模型过拟合风险**：模型在训练所用 Harness 上过度拟合
|
||
- **行为正确性仍难保证**：对"功能是否符合用户意图"保证有限
|
||
- **复杂度膨胀陷阱**：过度工程化浪费时间调优配置
|
||
- **可测性差**：缺少 Harness 覆盖率指标
|
||
|
||
## 适用场景
|
||
|
||
| 高度适用 | 不适用 |
|
||
|---------|--------|
|
||
| 长期运行的编码任务 | 一次性简单任务 |
|
||
| 企业级/遗留代码库自动化 | 高度不确定或创意性任务 |
|
||
| 从零到一构建产品（无人工代码） | 模型能力覆盖的任务 |
|
||
| 反复出现相同类型失败的 Agent 工作流 | 团队不具备工程化能力 |
|
||
| 多 Agent 协作系统 | |
|
||
| 需要高可靠性的生产环境 | |
|
||
|
||
## 与其他方法的关系
|
||
|
||
| 方法 | 关系 |
|
||
|------|------|
|
||
| [[AgenticSE 智能体软件工程]] | Harness 是解决 AI 队友可靠性的具体技术 |
|
||
| [[SDD 规格驱动开发]] | Harness 关注环境，SDD 关注规格 |
|
||
| [[Superpowers 技能框架]] | Harness 关注环境，Superpowers 关注流程 |
|
||
|
||
## 原文档
|
||
|
||
- `/obsidian/参考资料/Harness_Engineering/`
|
||
- OpenAI: Harness engineering: leveraging Codex in an agent-first world
|
||
- Anthropic: Effective harnesses for long-running agents
|
||
- Thoughtworks: Harness engineering for coding agent users
|
||
- LangChain: The Anatomy of an Agent Harness
|
||
- HumanLayer: Skill Issue: Harness Engineering for Coding Agents
|
||
- Inngest: Your Agent Needs a Harness, Not a Framework
|
||
- 学术论文: The Harness Layer as Control, Agency, and Runtime
|
||
|
||
---
|
||
|
||
*基于 11 篇原始资料整理，整理日期：2026-04-28* |