从 Agent = Model + Harness 说起：重新看看 Cursor、Claude Code 和 Codex区别

最近在关注 DeepSeek 的 Code Agent 相关进展时，我注意到一个很有意思的公式：

Agent = Model + Harness

DeepSeek 在 Code Agent 的 benchmark 中明确提到了自己的 Harness，同时官方也在提供将 DeepSeek 模型接入 Claude Code、Pi 等不同 Coding Agent / Coding Harness 的方式。

这让我重新思考了一个问题：

我们每天使用 Cursor、Claude Code、Codex 时，真正使用的到底是什么？

过去我们聊 AI 编程工具，最关心的问题通常是：

它用的模型是 Claude 还是 GPT？
模型版本是什么？
benchmark 排名多少？
上下文窗口多大？
推理能力强不强？

这些当然重要。但如果你实际使用过不同的 AI Coding 工具，大概率会碰到一个很反直觉的现象：

明明底层使用的是同一个模型，换一个工具之后，怎么感觉像换了一个模型？

有时候一个工具里的 Claude 很聪明，能自己找到问题、修改代码、执行测试。

换一个工具，还是 Claude，却像突然"降智"了。

为什么？

一个很有解释力的框架是：

复制代码

Agent ≈ Model + Harness

当然，这不是一个严格的数学公式。

它更像是一把理解 Agent 的钥匙。

而如果继续把这个公式拆下去，我们会发现：

今天 AI Coding 产品之间的竞争，早已经不只是模型之间的竞争。

一、先从一个最简单的比喻开始：Model 是大脑

假设我们把一个 AI Agent 看成一个人。

那么：

复制代码

Model ≈ 大脑

Model 主要负责：

理解问题
推理
判断
规划
生成代码
决定下一步做什么

比如我告诉一个 Coding Agent：

登录页面偶尔会重复请求两次接口，帮我排查一下。

Model 可能经过推理后认为：

复制代码

可能是组件重复挂载
↓
也可能是 useEffect / watch 触发两次
↓
需要先找到登录页面
↓
再找到对应请求函数
↓
查看请求调用链

这些"思考"主要发生在模型里。所以把 Model 理解成大脑，非常合适。

但另一个问题也来了：

二、只有一个大脑，能写代码吗？

想象一下：你有一个智商极高的程序员。但是：

他看不到你的代码
不能打开文件
不能搜索项目
不能修改代码
不能运行命令
看不到 Terminal
不能运行测试
不知道 Git Diff
甚至不知道你的项目目录在哪里

你问他：

帮我修一下这个 bug。

他能怎么办？只能根据你告诉他的几句话进行猜测。这其实就是早期 ChatGPT 写代码时的状态：

复制代码

你复制代码
↓
粘贴进 ChatGPT
↓
模型分析
↓
模型给你代码
↓
你复制回来
↓
自己运行
↓
发现报错
↓
再把错误粘回去

仔细看，这里面其实存在一个非常重要的东西：

你。

你实际上充当了模型的"身体"。

是你在：

复制代码

读文件
↓
复制代码
↓
提供 Context
↓
执行模型给出的代码
↓
运行测试
↓
复制错误
↓
重新反馈给模型

换句话说：

早期的人类，其实就是大模型的 Harness。

而 Coding Agent 做的一件非常重要的事情，就是把原本由人完成的这部分工作给自动化了。

三、Harness：给大脑装上一副身体

于是，我们就可以继续这个类比：

ini 复制代码

Model
=
大脑

那么 Harness 是什么？

我更愿意把它理解成一个组合：

身体 + 感官 + 神经系统。

为什么不只是"手脚"？

因为 Harness 做的不仅仅是执行动作。它还要负责把：

复制代码

感知
↓
思考
↓
行动
↓
反馈

真正连接起来。

可以做一个简单映射：

人	AI Agent
大脑	Model
眼睛、耳朵	Context 获取
注意力	Context Engineering
手脚	Tools
神经系统	Harness
工具箱	MCP / Skills / CLI
工作环境	IDE / Terminal / Repo / Sandbox

比如一个 Coding Agent 修 bug，大概会经历：

markdown 复制代码

用户提出问题
        ↓
读取项目
        ↓
搜索相关代码
        ↓
把相关 Context 交给 Model
        ↓
Model 分析
        ↓
决定修改文件
        ↓
Harness 执行修改
        ↓
运行测试
        ↓
获取错误信息
        ↓
重新交给 Model
        ↓
Model 再次分析
        ↓
继续修改

这时候，一个真正的 Agent Loop 出现了：

erlang 复制代码

Observe
   ↓
Think
   ↓
Act
   ↓
Observe
   ↓
Think
   ↓
Act
   ↓
...

所以如果让我用一句话解释 Model 和 Harness 的关系，我会这么表述：

Model 负责产生智能，Harness 负责兑现智能。

四、Harness 并不等于 Tool Calling

这里特别容易产生一个误区：很多人看到 Agent 可以：

调用 Terminal
读取文件
修改代码
调用 MCP

于是认为：

ini 复制代码

Harness = Tools

这其实并不准确。

Tool 更像锤子、螺丝刀、电钻。

Harness 解决的是：

什么时候拿锤子？拿哪把锤子？怎么使用？使用以后怎么判断结果？失败以后下一步怎么办？

比如两个 Agent 都拥有：

sql 复制代码

read_file
write_file
search
terminal

它们拥有完全相同的工具。

但面对：

帮我解决这个项目里的重复请求问题。

Agent A 可能：

复制代码

读取当前文件
↓
猜测原因
↓
直接修改

Agent B 可能：

bash 复制代码

搜索请求方法
↓
查找引用
↓
找到组件调用链
↓
读取相关 hook
↓
查看生命周期
↓
分析原因
↓
修改代码
↓
运行 lint
↓
运行 test
↓
检查错误
↓
继续修复

工具一样。最终效果却可能完全不同。区别就在于：

diff 复制代码

工具调度
+
上下文组织
+
执行策略
+
反馈机制
+
Agent Loop

也就是说：

Tool 是能力，Harness 是如何组织这些能力完成工作的系统。

五、还有一个经常被低估的东西：Context Engineering

理解 Harness 之后，还要引入另外一个非常重要的概念：

Context Engineering。

这是我认为理解 AI Coding Agent 时，最容易被低估的一层。

假设有一个大型前端项目：

css 复制代码

src/
├── api/
├── components/
├── hooks/
├── pages/
├── router/
├── store/
├── utils/
└── ...

几十万行代码。

用户只说一句：

登录以后为什么会重复请求用户信息？

真正的问题不是：

模型会不会写代码？

而是：

应该给模型看哪些代码？

整个仓库可能有几十万甚至几百万行。但真正和这个 bug 有关系的，也许只有：

复制代码

login.vue
useAuth.ts
userStore.ts
userApi.ts
routerGuard.ts

如果把整个项目全部扔给模型：

复制代码

信息过载
↓
噪声增加
↓
注意力被稀释
↓
推理质量下降

如果只给当前文件：

复制代码

信息不足
↓
看不到调用链
↓
模型只能猜

所以真正困难的问题变成了：

如何在有限的 Context Budget 中，把最有价值的信息交给模型？

这就是 Context Engineering。

六、如果 Model 是大脑，Context Engineering 就是注意力

还是继续人的比喻。你坐在工位上修 bug。你周围可能有：

几百万行代码
几百份文档
几万个 Git Commit
几千个 Issue
Terminal 日志
浏览器 Console
数据库
API 文档

理论上这些都是信息。但你真正解决问题时，不可能同时关注全部内容。

你会主动选择：

复制代码

这个文件重要
↓
这个调用链值得看
↓
这个日志可能有关
↓
这三个文件暂时不用看

这就是人的"注意力管理"。

AI Agent 同样需要。

于是：

ini 复制代码

Model
=
你有多聪明

Context Engineering
=
你现在正在看什么

一个非常强的程序员，如果拿错了代码，同样可能做出错误判断。

一个非常强的模型，如果拿到了错误的 Context，也一样如此。

这也是为什么很多时候：

你感觉某个 Coding Agent "更聪明"，未必完全是 Model 更聪明，也可能是它更擅长给 Model 找到正确的信息。

七、为什么我们经常说 Cursor "工程化做得好"？

说到这里，就可以重新理解一句经常出现的话：

Cursor 工程化做得很好。

以前听到这句话，我其实觉得有点模糊。

什么叫"工程化好"？只是 UI 好看吗？只是把 Claude 接进 IDE 吗？

如果按照前面的框架拆开，"工程化"其实至少包含几层。

复制代码

AI Coding Product
│
├── Model
│
├── Context Engineering
│
├── Harness
│
├── Environment Integration
│
└── Product Engineering

继续展开：

javascript 复制代码

Context Engineering
│
├── Codebase Index
├── Search
├── Symbol / 文件定位
├── Context 选择
└── Context 压缩


Harness
│
├── Agent Loop
├── Tool Calling
├── Read / Write
├── Terminal
├── Test
├── Git
└── Feedback


Environment Integration
│
├── Editor
├── 当前文件
├── 光标
├── Selection
├── Diff
└── Terminal


Product Engineering
│
├── UX
├── 延迟
├── 稳定性
├── 权限控制
└── Workflow

这样一拆，"工程化"三个字终于具体了。

以 Cursor 为例。

Cursor 官方文档目前明确把 Agent 定义为能够独立完成复杂 Coding Task、运行 Terminal 命令并修改代码的助手；它还会对 Codebase 建立索引，让 Agent 可以从代码仓库中获取 Context，同时 Terminal、Sandbox 等能力也直接被整合进 Agent 工作流。

于是一个问题：

帮我看看这个组件为什么重复请求。

对于一个深度集成 IDE 的 Agent 来说，它天然可能获得：

diff 复制代码

当前项目
+
当前文件
+
代码索引
+
相关文件
+
Terminal
+
Diff
+
Git

这时候 Model 不再是一个"坐在聊天室里的聪明人"。而是一个：

已经坐在你工位上，并且拥有开发环境的程序员。

这就是 Harness 和工程化带来的变化。

八、同一个模型，为什么在不同工具里像两个模型？

现在我们可以回答文章开头的问题了。

假设两个产品底层使用完全相同的 Model：

css 复制代码

                同一个 Model
                     │
              ┌──────┴──────┐
              ↓             ↓
           Product A     Product B

Product A：

diff 复制代码

弱 Context
+
简单文件读取
+
简单 Tool Calling
+
弱 Agent Loop

Product B：

diff 复制代码

代码索引
+
精准 Context
+
完善工具链
+
Terminal
+
Test
+
Git
+
成熟 Agent Loop

最后的用户感受很可能是：

Product B 的模型明显更聪明。

但实际上：

ini 复制代码

Model
=
一样

真正不同的是：

复制代码

Model 周围的系统

这也是为什么单纯通过"底层模型是谁"来判断一个 AI Coding 产品，已经越来越不够用也不太准了。

九、重新看 Claude Code：它卖的不只是 Claude

Claude Code 是另外一个非常典型的例子。

如果只看名字，很容易认为：

ini 复制代码

Claude Code
=
Claude Model + Terminal UI

但现在的 Claude Code 显然已经远远超过这个范围。

Anthropic 官方文档展示的能力包括：

文件读取、搜索、编辑
Bash
CLAUDE.md
Skills
Hooks
MCP
Subagents
Code Intelligence
Memory
Permissions

Claude Code 的扩展体系甚至可以让 Hook 在生命周期事件中执行 Shell、HTTP 请求、LLM 判断或者启动 Subagent。

如果套用前面的模型：

css 复制代码

Claude Model
        ↓
Claude Code Harness
        ↓
Read / Grep / Edit / Bash
        ↓
CLAUDE.md / Memory
        ↓
Skills / Hooks
        ↓
MCP
        ↓
Subagents
        ↓
开发环境

我们会发现：

Claude Code 真正的产品并不是 Claude 模型本身，而是一套围绕 Claude 构建的软件工程执行环境。

甚至今天 Claude Code 已经不仅存在于 Terminal，它还有 IDE、Desktop 等形态，而 Desktop 和 CLI 使用的是同一套底层 engine。

所以真正值得关注的不是：

Claude Code 有没有某个按钮。

而是：

Anthropic 正在怎样设计 Claude 的工作环境。

十、再看 Codex：这里甚至直接出现了"Codex Harness"

如果说前面的 Harness 还比较抽象，那么 Codex 会更加直接。

OpenAI 官方已经明确使用：

Codex harness

这个说法。

OpenAI 对 Codex Agent Loop 的介绍中，把 Harness 描述为负责协调：

sql 复制代码

User
↓
Model
↓
Tools

之间交互和执行逻辑的核心系统。

同时 Codex Harness 还涉及 thread 生命周期、持久化、配置、认证等 Agent Runtime 能力。

于是 Codex 可以拆成：

markdown 复制代码

GPT 系列模型
      ↓
Codex Harness
      ↓
Agent Loop
      ↓
Tools
      ↓
Terminal / Files / Git
      ↓
Sandbox
      ↓
AGENTS.md
      ↓
Skills
      ↓
Subagents

Codex 还会在执行任务前读取 AGENTS.md，通过项目级规则获得持续 Context；Skills 则可以把 Instructions、Resources 和 Scripts 封装成可复用工作流。

从这个角度看：

复制代码

GPT Model
≠
Codex

更准确应该是：

ini 复制代码

Model
+
Codex Harness
=
Codex Agent

再往外：

ini 复制代码

Codex Agent
+
CLI / IDE / App / Cloud
=
Codex 产品体验

特别是 Codex App，现在甚至加入了并行 Agent、Worktree、长任务等能力。

这时候 Coding Agent 已经开始从：

"AI 帮我写代码"

走向：

"我管理多个 AI 软件工程师工作"。

十一、所以，Cursor、Claude Code、Codex，真正的区别到底在哪？

到这里，我们就不应该再用简单的：

复制代码

谁最好？

来比较它们。更有意义的问题应该是：

vbnet 复制代码

它使用什么 Model？

它如何构造 Context？

它有什么 Tools？

它如何运行 Agent Loop？

它和开发环境结合多深？

它如何管理权限？

它如何验证结果？

它如何保存项目规则？

它如何处理长任务？

它如何支持多个 Agent？

可以形成这样一套判断框架：

维度	要解决的问题
Model	大脑有多聪明？
Context	大脑现在看到了什么？
Context Engineering	有没有看到真正重要的信息？
Tools	它能做什么？
Harness	它如何把思考与行动组织成闭环？
Environment	它在哪工作？
Product Engineering	整套系统是否稳定、流畅、可控？

而 Cursor、Claude Code、Codex，其实是在用不同的产品路径回答这些问题。

粗略地说：

Cursor

非常强调：

diff 复制代码

Editor
+
Codebase
+
Context
+
Agent

它最大的特点之一，是 AI 与日常 IDE 工作流之间距离很短。

Claude Code

非常适合从：

diff 复制代码

Model
+
Terminal / Filesystem
+
可扩展 Harness

这个角度理解。

Skills、Hooks、MCP、Subagents 等能力，让它越来越像一个可以不断扩展的软件工程 Agent Runtime。

Codex

OpenAI 则正在非常明确地建设：

diff 复制代码

Model
+
Codex Harness
+
Sandbox
+
Skills
+
Agent Runtime
+
Multi-Agent

尤其随着 Codex App 和并行 Agent 工作流出现，它越来越不像一个单纯 Coding Assistant，而更像 Agent 工作平台。

需要说明的是，这些产品都在快速变化，上面的划分更多是在描述它们当前比较鲜明的产品路线，而不是给它们贴永久标签。

十二、Model 决定上限，Harness 决定智能能兑现多少

理解这些之后，我越来越喜欢这样描述 Model 和 Harness 的关系：

Model 决定智能的上限，Harness 决定这些智能能被兑现多少。

比如做一个纯粹用于理解的假设：

复制代码

Model：95
Harness：50

最终产品不一定很好用。

反过来：

复制代码

Model：85
Harness：95

真实工程体验甚至可能更好。

当然，这并不是一个可以真正量化的数学公式。但它揭示了一个重要事实：

模型能力并不会自动转化为产品能力。

中间还有很长的一条链路：

复制代码

Model
↓
Context
↓
Planning
↓
Tool Calling
↓
Execution
↓
Feedback
↓
Validation
↓
Product UX

任何一环做不好，都可能浪费模型本身的能力和产出效果。

十三、这也解释了为什么"换模型"不一定能解决 Agent 的问题

以前一个 AI 工具不好用，我们第一反应经常是：

换个更强的模型。

但以后可能要多问一句：

真的是模型的问题吗？

比如一个 Agent 经常修改错文件。可能不是 Model 不够聪明，而是：

sql 复制代码

Search 不好

一个 Agent 经常忽略项目规范。可能是：

复制代码

Project Context 没有正确注入

一个 Agent 修好一个 bug，又引入三个 bug。可能是：

vbnet 复制代码

没有好的 Test / Validation Loop

一个 Agent 长任务越做越糊涂。可能是：

复制代码

Context Management 出了问题

Agent 总是在不该执行命令的时候执行。可能是：

复制代码

Permission / Harness Policy 不合理

所以我们排查 AI Agent，就像排查一个软件系统。

不能什么问题都归结成：

复制代码

LLM 不够强！！

十四、未来 Coding Agent 的竞争，很可能是系统能力的竞争

过去两年，我们关注最多的是模型：

erlang 复制代码

GPT
Claude
Gemini
DeepSeek
...

这是因为大模型能力一直在快速提升。

但随着模型能力逐渐越过"能写代码"这条线，下一阶段真正困难的问题开始变成：

怎么让它稳定地完成真实的软件工程任务？

真实的软件工程不是 LeetCode。

也不是根据一句 Prompt 生成一个函数。

它是：

rust 复制代码

读需求
↓
理解旧代码
↓
找到相关模块
↓
理解架构
↓
修改多个文件
↓
运行程序
↓
发现错误
↓
Debug
↓
跑测试
↓
检查 Diff
↓
继续修改

这天然就是一个系统问题。

于是 Coding Agent 的竞争，也会越来越像：

复制代码

Model
×
Harness
×
Context Engineering
×
Environment
×
Product Engineering

这里我故意用了乘号。因为任何一项太差，都可能拖垮最终体验。

十五、作为程序员，我们应该怎么重新看 AI Coding 工具？

以后再看到一个新的 AI Coding 产品，我觉得可以先不要急着问：

它用的什么模型？

而是连续问这样几个问题：

1. Model

它的大脑是谁？

推理、Coding、长上下文能力如何？

2. Context

它到底能看到什么？

只是当前文件？

还是整个 Repository？

有没有 Search、Index、Symbol、Memory？

3. Harness

模型如何调用工具？

如何修改文件？

如何执行 Terminal？

如何获得反馈？

失败之后会不会继续？

4. Environment

它工作在哪里？

IDE？

Terminal？

Cloud Sandbox？

Git Worktree？

5. Product Engineering

这些能力是否真正稳定？

权限是否可控？

Diff 是否容易 Review？

延迟是否可以接受？

工作流是否顺手？

这样看完，你才能真正判断：

这个工具为什么好用。

而不是停留在：

"它用了某某最新模型，所以应该很强。"

写在最后

第一次接触大模型时，我觉得最重要的是 Model。

后来使用 Cursor，我开始意识到 Context 很重要。

再后来使用各种 Coding Agent，我越来越觉得：

Model 只是整个 Agent 系统中的一个核心组件。

当然，它仍然可能是最重要的组件，就像人的大脑一样！！

但一个再聪明的大脑，也需要：

diff 复制代码

眼睛
+
耳朵
+
注意力
+
神经系统
+
手脚
+
工具
+
工作环境

才能真正做成事情。

所以，如果让我用两句话总结全文，我会这样说：

模型负责产生智能，Harness 负责兑现智能。

以及：

过去我们选择 AI 编程工具，最先问的是"它用的是什么模型？"；以后更值得问的问题可能是："它是怎么驾驭这个模型的？"

当我们开始问第二个问题时，也许才算真正开始理解 AI Agent。

注：AI Coding 产品迭代速度非常快，本文涉及 Cursor、Claude Code、Codex 的具体能力基于 2026 年 8 月公开官方资料。本文重点不是比较某个版本的功能多少，而是借这些产品建立一套理解 Coding Agent 的通用框架。