深挖Harness Engineering——全方位深度解析
Harness Engineering 全方位深度解析：从入门到精通
摘要：2026 年上半年，AI 工程领域最具统治力的热词非 Harness Engineering（驾驭工程） 莫属。从 Mitchell Hashimoto 的博客命名，到 OpenAI 百万行代码零手写实验，再到 Martin Fowler、Anthropic、LangChain 的集体跟进——它标志着 AI 工程重心从"优化模型"到"设计模型运行环境"的根本性转移。本文将由浅入深、全方位深挖这一新范式。
目录
- 一、什么是 Harness Engineering？
- 二、概念演进史：从 Prompt 到 Harness
- 三、为什么是现在？——问题背景
- 四、核心哲学与第一性原理
- 五、架构深挖：Harness 的核心组件
- 六、经典案例拆解
- 七、实战指南：搭建你自己的 Harness
- 八、工具生态全景
- 九、进阶话题：自进化 Harness 与前沿研究
- 十、概念辨析：别搞混了这几个 “Harness”
- 十一、争议与冷思考
- 十二、未来趋势
- 十三、学习路线图与资源
- 结语
一、什么是 Harness Engineering？
1.1 一句话定义
Harness Engineering（驾驭工程） 是围绕 AI 智能体（Agent）设计和构建约束机制、反馈回路、工作流控制与持续改进循环的系统工程实践。它不优化模型本身，而是优化模型运行的环境。
1.2 “Harness” 这个词从哪来？
Harness（/ˈhɑːrnɪs/）的英文原意是 “马具”——包括缰绳、鞍具、辔头在内的一整套装备。它的隐喻极其精准：
| 马具世界 | AI 世界 |
|---|---|
| 🐴 马匹（力量与速度） | 大语言模型（推理能力） |
| 🧑 骑手（方向与意图） | 人类工程师（目标与决策） |
| 🔗 缰绳 + 鞍具（控制框架） | Harness（运行控制系统） |
这个类比揭示了一个关键洞察：不是限制马的力量，而是引导力量朝正确方向输出。 当模型能力足够强时，瓶颈就不再是"马不够快"，而是"缰绳不够好"。
1.3 核心公式
LangChain 的 Vivek Trivedy 给出了一个被广泛引用的定义：
Agent = Model + Harness
以及一句更决绝的话：
“If you’re not the model, you’re the Harness.”
（如果你不是模型本身，那你就是 Harness。）
也就是说，模型权重之外的一切——系统提示词、工具调度、上下文管理、权限控制、错误恢复、反馈循环、沙箱隔离、可观测性……统统属于 Harness 的范畴。
1.4 谁提出的？关键时间线
| 时间 | 事件 | 关键人物/组织 |
|---|---|---|
| 2025.08 – 2026.01 | OpenAI 内部进行五个月"零手写代码"实验 | OpenAI Frontier 团队 |
| 2025.11 | Anthropic 发布《Effective Harnesses for Long-Running Agents》 | Anthropic |
| 2026.02.05 | Mitchell Hashimoto 发表博客《My AI Adoption Journey》，正式命名 “Harness Engineering” | Mitchell Hashimoto（HashiCorp 联合创始人、Terraform 之父） |
| 2026.02.11 | OpenAI 发布官方文章《Harness Engineering: Leveraging Codex in an Agent-First World》，概念引爆 | Ryan Lopopolo |
| 2026.02.17 | Martin Fowler 网站发布深度分析，Birgitta Böckeler 撰写长文 | Martin Fowler / Thoughtworks |
| 2026.03 | LangChain 发布《The Anatomy of an Agent Harness》 | LangChain / Akshay Pachaar |
| 2026.03 底 | Claude Code npm 包意外泄漏 sourcemap，51.2 万行源码被社区分析 | Anthropic |
| 2026.07.04 | 翁荔（Lilian Weng）发万字长文：AI 自进化从 Harness 开始 | Thinking Machines Lab |
| 2026.07.30 | Mitchell Hashimoto 官宣新公司 Superlogical，为 Agent 造"持久化终端" | Mitchell Hashimoto |
| 2026.08.01 | DeepSeek Harness 团队开启内测招募 | DeepSeek |
Hashimoto 的原始定义朴素而有力：
“每当 AI 犯错，就工程化一个方案，让它永远不再犯同样的错。”
二、概念演进史：从 Prompt 到 Harness
Harness Engineering 不是凭空出现的，它是 AI 工程重心三次转移的最新一站：
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Prompt │ │ Context │ │ Harness │
│ Engineering │ ──► │ Engineering │ ──► │ Engineering │
│ (2022-2023) │ │ (2025) │ │ (2026) │
├──────────────────┤ ├──────────────────┤ ├──────────────────┤
│ 核心关注： │ │ 核心关注： │ │ 核心关注： │
│ 单轮对话质量 │ │ 上下文管理 │ │ 系统级运行环境 │
│ │ │ │ │ │
│ 解决的问题： │ │ 解决的问题： │ │ 解决的问题： │
│ 如何让模型 │ │ 如何让模型 │ │ 如何让模型 │
│ "说对话" │ │ "记住事" │ │ "干成事" │
└──────────────────┘ └──────────────────┘ └──────────────────┘
用做饭来打比方：
| 阶段 | 类比 | 关注点 |
|---|---|---|
| Prompt Engineering | 对厨师喊话：“少放盐！” | 指令措辞 |
| Context Engineering | 把菜谱、食材清单摆到厨师面前 | 信息供给 |
| Harness Engineering | 设计整个厨房的动线、安全规范、质检流程 | 运行环境 |
SaaS 领域投资人 Aakash Gupta 的判断被广泛引用：
“2025 年是 Agent 之年，2026 年是 Harness 之年。模型是商品，Harness 才是护城河。”
三、为什么是现在？——问题背景
3.1 模型智力已经"过线"
2025 年底，GPT-5.x、Claude Opus 4.x、Gemini 3.x 相继发布。一线工程师们发现了一个反直觉的事实：
换个更强的模型，对实际产出的提升，远不如把模型外面那一圈东西搞好来得猛。
模型在静态 Benchmark 上的差距正在缩小，但真正的差距在任务越复杂、越长期时才会显现——核心指标是 耐久性（Durability）：模型在执行了几十上百次工具调用之后，还能不能持续遵循最初的指令？
3.2 Agent 落地的四大"翻车姿势"
Anthropic 在长时运行 Agent 的实践中，总结了三种典型失败模式：
| 失败模式 | 表现 | Harness 对策 |
|---|---|---|
| One-shotting（一步到位） | Agent 试图在一个会话里把所有功能做完，结果顾此失彼 | 任务拆解 + 检查点机制 |
| Context Loss（上下文丢失） | 长任务中模型"忘了"前面做过什么 | 状态持久化 + 上下文压缩/摘要 |
| Tool Hallucination（工具幻觉） | 调用不存在的工具、传错参数 | 强类型工具注册表 + 参数校验 |
| Reasoning Drift（推理漂移） | 多步推理中逐渐偏离目标 | 反馈回路 + 目标锚定 |
3.3 Demo 与生产之间的鸿沟
每个 Agent 在 Demo 阶段都惊艳无比，但一旦投入真实代码库、执行跨越数小时甚至数天的长周期任务，现实无比骨感。Harness Engineering 正是填补"强大的 AI 模型"与"可靠的生产力系统"之间鸿沟的工程学科。
四、核心哲学与第一性原理
4.1 “人类掌舵，智能体执行”
Harness Engineering 的核心哲学可以概括为八个字：
Human Steer, Agent Execute.
人类掌舵，智能体执行。
工程师的角色发生了根本性转变：
传统：人类编写代码 → 机器执行代码
现在：人类设计环境 → Agent 在环境中编写并执行代码
4.2 零手写代码的极端约束
OpenAI Codex 团队给自己立下了一条铁律：不手写一行代码。 这看似自我设限，实则逼出了全新的工作方式——因为当你不能亲自动手，你就必须学会如何让别人替你可靠地动手。
4.3 错误即工程机会
Hashimoto 的核心循环：
Agent 犯错 → 分析根因 → 工程化一个防护方案 → Agent 永不再犯同类错误
↑ │
└──────────── 持续改进闭环 ◄────────────────────┘
这不是在"调教"模型，而是在迭代 Harness 本身。Harness 是代码，代码可以版本控制、可以测试、可以持续演进。
4.4 你不会把 CPU 直接交给用户
一个精辟的类比：
你不会把 CPU 直接交给用户，你交付的是操作系统。
同理，你不会把裸模型直接交给用户，你交付的是 Agent = Model + Harness。
五、架构深挖：Harness 的核心组件
5.1 综述级分类：ETCLOVG 七层模型
基于 170+ 开源项目的综述论文《Agent Harness Engineering: A Survey》提出了 ETCLOVG 七层分类框架，将 Agent Harness 定义为"将模型调用转化为有边界、有状态、工具中介的任务执行的工程化包装层"：
┌─────────────────────────────────────────────────────┐
│ G - Governance（治理约束） │
│ 权限控制 · 审计追踪 · 安全策略 │
├─────────────────────────────────────────────────────┤
│ V - Verification（评估反馈） │
│ 质量评估 · 自动化测试 · 闭环校验 │
├─────────────────────────────────────────────────────┤
│ O - Observability（可观测性） │
│ 日志 · 追踪 · 指标 · 异常检测 │
├─────────────────────────────────────────────────────┤
│ L - Lifecycle / Orchestration（编排） │
│ 任务拆解 · 工作流控制 · 子Agent调度 · 重试 │
├─────────────────────────────────────────────────────┤
│ C - Context（上下文控制） │
│ 上下文窗口管理 · 记忆读写 · 摘要压缩 · RAG │
├─────────────────────────────────────────────────────┤
│ T - Tool（工具接口） │
│ 工具注册表 · 参数校验 · 沙箱执行 · MCP 协议 │
├─────────────────────────────────────────────────────┤
│ E - Execution（执行基板） │
│ 运行时环境 · 进程管理 · 状态持久化 · 恢复 │
└─────────────────────────────────────────────────────┘
▲
│ 模型调用
┌────┴────┐
│ LLM │
└─────────┘
5.2 Martin Fowler 的 Feedforward / Feedback 框架
软件工程泰斗 Martin Fowler 与 Thoughtworks 杰出工程师 Birgitta Böckeler 在 2026 年 4 月提出了一个更精炼的二分法：
| 维度 | 名称 | 作用时机 | 典型手段 |
|---|---|---|---|
| Guides（前馈控制） | 事前引导 | Agent 行动之前 | System Prompt、架构规范文档、Linter 规则、代码模板、Few-shot 示例 |
| Sensors（反馈控制） | 事后检测 | Agent 行动之后 | CI/CD 检查、单元测试、代码审查 Agent、运行时监控、错误日志分析 |
Guides（前馈） Sensors（反馈）
┌──────────────┐ ┌──────────────┐
│ System Prompt│ │ CI Pipeline │
│ 架构规范 │ ──► Agent ──► │ 单元测试 │
│ Linter 规则 │ 执行 │ 代码审查 │
│ 代码模板 │ │ 运行时监控 │
└──────────────┘ └──────┬───────┘
│
▼
反馈回注 Agent
（修复 → 重试）
他们进一步将 Harness 的职责归纳为三大组件：
- 上下文工程（Context Engineering）：管理模型"看到什么"
- 架构约束（Architectural Constraints）：通过 Linter、类型系统等硬性约束防止越界
- 反馈回路（Feedback Loops）：自动化验证，让 Agent 能自我纠错
5.3 四大核心职责
从工程落地角度，Harness 承担四大核心职责：
┌────────────────────────────────────────────────────────┐
│ Harness 四大核心职责 │
├──────────────┬──────────────┬──────────────┬───────────┤
│ 📋 任务拆解 │ 🧠 上下文管理 │ 🔧 工具编排 │ 💾 状态持久化│
│ │ │ │ │
│ 大任务→子任务 │ 动态注入/压缩 │ 注册/调度/校验 │ 检查点/恢复 │
│ 依赖关系管理 │ 记忆读写 │ 沙箱隔离 │ 会话持久化 │
│ 并行/串行编排 │ RAG 检索 │ 权限控制 │ 断点续跑 │
└──────────────┴──────────────┴──────────────┴───────────┘
5.4 深入一层：Harness 的完整组件清单
综合 Anthropic、OpenAI、LangChain 的实践，一个生产级 Harness 通常包含以下组件：
| # | 组件 | 职责 | 对应马具隐喻 |
|---|---|---|---|
| 1 | System Prompt | 定义角色、边界、行为规范 | 缰绳 |
| 2 | 工具注册表（Tool Registry） | 强类型工具声明、参数校验、handler 映射 | 马蹄铁 |
| 3 | 编排循环（Orchestration Loop） | 感知→推理→执行→反馈的主循环 | 骑手操控 |
| 4 | 上下文管理器 | 窗口管理、摘要压缩、优先级排序 | 马鞍 |
| 5 | 记忆系统（Memory） | 短期/长期记忆、向量检索、经验积累 | 马的记忆训练 |
| 6 | 权限控制（Authority） | 文件系统/网络/API 访问的白名单与审批 | 围栏 |
| 7 | 沙箱（Sandbox） | 隔离执行环境，防止破坏性操作 | 马场 |
| 8 | 验证管道（Verification） | Lint → 类型检查 → 单元测试 → 集成测试 | 质检站 |
| 9 | 重试与恢复（Retry & Recovery） | 失败检测、自动重试、断点续跑 | 急救包 |
| 10 | 可观测性（Observability） | 日志、Trace、指标、Token 消耗追踪 | 行车记录仪 |
| 11 | 评估体系（Evaluation） | 基准测试、A/B 对比、回归检测 | 赛马场 |
| 12 | 熵管理（Entropy Management） | 清理无效上下文、防止系统混乱积累 | 马厩清洁 |
5.5 Claude Code 的 Harness 架构实例
Anthropic 的 Claude Code（51.2 万行 TypeScript）是目前最成功的 Harness Engineering 商业实践，半年内达到 10 亿美元年化收入。其架构可拆解为 5 个核心组件：
┌──────────────────────────────────────────────────────────┐
│ Claude Code Harness │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 1. 单线程 Master Loop │ │
│ │ 感知 → 推理 → 工具执行 → 结果回注上下文 → 循环 │ │
│ └──────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 2. 强类型工具派发注册表（Typed Tool Registry） │ │
│ │ bash / read / write / grep / glob / ... │ │
│ │ 工具名 → Handler 映射 + 参数 Schema 校验 │ │
│ └──────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 3. 上下文管理管线 │ │
│ │ CLAUDE.md 注入 / 自动摘要 / 滑动窗口 / RAG │ │
│ └──────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 4. 权限模型 + Hooks 机制 │ │
│ │ 文件读写审批 / 命令白名单 / 生命周期钩子 │ │
│ └──────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 5. 沙箱安全层 │ │
│ │ 进程隔离 / 网络策略 / 文件系统边界 │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
六、经典案例拆解
6.1 案例一：OpenAI Codex —— 百万行代码，零手写
这是 Harness Engineering 最具标志性的实证实验。
| 指标 | 数据 |
|---|---|
| 团队规模 | 最初 3 人（后扩至 7 人） |
| 开发周期 | 5 个月（2025.08 – 2026.01） |
| 代码总量 | ~1,000,000 行 |
| PR 数量 | 1,500+ |
| 手写代码 | 0 行 |
| 效率提升 | 约 10 倍（对比传统开发） |
| PR 节奏 | 平均每天 3.5 个 PR |
关键实践：
- 极端约束：强制"零手写代码"，倒逼团队从"写代码"转向"构建工具与系统思维"
- 一分钟反馈循环：构建极速反馈闭环，让 Agent 在一分钟内获得执行结果
- 声明式提示词：工程师仅提供意图描述，由 Codex 自主规划执行路径
- CI 驱动迭代：Agent 自主复现缺陷 → 给出修复 → 验证结果 → 提交 PR
- 工具也由 Agent 构建：连 CI 配置、可观测性配置、开发工具本身都由 Agent 生成
Ryan Lopopolo：“人类是唯一稀缺资源。 我们构建 Harness 的目的是为大规模 AI 任务提供统一、可靠的运行方式，让团队专注于研究与产品开发，而非基础设施编排。”
重要细节：项目一开始差点烂尾——AI 天天走错方向、同一个错来回犯。救活它的不是换更聪明的模型，而是持续迭代 Harness。
6.2 案例二：LangChain 的 Terminal Bench 实验
LangChain 在《The Anatomy of an Agent Harness》中引用了一组惊人的对比数据：
同一个 LLM（权重一个字节没改）
│
├── Harness A（基础版） → Terminal Bench 2.0 通过率：52.8% （排名 30+）
│
└── Harness B（精巧版） → Terminal Bench 2.0 通过率：66.5% （排名 Top 5）
提升幅度：+13.7 个百分点，仅靠换"壳"
结论：Harness 的设计质量可以带来比换模型更大的性能提升。
6.3 案例三：Anthropic 的长时运行 Agent 实践
Anthropic 在 2025 年 5 月尝试让 Claude 从零构建完整 Web 应用，经历了三次架构迭代：
| 迭代 | 方案 | 问题 |
|---|---|---|
| V1 | 单会话 One-shot | 上下文爆炸，后期质量崩塌 |
| V2 | 多会话 + 手动检查点 | 人工介入过多，不可扩展 |
| V3 | 自动检查点 + 子 Agent 分治 + 客观评估管道 | ✅ 稳定运行 |
关键发现：人工评估效率低，Agent 自评有主观滤镜，必须建立客观自动化评估体系。
6.4 案例四：个人开发者的 Harness 实践
一个真实案例：某开发者一个人、2 周、3 万块钱，用 Claude Code 做了一个产品上线 App Store。他做的核心事情就是学会了 Harness Engineering——不是写代码，而是：
- 精心维护
CLAUDE.md项目规范文件（Guides） - 搭建自动化测试管道（Sensors）
- 设计任务拆解模板（Orchestration）
- 配置权限白名单（Governance）
七、实战指南：搭建你自己的 Harness
7.1 最小可行 Harness（MVH）
如果你刚开始，可以从一个最小可行 Harness 起步：
# 项目根目录结构
my-project/
├── AGENTS.md # ← Harness 核心：Agent 行为规范
├── .harness/
│ ├── rules/ # ← Lint 规则、架构约束
│ ├── templates/ # ← 代码模板、Few-shot 示例
│ └── checkpoints/ # ← 状态持久化
├── .github/workflows/
│ └── agent-ci.yml # ← 自动化验证管道
├── src/
└── tests/
7.2 AGENTS.md：你的第一根"缰绳"
这是 Harness 中最核心的文件，相当于给 Agent 的"宪法"：
# AGENTS.md
## 项目概述
这是一个基于 FastAPI 的订单管理系统，Python 3.12，PostgreSQL 16。
## 架构规范（不可违反）
- 所有 API 必须经过 `src/api/` 路由层，禁止业务逻辑直接暴露
- 数据库操作只能通过 `src/repositories/` 层
- 禁止使用 `print()`，统一使用 `src/utils/logger.py`
- 所有新函数必须有 type hints 和 docstring
## 编码约定
- 遵循 PEP 8，行宽 100
- 异步函数使用 `async/await`，禁止 `threading`
- 错误处理统一使用 `src/exceptions.py` 中定义的异常类
## 测试要求
- 每个新功能必须附带单元测试
- 测试覆盖率不低于 80%
- 运行 `pytest tests/ -v` 确认全部通过后再提交
## 禁止操作
- ❌ 不得修改 `src/core/config.py` 中的数据库连接配置
- ❌ 不得安装未经审批的新依赖
- ❌ 不得删除任何现有测试用例
7.3 反馈回路：CI 管道配置
# .github/workflows/agent-ci.yml
name: Agent CI Pipeline
on: [pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# Sensor 1: 静态检查（前馈约束的运行时验证）
- name: Lint & Type Check
run: |
ruff check src/ --fix
mypy src/ --strict
# Sensor 2: 单元测试
- name: Unit Tests
run: pytest tests/ -v --cov=src --cov-fail-under=80
# Sensor 3: 安全扫描
- name: Security Scan
run: bandit -r src/ -ll
# Sensor 4: 架构合规检查
- name: Architecture Compliance
run: python scripts/check_architecture.py
# 反馈回注：将失败信息结构化，供 Agent 读取
- name: Export Failure Report
if: failure()
run: python scripts/generate_failure_report.py > .harness/feedback.md
7.4 工具注册：强类型工具接口
# harness/tool_registry.py
from dataclasses import dataclass
from typing import Callable, Any
from pydantic import BaseModel, ValidationError
@dataclass
class ToolSpec:
"""强类型工具规格定义"""
name: str
description: str
handler: Callable
params_schema: type[BaseModel] # Pydantic Schema 校验
requires_approval: bool = False # 是否需要人工审批
sandbox: bool = True # 是否在沙箱中执行
class ToolRegistry:
def __init__(self):
self._tools: dict[str, ToolSpec] = {}
def register(self, spec: ToolSpec):
self._tools[spec.name] = spec
def invoke(self, tool_name: str, raw_params: dict) -> Any:
spec = self._tools.get(tool_name)
if spec is None:
raise ToolNotFoundError(f"工具 '{tool_name}' 不存在")
# 参数校验 —— 杜绝工具幻觉
try:
validated = spec.params_schema(**raw_params)
except ValidationError as e:
raise ToolParamError(f"参数校验失败: {e}")
# 权限检查
if spec.requires_approval:
if not self._request_human_approval(spec, validated):
raise PermissionDeniedError(f"工具 '{tool_name}' 被拒绝")
# 沙箱执行
if spec.sandbox:
return self._run_in_sandbox(spec.handler, validated)
return spec.handler(validated)
# 注册示例
registry = ToolRegistry()
registry.register(ToolSpec(
name="file_write",
description="写入文件到项目目录",
handler=write_file,
params_schema=FileWriteParams, # path: str, content: str
requires_approval=True, # 写文件需要审批
))
7.5 上下文管理策略
# harness/context_manager.py
class ContextManager:
"""管理 Agent 的上下文窗口，防止信息过载"""
def __init__(self, max_tokens: int = 128_000):
self.max_tokens = max_tokens
self.layers = []
def build_context(self, task: str) -> str:
"""分层构建上下文，按优先级注入"""
context_parts = [
self._load_system_prompt(), # Layer 1: 角色与规则（始终存在）
self._load_project_spec(), # Layer 2: AGENTS.md 项目规范
self._load_relevant_docs(task), # Layer 3: RAG 检索相关文档
self._load_recent_history(), # Layer 4: 近期对话（可压缩）
self._load_task_state(), # Layer 5: 当前任务状态/检查点
]
return self._fit_to_window(context_parts)
def _fit_to_window(self, parts: list[str]) -> str:
"""当上下文超限时，从低优先级层开始压缩/摘要"""
total = sum(count_tokens(p) for p in parts)
while total > self.max_tokens and len(parts) > 2:
# 对 Layer 4 做摘要压缩
parts[3] = self._summarize(parts[3])
total = sum(count_tokens(p) for p in parts)
return "\n\n---\n\n".join(parts)
7.6 持续改进循环
# harness/improvement_loop.py
class ImprovementLoop:
"""Hashimoto 核心循环的工程化实现"""
def on_agent_error(self, error: AgentError):
"""每当 Agent 犯错，触发工程化修复"""
# 1. 分类错误
category = self.classify(error)
# e.g., "architecture_violation", "missing_test", "wrong_dependency"
# 2. 检查是否已有防护
if self.has_guard(category):
self.strengthen_guard(category, error)
else:
# 3. 工程化新防护
guard = self.engineer_guard(category, error)
# 可能是：新的 lint 规则 / AGENTS.md 新条目 /
# 新的 CI 检查 / 新的工具参数约束
# 4. 注册到 Harness
self.harness.add_guard(guard)
# 5. 记录到知识库（供未来参考）
self.knowledge_base.append({
"error": error,
"guard": guard,
"timestamp": now(),
})
# 6. 将修复方案反馈给 Agent 重试
self.retry_with_feedback(error, guard)
7.7 Harness 成熟度模型
| 等级 | 名称 | 特征 | 典型表现 |
|---|---|---|---|
| L0 | 裸奔 | 直接调 API，无任何工程化 | “帮我写个函数” |
| L1 | 提示词级 | 有 System Prompt，但无结构化约束 | 复制粘贴提示词模板 |
| L2 | 规范级 | 有 AGENTS.md / CLAUDE.md + 基本 Lint | Agent 能遵循项目规范 |
| L3 | 管道级 | 完整 CI 反馈回路 + 自动化测试 | Agent 可自主迭代修复 |
| L4 | 编排级 | 多 Agent 协作 + 任务拆解 + 检查点 | Agent 可执行跨天任务 |
| L5 | 自进化级 | Harness 自身可由 Agent 优化 | Meta-Harness / ADAS |
八、工具生态全景
8.1 商业产品
| 产品 | 厂商 | Harness 特色 |
|---|---|---|
| Claude Code | Anthropic | 51.2 万行 TS，单线程 Master Loop + Hooks + 沙箱，$10 亿年化收入 |
| Codex | OpenAI | 声明式提示词驱动，CI 深度集成，百万行代码验证 |
| Cursor | Anysphere | IDE 级 Harness，代码库索引 + 上下文感知 |
| Windsurf | Codeium | 多文件编辑编排 + 实时反馈 |
8.2 开源框架
| 项目 | 定位 | 亮点 |
|---|---|---|
| LangChain DeepAgent | “Batteries-included agent harness” | 三行代码创建能规划、写文件、派子任务的 Agent；Harness Profiles 可版本化 |
| OpenClaw | 开源智能体框架 | 2025.11 推出，基于 Token 计费，带动"词元"概念大众化 |
| AgentScope | 多 Agent 编排 | 阿里开源，支持复杂工作流 |
| Hermes | Agent 运行时 | 轻量级 Harness 实现 |
8.3 关键协议与标准
- MCP（Model Context Protocol）：Anthropic 提出的工具接口标准协议，正在成为 Harness 工具层的事实标准
- Harness Profiles：LangChain DeepAgent 引入的概念，将 Harness 配置变成可版本化的"一等公民"
8.4 行业格局速览（2026.08）
模型层（商品化） Harness 层（护城河） 应用层
┌──────────┐ ┌──────────────────┐ ┌──────────┐
│ GPT-5.x │ │ Claude Code │ │ 企业开发 │
│ Opus 4.x │ ───► │ Codex Harness │ ───► │ 自动运维 │
│ Gemini 3 │ │ DeepAgent │ │ 数据分析 │
│ DeepSeek │ │ 自研 Harness │ │ 客服/销售 │
│ ... │ │ │ │ ... │
└──────────┘ └──────────────────┘ └──────────┘
可替换 核心竞争力 业务价值
九、进阶话题：自进化 Harness 与前沿研究
9.1 翁荔的万字长文：AI 自进化从 Harness 开始
2026 年 7 月 4 日，前 OpenAI 安全研究副总裁、Thinking Machines Lab 联合创始人**翁荔（Lilian Weng）**发表长文，提出了一个深刻观点：
AI 的自我提升未必会先从"模型直接改写自己的权重"开始，更可能先从"Agent 优化自己的 Harness 代码"开始。
理由很直接：Harness 就是代码，而代码是可搜索、可优化、可验证的。相比直接修改权重（高风险、不可解释），让 LLM 优化执行 Agent 的代码（提示词、工具调用、子 Agent、控制流、记忆、工作流逻辑）是更安全的自进化路径。
9.2 Meta-Harness 与自动 Harness 搜索
相关前沿研究方向：
| 方向 | 核心思想 | 代表工作 |
|---|---|---|
| Meta-Harness | 用 LLM 搜索和优化 Harness 设计空间 | Meta-Harness |
| ADAS | Automated Design of Agentic Systems，自动设计 Agent 系统 | ADAS |
| AFlow | 用代码表示工作流，LLM 自动优化 | AFlow |
核心洞察：代码是定义程序和系统的通用语言。Harness 就是代码。 如果 LLM 能优化执行 Agent 的代码，那它就在优化自己。
9.3 耐久性问题：模型的真实差距
一个被低估的研究方向：
顶级模型在静态榜单上的差距正在缩小——但这可能是一种幻觉。模型之间真正的差距，在任务越复杂、越长期时才会显现。核心指标是耐久性（Durability）：模型在执行了几十甚至上百次工具调用之后，还能不能持续遵循最初的指令？
这意味着 Harness 设计需要针对不同模型的耐久性特征做适配——同一个 Harness 在不同模型上的表现可能天差地别。
9.4 Harness 与记忆：锁定效应
一个值得警惕的问题：记忆是 Agent 体验的核心，能创造极强的锁定效应。
如果你使用闭源的 Harness（尤其是通过专有 API 提供的），你实际上是将 Agent 的记忆控制权交给了第三方。这引发了关于 Harness 开放性 的重要讨论：
- 你的 Agent 记忆是否可以导出？
- 切换 Harness 时，历史经验是否可以迁移？
- Harness 的配置是否应该标准化？
9.5 Mitchell Hashimoto 的新征程：Superlogical
2026 年 7 月 30 日，Harness 概念的提出者 Hashimoto 官宣新公司 Superlogical，做的是"all work 的 multiplexer"——一个永远不会断的终端会话：
你在电脑上干活，关掉笔记本回家，掏出手机，会话还在那。你在上面跑开发环境、跑 CI 任务、跑 AI Agent，全在一个 session 里。全程跟着你走，跨设备，跨网络。
这本质上是 Harness 执行基板的进一步基础设施化——Agent 需要一个永不中断的运行环境。
十、概念辨析：别搞混了这几个 “Harness”
“Harness Engineering” 这个词在不同语境下含义截然不同，极易混淆：
| 概念 | 领域 | 含义 | 关键区别 |
|---|---|---|---|
| Harness Engineering（驾驭工程） | AI / 软件工程 | 为 AI Agent 构建运行控制系统的工程范式 | 本文主角 ✅ |
| Wire Harness Engineering（线束工程） | 汽车 / 航空 / 制造业 | 电气线束（线缆总成）的设计、制造与验证 | 传统工业学科，是设备的"电气神经网络" |
| Harness.io | DevOps / SaaS | 一家 CI/CD 平台公司 | 商业产品，与 AI Harness 概念无关 |
| Test Harness（测试线束） | 软件测试 | 自动化测试的框架和桩代码 | 软件工程传统术语 |
⚠️ 特别注意：在中文语境中，"线束工程"一词同时被用于翻译 AI 领域的 Harness Engineering 和传统制造业的 Wire Harness Engineering，阅读时需要根据上下文判断。
十一、争议与冷思考
11.1 乐观派
- “模型是商品，Harness 才是护城河”
- Harness 让 AI 从"能说会道"变为"能征善战"
- 10 倍效率提升已被实证验证
11.2 质疑派
- 过度工程化风险：随着模型能力增强，复杂的 Harness 可能变成不必要的负担。模型越强，Harness 应该越薄而非越厚
- 焦虑驱动：有评论认为 Harness 热潮背后是"人类对 AI 深度失控的焦虑"，是"为掩盖技术无能而修筑的最后一道防线"
- 可移植性差：深度绑定特定 Harness 的项目，迁移成本极高
- 企业落地门槛：金融机构等强监管行业，"零手写代码"模式面临合规挑战
11.3 理性视角
一个平衡的判断：
Harness 不会消失，但会演化。 随着模型能力提升，Harness 的重心会从"补偿模型缺陷"转向"治理与验证"。管理和验证的核心作用不可或缺，但具体形态会持续简化。
十二、未来趋势
基于当前行业动态，Harness Engineering 的未来走向可以从以下几个维度预判：
12.1 短期（2026 下半年）
- 🔥 标准化：Harness 配置格式（如 Harness Profiles）走向标准化
- 🔥 开源竞争白热化：DeepSeek、LangChain 等加速开源 Harness 实现
- 🔥 Harness 工程师成为新兴岗位（百度百科已收录"Harness 工程师"词条）
12.2 中期（2027-2028）
- 📈 自进化 Harness：Agent 自动优化自身 Harness 成为主流实践
- 📈 Harness 即服务（HaaS）：云厂商提供托管 Harness 平台
- 📈 跨模型 Harness：一套 Harness 适配多个模型的通用层
12.3 长期（2029+）
- 🔮 Harness 与模型协同进化，边界逐渐模糊
- 🔮 "人类掌舵"的比例逐步下降，但治理层（Governance）始终由人类掌控
- 🔮 Harness Engineering 可能融入更广义的 AI Systems Engineering 学科
十三、学习路线图与资源
13.1 入门路线
Week 1-2: 理解概念
├── 读 Mitchell Hashimoto 原文《My AI Adoption Journey》
├── 读 OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》
└── 理解 Agent = Model + Harness 公式
Week 3-4: 动手实践
├── 为你的项目写一份 AGENTS.md / CLAUDE.md
├── 用 Claude Code 或 Codex 完成一个真实任务
└── 体验"犯错 → 工程化修复"循环
Week 5-6: 深入架构
├── 读 Martin Fowler / Birgitta Böckeler 的 Harness Engineering 长文
├── 读 Anthropic《Effective Harnesses for Long-Running Agents》
└── 读 LangChain《The Anatomy of an Agent Harness》
Week 7-8: 进阶研究
├── 读综述论文《Agent Harness Engineering: A Survey》（ETCLOVG 框架）
├── 读翁荔（Lilian Weng）的 Harness 长文
└── 尝试用 DeepAgent 搭建自己的 Harness
13.2 必读文献清单
| # | 文献 | 作者/来源 | 时间 |
|---|---|---|---|
| 1 | My AI Adoption Journey | Mitchell Hashimoto | 2026.02 |
| 2 | Harness Engineering: Leveraging Codex in an Agent-First World | OpenAI (Ryan Lopopolo) | 2026.02 |
| 3 | Harness Engineering（深度分析） | Martin Fowler 网站 / Birgitta Böckeler | 2026.02-04 |
| 4 | Effective Harnesses for Long-Running Agents | Anthropic | 2025.11 |
| 5 | The Anatomy of an Agent Harness | LangChain / Akshay Pachaar | 2026.03 |
| 6 | Agent Harness Engineering: A Survey | 学术综述（170+ 项目） | 2026 |
| 7 | Harness Engineering 与 AI 自进化 | 翁荔 (Lilian Weng) | 2026.07 |
13.3 核心能力模型
成为一名合格的 Harness 工程师，需要以下能力：
┌─────────────────┐
│ 系统架构设计 │ ← 核心中的核心
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌────────▼───────┐ ┌───▼────────┐ ┌──▼───────────┐
│ 上下文工程 │ │ 工具/沙箱 │ │ 评估与测试 │
│ (信息架构) │ │ (安全执行) │ │ (质量闭环) │
└────────────────┘ └────────────┘ └──────────────┘
│ │ │
└──────────────┼──────────────┘
│
┌────────▼────────┐
│ 持续改进思维 │ ← Hashimoto 核心循环
└─────────────────┘
结语
Harness Engineering 的崛起，标志着 AI 工程进入了一个新阶段：
过去，我们问"模型够不够聪明"；现在，我们问"环境够不够可靠"。
Mitchell Hashimoto 用一句朴素的话定义了这场革命：
“每当 AI 犯错，就工程化一个方案，让它永远不再犯同样的错。”
OpenAI 用 100 万行代码、零手写提交的实验证明了它的威力。Martin Fowler 用 Feedforward/Feedback 框架赋予了它理论深度。Anthropic 用 Claude Code 的 10 亿美元年收入验证了它的商业价值。
模型是引擎，Harness 是整辆车。 在 AI Agent 时代，造引擎的人很多，但造好整车的人，才是真正的赢家。
本文写于 2026 年 8 月 4 日。Harness Engineering 仍在快速演进中，建议持续关注 OpenAI、Anthropic、LangChain、Martin Fowler 网站及 Lilian Weng 博客的最新动态。
如果这篇文章对你有帮助，欢迎点赞、收藏、转发。如有疑问或补充，欢迎在评论区交流。 🚀
葡萄城是专业的软件开发技术和低代码平台提供商，聚焦软件开发技术，以“赋能开发者”为使命，致力于通过表格控件、低代码和BI等各类软件开发工具和服务，一站式满足开发者需求，帮助企业提升开发效率并创新开发模式。
更多推荐
7
0- 0
已为社区贡献1条内容
所有评论(0)