我先联网查这条消息的原始出处和具体实验数据，再成稿。
这条对应的是「Self-HPO：让 Harness 和策略交替进化」那篇论文，我去核对作者单位和实验细节。
论文确认了：微软研究院 + 弗吉尼亚大学 + 卡内基梅隆，10 月 16 日挂上 arXiv。我把正文的实验细节读一下。
论文原文、实验表和开源仓库都拿到了。以下是成稿。
微软让 Harness 和模型一起进化：代码 Agent 自己改运行框架，平均解题率 57.8% 提到 64.8%
先说结论：微软研究院联合弗吉尼亚大学、卡内基梅隆大学，10 月 16 日在 arXiv 挂出一篇论文，提出 Self-HPO—— 一个让代码 Agent 的 "运行框架（harness）" 和 "模型策略（policy）" 交替进化的框架。和以往只调一边的做法不同，它让当前模型自己去分析失败轨迹、提出 harness 改法、挑出最好的那版，然后在新 harness 下用强化学习更新模型权重，下一轮再由更新后的模型继续当 "harness 提案人"。用 Qwen3.5-35B-A3B 做基座、mini-SWE-agent 做初始 harness，在 SWE-Bench Verified、Multilingual、Pro 三个榜上，平均解题率从 57.8% 提到 64.8%，Verified 上从 61.0% 提到 69.5%。全程不需要第二个模型来出主意，代码和模型已开源在 MSR-Orchard/Self-HPO。
真正有意思的地方在于：被改的不是提示词，而是执行逻辑。论文的案例里，进化后的 harness 会加四个检查 —— 步数快用完时提前警告并催它交作业、提交空补丁时打回让它先 git add -N、第一次提交前强制核对 API 签名、补丁打不上时用沙箱里的 git diff 兜底。这些都是原来那套循环里根本没有的 "护栏"。
Harness 是什么，为什么它和模型一样重要
Harness 是包在模型外面的一层运行脚手架，决定模型看到什么、动作怎么执行、拿到什么反馈、什么时候结束。用论文里的话说，模型定义能力边界，harness 决定这些能力能被 "调用出多少"。
| 对比 | 同一个模型，不同 harness |
|---|---|
| 结果 | 可能一个任务做对，另一个做错 |
| 原因 | 上下文怎么给、工具怎么调、失败怎么反馈、何时终止，全在 harness |
| 含义 | 刷榜刷不动的瓶颈，有时不在模型，在壳子 |
这也是为什么近两年 "改 harness" 成了一门独立的手艺：Self-Harness、Meta-Harness 这类工作，都是固定模型不动，只搜提示词、工作流和 Agent 代码。
只优化一边，为什么不够
两条路各有天花板，论文把它们摆得很清楚。
| 路线 | 做什么 | 天花板 |
|---|---|---|
| 只优化 harness | 冻结模型，搜提示词、流程、代码 | 模型本身没变强，只能把已有能力逼出来 |
| 只优化 policy | 冻结 harness，用 RL 或 SFT 训模型 | 只能从固定 harness elicits 出来的轨迹里学，见不到别的失败模式 |
| 一起优化（Self-HPO） | 交替进行，互相喂料 | 目标和搜索集都跟着对方变 |
更麻烦的是 "移动靶" 问题：你为一个 checkpoint 调好的 harness，换到更新后的模型上可能就不对症了；而模型只在旧 harness 给出的轨迹里学习，也永远遇不到新问题。已有的联合优化工作大多依赖一个外部提案模型，Self-HPO 想把这件事交给自己。
Self-HPO 怎么转起来
它是一个两拍循环，每拍各干一件事。
- H-step（改壳）：冻结当前模型，让它在搜索集上跑任务、看自己的失败轨迹，提出 K 个 harness 候选（论文里 K=6）。每个候选都是在当前最优版本上做定向修改，可以改提示词，也可以改可执行代码；所有候选在同一搜索集上打分，留下最好的那版。
- P-step（训模型）：冻结刚选出的 harness，在新壳子里用强化学习更新模型。奖励是执行验证器给的 0/1 结果，优化器用 GRPO 配 Orchard 的 Balanced Adaptive Rollout（BAR），后者会额外采样轨迹来凑成有对比的奖励组，减少 "全失败、没梯度" 的空转组。
- 换靶：这一轮 P-step 里怎么跑都没解出来的任务，被标成 "难题集"，直接成为下一轮 H-step 的搜索集。
- 循环：更新后的模型接着当提案人，直到难题集在两轮之间稳定下来。
用一句大白话概括：先让 "现在的自己" 给自己挑毛病、改工具，再在新工具下练本事，练完把还搞不定的题留给下一轮。论文跑了两轮，每个 H-step 6 个候选，每个 P-step 50 次 RL 更新，训练集 2484 道题，来自 SWE-rebench、SWE-rebench V2 和 Scale-SWE。
数字说话
主结果（三次评测取平均）：
| 方法 | 改 harness | 训模型 | SWE-Verified | SWE-Multi | SWE-Pro | 平均 |
|---|---|---|---|---|---|---|
| Base | 否 | 否 | 61.0% | 54.2% | 58.3% | 57.8% |
| 只训模型（RLVR） | 否 | 是 | 67.5% | 56.3% | 61.8% | 61.9% |
| 只改 harness（Self-Harness） | 是 | 否 | 65.2% | 54.3% | 60.7% | 60.1% |
| Self-HPO | 是 | 是 | 69.5% | 59.7% | 65.2% | 64.8% |
三个细节值得单独说：
- 跨语言迁移成立。训练只用 Python 题，但 SWE-Multi 覆盖 9 种非 Python 语言，Self-HPO 仍比 Base 高 5.5 个点；而只改 harness 的 Self-Harness 在这个榜上只涨 0.1 个点。这说明 "改壳" 学到的不全是某个语言的技巧。
- 强模型当老师，改壳比蒸馏更划算。用 Opus 4.8 做提案人时，HPO 在 Verified 上到 71.6%、平均 66.3%，高于只用 Opus 4.8 优化 harness 的 Meta-Harness（69.1%／63.5%），更远高于把 Opus 4.8 轨迹蒸馏进权重的 SFT（65.0%／54.6%，且两个 OOD 榜都掉到 Base 以下）。
- 消融给出的取舍。P-step 换成 SFT 掉 4.4 个点、换成 RFT 掉 1.1 个点；H-step 复用固定搜索集掉 1.5 个点；把外部提案人换回自己掉 2.1 个点。翻译一下：RL 比微调更适配这个循环，搜索集必须跟着模型换，外部强模型是加分项但不是必需品。
它到底改了什么，看四个补丁最直观
论文把初始 harness 和进化后的版本做了逐行对比。原始循环有四种 "白干" 的失败方式，优化后的 harness 一一补上。
| 原始失败模式 | 进化后加的检查 | 效果 |
|---|---|---|
| 步数 / 时间预算耗尽，直接交白卷 | 预算阀：接近上限时提前警告，催促尽力提交 | 避免空结果收场 |
| 提交空补丁（新文件没 git add） | 空补丁守卫：打回一次，要求 git add -N | 拦住无效提交 |
| 基于猜测的 API 契约写代码 | 契约接地：第一次提交前压一次，要求对着仓库和测试核签名 | 减少 "看着对、跑不通" |
| 补丁格式坏了，打不上 | 兜底：apply 检查失败就用沙箱里的 git diff 提交 | 保住已有的有效改动 |
注意这些都是运行时逻辑的改动，不是换一句提示词。论文明确写了：harness 优化可以改执行和终止逻辑，不只是改 prompt。
为什么 "1+1 大于 2"
论文做了交叉评估，把训好的模型和改好的壳拆开配对：
| 组合 | Verified 解题率 | 相对 Base |
|---|---|---|
| Base 模型 + Base harness | 61.0% | — |
| Base 模型 + 进化后 harness | 64.5% | +3.5 |
| 进化后模型 + 原始 harness | 64.4% | +3.4 |
| 进化后模型 + 进化后 harness | 69.5% | +8.5 |
单看两边各涨 3.5 和 3.4，加起来 6.9；合在一起涨 8.5，多出 1.6 个点。这说明两者不是简单叠加，而是互相放大：壳子给模型腾出了能表达的空间，模型又把壳子教的技能内化成了权重。
另外两个指标也能佐证：pass@8 从 80.0% 提到 84.8%（能力边界扩了）；按难度拆 pass@1，中等题 +17.2、简单题 +12.9、难题 +6.1，但 "Base 本来就能稳定解出" 的那组反而 -2.2。也就是说，提升主要来自 "原来时灵时不灵" 和 "原来完全不会" 的题，代价是少数稳过的题出现了波动。训练信号上，零成功率组的占比从 RLVR 的 11%—17% 降到 6.5%，稀疏奖励下的空转明显减少。
边界和该泼的冷水
- 只验证了一个基座。全部实验用 Qwen3.5-35B-A3B，换更大或更小的模型表现如何，论文没给。
- 只跑了两轮。停止条件是难题集稳定，两轮就到头了，更多轮会不会继续涨、会不会过拟合，是开放问题。
- 训练和评测都在 SWE-Bench 家族。虽然有 OOD 榜，但同源风险仍在，真实仓库、真实多轮协作的表现没测。
- 成本没披露。两轮 H-step 各 6 个候选全量评测、两轮 P-step 各 50 次 RL 更新，算力开销不是小数，这对 "能不能复制" 是个现实门槛。
- 少数任务会退化。Resolved 组 -2.2 个点就是证据，不是全面提升。
- 开源可复现。代码在 github.com/MSR-Orchard/Self-HPO，模型在 huggingface.co/self-hpo，这点比很多只发论文的工作实在。
同一时间线上，微软在 harness 这块动作挺密集：10 月 7 日微软亚洲研究院开源 Agent Lightning v1.0，提出 "Harnessed Agentic RL"，让训练直接跑在真实 harness 里；10 月 28 日又把 GitHub 团队做的多模型 harness 通过 Microsoft Foundry 开放，支撑 Copilot Code、Copilot Studio、VS Code 等产品。一条是训练方法，一条是产品底座，Self-HPO 卡在中间，回答的是 "壳子和模型能不能互相带飞"。
结论
这篇论文的价值不在于又刷高了几个点，而在于把 "改 harness" 和 "训模型" 从两条平行线拧成了一根螺旋：模型每次变强，都会重新定义自己该被怎么用；壳子每次变好，都在给模型腾出新的表达空间。对做代码 Agent 的团队来说，最实用的一条结论是 —— 别把 harness 当成一次性写死的脚手架，它可以是一个持续迭代的变量，而且让模型自己来提修改方案，效果不比请一个更强的外部模型差太多。至于这套方法能不能从 SWE-Bench 走到真实工程，还得看算力账和更多基座的验证。
【相关 FAQ】
问题 1：Harness 和模型一起进化是什么意思，微软这篇论文做了什么？
回答 1：Harness 和模型一起进化指 Self-HPO 框架让代码 Agent 的运行框架（harness）和模型策略（policy）交替优化：模型先分析自己的失败、提出 harness 改法，再在新 harness 下用强化学习更新权重，下一轮由更新后的模型继续提案。平均解题率从 57.8% 提到 64.8%。
问题 2：为什么 Harness 和模型一起进化比只改一边效果更好？
回答 2：只改 harness 时模型本身没变强，只训模型时又只能从固定 harness 给出的轨迹里学。Harness 和模型一起进化能互相喂料：壳子暴露并补偿当前模型的弱点，模型把学到的行为内化后，又改变下一轮该改哪里。论文里联合收益 8.5 个点，超过单边收益之和 6.9 个点。
问题 3：Harness 和模型一起进化具体怎么实现，需要几个模型？
回答 3：Self-HPO 只用当前模型自己当 harness 提案人，不需要额外模型。每轮先做 H-step（提 6 个 harness 候选并选最优），再做 P-step（在新 harness 下用 GRPO 加 BAR 做 50 次 RL 更新），上一轮没解出的难题成为下一轮搜索集，论文跑了两轮。
问题 4：Harness 和模型一起进化改了哪些东西，是改提示词吗？
回答 4：不只是提示词，还改运行时逻辑。论文案例里进化后的 harness 加了四个检查：预算快耗尽时提前警告并催提交、空补丁打回并要求 git add -N、首次提交前强制核对 API 签名、补丁打不上时用沙箱 git diff 兜底。
问题 5：Harness 和模型一起进化的效果在哪些榜单上验证过？
回答 5：在 SWE-Bench Verified 从 61.0% 到 69.5%，SWE-Bench Multilingual 从 54.2% 到 59.7%，SWE-Bench Pro 从 58.3% 到 65.2%，平均 57.8% 到 64.8%。训练只用了 Python 题，但跨语言榜也有提升。用 Opus 4.8 当外部提案人时 Verified 可到 71.6%。
问题 6：Harness 和模型一起进化有什么局限，能直接用到生产吗？
回答 6：目前只验证了 Qwen3.5-35B-A3B 一个基座，只跑两轮，训练与评测都在 SWE-Bench 家族，算力成本未披露，且 "Base 本来稳过" 的任务组 pass@1 还降了 2.2 个点。代码和模型已开源（MSR-Orchard/Self-HPO），可以复现，但上生产还需更多基座和真实仓库的验证。
【参考资料】
[2026-10-29]（Agent Harness：Agent Framework 概念文档）Microsoft Learn
[2026-10-28]（Introducing the Microsoft Copilot harness: Unlocking the potential of truly multi-model agentic work）The Official Microsoft Blog
[2026-10-20]（Self-HPO Rewrites Its Coding Harness）AICrier
[2026-10-16]（Self-Evolving Coding Agents via Harness-Policy Optimization）arXiv（2610.22791）
[2026-10-07]（Agent Lightning v1.0: A 3,500-Line Lightweight Agentic RL Framework for Training Agents with Real Harnesses）Microsoft Research Blog
【免责声明】
本文依据 arXiv 论文《Self-Evolving Coding Agents via Harness-Policy Optimization》（arXiv:2610.22791，2026 年 10 月 16 日提交）原文及微软官方公开资料整理，实验数据、基座模型、训练配置、榜单结果均引自论文正文与表格，未做二次测算。论文为预印本，尚未经过同行评审，结论可能随后续版本修订；文中对工程适用性的判断为分析性观点，不构成技术选型或投资建议。开源仓库与模型权重信息以作者发布的 GitHub、Hugging Face 页面为准。