StarHarness：不改模型参数，也能进化企业级智能体

企业级智能体经常不是“不会推理”，而是无法顺利适应具体环境：工具参数不清晰、系统约定未被说明、任务拆解方式不合适，都会让模型在实际操作中反复失败。StarHarness 关注的正是这层经常被忽视的运行框架，即 harness。

核心思路

StarHarness 在模型权重保持不变的情况下，搜索与环境更匹配的智能体配置。可被调整的对象不局限于系统提示词，还包括任务 framing、工具接口与数据模式、技能模块、MCP 支持的服务、子智能体组织方式、状态管理、上下文处理，以及 agent loop 的执行逻辑。换言之，研究者把“如何让模型工作”本身视为一个可演化的工程对象。

它的搜索策略有三个关键设计：

• 按失败行为分层抽样：根据默认 harness 下的失败类型组织任务，构建规模较小但覆盖不同问题的进化池。
• 分离搜索与选择：让提议修改方案的过程只能看到部分任务，同时使用提议者不可见的选择任务评估改动，减少针对样本的投机优化。
• 保留独立测试任务：将未参与进化的任务用于检验泛化，而不是只报告搜索池中的成绩。

实验观察

研究覆盖 ITBench SRE、EnterpriseOps-Gym ITSM 和 AutomationBench Finance 三类企业场景。论文摘要称，在每个环境接受约 4 至 12 次修改后，进化后的 harness 相比默认配置带来约 20 至 35 个百分点的全基准性能提升；这些收益也出现在未参与进化的任务上，并能在 GPT 与 Qwen 模型家族之间迁移，而无需重新进化。材料还提到，部分设置下推理成本下降了 17% 至 53%。

一个颇具启发性的结果是：在 ITBench 上，使用进化 harness 的 Qwen3.5-27B 比运行默认 scaffold 的 GPT-5.5 高 19.2 个百分点。这并不意味着小模型普遍优于大模型，而是说明模型能力最终能否落地，取决于模型与工具环境之间的匹配程度。

意义与限制

轨迹分析将改进归因于接口修复、环境约定补充和操作知识注入。这些变化能够压缩搜索路径，减少误诊，并在若干场景中缩短执行轨迹。对企业部署而言，结论的价值在于：升级智能体不一定首先意味着更换模型，也可以从工具设计、上下文组织和执行控制入手。

不过，现有材料主要提供摘要和发布页面信息，尚不足以判断搜索成本、不同修改类型的独立贡献，以及跨环境迁移的边界。StarHarness 更适合作为一种面向特定环境的优化方法，而不是替代模型评测或通用能力训练的万能方案。

来源：Hugging Face Daily Papers