陶玉印的博客

企业数据治理、数据仓库、数据质量、AI应用实践与研究

0%

Harness 的出现在解决什么问题

发表于

一、为什么突然出现 Agent Harness

严格说 Harness 并不是 2026 年才出现。

Claude Code、Codex CLI、Aider、Cline、OpenHands、SWE-agent 早就各自在内部实现了类似机制。只是以前大家通常叫：

  • Agent Loop
  • Agent Runtime
  • Agent Scaffold
  • Tool Loop
  • Execution Engine
  • Agent Framework

到了 2025 年后，模型能力变强，问题开始发生变化。

以前：

1
2
3
4
5
6
7
8
用户
 ↓
Prompt
 ↓
LLM
 ↓
答案

后来变成：

1
2
3
4
5
6
7
8
9
10
11
用户
 ↓
LLM
 ↓
Tool Calling
 ↓
API / Search / SQL / Shell
 ↓
LLM
 ↓
答案

再到 Coding Agent：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Task
 ↓
理解代码库
 ↓
制定计划
 ↓
修改文件
 ↓
执行命令
 ↓
运行测试
 ↓
发现错误
 ↓
修复
 ↓
再次测试
 ↓
提交 PR

这时候，真正复杂的已经不再是那一次 LLM API 调用，而是围绕 LLM 的整个循环。

OpenAI 在分析 Codex 时，把这个核心直接称为 Codex harness：它负责用户、模型和工具之间的 Agent Loop，Codex CLI、IDE、Web 等不同界面实际上都建立在同一个 Harness 之上。

2026 年 2 月 OpenAI 的 Harness engineering 文章进一步把这个问题放大：他们构建一个约百万行代码的内部产品，应用代码、测试、CI、文档和工具全部由 Codex 生成。团队最终发现，工程师大量精力并不是继续优化 Prompt，而是在设计 环境、规则、工具、反馈回路和验证机制。

于是工程重点开始发生变化：

1
2
3
4
5
6
7
Prompt Engineering
        ↓
Context Engineering
        ↓
Agent Engineering
        ↓
Harness Engineering

这几个阶段并不是严格替代关系，而是工程关注层次不断扩大。

二、Agent Harness 到底解决了什么问题

这是理解 Harness 最关键的部分。

1. 解决 LLM “只能生成文本”的问题

裸模型本质还是：

tokens → tokens

即便支持 Function Calling，它自己也不会真正维护：

  • 文件系统
  • Shell
  • 数据库连接
  • API
  • 浏览器
  • MCP
  • 状态
  • Session
  • 重试
  • Checkpoint
  • Sandbox

Harness 把这些环境暴露给模型。

于是：

1
2
3
4
5
6
7
8
9
10
LLM
 ↓
Harness
 ├─ filesystem
 ├─ shell
 ├─ browser
 ├─ SQL
 ├─ MCP
 ├─ API
 └─ sandbox

模型才真正具有“行动能力”。

三、第二个问题：Agent Loop 不可靠

最简单的 Agent 通常只有：

1
2
3
4
5
6
while not done:
    response = llm(context)

    if response.tool_call:
        result = tool(response.tool_call)
        context.append(result)

Demo 很容易写。

生产环境很难。

因为很快就会遇到：

1
2
3
4
5
6
7
8
9
重复调用工具
死循环
提前结束
错误工具
错误参数
反复修改同一文件
执行失败不知道恢复
测试失败继续往下跑
任务已经完成却不知道停止

Harness 因此需要负责：

1
2
3
4
5
6
7
8
9
10
11
Loop Controller

max_iterations
timeout
stop_condition
retry
backoff
loop detection
checkpoint
failure recovery
verification

这也是 Harness 与简单 Function Calling 最大的区别之一。

四、第三个问题：Context Window

长任务最大的工程问题之一其实是：

Agent 工作产生的信息远远超过模型 Context Window。

例如一个 Coding Agent：

1
2
3
4
5
6
7
读取代码       30K
搜索结果       20K
shell output   50K
编译日志       80K
test logs      50K
历史对话       40K

很快几百 K tokens。

所以现代 Harness 普遍开始内建：

1
2
3
4
5
6
7
8
9
10
Context Manager
│
├── Context Selection
├── Summarization
├── Compaction
├── Tool-result eviction
├── File memory
├── Retrieval
├── Working memory
└── Long-term memory

Anthropic 曾专门研究 long-running agent，发现仅依赖 context compaction 并不足以让 Agent 稳定完成跨多个上下文窗口的大型软件任务，还需要任务分解、工作交接和持久化中间状态。

所以可以认为：

Context Engineering 正在逐渐成为 Harness 的一个子系统。

五、第四个问题：执行安全

当 Agent 只能回答问题的时候，风险主要是：

回答错了

当 Agent 获得：

1
2
3
4
5
6
7
8
9
rm
git push
kubectl
数据库
ERP API
邮件
云平台
生产环境

风险变成：

做错了

这是完全不同的问题。

于是 Harness 必须加入：

1
2
3
4
5
6
7
8
9
10
Policy Engine
       │
       ├─ Tool Allowlist
       ├─ Permission
       ├─ Human Approval
       ├─ Sandbox
       ├─ Network Policy
       ├─ Credential Boundary
       ├─ Resource Limit
       └─ Audit

Anthropic 2026 年对 Claude Code、Claude.ai 和 Cowork 的安全实践总结得很清楚：Agent 能力越强，真正需要控制的是 blast radius——它最多能造成多大影响，因此 Sandbox、VM、网络出口控制等环境级隔离越来越重要。

这也是为什么：

Sandbox 正在变成 Harness 的标准组件。

六、第五个问题：模型输出不可验证

这是 Agent 和 Chatbot 最大的工程区别之一。

Chatbot：

1
2
3
用户：分析这个问题
LLM：给出答案

很多时候人看一下即可。

Agent：

1
2
3
4
5
修改代码
执行SQL
创建文件
调用业务系统
部署应用

不能靠：

LLM：我认为任务已经完成。

必须形成：

1
2
3
4
5
6
7
8
9
10
11
Plan
 ↓
Execute
 ↓
Observe
 ↓
Verify
 ↓
Pass?
 ├── YES → Done
 └── NO  → Retry/Fix

因此现代 Harness 越来越重视：

  • deterministic verification
  • tests
  • lint
  • schema validation
  • acceptance criteria
  • critic
  • evaluator
  • self-verification

LangChain 2026 年的一个案例很有代表性：不更换模型，只改 Harness，加入 self-verification、loop detection 和 tracing 等机制，其 Coding Agent 在 Terminal-Bench 2.0 上从 Top 30 提升到 Top 5。

这说明一个非常重要的趋势：

模型能力已经不再等于 Agent 能力。

更准确地说：

1
2
3
4
5
6
7
8
Agent Capability
≈
Model
× Harness
× Tools
× Context
× Environment
× Verification

七、Harness 的典型架构

现在比较完整的 Agent Harness，可以抽象成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
                 User / API
                     │
                     ▼
             ┌──────────────┐
             │ Agent Harness│
             └──────┬───────┘
                    │
    ┌───────────────┼─────────────────┐
    │               │                 │
    ▼               ▼                 ▼
Planner        Context Manager    Policy Engine
    │               │                 │
    │          ┌────┴─────┐           │
    │          │ Memory   │           │
    │          │ RAG      │           │
    │          │ Compact  │           │
    │          └──────────┘           │
    │                                 │
    └──────────────┬──────────────────┘
                   ▼
             Agent Loop
                   │
          ┌────────┴────────┐
          ▼                 ▼
        Model          Tool Router
                           │
              ┌────────────┼─────────────┐
              ▼            ▼             ▼
             MCP          API          Shell
              │            │             │
              └────────────┼─────────────┘
                           ▼
                        Sandbox
                           │
                           ▼
                        Result
                           │
                           ▼
                       Verifier
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
            Pass                       Fail
              │                         │
             Done                 Retry / Recover

再往生产环境走，还会增加：

1
2
3
4
5
6
7
8
9
10
11
12
13

Tracing
Observability
Evaluation
Cost
Token Budget
Checkpoint
Session
Queue
Scheduler
Secrets
Audit
Multi-Agent

八、Harness、Framework、Runtime、Orchestrator 到底有什么区别

现在行业仍然有术语混用。2026 年甚至已有论文专门研究“什么才算 Agent Harness”，指出 Claude Code、Codex CLI、Aider、Cline、OpenHands、SWE-agent 都可以被视为 Harness，但 Agent Framework、SDK、IDE Plugin、Eval Harness 和 Orchestrator 并不能简单等同。

当前主流产品重新归类

产品 最核心定位 备注
LangChain Framework Agent、Tool、Model 等开发抽象
Cordis Composition Framework DeepSeek Harness 的插件与事件基础
LangGraph Runtime State、Checkpoint、Durable Execution
DeepSeek Harness Composable Harness Agent Loop、Session、Tool、Sandbox、Policy 全插件化
Deep Agents Harness 基于 LangGraph 的 Batteries-included Harness
Claude Agent SDK Model-native Harness Claude 深度优化
Codex Harness Model-native Harness Codex 执行核心
OpenHands SDK Software Agent Harness Coding / Software Engineering 优化
AWS AgentCore Harness Managed Harness 云托管 Agent Harness
Agent Teams / Symphony 类 Orchestration 多 Agent / 多任务协调
OpenHands Control Plane Control Plane Agent Fleet 管理

可以把四个概念压缩成四句话：

1
2
3
4
5
6
7
8
9
10
11
Framework
= 怎么写 Agent

Runtime
= Agent 怎么可靠地跑

Harness
= Agent 到底怎么工作

Orchestrator
= 多个 Agent 怎么协同运行

九、Agent Harness 已经演化到什么阶段

如果按技术演进看，可以划成五代。

Stage 1：Agent Loop

大约 2023–2024。

核心：

1
2
3
4
5
6
7
8
LLM
 ↓
Tool
 ↓
Observation
 ↓
LLM

典型：

  • ReAct
  • Function Calling
  • LangChain Agent

这一阶段的 Harness 本质就是几十到几百行循环代码。

Stage 2：Context + Tools

2024–2025。

开始出现：

1
2
3
4
5
6
7
Tool Calling
RAG
Memory
MCP
Filesystem
Browser
Shell

Agent 开始真正进入外部环境。

Coding Agent 成为最早成熟的应用。

Stage 3：Production Harness

2025–2026。

现在基本处于这个阶段。

Harness 开始内建：

1
2
3
4
5
6
7
8
9
10
11
12
planning
todo
context compaction
filesystem
skills
subagents
sandbox
checkpoint
approval
verification
retry
tracing

Claude Agent SDK、Codex Harness、Deep Agents、OpenHands 都属于这一代。

Stage 4：Managed Harness

这是 2026 年正在快速发生的变化。

以前：

1
2
3
4
5
6
7
8
9
10
11
12
开发者
 ↓
自己写 Agent Loop
 ↓
自己维护 context
 ↓
自己接 tools
 ↓
自己做 sandbox
 ↓
自己做状态恢复

现在云厂商开始提供：

1
2
3
4
5
6
7
8
9
10
model
tools
skills
instructions
policy
memory

        ↓

Managed Harness

例如 AWS 在 2026 年 6 月 17 日宣布 Bedrock AgentCore Harness GA，直接提供：

  • orchestration loop
  • tool execution
  • context window management
  • state persistence
  • failure recovery
  • session isolation
  • filesystem
  • shell
  • memory
  • skills
  • browsing

开发者更多变成“声明 Agent”，而不是手写循环。

Anthropic Managed Agents 也走的是类似方向，将：

1
2
3
Session
Harness
Sandbox

抽象成稳定接口，而底层 Harness 可以随着模型能力变化持续升级。

所以：

Harness 正在经历类似 Kubernetes 把容器运行复杂性基础设施化的过程。

Stage 5：Agent Control Plane / Agent Fleet

这是目前刚开始形成的一层。

当企业不是运行：

1 Agent

而是：

1
2
3
100
1000
10000 Agents

问题会变成：

1
2
3
4
5
6
7
8
9
10
11
谁创建 Agent？
谁分配任务？
用哪个模型？
花了多少钱？
能访问什么？
跑在哪个 Sandbox？
任务失败怎么办？
谁审批？
谁审计？
谁负责版本？
Agent之间如何协作？

于是：

1
2
3
4
5
6
7
8
9
               Agent Control Plane
                      │
    ┌─────────────────┼──────────────────┐
    ▼                 ▼                  ▼
Agent A            Agent B             Agent C
    │                 │                  │
 Harness           Harness            Harness
    │                 │                  │
 Sandbox           Sandbox            Sandbox

OpenHands 已经明确把整个 Agent 软件栈分成：

1
2
3
Harness
Orchestrator
Control Plane

其中 Harness 管单个 Agent 的 reasoning loop，Orchestrator 管环境，Control Plane 管大量 Agent 的 routing、budget、policy、observability。

OpenAI 的 Symphony 也反映了同一趋势：让 Linear 等项目管理系统成为控制面，每个任务可以分配一个持续运行的 Coding Agent。

十、再往下一步：Self-Evolving Harness

这是现在很值得关注的研究方向。

目前 Harness Engineering 通常还是：

1
2
3
4
5
6
7
Agent失败
 ↓
工程师分析 Trace
 ↓
修改 Tool / Prompt / Memory / Middleware
 ↓
重新评测

正在探索：

1
2
3
4
5
6
7
8
9
10
11
12
13
Agent运行
 ↓
Trace
 ↓
自动发现 Failure Pattern
 ↓
修改 Harness
 ↓
Eval
 ↓
保留提升
 ↓
继续演化

2026 年已经出现 Agentic Harness Engineering 相关研究，让系统根据执行轨迹自动优化 Harness；研究结果也表明性能提升更多来自 tools、middleware 和 memory，而不仅是 system prompt。

不过这一层一般定义为：

研究期 / Early Adopter，而不是成熟生产标准。

十一、目前横向有哪些主要产品

这里必须分类型，否则 Claude Code、LangGraph、AWS AgentCore 放在一张榜里其实没有太大意义。

第一类：Model-native Harness

1. Anthropic Claude Agent SDK / Claude Code

特点：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Claude
 +
Agent Loop
 +
Tools
 +
Context Management
 +
Filesystem
 +
Shell
 +
Skills
 +
Subagents

优势：

  • 与 Claude 深度优化；
  • Coding Agent 很成熟；
  • Context engineering 强；
  • 长任务能力强；
  • Skills 体系值得关注；
  • 安全和 Sandbox 投入很深。

Anthropic 已经明确将 Claude Agent SDK 称为一个 general-purpose Agent Harness。

适合：

Claude 生态、Coding Agent、高能力自主 Agent。

2. OpenAI Codex Harness / Agents SDK

Codex CLI、IDE、Web 背后实际上共享 Codex Harness。OpenAI 2026 年进一步在 Agents SDK 中加入 model-native harness，使 Agent 可以直接操作文件、执行命令并在受控 Sandbox 中完成长任务。

优势：

1
2
3
4
5
Codex / GPT 深度优化
coding
sandbox
computer tools
long-horizon task

一个值得关注的架构变化是：

1
2
3
4
5
6
7
Codex Harness
      │
  App Server
      │
 ┌────┼─────────┐
 ▼    ▼         ▼
CLI   IDE       App

Harness 正在和 UI 解耦。

第二类：Model-agnostic Harness

3. LangChain Deep Agents

这是目前非常典型的“纯 Harness 产品”。

架构：

1
2
3
4
5
Deep Agents
     ↓
LangChain
     ↓
LangGraph Runtime

内建：

  • planning
  • Todo
  • filesystem
  • subagents
  • context management
  • long-term memory
  • model profiles

而且可以使用不同模型。

适合：

企业自己构建通用 Agent Harness。

如果不希望被 OpenAI / Anthropic 单一模型绑定，这是目前非常值得研究的一条路线。

4. OpenHands Software Agent SDK

这是 Coding Harness 中非常值得关注的开源方案。

OpenHands SDK 已经包含：

1
2
3
4
5
6
7
8
9
Agent reasoning loop
State
LLM abstraction
Tools
Workspace
Skills
Context condenser
MCP
Security

并且支持：

1
2
3
Claude
GPT
Open-source LLM

同时拥有：

1
2
3
4
Docker Sandbox
Remote Sandbox
Agent Server
Cloud

特别适合：

私有部署、自建 Coding Agent、模型无关 Agent。

第三类：Enterprise / Managed Harness

5. Microsoft Agent Framework Harness

微软最新 Agent Framework 已经直接提供 HarnessAgent。

包含：

1
2
3
4
5
6
7
8
planning
todo
context compaction
file memory
file access
tool approval
agent looping
background agents

并可以基于不同 IChatClient，包括不同模型提供商。

方向非常明显：

企业 SDK + Harness。

6. AWS Bedrock AgentCore Harness

这是目前“Harness as Managed Infrastructure”路线非常典型的代表。

配置：

1
2
3
4
5
6
Model
Tools
Skills
Instructions
Memory
Environment

AWS 帮你生成和运行 Harness。其 API 甚至已经直接出现：

CreateHarness

以及：

1
2
3
4
5
6
7
8
9
10
allowedTools
maxIterations
maxTokens
memory
model
skills
tools
timeout
truncation
environment

这基本已经把 Harness 正式产品化。

十二、目前产品格局可以这样看

产品 类型 模型绑定 插件/扩展 Sandbox Long-running Multi-Agent 企业自建价值 当前成熟度
Claude Agent SDK Model-native Harness Claude 强绑定 ★★★★ ★★★★ ★★★★★ ★★★★ ★★★★ 成熟
OpenAI Codex Harness / Agents SDK Model-native Harness OpenAI 优先 ★★★★ ★★★★★ ★★★★★ ★★★★ ★★★★ 成熟
DeepSeek Harness 通用可组合 Harness 低 ★★★★★ ★★★★ ★★★★ ★★★★ ★★★★★ Developer Preview
LangChain Deep Agents 通用 Harness 低 ★★★★★ ★★★★ ★★★★★ ★★★★★ ★★★★★ 快速成熟
OpenHands SDK Software/Coding Harness 低 ★★★★ ★★★★★ ★★★★ ★★★★ ★★★★★ 较成熟
Microsoft Agent Framework Harness Enterprise Harness 低 ★★★★ ★★★★ ★★★★ ★★★★ ★★★★★ 快速成熟
AWS Bedrock AgentCore Harness Managed Harness AWS 生态 ★★★★ ★★★★★ ★★★★★ ★★★★ ★★★★ 生产化

这里的星级是基于当前产品定位做的架构成熟度判断，不是官方评分。

另外，在 Coding Harness 这个更宽泛的分类里，Claude Code、Codex CLI、Aider、Cline、OpenHands、SWE-agent 等通常都可以归进去；2026 年针对 Harness 定义的研究也使用了这几种系统作为典型案例。

十三、目前最重要的变化

以前大家讨论 Agent，经常画成：

1
2
3
4
5
6
         Agent
           │
 ┌─────────┼─────────┐
 ▼         ▼         ▼
LLM       RAG       Tools

现在更准确的架构应该是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
                    Agent Application
                           │
                           ▼
                    Agent Harness
                           │
       ┌───────────────────┼───────────────────┐
       ▼                   ▼                   ▼
 Model Router        Context Layer        Tool Layer
       │                   │                   │
       ▼                   ▼                   ▼
GPT/Claude/...       Memory / RAG          MCP / API
                           │
                           ▼
                        Runtime
                           │
                           ▼
                        Sandbox
                           │
                           ▼
                        Systems

再往企业级发展：

1
2
3
4
5
6
7
8
9
10
              Agent Control Plane
                      │
   ┌──────────────────┼──────────────────┐
   │                  │                  │
   ▼                  ▼                  ▼
Agent A            Agent B            Agent C
   │                  │                  │
Harness            Harness            Harness
   │                  │                  │
Runtime            Runtime            Runtime

十四、这件事情真正的意义

Agent Harness 最大的意义不是增加了一个 AI 新名词，而是它把 Agent 工程的重心从：

如何让模型回答得更好？

转向：

1
2
如何构造一个系统，
让模型持续、正确、安全、低成本地完成任务？

这实际上是一次工程范式变化：

第一阶段

模型决定能力。

第二阶段

模型 + Prompt 决定能力。

第三阶段

模型 + Context + Tools 决定能力。

现在

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Model
+
Context
+
Tools
+
Memory
+
Runtime
+
Sandbox
+
Policy
+
Verification
+
Observability
+
Harness

共同决定 Agent 能力。

所以未来企业真正重要的资产，很可能不仅是：

1
2
3
4
Prompt Library
Knowledge Base
Model Router
MCP Servers

而会进一步形成：

Enterprise Agent Harness

它负责统一：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Agent Loop
Context
Memory
Tool
MCP
Model Routing
Security
Sandbox
Retry
Checkpoint
Verification
Observability
Cost
Audit

模型可以换，Harness 尽量不换。

这也是 Agent Harness 最有战略意义的一点：

未来企业 AI 平台的稳定层很可能不是某一个 LLM，而是 Model Router + Semantic/Knowledge Layer + Agent Harness + Agent Control Plane。

而从目前看，行业成熟度判断为：

1
2
3
4
5
6
Coding Harness             █████████░  成熟
General Agent Harness      ███████░░░  快速成熟
Managed Harness            ██████░░░░  早期生产期
Enterprise Control Plane   ████░░░░░░  形成期
Multi-Agent Fleet          ████░░░░░░  形成期
Self-Evolving Harness      ██░░░░░░░░  研究期

这可能也是继 Model Router、Semantic Layer、MCP 之后，企业 Agent 架构里最值得重点关注的一层。

如果继续往企业架构方向推演，下一步最有价值的是把 Model Router + Agent Harness + MCP + Semantic Layer + Sandbox + Control Plane 拼成一套完整的企业级 Agent 技术架构，并明确每一层哪些应该自建、哪些适合直接使用开源产品。