同一模型从30%到81%：3种Agent Harness怎么选

2026 年 11 月 3 日，IBM Research 在 Hugging Face 发布了 CUGA、Hermes 与 Deep Agents 的对照实验。三者使用同一个开放权重模型 GLM-5.3-flash，在 AppWorld 的 90 项任务上完成任务数从 30.0% 到 81.1% 不等。现在值得看，不只是多了一个高分框架，而是它把一个常被忽略的问题摆到了台面上：Agent 的实际表现不仅由模型决定，也由模型外面的执行系统决定。

下文中的实验数据均来自官方原文；涉及“更适合谁”的判断，是我根据其定位和公开设置作出的推算，不是 IBM 的统一结论。本文先把 Harness 说成人话：它是包在模型外面的代码、工具、提示、流程与检查机制，决定模型怎样看见任务、怎样调用工具、怎样纠错，以及何时停止。

同一模型，为什么能跑出三种成绩

IBM 的实验固定了模型，只替换 Harness。三个方案都运行 GLM-5.3-flash，任务来自 AppWorld：一个包含 9 个应用、457 个 API 的多步骤操作基准，涉及邮件、支付和文件存储等场景。测试包含 30 个场景，每个场景有 3 个变体，共 90 项任务；每项任务只尝试一次，全部使用 Harbor 评估框架。

这里的控制变量很关键：如果不同方案分别使用不同模型，最终很难判断差距来自模型推理能力，还是来自工具筛选、上下文管理、错误恢复等工程设计。IBM 把模型、任务和评估框架固定后，结果如下：

完整场景比例比单看任务比例更能暴露稳定性。只有一个场景里的三个变体全部通过，才计入完整场景通过数；换句话说，它奖励的是重复完成同类任务时的稳定性，而不是偶然成功一次。结果显示，CUGA 在这一指标上同样领先。

但这不是“CUGA 全面碾压”的榜单。IBM 明确列出了三项限制：样本只有 90 项任务，且集中在一个基准；三个方案的配置并不完全相同；实验没有启用企业策略，因此没有测量规则执行能力。换句话说，这次测试能说明不同 Harness 对同一类多应用 API 任务的设计差异，却不能直接证明任何框架在所有场景都更好。

三种 Harness，其实解决不同问题

CUGA 是 IBM 开源的 ConfigUrable Generalist Agent，面向企业自动化。它的重点不是单纯陪人聊天，而是让 Agent 在业务系统中执行受约束的流程，并可以部署在自己的环境，包括主权云和隔离网络。

Hermes 来自 Nous Research，定位是常驻式个人助理。IBM 将它描述为适合 always-on personal assistant，也就是长期在线、随时响应的个人助手。它和 Deep Agents 都有各自擅长的任务，因此原实验同时拿它们作参照，并不是把后两者当成不成熟产品。

Deep Agents 则来自 LangChain，面向较长的多步骤任务，例如研究工作。官方给它配置的 AppWorld 工具通过 MCP（Model Context Protocol，一种让模型以统一方式连接工具和数据的协议）提供，并启用了工具选择、上下文摘要、待办列表、重试与调用次数限制等 LangChain 中间件。这里的“中间件”可以理解为夹在模型与工具之间的加工层，负责整理信息、控制流程和处理异常。

三者最直观的区别，不是能力强弱，而是默认目标不同：

因此，官方给出这次分数后，明确反对把问题简化成“哪个 Harness 最好”。更合理的问题是：哪个 Harness 的默认机制与你的工作形态一致？

差距来自哪里：执行循环里的检查点

CUGA 在实验中并非简单地给同一个 Agent 换一套提示词。它采用一条固定循环：准备任务、调用模型、执行动作，然后继续迭代。每个步骤只获得当前应用相关的工具和少量共享工具，而不是一次塞入全部 469 个工具；需要其他工具时，再通过工具搜索补进来。

它还在执行前后设置了两个检查点。执行前，验证环节会检查准备修改数据的代码块；执行后，自动反思机制检查结果，决定是否继续。CUGA 还支持 CodeAct，即让模型编写 Python 代码调用应用 API，并使用带时间限制的受限沙箱运行。

官方原文中还有一句值得单独保留：Harness 拥有的每一步，都是一个执行点。它把差异归因于流程设计，而不是藏在一句更聪明的系统提示里。

这里还有一个容易被忽略的口径问题。实验表写的是 469 个工具，而 AppWorld 本身被描述为包含 457 个 API；前者对应 Deep Agents 实际配置的可用工具数量，后者是基准中的应用接口规模，两者不能直接当作同一项指标比较。

企业真正缺的，可能不是更高完成率

对于普通用户，81.1% 看起来像“更聪明”；对需要接入 CRM、支付或内部系统的企业，更重要的问题是：模型会不会在不确定时越权？能否在本地边界内运行？出了问题能否留下可检查的执行轨迹？

这正是 CUGA 想补的部分。IBM 表示，CUGA 允许使用开放权重模型或托管模型，并可部署在企业自己的环境。官方还特别强调，执行规则属于 Harness 的职责：即使模型作出某个选择，业务约束仍应被系统执行。

不过，官方原文也明确说，本次 AppWorld 对比没有使用策略，因此没有测量 policy enforcement，也就是“策略约束的实际执行效果”。这意味着一个重要边界：当前实验可以支持“CUGA 更适合企业流程”的方向性判断，却不能证明它已经证明自己在真实企业规则上的可靠性。相关细节可继续查看 IBM Research 的 CUGA Harness 原文。

选型别只看分数：先按工作形态分类

如果你的任务是个人常驻助理、跨消息渠道响应，或长期保持上下文，Hermes 的默认定位更贴近需求；如果任务是研究、资料整理和较长的多步骤流程，Deep Agents 的摘要、待办及重试机制更直接；如果任务会修改业务数据，并且要求执行前检查、本地部署或隔离环境，CUGA 值得优先试用。

下面不是官方安装命令，而是一份根据公开定位整理的决策清单，方便团队先做初筛：

agent_selection:
  always_on_personal_assistant:
    candidates: [Hermes]
    reasons:
      - 面向常驻式个人助理
      - 适合持续在线与多渠道响应

  long_running_research:
    candidates: [DeepAgents]
    reasons:
      - 支持上下文摘要与待办列表
      - 提供重试和调用次数限制

  enterprise_business_execution:
    candidates: [CUGA]
    reasons:
      - 支持执行前验证与执行后反思
      - 可在自有环境或隔离网络部署
    verify_before_adoption:
      - 策略执行是否满足本企业要求
      - 真实业务数据上的任务完成率

这里最大的反方观点是：这次比较并非严格控制了所有变量。CUGA 使用专门配置的 AppWorld 流程，Hermes 和 Deep Agents 则采用各自的工具与中间件设置。国际社区的葡萄牙语交叉报道也重复列出了同样三项限制；另一份实验结果摘要则确认了三个任务通过比例及场景数量。

因此，81.1% 不应被当成购买或迁移决定的终点，它更适合作为一组机制证据：工具聚焦、任务分解、执行前验证和执行后反思，可能显著影响多应用 Agent 的稳定性。

用同一套任务验证，而不是照抄榜单

对准备采用 Agent Harness 的团队，最稳妥的做法是复用官方的比较思想：固定同一个模型，拿自己的真实任务、工具权限和失败标准，比较候选方案。不要同时换模型、提示词和 Harness，否则即使成绩提高，也很难知道究竟是哪项改动生效。

除了任务完成率，还应记录完整场景通过数、工具调用次数、失败后的恢复能力、越权动作次数、执行日志是否足以定位问题，以及部署后是否仍需依赖外部服务。Hugging Face 本身也提供模型与数据集入口，可把不同模型放进同一套业务任务中观察；但对当前这个问题，最值得复现的并不是再换一个更强模型，而是先固定模型，看看 Harness 能否把已有能力稳定释放出来。

同模型从 30.0% 到 81.1% 的变化，给 Agent 用户留下的实用结论很明确：选型时别只问“用哪个模型”，还要问“模型在什么执行系统里工作”。选对工作形态，再用自己的任务复测，比追逐一张通用榜单更可靠。

参考来源

• Agent Harness