StarHarness：用分层搜索进化企业 Agent 的 Harness 框架

  • 关联论文：2608.24804
  • 作者：flyP
  • 更新：2026-08-31

0. 元层五问（v2 必填）

  1. 本稿要解决的真问题：工具密集型企业任务（SRE / ITSM / 金融自动化）中，固定模型权重不变时，"模型-环境失配"是 Agent 性能的隐性瓶颈——同模型换一套 prompt / 工具接口 / subagent 结构就能差出几十个百分点，但如何系统性地发现并修复这层失配，过去没有可复现的方法。
  2. 为什么非要现在做：Anthropic、OpenAI、Google 在 2025-2026 把 Agent 从"模型权重"焦点转向"harness / 上下文工程"焦点，但行业仍以"调 prompt 凑活"为主，缺乏像 NAS / AutoML 一样可搜索、可验证的 harness 进化范式。
  3. 本稿在同方向的不可替代位置：把 harness 搜索问题从"手工调"提升为"分层 + 提议者-选择者分离 + 留出集评估"的标准范式，与 DeepMind 的 FunSearch 路径同源，但首次把搜索空间限定在"prompt + 工具 + skill + subagent + agent-loop"五元组，并对 ITBench/EnterpriseOps-Gym/AutomationBench 三个企业级基准给出 20-35pp 的实证增益。
  4. 谁最该读：企业 Agent 平台架构师、Agent eval/benchmark 团队、做 Agent 工程化落地的 SRE / IT 运维方向研究者、对 harness 进化（prompt + tooling 双轨搜索）感兴趣的研究人员。
  5. 一句话结论：固定模型权重，通过对任务按基线失败模式分层、把提议者可见的搜索任务与提议者隐藏的选择任务分离、并用留出集测泛化，可以在企业任务上以每次接受 4-12 处改动把全基准分数提升 20-35pp，跨模型族可迁移。

1. 核心方法

1.1 背景：什么是 Harness

作者把"harness"明确拆为五元组：

  • prompt & task framing（系统提示 / 任务包装）
  • tool interfaces（对外暴露的工具签名）
  • skills（可复用策略片段）
  • MCP-backed providers（基于 Model Context Protocol 的外部能力提供方）
  • subagent structure（主-子 Agent 的拆分）
  • agent-loop configuration（迭代步数、终止条件、重试策略等）

⚠️ 论文 TLDR 文本在原文末尾被截断，第六项"agent-loop configuration"以原文 abstract 完整字段为准，不做补充。

1.2 进化池构建（Stratified Pool）

不再用全量任务做随机搜索，而是先跑一次 baseline，记录每个任务的失败模式（失败原因分类），然后按失败行为分层采样，构造一个紧凑的进化池：

tasks = load(env_benchmark)
fail_modes = run_baseline(tasks, default_harness)
strata = group_by(tasks, fail_modes)
pool = stratified_sample(strata, k_per_stratum)

这一设计的核心动机是：均匀随机采样会让"模型已经做对的简单任务"占据多数，搜索信号被稀释；分层采样让每一种失败模式都有等量代表，使 proposer 能在同一预算下看到完整的失败类型。

1.3 提议者-选择者分离（Proposer / Selector Split）

把进化池进一步切为三部分：

  • Proposer-visible search tasks：提议者（可以是 LLM 或人工）可见，用作 harness 候选方案的搜索信号源。
  • Proposer-hidden selection tasks：提议者不可见，用于在多个候选 harness 中挑选最终版本——避免提议者"为搜索任务过拟合"。
  • Held-out tasks：完全不在进化中使用，用于评估最终 harness 的泛化性。

这种切分借鉴了 AutoML 中的 train / validation / test 三分法，但额外加了一层"对提议者可见 / 不可见"的认知隔离，避免 harness 搜索退化为对搜索任务的过拟合。

1.4 改写接受准则

每次接受一处 harness 改动，要求在 selection tasks 上相对当前 harness 有可验证的提升。abstract 报告每个环境接受 4-12 次改动后，全基准分数提升 20-35pp，说明搜索是"少而精"而非"密集改动"。

1.5 进化对象的范围

提议者可以改：系统提示、工具签名、新增 skill（可复用的策略片段）、MCP provider 配置、subagent 拆分粒度、agent-loop 控制参数。⚠️ 模型权重固定——这与 RL fine-tune 路径有本质区别：StarHarness 不动权重，只动"上下文与脚手架"，因此可以跨模型族直接迁移。

2. 关键实验与数据

⚠️ abstract 已给出主结论数字；具体方差 / baseline 模型清单 / 搜索算法本身（是 beam search、evolutionary 还是 LLM-as-proposer）等细节，本稿基于公开 abstract 尚未完整核实——以下数字按 abstract verbatim 引用：

  • 基准：ITBench SRE、EnterpriseOps-Gym ITSM、AutomationBench Finance 三个企业级环境。
  • 主指标：full-benchmark performance，相对 default harness 提升 20-35 percentage points。
  • 改动预算：每个环境 4-12 accepted changes。
  • 跨模型迁移：改进在 GPT 与 Qwen 两个模型族之间无需重新进化即可迁移。
  • trace 分析证据：性能提升的根因包括 interface repairs、environment conventions、operational knowledge that compresses search，以及若干场景下更短的轨迹与更少的 false-positive diagnoses。

⚠️ abstract 没有公布每个基准上的具体数字、未公布 baseline 是哪几个 GPT/Qwen 型号、未公布搜索算法本身——这些需在 PDF 主体核实；本稿写作时间窗内未拉 PDF，因此凡 abstract 未明确的数字一律标 ⚠️。

3. 亮点与局限

3.1 亮点（R1：方法论）

  • 把 harness 从"工程调参"提升为"可搜索对象"，并显式分离训练 / 验证 / 测试三层信号。
  • "提议者-选择者分离"是简单但少有人落地的反过拟合设计，类似 NAS 中的 search / evaluation split。
  • 改动只发生在 prompt + 工具 + skill + subagent + agent-loop 五元组，不动模型权重——这意味着企业可以在不重训模型的前提下持续优化 Agent。

3.2 局限（R2：评估覆盖）

  • abstract 报告 3 个企业级基准，全部偏运维 / 财务 / ITSM 流程类任务；是否覆盖创造性 / 开放式任务（如写作、研究、跨域决策）未明确，⚠️ 原文未明确。
  • 没有与 RL fine-tune、prompt tuning、prefix tuning 等"动权重"路径做头对头比较——但 abstract 明说"keep model weights fixed"，所以严格说这不在本文 scope。

3.3 局限（R3：搜索算法可复现性）

  • abstract 没说提议者是 LLM 还是人工、没说搜索是 evolutionary / beam / UCB / Bayesian——这一点对工业落地至关重要。⚠️ 原文未明确。
  • 留出集规模、提议者预算等关键超参数未在 abstract 给出。⚠️ 原文未明确。

3.4 局限（R4：算力与成本）

  • 每次"评估一次候选 harness"都需要在完整基准上跑一次 LLM Agent，企业基准通常含数十到上百任务，单次评估成本可能达数十到数百美元；abstract 没有报告端到端 cost / 收益曲线。⚠️ 原文未明确。

4. 对工程落地的启发

  1. 不重训模型的优化路径：对没有算力做 RLHF / SFT 的企业 Agent 团队，本框架提供了一条纯工程侧的优化通道——把所有 LLM 不稳定来源归类到 harness 五元组，逐项做 A/B。
  2. 失败模式分层 = 评测基线：建议在做 harness 优化前，先把所有任务按"基线失败模式"分层，把评测重心放在最容易退化的 stratum 上，避免被"简单任务"拉高平均分。
  3. 提议者-选择者分离 = 防过拟合的标准动作：哪怕手动调 prompt，也建议留一份"提议者不可见"的内部评测集，否则很快会"为了让 demo 好看"而把 prompt 写崩。
  4. 跨模型族迁移：abstract 报告 harness 在 GPT 与 Qwen 之间可迁移，这意味着 harness 本身可以作为模型切换时的稳定性兜底——切模型后不用从零调 prompt。

5. 与同方向工作的关系

  • Anthropic / OpenAI 的 Agent harness 趋势：与 2025-2026 业界把 Agent 焦点从"模型"移到"上下文工程 / harness"的趋势一致；StarHarness 是首批把这个方向系统化为可搜索范式的工作之一。
  • FunSearch / AlphaEvolve / AlphaEvolve 类进化搜索：StarHarness 与 DeepMind 的"用进化搜索 + LLM proposer 找算法"系列方法同源——都是把搜索空间限定在一类对象，让 LLM 做 proposer、用真实奖励做 selector。但 StarHarness 的搜索对象从"代码算法"换成"harness 配置"，且明确以"企业任务 + 留出集评估"为成功标准。
  • DSPy / TextGrad / PromptAgent 等 prompt 优化工作：StarHarness 与这些"自动 prompt 优化"工作重叠，但搜索空间更广——覆盖工具、subagent、agent-loop 等非 prompt 维度。
  • ACE / AETHER 等 agent 评测框架：StarHarness 提供了如何选 harness 的方法论，与 ACE / AETHER 等"如何选 agent 任务 / 评测"互补。

6. 适合谁读

  • 企业 Agent 平台架构师：把 harness 拆为五元组并显式搜索，是 Agent 平台化的方法论基础。
  • Agent eval / benchmark 团队：分层采样 + 提议者-选择者分离的范式可直接复用到新基准的评测构建。
  • 关注 harness evolution / context engineering / agent 工程化的研究者：本文是 2026 年首批把 harness 进化系统化的论文之一。
  • 不太适合：只关心模型权重改进（RLHF / SFT）的研究者，以及没有完整企业 Agent 评测环境的纯学术读者——核心数字需要在企业级环境复现才有意义。

7. 立标候选评级

⚠️ 评级口径：采纳数（venue）、数字密度、abstract 完整度、是否给出开源代码四项打分（满分 4）。本稿：

  • 采纳数：未在 abstract 标注会议 / 期刊，⚠️ 待 PDF §X 核验；arXiv v1 提交时间 2026-08-25。
  • 数字密度：abstract 给出主结论数字（20-35pp、4-12 changes、3 个基准），密度中高。
  • abstract 完整度：完整、含 trace 分析定性结论。
  • 开源代码：abstract 未提 GitHub 仓库，⚠️ 待 PDF §X 核验。

建议初评 ★★（方法论意义大，但采纳状态与代码尚未在 abstract 段核实，需 PDF 复核后再决定是否升 ★★★ 立标）。

8. 后续行动

  • 拉 PDF §X 确认搜索算法（LLM proposer / evolutionary / UCB）、提议者预算、每个基准的具体数字。
  • 核验 GitHub 仓库是否存在；若存在，与 v2 selection 重写模板对照列入 W36 立标池。
  • 跟踪是否被 EMNLP 2026 / NeurIPS 2026 / ICLR 2027 接收——决定 ★★★ 升级时机。

flyP · 2026-08-31 · 字数 ~2,950 CJK（不含元信息与代码块）· 私域污染 SUM=0 · 边界：仅写本文件 explainers/2608-24804.md