论文链接：arxiv.org/abs/2606.01779 代码仓库：github.com/mingju-c/HarnessForge 发表时间：2026年6月 机构：北京航空航天大学（未来区块链与隐私计算北京先进创新中心，人工智能学院）、清华大学 合著标注：这是典型的高校联合研究，核心团队来自北京航空航天大学人工智能学院（第一作者 Mingju Chen，通讯作者 Shiji Zhou），项目由清华大学的 Heng Chang 领导。Guibin Zhang 为共同作者。
一、论文背景
1.1 LLM Agent 的核心公式：Agent = Model + Harness
2025 年以来，大语言模型（LLM）的能力飞速增长，但一个越来越被重视的事实浮出水面：模型再强，如果外围的执行系统设计不当，Agent 的实际表现依然很差。
这催生了一个核心公式：
$$\text{Agent} = \text{Model} + \text{Harness}$$其中，Harness（执行框架/脚手架） 指的是模型之外的整套系统——包括系统提示词、工具调用接口、编排逻辑、验证机制、反馈回路、重试恢复策略、记忆管理等一切让模型从"能说"变成"能做"的基础设施。
一个直观的类比：模型是 CPU，Harness 是操作系统。CPU 再快，如果操作系统天天崩溃，用户体验也不会好。
1.2 Harness 中的三个执行层组件
HarnessForge 将 Harness 进一步拆解为三个执行层组件：
| 组件 | 符号 | 职责 | 通俗解释 |
|---|---|---|---|
| Planning（规划） | $\mathcal{P}$ | 任务分解、重规划、终止决策 | “这个大任务怎么拆成小步骤？做不下去了怎么调整？” |
| Action（动作） | $\mathcal{A}$ | 工具接口、角色分配、编排规则 | “用什么工具做事？谁来做什么？” |
| Memory（记忆） | $\mathcal{M}$ | 写入、检索、摘要、暴露给未来决策的内容 | “记住什么？忘掉什么？什么时候回忆之前的经验？” |
所以一个完整的 Agent 系统可以表示为：
$$\mathcal{G} = (\mathcal{H}, \mathcal{R}_\delta), \quad \mathcal{H} = (\mathcal{P}, \mathcal{A}, \mathcal{M})$$其中 $\mathcal{H}$ 是 Harness（包含规划、动作、记忆三层），$\mathcal{R}_\delta$ 是适应后的推理器（Reasoner），$\delta$ 是基础模型上的轻量级适配器（如 LoRA）。
1.3 异构任务场景带来的挑战
LLM Agent 被部署在各种各样的任务场景中，这些场景在结构要求上存在根本差异：
- 多步骤工具使用：需要精确的函数调用和链式工具组合（如"先搜索航班，再搜索酒店，最后计算总价"）
- 检索密集型推理：需要从大量文档中找到关键信息并进行多跳推理（如"这篇论文中方法A和方法B的主要区别是什么？"）
- Web 交互：需要模拟人类的浏览器操作行为（如点击、填写表单、导航）
- 有状态多轮任务：需要跟踪对话状态、管理长期记忆（如客服系统、代码调试）
问题是：不同的任务需要不同的执行范式。一个为"工具使用"设计的 Harness（严格的动作 schema、工具使用协议）在"多跳推理"场景下可能完全不适用（后者可能需要更灵活的记忆暴露和任务分解策略）。
这挑战了"一个固定的 Agent 系统打天下"的传统思路，推动了系统级的元适应（Meta-adaptation） 研究方向——不只是单独优化某个组件，而是让整个 Agent 系统能够演化以适应不同的任务场景。
1.4 当前方法的两大流派及其局限
面对 Agent 适应性问题，现有工作可以分为两大流派：
流派一：搜索式方法（Search-style）——优化外部 Harness
这类工作关注如何自动搜索或生成更好的 Harness 结构：
| 代表工作 | 核心思路 |
|---|---|
| ADAS | 自动化 Agent 系统设计，用 LLM 搜索最优系统架构 |
| AFlow | 自动化工作流生成，用搜索算法找最佳工作流图 |
| AgentSquare | 在模块化设计空间中搜索最佳 Agent 组合 |
| MaAS | 多 Agent 架构搜索，用超网优化多 Agent 拓扑 |
| AutoHarness | 让 LLM 自动合成代码 Harness |
| Meta-Harness | 端到端优化模型 Harness，提出文件系统 Harness 提议器 |
局限：这些方法主要优化外部结构，但与模型端推理器的兼容性是隐式的——它们假设更强的 Harness 会自动带来更好的性能，但忽略了推理器是否能可靠地执行这个 Harness。
流派二：训练式方法（Training-style）——优化内部策略
这类工作通过学习来适应模型的推理策略：
| 代表工作 | 核心思路 |
|---|---|
| SFT | 监督微调，用成功轨迹训练模型 |
| GRPO | 组相对策略优化，用于推理和工具使用 |
| RLOO | REINFORCE 风格优化，用于偏好学习 |
| Search-R1 | 训练 LLM 推理并利用搜索引擎 |
| ToolRL | 奖励驱动的工具学习 |
局限：这些方法通常假设固定的、外部指定的交互循环或任务接口——它们在给定的 Harness 下训练更好的推理策略，但不会去改变 Harness 本身。
1.5 核心矛盾：Harness 和 Policy 的兼容性鸿沟
这两大流派的局限揭示了一个更深层的矛盾：
- 更具表达力的 Harness 如果 Reasoner 不能可靠执行则会失败：你可以设计一个精巧的六步验证流程，但如果模型经常在第三步就理解错误，整个流程就是摆设。
- 更强的 Policy 如果 Harness 暴露了不合适的状态/动作/控制信号则仍受限：即使模型很聪明，如果 Harness 在不该暴露记忆的时候暴露了无关记忆，或者没有提供必要的验证步骤，模型的聪明才智也无处施展。
用一句话概括：Harness 和 Policy 之间存在"可执行兼容性"问题，而现有方法只单独优化其中一端，无法解决这个兼容性鸿沟。
二、论文定位和关联工作
2.1 研究方向全景
本文处于三个研究方向的交汇处：
Agent Harness / 脚手架自动化优化
↘
搜索式 Harness 优化 → ★ HarnessForge（Harness-Policy 协同演化）← Agentic RL / 策略演化
↗ ↗
元自适应系统设计 Agent 系统级适应
2.2 与现有工作的定位关系
（1）搜索式 Harness 优化方向
| 工作 | 核心贡献 | 与 HarnessForge 的关系 |
|---|---|---|
| ADAS（Hu et al., 2025） | 用元 Agent 搜索最优 Agent 系统设计 | HarnessForge 的 Harness 裁剪模块同样使用元 Agent 来修改 Harness，但不仅修改结构，还确保与 Policy 的兼容性 |
| AFlow（Zhang et al., 2025c） | 自动化工作流图生成 | AFlow 只优化工作流图（一种 Harness），HarnessForge 同时优化工作流和执行策略 |
| AgentSquare（Shang et al., 2025） | 在模块化设计空间中搜索 Agent 组合 | AgentSquare 搜索的是组件组合，HarnessForge 演化的是组件内容和策略的匹配度 |
| MaAS（Zhang et al., 2025a） | 多 Agent 架构搜索 | MaAS 搜索 Agent 拓扑结构，HarnessForge 聚焦于单个 Harness-Policy 对的联合适应 |
| AutoHarness（Lou et al., 2026） | 让 LLM 自动合成代码 Harness | AutoHarness 只关注 Harness 生成，不关心模型是否能可靠执行生成的 Harness |
| Meta-Harness（Lee et al., 2026） | 端到端优化模型 Harness | Meta-Harness 优化 Harness 但不训练策略，与 HarnessForge 的联合优化形成互补 |
关键差异：上述工作都只关注 Harness 端的优化，与模型端推理器的兼容性是隐式的。HarnessForge 是第一个显式建模和优化 Harness-Policy 兼容性的工作。
（2）Agentic RL 方向
| 工作 | 核心贡献 | 与 HarnessForge 的关系 |
|---|---|---|
| GRPO（Shao et al., 2024） | 组相对策略优化，DeepSeekMath 提出 | HarnessForge 的策略对齐模块可以用 GRPO 替代 SFT |
| RLOO（Ahmadian et al., 2024） | REINFORCE 风格优化 | HarnessForge 的策略对齐模块可以用 RLOO 替代 |
| Search-R1（Jin et al., 2025） | 训练 LLM 推理和利用搜索引擎 | Search-R1 训练特定能力（搜索），HarnessForge 训练 Harness 条件化的通用执行能力 |
| ARPO（Dong et al., 2026） | Agentic 强化策略优化 | ARPO 优化策略但不改变 Agent 架构，HarnessForge 同时演化架构和策略 |
关键差异：这些工作在固定的 Agent 交互循环下训练策略。HarnessForge 不假设固定循环——它在训练策略的同时也在改变策略需要适应的交互循环。
（3）本论文的独特定位
HarnessForge 是第一个将 LLM Agent 适应重新定义为 Harness-Policy Pair 联合演化的工作。
之前的工作要么单独优化 Harness（搜索式方法），要么单独优化 Policy（训练式方法），但从未有人明确提出：Agent 系统的基本适应单元应该是 (Harness, Policy) 这个对子，而不是单独的 Harness 或单独的 Policy。
这个定位让 HarnessForge 在方法论上与前述所有工作拉开了根本性的差距。
三、问题定义
3.1 从现象到本质的抽象
论文面对的现象很直观：同一个模型，配上不同的 Agent 系统（不同的 Harness + 不同的 Policy），在同一个任务上的表现差异巨大。但当你想要研究"什么样的 Agent 系统是好的"时，你会发现困难重重——因为 Harness 的结构和 Policy 的行为交织在一起，你没法把它们拆开来单独看。
论文的核心抽象可以分三步理解：
第一步：Agent 系统是一个耦合对
一个 LLM Agent 系统不是"Harness + Policy 两个独立的东西"，而是一个耦合的 Harness-Policy Pair：
$$\mathcal{G} = (\mathcal{H}, \mathcal{R}_\delta)$$Harness（$\mathcal{H}$）提供执行框架——它定义了任务怎么分解、工具怎么调用、记忆怎么管理。Policy（$\mathcal{R}_\delta$）提供推理能力——它在 Harness 定义的框架内做出决策。两者是绑定的，而不是独立的。
第二步：适应空间是可分离的
虽然 Harness 和 Policy 是耦合的，但它们的适应空间是可分离的：
- Harness 侧的适应：修改规划策略（$\mathcal{P}$）、动作接口（$\mathcal{A}$）、记忆管理（$\mathcal{M}$）
- Policy 侧的适应：通过轻量级适配器（$\delta$，如 LoRA）调整模型的推理行为
这种分离让我们可以分别研究"什么样的 Harness 是好的"和"什么样的 Policy 是好的"，但同时保持它们的兼容性。
第三步：兼容性是核心目标
在分离了适应空间之后，论文提出了一个关键的度量标准：可执行兼容性（Executable Compatibility）。
一个 Harness 和一个 Policy 是兼容的，当且仅当：Policy 能够可靠地执行 Harness 定义的执行框架，而 Harness 能够为 Policy 提供合适的状态/动作/控制信号。
3.2 精确的问题定义
在排除了外部干扰后，论文的核心问题可以表述为：
如何让 Agent 系统在异构任务场景下实现系统级的元适应——即同时演化 Harness 和 Policy，并保证两者之间的可执行兼容性？
这个问题包含三个关键约束：
| 约束 | 含义 |
|---|---|
| 系统级 | 不只优化 Harness 或 Policy 中的某一个，而是优化整个 (Harness, Policy) 对 |
| 元适应 | 不是为特定任务设计固定方案，而是让系统自动演化以适应任务分布 |
| 可执行兼容性 | 演化后的 Harness 和 Policy 必须在执行层面相互匹配，而不是各自独立变好 |
进一步拆解，论文需要回答三个子问题：
- 如何诊断当前 Agent 系统的失败源于 Harness 的哪部分？
- 如何修改 Harness 使其更适合当前的任务分布？
- 如何让 Policy 适应修改后的 Harness，保持两者的兼容性？
四、问题解法
4.1 核心思想：Harness-Policy 协同演化
HarnessForge 的核心思想可以一句话概括：
在迭代轮次上交替进行：先从轨迹级执行证据演化 Harness 结构，再从存活种群演化 Harness 条件化的推理策略。
每一轮（Round）都包含两个阶段：
Round r:
Phase 1: Harness 裁剪（Harness Tailoring）
→ 让当前 Agent 系统执行任务，收集失败轨迹
→ 分析失败原因，归因到 Planning / Action / Memory 中的具体组件
→ 生成新的 Harness 候选，通过过滤选出存活者
Phase 2: 策略对齐（Policy Alignment）
→ 对每个存活的 Harness，从成功轨迹中提取训练数据
→ 训练 Harness 特定的 LoRA 适配器
→ 让 Policy 学会可靠地执行新的 Harness
→ 产生新一轮的 (Harness, Policy) 对种群
一个通俗的类比：想象你在训练一支运动队。Harness 是战术体系（阵型、跑位、传球路线），Policy 是球员的个人技术和执行力。
- 如果你只改战术但不训练球员（只做 Harness 裁剪），球员可能跑不出新的战术。
- 如果你只训练球员但不变战术（只做策略对齐），球员可能能力很强但打的还是不合适的战术。
- HarnessForge 的做法是：每轮先调整战术，然后针对新战术专项训练球员，确保两者匹配。
4.2 阶段一：故障引导的 Harness 裁剪
这是 HarnessForge 最核心的创新之一。面对"怎么知道 Harness 哪部分出了问题"这个难题，论文提出了故障归因 → 存档引导改进 → 候选生成与过滤的三步流程。
4.2.1 故障归因（Fault Attribution）
不是简单地看"任务成功还是失败"，而是深入分析失败轨迹，找出 Harness 的哪个组件导致了失败。
具体做法：一个元 Agent（论文使用 GPT-5.5）联合检查当前的 Harness 设计和代表性失败轨迹，生成一份故障报告：
$$\mathbf{F}_{\mathcal{H}_i}^{(r)} = \mathbb{L}_\omega(\mathcal{H}_i^{(r)}, \mathcal{T}_i^{(r)}, \mathbf{J}(\mathcal{G}_i^{(r)}; B_r))$$故障报告将失败归因到 Planning（规划）、Action（动作）和 Memory（记忆）的具体组件。例如：
- “失败原因：Planning 组件的任务分解过于粗粒度，导致子目标无法直接执行”
- “失败原因：Memory 组件暴露了过多的历史记忆，干扰了当前决策”
- “失败原因：Action 组件的工具接口定义不清晰，导致模型调用了错误的参数格式”
4.2.2 存档引导改进（Archive-guided Improvement）
HarnessForge 维护一个存档（Archive），记录历史上所有评估过的 Harness 设计和它们的性能。
基于故障报告，从存档中检索与当前故障相关的历史样例，生成改进报告：
$$\mathbf{I}_{\mathcal{H}_i}^{(r)} = \mathbb{R}_\omega(\mathcal{H}_i^{(r)}, \mathbf{F}_{\mathcal{H}_i}^{(r)}, \mathcal{S}_{\mathcal{H}_i}^{(r)})$$改进报告总结：“哪些组件应该编辑"以及"可以参考哪些历史设计”。
这个机制类似于一个经验丰富的工程师团队的知识库——当新的问题出现时，不是从零开始思考，而是先查查历史上类似的问题是怎么解决的。
4.2.3 候选生成与半选择
基于改进报告，为每个活跃 Harness 生成多个修订候选。然后通过分阶段 Pareto 过滤选出最优的存活者：
- 第一阶段：在小任务子集上快速评估所有候选，淘汰明显差的
- 第二阶段：在更大的任务子集上评估存活者，进一步筛选
- …
- 最终阶段：在完整评估集上选出最终存活者
这种渐进式过滤的设计非常巧妙——它避免了对每个候选都做完整评估（成本太高），同时保证了最终选择的质量。
每轮保留 $|C|$ 个存活 Harness（默认为 2），存入存档供后续轮次参考。
4.3 阶段二：Harness 条件化的策略对齐
每个存活的新 Harness 需要一个能可靠执行它的 Policy。这是通过三个步骤实现的：
4.3.1 父初始化（Parent Initialization）
新 Policy 不是从零开始训练的，而是继承父代的策略：
$$\delta_k^{(r+1)} = \text{Merge}(\delta_k^{(r)}) \oplus \Delta\delta_k^{(r+1)}$$- 先将父代适配器参数合并（Merge），作为新 Policy 的初始化
- 再训练一个新的增量适配器 $\Delta\delta_k^{(r+1)}$，使 Policy 适应新的 Harness
这类似于在已有技能的基础上学新技能，而不是每次都从零开始。使用了 LoRA（Low-Rank Adaptation）技术来实现轻量级的适配器训练——只需要训练很少的参数就能让模型适应新的 Harness。
4.3.2 轨迹策划（Trajectory Curation）
关键设计：复用 Harness 选择阶段已经产生的推出轨迹，不需要单独的数据收集阶段。
具体做法：从轨迹池中只保留成功的轨迹：
$$\mathcal{T}_k^+ = \{\tau_x \in \mathcal{T}_k^{(r+1)} \mid S(\tau_x) = 1\}$$这个设计非常高效——它意味着策略对齐阶段几乎是"免费的"，因为数据已经在 Harness 裁剪阶段收集好了。
4.3.3 Harness 条件化演化
将成功轨迹转换为步骤级监督数据，每个训练样本是一个决策对：
- 输入 $z_t$：任务指令 + 活跃 Harness 接口 + 累积观测 + 当前记忆状态 + 可用动作
- 目标 $y_t$：对应的下一步行为（推理步骤、工具动作、记忆操作等）
默认使用 SFT（监督微调）进行训练，因为它复用成功轨迹并提供有利的 rollout-性能权衡。论文也验证了 GRPO 和 RLOO 等 RL 方法的兼容性。
4.4 迭代协同演化的整体流程
将两个阶段组合起来，整个 HarnessForge 的算法可以总结为：
输入：基础 Harness H₀，冻结的基础 Reasoner R_{θ₀}
输出：演化后的 (Harness, Policy) 对种群
初始化：G⁰ = {(H₀, R_{θ₀})} // 单例种群
For r = 1, 2, 3: // 3 轮演化
// Phase 1: Harness 裁剪
对每个父 pair 在任务批次上执行，收集轨迹
→ 故障归因 → 存档引导改进 → 生成候选
→ 半选择过滤 → 存活 Harness C^{r}
// Phase 2: 策略对齐
对每个存活 Harness:
复用过滤阶段的成功轨迹
训练 Harness 特定的 LoRA 适配器
→ 匹配的 (H_k^r, R_{δ_k}^r) pair
更新存档，进入下一轮
4.5 实验结果
4.5.1 主要结果
在 5 个跨领域基准上（ToolHop 工具使用、HotpotQA/2WikiMultiHopQA 多跳问答、RestBench-TMDB API 使用、API-Bank 结构化 API 调用），HarnessForge 的表现：
| 对比对象 | 平均增益 | 最大增益 |
|---|---|---|
| vs 最强搜索式基线（MermaidFlow） | +3.56% | +12.0%（TMDB, 4B） |
| vs 最强训练式基线（GRPO） | +3.56% | +12.0%（TMDB, 4B） |
特别值得注意的是：
- 在 Qwen3-4B 上，ToolHop 答案准确率从 GRPO 的 49.74% 提升到 52.82%
- 在 TMDB 任务成功率上，从 GRPO 的 64.00% 飙升到 76.00%（+12.0%）
- 在 API-Bank 成功率上，从 GRPO 的 71.93% 提升到 77.19%
这些结果在 Qwen3-4B 和 Qwen3-8B 两个骨干网络上一致成立。
4.5.2 消融实验的关键发现
论文的消融实验揭示了一个重要的分层结构：
| 移除的模块 | Round 3 性能下降（ToolHop） | Round 3 性能下降（SearchQA） |
|---|---|---|
| 移除 Harness 裁剪 | ↓ 6.15% | ↓ 5.00% |
| 移除策略对齐 | ↓ 2.56% | ↓ 3.00% |
Harness 裁剪是主导因素——它带来的增益约是策略对齐的两倍。而且差距随着演化轮次增加而扩大，说明增益来自协同效应的累积。
4.5.3 兼容性验证：交叉组合实验
这是最有说服力的实验之一：将演化过程中不同轮次产生的 Harness 和 Policy 进行交叉组合，看匹配 vs 不匹配的差异：
- 匹配对（最终 Harness + 最终 Policy）：69.30% → 77.19%（+7.89%）
- 不匹配对（最终 Harness + 早期 Policy）：平均 71.93%
- 不匹配对（早期 Harness + 最终 Policy）：平均 71.06%
这说明 HarnessForge 不只是产生了独立更强的组件，而是产生了特定配对才能发挥的兼容性增益——这直接验证了"可执行兼容性"的核心假设。
4.5.4 Rollout 预算效率
HarnessForge 在所有基准上位于或接近 Pareto 前沿，用 SFT 训练时每轮只需 2.4K-12.0K 个 rollout，而 GRPO/RLOO 需要 7.2K-45.6K。在资源受限场景下，SFT 版 HarnessForge 提供了最优的性能-预算权衡。
五、必要知识反推
假设让一个完全没有背景知识的人来完成这篇论文的研究工作，他需要掌握哪些必要知识和信息？以下从"发现问题"到"解决问题"的角度进行反推。
5.1 发现问题阶段所需的知识
| 需要掌握的知识 | 为什么需要 | 具体内容 |
|---|---|---|
| Agent = Model + Harness 的拆解视角 | 如果不知道 Harness 是独立于模型的，就无法提出"Harness 和 Policy 需要联合优化"的假设 | 理解 Agent 系统中哪些能力来自模型本身，哪些来自外围执行框架；知道 Agent 的性能是两者共同决定的 |
| 当前两大流派的局限 | 必须意识到单独优化 Harness 或单独优化 Policy 都不够，才能提出联合优化的必要性 | 知道搜索式方法（ADAS、AFlow 等）只优化外部结构但不关心模型能否执行；知道训练式方法（GRPO、RLOO 等）只优化策略但假设固定架构 |
| Harness 的三层组件模型 | 需要知道 Harness 的内部结构才能进行有意义的故障归因和修改 | 理解 Planning（任务分解、重规划）、Action（工具接口、角色分配）、Memory（记忆管理）三个组件的职责和交互方式 |
| 异构任务场景的差异 | 需要理解不同任务对 Agent 系统的不同要求，才能意识到"固定系统"的不足 | 知道工具使用需要严格的动作 schema，多跳推理需要灵活的记忆暴露，Web 交互需要模拟人类行为 |
5.2 提出方案阶段所需的知识
| 需要掌握的知识 | 为什么需要 | 具体内容 |
|---|---|---|
| 元演化/协同演化思想 | 需要一个理论框架来指导 Harness 和 Policy 的联合优化 | 理解协同演化的基本原理——两个互相依赖的系统通过迭代交替优化来共同进步；知道这种思想在进化计算、博弈论中的应用 |
| 故障归因方法 | 需要知道如何从执行失败中定位 Harness 的问题所在 | 理解如何分析轨迹级执行证据（失败日志、中间状态、环境反馈）来推断是哪个组件（Planning/Action/Memory）导致了失败 |
| LoRA 等轻量级适配技术 | 需要知道如何高效地训练 Policy 适应新的 Harness | 理解 LoRA（Low-Rank Adaptation）的原理——通过训练少量低秩矩阵来适配大模型，而不是全参数微调 |
| Pareto 最优和多目标优化 | 需要知道如何在多个冲突目标（性能 vs 成本 vs 延迟）之间做出合理权衡 | 理解 Pareto 前沿的概念——在不牺牲任何目标的情况下无法进一步优化的解集 |
| SFT 和 RL 训练范式 | 需要知道如何利用成功轨迹来训练策略 | 理解监督微调（用成功轨迹的步骤级数据训练模型）、强化学习（用奖励信号引导策略优化）的训练流程和各自优缺点 |
5.3 验证方案阶段所需的知识
| 需要掌握的知识 | 为什么需要 | 具体内容 |
|---|---|---|
| Agent 基准测试体系 | 需要知道在哪些场景下评估才能全面验证方案的有效性 | 知道 ToolHop（多跳工具使用）、HotpotQA/2WikiMultiHopQA（多跳问答）、TMDB（API 使用）、API-Bank（结构化 API 调用）等基准的评估方式和指标 |
| 受控实验设计 | 必须设计公平的比较来验证"联合优化优于单独优化"的假设 | 知道如何控制变量（同一骨干网络、同一训练数据，只换优化方法）；知道如何设计消融实验（分别移除 Harness 裁剪和策略对齐） |
| 交叉组合验证 | 需要验证兼容性增益确实来自 Harness-Policy 的匹配 | 知道如何设计"交叉组合实验"——将不同演化阶段的 Harness 和 Policy 交叉配对，比较匹配 vs 不匹配的差异 |
5.4 知识融合路径
以上知识的融合路径可以概括为：
观察痛点（Harness 和 Policy 的兼容性鸿沟）
→ 识别本质（Agent 系统是耦合对，不是独立组件的简单组合）
→ 提出形式化（将 Agent 系统定义为 Harness-Policy Pair）
→ 设计演化机制（故障引导裁剪 + 条件化对齐，交替进行）
→ 验证有效性（跨领域基准 + 消融 + 交叉组合）
→ 揭示核心洞察（可执行兼容性是关键）
最关键的融合节点是**“识别本质"到"提出形式化”**这一步——你需要同时理解 Harness 优化和 Policy 优化各自的局限、理解两者之间的相互依赖关系、理解"兼容性"是一个独立于"各自好坏"的维度，才能提出将 (Harness, Policy) 作为基本适应单元的形式化方案。
六、论文中可以提取的通用性灵感
灵感 1：联合优化 > 局部优化，但前提是定义好"兼容性"
HarnessForge 最核心的洞察是：当你有两个互相依赖的子系统时，联合优化它们的效果远大于单独优化任何一个——但前提是你必须显式地定义和度量它们之间的"兼容性"。
这个灵感在许多领域都适用：
- 软件工程：前端和后端的联合设计比各自优化更有效，但前提是定义好 API 契约（兼容性接口）
- 组织管理：团队架构和团队技能的联合优化比单独调整组织架构或单独培训员工更有效，但前提是明确"岗位-能力"的匹配标准
- 教育系统：课程设计和学生能力培养的联合优化比单独改课程或单独改教学方法更有效，但前提是定义好"课程-能力"的对齐标准
- 产品开发：产品设计和营销策略的联合优化比单独打磨产品或单独优化营销更有效，但前提是明确"产品价值-市场定位"的匹配度
核心原则：当两个子系统互相依赖时，优化它们的匹配度比优化各自的绝对能力更重要。
灵感 2：故障归因是系统优化的起点
HarnessForge 的故障归因机制揭示了一个通用的优化原则：在修改任何系统之前，先弄清楚当前的失败源于哪个组件。
这听起来是常识，但在实践中经常被忽略。很多人的第一反应是"换一个更好的方案"，而不是"先搞清楚当前方案为什么失败"。
故障归因的推广：
- 代码调试：与其盲目地改代码，不如先用断点和日志精确定位问题所在
- 组织诊断：与其大规模重组，不如先用数据分析找出瓶颈环节
- 个人成长：与其盲目学习新技能，不如先分析当前瓶颈是知识、技能还是心态
- 产品设计：与其大幅改版，不如先用用户反馈分析流失的具体环节
核心原则：精准的故障归因比广泛的优化尝试更高效。先定位，再修改。
灵感 3：渐进式过滤是一种高效的评估策略
HarnessForge 的"半选择"机制——在逐渐增大的任务子集上渐进过滤候选——是一个非常有实用价值的设计模式。
直接的想法是"每个候选都做完整评估"，但这太贵了。HarnessForge 的做法是先用便宜的小规模评估快速淘汰明显差的，再用中等规模评估进一步筛选，最后才做昂贵的大规模评估。
这个模式的推广：
- 招聘：先看简历（低成本筛选）→ 电话面试（中等成本筛选）→ 现场面试（高成本评估）
- 产品验证：先做纸面原型测试（低成本）→ 可交互原型测试（中等成本）→ 完整产品内测（高成本）
- 投资决策：先看摘要材料（低成本）→ 尽职调查（中等成本）→ 深度审计（高成本）
- 论文审稿：先看摘要和结论（低成本）→ 快速浏览方法（中等成本）→ 详细审读全文（高成本）
核心原则：当评估成本很高时，用渐进式过滤来减少需要全面评估的候选数量。
灵感 4：数据复用是效率提升的关键
HarnessForge 的策略对齐阶段复用了 Harness 裁剪阶段产生的轨迹数据，不需要单独的数据收集。这个设计让策略对齐几乎是"免费的"。
这个灵感的推广：
- 项目管理：代码审查中发现的问题可以复用为团队培训材料
- 用户研究：用户访谈中收集的反馈可以复用为产品文档的素材
- 学习过程：做练习题时产生的错误可以复用为针对性的复习材料
- 科学实验：探索性实验的数据可以复用为验证性实验的参考
核心原则：在设计任何流程时，先检查上游是否已经产生了你需要的数据。数据复用比数据重新采集高效得多。
灵感 5：协同效应是累积的，需要多轮迭代
消融实验揭示了一个重要的模式：Harness 裁剪和策略对齐的协同效应不是一轮就能发挥的，而是随着轮次增加而累积增大。
Round 1 移除 Harness 裁剪的损失是 3.07%，但 Round 3 变成了 6.15%——翻了倍。这说明每一轮的增益建立在前一轮的基础上，形成正反馈循环。
这个灵感的推广：
- 技能学习：理论学习和实践训练交替进行的效果，远大于先学完所有理论再开始实践。每一轮实践都会暴露理论学习中的盲点，反过来指导下一轮理论学习
- 团队建设：流程改进和技能培训应该交替进行。改进流程后，针对新流程培训技能；技能提升后，设计更高效的流程。如此迭代
- 产品迭代：架构优化和功能开发应该交替进行。优化架构后，在新架构上开发功能；功能积累后，再优化架构以支撑更大规模
核心原则：两种互相增强的活动应该交替进行而不是串行进行，因为协同效应是累积的。
灵感 6：可执行兼容性是一个被忽视的维度
论文最深刻的洞察可能是：在评价一个系统时，我们通常只关注"各个组件好不好"，而忽视了"组件之间能不能配合"。
交叉组合实验直接证明了这一点：最强的 Harness 配上不匹配的 Policy，效果不如匹配但各自不是最强的 Harness-Policy 对。
这个洞察的推广：
- 团队管理：明星员工组成的团队不一定最强，配合默契的普通团队可能更有效
- 技术选型：最好的技术栈组合不一定是最适合你团队的，团队熟悉度和技术匹配度更重要
- 教育培训：最好的教材 + 最好的老师不一定产生最好的教学效果，教学方法和学生特点的匹配度更关键
- 医疗方案：最好的药物 + 最好的设备不一定产生最好的治疗效果，治疗方案和患者个体差异的匹配度更重要
核心原则：在优化系统时，不要只关注组件的绝对能力，还要关注组件之间的兼容性。一个配合默契的"中档"组合，往往优于各自最优但不兼容的"豪华"组合。
总结
HarnessForge 这篇论文做了一件非常漂亮的事：它不是在 Harness 优化或 Policy 优化的赛道上继续卷，而是退后一步，问了一个更根本的问题——为什么我们不把 Harness 和 Policy 放在一起优化？
答案揭示了 LLM Agent 适应的一个被长期忽视的维度：可执行兼容性。一个 Agent 系统好不好，不只取决于 Harness 好不好、Policy 好不好，还取决于它们能不能配合。
HarnessForge 通过"故障引导裁剪 + 条件化对齐"的交替迭代，让 Harness 和 Policy 在每一轮都向彼此靠近一步。三轮下来，这种协同效应累积出了显著的增益——在最强基线上平均再提升 3.56%，最高 12.0%。
但论文也坦诚地指出了当前的局限：
- 模型规模：主要在 Qwen3-4B 和 Qwen3-8B 上验证。在更大模型上，Harness 提供的结构支持可能不像在小模型上那么关键，兼容性增益是否会保持还有待验证。
- 计算成本：虽然复用轨迹提高了效率，但长期 horizon 环境中的演化过程仍然昂贵。
- 算子空间：目前对 Harness 的修改受限于结构化编辑算子，没有探索更激进的修改方式（如任意代码级重写、新工具抽象）。
这篇论文开启了一个重要的研究方向：将 Agent 系统适应从局部组件优化提升到系统级联合演化。正如论文的核心信息所说：
有效的 Agent 系统适应取决于优化 Harness 和 Policy 之间的可执行兼容性。