Agent Harness：2026 年 AI 工程化最核心的基础设施

"Agent = Model + Harness" —— 2026 年 AI 工程圈的定义性公式

2026 年春天，AI 工程圈被一个看似生僻的词汇点燃了。

"Agent Harness"。

OpenAI 用它构建了一个百万行代码的产品，零行人工手写。Anthropic 的 Claude Code 用它实现了 100% 自举开发。LangChain 发布了 Deep Agents，将 Harness 作为一等公民。Martin Fowler 专门写了一篇长文，定义这个新兴工程领域。

这不是又一个框架的炒作。这是一场正在发生的工程范式转移——当模型能力达到阈值后，决定 Agent 成败的不再是模型本身，而是包裹在模型外面的那层"Harness"。

一、什么是 Agent Harness？

1.1 一句话定义

Agent Harness 是包裹在 LLM 外面的软件基础设施层，负责处理除模型本身以外的所有事务。

Simon Willison 的经典定义：

"Agent = LLM running tools in a loop"

而 Harness 就是让这个 loop 跑起来的完整工程系统。

1.2 核心公式

Agent = Model + Harness

LangChain 的 Vivek Trivedy 在 2026 年 3 月首次系统阐述了这个公式，随后被 OpenAI、Martin Fowler 和学术界快速采纳。

1.3 为什么现在火了？

2025-2026 年，AI 行业发现了一个反直觉的事实：

核心洞察：当模型能力达到阈值后，工程封装（Harness） 比模型本身的提升更能决定 Agent 的可靠性。

二、Harness 解决了什么问题？

2.1 模型的原生局限

纯 LLM 只能做一件事：接收文本输入，输出文本。

它不能：

• ❌ 记住跨会话的信息
• ❌ 执行代码或调用 API
• ❌ 访问外部文件系统
• ❌ 自我验证和纠错
• ❌ 分解复杂任务并跟踪进度

2.2 Harness 的四大弥补

2.3 一个具体例子

假设你要让 Agent 开发一个 Web 应用：

没有 Harness 的模型：

用户：帮我写一个 claude.ai 的克隆
模型：（生成几千行代码）
用户：代码在哪里运行？
模型：我无法执行代码，我只能生成文本...

有 Harness 的 Agent：

用户：帮我写一个 claude.ai 的克隆
Harness：
  1. 初始化项目目录和 git 仓库
  2. 创建 feature_list.json（200+ 功能点）
  3. 生成基础架构代码
  4. 启动开发服务器验证
  5. 记录进度到 claude-progress.txt
  6. 每轮会话增量开发一个功能
  7. 自动化测试验证
  8. 提交 PR

三、ETCLOVG：Harness 的七层架构

2026 年 4 月，一篇综述论文 Agent Harness Engineering: A Survey 提出了目前最系统的 Harness 工程框架。

┌─────────────────────────────────────────────────────────────┐
│                    ETCLOVG 七层架构                           │
├─────────────────────────────────────────────────────────────┤
│  G │ Governance（治理与安全）                                │
│    │ 权限模型、审计、声明式约束、生命周期钩子                    │
├────┼─────────────────────────────────────────────────────────┤
│  V │ Verification（验证与评估）                               │
│    │ 基准测试、故障归因、回归反馈、部署时评估循环                │
├────┼─────────────────────────────────────────────────────────┤
│  O │ Observability（可观测性）                                │
│    │ 轨迹追踪、成本监控、可靠性信号、运维工具                   │
├────┼─────────────────────────────────────────────────────────┤
│  L │ Lifecycle（生命周期与编排）                               │
│    │ 单 Agent 控制循环、多 Agent 编排、任务触发流水线           │
├────┼─────────────────────────────────────────────────────────┤
│  C │ Context（上下文与记忆管理）                                │
│    │ 短期对话、长期记忆、上下文压缩、防漂移                     │
├────┼─────────────────────────────────────────────────────────┤
│  T │ Tool Interface（工具接口与协议）                           │
│    │ MCP、A2A 协议、工具描述、工具选择、会话管理                │
├────┼─────────────────────────────────────────────────────────┤
│  E │ Execution（执行环境与沙箱）                                │
│    │ 容器、microVM、浏览器沙箱、OS 权限、代码运行时              │
└────┴─────────────────────────────────────────────────────────┘

3.1 各层详解

E - Execution（执行环境）

• 决定 Agent 代码在哪里运行
• 沙箱隔离、权限控制、资源限制
• 从 Docker 容器到 microVM 到浏览器环境

T - Tool Interface（工具接口）

• MCP（Model Context Protocol）：标准化工具描述和调用
• A2A（Agent-to-Agent Protocol）：Agent 间通信
• 工具发现、选择、执行、结果反馈

C - Context（上下文管理）

• 短期：当前会话的对话历史
• 中期：跨会话的记忆摘要
• 长期：知识库、向量检索、持久化状态

L - Lifecycle（生命周期编排）

• 单 Agent：ReAct 循环、Plan-and-Execute
• 多 Agent：父 Agent 委派子 Agent
• 任务分解、进度跟踪、失败重试

O - Observability（可观测性）

• 轨迹记录（Trace）：每一步的输入输出
• 成本追踪：Token 消耗、API 调用费用
• 性能监控：延迟、成功率、错误率

V - Verification（验证与评估）

• 基准测试：SWE-bench、Terminal-bench 等
• 回归测试：确保修改不破坏已有功能
• 人工评估：对复杂任务的人类判断

G - Governance（治理与安全）

• 权限控制：Agent 能访问什么资源
• 审计日志：所有操作可追溯
• 安全策略：防止提示注入、越权操作

四、行业巨头的 Harness 实践

4.1 Anthropic：Claude Code 的 Harness 设计

Anthropic 在 2025 年 11 月发布的 Effective Harnesses for Long-Running Agents 中，分享了 Claude Code 的核心 Harness 设计。

核心问题：长周期 Agent 在跨会话时会"失忆"

解决方案：Initializer + Coding Agent 双模式

第一轮会话：Initializer Agent
  ├── 创建项目目录结构
  ├── 初始化 git 仓库
  ├── 编写 feature_list.json（200+ 功能点，全部标记为 failing）
  ├── 创建 claude-progress.txt（进度日志）
  ├── 编写启动脚本（init.sh）
  └── 提交初始 commit

后续每轮会话：Coding Agent
  ├── 读取 claude-progress.txt 了解进度
  ├── 从 feature_list 选择最高优先级的 failing 功能
  ├── 实现该功能
  ├── 运行自动化测试验证
  ├── 将功能标记为 passing
  ├── 更新 claude-progress.txt
  └── 提交 commit

关键洞察：

• Initializer 解决"一次性做太多"的问题
• Coding Agent 解决"过早宣布胜利"的问题
• claude-progress.txt 是跨会话记忆的桥梁

4.2 OpenAI：Harness Engineering 的极端实践

OpenAI 在 2026 年 2 月发布的 Harness engineering: leveraging Codex in an agent-first world 中，描述了一个极端实验：

一个 3 人团队，5 个月，从零构建一个百万行代码的产品，零行人工手写代码。

约束条件：

• 不允许手动写任何代码
• 所有代码必须由 Codex Agent 生成
• 人类只负责：写需求、审查结果、调整 Harness

结果：

• 开发速度提升 10 倍
• 代码覆盖率达到生产标准
• CI/CD、文档、监控全部由 Agent 生成

核心方法论：

Human: 写需求描述（声明式）
   ↓
Harness: 分解任务、生成代码、运行测试
   ↓
Human: 审查结果、调整需求
   ↓
Harness: 迭代优化

4.3 LangChain：Deep Agents 的 Batteries-Included Harness

LangChain 在 2026 年 3 月发布 Deep Agents，定位是 "batteries-included agent harness"。

设计哲学：

• 开箱即用：规划、上下文管理、委派全部内置
• 模型无关：支持任何模型提供商
• 原生集成：与 LangSmith 追踪和部署无缝衔接

核心架构：

# Deep Agent 的 Harness 结构
parent_agent
  ├── planning_model      # 规划任务分解
  ├── sub_agent_registry  # 子 Agent 注册表
  ├── memory_files        # 持久化记忆文件
  ├── skills              # 可复用技能模块
  └── human_in_the_loop   # 人工介入点

4.4 Martin Fowler：Harness Engineering 的理论框架

Martin Fowler 在 2026 年 4 月的文章中，从软件工程角度定义了 Harness Engineering。

核心模型：Feedforward + Feedback

        ┌─────────────┐
        │   Guides    │  ← Feedforward（前馈控制）
        │  (人类制定)  │     预期 Agent 行为，提前引导
        └──────┬──────┘
               ↓
        ┌─────────────┐
        │  Coding Agent │
        │   (LLM)      │
        └──────┬──────┘
               ↓
        ┌─────────────┐
        │   Sensors   │  ← Feedback（反馈控制）
        │  (自动执行)  │     观察 Agent 输出，帮助自修正
        └─────────────┘

三种 Harness 类型：

两种执行类型：

五、Harness 工程的关键数据

5.1 性能差距实验

论文 How Much Heavy Lifting Can an Agent Harness Do? 的核心发现：

在一个 noisy Collaborative Battleship 游戏中，固定使用同一个 LLM：

结论：声明式规划层本身就能带来最大收益，根本不需要调用 LLM。

5.2 行业对比

六、Harness 与 Orchestrator 的区别

这是一个经常被混淆的概念：

关系：

• Orchestrator 决定 "做什么"
• Harness 提供 "怎么做" 的能力

例子：

Orchestrator: "这个任务需要调用搜索工具，然后分析结果"
Harness: 提供搜索工具的实现、管理 API 密钥、处理超时、格式化结果

七、Harness 工程的 5 大开放挑战

7.1 执行环境加固与扩展

• 如何平衡安全性（沙箱隔离）与功能性（文件系统访问）？
• 容器 vs microVM vs 浏览器环境的选择模型

7.2 长运行 Agent 的可靠状态

• 上下文压缩时的信息丢失如何量化？
• 如何从持久化工件恢复，而非依赖压缩历史？

7.3 原生追踪故障诊断

• 让追踪（trace）成为系统的一等公民，而非事后分析
• 从轨迹中自动归因故障、生成回归测试

7.4 Agent ↔ 工具 ↔ 人类 的标准交接

• 交接内容：意图、约束、权限、工件、预算、风险级别...
• 既要足够丰富保证安全，又要足够简单便于采用

7.5 随模型改进的自适应简化

• 模型变强后，某些 Harness 干预可能变成负担
• 需要机制自动消融、优化、简化 Harness 层

八、对开发者的意义

8.1 技能转变

8.2 面试加分项

如果你正在面试 AI 相关岗位（比如字节 CQC 大模型运营），理解 Harness 可以让你这样回答：

"我理解 Agent Harness 是包裹 LLM 的工程基础设施层。在内容风控场景中，Harness 负责管理审核规则的上下文（C层）、调用分类模型工具（T层）、编排多轮审核流程（L层）、监控模型效果指标（V层）。优化 Harness 结构可能比换模型更能提升审核准确率。"

8.3 学习路径

1. 先用 Claude Code / Codex 实际体验 Agent 编程
2. 阅读 LangChain 的 The Anatomy of an Agent Harness
3. 研究 OpenAI 和 Anthropic 的工程博客
4. 尝试自己构建一个简单的 Harness（工具调用 + 记忆）
5. 关注 ETCLOVG 七层模型，系统性理解

九、写在最后

2026 年，AI 工程正在经历一场静默的革命。

一年前，大家还在比拼谁的模型参数更多、训练数据更大。今天，行业共识已经转向：模型是燃料，Harness 是引擎。

OpenAI 用 Harness 实现了 10 倍开发速度。Anthropic 用 Harness 让 Claude Code 自举开发。LangChain 把 Harness 变成可复用的基础设施。Martin Fowler 把它定义为软件工程的新分支。

对于普通开发者来说，这意味着：

• 你不需要训练模型，但你需要理解如何驾驭模型
• Prompt 工程只是起点，Harness 工程才是终点
• Agent = Model + Harness，两者缺一不可

2026 年，Harness Engineering 正在成为 AI 工程化最核心的基础设施。现在理解它，正是时候。

参考资源

1. OpenAI — Harness engineering: leveraging Codex in an agent-first world (2026-02)
2. Anthropic — Effective harnesses for long-running agents (2025-11)
3. Anthropic — Scaling Managed Agents: Decoupling the brain from the hands (2026-04)
4. LangChain — The Anatomy of an Agent Harness (2026-03)
5. Martin Fowler — Harness engineering for coding agent users (2026-04)
6. 综述论文 — Agent Harness Engineering: A Survey (OpenReview 2026)
7. 核心论文 — How Much Heavy Lifting Can an Agent Harness Do? (arXiv 2026)
8. GitHub 仓库 — github.com/Gloriaameng/Awesome-Agent-Harness

本文持续更新。如果你有好的实践或发现，欢迎分享。