Update from Sync Service
This commit is contained in:
FNS Service
@@ -1,129 +0,0 @@
|
||||
---
|
||||
title: Harness Engineering 知识体系
|
||||
tags:
|
||||
- AI-Agent
|
||||
- Engineering
|
||||
- Prompt-Engineering
|
||||
- Context-Engineering
|
||||
created: 2026-04-21
|
||||
source: 基于11篇原始资料整理（OpenAI/Anthropic/Thoughtworks/LangChain/HumanLayer/Inngest/学术界）
|
||||
---
|
||||
|
||||
# Harness Engineering
|
||||
|
||||
> AI Agent = Model + Harness
|
||||
>
|
||||
> *"The model contains the intelligence and the harness is the system that makes that intelligence useful."* — LangChain
|
||||
|
||||
## 核心定义
|
||||
|
||||
**Harness** = 除模型以外的一切——工具、指令、状态管理、验证机制、运行时基础设施
|
||||
|
||||
让模型输出从"不可靠"变成"可信赖"的工程体系。
|
||||
|
||||
---
|
||||
|
||||
## 各机构视角
|
||||
|
||||
| 机构 | 侧重点 |
|
||||
|------|--------|
|
||||
| **LangChain** | 最宽泛：Harness = 一切非模型的技术层 |
|
||||
| **Anthropic** | 环境脚手架 + 长任务连续性 + clean state 理念 |
|
||||
| **OpenAI** | 代码仓库即知识系统，强调"零人工代码"自动化 |
|
||||
| **Thoughtworks** | 赛博内廷（cybernetic governor），区分"构建者挽具"vs"用户挽具" |
|
||||
| **HumanLayer** | Harness = Context Engineering 的子集，专注上下文窗口管理 |
|
||||
| **Inngest** | 持久化事件驱动基础设施 |
|
||||
| **学术界（CAR框架）** | Control + Agency + Runtime 三元框架 |
|
||||
|
||||
---
|
||||
|
||||
## 五大大子系统（walkinglabs 综合框架）
|
||||
|
||||
### 1. Instructions（指令）
|
||||
告诉 Agent 做什么、按什么顺序、读什么文件。采用**渐进式披露**（Progressive Disclosure），而非巨型文件。
|
||||
|
||||
### 2. State（状态）
|
||||
追踪已完成什么、正在做什么、接下来是什么。**持久化到磁盘**，确保会话间连续性。
|
||||
|
||||
### 3. Verification（验证）
|
||||
只有通过测试才算完成。Agent 不能在无可运行证据的情况下宣告任务完成。
|
||||
|
||||
### 4. Scope（范围）
|
||||
将 Agent 约束到**每次一个功能**，防止过度扩展和半途而废。
|
||||
|
||||
### 5. Session Lifecycle（会话生命周期）
|
||||
- 开始时初始化
|
||||
- 结束时清理
|
||||
- 为下一次会话留下清晰的重启路径
|
||||
|
||||
---
|
||||
|
||||
## 两类控制（Thoughtworks）
|
||||
|
||||
| 类型 | 计算型 | 推理型 |
|
||||
|------|--------|--------|
|
||||
| 执行 | CPU确定性快速 | GPU/NPU语义分析 |
|
||||
| 例子 | 测试/linter/类型检查 | LLM as Judge/AI代码审查 |
|
||||
| 特点 | 结果可靠 | 成本高但能处理语义判断 |
|
||||
|
||||
### 前馈导引 + 反馈传感
|
||||
- **前馈导引**（Feedforward Guides）：在工作前注入上下文（AGENTS.md、技能文件、引导脚本）
|
||||
- **反馈传感**（Feedback Sensors）：工作后检测问题（静态分析、日志、测试）
|
||||
|
||||
---
|
||||
|
||||
## 三类调控维度（Thoughtworks）
|
||||
|
||||
| 维度 | 调控内容 | 例子 |
|
||||
|------|----------|------|
|
||||
| **可维护性挽具** | 代码内部质量 | 重复代码、圈复杂度、测试覆盖率 |
|
||||
| **架构适应性挽具** | 架构特征 | 性能要求、可观测性标准、依赖方向规则 |
|
||||
| **行为挽具** | 功能正确性 | 规格说明、测试套件、端到端验证 |
|
||||
|
||||
---
|
||||
|
||||
## CAR 框架（学术界）
|
||||
|
||||
三个维度：
|
||||
- **Control（控制）** — 哪些指令保持权威
|
||||
- **Agency（智能体能力）** — 哪些行动可用
|
||||
- **Runtime（运行时）** — 状态如何延续、故障如何处理
|
||||
|
||||
提出 **Harness-sensitive** 概念：部分 Agent 性能提升可能来自 Harness 改进，而非模型本身。
|
||||
|
||||
---
|
||||
|
||||
## 实测效果（Anthropic）
|
||||
|
||||
同一模型 + 同一提示词（构建2D复古游戏编辑器）：
|
||||
|
||||
| | 有Harness | 无Harness |
|
||||
|--|-----------|-----------|
|
||||
| 成本 | $9 | 更高 |
|
||||
| 时间 | 20分钟 | 更长 |
|
||||
| 结果 | 可运行 | 无法运行 |
|
||||
|
||||
**结论**：Harness 改进可能比模型本身带来的性能提升更显著。
|
||||
|
||||
---
|
||||
|
||||
## 核心启示
|
||||
|
||||
1. **Harness 是杠杆** — 同一模型，有无 Harness 结果差异巨大
|
||||
2. **验证即完成** — Agent 不能在无可运行证据的情况下宣告完成
|
||||
3. **状态持久化** — 会话间的连续性是长任务的关键
|
||||
4. **Scope 约束** — 防止 Agent 过度扩展和半途而废
|
||||
5. **渐进式披露** — 指令文件不要堆成巨型文件
|
||||
|
||||
---
|
||||
|
||||
## 与 OpenClaw 的关系
|
||||
|
||||
OpenClaw 本身就是一种 **Harness** 的实现：
|
||||
- `AGENTS.md` / `SOUL.md` / `USER.md` = Instructions 子系统
|
||||
- `MEMORY.md` / `memory/` = State 子系统
|
||||
- `HEARTBEAT.md` = Verification + Session Lifecycle
|
||||
- Skills 系统 = 工具扩展（Tool Harness）
|
||||
|
||||
Harness Engineering 理论可以指导 OpenClaw 的优化方向。
|
||||
|
||||
Reference in New Issue
Block a user