事情是从一个让我困惑了很久的现象开始的。
去年我做了几个 AI Agent 的项目，遇到一件很奇怪的事。我跑的是 Claude Opus，按理说是当时最强的模型之一。但任务完成率就是上不去，卡在 40% 多。
然后我看到有人用同款模型，同类任务，跑出了将近 80%。
我当时的第一反应是——他用了什么 prompt trick？还是偷偷微调过？
后来才慢慢意识到，不是模型问题，也不是 prompt 问题。
是系统问题。
我们一直在盯着错误的变量
整个 AI 行业现在有一种惯性思维，就是"模型越大越强，新模型出了赶紧换"。
这不是没有道理。但这个思维有一个隐含假设——其他条件相同的情况下，更好的模型 = 更好的 Agent。
问题在于，这个"其他条件"，根本没有被认真对待过。
我们来想一个类比。你买了一台顶级发动机，然后把它塞进一个没有方向盘、没有变速箱、没有刹车系统的车壳里。
这台车能跑吗？
当然不能。
但我们恰恰就在干这件事。花大量时间关注"发动机"（模型），却几乎不认真设计那个"车壳"——也就是围绕模型构建的整个系统。
这个"车壳"有个专业名字：Harness，也有人叫它 Agent 脚手架，有说叫他马鞍。
我们不妨先把概念理清楚，因为这块真的很容易混
我最开始也搞不清楚 Harness 和 Framework 的区别，网上各种说法，越看越乱。
后来我用一个比喻想明白了：
Framework 是定制家具——它给你一套榫卯接口和木料，你自己决定怎么拼，怎么组，做成什么形状。LangChain 就是这个路子，模块化、灵活，但你得自己做很多决策。
Harness 是宜家家具——它已经替你做好了所有决定。状态怎么管、工具怎么调、出错了怎么恢复，全内置好了。你开箱直接用，但你改不了太多。
Framework（框架） Harness（脚手架）
───────────────── ─────────────────
提供模块和接口 提供完整决策系统
开发者自行组装 开箱即用
灵活度高 灵活度低
类比：定制家具 类比：宜家家具两者没有绝对高下，但重点是——Harness 代表的是一种完整的系统设计哲学，而不仅仅只是工具包。
那么，模型本身能做什么？
要理解为什么 Harness 这么关键，你得先真正想清楚一件事：
一个裸模型，到底能做什么？
答案很简单——它能接收文本，输出文本。
仅此而已。
它不能记住上一次会话发生了什么，不能执行代码，不能读本地文件，不能上网查最新信息，不能在任务失败之后自动重试。
所以问题就来了：我们希望 Agent 做的那些事——写代码、跑测试、调接口、多步推理、自动纠错——这些能力，模型一个都没有。
用户的期望
─────────────────────────────────────────────────
执行代码 / 访问文件 / 记忆状态 / 网络搜索 / 错误恢复
原始模型的能力
─────────────────────────────────────────────────
接收文本输入 → 生成文本输出
↕ 这中间的鸿沟，就是 Harness 要填的Harness 不是锦上添花，它是让模型从"会说话"变成"能干活"的基础设施。
我们来看看Harness 的核心组件，逐个拆开看
我把 Harness 的核心组件一个个拆开想了一遍，发现每一个都有它存在的具体理由。
文件系统
这是最容易被忽略，但其实最关键的一块。
为什么？因为多步任务里，Agent 需要一个地方存"中间结果"。没有持久化工作空间，每一步都是孤立的，你没法真正协作，没法恢复状态。
文件系统是 Agent 的"工作桌"。没有桌子，干什么活都得捧在手上。
Bash 与代码执行
这个我觉得是被严重低估的一个设计。
代码执行不只是"让 Agent 能跑代码"这么简单。更深层的逻辑是：代码执行是一个"元工具"。
意思是，有了代码执行能力，Agent 可以在运行时动态创建新工具。需要解析 CSV？写一段 Python。需要调一个没有现成接口的 API？写一个函数。
这改变了 Agent 的上限。
沙盒环境
这个很直观——代码执行是危险的。你得把它隔离起来。
但沙盒还有另一个价值：可复现性。每次运行都在干净的环境里，排除了"我本地没问题"这种噩梦。
内存与搜索
上下文窗口有限是事实，但知识是无限的。
Harness 的做法是：不把知识塞进模型，而是在需要的时候，把正确的知识注入到上下文里。
Claude Code 里有个 AGENTS.md 文件，就是干这个的——存储项目约定和偏好，在需要的时候喂给模型。这比什么"长上下文窗口"实用多了。
对抗上下文腐烂
这是一个长期任务中必须面对的工程问题。
长任务跑着跑着，上下文窗口会被塞满——大量工具调用的输出、历史对话、错误日志。模型开始"忘事"，开始绕圈，开始犯低级错误。
处理方式有两种思路：压缩历史，或者把工具调用输出卸载到外部存储。这两个方向都有代价，需要根据任务类型做取舍。
渐进式披露——一个反复被验证的关键模式
这是我研究这个话题之后，觉得最有价值的一个设计模式。
不要一次性给模型所有工具和信息。按需给。
听起来很简单，但背后的逻辑很深。
大模型对上下文位置非常敏感。有研究表明，模型对上下文开头和结尾的信息，注意力远高于中间部分。这就是所谓的"U 型曲线"。
模型注意力分布（示意）
高 ██ ██
██ ██
██ ██ ██
低 ██████ ████████████
─────────────────────────────→
开头 结尾
上下文位置如果你一次性给了 50 个工具，大部分工具的描述会落在注意力低谷区。模型要么忽略它们，要么在它们之间乱选。
渐进式披露的做法：当前任务需要什么工具，才给什么工具。
Cursor 就是这么干的。他们用懒加载工具，只在需要时注入相关工具定义。结果呢——Token 使用量削减了 46.9%。
不是 5%，不是 10%。将近一半。
随后，我们来看几个真实案例，这些比我说什么都有说服力
第一个就是Vercel 的案例：删东西比加东西更有效，离了个大谱！
这个案例我觉得是最有冲击力的。
Vercel 的团队发现他们的 Agent 一直跑不通。他们的第一反应是——加功能？优化 prompt？换模型？
然后他们做了一个反直觉的决定：删掉 Agent 80% 的工具。
结果：Agent 从失败到成功。而且 Token 用量下降了，步骤数下降了，延迟也下降了。
为什么会这样？
工具太多，模型会陷入选择困难。每一步它都得在几十个工具里做决策，出错概率指数级上升。工具变少，决策树变简单，模型反而更可靠。
工具数量与任务成功率（简化示意）
成功率
高| ★ 最优点
| / \
| / \
| / \
低|_____/ \____________
────────────────────────────→
0 适量 过多 工具数量Manus 团队总结得更直接："最大的性能提升来自删除东西。"
我们在看看Claude Code 是怎么在玩的
Claude Code 走的是另一条路，但逻辑是自洽的。
它给模型极高的自主权，让模型控制整个循环。工具设计极简——甚至用了一个叫 TodoWrite 的工具，专门让模型记录自己的规划。
为什么要这样？因为规划本身是认知负担。用外部工具把规划显式化，可以释放模型的推理带宽，让它专注于执行。
这是一种很有意思的思路——把"思考"和"执行"分离，分别优化。
Cursor 的精细化路子
Cursor 做了一件很有工程精神的事：为不同的模型精细化调优 Harness。
不是用同一套 Harness 驱动所有模型，而是根据每个模型的特性，调整 Harness 的行为。同时，他们的语义搜索模型用了真实用户会话数据来训练，准确率提升显著。
这说明什么？Harness 本身也是一个需要持续迭代的产品，不是设计完就放着不动的。
我想把整个逻辑再梳理一遍
写到这里，我觉得有必要重新整理一下整个论证链条，确认没有跳步。
原始模型
只能文本输入输出
没有状态、没有工具、没有记忆
↓
Harness 填补鸿沟
文件系统 → 持久化状态
代码执行 → 动态创建工具
沙盒 → 安全可控环境
内存搜索 → 知识按需注入
上下文管理 → 对抗信息腐烂
↓
关键设计原则
渐进式披露 → 只给需要的，不堆砌
简化而非堆砌 → 删东西往往比加东西更有效
↓
最终公式
Agent = Model + Harness
(两者缺一不可，且 Harness 设计质量是关键变量)这条链条是完整的。中间没有跳步。
那以后呢？Harness 会消失吗？
说真的，这是一个我反复想过的问题。
有一种观点是：模型会越来越强，最终会把所有这些能力都内化进去，Harness 就没必要了。
我觉得这个逻辑有问题。
确实，优秀的 Harness 设计原语，会被吸收进下一代模型的训练数据里，成为模型的"原生能力"。这个反馈循环是真实存在的。
但这不意味着 Harness 会消失。它的角色会变——从"弥补模型缺陷"转向"性能优化与可靠性保证"。
就像编程语言越来越高级，但编译器工程师的工作并没有消失一样。
而且从商业角度看，在模型本身日益商品化的今天（各家模型能力越来越接近），Harness 工程设计能力，会成为真正的技术护城河。
这不是玄学，反倒，我认为是结构性优势。
最后说一句话
我们花了太多时间问"用哪个模型"，但其实真正该问的问题是：
"我们到底在造什么？"
不是引擎。是一辆能可靠上路的车。
模型是引擎，Harness 是底盘、传动、刹车、方向盘——所有让车能跑起来的其他一切。
忽略任何一部分，你造出来的都不是车。
