Harness 工程进入"可优化时代"：上下文、状态、组织与自进化（深度版）

导读

"智能体 = 模型 + Harness"，这句话在 2026 年已经很少有人反对。Harness 指模型之外的一切代码、配置与执行逻辑 [1]，过去常被看作"套壳"，靠经验手工调出来。

但最近几个月的证据越来越清楚：Harness 对成本、稳定性乃至最终成绩的影响，并不比换一个模型小。更值得关注的是，10 月出现的一批工作开始把 Harness 当作可度量、可学习、可自动改进的对象：

• 在上下文层，ReFold 用可逆的渲染层把 token 消耗降低 18%—60%，AutoCompact 让模型自己学会"何时压缩"；
• 在状态层，StateHarness 显式维护项目状态，把长程一致性做成了可测量的指标；
• 在组织层，微软的 Agensh 让 1,024 个智能体在没有中央调度器的情况下协作；
• 在自进化层，VERSE、RiseHarness 与 Self-HPO 分别回答了"自动改进 Harness 需要什么前提""如何从成败对照中找到改进点""Harness 和模型能否一起进化"。

本文梳理 14 个来源（5 个为背景文献），按四层结构逐一拆解，并给出判断、展望与金融场景的落地启示。

一、背景：为什么 Harness 成了独立的技术层

1.1 一个定义

LangChain 在 3 月的文章中给出了一个干脆的界定：凡是不属于模型本身的代码、配置和执行逻辑，都属于 Harness [1]。具体包括：

• 系统提示词；
• 工具、Skills、MCP 及其描述；
• 打包的基础设施，例如文件系统、沙箱、浏览器；
• 编排逻辑，例如子智能体派生、交接、模型路由；
• 用于确定性执行的钩子和中间件，例如压缩、续写、lint 检查。

1.2 两组证据

证据一：评测会把 Harness 的功劳算到模型头上。 5 月的立场论文《Stop Comparing LLM Agents Without Disclosing the Harness》[4] 认为，在前沿模型能力接近的长程任务上，表现差异更多由 Harness 配置决定，现有评测协议会把 Harness 带来的收益错误归因给模型。作者为此提出了 Harness 披露标准与方差分解协议。

证据二：同一个模型，换 Harness，成本可以差 40 倍。 6 月的《The Scaffold Effect in Coding Agents》[5] 做了一个控制实验：Qwen 3.6 Plus 与 MiniMax M2.5 分别搭配 Goose、OpenCode、OpenHands-SDK 三种开源 Harness，在 Terminal-Bench Pro 的 50 题分层子集上测试，共 300 次运行。实验有三个发现：

• 同一模型下的通过率差异只有 0—8 个百分点，95% 置信区间除最大差距外都包含 0；
• 每解出一道题的 token 消耗最多相差 40 倍；
• 各 Harness 的失败"指纹"在两个模型上可以复现：Goose 多为推理失败，OpenHands-SDK 多为验证失败或轮数耗尽，OpenCode 多为空转或超时。

作者还指出，"无动作轮次"不只是 token 税，更是人在回路中的"等待税"。两组证据合起来说明：只报告"模型名 + 通过率"是不完整的。

二、上下文层：决定模型每一步"看到什么"

2.1 规则化的成熟做法：检索、卸载、委派、分叉

上下文腐化（context rot）是 Harness 首先要处理的问题：窗口越满，模型的推理和完成任务能力越差。LangChain 在 3 月总结了几类基础手段 [1]：

• 压缩：接近上限时对已有上下文做摘要和卸载；
• 工具输出卸载：超过阈值的工具输出只保留头尾，完整内容写入文件系统，需要时再读；
• Skills 渐进披露：启动时只加载技能的元信息，避免大量工具描述一开始就挤占上下文。

10 月 23 日，LangChain 专文讨论检索 [2]，把问题归纳为搜索低效、一次塞入太多、内容无关或过时三类。Deep Agents 的做法是"先搜后读"（glob → grep → 按页 read_file）；对 RAG 类工具，则推荐"检索—卸载—委派"：结果存文件、只返回路径与预览、交给子智能体阅读。

9 月的另一篇文章 [3] 介绍了子智能体的两种上下文模式：isolated（全新上下文，只收到任务描述）与 fork（继承主管的完整对话，省去重复收集背景，并兼容提示缓存）。

这些做法有效但大多由规则驱动。10 月的两项工作分别从"不训练"和"训练"两个方向往前推进。

2.2 ReFold：可逆的上下文折叠

问题。智能体的交互历史只追加不删除，每一步都要把全部历史重发一遍。假设每轮长度大致恒定，T 步累计处理的上下文量按 Θ(T²) 增长。已有的上下文管理方法有三个代价 [6]：

• 需要额外的模型调用或训练好的策略来预测"哪些内容以后用不到"；
• 改写历史会让前缀缓存失效；
• 删掉的内容无法恢复。

作者的动机实验（16K 预算、50 道 SWE-bench Verified 题）给出了两个具体观察：其一，完整历史下工具输出只占 KV 缓存峰值的约 59%，只裁剪工具输出的方法动不了智能体自己不断累积的命令与推理，仍有 38%—86% 的会话超出预算；其二，摘要式压缩中位每题调用 4 次摘要、每次约 38 秒，额外增加约 152 秒耗时，占总成本的 14%。

机制。 ReFold 不改历史，只改"渲染给模型看的那一份"。它定义渲染函数 c_t = R(h_t)，并用两个算子和一个边界规则实现：

• 去重：同一文件片段或命令输出再次出现时，保留第一次，后续换成一行存根，注明"与第 k 步相同，可用 restore 恢复"；
• 折叠：智能体在每次回复前附带两个字段，一个是 progress（一句话说明这一步在做什么），一个是 stale（声明哪些步骤的输出已经用不到）。被声明的轮次折叠成一行进度注记，并保留函数签名、搜索命中等要点；
• 分块边界：边界每 k 步（论文取 k=3）才前移一次，最近的轮次完整保留；两次前移之间，渲染结果严格只追加，KV 缓存可以完整复用。

实验。在 mini-swe-agent 上，用 Qwen3.6-27B（稠密）和 Qwen3.6-35B-A3B（MoE）各测了 5 个基准、每个 50 题：

• 解出题数变化在 −1 到 +3 之间，在作者测得的运行间波动范围内；
• 两种模型的 token 消耗分别降低 18%—53% 和 42%—60%；
• 单会话 KV 缓存峰值分别降低 39%—58% 和 30%—55%；
• 计入缓存折扣后，估算成本分别降低 2%—35% 和 18%—45%。

在受限预算下，ReFold 最多避免了 92% 的强制压缩；在并发服务场景下，推理速度最高提升到 1.7 倍。

局限。折叠依赖智能体如实声明 stale 字段，声明错误时需要一次恢复操作；实验集中在代码与终端任务，后端为开源模型自部署，闭源 API 的计费方式会影响成本结论（论文附录补充了一个闭源模型的结果）。

算法拆解 1：ReFold 的渲染函数

• 一句话直觉：档案原件全部保留，只是每次开会时给大家发一份"去掉重复页、把已结案部分换成一行摘要"的简报。
• 生活类比：律师的案卷不会销毁，但出庭时只带"索引 + 关键页"。需要哪一页，随时去档案室调。
• 公式（论文式 4、6、7）：

S_t = S_{t−1} ∪ ( stale_t ∩ {t−k, …, t−1} )
b_t = max(0, k · ⌊(t − k) / k⌋)
c_t = p_sys ⊕ p_task ⊕ ⊕_{i=1..t}  { f_i          若 i ≤ b_t 且 i ∈ S_t
{ a_i ⊕ o_i    若 i > b_t
{ a_i ⊕ d_i    其他

• h_t：截至第 t 步的完整交互历史，只追加、不修改
• a_i、o_i：第 i 步的动作（含推理与工具调用）和环境观察
• stale_t：智能体在第 t 步声明"已不再需要"的步骤编号；ReFold 只接受最近 k 步内的声明
• S_t：累计被标记为"已用完"的步骤集合
• b_t：分块边界，每 k 步前移一次；编号大于 b_t 的轮次完整保留
• f_i：折叠注记，即 progress_i 加上从输出中摘出的要点
• d_i：去重后的观察，重复片段被换成存根
• ⊕：拼接
• 步骤：1. 每步把新轮次追加进历史 h_t；2. 解析智能体回复里的 progress 与 stale 字段，更新 S_t；3. 计算边界 b_t，边界之后的轮次原样渲染；4. 边界之前的轮次，已用完的换成折叠注记，其余做去重；5. 智能体发出 restore 命令时，由 Harness 直接从历史中取回原文，不转发给环境。
• 示例（数字取自论文表 1）：Qwen3.6-27B 在 SWE-bench Verified 上，每任务 token 从 96.5 万降到 50.5 万，步数从 50 降到 41，解出题数都是 38。步数减少的原因论文没有做因果分析，我们推测与上下文中干扰信息变少有关。
• 为什么有效：两个算子都不需要额外的模型调用；边界每 k 步才动一次，兼顾了压缩率与缓存命中；历史原件不动，误删的代价只是一次恢复，而不是永久丢失。
• 何时失效：任务高度依赖逐字比对早期输出（例如需要反复对照日志原文）时，频繁恢复会抵消收益；智能体若不认真填写 stale 字段，折叠就退化为单纯去重。

2.3 AutoCompact：让模型自己决定"何时压缩"

问题。规则化压缩的触发条件是"快满了"。可是编码任务里，前期的探索信息会逐渐过时，即使窗口没满，它们也在干扰模型。作者的初步实验发现，仅靠提示词，基础模型几乎从不主动压缩 [7]。

机制。给智能体增加一个 compact() 动作。调用后，以"# Auto Context Summary"开头的工作状态摘要替换此前的交互历史，原始任务描述保持不变。训练分两阶段：

• 评审引导的在线数据收集 + SFT：让基础模型跑 379 个 SWE-rebench 任务，由评审模型（GPT-5.5-Codex）逐步审查。审查覆盖三类决策：何时压缩、摘要保留什么、压缩后如何继续。不合格的输出被替换为修正版本，并且在环境中真实执行，后续轨迹从修正后的状态继续生成。最终得到 1,052 条轨迹，其中 24% 监督触发时机，53% 监督工作状态的构建，23% 监督压缩后的续写。
• 联合强化学习：在 SWE-Gym 上用 GRPO，每题采样 8 条轨迹，只用"补丁是否通过测试"作为二元奖励，没有任何压缩专用的奖励设计。

实验。基座为 Qwen3-Coder-30B-A3B，三次运行取平均：

• SWE-bench Verified 从 30.4% 升至 39.6%，SWE-PolyBench Verified 从 19.5% 升至 24.5%；
• 固定长度触发的压缩反而比基线低 1.6 和 0.9 个百分点；
• 在 256K 窗口下（没有任何轨迹达到强制压缩阈值），主动压缩依然有效。这说明压缩不只是防溢出，更是清理过时信息的手段；
• RL 之后，主动调用 compact() 的任务占比从 44.3% 升到 58.5%，摘要遗漏关键状态的比例从 3.1% 降到 0.2%，遗漏下一步动作的比例从 8.2% 降到 2.2%。

局限。只在编码任务和一个 30B 级基座上验证；摘要遗漏率靠关键词筛查加人工抽检统计；数据依赖强评审模型。

算法拆解 2：在线纠错式数据收集

• 一句话直觉：不是事后在成功轨迹里"插入"压缩动作，而是在智能体运行时实时纠正，并让纠正后的动作真正执行下去。
• 生活类比：教练陪练和看录像复盘不同。陪练时教练当场纠正动作，学员接着按纠正后的动作打下去，后面的局面也随之改变；看录像只能指出问题，改变不了后面发生的事。
• 步骤：1. 基础模型在环境中逐步行动；2. 每一步，评审模型只看当前已有的历史，按标注协议判断该动作是否合适；3. 不合适时，评审写出修正版本，环境执行修正版本；4. 模型从修正后的历史继续生成后续动作；5. 收集完整轨迹，用标准的下一个 token 预测目标做 SFT；6. 在 SFT 模型上做 GRPO：同组 8 条轨迹按成败计算相对优势，统一作用于编码动作、压缩决策、摘要文本和压缩后的续写。
• 公式（GRPO 的组内优势，标准做法见 [14]）：

A_i = ( r_i − mean(r_1..r_G) ) / std(r_1..r_G)

• r_i：第 i 条轨迹的奖励（补丁通过测试为 1，否则为 0）
• G：组大小（论文中为 8）
• A_i：该轨迹所有模型生成 token 共享的优势
• 示例：同一道题采样 8 条轨迹，3 条成功。成功轨迹的优势约为 (1 − 0.375) / 0.48 ≈ +1.29，失败轨迹约为 −0.78。如果成功轨迹恰好都在"定位到 bug 之后"调用了 compact()，那么这个时机就会被强化。
• 为什么有效：与离线插入相比（SWE-Compressor 就是在已完成的轨迹里插入压缩调用、保留原有后续动作），在线纠错让模型看到"压缩之后应该怎么接着做"。两者在同等数据量下，前者高 1.2 和 1.6 个百分点。RL 阶段再用任务成败把"压缩"与"解题"绑在一起优化。
• 何时失效：评审模型的判断标准决定了 SFT 的上限；二元奖励稀疏，组内全对或全错时没有学习信号；跨领域（如文档分析）时，"阶段是否完成"的判断更模糊。

三、状态层：从"放得下"到"记得住重点"

3.1 StateHarness：显式维护项目状态

问题。压缩解决的是"放不下"，长程任务还有一个"记不住重点"的问题：已经排除过的原因又被重新怀疑，几步前发现的调用方被遗忘，开了头的工作没有收尾 [8]。

机制。 StateHarness 不更新模型参数，而是在运行时维护四类持久记录：

• 任务状态：初始观察、环境信息、当前子问题与假设；
• 事件日志：重要发现、修改、测试结果、决定和转向理由；
• 关联笔记：与调用方、测试、文档、配置等的关联；
• 流程指引：反复失败的做法，以及后续应正常使用、需显式验证还是应避免。

在这四类记录之上，还有四个运行机制：

1. 工作简报：由固定规则从记录中刷新，不额外调用模型做摘要；
2. 变更影响检索：在修改接口、删除源文件等操作前，先搜索可能受影响的位置，作为候选交给智能体逐一判断；
3. 收尾协议：结束前回看原始需求、关联记录、相关测试与未决警告，每项要么处理，要么记录不需处理的理由；
4. 诊断会话：监控"反复读同一文件""长时间不看简报"等信号，先提醒，信号持续累积时启动一个独立会话回看完整日志，给出建议。

实验。同一模型 Claude Sonnet 5，与原版 Claude Code 对比：

• RefactorBench 全链完成率从 29.4% 升至 35.3%，清理检查准确率从 87.0% 升至 95.4%。其中导入语句 +11.7、文档 +9.1 个百分点，调用点则没有变化；
• 5 个 LHTB 软件工程任务的平均奖励从 0.427 升至 0.576；
• ChainSWE 的修复率从 35.1% 升至 39.5%，残留技术债从 60 项降到 43 项，但 pass-to-pass 回归从 16 增加到 23；
• 开销同步上升：在 ChainSWE 上 token 从 24.9K 增到 35.3K，工具调用从 75 次增到 96 次，耗时从 300 秒增到 383 秒。不过与另一个"经理—执行者—审计者"三角色框架相比，StateHarness 的 token 只有其约六分之一（35.3K 对 208.0K），修复率反而更高。

局限。作者如实报告了回归增加。维护状态能提升长程一致性，但不能保证"以前通过的继续通过"，任务完成与变更一致性是两个相关但不同的目标。另外，所有实验都基于同一个闭源模型。

算法拆解 3：状态记录 + 规则化简报 + 信号触发诊断

• 一句话直觉：给智能体配一本"项目工作底稿"，并规定什么时候必须翻看、什么时候请人复核。
• 生活类比：医院的病历加交班制度。病历记录诊断与用药，交班时只讲要点；病情反复时，另请一位医生调阅全部病历会诊。
• 步骤：1. 智能体在执行中更新四类记录，假设改变时替换当前焦点，并在事件日志里留下转向理由；2. Harness 用固定规则刷新工作简报，只展示当前子问题、流程指引、最近事件与诊断提示；3. 执行受支持的修改前，先做变更影响检索，候选位置由智能体逐一确认、记录处理结果；4. 监控行为信号：信号较弱时只发提醒，持续累积时才启动诊断会话；5. 结束前执行收尾协议，逐项核对关联制品。
• 伪代码：

on_event(e):
records.append(e)                       # 事件日志只追加
brief = refresh_by_rules(records)       # 不调用 LLM
if e.is_interface_change():
candidates = repo_search(e.symbol)  # 候选，不是确定依赖
agent.inspect(candidates); records.add_relations(...)
signals.update(e)
if signals.weak():   agent.remind(brief)
if signals.strong(): brief.alerts += diagnose(records)  # 独立会话
before_finish():
for item in requirements ∪ relations ∪ open_warnings:
handle(item) or record_reason(item)

• 示例（改写自论文第 3.3 节）：修改一个数据加载函数的接口后，影响检索找到一个服务调用方和一个命令行入口。智能体先更新服务调用方，并在关联笔记里记下"命令行入口待检查"；测试结果写入日志后，简报刷新，后续决策能区分已完成和未解决的后果。
• 为什么有效：把"记住"搬到外部记录，把"想起来"交给规则和信号。
• 何时失效：变更影响检索只覆盖预定义的几类操作；诊断建议可能引入新的修改，从而带来回归（ChainSWE 上的回归增加可能与此有关，但论文没有给出归因，这里只是我们的推测）。

四、组织层：去掉中央调度器的 1,024 智能体

4.1 Agensh：组织智能可以作为新的扩展维度

问题。多智能体 Harness 的常见瓶颈是中央调度器：任务分配和协调都压在一个节点上，规模一大就成为瓶颈 [9]。

机制。 Agensh 叠加在单智能体 Harness 之上（实验中使用 Copilot），不替换它。每个工作者并发、异步地执行五步协作循环：

1. 收集上下文：读取目标、当前状态、同伴进展与已有发现；
2. 认领子任务：把认领范围作为 CLAIM 写入共享上下文，冲突时通过私信协商；
3. 行动：在本地完成子任务，有用的中间发现随时共享；
4. 验证：对照子任务的验收标准，不满足就继续修改；
5. 合并：合入共享工作区，并发布"改了什么、为什么、验证证据"。

支撑这个循环的基础设施有三部分：

• 共享工作区：用 Gitea 承载，工作者在私有分支开发，合入主分支；
• 消息接口：用 Mattermost 承载，频道广播与私信分优先级投递；
• 共享上下文：按类型记录 OBSERVED、FACT、FAIL、CLAIM、PATCH_SUMMARY 等条目，只追加，可全文检索。

协作循环写在每个工作者的提示词里，除了工作者编号，所有人的提示词完全相同。

实验。在 ProgramBench 中难度较高的 5 个任务上（FFmpeg、gromacs、pandoc、PHP-src、ctags；6 小时预算，禁止联网；模型为 GPT-5.6-sol 高推理档位）：

• 平均最终测试通过率随智能体数量上升：1 个为 19.31%，8 个为 20.68%，32 个为 26.52%，128 个为 28.78%，相对提升约 49%；
• pandoc 任务上，1 个为 33.89%，128 个为 50.94%，1,024 个为 55.06%；
• 更大的组织更早达到同等水平：pandoc 上 128 个智能体在 30 分钟检查点就超过 30% 通过率，32 个和 8 个分别要到 60 和 90 分钟。

作者还观察到，随着规模扩大，约定接口、多人评审、按经验选评审人、标准化集成流程等分工会自发出现。

局限。论文没有报告不同规模下的 token 或费用（我们在全文中没有找到相关数字），1,024 个智能体的实验也只在 pandoc 一个任务上进行；任务都可以用测试用例自动评分，对需要人类判断的业务任务，协调成本与收益尚待验证。

五、自进化层：让 Harness 优化 Harness

5.1 前情：Meta-Harness

3 月的 Meta-Harness [10] 给出了自动搜索 Harness 代码的可行性证明：一个智能体提议者通过文件系统访问所有历史候选的源码、得分和执行轨迹，据此提出新的 Harness。它在在线文本分类上比已有的上下文管理系统高 7.7 个百分点，同时少用 4 倍上下文 token；在 TerminalBench-2 上，发现的 Harness 超过了手工设计的基线。

但随之而来有两个问题：

• 在同一个基准上搜索、同一个基准上报告，收益可能来自过拟合；
• 提议者自身的工具和流程是固定的，能不能也让它进化？

5.2 VERSE：没有验证，自我进化会变差

问题。如果优化器不仅改执行者的 Harness，也改自己"诊断失败、开发修改、测试效果"的方式，会不会更好 [11]？

关键对照（观察 1）。优化器为 Qwen3.8-Flash-Next，执行者为 Qwen3.8-27B，在 SWE-rebench 上进化 6 轮，按严格划分的训练、验证、测试集评估：

没有验证时，没有任何一轮在验证集上超过第 0 轮，验证集最终选回了初始 Harness。优化器无法在提交前检验修改，就会被嘈杂的反馈误导，把错误的"教训"写进自己的 Harness。

观察 2。在 5 个执行者上运行带简单验证的自我进化优化器，它一共自建了 51 个制品，大致分为四类：归因工具、验证检查、训练审计笔记和工作流规则。

机制。 VERSE 把这四类能力作为起点直接提供，并允许优化器继续改进自己：

• 归因 + 轨迹最小化：重跑失败轨迹的步骤子集，只保留仍能复现同一错误的少数步骤。重放研究中，失败轨迹的中位长度从 129 步缩到 8 步；
• 三个验证工具：verification 检查草稿是否修复了目标任务（连续通过两次才算修复），replay 检查失败是否可复现，perturbation 删除或替换某一步后重放，检查失败是否依赖这一步；
• 训练审计：逐轮跟踪每种失败模式在哪些训练任务上仍然存在；
• 优化器自我更新：每轮结束最多用 30 轮对话修改自己的提示词、技能、工具、钩子与笔记。

实验。 VERSE 接到 4 个已有的 Harness 优化器上。带自我进化时，在全部 16 组比较中都超过对应基线，幅度为 0.6—10.3 个百分点。表现较好的 Harness 在分布内测试集达到 42.3%，在五种语言的分布外新任务上达到 37.7%，对比基线中较强者的 39.2% 和 29.3%。代价是更长的进化时间：以 Meta-Harness 为宿主时，从 21.6 小时增加到 38.0 小时，执行者 token 从 5.5 亿增加到 6.34 亿。

算法拆解 4：双层优化 + 执行验证

• 一句话直觉：内层改执行者的 Harness，外层改"改 Harness 的方法"；两层都必须用跑出来的结果说话。
• 生活类比：一个培训部门既要改进员工的操作手册（内层），也要改进自己"编写手册"的流程（外层）。新手册上线前必须找几位员工试用，否则改得越勤，可能错得越多。
• 公式（论文式 2）：

内层：h_{t+1}(g) ∈ argmin_{h ∈ C_t(g)}  L̂_train(h)
外层：min_g  E[ L̂_val( h_{t+1}(g) ) ]

• h：执行者的 Harness（提示词、工具、工作流）
• g：优化器自己的 Harness（提示词、技能、工具、钩子、笔记）
• C_t(g)：第 t 轮在预算内生成的候选集合，生成方式取决于 g
• L̂_train、L̂_val：训练集和验证集上的经验损失（失败为 1，成功为 0，取平均）
• 最终 Harness 按验证集选择，测试集只用于报告
• 步骤：1. 在训练任务上运行当前 Harness，收集失败轨迹；2. 用轨迹最小化定位关键步骤，用 replay 确认可复现，用 perturbation 确认因果；3. 起草修改，用 verification 在目标任务上连续跑两次确认修复，再提交；4. 训练审计记录哪些失败被消除、哪些回归；5. 轮末，优化器根据验证集表现与工具使用情况修改自己的 g；6. 所有轮次结束后，按验证准确率选出最终 Harness。
• 示例（改写自论文第 3.2 节的建模）：某次工具调用失败，可能是超时，也可能是参数错误，两种原因的修复方式不同。直接看轨迹时两种假设都说得通；perturbation 把可疑的那一步换成正确参数后重放，失败消失，于是确认是参数问题，修复方向就明确了。论文把这类情形建模为二元假设检验，并证明：每做一次"结果依赖于真实原因"的检查，选错修复的概率上界都会乘上一个小于等于 1 的系数而收紧；反之，如果只是反复重读已有证据，误差存在一个无法突破的下界。作者的重放研究也印证了"光读不跑"的局限：让大模型阅读轨迹找出被注入的错误步骤，只有 57.3% 的情况能指认该步或其相邻步骤。
• 为什么有效：执行验证把"我觉得这样改会好"变成"跑过了确实好"，切断了噪声反馈向优化器自身的传导；验证集选择与严格的数据划分降低了过拟合。
• 何时失效：验证预算有限，一次通过可能是运气（所以要求连续通过两次）；验证集反馈本身也会泄露信息，论文附录给出了这一偏差的上界分析；任务若没有可执行的判定，验证工具就无从使用。

5.3 RiseHarness：从"同一任务有成有败"中找改进点

问题。长程终端智能体经常是"跑一次成功，重复跑却失败"。平均成功率掩盖了这种不稳定 [12]。

机制。 RiseHarness 专门挑选同一配置下"有成有败"的翻转任务，用成功运行作为参照分析失败。分析时结合两类轨迹：智能体轨迹，以及运行时监控记录的 Harness 内部轨迹（函数调用、参数、返回值、异常、源码位置）。之所以要看后者，是因为模型请求的命令可能没被派发，终端输出也可能没有完整返回给模型。一本"Harness 手册"把这些证据关联到具体的 Harness 行为和源码。随后，系统去其他 Harness 框架中检索相关实现作为设计参考，改造出候选版本，经过行为检查和重复评估，测得有收益的版本才进入下一轮。作者明确把特定模型作为 Harness 适配的单位。

实验。以 Terminus-2 为起点、在 Terminal-Bench Hard（100 题）上进化，每题重复 4 次：

• DeepSeek-V4-Flash：Pass@1 从 56.75% 升至 64.00%，4 次全过的任务占比从 37% 升至 51%，翻转率从 34% 降至 22%；
• GPT-6-sol：Pass@1 从 50.25% 升至 55.50%，4 次全过从 39% 升至 46%，翻转率从 20% 降至 14%；
• 冻结后迁移到未参与进化的 Terminal-Bench 2.1，两个模型的 Pass@1 分别提升 7.3 和 3.09 个百分点（DeepSeek 使用在 TB2.1 上观测最好的版本）。

消融实验显示，去掉 Harness 内部轨迹与手册、或去掉外部实现检索，效果都会下降。

一个值得借鉴的评估细节：论文同时报告 Pass@1、Pass^r（r 次全过）、Pass@r（至少过一次）与 Flip = Pass@r − Pass^r。作者提醒，Flip 降低不一定是好事，翻转任务也可能变成全败任务，所以必须与 Pass^r 一起看。

5.4 Self-HPO：Harness 与模型一起进化

问题。只优化 Harness 或只优化模型都不够：为某个检查点调好的 Harness，未必针对更新后策略的失败模式；而固定 Harness 下的策略学习，也只能从这个 Harness 引出的轨迹中学 [13]。

机制。 Self-HPO 交替执行两步：

• H 步：冻结当前策略，让它分析自己在搜索集上的失败，提出 K=6 个 Harness 候选，保留得分最高者；
• P 步：冻结新 Harness，用 GRPO 加上平衡自适应采样做强化学习。训练中从未解出的任务成为下一轮 H 步的搜索集。

实验。基座 Qwen3.5-35B-A3B，种子 Harness 为 mini-SWE-agent，交替两轮：

• SWE-bench Verified 从 61.0% 升至 69.5%；三个基准平均从 57.8% 升至 64.8%，比只做强化学习高 2.9 个百分点；
• 交叉评估：只换 Harness 时为 64.5%，只换策略时为 64.4%，两者组合为 69.5%。联合增益 8.5 个百分点，比单独增益之和（6.9）多 1.6；
• 用 Opus 4.8 作外部提议者时，通过 Harness 优化"学习"强模型，比直接蒸馏它的轨迹更有效：SFT 蒸馏在两个分布外基准上反而低于基线，Meta-Harness 方式则在两者上都有提升；
• 收益并不均匀：在基线原本已解出的任务组上，pass@1 下降了 2.2 个百分点。

算法拆解 5：Harness—策略交替优化

• 一句话直觉：先给运动员换一套更合适的装备，再在新装备下训练；训练后暴露出的新短板，决定下一轮换什么装备。
• 生活类比：赛车团队的"调校—试驾"循环。车手试驾后反馈问题，工程师调校赛车；车手适应新调校后能力提升，又会暴露出新的问题。
• 目标函数（论文式 1）：

J(H, P) = E_{x∼D} E_{τ∼π_{H,P}(·|x)} [ y(x, τ) ]

• H：Harness；P：策略（模型）
• x：任务；τ：在 H 与 P 下产生的轨迹
• y(x, τ) ∈ {0, 1}：可执行验证器的判定
• J：期望解决率
• 伪代码（据论文算法 1 简化）：

S ← 从训练集 D 随机抽样
repeat:
# H 步：策略不动，自己提 Harness
best ← H_t
for k in 1..K:
H_k ← P_t.propose(best, failures_on(S))
if score(H_k, P_t, S) > score(best, P_t, S): best ← H_k
H_{t+1} ← best
# P 步：Harness 不动，训练策略
P_{t+1}, rollouts ← RL(H_{t+1}, P_t, D)
S ← {从未解出的任务 in rollouts}
until S 在两轮之间趋于稳定

• 示例（取自论文表 3）：H₂ 配原始策略 64.5%，P₂ 配原始 Harness 64.4%，H₂ 配 P₂ 69.5%。多出来的 1.6 个百分点，可以理解为"新 Harness 让新策略学到的能力更容易发挥出来"。
• 为什么有效：H 步针对的是当前策略的真实失败，P 步在更合适的 Harness 下采样，得到更多有效的训练信号。论文还观察到，训练中"全组零成功"的情况变少了。
• 何时失效：需要能做强化学习的开源模型与可执行验证器；Harness 与策略深度耦合后，单独替换任一方的收益会打折；论文中两轮之后即停止，更多轮次是否持续有效尚无证据。

六、横向对比与演进逻辑

把这些工作串起来，可以看到三条演进线索：

1. 从"手工 + 规则"到"学习 + 搜索"。上下文管理从"快满了就压缩"，发展到 AutoCompact 让模型自己判断时机；Harness 设计从工程师手调，发展到 VERSE、RiseHarness 自动搜索，再到 Self-HPO 与模型一起训练。
2. 从"省 token"到"可复用、可追溯"。 ReFold 强调可逆，StateHarness 强调记录可回看，Agensh 用 Git 与消息记录保存每一次协作。好的 Harness 不只是省钱，还要让过程可以复查。
3. 从"在测试集上调"到"严格划分 + 执行验证"。 VERSE 的三分法与执行验证、RiseHarness 的重复评估，都在回应 Harness 优化容易过拟合、容易自我欺骗的问题。

七、我们的观点

观点一：评估单位应当是"模型 × Harness"组合，而不是模型。 40 倍的成本差异、可复现的失败指纹、1+1>2 的联合增益，都说明 Harness 不是中性的容器。选型和对外披露时，应同时记录 Harness 版本、token 消耗、时延与失败类型。

观点二：执行验证是 Harness 自动化的前提，不是锦上添花。 VERSE 的对照结果值得反复强调：没有验证的自我进化，表现比不进化还差。这与本系列 Agent 篇的结论一致：没有证据支撑的"自我改进"，可能只是自我强化的错觉。

观点三：上下文管理的重心正在从"压缩率"转向"信息的可恢复性与时效性"。 ReFold 的可逆设计和 AutoCompact"未溢出也压缩"的发现指向同一件事：问题不在于窗口放不下，而在于过时信息干扰判断。压缩的评价标准应该是"决策质量"，而不只是"省了多少 token"。

观点四：显式状态与可审计性天然契合。 StateHarness 的工作底稿、Agensh 的共享工作区与消息记录，本质上都把智能体的内部状态外化为可读、可查的工件。对强监管行业，这类设计的价值可能首先体现在合规上，其次才是性能。

观点五：多智能体扩展有收益，也有边界。 Agensh 的任务都有自动判分且未披露成本；对需要人类判断的业务任务，大规模并行是否划算仍待验证。

八、未来展望

8.1 未来 6—12 个月

• Harness 披露成为评测惯例：基准与论文会更多地报告 Harness 配置、token 与时延，"模型 × Harness"的组合榜单可能出现。
• 可逆、缓存友好的上下文管理成为默认选项：类似 ReFold 的渲染层设计不需要训练、即插即用，预计会被主流框架吸收。
• "压缩"进入模型训练目标：主动压缩、工作状态摘要等能力可能成为编码模型后训练的常规组成部分。
• Harness 优化工具链成形：轨迹最小化、重放、扰动等验证工具，可能以开源组件的形式出现。

8.2 未来 1—3 年

• Harness 与模型联合发布：模型厂商可能同时发布"为该模型调优的 Harness"，就像今天同时发布推理参数建议。RiseHarness"以模型为单位适配"的思路会被广泛采用。
• 组织规模成为新的扩展维度：在有硬性时间约束、可自动验收的任务上（如大型代码迁移），数百到上千个智能体并行可能进入工程实践，成本核算与协调协议会成为研究重点。
• Harness 治理成为企业 IT 的新职能：提示词、工具定义、编排逻辑、压缩策略被纳入版本管理、变更审批与回归测试，类似今天对模型与策略的管理。

8.3 对金融与风控的含义

金融机构引入智能体，难点往往不在模型，而在 Harness：数据权限、工具审计、上下文边界、出错回溯。这批研究说明这些问题都可以被工程化、被度量，甚至被自动优化，但在金融场景中，自动优化必须配上验证与审批闸门。

九、落地启示

结合我们在风控决策系统上的经验，给金融团队五条建议：

1. 把 Harness 当作受管资产。提示词、工具定义、编排逻辑、压缩策略都应纳入版本管理、变更审批与回归测试，像管理评分卡和策略规则一样管理 Harness。
2. 上下文最小化与数据合规是一回事。 "检索—卸载—委派"天然契合金融数据的"最小必要"原则：主智能体只看到与当前决策相关的摘要和路径，敏感原始数据留在受控存储中，按权限读取。ReFold 式的"原件保留、渲染压缩"也满足审计留痕的要求。
3. 显式维护"案件状态"。参照 StateHarness，尽调或调查类智能体应维护结构化的案件状态：已核实的事实、待核实的疑点、已排除的假设、未完成的步骤。它既是智能体的工作记忆，也是交给审批人的工作底稿。
4. 选型时测"组合"而非"模型"。评估供应商方案时，要求提供模型与 Harness 的完整配置，并在自己的样本上同时测通过率、token 成本、重复运行的稳定性（Pass^r 与翻转率）和失败类型。
5. 自进化要有闸门。自动优化 Harness 的机制在金融场景中必须带上执行验证与人工审批：每次改动要有原因、有测试、有记录，未经验证的改动不得上线。

对弘犀来说，风控决策引擎本身就是一种高度工程化的"Harness"：规则编排、模型调用、数据接入、审批流转、监控告警。把大模型智能体纳入这套成熟的治理框架，而不是另起一套不受管的运行环境，是更稳妥的路径。

结语

Harness 正在经历从"手艺"到"工程"、再到"可学习对象"的转变。10 月的这批研究给出了清晰的路线图：上下文要可逆、要有时效性，状态要显式、可回看，组织要去中心化、可追溯，自进化必须以执行验证为前提，最好与模型一起进化。模型决定能力的上限，Harness 决定这种能力能否被稳定、经济、可审计地发挥出来。

参考文献

1. [1] Trivedy, V.（LangChain）. The Anatomy of an Agent Harness. LangChain Blog, 2026-03-10（背景）. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
2. [2] Weng, J.（LangChain）. Context Engineering Starts with Retrieval. LangChain Blog, 2026-10-23. https://www.langchain.com/blog/context-engineering-starts-with-retrieval
3. [3] Bengre, T., Curme, C.（LangChain）. Organizing Context in a Multi-Agent Harness. LangChain Blog, 2026-09-08. https://www.langchain.com/blog/organizing-context-in-a-multi-agent-harness
4. [4] Zhang, Y., Wang, J., Ge, Y., et al. (incl. Reddy, C. K.). Stop Comparing LLM Agents Without Disclosing the Harness. arXiv:2605.23950, 2026-05-07（背景）. https://arxiv.org/abs/2605.23950
5. [5] Vats, N., Golev, O. The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation. arXiv:2607.22585, 2026-06-08（背景）. https://arxiv.org/abs/2607.22585
6. [6] Su, Y., Tian, J., Zhang, Z., Kundu, S. ReFold: Training-Free Reversible Inter-Turn Context Folding for Long-Horizon Agents. arXiv:2610.07863, 2026-10-06. https://arxiv.org/abs/2610.07863
7. [7] Zhang, X., Zheng, L., Du, C., An, B., Dong, X. AutoCompact: Learning When to Compact Context in Long-Horizon Coding Agents. arXiv:2610.02163, 2026-10-01. https://arxiv.org/abs/2610.02163
8. [8] Zou, C., Zhou, Y., Luo, X., Zhang, X. StateHarness: Maintaining Evolving Project State for Long-Horizon Coding Agents. arXiv:2610.17616, 2026-10-13. https://arxiv.org/abs/2610.17616
9. [9] Zhan, Z., Song, T., Dong, L., et al. (incl. Wei, F.; Microsoft Research). Agensh: Scaling Organizational Intelligence to 1,024 Agents. arXiv:2609.26781, 2026-09-22；开源仓库 2026-10-24. https://arxiv.org/abs/2609.26781 ；https://github.com/microsoft/Agensh
10. [10] Lee, Y., Nair, R., Zhang, Q., et al. (incl. Khattab, O.; Finn, C.). Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052, 2026-03-30（背景）. https://arxiv.org/abs/2603.28052
11. [11] Wang, Z., Ge, Y., Wang, Z., et al. (incl. Wilson, A. C.; Reddy, C. K.). VERSE: Verified Self-Evolving Optimizer for Agent Harnesses. arXiv:2610.02616, 2026-10-02. https://arxiv.org/abs/2610.02616
12. [12] Wang, R., Shi, Y., Li, Z., et al. (incl. Mi, H.). Harness Self-Evolution for Long-Horizon Terminal Agents（RiseHarness）. arXiv:2610.27435, 2026-10-20. https://arxiv.org/abs/2610.27435
13. [13] Wei, Z., Yao, W., Peng, B., Wang, D., Wu, Q., Cheng, H., Meng, Y., Gao, J. Self-Evolving Coding Agents via Harness-Policy Optimization. arXiv:2610.22791, 2026-10-16. https://arxiv.org/abs/2610.22791
14. [14] Shao, Z., Wang, P., Zhu, Q., et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models（GRPO 出处）. arXiv:2402.03300, 2024-02-05（背景）. https://arxiv.org/abs/2402.03300

弘犀研究 · 前沿 AI 深度综述 · 弘犀智能