支持增量编译wiki
This commit is contained in:
Junjian Wang
@@ -1,137 +1,146 @@
|
||||
---
|
||||
title: Harness 工程
|
||||
tags: [核心概念, Harness, 架构]
|
||||
source: [OpenAI, Anthropic, Martin Fowler, LangChain, NxCode]
|
||||
confidence_score: 高
|
||||
last_updated: 2026-04-07
|
||||
title: "Harness 工程"
|
||||
source: "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering"
|
||||
raw_sources:
|
||||
- path: raw/Externalization in LLM Agents A Unified Review of Memory, Skills, Protocols and Harness Engineering.md
|
||||
hash: "sha256:to-be-computed"
|
||||
tags:
|
||||
- "核心概念"
|
||||
- "Harness工程"
|
||||
- "智能体架构"
|
||||
last_updated: 2026-04-11
|
||||
---
|
||||
|
||||
# Harness 工程
|
||||
|
||||
**Harness 工程**（Harness Engineering）是设计和实现使 AI 智能体可靠工作的系统的新学科。如果说 2025 年是 AI 智能体验证它们能够编写代码的一年，那么 2026 年就是我们认识到**智能体不是难点——Harness 才是**的一年。
|
||||
**Harness 工程**是构建外部化 Agent 运行时环境的综合学科。它将记忆、技能和协议这三个外部化模块统一成一个连贯的认知环境。
|
||||
|
||||
## 核心定义
|
||||
## 什么是 Harness？
|
||||
|
||||
### 什么是 Harness？
|
||||
Harness 是将原始模型能力转化为可靠 Agent 行为的脚手架。实用的 Agent 最好被理解为在 Harness 内部运行的模型，而不是带有外围能力的模型。
|
||||
|
||||
术语 "Harness" 来源于马具——缰绳、马鞍、马嚼子——用于引导强大但不可预测的动物朝正确方向前进的全套设备。这个比喻是有意为之的：
|
||||
> **核心洞见**：Harness 不仅仅是实现便利性，它是设计的认知环境，外部化模块在其中共同生效。
|
||||
|
||||
- **马**是 AI 模型——强大、快速，但自己不知道要去哪里
|
||||
- **Harness**是基础设施——约束、护栏、反馈循环，用于高效地引导模型的能力
|
||||
- **骑手**是人类工程师——提供方向，而不是亲自奔跑
|
||||
### Harness 的功能组成
|
||||
|
||||
没有 Harness，AI 智能体就像开放田野里的纯种马。快速、令人印象深刻，但对于完成任何事情来说完全无用。
|
||||
Harness 包含使这种耦合成为可能的外部系统：
|
||||
- 持久记忆和项目级上下文
|
||||
- 可重用技能和可执行例程
|
||||
- 用于与工具和服务进行确定性交互的协议化接口
|
||||
- 更广泛的运行时基础设施
|
||||
|
||||
### Harness 工程的正式定义
|
||||
## Harness 的六大分析维度
|
||||
|
||||
**Harness 工程**是设计和实现以下系统的学科：
|
||||
|
||||
|
||||
1. **约束** AI 智能体可以做什么（架构边界、依赖规则）
|
||||
2. **告知** 智能体应该做什么（上下文工程、文档）
|
||||
3. **验证** 智能体正确执行了（测试、linting、CI 验证）
|
||||
4. **纠正** 智能体出错时（反馈循环、自我修复机制）
|
||||
### 1. 智能体循环和控制流
|
||||
|
||||
Martin Fowler 将其描述为"我们可以用来控制 AI 智能体的工具和实践"——但它不仅仅是安全。一个好的 Harness 使智能体**更有能力**，而不仅仅是更受控制。
|
||||
智能体循环是 Harness 的时间骨干。最简单的形式是实现感知-检索-计划-行动-观察周期。
|
||||
|
||||
## 为什么 Harness 工程现在如此重要
|
||||
**关键控制机制**：
|
||||
- 最大步数限制
|
||||
- 递归深度边界
|
||||
- 每步成本上限
|
||||
- 超时约束
|
||||
|
||||
### 模型是商品，Harness 是护城河
|
||||
这些控制定义了模型推理展开的操作 envelope。
|
||||
|
||||
AI 行业正面临一个令人不安的事实：**底层模型的重要性不如围绕它的系统。**
|
||||
### 2. 沙箱和执行隔离
|
||||
|
||||
LangChain 明确证明了这一点。他们的编码智能体在 Terminal Bench 2.0 上从 **52.8% 提升到 66.5%**——从 **Top 30 跃升至 Top 5**——对模型没有做任何改变。他们只改变了 Harness：
|
||||
每当 Agent 对世界采取行动时，Harness 必须决定暴露多少环境以及如何包含意外的副作用。
|
||||
|
||||
| 改变 | 他们做了什么 | 影响 |
|
||||
|------|-------------|------|
|
||||
| 自我验证循环 | 添加完成前检查清单中间件 | 在提交前捕获错误 |
|
||||
| 上下文工程 | 启动时映射目录结构 | 智能体从一开始就理解代码库 |
|
||||
| 循环检测 | 跟踪重复的文件编辑 | 防止"末日循环" |
|
||||
| 推理三明治 | 规划/验证使用高推理，实现使用中等推理 | 在时间预算内获得更好的质量 |
|
||||
**隔离粒度**：
|
||||
- **云沙箱** - 每个任务在专用云沙箱中运行，带有自己的文件系统快照、网络限制和资源配额
|
||||
- **分级权限模式** - 暴露从完全自主执行到每个工具调用都需要强制用户批准的分级权限模式
|
||||
|
||||
**相同的模型。不同的 Harness。显著更好的结果。**
|
||||
**沙箱的双重作用**：
|
||||
1. 安全围栏 - 限制危险操作
|
||||
2. 认知边界 - 通过移除不相关状态简化 Agent 的操作环境
|
||||
|
||||
### OpenAI 的 100 万行代码证明点
|
||||
### 3. 人工监督和审批门
|
||||
|
||||
OpenAI 的实验是迄今为止最令人信服的证据：
|
||||
完全自主很少适合部署的 Agent。大多数生产系统在 Agent 循环中插入干预点。
|
||||
|
||||
- **5 个月**的开发
|
||||
- 最终产品中有 **100 万+ 行代码**
|
||||
- **零行手动编写的代码**——每一行都是由 Codex 智能体生成的
|
||||
- **用人类所需时间的约 1/10 构建**
|
||||
- 产品有**内部日常用户和外部 Alpha 测试者**
|
||||
- 它**交付、部署、出故障并得到修复**——全部由 Harness 内的智能体完成
|
||||
**常见模式**：
|
||||
- **执行前批准** - 在每个可能有后果的行动之前暂停 Agent 并请求明确确认
|
||||
- **执行后审查** - 让 Agent 行动但在提交或继续之前将结果浮出水面进行检查
|
||||
- **升级触发器** - 允许 Agent 在正常条件下自主运行，但在检测到特定风险信号时暂停并请求人工输入
|
||||
- **Hook 系统** - 允许操作员将任意逻辑附加到 Agent 循环中的特定生命周期事件
|
||||
|
||||
工程师的工作？设计 Harness。指定意图。提供反馈。不是编写代码。
|
||||
### 4. 可观测性和结构化反馈
|
||||
|
||||
## 三大支柱
|
||||
不留下可检查轨迹的 Agent 是无法调试、审计或改进的 Agent。
|
||||
|
||||
OpenAI 的框架将 Harness 工程组织为三个核心类别：
|
||||
**可观测性的实现**：
|
||||
- 每个模型调用、工具调用、内存读/写和决策分支的结构化日志
|
||||
- 将每个行动与其因果前因联系起来的执行轨迹
|
||||
- 聚合指标，如步数、令牌消耗、错误率和延迟分布
|
||||
|
||||
### 1. 上下文工程
|
||||
**双重目的**：
|
||||
1. **外部** - 支持调试、合规审计和事件后分析
|
||||
2. **内部** - 关闭将执行结果连接回产生它们的模块的反馈循环
|
||||
|
||||
上下文工程是关于确保智能体在正确的时间获得正确的信息。
|
||||
### 5. 配置、权限和策略编码
|
||||
|
||||
**静态上下文：**
|
||||
- 仓库本地文档（架构规范、API 契约、风格指南）
|
||||
- 编码项目特定规则的 `AGENTS.md` 或 `CLAUDE.md` 文件
|
||||
- 由 linter 验证的交叉链接设计文档
|
||||
Harness 必须不仅编码 Agent 可以做什么，还要编码它在什么条件下被允许做什么。
|
||||
|
||||
**动态上下文：**
|
||||
- 智能体可访问的可观测性数据（日志、指标、追踪）
|
||||
- 智能体启动时的目录结构映射
|
||||
- CI/CD 流水线状态和测试结果
|
||||
**分层配置**：
|
||||
- **用户级设置** - 编码个人偏好和信任边界
|
||||
- **项目级设置** - 指定哪些工具可用、哪些文件路径可访问以及哪些命令需要批准
|
||||
- **组织级设置** - 施加合规约束、成本上限和单个项目无法覆盖的数据处理规则
|
||||
|
||||
**关键规则：** 从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**仓库必须是单一事实来源。**
|
||||
### 6. 上下文预算管理
|
||||
|
||||
### 2. 架构约束
|
||||
上下文窗口仍然是任何 Agent 系统中最稀缺的共享资源。
|
||||
|
||||
这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好代码"，不如**机械地强制执行好代码的样子**。
|
||||
**有效管理策略**：
|
||||
- **摘要** - 将较旧的对话轮次和执行历史压缩为更短的表示
|
||||
- **基于优先级的驱逐** - 移除或降级与活动子任务相关性已衰减的上下文条目
|
||||
- **分阶段加载** - 确保详细的程序指导仅在检测到匹配的任务模式时才进入上下文
|
||||
|
||||
**依赖分层：**
|
||||
```
|
||||
Types → Config → Repo → Service → Runtime → UI
|
||||
```
|
||||
## 生产系统中的 Harness
|
||||
|
||||
每层只能从其左侧的层导入。这不是建议——它由结构测试和 CI 验证强制执行。
|
||||
成熟的 Agent 系统在以下方面收敛于惊人相似的 Harness 结构集：
|
||||
|
||||
**约束强制执行工具：**
|
||||
- **确定性 linters**——自动标记违规的自定义规则
|
||||
- **基于 LLM 的审计员**——审查其他智能体代码的架构合规性
|
||||
- **结构测试**——像 ArchUnit，但用于 AI 生成的代码
|
||||
- **预提交钩子**——在提交任何代码前的自动检查
|
||||
| 维度 | 共同模式 |
|
||||
|------|----------|
|
||||
| **循环和控制流** | 围绕显式循环组织执行，带有终止控制 |
|
||||
| **沙箱** | 在不同粒度实现执行隔离 |
|
||||
| **人工监督** | 实现可配置的审批门和 hook 系统 |
|
||||
| **可观测性** | 产生结构化执行轨迹和日志 |
|
||||
| **配置和治理** | 跨多个范围分层配置 |
|
||||
| **上下文预算** | 通过摘要、分阶段加载和驱逐主动管理 |
|
||||
|
||||
**为什么约束能改善输出：** 矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。
|
||||
## Harness 作为认知环境
|
||||
|
||||
### 3. 熵管理（"垃圾回收"）
|
||||
Harness 的重要性超出了普通软件工程意义上的基础设施。它通过确定推理展开的环境来塑造 Agent 的有效认知。
|
||||
|
||||
这是最被低估的组件。随着时间的推移，AI 生成的代码库会积累熵——文档与现实脱节、命名约定分歧、死代码堆积。
|
||||
> **关键主张**：Agent 可以知道、记住和做什么，不仅由模型权重固定，还由周围系统提供的访问、持久性和行动条件固定。
|
||||
|
||||
Harness 工程通过**定期清理智能体**来解决这个问题：
|
||||
- **文档一致性智能体**——验证文档与当前代码匹配
|
||||
- **约束违规扫描器**——找到逃过早期检查的代码
|
||||
- **模式强制执行智能体**——识别并修复与既定模式的偏差
|
||||
- **依赖审计员**——跟踪并解决循环或不必要的依赖
|
||||
### 理论视角
|
||||
|
||||
这些智能体按计划运行——每日、每周，或由特定事件触发——保持代码库对人类审查者和未来 AI 智能体都健康。
|
||||
1. **Norman 的认知人工制品** - Harness 在系统级别符合此描述。它不仅仅是用更多上下文或更多工具增强模型；它重组了模型面临的表征问题。
|
||||
|
||||
## 相关概念
|
||||
2. **Kirsh 的空间智能使用** - Harness 为 Agent 发挥类似作用。它是一个认知生态位，其中信息、工具、权限和程序被安排成使得期望行为更容易执行而不期望行为更难产生。
|
||||
|
||||
- [[Context-Engineering|上下文工程]]
|
||||
- [[Architectural-Constraints|架构约束]]
|
||||
- [[Entropy Management|熵管理]]
|
||||
- [[OpenAI Harness Engineering|OpenAI Harness 工程]]
|
||||
- [[Anthropic-Harness-Design|Anthropic Harness 设计]]
|
||||
- [[LangChain Harness Engineering|LangChain Harness 工程]]
|
||||
3. **分布式认知** - 操作智能分布在模型参数、外部记忆存储、可执行技能、协议定义、工具表面、监控系统和管理它们交互的运行时约束之间。
|
||||
|
||||
## 参考来源
|
||||
## 模块交互图
|
||||
|
||||
1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
|
||||
2. Anthropic - Harness design for long-running application development
|
||||
3. Martin Fowler - Harness engineering for coding agent users
|
||||
4. LangChain - Improving Deep Agents with harness engineering
|
||||
5. NxCode - Harness Engineering: The Complete Guide
|
||||
|
||||
|
||||
---
|
||||
记忆、技能和协议在 Harness 内部通过六个主要流动相互强化：
|
||||
|
||||
*最后更新：2026-04-07*
|
||||
*本文档由 [[WikiLLM]] 编译自多个来源*
|
||||
1. **记忆到技能** - 经验蒸馏
|
||||
2. **技能到记忆** - 执行记录
|
||||
3. **技能到协议** - 能力调用
|
||||
4. **协议到技能** - 能力生成
|
||||
5. **记忆到协议** - 策略选择
|
||||
6. **协议到记忆** - 结果同化
|
||||
|
||||
## 相关研究
|
||||
|
||||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||||
- [[Memory-Systems|记忆系统]]
|
||||
- [[Skill-Systems|技能系统]]
|
||||
- [[Agent-Protocols|智能体协议]]
|
||||
|
||||
Reference in New Issue
Block a user