模型换个Harness就「变笨」？EverMind把自进化从研究推向产品，让AI「越用越聪明」焦点报道-走进中关村网

模型换个Harness就「变笨」？EverMind把自进化从研究推向产品，让AI「越用越聪明」焦点报道

来源：机器之心Pro 　2026-08-11 11:29:35

同一个模型，权重一个参数都不改，只是换一套 Harness，表现就可能大幅波动。这看似是 Agent 工程中的「玄学」，实际上暴露了自进化走向产品必须回答的两个问题：怎样证明改进真实有效，以及怎样获得足够连续、真实、可回溯的数据，让改进能够长期发生。

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：把「自我改进」变成可验证的工程

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

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

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

这种设计的精妙之处在于：改进由一个「强模型」来思考，而被改进的只是一个「弱模型」的外壳。

图 1：传统人工调优（上）需要耗费大量人力且效率低下，而 HarnessBank 自进化（下）通过双 Agent 架构和基因库分格存档，实现了精准、高效的自动化迭代。

在形式上，进化只允许修改 Harness 的可变面（如 prompt、注入知识、运行时逻辑、配置），而评估、记账、自进化相关的代码则被锁成不可动内核。这种严格的控制保证了进化前后的结果始终具有可比性。

图 2：HarnessBank 框架流程：1) 选出当前最强父代；2) 运行训练任务获取诊断；3) 基于基因库重组或重新发明机制；4) 通过四道门控筛选；5) 评估并竞争入库。

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

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

02. 避坑指南：现有自进化方案的三大「翻车」陷阱

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

陷阱一：搜索塌缩

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

EverMind 的应对：Harness Gene Bank

HarnessBank 不按分数高低只存一个最优解，而是采用类似MAP-Elites的思想，按「语义坐标」分格存档。

横坐标（改在哪）：prompt、知识、运行时、配置。
纵坐标（为什么改）：针对哪类失败病理。

同一病理的候选在同格竞争，不同病理的方案各占一格，既保住了多样性，又确保了每一格的质量。而这件事成立的前提是每一步都过了门控：只有确认真实有效的机制才值得留存，也只有这样，把它们累加起来才是在探索更好的 Harness，而不是在累积噪声。

陷阱二：任务过拟合

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

EverMind 的应对：严格的留出集验收

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

陷阱三：收益不可验证

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

EverMind 的应对：四道严格的「门控」

03. 核心机制：四道门拦住「假提升」

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

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

04. 核心洞察：没有万能的 Harness

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

但更重要的发现是：没有万能的 Harness。

跨模型实验揭示了一条深刻的「病理到补丁的匹配律」：每个模型都有自己支配性的失败模式。

Qwen3.6-27B容易死于「空转回合」，verify-finalize补丁能带来+15.4%的提升。
Qwen3.6-397BGemini 3 Flash则容易死于「粗心」，需要的是「清单补丁」。
如果把 27B 的补丁生搬硬套给 397B，效果几乎归零；如果把针对某一模型的恢复机制错误地应用到另一个模型，甚至会导致严重的负优化（如-15.7%）。
更极端的例子在数学推理上：Qwen3.6-27B的问题是「想太多」，Gemini 恰恰是「想太少」，同一个推理预算的旋钮，两个模型需要往相反方向拧。

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

05. 给 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 端直接数据飞轮便开始形成：

这个飞轮与传统互联网的数据飞轮有本质区别。它不是单纯用更多用户行为训练一个统一模型，而是围绕每个用户建立可管理的长期记忆，再让多个 Agent 在授权范围内消费这些记忆。由此产生的，不只是更大的数据池，而是更高质量的个体化经验：哪些信息值得记住、哪个 Agent 在什么场景下更有效、哪种工作流经常失败、什么结果符合用户偏好。

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

从「更聪明的模型」走向「越用越懂你的系统」

今天，大模型行业仍习惯用参数规模、基准成绩和上下文长度衡量智能。但对用户而言，真正可感知的进步往往更朴素：它是否记得我做过什么，是否理解我为什么这样做，是否能从上一次的失误中改进，是否能把一个工具里的经验带到另一个工具里。

HarnessBank 证明，冻结权重的模型也能通过外围机制获得显著且可验证的提升；Raven 让这种提升进入 Agent 的持续运行过程；EverMe 则开始把个人数据、记忆管理和多 Agent 生态连接起来。

由此，EverMind 正在形成一条从学术研究、开源基础设施到 C 端产品的完整路径。

这条路径的终点并不是让所有人拥有同一个更强的 AI，而是让每个人拥有一个基于自身记忆、能够跨应用协作、并在真实使用中持续进化的智能系统。随着 EverMe 内测推进和更多 Agent 接入，EverMind 所探索的自进化，也正在从论文中的统计显著性，走向用户每天都能感知的能力复利。

更多信息请访问：