模型与Harness共进化：薄壳还是厚壳？从工具调用评测看工程层设计

上周我给一个开源模型做评测任务不复杂把模型加载到本地然后让它跑一批工具调用题目。同一个模型我分别用了两套方案来跑——一套是我自己临时写的、差不多300行的轻量级调用脚本另一套是套了一圈社区里相当完整的harness框架。结果很有意思也很意外后者的准确率明显高出前者。我一开始怀疑是随机误差反复跑了几轮结论都一样。问题不在模型上出在模型和我之间的那层“壳”上。这层“壳”现在圈子里习惯叫harness。它就是从模型到实际任务中间的那一整层工程包装。这个系列的第十八篇前面聊过模型选型、推理加速、微调、服务化部署这期想集中讨论一个如今躲不开的话题模型与harness之间的“共进化”以及围绕“薄vs厚”展开的、社区里争论了很久的路线问题。无论你是在调prompt、做agent编排还是在设计内部的推理框架这篇文章都值得读完再动手写代码。1. 先厘清概念Harness 不是框架更不是 Agent 的马甲我注意到一个现象很多人一提到harness就把它跟agent、workflow甚至SDK混着用。这其实是个比较大的理解偏差如果不先掰清楚后面关于薄和厚的所有讨论都会黏成一团。1.1 Harness 从评测脚本到工程层的身份转变Harness这个词本来来自测试领域意思是一套“夹具”用来把被测对象固定住、接好输入输出、再判定结果。在大模型出现早期它确实就是这个意思——OpenAI的eval harness、EleutherAI的lm-evaluation-harness都是把一堆评测题目灌给模型收集输出和标准答案比对。那时候的harness很薄本质就是一个循环加一个计分器。但到了最近半年到一年事情起了变化。随着模型开始支持函数调用、结构化输出、多轮上下文管理harness的含义从“评测夹具”扩展成了“模型接入生产环境的工程层”。你会发现社区里开始出现codex harness、deepseek harness这类名字它们做的早就不只是评测了工具调用怎么编排、上下文怎么压缩、输出怎么校验、错误怎么重试全都归它管。harness从一个旁路工具变成了主链路的一部分。这个转变的根源在于模型本身并不直接“做事”是harness决定了一个任务在模型看来是什么样。同一个问题prompt怎么拼、历史怎么截、工具说明怎么给这些看似外围的细节实际上直接决定了模型“看到的世界”。1.2 Harness 与 Agent、Workflow、SDK 的边界为了避免循环定义我通常用一句话来切分这几个概念agent是决策者workflow是流程SDK是工具箱harness是“承载模型运行的环境”。agent负责决定下一步调用哪个工具、何时终止。它可以是模型本身配合一套推理策略来实现。workflow把固定的步骤写成DAG或者顺序链路比如“先检索再生成”。SDK提供API的封装让你能方便地调用模型比如OpenAI SDK。harness在SDK之上、在agent之下负责把模型接到一个具体任务里需要的通用能力——上下文管理、工具注册、输出校验、可观测性。举个例子你在代码里用SDK发起一次模型请求那只完成了5%的工作剩下的95%包括请求之前如何构造上下文、请求之后如何校验输出、出错怎么办这些都是harness层的事情。一个简单的判断法如果你今天换一个模型厂商你的哪些代码需要改动需要改的那些部分就是在你的工程里扮演harness角色的部分。可能是你自己写的也可能来自开源框架——总之它一直都在只是你有没有意识到它的存在。从这个角度看薄vs厚的争论不是在争“要不要harness”而是在争“harness应该承担多少责任、长成什么形态”。2. 薄 Harness 的立场让模型裸奔问题看得见薄派的核心主张听起来很酷模型本身就是智能体你给它一个上下文它就能输出结果。你只需要一个HTTP客户端、一个API key、一个合理的prompt模板完事。多一层封装就多一层黑盒多一层不可控。2.1 薄方案的核心假设与典型形态薄方案背后的假设是模型的非确定性已经够难处理了你的工具层不应该再引入新的不确定性。如果模型返回的内容和你预想的不一样你要能立刻看到原始的响应知道是模型的问题还是你的问题而不是被框架的错误信息绕进去。典型的薄harness在代码层面就是几百行到一千行左右的东西。# 一个极简的 thin harness 核心循环 import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keylocal) def run_once(messages, toolsNone): resp client.chat.completions.create( modellocal-model, messagesmessages, toolstools or [], tool_choiceauto, temperature0, ) return resp.choices[0].message就这些。剩下的prompt模板、历史截断、工具执行和结果回填全部由上层应用自己负责。你要是愿意可以把它压缩到一个文件里跑完就扔。2.2 薄的优势可控性、透明度和调试效率薄方案最大的好处是透明。模型返回的raw message你直接就能看到工具调用的参数解析出错你马上就知道是哪一段正则或者哪一段JSON解析出的问题。调试的时候你能直接从请求体一路追踪到响应体链路极短。第二个好处是灵活。模型厂商一旦发了新能力——比如原生的结构化输出、新的上下文缓存——你可以在半天之内接进去因为你的封装足够少没有框架等着发版。这对做研究和快速试错的人来说是无可替代的优势。第三个很多人忽略的好处是薄方案能让你对模型本身有更准确的体感。用厚框架跑模型你会分不清某些错误是模型的问题还是框架的问题用薄方案模型的真实能力边界暴露得很清楚。我在做模型选型评测时如果没有特殊要求一定会先用薄方案把模型“裸奔”一遍。2.3 薄的代价重复轮子和隐藏的技术债薄方案的问题也很明显——不解决“规模化后的重复劳动”。你在这个项目里写了一套工具调用解析那个项目里又要写一套这个项目里你手动实现了长文本的滑动窗口压缩那个项目里又要再来一遍。每一次都是相似的逻辑但每一遍又不太一样于是到处是微妙的兼容性问题。还有一个更隐蔽的成本团队协作。薄方案意味着所有约定都是隐式的。prompt模板怎么组织、错误码怎么约定、日志打什么字段这些如果全靠个人自觉新成员上手会很痛苦项目之间的复用也特别差。长久下去你的代码库会积累一堆“看起来薄但实际很脆”的客户端。我的经验是薄方案适合单点实验、适合研究者、适合对模型能力边界需要绝对清晰认知的场景。但如果你准备做一个多人维护、长期迭代的agent产品全部用薄方案中期之后的技术债会成倍放大。3. 厚 Harness 的立场把复杂度拦在应用之外厚派的想法正好反过来模型是非确定性的但这不应该由每个应用开发者去硬扛。调用模型、管理上下文、执行工具、校验输出这些通用复杂度应该由一个厚厚的框架层统一解决应用只需要专注业务逻辑。3.1 厚方案解决的问题和它的组件栈一个成熟的厚harness通常包含下面这些组件模型路由层对接多家模型自动重试、限流、fallback。上下文管理层多轮历史记录、截断策略、向量记忆。工具注册与执行层把函数转成JSON Schema执行工具把结果写回对话。输出校验层强制JSON模式、按schema校验、失败时自动修复重试。可观测层全链路trace、token统计、成本核算。你写业务代码时并不直接跟“模型”打交道而是跟harness暴露出来的更高层接口打交道。比如你只需要声明一个tool装饰器harness自动帮你完成从函数到工具描述的转换并处理工具返回结果后与模型的再次交互。3.2 厚的优势开箱即用和工程化保障厚方案最大的价值是“开箱即用”。你把harness配置好注册好工具剩下的多轮交互、工具调用、历史管理它都管了。对产品团队来说这能省掉大量的基建时间。特别是做复杂的工具调用场景时内部细节非常多——解析模型输出的arguments、执行之后把error message回传给模型让ta自己修正这些逻辑在厚框架里已经迭代过很多轮了。另一个优势是标准化。团队成员按照harness约定的方式来加工具、写prompt、记日志出问题时有一套统一的排查路径。项目之间的经验也可以互相迁移。3.3 厚的代价抽象泄露与依赖锁定厚方案的代价一句话概括每多一层抽象排查问题就多绕一环。工具调用出了问题你得先判断是模型输出不规范还是harness的解析有bug还是工具Schema写错了还是上下文管理压缩掉了关键信息。链路一长问题定位的时间成倍增长。更麻烦的是依赖锁定。一个活跃维护的厚harness它的设计总是跟着最主流模型的能力走。但如果你用的是一个小众模型或者公司内部的私有模型harness里那些“为最新模型优化”的特性可能完全不适用。我见过不少团队卡在“harness版本太旧接不了新模型”和“升级harness一堆旧任务行为变了”的两难之间。抽象泄露是没办法完全消除的。到了排查极限时你还是会打开harness的源码去看到底是怎么解析某段输出、怎么处理某类错误的。厚不等于省心只是把省心推迟到了你需要深入研究的那一天。4. 一次真实对比复盘同一个模型在薄与厚两种装备下的表现差距回到文章开头那个评测。我把这次对比的完整过程和数据放出来给大家一个直观参考。4.1 评测场景设置工具调用任务和本地模型我用的是一个开源的中等规模模型本地加载这也呼应了最近很多人关心的“加载本地模型”用法。任务分两组一组是10道单轮工具调用题要求模型根据用户意图选择合适的工具和参数另一组是10道多步推理题需要模型连续调用多个工具并根据中间结果调整后续调用。薄方案是我手写的脚本约300行包含基础的messages管理、工具schemas传入、输出解析和简单的错误重试。厚方案是社区里一个比较主流的开源harness框架配置了相同的模型、相同的工具集合prompt我尽可能调整为等价的形式——当然完全不调整是不现实的因为框架会加自己的system prompt。每组题目我各跑了三轮取平均值尽量降低采样随机性的影响。4.2 对比维度与实测数据主要对比四个维度任务完成正确率、平均响应时延、调试耗时、代码量。数据如下。对比项薄方案自写脚本厚方案开源harness单轮工具调用正确率70%85%多步工具调用正确率50%75%平均响应时延每轮约2.1秒约2.3秒单条错误平均定位耗时约15分钟约40分钟核心代码量约300行约600行配置业务代码正确率方面厚方案明显胜出。单轮工具调用高了15个点多步推理高出一截。响应时延方面迭代成本不小额外封装带来的差异很小但并非没有——主要体现在框架的上下文格式化逻辑上。调试耗时方面薄方案明显更快因为链路短问题一眼就能看出来。这个结果不能简单理解为“厚必然更好”但它确实说明了一件事在工具调用这类对流程一致性要求很高的任务里框架帮你处理好的那些细节——比如工具结果回填的格式、错误信息的组织方式——对模型的表现有实打实的影响。4.3 这次对比给我的三个具体判断第一harness不是透明的。它看起来只是“转发请求”但实际上它改变了模型接收到的上下文形态。prompt里多一句系统提示、少一段工具说明模型的输出质量都会变化。所以你在评测模型时必须明确说明是在哪个harness环境下评测的否则结果不可复现。第二只要工具调用的协议还依赖文本格式化厚harness就有不可替代的价值。当前模型的工具调用本质上是“把工具描述塞进prompt然后让模型吐出一段特定格式的JSON”。这个过程的稳定性受prompt排版影响非常大。厚框架帮你把这些细节打磨好了准确率自然更高。第三对研究者来说薄方案永远是必需品。当我想搞清楚“这个模型到底能不能理解某个工具的规则”时只有薄方案能给我干净、独立、无干扰的答案。厚方案更适合你已经确认模型能做某件事、接下来要规模化稳定运行的时候。5. 共进化的逻辑模型越强Harness 越薄Harness 越好模型越强最开始引发我思考这个问题的并不是薄vs厚的路线之争而是一个更底层的变化模型能力在快速进化这导致harness的“最佳厚度”本身也在变动。反过来harness的设计又在影响着人们能用模型做出什么。这就是所谓的“共进化”。5.1 模型能力上行如何“吃掉”Harness 的厚度先说模型变强如何让harness变薄。最典型的是上下文窗口。以前模型只有4k、8k上下文时harness必须实现复杂的滑动窗口、摘要记忆把对话历史反复压缩。但现在很多模型原生支持几十万甚至上百万token的上下文很多厚框架里维护了半天的“记忆模块”突然变得没必要了。第二个典型是原生工具调用。最早大家是用prompt“教”模型输出JSON来实现工具调用harness要花大量精力在解析和容错上。现在不少模型支持原生的function calling接口你直接传tools数组模型返回结构化的tool_call对象。这直接把harness的解析层变薄了。第三个是结构化输出。以前要让模型输出一个稳定的JSON你需要写很严格的prompt并用Pydantic之类的库反复校验修复。现在一些模型支持json mode或结构化输出约束harness的校验层也跟着变薄。你可以清晰地看到一条主线模型的原生能力越强原本由harness承担的“补偿性复杂度”就越少。这是“薄派”最大的论据——别急着封装因为模型很快会把这个需求吃掉。你费尽心机写出来的上下文压缩模块很可能在下一代模型面前一文不值。5.2 Harness 的工程反哺Context Engineering 与结构化输出如何放大模型潜力但共进化不是单向的。好的harness设计能反过来让模型表现得更好甚至“看起来”像是模型变强了。我印象最深的是context engineering。这个词最近在社区里被频繁提起核心思想是把prompt当成代码来维护用工程手段管理上下文——哪些信息必须放在靠前的位置、哪些历史信息需要保留结构化摘要、工具描述应该用什么措辞、错误信息该怎么回传给模型。同一道题用粗糙的上下文和精心构造的约束上下文去跑模型的成功率差距可以达到20%以上。这看起来是模型的能力差异实际上是harness的工程水平差异。另一个反哺路径是评测闭环。一个设计良好的harness会把每一次模型输出、工具调用、用户反馈都记录下来形成数据闭环。这些数据不仅能帮你定位问题还能沉淀成测评集反过来指导模型微调和prompt迭代。这个意义上harness不只是“使用”模型还在“培养”模型。还有热词里提到的“模型检查器”。我认为它应该被纳入harness的范畴。模型检查器负责在模型输出进入下一步之前验证它是否符合预期schema、是否满足约束条件、是否存在明显的事实错误。它让harness从“拿来即用”进化到“判定是否可用”的层次。这在agent场景里尤其重要——一个错误的结构化输出可能导致整条工具链跑偏。5.3 从“适配模型”到“模型适配 Harness”的螺旋上升共进化的最有趣阶段是当harness的设计开始反过来影响模型训练。以前是模型发布后harness去适配它的接口。现在一些模型在训练阶段就考虑了主流harness的使用方式比如专门针对主流工具调用的prompt格式做了对齐训练让模型在标准框架下的表现更好。这形成了一个明显的螺旋harness定义了“好用的标准”模型随着这个标准去优化。这也是为什么换个框架来测评同一个模型的排名可能会变化——因为模型可能已经在某个harness的语境下被“驯化”过。对工程团队来说这带来一个务实的启示不必盲目追求harness里的所有新功能而应该关注主流的、被广泛适配的那部分能力。越主流的接口模型对齐得越好你的踩坑成本就越低。6. 未来的一段路协议化、原生化与自适应 Harness关于薄和厚的未来我有些带判断性的推测不一定对但至少可以给实践者提供一个参照。6.1 薄与厚不是终点分层演进才是归宿我的判断是薄与厚并不是谁取代谁的关系而是在不同的层级上分层演进。最底层——模型调用本身——会变得原生化、标准化。你能看到MCP这类工具协议正在试图把模型连接外部工具的方式统一。未来这一层一定会更薄、更稳定、更标准化这是所有人都受益的地方。再往上一层——编排层——则会变得更厚。因为单个模型调用的标准化反而释放出空间去做更复杂的编排多模型协作、任务规划、反思循环、人在回路。这些复杂度不会消失它们会从“模型接入”的环节转移到“业务智能”的环节。换句话说该薄的会薄到协议层该厚的会厚到应用层。争论“harness应该薄还是厚”不如问“我的厚度放在了哪一层”。6.2 我对“自适应 Harness”的一个具体设想顺着这个思路我个人最看好的方向是自适应harness——它自己知道该薄的地方薄、该厚的地方厚。设想一个场景harness先探测你接入的模型能力——是否原生支持工具调用、上下文窗口多大、有没有结构化输出约束。如果支持它自动跳过文本解析那一套直接用原生接口如果不支持它才启用兼容层来做prompt解析和结果校验。再比如它根据你的任务复杂度和上下文长度动态决定是否需要启用摘要压缩。这种自适应能力的价值在于它让你不用在“换一个型号就要改一遍harness”上面浪费时间。模型能力在快速迭代今天还不支持的接口下一版可能就支持了。一个会跟着模型能力自动调整厚度的harness本质上是对“共进化”这一现实的最优响应。它还可以和模型检查器结合harness先把模型输出做一次基础校验如果校验失败自动调整下一条prompt的构造方式重新请求而不是把错误直接抛给上层。这种“自我修复”能力会让未来基于模型的系统的稳定性上一个台阶。6.3 给实践者的配置参考最后给几条相对务实的建议都是我踩过坑之后总结的。如果团队里就一两个人在做原型验证或模型评测用薄方案。保持手感保持对模型能力的敏感。如果要做产品化尤其涉及复杂工具调用和多轮交互别犹豫直接上成熟的厚harness。省下的时间足够支付它带来的额外学习成本。无论选薄选厚都一定把评测集和trace日志留好。没有评测集你无法判断升级harness到底是变好了还是变坏了没有trace出问题时你就是盲人摸象。关注模型原生的新能力时刻准备着把harness里的某个自研模块删掉。我自己就曾经花两周写了一套上下文压缩逻辑后来发现新模型的长上下文直接解决了这个问题整个模块变成了废代码。再说回我开头的那个评测它让我彻底改变了看问题的方式以前我关心“模型能不能做好这件事”现在我更关心“我的harness有没有让模型有机会表现好”。这个视角的转换挺重要的。模型能力的天花板确实存在但大多数时候你根本没碰到天花板你只是被自己那层劣质的“壳”给挡住了。调整这层壳让它匹配你当前模型的真实水平再随着模型升级不断迭代它——这大概就是“模型-harness共进化”对普通从业者最实在的一条行动指南。