StarHarness：企业环境中基于分层搜索的 Harness 演化

TL;DR StarHarness 在不改模型权重的情况下，通过分层任务池与隐藏选择进化 agent harness，在 ITBench、EnterpriseOps-Gym、AutomationBench 上提升 20–35 个百分点，且跨 GPT 与 Qwen 模型迁移，解决企业工具场景中的模型-环境错配。

问题

问题背景

在工具丰富的企业环境中，LLM 智能体通过 harness（包括 prompt、工具接口、子代理结构、agent-loop 配置等）与环境交互。当前研究多聚焦模型能力提升，但 harness 设计本身 对任务成功率影响显著；在模型权重固定时，它是降低 model-environment mismatch 的关键杠杆。

现有方法局限

• 传统 prompt engineering 依赖专家手工调整，难以扩展到大规模、多环境的企业工具集。
• 自动优化方法如 DSPy、OPRO 主要优化单一 prompt 或少量工具，未覆盖 harness 的多个组件（如 skills、MCP-backed providers、subagent 结构）。
• 常见的搜索策略在同一任务集上训练和评估，容易导致 过拟合，且很少验证跨模型家族（如 GPT 与 Qwen）的迁移性。
• 缺乏针对 企业状态化后端 和 隐式领域约定 的自动学习机制，工具 schema 常缺失关键操作语义，造成大量失败诊断。

为什么这个问题难/重要

企业环境具有工具面大、跨步骤依赖强、状态变更需精确匹配等特点，harness 搜索空间组合爆炸；同时必须保证对未见过任务的泛化，避免演化过程自欺。业界迫切需要降低 model-environment mismatch 的实用方法，StarHarness 通过分层任务池、分离搜索与选择任务、保留 held-out 任务评估泛化，为此提供了一条可操作路径。

行业类比

类似在固定 LLM 基础上，通过调整 API 描述、工具封装和子代理编排来适配不同 SaaS 平台，而不重新训练模型，如同 RAG 系统中优化检索策略以适配特定知识库。

核心洞察

• StarHarness 的核心洞察在于把 agent 性能瓶颈从模型权重转移到 harness 配置，通过分层采样与隐藏选择任务，用极少量的 accepted changes（4-12 次）换取 20-35 个百分点提升，并泛化到 held-out 任务。与 prompt optimization 或 fine-tuning 不同，它不改模型，而是修改工具接口、任务框架、子代理结构等；分层按 baseline 失败行为划分任务，让进化池覆盖不同失败模式；proposer 无法看到 selection tasks，防止搜索只针对可见任务过拟合；held-out 评估证明增益来自环境适配而非记忆。这为工具丰富的企业环境提供了一条低成本、可验证的迭代路径。
• 进化得到的 harness 变更可以跨 GPT 和 Qwen 模型家族零成本迁移，而且轨迹分析显示它压缩搜索、减少误诊，说明 harness 捕获的是环境自身的操作知识而非模型特定行为。通常 prompt 对模型很敏感，但 StarHarness 进化的接口修复、环境约定和操作知识在冻结权重下仍可迁移，表明它改善的是 agent 与环境交互的信息瓶颈，而非模型推理能力。这提示工程师应优先修复工具 schema、环境约定等可复用层，而不是为每个模型重新调优，从而降低多模型部署的维护成本。

方法

输入与总体流程

StarHarness 在固定模型权重的前提下，以默认 agent harness 为起点，输入任务集及其在默认 harness 下的基线失败行为。框架不修改模型，只进化 harness 配置，包括 prompt 与任务框架、工具接口、技能、MCP 后端、子代理结构与 agent 循环。

关键模块

1. 任务分层与紧凑进化池：对任务按基线失败模式分层，每层抽取少量代表任务组成搜索池，避免全量任务进化开销。
2. proposer-visible / proposer-hidden 分离：生成新 harness 的 proposer 仅可见搜索任务，负责接受或拒绝变更的选择器则基于隐藏任务评估，防止选择器过拟合特定任务。
3. 探索与利用搜索：交替进行大胆的新结构探索与局部微调，结合候选隔离与 guardrails，保证每次变更可独立回溯、可安全应用。
4. held-out 泛化评估：保留一组未参与进化的任务，用于最终验证泛化性能。

输出与效果

进化输出是环境专属的改进 harness，在 ITBench SRE、EnterpriseOps-Gym ITSM、AutomationBench Finance 上相对默认 harness 提升 20-35 个百分点，且跨 GPT 与 Qwen 模型传递、在 held-out 任务上保持。

差异点：与单点 prompt 优化或人工 wrapper 调整不同，StarHarness 用分层抽样与 proposer-hidden 选择实现结构化 harness 进化，兼顾搜索成本与泛化。

实验

实验设计

StarHarness 在三个企业基准上评估，固定模型权重，仅演化 harness。通过基线失败行为分层构建紧凑演化池，将任务分为 proposer-visible search tasks 与 proposer-hidden selection tasks，并保留 held-out tasks 用于泛化测试。每个环境执行 4–12 次 accepted changes。

关键发现

相对于默认 harness，全基准性能提升 20–35 个百分点，三个数据集均显著。性能增益在 held-out tasks 上保持，并且跨 GPT 和 Qwen 模型家族无需重新演化即可迁移。轨迹分析显示改进来自接口修复、环境约定和操作知识，带来更少假阳性诊断和更短轨迹。

与基线对比

默认 harness 在工具丰富的企业任务中存在持续模型-环境不匹配；StarHarness 通过演化 harness 缓解该 mismatch。与 prompt tuning 或权重微调不同，该方法在推理阶段无权重变化，更适合企业部署。更重要的是，迁移能力表明 harness 学习到的是环境接口层面的通用知识，而非模型特定的捷径。

行业影响

落地场景

StarHarness 直接适用于企业环境中工具密集型 agent 的部署与迭代，典型场景包括：

• IT 服务管理 (ITSM)：工单自动分类、故障排查、变更管理，如 ServiceNow、Jira Service Management 平台上的运维助手。
• 站点可靠性工程 (SRE)：基于监控遥测的根因分析、告警处理，减少人工介入。
• 财务自动化：跨 ERP/CRM 系统的对账、发票处理、审批流自动化。

这些场景的共同特征是：模型权重固定，但工具接口、任务框架、环境约定差异巨大，导致通用 agent 频繁失败。StarHarness 通过演进 harness 而非模型，可针对每个企业环境快速适配。

商业价值

核心价值在于降低模型微调与多模型维护成本，同时提升任务成功率。

• 降本：避免为每个客户或环境进行模型微调（GPU 成本、数据标注、运维开销），只需演进轻量 harness 配置。
• 增效：在 ITBench SRE、EnterpriseOps-Gym ITSM、AutomationBench Finance 上提升 20–35 个百分点，意味着更少的人工干预、更短的故障解决时间 (MTTR)、更低的误诊率。
• 可迁移性：演进后的 harness 可跨 GPT 和 Qwen 模型家族复用，企业可自由切换底层 LLM 而不损失任务表现，保护投资。

跟现有产品/工作流的接口

StarHarness 可作为独立的 harness 优化服务，通过以下方式集成：

1. MCP (Model Context Protocol)：连接企业工具后端，自动发现工具 schema 并作为演进输入。
2. 配置化输出：演进结果导出为 YAML/JSON 格式的 harness 配置，被现有 agent runtime（如 LangGraph、AutoGen、自研框架）直接加载。
3. CI/CD 流水线：定期基于新的失败任务池触发演进，通过 hidden selection 和 held-out 验证后发布新 harness，类似模型 A/B 测试。

具体落地 use case

• 企业服务管理平台：ServiceNow 的虚拟代理基于 StarHarness 针对不同租户的字段映射、审批规则和 SLA 要求演进 harness，减少错误工单操作，提高自动解决率。
• 金融运营自动化：在应付账款自动化中，agent 需适配不同 ERP（如 SAP、Oracle）的 API 差异和业务校验逻辑。StarHarness 可演进对应 harness，使同一模型在不同财务系统间无缝切换，提升直通处理率。

局限

• **搜索空间依赖人工设计**：StarHarness 需要在每个环境中预先定义可进化的 harness 组件（提示模板、工具接口、子智能体结构等）及其合法修改范围，这限制了自动化程度，且要求领域专家投入构造搜索空间。此外，进化过程需多次执行完整智能体轨迹以评估候选修改，计算开销显著高于单次提示优化，可能不适合资源受限或在线场景。
• **基准覆盖有限**：实验仅在 ITBench SRE、EnterpriseOps-Gym ITSM 和 AutomationBench Finance 三个企业基准上进行，这些基准虽代表工具丰富、状态严格的场景，但未能涵盖更广泛的企业任务类型（如长期自主规划、多智能体协作、开放式探索）。因此，StarHarness 的泛化能力可能被高估，其结论在不同领域或不同工具拓扑下是否成立仍需验证。
• **缺乏与同类方法直接对比**：论文未将 StarHarness 与现有的自动提示/智能体优化方法（如 DSPy、TextGrad、AgentOptimizer 等）进行基准测试，难以量化其相对优势。同时，分层采样和隐藏选择任务的设计可能引入偏差，使得最终 harness 在进化池上表现好，但在真实分布外任务上仍有退化风险；文中虽使用 held-out 任务，但 held-out 来自同一环境，无法完全消除分布偏移。