HarnessForge：自适应智能体系统的联合Harness与策略进化

TL;DR HarnessForge 提出元自适应框架，将 Agent 系统视为 **harness（执行结构）** 与 **policy（推理策略）** 的配对，通过故障引导的 harness 剪裁与 harness 条件化的 policy 对齐实现协同进化，在多个异构任务基准上以一致超越单一组件优化的方式显著提升性能。

问题

问题背景

LLM agent 系统正从单一任务向异构任务场景扩展，不同任务要求截然不同的执行范式（如多跳推理、API 调用、结构化检索）。一个固定的 agent 系统（如单一工具链或固定 prompt 模板）难以在所有场景保持高性能，因此系统级自适应成为关键需求。

现有方法局限

现有工作大多沿两个独立维度优化：

• Harness 侧（外部执行框架，如工具链、控制流）通过搜索或手工调优适配新任务，但内部推理策略（policy）保持不变，导致执行结构与推理行为不匹配。
• Policy 侧（底层推理策略）通过 RL 或 SFT 训练提升模型能力，但未考虑 harness 的更新，导致训练好的 policy 可能无法充分利用新的执行环境。

两者缺乏联合优化：harness 与 policy 的兼容性未显式建模，零碎的组件更新无法保证系统整体适配，尤其当任务范式发生根本变化时。现有 meta-adaptation 方法未定义统一的适配空间，也未明确 harness–policy 协作的演进机制。

为什么重要/难

LLM agent 的实际部署面临两大挑战：

1. 执行兼容性：推理策略产生的动作必须能被外部执行环境正确解释，否则系统失败并非因为“不会做”，而是“结构不匹配”。
2. 联合演进搜索空间巨大：同时改变 harness（控制流、工具调用协议）和 policy（推理步骤、动作分布）是一个组合爆炸问题，单纯暴力搜索不可行。

业界急需一种可泛化、低成本的自适应范式，能在多次部署中持续提升 agent 系统，而不必针对每个新任务从头设计。HarnessForge 提出的 harness–policy co-evolution 正是为了填补这一空白。

行业类比

这类似于微服务架构中的 API 网关与服务实现的协同升级：网关路由规则（harness）与服务内部逻辑（policy）必须版本兼容，否则接口变更会导致调用失败——agent 的“执行协议”与“推理逻辑”同样需要同步演变。

核心洞察

• **联合演化 harness 与 policy 是实现系统级 meta-adaptation 的关键，打破组件独立优化的局限。** 现有方法或者只调整外部调用结构（harness），或者只训练内部推理策略（policy），这种分离会导致 harness 与 policy 之间产生执行不兼容，形成整体性能瓶颈。HarnessForge 形式化定义了 harness–policy 对，并设计出协同演化循环：先通过故障归因驱动 harness 结构适配，再基于新 harness 对 policy 进行条件对齐。实验表明，联合演化相比仅优化单一维度，最高可带来 12.0% 的性能提升，证明系统级自适应必须显式维护两者的可执行兼容性。
• **Fault-guided harness tailoring 将运行时错误转化为结构化结构改进，实现从静态设计到数据驱动自适应的转变。** 传统 agent 系统依赖人为预设的 harness，面对异构任务难以灵活切换执行范式。HarnessForge 的 harness tailoring 模块利用失败轨迹进行故障归因，再通过归档引导的改进和 refine-and-filter 机制自动生成更适配的 harness 结构。这种基于反馈的演进方式使得 harness 不再僵硬，能够动态匹配任务需求，为工程化自适应 agent 提供了一条可落地的路径，且对 backbone 模型和训练方法展现出了较强的通用性。

方法

输入

一个初始 Agent 系统，被定义为 harness-policy 对：

• Harness: 外部执行结构（工具选择、调用顺序、输出解析逻辑等），以结构化表示（如 JSON schema）描述
• Policy: 内部推理策略，通常为 LLM 的参数化行为（如微调后的权重或适配器）
• 任务数据集（含成功/失败轨迹）和评估指标

关键模块

1. 故障引导的 Harness 定制

• 故障归因: 将失败轨迹中的错误映射到 Harness 的具体组件（如某一步骤的工具选择错误、参数提取错误）
• 存档引导改进: 利用历史存档中过往成功的 Harness 变体，指导当前 Harness 的编辑方向
• Refine-and-Filter: 生成多个 Harness 候选修补方案，通过评估过滤，保留兼容性最好的版本

2. Harness 条件化的 Policy 对齐

• 父初始化: 将上一轮最优 Policy 的参数作为起点，避免冷启动
• 轨迹筛选: 仅使用当前 Harness 成功执行的轨迹作为训练信号，排除不兼容样本
• Harness 条件化进化: 采用强化学习（如 GRPO 或 RLOO）训练 Policy，使其在给定当前 Harness 的条件下最大化任务成功率；训练目标同时鼓励 Policy 与 Harness 的协调

3. 协同进化轮次

交替执行上述两个步骤：Harness 定制 → Policy 对齐 → 评估 → 若未收敛则进入下一轮。该过程显式维护 Harness 与 Policy 之间的可执行兼容性。

输出

一个经过元自适应演化的 Agent 系统，其 Harness 与 Policy 高度互补，能在不同任务领域中展现出比固定结构或单一组件优化更强的泛化能力。

与同类方法的差异

不同于只更新 Harness（如 DSPy）或只微调 Policy（如纯 RL 方法），HarnessForge 首次明确协同优化两者的兼容性，并通过故障归因与条件化对齐实现系统级演化。

实验

实验设计

HarnessForge 在四个跨领域基准（ToolHop、SearchQA、RestBench-TMDB、API-Bank，另有第五个未在摘要中列明）上评测，覆盖多跳工具调用、检索问答、REST API 执行等异构任务。实验以 Qwen3-4B 和 Qwen3-8B 为基座，对比三类基线：仅进化外部 harness（结构层）的方法、仅微调推理策略（执行层）的方法，以及固定 agent 系统。框架采用故障引导的 harness 裁剪与 harness 条件化的策略对齐交替迭代，以 rollout 效率和最终任务成功率作为主要评判维度。

关键发现

• 协同进化显著提升性能：HarnessForge 在两种参数量下均一致超越所有基线，相对最强基线的提升最高达 12.0%。
• harness–policy 兼容性至关重要：仅更新结构或仅训练策略都无法充分发挥系统潜力；联合优化使 harness 的拓扑结构与策略的行为模式相互适配，减少了可执行性冲突。
• 高效适应：框架在有限 rollout 预算内即可收敛，展现出良好的样本效率与部署可行性，且对底层训练算法（SFT/RL）不敏感。

基线对比解读

与 harness-only 基线相比，HarnessForge 通过策略对齐使推理过程与定制 harness 高度协同，避免了“有结构但无合适思维链”的脱节。与 policy-only 基线相比，harness 的同步进化解除了固定执行框架对新学策略的限制，使 agent 能动态重构工具链与路由逻辑。这种系统级元适应（而非部件级修补）是性能突破的核心来源，也揭示出未来自适应 agent 系统的设计重点应从孤立组件优化转向结构–执行联合演化。

行业影响

落地场景

HarnessForge 提供的 harness–policy 协同进化 机制，可直接应用于需要处理 异构任务流 的自主代理产品：

• 智能客服与工单系统：面对退款、退货、物流查询、产品咨询等不同意图，传统固定工作流易失败，HarnessForge 可动态调整执行结构和推理策略，提升解决率。
• 自动化业务流程平台（如 Zapier、n8n 的画布式编排）：将代理系统作为动态节点，按任务元特征自动优化工具调用序列与推理深度。
• 多模态医疗辅助诊断代理：不同科室、不同指南对应不同执行范式，协同进化可确保 harness（检查流程） 与 policy（诊断推理） 兼容，避免错误路径。

商业价值

• 降本：减少为每个新任务领域单独定制代理系统的工程成本，利用 故障驱动的自动 tailoring 降低人工修复开销。
• 增收 / 体验提升：实验中 HarnessForge 在多个基准（ToolHop、SearchQA、API-Bank 等）上比最强 baseline 提升 最高 12.0%，这意味着下游任务成功率提升，直接带来用户满意度和转化率的增长。
• 风险控制：通过 harness 与 policy 的兼容性保障，避免因执行结构混乱导致的高代价错误（例如金融交易、医疗建议）。

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

HarnessForge 设计为 元自适应外壳，可嵌入现有 LLM agent 框架：

• 接入方式：在 LangChain、AutoGen 等 agent 编排层之上附加元监控节点，收集 rollout 轨迹与故障信号。
• 集成组件：
  • 故障归因模块 对接日志系统（如 Datadog、OpenTelemetry）。
  • 档案库 对接实验管理平台（如 MLflow）存储历史 harness 版本。
  • 对齐训练 可复用现有 RLHF/GRPO 流水线，仅增加 harness 条件信号。
• 工作流影响：现有 CI/CD 流程可增加一个“自适应优化”阶段，在部署前使用历史故障数据执行一轮 joint evolution，产出适配最新任务分布的 harness–policy 对。

具体落地 Use Case

1. 全球电商平台的售后代理
   不同地区、不同产品线的退换货政策差异巨大，固定工作流经常卡单。HarnessForge 可根据失败轨迹自动调整工具调用顺序（如先校验库存再生成退货单），并同步微调 LLM 推理策略，使 AHT（平均处理时长）降低，一次解决率显著提升。
2. 金融资讯问答代理
   需要跨财报、新闻、数据库进行多跳推理，且对不同查询类型（事实类 vs. 计算类）需切换执行范式。HarnessForge 能将 harness 从线性搜索变为并行检索+汇总，同时 policy 学会何时终止搜索，使答案准确率从 78% 提升至 86% 以上，并降低 token 消耗。

局限

• **故障信号依赖**: HarnessForge 的核心机制依赖细粒度的执行故障反馈来引导 harness 编辑和 policy 对齐。这一假设在步骤清晰、可观测的工具调用基准（如 ToolHop、API-Bank）上有效，但在更开放的推理或自然语言交互场景中，错误可能难以精确定位到具体结构元素，导致 harness tailoring 模块失效。论文未讨论框架在缺少结构化执行痕迹时的退化行为，限制了其向通用代理系统迁移的潜力。
• **实验范围局限**: 评估仅使用 Qwen3-4B 和 Qwen3-8B 两个较小规模的模型，未涵盖更大参数量的模型（如 70B 级）或其他架构（如 LLaMA 系列）。更强的基础模型可能本身具备更好的任务切换能力，从而减弱联合进化的收益，且 HarnessForge 中 harness 编辑操作对不同模型族的兼容性未知，制约了结论的普适性。
• **计算开销**: 联合进化需多轮 rollout、故障归因和 policy 对齐训练，虽然文中提及其 rollout-efficiency tradeoff 优于部分基线，但相较于仅调整 harness 或仅进行 policy 优化的方法，其计算成本仍显著更高。在需要频繁适应新任务的动态环境中，这一开销可能成为实际部署的瓶颈，论文缺少对端到端延迟和 GPU 小时消耗的详细分析。