IBM Research 对比 CUGA、Hermes 与 Deep Agents 三种 agent harness

回到文章列表 a]:hidden"> 同一个模型，不同的运行框架：CUGA、Hermes 与 Deep Agents——何时应选择 CUGA？ 企业文章 已发布 2026年11月3日 点赞 2 Sami Marreed samimarreed 关注 ibm-research Anupama Murthi anupamamurthi 关注 ibm-research Vinod Muthusamy vinodmut 关注 ibm-research Ankita Naik ankita-naik 关注 ibm-research Segev Shlomov segevshlomov 关注 ibm-research Jayaram Radhakrishnan jayaramkr 关注 ibm-research Aminat A aadebiyi 关注 ibm-research Ayhan Sebin ayhansebin 关注 ibm-research Hamid Adebayo harmedox 关注 ibm-research Erez Bilgory erezbi 关注 ibm-research Asaf Adi AsafAdi 关注 ibm-research Jim Laredo laredoj 关注 ibm-research Merve Unuvar mrvnvr 关注 ibm-research :last-child]:mb-0"> 一项受控实验：同一模型，不同运行框架 结果 分数从何而来 运行框架掌控的每一步都是执行点 为什么选择 CUGA 何时应选择其他方案 试用 CUGA 市面上有近 200 个 agent 运行框架可供选择。我们让其中三个使用同一个开放权重模型，并在 90 个 AppWorld 任务上运行，结果仅更换运行框架就让任务完成率从 30% 提升到 81%。对于企业用途，CUGA 补充了该基准测试未覆盖的内容：由运行框架强制执行规则，以及在你自己的边界内部署。 awesome-agent-harness 和 best-of-Agent-Harnesses 等社区列表收录了近 200 个运行框架，它们清楚地说明了一点：重要的是运行框架，而不仅仅是模型。在 best-of-Agent-Harnesses 引用的一项分析中，同一个 GLM-5.2 模型在 SWE-bench Pro 上的成绩从 23% 提升到 52%，而变化的只有运行框架。 所以正确的问题不是“哪个运行框架最好？”，而是“哪个运行框架适合我的工作负载、我的模型？”Nous Research 的 Hermes 专为常驻个人助理打造，LangChain 的 Deep Agents 则面向研究等长时间、多步骤任务。两者在这些工作上都很出色。 企业工作是另一回事。Agent 要操作业务系统，比如 CRM 和支付系统，而且必须遵守无论模型做出什么决定都成立的规则。CUGA（ConfigUrable Generalist Agent，可配置通用 Agent）是 IBM 为此打造的开源运行框架，支持开放权重或托管模型，部署在你自己的环境中，包括主权云和气隙部署。为了衡量运行框架带来的增益，我们保持模型不变，只更换运行框架。 一项受控实验：同一模型，不同运行框架 我们在 AppWorld 上运行了 CUGA、Hermes 和 Deep Agents。AppWorld 是一个跨 9 个应用、457 个 API 的多步骤任务基准测试，涉及邮件、支付和文件存储等。这些应用是消费级应用，所以 AppWorld 只是一个代理：它测试的是企业自动化同样需要的一部分能力，比如登录、阅读 API 文档、翻页获取结果，以及跨多个应用更改状态。每个运行框架都使用同一个开放权重模型 GLM-5.3-flash，运行相同的 30 个场景中的 90 个任务，每个任务尝试一次。所有运行都使用 Harbor 评估框架，我们的设置已在 harbor-eval（我们的 Harbor 分支）中公开。 结果 AppWorld，30 个场景中的 90 个任务，GLM-5.3-flash TGC：通过的任务数 SGC：三个变体全部通过的场景数 CUGA 81.1（73/90） 66.7（20/30） Hermes 46.7（42/90） 26.7（8/30） Deep Agents 30.0（27/90） 6.7（2/30） 图 1. AppWorld，30 个场景中的 90 个任务，每个运行框架都使用 GLM-5.3-flash。TGC：通过的任务数。SGC：三个变体全部通过的场景数。 如何解读。这不是对 Hermes 或 Deep Agents 的定论。两者都不是为 AppWorld 这类多应用 API 工作而构建的，而这正是要点：运行框架必须适合工作本身。 最有用的数字是 SGC。一个场景只有在其三个变体全部通过时才算通过，所以 SGC 奖励的是一致性，而非侥幸的一次运行。在这里差距更大：CUGA 为 20 个场景，Hermes 为 8 个，Deep Agents 为 2 个。 有三点局限。这是一个基准测试上的 90 个任务样本，因此结果可能不适用于其他任务。各设置并不完全相同（见上文的设置表）。而且这些运行没有使用策略，因此它们并未衡量策略执行。 分数从何而来 在 90 个任务的比较中，每次运行的模型都相同，所以差异来自运行框架。每个 CUGA agent 都运行同一个紧凑循环：准备、调用模型、执行、重复。同一个循环可以从一个拥有自己工具的 CugaAgent 扩展到协调多个 agent（本地或通过 A2A 远程）的 CugaSupervisor。以下是 AppWorld 设置中运行的 CUGA 功能，按其作用分组： 借助这些功能，模型需要做的决定更少，运行框架能在错误影响结果之前捕获更多错误。 运行框架掌控的每一步都是执行点 运行框架控制的每一步，比如上面列表中的那些，也是它可以检查规则的地方。 大多数团队会把业务规则，比如支付审批或客户 PII 保留在组织内部，写进系统提示词。提示词是指令，不是强制执行。模型可能误读它，用户可能说服 agent 违背它，注入的消息也可能在任务中途改变它。 CUGA 策略把这些规则从提示词中移出，放进运行框架。我们在 ACM CAIS 2026 论文《Governance by Construction for Generalist Agents》（arXiv）中描述了这个策略层。策略在每次运行的四个节点上起作用： 引导（Guidance）引导模型，但审批和 ToolGuards 由运行时强制执行。把支付审批和 PII 处理等规则放在第二组，它们无论模型做出什么决定都成立。 你可以在 Policy Playground 中亲自看到区别，它把同一条消息发送给两个实时 agent，一个没有策略，一个有策略： 图 2. 对于“把我欠的所有钱都付了。”，没有策略的 agent 支付了 90 美元，其中包括一笔催收中的被拒索赔。有策略的 agent 将付款挂起等待审批，然后只支付了应支付的 10 美元。 为什么选择 CUGA

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）