AI 工程 · 2026年3月11日 · 深度报告

Agent = Model + Harness：决定 AI Agent 性能的真正因素

所有人都在追逐更强大的模型，但几乎没人谈论脚手架。这是我最近观察到的一个奇怪现象。每当有新模型发布，科技圈就会沸腾，大家讨论参数量、基准测试分数、上下文长度。但当我深入研究那些真正成功的 AI agent 产品时，我发现了一个被严重忽视的真相：决定 AI agent 性能的，不是你用哪个模型，而是你如何使用这个模型。

Harness 到底是什么

Tony Kipkemboi 把 agent 开发比作一个光谱：最左边是原始代码，你直接调用 API，自己管理状态，从零开始构建一切。中间是 agent framework（代理框架），给你提供结构和抽象，但你仍然需要做很多决定。最右边是 agent harness（代理脚手架），这是最有观点的方案，一切都已经内置好了。

Viv 则从更技术的角度给出了定义：Agent = Model + Harness。如果不是模型本身，那就是 harness。换句话说，harness 是所有不属于模型的代码、配置和执行逻辑。

Harness 包含什么

系统提示
工具和技能及其描述
捆绑的基础设施（文件系统、沙盒、浏览器）
编排逻辑（子 agent 生成、交接、模型路由）
用于确定性执行的钩子和中间件（压缩、续传、语法检查）

Framework vs Harness：关键区别

Framework 给你提供构建 agent 的抽象。你定义角色、任务、工具。你指定 agent 如何协作，是顺序工作还是层次化工作。Framework 处理管道工作——调用 LLM、路由工具输出、管理执行循环。但你仍在做架构决策。

相比之下，harness 不给你构建块，它给你一个完整的系统。Tony 举的例子是 OpenClaw，几周前在网上很火。这是一个 harness。你下载它，添加 API 密钥，突然就有了一个可以在 WhatsApp、Telegram 和其他平台上聊天的 agent。内存已处理。上下文管理已处理。Agent 循环已处理。工具调用、权限、状态持久化，全都内置了。

你不是在配置内存系统，不是在决定工具如何注册或 agent 如何从错误中恢复。这些决定已经由构建 harness 的人做出。你的工作是把它指向一个任务并让它运行。

数据说话：为什么 Harness 比模型更重要

CORE-Bench 的测试结果非常直接：

模型	Harness A	Harness B	提升
Claude Opus 4.5	42%	78%	+86%
Sonnet 4	33%	47%	+42%
Sonnet 4.5	44%	62%	+41%

同样的模型，性能几乎翻倍。唯一的变量是 harness。

            Cursor 案例：懒工具加载将 token 使用量削减了 46.9%。这是一个具有统计显著性的数字。同样的任务，同样的模型，只是改变了工具的加载方式，就能节省近一半的 token。
        

            Vercel 案例：删除了 agent 80% 的工具，结果 agent 从失败任务变成了完成任务。Token 从 145463 降到 67483，步骤从 100 降到 19，延迟从 724 秒降到 141 秒。
        

顶尖公司的 Harness 实践

Claude Code：模型控制循环

Claude Code 采用"模型控制循环"的理念。它是一个简单的 while(tool_call) 循环，没有复杂的 DAG 编排，没有竞争的 agent 角色。模型接收消息和工具，返回文本结束循环，返回工具调用继续循环。

Claude Code 只提供约 18 个原始工具，分四类：命令行发现、文件交互、网页访问和编排。设计哲学是原始工具优于集成。更有意思的是，Anthropic 选择正则表达式（ripgrep）而不是向量数据库进行代码搜索，理由是 Claude 的代码理解能力足够强。

Cursor：文件作为基本原语

Cursor 的核心决策是"文件作为基本原语"。为什么？因为文件支持强大搜索、可自然分组、可版本化。他们针对每个前沿模型专门调优 harness。不同模型得到不同工具名称、提示指令和行为指导。

Cursor 的自定义语义搜索特别值得一提。他们的嵌入模型使用 agent 会话轨迹作为训练数据。结果是搜索准确率平均提高 12.5%，在大型代码库上的代码保留率提高 2.6%。

Manus：删除的艺术

Manus 从推出以来已经重写了五次框架。他们最独特的做法是使用 logit masking 而不是动态移除工具。所有约 29 个工具永久加载，每步可用性通过约束输出 token 概率控制。

Manus 团队得出的最大教训是：最大性能提升来自删除东西。复杂工具定义被 shell 执行替代，"管理 agent"被简单交接替代。如果你的 agent harness 在模型变好的同时变复杂，那就出问题了。

● ● ●

Progressive Disclosure：关键但被忽视的模式

Himanshu 特别强调了 progressive disclosure（渐进式披露）这个概念，我认为这是整个 harness 设计中最被低估的模式。

Progressive disclosure 借鉴自 UI/UX 设计，1980 年代起源于 IBM Research 的 John Carroll，1990 年代由 Jakob Nielsen 推广。核心原则：只显示现在需要的内容，按需揭示复杂性。

数据对比

静态加载：注入 25000 个 token，效率 0.8%

Progressive disclosure：只需 955 个 token，效率 100%

改进：约 26 倍

Liu 等人在 TACL 2024 的论文证明，LLM 性能遵循 U 型曲线——相关信息在输入开头或结尾时性能最高，在中间时下降。即使长上下文模型也是如此。

Harness 的核心组件

基于 Viv 的分析，harness 必须包含的几个核心组件：

文件系统 - 最基础的 harness 原语，让 agent 有持久存储
Bash 和代码执行 - 通用工具，让模型可以自己创建工具
沙盒和执行环境 - 安全的操作环境，实现规模化
内存和搜索 - 用于持续学习，访问训练时不存在的知识
压缩 - 当上下文窗口接近填满时的策略

Harness 的未来

Viv 认为随着模型变得更有能力，今天存在于 harness 中的一些东西会被吸收到模型中。模型会在规划、自我验证和长时程连贯性上原生变好，因此需要更少的上下文注入。

但这并不意味着对你任务最好的 harness 就是模型后训练时用的那个。Terminal Bench 2.0 排行榜是个好例子。Opus 4.6 在 Claude Code 中的得分远低于在其他 harness 中的 Opus 4.6。通过只改变 harness 可以榨取很多价值。

我对 Harness 未来的思考

我认为 harness 工程正在成为一门独立的学科。就像软件工程从计算机科学中分离出来，成为一个有自己方法论、最佳实践和工具链的领域一样，harness 工程也在经历类似的过程。

虽然模型在变得更强大，但对 harness 的需求不会消失，只是会转变形式。早期的 harness 主要是在弥补模型的不足，但随着这些能力逐渐被模型原生支持，harness 的角色会从"能力补充"转向"性能优化"和"可靠性保证"。

从商业角度看，harness 工程能力将成为 AI 公司的核心竞争力之一。模型本身正在快速商品化，但如何有效利用这些模型、如何设计出让模型发挥最大效能的系统，这才是真正的护城河。

最好的团队一直在简化。Manus 五次重写，每次都删除东西。Anthropic 设计 Claude Code 是为了随模型改进而缩小。Harness 工程的终极目标不是构建一个功能齐全、无所不包的系统，而是找到最小必要集。

            核心洞察：Agent = Model + Harness。模型提供智能，harness 让智能有用。在追逐更强大模型的同时，我们不应该忽视 harness 工程的价值。因为最终，没有人购买引擎，大家购买的是完整的汽车。
        

参考来源

Himanshu - "12 Factor Agents"
Viv - "Building effective agents"
Tony Kipkemboi - "From Frameworks to Harnesses"
Anthropic - "Claude Code" Documentation
Cursor - Engineering Blog
Manus - Technical Deep Dive