Agent Harness：Agent 的「操作系统」

Anthropic 的工程团队在 2025 年提出一个概念：Agent 的价值不在模型，在 Harness。这句话值得所有做 AI 产品的人反复读。

什么是 Harness

Harness = 包裹 LLM 的完整运行时系统，负责管理 Agent 的感知、决策、执行和反馈循环。

类比：

• LLM 是 CPU——负责计算（推理）
• Harness 是 操作系统——负责调度、内存管理、I/O、进程控制

同一个 GPT-4o，放在不同的 Harness 里，表现可以天差地别。

Harness 的核心组件

┌─────────────────────────────────────────────┐
│                  Harness                     │
│                                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Context   │  │ Tool     │  │ Loop     │  │
│  │ Manager   │  │ Router   │  │ Controller│  │
│  └──────────┘  └──────────┘  └──────────┘  │
│                                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Skill     │  │ Sandbox  │  │ Eval &   │  │
│  │ Loader    │  │ / Safety │  │ Monitor  │  │
│  └──────────┘  └──────────┘  └──────────┘  │
│                                              │
│         ┌──────────┐                         │
│         │   LLM    │                         │
│         └──────────┘                         │
└─────────────────────────────────────────────┘

逐个拆解：

1. Context Manager（上下文管理器）

Agent 最大的瓶颈不是模型能力，是 上下文窗口的管理。

Harness 要做的：

• 决定塞什么进上下文（代码文件、Skill、MCP 返回、历史对话）
• 什么时候压缩/摘要旧对话
• 怎么组织信息让 LLM 最高效地利用

这是 2026 年 AI 工程最核心的战场。 详见「上下文工程」篇。

2. Tool Router（工具路由）

LLM 输出「我想调用 tool_X」→ Harness 负责：

• 解析 tool call 请求
• 路由到正确的 MCP Server / 内置工具
• 处理错误、重试、超时
• 把结果格式化后塞回上下文

3. Loop Controller（循环控制器）

Agent 不是一次调用，是 多轮循环：

while (not done && steps < max_steps):
    response = llm.call(context)
    if response.has_tool_calls:
        results = execute_tools(response.tool_calls)
        context.append(results)
    else:
        done = True
return response

Harness 控制：

• 最大步数（防止无限循环）
• 什么时候该停（任务完成判断）
• 中间状态持久化（断了能续）

4. Skill Loader（技能加载器）

根据当前任务类型，从 Skill 库中选择相关 Skill 注入上下文。Cursor 的实现是扫描 .cursor/skills/ 目录，匹配任务关键词。

5. Sandbox / Safety（沙箱与安全）

Agent 能执行代码、改文件、调 API——Harness 必须提供：

• 文件系统隔离（只能碰 workspace 内的文件）
• 命令执行白名单（允许 npm test，禁止 rm -rf /）
• 网络访问控制
• 人工确认 gate（删文件、发 PR 前弹确认）

6. Eval & Monitor（评估与监控）

生产级 Harness 内置：

• 每步 tool call 的成功/失败率
• Token 消耗追踪
• 任务完成质量评分
• 异常行为检测（循环、越权）

三家产品的 Harness 对比

组件	Cursor	Claude Code	Devin
Context	代码索引 + 当前文件 + @引用	整个 repo + terminal 输出	浏览器 + IDE + terminal
Tools	MCP + 内置（读写文件、terminal）	内置（bash、读写、搜索）	全套（浏览器、IDE、部署）
Loop	Agent 模式，用户可中断	自主长任务，少中断	完全自主，异步执行
Sandbox	Workspace 边界	本地 shell	云端 VM 隔离
Skill	SKILL.md 按需加载	CLAUDE.md 项目指令	内部训练的行为模式

关键差异：

• Cursor 的 Harness 优化方向是 人机协作——Agent 做一步，人看一眼，再继续
• Claude Code 优化 长任务自主执行——给了 goal 就跑到完，中间少打扰
• Devin 优化 完全异步——提交任务后走开，回来看结果

Harness 设计的核心权衡

自主性 ←──────────────────────→ 可控性
Devin                          Cursor Tab 补全
(完全自主)                      (每步确认)

上下文大小 ←──────────────────→ 成本/速度
Devin (whole repo)             Cursor (@file 精确引用)

通用性 ←──────────────────────→ 领域深度
通用 Agent                     代码专用 Harness

没有「最好的 Harness」，只有 最匹配场景 的 Harness。

自建 Harness 的最小实现

如果你要在产品里集成 Agent，最小 Harness 需要：

class MinimalHarness:
    def run(self, goal: str, max_steps: int = 20):
        context = self.build_initial_context(goal)
        for step in range(max_steps):
            response = self.llm.chat(context, tools=self.available_tools)
            if response.tool_calls:
                for call in response.tool_calls:
                    result = self.execute_tool(call)
                    context.append(result)
            else:
                return response.text  # 任务完成
        return "Max steps reached"

看起来简单，但每个方法背后都是大量的工程决策——这就是 Harness 的价值。

小结

模型大家都在用（GPT-4o、Claude、Gemini），Harness 才是差异化所在。理解 Harness 的组件和权衡，你就理解了 Cursor 为什么比裸调 API 好用十倍。

下一篇：Harness 里最关键的那个组件——Context Manager，也就是「上下文工程」。