EVOHARNESSBENCH: 你的智能体能否跟上不断演进的 Harness？

TL;DR EvoHarnessBench 首次将非平稳性置于 agent 外部 harness（工具/技能/代理）而非任务流，系统评估其在 harness 演化下的保留与适应，揭示扩展引发遗忘、适应不一致等关键差距。

问题

问题背景

现代 LLM 智能体通过外部 harness（工具、技能、子智能体）来扩展观察与行动空间。业界已从单任务评测转向持续学习设定，但多数智能体 benchmark 仍默认 harness 在评测过程中固定不变。

现有方法局限

• 现有 continual agent benchmark 将非平稳性放在任务流上（如新任务、环境变化），而工具集、技能库、agent 图保持不变。
• 这掩盖了真实部署中的 harness 演化：新增工具改变 action schema；新增技能引入新的调用协议；新增子智能体改变 delegation 图。
• 模型在这种固定 harness 下习得的策略，遇到 harness 变化后会出现动作空间不匹配、技能选择失效、多智能体协作图失效。
• 缺少把 harness 演化作为独立变量的受控评测，无法分离“保留旧能力”与“适应新能力”两个目标。

为什么难 / 重要

harness 演化带来非平稳的观察 / 行动空间，与模型已学到的工具调用分布发生冲突，容易引发 harness-induced forgetting（即使只新增能力，旧任务性能也可能下降）。同时，保留旧能力与适应新能力可能互相拉扯：纯粹扩展 memory 或重新训练，不一定能同时守住旧工作流并高效利用新能力。业界关注部署后 agent 持续运维：平台不断上架新工具 / 插件 / 子 agent，旧工作流必须保持可用，新能力又需快速吸收。

行业类比

类似移动应用生态：App 持续更新并新增 API，通用助手既要调用新功能，又不能弄丢用户已依赖的旧技能。

核心洞察

• EvoHarnessBench 将非平稳性从任务流转移到供 agent 使用的外部 harness（工具/技能/子代理），而非延续传统持续学习基准中固定 harness、变化任务的做法。这一设计更贴近生产环境：实际部署中工具库、技能包与团队结构频繁更新，而任务本身可能保持稳定。该设置暴露了 **harness-induced forgetting** 现象，即仅扩充可用工具也可能导致已解决任务性能下降，说明 agent 对 harness 的依赖存在隐含脆弱性，并提示工程上需将 harness 演化纳入回归测试。
• 论文区分了 **deployment evaluation**（保留已有能力）与 **self-evolving adaptation**（适应新能力）两个评测维度，并发现二者并非正相关，甚至可能相互拉扯。与传统持续学习侧重避免遗忘不同，该结果提示在构建可演化 agent 时，单纯积累经验或继续训练无法同时优化保留与适应。这要求开发者分别监控两个指标，并在系统设计中权衡：例如引入缓存/路由机制以保留旧能力，同时通过受控探索促进新能力获取。

方法

输入与总体设计

• 从 verifier-based benchmarks 中选取可验证的任务作为基础任务集合。
• 将智能体运行所需的工具、技能、子智能体抽象为可组合的 harness 元素。

关键模块

1. 三轴 harness 定义：分别覆盖 tools(520个)、skills(42个)、agents(62个)三类能力单元。
2. 确定性演化流构建：按阶段向基础 harness 逐步添加新能力，构造 17 条多阶段 harness streams。每个阶段包含一组任务(总计 802)与新引入的工具/技能/智能体。构建过程采用确定性规则，保证可复现。
3. 双评估协议：
   • deployment evaluation：仅扩展 harness，不进行自我演化，用于测量模型在旧任务上的保留能力。
   • self-evolving adaptation evaluation：允许智能体根据历史经验调整自身(如维护记忆、更新提示或内部策略)，检验新增能力时积累经验是否仍可用。
4. 指标：除任务成功率外，重点计算 harness-induced forgetting、适应增益等，度量保留与适应两个维度。

输出

输出分轴、分阶段的性能曲线，揭示三个核心差距：

• 仅扩展 harness 就可使旧任务性能下降，产生 harness-induced forgetting；
• 自我演化适应在不同阶段、能力轴、环境中表现不稳定；
• 保留与适应可能相互冲突，保留旧能力不必然提升对新能力的适应，反之亦然。

与同类方法的差异点：传统面向智能体的 continual-learning 基准通常固定 harness、让任务流非平稳；EvoHarnessBench 反转该设定，将非平稳性置于外部提供的 harness 本身，更贴近真实生产环境中工具/技能/智能体持续增补的场景。

实验

实验设计

EVOHARNESSBENCH 将非平稳性从任务流转移到外部 harness（工具、技能、智能体），构建了 17 条多阶段 harness 流，包含 802 个任务、520 个工具、42 个技能、62 个智能体。评估分两种互补设置：一是 deployment evaluation，隔离 harness 扩展时对既有能力的保留；二是 self-evolving adaptation，测试新增能力引入后积累经验是否仍然有用。

关键发现

1. 工具扩展 本身即可导致对先前已解决任务的性能下降，产生 harness-induced forgetting。
2. 自演化适应 的收益在 harness 演化阶段、能力轴及环境之间不一致。
3. 保留与适应 可能相互拉扯：保留早期能力不必然提升对新能力的适应，反之亦然。

与现有基准对比

不同于现有 continual-learning benchmark 将非平稳性置于任务流而固定 harness，EVOHARNESSBENCH 将非平稳性放在外部提供的 harness 中，更贴近生产环境中工具、技能、子智能体持续更新的现实。该设计揭示了 harness 演化带来的独特挑战——即使任务分布不变，仅 harness 扩展也能引发遗忘，这为构建既能跟上演化又能保留有效行为的智能体提供了新的评估视角。

行业影响

落地场景

EVOHARNESSBENCH 适用于持续演进的企业级 Agent 平台：当产品团队为客服机器人、IT 运维助手或营销自动化系统新增工具、技能或子 Agent 时，需要验证旧任务是否退化。典型用例：电商智能客服在增加“物流查询”工具后，原有的“订单修改”任务可能因工具选择混淆而失败；多 Agent 工作流中引入新专家 Agent 可能导致任务路由错误。该基准提供了可复现的演化场景，用于发布前回归测试。

商业价值

• 降低维护成本：自动检测 harness 更新引发的遗忘，避免人工排查生产事故，减少回归测试人力。
• 提升用户体验：保留旧能力的同时快速适应新功能，减少服务中断，提高客户满意度与留存。
• 控制风险：通过区分部署评估与自演化适应评估，可量化权衡保留与适应，避免盲目上线新功能。

与现有工作流的集成

可将 EVOHARNESSBENCH 作为评估套件嵌入 LLMOps 流水线：

1. 在每次 harness 版本变更（如新增工具、更新 skill 库）时触发基准测试。
2. 输出 保留率、适应增益、遗忘率 等指标，与现有监控系统（如 Prometheus、Grafana）对接。
3. 根据结果决定是否回滚或灰度发布，并指导 harness 架构设计：将稳定核心与可变组件解耦，支持版本化工具注册表。

具体用例：企业知识库 Agent 添加“合同审查”技能后，需要确保原有“摘要生成”技能不退化；使用该基准的多阶段流可验证跨阶段累积经验是否有效，从而优化持续学习策略。

局限

• 基准的构建依赖 verifier-based benchmarks，任务和 harness 元素通过确定性规则生成，可能与真实世界 harness 演化存在差距。例如，演化流是预先定义的，缺失了实际环境中常见的非确定性更新、依赖冲突和版本兼容性问题。此外，数据集规模（802 个任务、520 个工具、42 个技能、62 个智能体）相对有限，可能影响跨多种模型和设置下结论的泛化性。
• self-evolving adaptation 设置简化了真实自演化过程。论文中的自演化主要基于离线经验回放或固定策略，未涉及在线持续学习、部分可观测性、资源约束或人工干预等生产环境中的关键因素。因此，所报告的适应能力可能不能完全反映部署中智能体面对连续 harness 更新时的实际表现，导致评估偏差。
• 基准仅覆盖 harness 扩展（新增能力），未考虑缩减、替换或版本回退等演化模式，而这些在实际系统中同样常见。同时，研究发现保留与适应存在张力，但并未提供协调两者的方法或基线，使得基准当前主要用于诊断问题，而非指导算法设计，限制了其对实际改进的推动作用。