Meta｜EvoHarness-RL：优化Agent harness使用的研究框架

Agent 能力往往不取决于「底座模型再大一点」，而取决于外层 harness 有没有被用对——工具怎么选、失败怎么重试、记忆怎么裁、规划提示怎么写、环境接口怎么接。Meta 提出 EvoHarness-RL 研究框架，目标正是优化 Agent 对 harness 的使用方式。

Meta 在大模型、开源权重与 Agent 相关研究上持续投入。EvoHarness-RL 把问题从「换更大模型」转向「把外层运行时骨架用得更聪明」：同样预算下，小模型配上更好的编排与工具策略，是否也能在复杂工作流里跑出接近更高阶模型的效率叙事。

核心事实： 框架用于优化 Agent 对 harness 的使用；公开材料口径提到，约8B量级模型经该框架相关优化后，在复杂工作流上可接近更高阶模型的效率叙事。必须标明：这是研究与公开报道口径，不是生产环境的服务等级协议（SLA）承诺，也不能直接当成线上稳定性或成本保证。

harness 通常覆盖这些外层能力：

1. 工具选择： 何时调用检索、代码执行、浏览器或其他 API。
2. 重试与回退： 失败后如何换策略，而不是死循环同一动作。
3. 记忆与上下文裁剪： 哪些轨迹保留、哪些丢掉。
4. 规划提示： 任务如何拆解、中间检查点如何设置。
5. 环境接口： 与沙箱、仓库、业务系统的边界与权限。

所谓 Agent harness，白话是套在模型外面的运行时骨架；所谓 EvoHarness-RL，从命名看是把「如何使用这套骨架」本身当成可用强化学习等方式搜索或优化的对象，而不是写死一套提示词模板。对工程团队，启发很实际：预算有限时，先挖透小模型 + 好 harness，可能比盲目换更大模型更划算。

背景上，企业 Agent 落地卡点越来越多地出现在工具编排与失败恢复，而不是单次问答分数。评测若只比裸模型、不比 harness，很容易高估「换大模型」的边际收益，低估「把外层用对」的工程价值。

影响上，研究叙事若成立，将推动 Agent 平台把自动调 harness 做成产品能力；评测方则需警惕「接近更高阶模型」是否只在特定任务集、特定工具预算下成立。需要把边界读清楚：效率对比属研究/报道口径，任务集、对照模型、是否允许工具与计算预算是否对齐，决定结论能否外推；本条素材未单独确认其是否已开源或并入 Meta 内部产品线。

下一观察点是论文或代码是否公开、独立复现能否支撑「约8B接近更大模型」的表述，以及企业 Agent 平台是否吸收类似自动优化 harness 的思路。