同一个模型，权重一个参数都不改，只是换一套 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-397B 和 Gemini 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 所探索的自进化，也正在从论文中的统计显著性，走向用户每天都能感知的能力复利。
更多信息请访问：
EverMe：https://everme.evermind.ai/
Raven：https://raven.evermind.ai/
HarnessBank：https://arxiv.org/abs/2607.13683
注：本文参考 EverMind 开源社区大使 「尹珉的 AI 笔记 」原创分析文章《没有万能的 Harness：为什么它换个模型就失灵》改写后获得授权发布。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
