HarnessX 深度拆解：小米Darwin Agent Team的自动进化Agent外壳，如何让弱模型暴涨44%？

> 一句话：把Agent外壳拆成类型化乐高积木，用四阶段防翻车引擎AEGIS自动进化，再用跨版本GRPO让模型和外壳协同训练——15个设置中14个提升，平均+14.5%，最弱的Qwen3.5-9B在ALFWorld上从53%干到97%。

---

🔗 论文信息

• 论文标题：HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry
• 论文地址：https://arxiv.org/pdf/2606.14249v1
• 作者团队：小米 Darwin Agent Team
• 代码状态：未明确开源（框架描述完整，可复现）
• 核心贡献：组合化harness架构 + AEGIS四阶段进化引擎 + 跨harness版本GRPO协同进化

---

一、动机：为什么Agent外壳比模型更重要？

一个智能体能力的上限，不只取决于底层模型，还取决于包裹在模型外面的那层 harness（外壳）。它把模型的原始输出转化成结构化的Agent行为：任务怎么表示、外部工具怎么调用、中间决策怎么传递——都由它决定。

任务链条越长、环境越复杂，harness的设计就越关键。

1.1 现有四条进化路线

路线	代表工作	修改范围
自动优化提示词	APE、OPRO、EvoPrompt、ProTeGi、TextGrad、DSPy、MIPRO	窄：只改提示词
积累复用历史经验	Memento、MIA	窄：只改记忆
自动调整多Agent协作	GPTSwarm、ADAS、AFlow	中等：改编排流程
直接改写harness源码	SICA、AHE、Darwin Gödel Machine	宽：改源码但无边界

1.2 三条共同缺陷

迁移性差：各方案修改范围很有限。想动到自己覆盖范围之外的东西，只能另起炉灶；改源码的方案则没有清晰组件边界，改一处牵动全局，有效改法也难拆出来复用。

漂移风险：不管是改提示词还是改源码，让程序反复修改自己再拿打分筛——本质就是优化。是否收敛局部最优、是否灾难性遗忘、是否奖励作弊，各方案都难以避免，也很少提出针对性防御。

不考虑模型变化：多数研究只动外壳不碰模型，runtime产生的海量轨迹并未用于模型协同进化。

---

二、HarnessX 三核心设计

2.1 组合：把外壳拆成类型化乐高

"处理器"（Processor）是最小零件——Agent每执行一步，经过8个固定生命周期hook：

task_start → before_model → after_model → before_tool → after_tool → before_task → after_task → task_end

每个hook规定了在此处允许改动什么（如task_start只能改系统提示词，after_tool只能改工具返回结果）。处理器挂在某个hook上，消费上游事件，产出放行、改写、拆分、拦截或中断等新事件。

关键设计：同一hook上的处理器输入输出都是同一类事件，可以像乐高一样按顺序拼接——随意插入、替换、删除，不影响周围流水线的类型正确性。论文用统一接口规格兜底，任何插拔都会被自动校验，插错了当场拦下。

在这个基础上，作者把Agent全部行为归纳成九个维度： 1. 模型选择 2. 上下文组装 3. 记忆管理 4. 工具生态 5. 执行环境 6. 评估与奖励 7. 控制与安全 8. 可观测性 9. 训练桥

2.2 AEGIS 进化引擎：四阶段防翻车流水线

AEGIS（希腊神话中宙斯/雅典娜的"神盾"）是HarnessX的自进化核心。如果把自进化看作强化学习：

• 当前harness配置 = 状态
• 一次改动 = 动作
• 轨迹 + 验证器打分 = 奖励
• 确定性验收门控 = 状态转移

强化学习的经典病症，自进化框架也跑不掉：

病症	表现	AEGIS防御阶段
奖励作弊	把答案塞进提示词，利用验证器格式规律蒙混	评判器
灾难性遗忘	修好失败模式A，弄坏原本正常的模式B	确定性门控
探索不足	只敢小修措辞，不敢结构性大改	规划器

四阶段流水线：

阶段1：消化器（Digestor）

• 把千万token的原始轨迹压缩成结构化证据（任务成败、失败类别、涉及组件、证据片段）
• 提供跨轮次历史案例，区分顽固失败与偶发噪声

阶段2：规划器（Planner）

• 生成改动前先做整体分析：哪些任务失败、试过哪些改动、还有哪些类型没尝试
• 对抗探索不足的主防线

阶段3：进化器（Evolver）

• 基于规划结果生成候选harness，含改动清单（变更文件、受影响任务、生效判断标准）
• 新增处理器代码附带冒烟测试，每次改动都是可证伪的契约

阶段4：评判器（Judge）

• 对照轨迹证据审查候选，确保改动准确客观，不是针对具体case的作弊

确定性门控：执行非LLM主观判断的确定性检查，任何改动不许把之前做对的任务弄错。

变体隔离：如果不同任务需要冲突行为，维护多个harness变体，按历史成功率路由。变体数量超上限则淘汰综合表现最差的。

三个继续条件：消化器、规划器、进化器各自带有继续条件——没值得改的失败、找不到可行方向、拿不出类型安全的候选，就按兵不动。

2.3 模型协同进化：跨harness版本的GRPO

HarnessX 在轨迹上"一鱼两吃"：一边喂AEGIS进化外壳，另一边存进共用轨迹池训练模型本身。

核心设计：跨harness GRPO

普通GRPO：组内只有同一策略的多次采样，方差来自采样随机性。

HarnessX GRPO：组内轨迹故意混进同一任务历次进化的所有harness版本，差异主要反映不同harness在同一任务上的优劣对比。被验证更优的harness版本更能产生正向梯度，模型被推向更适配它们的行为模式。

实现细节：每条轨迹还原回当时实际使用的harness设置（提示词、工具清单、上下文规则），再让新模型打概率。因为不同harness的工具列表和提示词写法不同，无法统一执行重要性采样——必须逐条还原。

---

三、实验结果：数据说话

3.1 五基准系统评测

覆盖五个基准：

• ALFWorld（具身规划）
• WebShop（网页操作）
• GAIA（多步检索）
• τ³-Bench（多轮对话）
• SWE-bench Verified（软件工程）

搭配三个模型家族：Claude Sonnet 4.6、GPT-5.4、Qwen3.5-9B。指标用pass@2。

15个模型×基准设置中，14个提升，平均+14.5%，最高+44.0%

模型	基准	基线	HarnessX	提升
Qwen3.5-9B	ALFWorld	53.0%	97.0%	+44.0%
Qwen3.5-9B	WebShop	44.0%	72.5%	+28.5%
Qwen3.5-9B	GAIA	15.3%	24.0%	+8.7%
Claude Sonnet 4.6	ALFWorld	80.0%	90.0%	+10.0%
GPT-5.4	WebShop	68.0%	78.0%	+10.0%

关键发现：提升幅度与基线高低呈反比——越弱的模型涨得越多。弱模型有大量自己改不掉但外壳能补上的行为缺口；强模型早填平了坑，剩下的硬骨头光改外壳不够。

3.2 变体隔离：解决异构任务冲突

唯一没提升的设置是 GAIA × GPT-5.4（异构任务集存在冲突决策偏好）。

采用变体隔离后（最多k个harness共存，按历史成功率路由）：稳定提升到87.4%，且token消耗更低。

3.3 与 Claude Code SDK 对比

把四阶段AEGIS换成单Agent进化器（Claude Code SDK）：

• 同等模型与基础设施下，最终精度相当
• 但AEGIS省了约12% token

结论：在足够强的元Agent下，HarnessX优势主要来自可隔离的类型化组件 + 可诊断的结构化轨迹——效率与可审计性更好。

3.4 协同进化：额外+4.7%

对比"冻结模型仅更新harness" vs "协同进化"：

• GAIA 与 WebShop 两个基准上，协同进化额外多榨出平均+4.7%

3.5 失败案例：AEGIS的纠偏能力

τ³-Bench 上连续多轮同类改动后，合规率骤降14个点（灾难性遗忘），但随后在两轮内自行诊断并恢复。

奖励作弊、探索不足也反复出现，但AEGIS流水线能快速纠偏，保证性能整体上升。

---

四、局限与诚实披露

作者对自身边界相当坦诚：

1. 跨任务泛化性：所有提升都在用于进化的同一批任务上测得，对未见任务的泛化尚未验证 2. 离散动作空间：未验证能否推广到连续控制等场景 3. 强元Agent依赖：AEGIS需要具备多文件代码生成、结构化轨迹分析与多步规划能力的元Agent，实现时用的都是闭源强模型 4. 基准覆盖度：SWE-bench仅用55题子集，τ³-Bench只评了三个域

---

五、核心启示：为什么这篇论文重要？

5.1 三个关键洞察

1. 外壳和模型是共生体，不是上下游

传统思路：模型训练好了，再套个外壳去用。HarnessX 证明：外壳的进化轨迹本身就是模型训练信号，两者应该协同进化。

2. 组件化不是过度工程，是自动进化的前提

如果harness是一团代码，自动修改它等于让LLM改 spaghetti code——成功率低、可解释性差、难以回滚。HarnessX 的类型化hook + 处理器架构，本质上是给自动进化创造了一个可操作的修改空间。

3. 防御性设计比进攻性设计更重要

现有自进化工作大多关注"怎么让系统自动改进"，HarnessX 额外关注"怎么防止系统改进时翻车"。AEGIS 的四阶段流水线、确定性门控、变体隔离——都是防御性架构，这在Agent自进化领域很少见。

5.2 与Deli AutoResearch的对比

维度	Deli AutoResearch	HarnessX
目标	长程自主研究任务（数天到数周）	Agent执行性能优化
核心机制	状态文件 + 看门狗 + 停滞检测	类型化组件 + AEGIS进化引擎 + GRPO协同训练
进化对象	研究方向/论文结构	Agent外壳配置
防翻车机制	给自己往下打分 + 结构转向	四阶段评审 + 确定性门控 + 变体隔离
模型协同	无（只进化流程）	有（跨harness GRPO）
验证方式	模拟同行评审	真实基准测试 + 失败案例分析

两者互补：Deli AutoResearch 解决"长程任务怎么不死"，HarnessX 解决"Agent外壳怎么自动变好"。

5.3 对工程实践的直接启示

1. 如果你在做Agent框架：考虑把harness拆成类型化hook，而不是一个monolithic配置。这会让自动优化和A/B测试变得容易得多。

2. 如果你在用弱模型做Agent：harness层面的优化空间可能比换模型更大——Qwen3.5-9B在ALFWorld上暴涨44%就是证明。

3. 如果你在做RLHF/RLAIF：考虑 HarnessX 的跨harness GRPO设计——把策略差异（harness版本差异）变成组内对比信号，而不是采样噪声。

---

参考文献

• HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry. arXiv:2606.14249v1. Xiaomi Darwin Agent Team.
• Deli AutoResearch Framework: https://victorchen96.github.io/auto_research/framework.html

#HarnessX #AgentFramework #AutoEvolution #GRPO #Xiaomi #DarwinAgent #AEGIS #SelfPlay #AgentHarness #Composable #RL #WebShop #ALFWorld #GAIA #SWE-bench #ICLR #AutoML #LLM #Agent #OpenSource