同一模型，换套Harness就变笨？

截至 2026 年 11 月 3 日，Agent 开发正在从“选哪个模型”转向“模型应该装进哪套 Harness”。IBM Research 近日发布的对比文章把 CUGA、Hermes Agent 与 Deep Agents 放到同一视野下，核心结论很直接：即使底层模型完全相同，系统提示词、工具定义、上下文管理和执行循环不同，也足以让最终任务表现出现明显差距。

这不是一个单纯的框架排行榜问题，而是 Agent 评测中长期被忽略的变量控制问题。开发者看到的最终得分，实际上是“模型能力 × Harness 适配 × 工具环境 × 任务类型”的联合结果；把全部功劳或责任都归给模型，已经越来越不准确。

Agent 的实际能力，不等于模型裸能力，而是 Model、Harness、Tools 与 Environment 共同作用的结果。

Harness 不是模型外面的一层简单胶水

Agent Harness 是包裹在大模型外部、负责上下文组织、工具调用、执行循环、状态管理和安全控制的运行系统。模型本身只负责接收输入并生成输出，它不会天然读取代码库、操作浏览器、执行终端命令，也不会自动判断一次工具调用是否真的完成了任务。

Harness 决定了模型“看到什么、能做什么、做错后怎么办”。一套成熟的 Harness 通常至少包含以下六类能力：

1. 系统提示词与上下文装配：决定规则、任务状态、历史记录和工具结果以什么顺序进入模型上下文。
2. 工具描述与参数转换：把文件、终端、浏览器、数据库或 MCP 工具转成模型能够理解的调用接口。
3. Agent 循环：控制模型在思考、调用工具、读取结果和继续执行之间如何往返。
4. 状态与记忆管理：决定哪些信息保留、哪些信息压缩，以及跨会话信息是否持久化。
5. 权限与执行环境：约束模型能访问的文件、命令、网络和外部系统。
6. 验证与停止条件：判断任务是否真的完成，还是模型只是生成了一句“已经完成”。

同一模型在不同 Harness 中并没有获得完全相同的有效输入。即使用户提示词一致，Harness 写入的系统指令、工具 schema、错误信息和历史摘要仍可能完全不同，因此所谓“同模型对比”只能控制模型权重，不能自动控制整个推理环境。

CUGA、Hermes 和 Deep Agents 并不是同一种产品

CUGA 是 IBM Research 推进的可配置通用 Agent Harness，重点是把规划、工具、执行策略和任务环境拆成可以组合与替换的工程组件。它更接近一套面向复杂任务与受控部署的 Agent 运行系统，而不是只提供一个循环函数。

Hermes Agent 是 Nous Research 开源的长期运行型 Agent 软件，它把模型接入、终端工具、会话、持久记忆、Skills 和消息渠道整合到一个可直接使用的 Agent 产品中。需要特别区分的是，Hermes Agent 是软件项目，Hermes 3、Hermes 4 等名称则属于 Nous Research 的模型系列，两者不能混为一谈。

Deep Agents 是 LangChain 团队基于 LangGraph 构建的可嵌入 Agent Harness，核心能力包括任务规划、文件系统、子 Agent、上下文卸载和图状态执行。它更像一套供开发团队嵌入自有应用的工程底座，而不是预先定义好使用方式的个人助理。

三者虽然都能套在模型外面，但产品边界并不一致。CUGA 强调可配置执行与复杂工作流，Hermes 强调开箱即用和持续陪伴，Deep Agents 强调图编排、子 Agent 和应用集成；直接问“谁最强”，就像比较 Kubernetes、个人电脑操作系统和后端框架，问题本身缺少场景。

三套 Harness 的定位对比

下表是基于官方项目定位整理的工程选型对比，不应被理解为脱离模型与任务的统一性能排名。

| 对比维度 | CUGA | Hermes Agent | Deep Agents | |---|---|---|---| | 核心定义 | 可配置的通用 Agent Harness | 面向长期运行的开源 Agent 软件 | 基于 LangGraph 的可嵌入 Agent Harness | | 主要目标 | 复杂任务执行、工具编排、受控部署 | 个人助理、终端操作、持续记忆与 Skills | 在自有产品中构建规划型和多 Agent 系统 | | 抽象层级 | 偏完整运行系统 | 偏成品 Agent 产品 | 偏开发框架与运行时组件 | | 规划方式 | 强调可配置规划与执行策略 | 由内置 Agent 循环驱动 | 任务清单、图状态与子 Agent 分工 | | 工具能力 | 适合接入浏览器、代码、企业工具与外部服务 | 终端、文件、网络、消息渠道和 Skills | 文件系统、工具节点、MCP 与自定义函数 | | 记忆方向 | 更重任务状态和可控上下文 | 更重跨会话持久记忆 | 更重图状态、存储后端和上下文卸载 | | 子 Agent | 可通过配置和任务结构组织 | 重点不在企业式多角色编排 | 属于核心设计之一 | | 可观测性诉求 | 适合强调执行轨迹、控制与评估的项目 | 更偏用户直接使用与长期交互 | 可结合 LangGraph 生态追踪状态和节点 | | 最适合团队 | Agent 平台、研究、企业自动化团队 | 独立开发者、研究者、个人助理用户 | 已采用 Python、LangChain 或 LangGraph 的应用团队 | | 软件价格 | 开源获取，无统一订阅价；模型与基础设施成本另计 | 开源获取，无统一订阅价；模型与基础设施成本另计 | 开源获取，无统一订阅价；模型与基础设施成本另计 | | 主要代价 | 配置面较大，需要理解任务和工具边界 | 产品默认观点较强，企业流程往往需要改造 | 灵活性高，但生产能力需要团队自行组装 |

这张表真正反映的是三种不同取舍。CUGA 试图把 Harness 本身变成一个可配置对象，Hermes 试图让用户尽快拥有一个能持续工作的 Agent，Deep Agents 则试图让开发者获得一套能够嵌入产品的构建模块。

为什么同一模型会出现完全不同的表现

工具描述质量会直接改变模型的决策准确率。一个 Harness 可能把网页操作拆成打开页面、读取元素、点击和验证四类工具，另一个 Harness 可能只暴露一个通用浏览器入口；前者更容易约束动作，后者更灵活，但也更依赖模型自行理解环境。

上下文顺序会直接影响模型关注什么。把任务目标放在工具日志之前，与放在数千 token 的执行记录之后，对模型而言不是同一份输入；当上下文接近窗口上限时，Harness 的截断和摘要策略甚至会决定最初的用户要求是否还留在上下文中。

错误恢复策略会放大模型之间的差异。工具返回超时后，有的 Harness 会原样把报错交回模型，有的会自动重试，还有的会切换工具或重新规划；模型最终是否完成任务，可能取决于外层系统是否给了它第二次机会。

停止条件会改变“成功”的定义。有些 Agent 在模型输出完成声明后立即退出，有些 Agent 会检查文件是否存在、测试是否通过或网页状态是否更新；前一种方案速度快、成本低，但容易出现语言上完成、环境中没有完成的假成功。

上下文压缩也不是中性的基础设施。摘要模型可能删除文件路径、参数值或用户约束，导致主模型在第 15 步忘记第 1 步的条件；另一套 Harness 如果把关键状态写入结构化存储，就可能在相同上下文窗口下继续稳定执行。

因此，Harness 不是单纯决定 Agent 下限的“壳”。它既可能帮助普通模型稳定完成任务，也可能用糟糕的工具定义和上下文策略压制强模型的能力上限。

什么时候应该优先选择 CUGA

CUGA 更适合任务流程复杂、工具种类多且需要控制执行方式的场景。典型例子不是“帮我总结一篇文章”，而是“登录内部系统读取订单，交叉检查数据库，生成报告，并把异常项提交给人工确认”这类跨系统任务。

1. 任务需要多阶段规划与重规划

多阶段任务最容易暴露简单 ReAct 循环的局限。模型如果只根据上一条工具结果决定下一步，可能在十几步之后偏离目标；CUGA 的价值在于把规划、执行和任务状态作为可配置部分，使开发者能够更明确地控制什么时候拆解任务、什么时候重规划以及什么时候停止。

2. 工具调用必须可追踪、可替换

企业 Agent 通常不能把所有工具权限一次性交给模型。CUGA 更适合需要工具白名单、环境隔离、执行记录和组件替换的团队，因为这些团队关心的不只是任务能否完成，还关心模型调用了什么、参数是什么、失败发生在哪一层。

3. 团队需要比较模型，而不是绑定模型

模型无关性只有在 Harness 行为相对稳定时才有意义。CUGA 的配置化思路适合建立内部评测矩阵：保持工具、任务和验证器不变，再替换不同模型，从而区分模型问题与执行系统问题。

4. 任务以浏览器和企业工作流为主

浏览器任务需要处理动态页面、身份状态、表单、分页和动作确认。相比只围绕代码仓库设计的 Harness，通用任务 Harness 更容易容纳网页、文件、数据和业务系统之间的连续操作，这也是 CUGA 更值得考虑的场景。

5. 团队愿意为控制力承担配置成本

CUGA 并不是默认配置越多越好。配置能力意味着更多策略需要开发者自己决定，如果任务只是单轮问答、简单终端命令或个人日程管理，引入完整的规划和治理层反而可能增加延迟、token 消耗与维护成本。

什么时候 Hermes Agent 更合适

Hermes Agent 更适合希望快速获得“长期在线数字助手”的用户。它的重点不是让企业平台团队重新设计每一层编排，而是把记忆、会话、Skills、终端和消息渠道组合成一个能够持续工作的整体。

个人研究助理是 Hermes 更自然的使用场景。用户可能希望 Agent 记住长期偏好、复用过去积累的技能，并通过终端或聊天渠道继续工作，这类需求与企业审批流并不相同，却高度依赖持久记忆和成品体验。

Hermes 的风险是默认产品形态可能与组织流程冲突。企业如果需要细粒度权限、确定性审批节点、统一观测和严格的数据边界，往往仍需改造其工具、存储和执行策略，最终工作量未必低于从框架搭建。

什么时候 Deep Agents 更合适

Deep Agents 更适合已经决定自行开发 Agent 产品的团队。它提供任务规划、文件操作、子 Agent 和 LangGraph 状态执行，但不会替团队定义完整的业务产品、权限模型和运维方式。

子 Agent 是 Deep Agents 最明显的工程优势之一。复杂任务可以由主 Agent 保留总体目标，再把检索、代码分析或报告生成交给独立子 Agent，从而隔离上下文并减少单个上下文窗口的压力。

LangGraph 生态是选择 Deep Agents 的现实理由。已经使用 LangChain、LangGraph 或相关可观测工具的团队，可以沿用图节点、状态存储和人工介入机制，迁移成本通常低于引入一套完全不同的运行系统。

Deep Agents 的代价是团队仍需补齐生产能力。身份认证、租户隔离、预算控制、工具权限、失败补偿和业务指标并不会因为安装框架自动出现，它更像一套强力底盘，而不是交钥匙产品。

不要再用单次跑分选 Harness

Harness 评测必须同时控制模型、任务、环境和验证器。只运行一次任务，很难区分真实能力、随机采样、网络波动与工具偶发失败；尤其是浏览器和终端任务，外部环境的一次变化就可能改写结果。

一个更可靠的内部评测至少应采用“模型 × Harness × 任务”的三维矩阵。假设团队测试 3 个模型、3 套 Harness 和 20 个任务，每个组合重复 5 次，总运行次数就是 3 × 3 × 20 × 5，即 900 次；这比挑几个演示案例更昂贵，却能看到稳定性、成本和失败类型。

建议至少记录以下指标：

• 任务成功率：由外部验证器判断，不采用模型自报完成。
• 平均执行步数：识别是否出现循环、重复搜索和无效工具调用。
• 端到端延迟：从接收任务到环境状态验证完成的总时间。
• 模型 token 消耗：分别记录输入、输出和上下文压缩成本。
• 工具失败率：区分模型选错工具与工具本身执行失败。
• 人工接管率：统计需要用户确认、纠错或补充信息的比例。
• 恢复成功率：工具报错后，Agent 能否重试、改路或重新规划。

评测还应保留完整轨迹，而不是只保留最终答案。两个 Agent 都可能成功完成任务，但一个用了 8 步，另一个用了 47 步并触发 6 次错误；如果不看执行轨迹，成本和可靠性差异会被最终成功率掩盖。

选型结论：先定产品形态，再定 Harness

CUGA、Hermes Agent 与 Deep Agents 之间没有脱离场景的全局赢家。CUGA 更适合复杂、可配置、需要治理与工具控制的任务；Hermes 更适合个人长期助理和开箱即用体验；Deep Agents 更适合开发团队把 Agent 能力嵌入自己的应用。

最值得警惕的误区是把 Harness 差异误判为模型差异。如果一个模型不会调用工具，问题可能出在模型，也可能出在工具 schema；如果长任务中途失忆，问题可能来自上下文窗口，也可能来自摘要和状态存储；如果模型过早宣布完成，问题可能是推理判断，也可能是 Harness 根本没有设置外部验证。

截至 2026 年 11 月，Agent 工程已经很难再用“换一个更强模型”解决全部问题。模型决定了推理能力的基础区间，但 Harness 决定这些能力如何被暴露、约束、验证和带入真实环境；对于正在做生产级 Agent 的团队，Harness 已经不是配套组件，而是产品本身的一半。

参考来源

• IBM Research：Same Model, Different Harness: CUGA, Hermes, and Deep Agents：本文主要参考资料，讨论同一模型在不同 Harness 下的表现差异，以及 CUGA 的适用场景。
• Nous Research / Hermes Agent：Hermes Agent 官方开源仓库，可用于核对其工具、记忆、Skills 与运行方式。
• LangChain / Deep Agents：Deep Agents 官方开源仓库，介绍规划、文件系统、子 Agent 与 LangGraph 集成。
• IBM / CUGA Agent：CUGA 相关开源实现与项目说明，用于了解其配置、工具和通用 Agent 架构。