同样的Claude，为什么有人80%成功率，你却只有40%？

你是否遇到过这样的困惑：同样使用Claude Opus，别人的任务完成率接近80%，而自己的却卡在40%多？很多人第一反应是怀疑对方使用了什么特殊的prompt技巧，或者偷偷对模型进行了微调。但经过深入分析，真正的问题其实隐藏在系统设计层面，而非模型本身。

Harness与Framework：容易被混淆的两个概念

当前AI行业存在一种惯性思维：模型越大越强，新模型出来了就赶紧替换。这种思维并非全无道理，但它隐含了一个关键假设——在其他条件相同的情况下，更好的模型等于更好的Agent。问题在于，这个“其他条件”往往被忽视了。我们可以做一个类比：买了一台顶级发动机，然后把它塞进一个没有方向盘、没有变速箱、没有刹车系统的车壳里——这辆车能跑吗？显然不能。而AI行业恰恰在做类似的事：花费大量时间关注“发动机”（模型），却几乎不认真设计那个“车壳”——也就是围绕模型构建的整个系统。

裸模型的能力边界

要理解这个问题，首先需要厘清Harness（脚手架）和Framework（框架）的本质区别。我用一个简单的比喻来解释：Framework就像定制家具——它提供一套模块化接口和组件，开发者可以自由决定如何组装、如何使用，做成什么形状。LangChain就是这种思路的代表，灵活度高，但需要开发者做大量决策。Harness则像宜家家具——已经替你做好了所有决定。状态如何管理、工具如何调用、出错了怎么恢复，这些全部内置完成。开发者开箱直接用，但修改空间有限。两者没有绝对优劣之分，但Harness代表的是一种完整的系统设计哲学，而不仅仅是工具包。

理解Harness的关键价值

要明白Harness为何如此关键，必须先认清一个事实：裸模型到底能做什么？答案很简单——它只能接收文本，输出文本。仅此而已。它不能记住上一次会话发生了什么，不能执行代码，不能读取本地文件，不能上网查询最新信息，不能在任务失败后自动重试。而我们期望Agent做的事情——写代码、跑测试、调接口、多步推理、自动纠错——这些能力模型本身一个都没有。用户期望与原始模型能力之间存在巨大鸿沟，而Harness正是要填补这个鸿沟。Harness不是锦上添花，而是让模型从“会说话”变成“能干活”的基础设施。

Harness的核心组件包括：文件系统（持久化工作空间，让Agent能存储中间结果，而非每一步都是孤立的）、Bash与代码执行（这是一个“元工具”，Agent可以在运行时动态创建新工具）、沙盒环境（隔离代码执行的危险，同时保证可复现性）、内存与搜索（上下文窗口有限，但知识无限，Harness的做法是在需要时把正确的知识注入上下文）、对抗上下文腐烂（长任务中上下文窗口会被塞满，需要压缩历史或卸载到外部存储）。 其中，渐进式披露是一个经过反复验证的关键设计模式——不要一次性给模型所有工具和信息，而是按需提供。研究表明，大模型对上下文开头和结尾的信息注意力远高于中间部分，这就是所谓的“U型曲线”。一次性给50个工具，大部分工具描述会落在注意力低谷区，模型要么忽略它们，要么乱选。Cursor采用懒加载工具的做法，将Token使用量削减了46.9%，接近一半。

如有侵权，请联系删除。