当所有人都在比较模型分数时，真正决定智能体成败的，往往是模型外面那层“马具”——编排逻辑、工具接口与状态管理。
发生了什么
Hugging Face 上出现了一篇题为《Same Model, Different Harness: CUGA, Hermes, and Deep Agents — When to Pick CUGA?》的讨论，核心命题很直接：在同一个底层模型下，不同的智能体框架（harness）会带来不同的行为与适用场景，文章对比了 CUGA、Hermes 与 Deep Agents 三者，并试图回答“什么时候该选 CUGA”。
需要说明的是，目前公开信息主要是标题与摘要层面，三者的具体实现细节、基准数据并未在片段中展开，因此这里不做超出范围的推断。
为什么重要
过去一年，行业叙事高度集中在模型能力上：参数、上下文长度、推理分数。但实际落地时，开发者很快发现，同一模型接入不同的工具调用协议、不同的规划循环、不同的错误恢复机制，最终任务完成率可以差出明显一截。
“harness”这个词的流行本身就说明问题：它把注意力从“模型会不会”转向“系统怎么让它会”。CUGA、Hermes、Deep Agents 这类框架，本质上是在模型之上叠加一层工程约定——如何拆解任务、如何调用工具、如何在多步执行中保持状态、失败后如何回退。这些约定不是中立的，它们隐含了对任务形态的假设。
因此，“选框架”其实是在选一套与自身业务匹配的执行范式，而不是选一个更时髦的库。
影响与看点
对开发者而言，这类对比的价值在于提醒：评估智能体时，应把 harness 作为独立变量纳入测试，而不是只跑模型 benchmark。同一模型换框架后的回归测试，可能比换模型更能暴露问题。
对框架作者而言，竞争点正在从“支持多少工具”转向“在什么任务分布下更稳”。CUGA 被单独拿出来讨论“何时选它”，暗示它可能在某些场景（如特定类型的任务编排或工具调用模式）有明确定位，而非通用最优解。
值得关注的是，这类讨论是否会推动形成更统一的 harness 评估口径——如果社区能给出跨框架的可比测试，选型就会从经验判断走向工程决策。我的判断是：短期内框架仍会碎片化，但“harness 即产品”的认知会加速扩散，模型厂商与框架层的边界也会随之重新划分。
