AI Agent自进化：如何用HarnessBank验证真实提升并构建数据飞轮

2026-08-11 12:36 0 阅读

在 AI Agent 的实际应用中，一个令人困惑的现象屡见不鲜：同一个模型，权重参数完全冻结，仅仅更换了外围的 Harness（运行外壳），最终表现却可能大相径庭。这看似是工程中的“玄学”，实则暴露了自进化走向产品必须回答的两个核心问题：如何证明改进是真实有效的，以及如何获得足够连续、真实、可回溯的数据，让改进能够长期发生。EverMind 正试图用 HarnessBank、Raven 与 EverMe，将这两个问题接成同一条产品路径。

模型未变，为何 Harness 更换导致“变笨”？

在 AI Agent 的架构中，模型只是能力的一部分。包裹在模型外围的提示词、知识注入、工具调用、运行时逻辑与配置，共同构成了 Harness，即 Agent 的“运行外壳”。同一颗模型放入不同 Harness，就像同一个人进入不同组织：知识与智力未变，但决策流程、工具条件和反馈机制一变，最终表现便会截然不同。EverMind 在 HarnessBank 研究中给出了一个直观结果：在 AppWorld 测试集上，同一颗冻结权重的 Qwen3.6-27B 模型，仅通过 Harness 进化，测试集 Pass@1 从 41.3% 提升至 56.7%。在覆盖终端操作、代码生成、数学推理、网页研究、知识工作、应用控制与代码修复的七个基准中，测试集 Pass@1 均取得正向提升，幅度为 5.1 至 15.4 个百分点。

但真正困难的并非让某一次分数上涨，而是证明上涨来自可复用的机制改进，而非随机波动、任务过拟合，甚至沙箱崩溃与验证器超时造成的“假成功”。如果连提升是否真实都无法判断，所谓自进化就可能变成自动制造回归。

HarnessBank：把“自我改进”变成可验证的工程

核心架构：一个 Agent 跑任务，一个 Agent 改 Harness

HarnessBank 的核心思路是将系统拆分为两个角色，形成一种“非对称”的进化结构：

任务 Agent：负责在现行的 Harness 下执行具体任务。它的骨干模型是被冻结的（默认使用 Qwen3.6-27B），保持稳定；
Evolver Agent：这是一个独立的、能力更强的模型（例如 Claude Opus 4.8）。它的任务是读取“任务 Agent”的执行轨迹，诊断出反复出现的失败机制，并生成新的候选 Harness。

这种设计的精妙之处在于：改进由一个“强模型”来思考，而被改进的只是一个“弱模型”的外壳。在形式上，进化只允许修改 Harness 的“可变面”（如 prompt、注入知识、运行时逻辑、配置），而评估、记账、自进化相关的代码则被锁成“不可动内核”。这种严格的控制保证了进化前后的结果始终具有可比性。

进化过程绝非盲目试错，而是遵循严谨的四步循环：

选择父代：从“基因库”中按质量偏置选出当前最强的 Harness 作为父代；
运行诊断：运行一批训练任务，获取完整的诊断信息（分数、轨迹、评估元数据）；
生成后代：Evolver 基于诊断生成后代：要么从失败轨迹中重新发明一个机制，要么将不同格子的机制重组起来；
门控筛选：后代必须通过严格的“筛选门”，通过后才能进入完整评估并最终入库。

避坑指南：现有自进化方案的三大“翻车”陷阱

为什么现有的许多自进化方案在实际应用中常常失效？EverMind 团队在论文中指出了三种典型的“翻车”方式，HarnessBank 针对性地给出了解决方案。

陷阱一：搜索塌缩

传统的贪心演化策略只保留当前看起来最好的改动。随着代数推移，改动的种类越来越窄，最后往往塌缩成 prompt 层面的保守修补。那些激进的、结构不同的方案一旦单次失败就会被彻底抛弃。

EverMind 的应对：Harness Gene Bank。HarnessBank 不按分数高低只存一个最优解，而是采用类似 MAP-Elites 的思想，按“语义坐标”分格存档。横坐标（改在哪）：prompt、知识、运行时、配置；纵坐标（为什么改）：针对哪类失败病理。同一病理的候选在同格竞争，不同病理的方案各占一格，既保住了多样性，又确保了每一格的质量。而这件事成立的前提是每一步都过了门控：只有确认真实有效的机制才值得留存，也只有这样，把它们累加起来才是在探索更好的 Harness，而不是在累积噪声。

陷阱二：任务过拟合

如果没有门控机制，进化很容易留下“背题补丁”——它在训练任务上有效，仅仅是因为记住了这些具体任务，而不是修正了真实的失败机制。

EverMind 的应对：严格的留出集验收。HarnessBank 明确区分了“多样性”和“防过拟合”。按病理分格解决了多样性和可重组问题；而真正阻挡过拟合的闸门，是测试集全程不参与进化决策，只在最后做一次验收。

陷阱三：收益不可验证

这是最隐蔽也最致命的陷阱。单次运行分数上涨，可能是机制真的起效，但也可能是执行噪声，甚至是沙箱崩溃、验证器超时等基础设施故障被误算成了成功。实测表明，无门控的循环甚至会部署比初始状态更差的“负优化”版本。

EverMind 的应对：四道严格的“门控”。

核心机制：四道门拦住“假提升”

Gated Harness Screening 是 HarnessBank 全文最核心的设计。每一个生成的后代，都必须在采样的任务子集上通过四道严格的关卡：

执行有效性门：确保任务确实执行了，没有因沙箱崩溃、超时等基础设施问题导致无效结果。
行为差异门：确保改动确实改变了 Agent 的行为，而非仅仅修改了 prompt 但实际执行路径未变。
统计显著性门：通过显著性检验（如配对 t 检验或 bootstrap），确认提升不是随机波动。
基线优势门：确保后代在验证集上优于当前父代，且提升幅度超过预设的最小阈值。

消融实验证明了这四道门的分量：如果去掉显著性检验门，收敛后的轮次中有 62% 到 76% 是“幻影进展”。而带有完整门控的版本，则能在 10 轮下限处干净退出，确保每一次部署都是真实的提升。

核心洞察：没有万能的 Harness

HarnessBank 在七个基准测试（覆盖终端操作、代码生成、数学推理等）中，测试集 Pass@1 全部实现了正向提升（幅度 +5.1% 到 +15.4%），且绝大多数通过了统计可信检验。但更重要的发现是：没有万能的 Harness。

跨模型实验揭示了一条深刻的“病理到补丁的匹配律”：每个模型都有自己支配性的失败模式。例如，Qwen3.6-27B 容易死于“空转回合”，verify-finalize 补丁能带来 +15.4% 的提升；而 Qwen3.6-397B 和 Gemini 3 Flash 则容易死于“粗心”，需要的是“清单补丁”。如果把 27B 的补丁生搬硬套给 397B，效果几乎归零；如果把针对某一模型的恢复机制错误地应用到另一个模型，甚至会导致严重的负优化（如 -15.7%）。更极端的例子在数学推理上：Qwen3.6-27B 的问题是“想太多”，Gemini 恰恰是“想太少”，同一个推理预算的旋钮，两个模型需要往相反方向拧。

结论很明确：真正可迁移的，是从诊断失败、结构化搜索到统计验证的这整套“流程”，而不是任何一条具体的 Harness 或 Prompt。

给 Agent 开发者的四个实战建议

HarnessBank 的方法论并非免费（需要强模型算力和大量的 rollout 预算），但它为 Agent 调优提供了极具价值的指导。EverMind 总结了四条实战经验：

验证四问（适用于任何 Agent 调优）：评估环境干净吗？改动真的执行了吗？增益过显著性检验了吗？比基线强吗？
分格存档：别只留当前最好的一套配置，按“改在哪、解决什么问题”分格存，结构不同的好方案才有被重组的机会。
别找普适最优：Harness 是模型特定的，别人的配置搬过来可能无效甚至有害。带走诊断到验证的流程，而不是某一条 prompt。
先算账再上：强模型和门控都需要成本。这套方法值不值得，取决于你有多怕部署一次“看起来涨了其实是噪声”的回归。

EverMind 通过 HarnessBank 证明了，Agent 的自进化不应是玄学，而应是建立在严谨统计验证基础上的工程实践。

从 HarnessBank 到 Raven：自进化开始进入运行时

HarnessBank 回答了“怎样安全地改”，Raven 则把这套方法带入真实 Agent 的运行框架。作为构建在 EverOS 之上的自进化 Agent Harness，Raven 将长期记忆、技能体系、运行策略和工具调用连接起来，使 Agent 能够从任务轨迹中总结经验，在不必频繁修改底层大模型权重的情况下，持续优化自身的技能、工作流与外围运行逻辑。

这一步让 EverMind 的技术路线形成清晰分层：EverOS 负责把分散的交互、知识与个人信息组织成长期记忆；Raven 负责将这些记忆转化为更好的执行策略——HarnessBank 为策略进化提供可验证的方法；SkillCorpus 等研究则帮助成功经验被规模化沉淀、检索与复用。记忆不再只是一个档案馆，而成为 Agent 发现问题、形成经验和改写行为的原料。

然而，从论文和开发者框架走向大众产品，还缺少最关键的一环：持续、真实、由用户直接产生的数据。基准测试可以证明机制有效，却无法代替一个人在工作、学习、沟通和使用不同应用时形成的长期轨迹。没有这部分数据，自进化很容易停留在实验室；拥有这部分数据，Agent 才可能真正理解“对谁进化、为何进化，以及进化后是否更有用”。

EverMe 上线内测：C 端直接数据飞轮开始成形

目前，EverMind 的首个 C 端产品 EverMe 已上线内测。它并不是把 EverOS 的开发者接口简单搬到消费端，而是在 EverOS 记忆架构基础上，提供更轻便、直观的个人记忆管理与调用能力，让普通用户能够汇集、查看、追溯和使用自己的记忆，并将这些记忆数据交给不同 Agent 服务。

从现阶段产品结构看，EverMe 正围绕 Memory Hub、Knowledge Base、数字分身与 Agent Hub 四个模块展开：

Memory Hub：目前已打通 11 个 Agent，包括 Claude Code、Codex、OpenClaw、Hermes、Kimi Code、Raven 等，支持历史数据冷启动导入与后续记忆实时写入，并通过 Timeline 管理跨 Agent 的个人轨迹。
Knowledge Base：支持连接多种常见应用数据，也支持 Notion、Obsidian 与本地文件等内容导入，形成个人知识库；用户还可以基于自己的数据进行 Deep Research，让研究结果不只依赖公开互联网，也能结合个人材料、既有项目与长期上下文。
数字分身：提供主分身、Onboarding、对话流与记忆溯源 Reference，让用户能够看到回答依据了哪些个人记忆，并逐步形成持续更新的数字身份。
Agent Hub：支持 Agent 分享，并为后续的发现、评价与协作机制奠定基础，使个人记忆和专业 Agent 不再被锁在单一产品中。

此外，EverMind 已成为 MiniMax Code 首批支持的 7 个生态伙伴之一。这意味着 EverMe／EverOS 的个人记忆能力正在与主流编码 Agent 生态发生更直接的连接：用户在不同工具中的任务上下文、偏好和经验，有机会被统一沉淀，并在下一次任务中继续发挥作用。

为什么 C 端数据飞轮，是自进化产品化的基础

对自进化而言，数据量并不是唯一关键。更重要的是数据是否属于同一个主体、是否跨越足够长的时间、是否包含完整的任务过程与结果反馈，以及用户是否拥有管理和授权这些数据的能力。EverMe 的价值，正是在 EverOS 的记忆架构上建立一个面向个人的直接入口，把原本散落在文件、知识工具和不同 Agent 中的数据组织为连续的个人记忆资产。

当这套入口被持续使用，一个 C 端直接数据飞轮便开始形成：用户使用 EverMe 产生记忆数据，这些数据被用于优化 Agent 的 Harness，优化后的 Agent 提供更好的服务，吸引更多用户使用，从而产生更多数据。这个飞轮与传统互联网的数据飞轮有本质区别：它不是单纯用更多用户行为训练一个统一模型，而是围绕每个用户建立可管理的长期记忆，再让多个 Agent 在授权范围内消费这些记忆。由此产生的，不只是更大的数据池，而是更高质量的个体化经验：哪些信息值得记住、哪个 Agent 在什么场景下更有效、哪种工作流经常失败、什么结果符合用户偏好。

这也解释了为什么 EverMe 对 EverMind 的战略意义远大于一个 C 端记忆工具。它把 EverOS 的底层架构、Raven 的运行时进化和 HarnessBank 的验证机制，接入真实用户的长期使用场景。学术研究提供“如何进化”的方法，C 端产品提供“用什么进化”的数据，而连接多个 Agent 的生态则提供“在哪里验证进化”的任务环境。三者结合，自进化才有机会形成可持续的产品闭环。