Agent Harness：让 AI 从「能说」变成「能做」的关键一层
中文 · Mia Builder 手记 · 2026年3月
同一个模型，换个运行环境，benchmark 排名从 Top 30 跳到 Top 5。不是模型变聪明了，是 harness 变好了。
TL;DR
- Agent = Model + Harness。 模型是大脑，harness 是身体。没有身体，大脑再聪明也只能说不能做。
- 人们以为自己在选模型，其实在选 harness。 Claude Code 比 Cursor「好用」，不是模型更强，是 harness 更完整（shell + memory + MCP）。
- Harness 有 5 个核心器官：文件系统、代码执行、记忆、上下文管理、工具扩展。所有 AI 产品都在朝这 5 个方向补齐。
- 行业影响：代码生成变便宜 → 瓶颈从 implementation 转向 review → 判断力成为最稀缺能力。
- 未来方向：Context Engineering > Prompt Engineering。与其调 prompt，不如设计信息流。
- Actionable：不需要等模型升级。给你的 AI 工具配一个 MCP tool、写一个 memory 文件，今天就能提升效率。
一个反直觉的事实
上周 LangChain 发了一组 Terminal Bench 2.0 的数据：Claude Opus 4.6 跑在 Claude Code（Anthropic 官方工具）里排 Top 30，但换一个优化过的 harness——模型完全不变——直接冲到 Top 5。
如果你是工程师，这应该让你停下来想一下。
我们花了两年讨论「哪个模型更强」，但这个数据说明：模型之间的差异，可能还没有运行环境之间的差异大。
这个「运行环境」就是今天要聊的东西——Agent Harness。
什么是 Harness？用你已经知道的东西解释
LangChain 上周给了一个定义：
Agent = Model + Harness
Harness 是除了模型本身之外的一切——系统 prompt、工具描述、文件系统、代码执行环境、记忆系统、上下文管理逻辑。
听起来抽象？你其实每天都在用 harness，只是没意识到。
| 你在用的东西 | 它是什么 |
|---|---|
| ChatGPT 网页版 | 一个极简 harness：对话历史 + 联网搜索 |
| Cursor | 一个 IDE harness：代码库索引 + 文件读写 + terminal |
| Claude Code | 一个完整 harness：文件系统 + shell + MCP 工具 + memory + skill 系统 |
这几个产品背后可以跑同级别的模型，但体验天差地别。差在哪？不是模型，是 harness。
一句话总结：模型是大脑，harness 是身体。大脑再聪明，没有手脚眼睛，也只能说不能做。
或者更直接一点：人们以为自己在选模型，其实在选 harness。
Harness 的 5 个核心器官
为什么说是「身体」？因为 harness 的每个组件都解决一个模型天生做不到的事。
1. 文件系统——让 AI 有「记事本」
没有它：模型只能在 context window 里工作。超过窗口的信息直接消失。你让它改一个 500 行的文件，它只能靠「记忆」，经常改着改着把前面的逻辑搞丢。
有了它：模型可以读文件、写文件、存中间结果。工作不再被 context window 绑死。复杂任务可以拆成多步，每步结果存到磁盘。
更关键的是——文件系统是多 agent 协作的基础。主 agent 写一份计划到文件里，子 agent 读取执行，结果写回另一个文件。没有共享文件系统，多 agent 就是空谈。
2. 代码执行——让 AI 有「手」
没有它：模型只能生成代码给你看。对不对？能不能跑？你得自己复制粘贴到终端试。
有了它：模型生成代码 → 自己执行 → 看到报错 → 自己修 → 再跑。这个写-跑-看-修的循环是 AI 从「代码生成器」变成「工程师」的关键。
OpenAI 上周把这个做到了极致：给 Responses API 配了一个托管的 Linux 容器（Debian 12，预装 6 种语言），模型可以在里面起服务、查数据库、调 API。不再是「帮你写段代码」，而是「帮你在一台电脑上干活」。
3. 记忆系统——让 AI 能「跨对话学习」
没有它：每次新对话，模型都是一张白纸。上次踩过的坑会重踩，纠正过的错误会重犯。
有了它：模型的学习可以持久化。上次你说「不要用 fireEvent，用 user-event」，这个偏好写进 memory，以后每次 session 自动加载。
我自己做了一套自动学习系统：用 hook 自动捕获对话中的纠正（“不是这样，应该…”），存入队列，定期审核后路由到长期记忆。模型不需要「更聪明」，它只需要「不重复犯同一个错」。
LangChain 在 Deep Agents 里用了不同的方案：路径路由——写到 /memories/ 目录的文件自动持久化，其他目录是临时的。Agent 不需要知道后面有两套存储，它只管读写文件，路由是 harness 层透明处理的。
4. 上下文管理——让 AI 不会「越聊越笨」
没有它：Chroma 的研究发现，模型的推理能力随着 context window 填满而显著下降——他们叫这个 “context rot”。一个 200K context 的模型，填到 150K 时表现可能比 50K 时差很多。
有了它：Harness 在合适的时机压缩 context。关键不是「压不压」，而是「什么时候压、保留什么」。
LangChain 这周发了一个有意思的方案：让模型自己决定什么时候压缩。模型会在任务切换、大量新信息涌入前、旧决策被推翻时主动触发压缩。不再靠人设阈值。
5. 工具与搜索——让 AI 能「感知外界」
没有它：模型的知识停在训练截止日。不知道你的代码库长什么样，不知道今天发生了什么，不知道你公司用什么工具链。
有了它：通过 MCP（Model Context Protocol）接入外部工具——浏览器调试、Slack 消息、日历事件、数据库查询。模型从「只能基于训练知识回答」变成「可以实时获取信息再回答」。
上周 Google 发布了 Chrome DevTools MCP——AI agent 可以直接接入你已经打开的浏览器 session，看 console 错误、分析网络请求、检查 DOM 元素。不需要截图粘贴给 AI，它自己看。
为什么很多人说 Claude Code 比 Cursor 好用？
这是 harness 差异的最佳案例。
很多工程师同时用过 Cursor 和 Claude Code，普遍反馈 Claude Code「更聪明」。但如果你把 Claude 模型单独拿出来放在一个聊天框里（比如 claude.ai），体验立刻回到和 ChatGPT 差不多的水平。不是模型变笨了，是 harness 变简了。
Claude Code 和 Cursor 的本质区别不是模型，是设计哲学：
| ChatGPT / Gemini 网页版 | Cursor | Claude Code | |
|---|---|---|---|
| 隐喻 | 聊天助手 | 更好的 IDE | 会写代码的终端 agent |
| 你的角色 | 你问它答 | 你开车，AI 副驾 | 你说目的地，它自己开 |
| 文件系统 | 无（只能看你粘贴的内容） | 读你打开的文件 + 索引代码库 | 完整 filesystem 读写 + glob/grep |
| 代码执行 | Code Interpreter（Python only） | 有限 terminal 集成 | 原生 shell，自己跑、自己看、自己修 |
| 记忆 | 有限的对话 memory | .cursorrules（项目级） | CLAUDE.md + memory 系统 + hooks |
| 上下文管理 | 固定窗口，满了就截断 | 手动 @file, @codebase | 自动读取相关文件，auto-compact |
| 工具扩展 | 联网搜索 + 插件 | IDE 插件 | MCP（无限扩展：Slack、日历、Linear、浏览器…） |
| 验证循环 | 你自己跑代码 | 你自己跑测试 | Agent 自己跑测试 → 看报错 → 修 → 再跑 |
人们感受到的「Claude Code 更好用」，拆开看其实是 4 件事：
- 写-跑-修循环不需要人介入 → 因为 harness 有 shell
- 不需要手动指定上下文 → 因为 harness 自动找相关文件
- 可以做跨系统的事（改代码 + 跑测试 + 查 Slack + 建 PR）→ 因为 harness 有 MCP
- 越用越懂你 → 因为 harness 有 memory
这也是为什么 Cursor 最近在加 agent mode 和 background agent——它在补 harness 的短板，朝「完整身体」的方向走。ChatGPT 加了 Code Interpreter、联网搜索、memory——也是在补 harness。所有产品都在趋同，因为 agent 需要的「身体零件」是确定的。
这对软件开发意味着什么
瓶颈在转移
Harrison Chase（LangChain CEO）上周写了一篇文章，核心观点是：代码生成变便宜后，瓶颈从 implementation 转向 review。
以前：PM 写 PRD → Designer 出图 → Engineer 实现 → 几周 现在：Engineer 直接让 agent 原型化 → review → 迭代 → 几小时
当 implementation 几乎免费时，判断力成为最稀缺的能力——判断该不该做、做得对不对、架构合不合理。
这催生了两种新角色：
- Builder：产品直觉 + agent 流利度 + 设计基础 → 快速交付
- Reviewer：领域专家 + 架构评估 + 快速判断 → 质量把关
Harness 质量直接影响产出质量
同一个工程师，同一个模型：
- 用 ChatGPT 网页版写代码 → 复制粘贴 → 手动调试 → 1 天完成一个功能
- 用配好 harness 的 Claude Code → 自动读代码库 → 自动跑测试 → 自动修 bug → 1 小时完成同样的功能
差异不在人的能力，不在模型的智能，在 harness。
行业现状：三家在做同一件事
有趣的是，LangChain、OpenAI、Anthropic 几乎同时在定义 harness 层，而且方向高度趋同：
| ChatGPT | Gemini | Cursor | LangChain (Deep Agents) | OpenAI (Responses API) | Anthropic (Claude Code) | |
|---|---|---|---|---|---|---|
| 文件系统 | 无（上传文件临时） | Google Drive 集成 | 代码库索引 + 打开的文件 | FilesystemMiddleware | Container + File API | 完整本地文件系统 |
| 代码执行 | Code Interpreter (Python) | Gemini Code Execution | 有限 terminal | Shell + Sandbox | 托管 Linux 容器 (6 语言) | 原生 shell |
| 记忆 | 对话 memory（有限） | 无持久 memory | .cursorrules | CompositeBackend 路径路由 | 容器持久化 + compaction | CLAUDE.md + memory + hooks |
| 上下文管理 | 固定窗口截断 | 固定窗口 | 手动 @file | Autonomous compression | Server-side compaction | /compact + auto-summarization |
| 工具扩展 | 插件 + 联网搜索 | Google 生态内置 | IDE 插件 | MCP + 自定义 middleware | Shell + 网络 allowlist | MCP（无限扩展） |
| 技能格式 | Custom GPTs | Gems | 无 | SKILL.md | SKILL.md (!) | Skill markdown |
从左到右，harness 从简到完整。有趣的是，所有产品都在向右边靠拢——ChatGPT 加了 Code Interpreter 和 memory，Gemini 加了 Deep Research 和代码执行，Cursor 加了 agent mode。
而在开发者框架层，趋同更明显。这些是用来造 agent 的工具：
| LangChain (Deep Agents) | OpenAI (Responses API) | Anthropic (Claude Code) | OpenClaw | |
|---|---|---|---|---|
| 定位 | 通用 agent 框架 | 云端 agent runtime | CLI coding agent | 本地个人 agent |
| 模型支持 | 100+ 模型 | GPT 系列 | Claude 系列 | 任意（Claude/GPT/本地） |
| 文件系统 | 虚拟 FS + CompositeBackend | 托管容器 + File API | 本地文件系统 | 本地文件系统 |
| 代码执行 | Shell + 可插拔 Sandbox | 托管 Linux 容器 (6 语言) | 原生 shell | 原生 shell + 可选沙箱 |
| 记忆 | 路径路由持久化 | 容器持久化 + compaction | CLAUDE.md + memory + hooks | 24/7 持久记忆 |
| 上下文管理 | Autonomous compression | Server-side compaction | /compact + auto-summarization | 持久 context |
| 工具扩展 | MCP + 自定义 middleware | Shell + 网络 allowlist | MCP | 50+ 内置集成 + 自定义 skill |
| 技能格式 | SKILL.md | SKILL.md | Skill markdown | Agent 可自写 skill |
| 独特能力 | Middleware pipeline 可组合 | 并发 shell + 密钥注入 | Hooks 生命周期事件 | 多平台接入 (WhatsApp/Slack/Telegram) |
| 部署 | LangGraph Platform / 自托管 | OpenAI 云 | 本地 CLI | 本地优先 + 可选云 runner |
几个有趣的观察：
- 技能格式收敛 — LangChain、OpenAI、Anthropic 都收敛到 SKILL.md 格式，OpenClaw 更进一步让 agent 自己写 skill
- 本地 vs 云的分化 — OpenAI 走全托管云端路线，Claude Code 和 OpenClaw 走本地优先，LangChain 两边都支持
- 记忆是最大差异点 — 每家的实现完全不同（路径路由 / 容器持久化 / 文件 + hooks / 24/7 always-on），说明行业还没找到最优解
- 所有框架都在朝同一个方向走 — 文件系统 + 代码执行 + 记忆 + 上下文管理 + 工具扩展，五个器官一个不少
通用 Harness 是标准身体，但你的工作需要定制身体
框架对比表看完，你可能会想：既然 OpenClaw / Claude Code 这些框架已经做了 harness，为什么工程师还需要自己配？
因为出厂 harness 是通用的，但你的工作场景不是。
拿 OpenClaw 举例。它出厂就有 50+ 集成、持久记忆、shell 执行——身体很完整。但它不知道：
- 你每天早上需要从 Linear + Slack + Calendar + GitHub 并行拉数据生成今日计划
- 你的 PR 需要 rollback plan，不是所有团队都要
- 你 review 代码时要检查
userEvent.setup()在每个itblock 里而不是beforeEach - 你写完代码后要自动跑 lint + typecheck + test 三件套才能 commit
这些是你的工作流的肌肉记忆。通用 harness 没有这些肌肉。
所以你要给它加 skill——告诉它你的团队怎么工作、你的标准是什么、你的流程怎么走。我给自己的 Claude Code 加了：
- 4 阶段 skill chain：design doc → implementation plan → execution log → code review，每个阶段有输入验证和完成检查
- 自动学习 hooks：自动捕获我的纠正（“不是这样，应该…”），存入队列，审核后变成长期记忆
- 每日计划 skill：并行拉 7 个数据源，AI 排序，生成带番茄钟估时的今日计划
加完之后，同一个 Claude Code，体验完全不同——它变成了一个懂我的工作方式、不会重复犯错、能按我的流程自动走完全程的 agent。
通用 harness 解决 80% 的问题。剩下 20% 的定制，是拉开效率差距的地方。
未来会怎样
短期（6 个月）：Context Engineering 成为核心技能
Karpathy 最近在推的概念——Context Engineering——精确控制模型每一步看到什么信息。这不是 prompt engineering 的升级版，而是 harness engineering 的核心子问题。
与其花时间调 prompt，不如花时间设计：什么信息在什么时候进入 context。
中期（1-2 年）：Model-Harness 耦合问题
LangChain 的文章里提到一个隐忧：OpenAI 的 Codex 在换了一个 tool（apply_patch）之后性能下降了。原因是模型在训练时和 harness 绑定了——它学会了「用这个特定的 tool 改代码」，换一个 tool 就不会用了。
这意味着：最好的 harness 不一定是模型训练时配对的那个。Harness 工程师需要独立于模型厂商思考最优方案。
长期：Agent 自主改进 Harness
现在 harness 是人设计的。未来，agent 可以分析自己的执行 trace，发现 harness 层的瓶颈，自己提出改进。LangChain 已经把这列为活跃研究方向之一。
我自己做了一个小规模的尝试：用 hook 自动捕获 agent 的失败模式（哪个命令经常失败、哪种纠正反复出现），聚合后生成 harness 改进建议。效果不错——agent 不需要更聪明，只需要环境更适合它。
给工程师的 Takeaway
-
你已经在用 harness，只是可能没意识到。 Cursor、Claude Code、Copilot 的体验差异，90% 来自 harness 设计，不是模型差异。
-
Harness Engineering 是一个真实的技能。 了解 harness 的 5 个组件、知道怎么配置和优化它们，会让你的 AI 工作效率比同事高一个量级。
-
不要只关注模型升级。 下次 GPT-6 或 Claude 5 发布时，问自己：我的 harness 准备好利用新能力了吗？
-
Context Engineering > Prompt Engineering。 与其花时间写更好的 prompt，不如花时间设计更好的信息流——让模型在每一步都拿到它需要的、且仅是它需要的信息。
-
动手试。 给 Claude Code 配一个 MCP tool、写一个 hook、建一个 memory 文件。Harness 的好处是：改进是可叠加的，每次小改进都会在未来的每次使用中生效。
金句收藏
留几句可以直接发朋友圈或者贴在显示器上的：
“Agent = Model + Harness。模型是大脑，harness 是身体。” — LangChain
“人们以为自己在选模型，其实在选 harness。”
“同一个模型，换个 harness，Top 30 变 Top 5。” — Terminal Bench 2.0
“代码生成变便宜后，瓶颈从 implementation 转向 review。判断力成为最稀缺的能力。” — Harrison Chase
“Context Engineering > Prompt Engineering。与其调 prompt，不如设计信息流。” — Andrej Karpathy
“Agent 不需要更聪明，只需要环境更适合它。”
“所有产品都在朝同一个方向走，因为 agent 需要的身体零件是确定的。”
我是 Mia，前 Google 工程师，现在在硅谷用碎片时间做 AI 产品。这篇文章来自我给自己的 AI 工作环境做 harness engineering 的真实经历——搭了一套自动学习系统和 4 阶段工作流 skill chain，然后发现 LangChain 和 OpenAI 上周发的文章在讲同一件事。有时候自己踩着踩着坑就踩到了行业前沿。