但Hermes当初能从OpenClaw手里抢走用户，恰恰是因为它把记忆和学习能力焊死在了核心代理里。
Nous Research创始人Teknium在2026年9月18日发推宣布Hermes Agent将从捆绑式架构转向精简核心加插件市场的路线，第一步就是移除所有内置记忆提供商，Honcho、Mem0等八个记忆系统全部由第三方维护者在自己仓库中维护并通过插件市场分发。这条推文获得了超过17万次查看，社区反应两极分化。
Hermes要把自己的器官一个个拆下来
Teknium的原话是，Hermes要变得更像Pi，更不像OpenClaw。这句话立刻在评论区引发了困惑，因为大多数人第一反应是以为Hermes要从一个个人助理工具转型去做编码代理。Teknium随后专门发帖澄清，说他指的只是打包策略，不是产品定位。
他说的打包策略是什么。Hermes Agent从2026年2月发布以来，一直是一个高度集成的工具。你安装Hermes，得到的不只是一个能跑命令、能读文件的核心代理，还得到了一整套预装的功能组件。记忆系统有八个外部提供商可以选择，Honcho、Mem0、OpenViking、Hindsight、Holographic、RetainDB、ByteRover、Supermemory。工具提供商、消息平台集成、技能包，全部打包在核心安装包里。
你装一次Hermes，这些东西全部就位。不需要额外操作，不需要研究哪个提供商适合自己，打开就能用。这是Hermes在2026年上半年迅速崛起的关键原因之一。当时社区的评价是，Hermes凭借自进化Agent、自动记忆管理和用户建模系统，在技术上全面超越了前任王者OpenClaw。
但Teknium现在说，这些东西太重了。他的推文原话是：打包和捆绑的东西要减少，插件要多，核心要更精简。第一步就是移除所有内置记忆提供商，让它们的创建者自己维护，放在自己的组织仓库里，通过插件市场上架。
这听起来像是一次清理，但意味着每一个Hermes用户升级之后，原来开箱即用的记忆系统会消失。
Pi用四个工具打败了一堆功能
要理解Teknium为什么要把Hermes往Pi的方向推，得先搞清楚Pi到底是个什么东西。
Pi是一个开源编码代理框架，GitHub上已经超过10万个星标，npm周下载量超过120万。它的设计理念跟当前主流AI编程工具完全相反。Claude Code、Cursor、Codex CLI这些工具都在疯狂堆功能，宠物、子代理、计划模式、扩展市场，恨不得把所有能想到的东西全塞进去。Pi反其道而行之，默认只给模型提供四个工具：读文件、写文件、编辑文件、执行命令。
四个工具，系统提示词加工具定义一共不到1000个token。就这么一个极简到离谱的东西，它比功能堆到爆的竞品跑得还稳。原因在于Pi的设计哲学：有了执行命令这个工具，需要搜文件就跑rg，需要看Git日志就跑git log，需要装依赖就跑npm install。大部分需求不需要专门做工具，一个bash就能搞定。工具越多，模型选择成本越高，出错概率越大，调试难度越高。
Pi的核心代码不到1500行，只有5个文件。它的系统提示词短到你可以一口气读完，模型不需要在一堆工具描述里找哪个才是当前任务该用的。这种极致的精简换来了两个东西：更低的token成本，更高的行为可预测性。当模型面对的工具只有四个的时候，它出错的概率天然就比面对四十个工具要低。
但是，这套逻辑有一个前提：用户愿意自己动手。Pi不内置子代理，不内置计划模式，不内置待办列表，甚至不内置权限系统，默认以启动它的那个用户的权限运行。你需要什么能力，自己用TypeScript写一个扩展放进去。Pi的哲学是“适配你的工作流，而不是反过来”。
对于那些在终端里泡了十年的开发者来说，这简直是最理想的设计。但Hermes的用户里有一大批不是这种人。
Hermes当初靠什么从OpenClaw手里抢人
OpenClaw是Hermes崛起之前开源AI代理领域的头号选手，它的策略跟Pi完全相反。
2026年9月发布的OpenClaw 2.0是一次超大规模更新，包含了16977个合并请求、698个直接提交和987位贡献者。这次更新触及了OpenClaw的每一个角落：安装引导、消息系统、记忆、技能、模型、自动化、浏览器控制、原生应用、插件、安全。
OpenClaw的记忆系统有一个叫Dreaming的东西，中文叫“梦境整理”。这是一个后台记忆巩固系统，它把强烈的短期信号移入持久记忆，整个过程保持可解释和可审查。Dreaming每次运行会执行三个协作阶段：浅层、REM、深层。它会把对话中产生的短期信号筛选、整理、加固，变成代理可以长期依赖的稳定记忆。你不需要做任何配置，OpenClaw自己会管这件事。
你下载OpenClaw，这些东西全部内置。不需要自己去插件市场找记忆提供商，不需要研究哪个技能包适合自己，不需要手动配置消息平台集成。开箱即用，全部就位。
这种厚重路线的代价是核心代码库越来越大，维护负担越来越重。但用户用脚投票的结果是，OpenClaw的厚重路线留住了人。基于500多条社区互动的一项分析发现，35%的用户依旧选择OpenClaw，原因是习惯、以及强大的技能和插件生态。不过同一份分析也显示，使用了OpenClaw的人中有30%开始使用Hermes，其中15%开始考虑迁移，原因是自主进化的学习能力、运行成本更低、不会经常崩溃。
Hermes在2026年上半年能从OpenClaw手里抢走这批用户，靠的正是把学习闭环和记忆系统深度集成到了核心代理里。用户不需要做任何配置，Hermes就知道怎么记住你、怎么学你、怎么越来越懂你。你纠正它一次，它把这次纠正写成一份可复用的技能文档。你让它处理一个复杂任务，干完之后它自己总结步骤和关键判断，存成一份Markdown文件。
现在Teknium要把这个集成拆掉，让用户自己装记忆提供商，自己配学习回路。这等于把Hermes当初赢来的核心优势主动放弃了。
变薄之后，Hermes还认得你吗
Hermes最核心的卖点是一个叫闭环学习回路的东西。翻译成大白话就是，你在用它干活的时候，它会默默记笔记。你纠正了它一次，它把这次纠正写成一份可复用的技能文档。你让它处理一个复杂任务，干完之后它会自己总结步骤和关键判断，存成一份Markdown文件。日积月累，它越来越懂你的工作习惯。
Nous Research的开发者Teknium每天用Hermes来开发Hermes本身。Hermes在旁边记录哪些做法管用、哪些做法被他否掉了。几个月下来，这个AI攒出了一套叫hermes-agent-dev的开发技能包，里面写着怎么准备合并请求、哪些捷径不能走、改了代码之后怎么验证。Teknium把这套技能包发给团队里所有工程师，谁都能装到自己那台Hermes上用。
这个学习回路要运转，依赖两样东西：记忆系统和技能系统。记忆系统让它记住你之前做过什么、纠正过什么、偏好是什么。技能系统让它把记住的东西转化成可复用的操作文档。这两个系统越深度集成到核心代理里，学习回路的效率和准确度就越高。
现在Teknium要把记忆系统从核心代码库里拆出去。记忆提供商将在第三方仓库里维护，用户需要自己去插件市场找到合适的、手动安装、手动配置。Hermes的核心代码里不再包含任何记忆提供商。
这就出现了一个矛盾。Hermes越精简，它对第三方记忆提供商的依赖就越深。而第三方提供商的质量、稳定性、API兼容性，Hermes团队不再直接控制。如果某一天Honcho改了API，或者Mem0停止维护，Hermes的核心代理可能连“记住用户昨天说了什么”这种最基本的事都做不到了。
社区里有人精准地指出了这一点：Hermes的闭环学习能力建立在记忆之上，而记忆现在不再是Hermes自己的事了。
记忆从核心拆出去的那一刻，学习闭环就断了
Hermes Agent有八个外部记忆提供商可以选择：Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory。一次只能激活一个，内置的MEMORY.md和USER.md始终在旁边辅助。
这些提供商各自有各自的专长。Honcho做的是AI原生的跨会话用户建模，带有辩证推理能力，它能从对话中提取关于你的结论，并且根据会话上下文自动调整推理深度。Mem0做的是服务端LLM提取加双记忆范围。Hindsight做的是知识图谱加反思合成。Holographic做的是本地SQLite存储加信任评分，零依赖。
当记忆提供商激活的时候，Hermes会自动做一连串事情：把提供商知道的上下文注入系统提示词，在每轮对话前预取相关记忆，在每次回复后同步对话内容，在会话结束时提取记忆，把内置记忆的写入镜像到外部提供商，并且添加提供商专用的工具让代理可以搜索、存储和管理记忆。
这一整套流程是Hermes学习闭环的发动机。记忆提供商负责“记住”，内置记忆和技能系统负责“转化”，两者咬合在一起，形成从对话到记忆、从记忆到技能、从技能到下次对话中自动调用的循环。
现在Teknium要把记忆提供商从核心代码库里拆出去。它们将在第三方仓库里维护，用户需要自己去插件市场找到合适的、手动安装、手动配置。
这意味着什么。意味着Hermes的核心代理不再保证你有一个可用的记忆系统。你需要自己判断哪个提供商适合你的使用场景，需要自己配置API密钥，需要自己在提供商出问题的时候去联系提供商的维护者。Hermes团队不再对这些记忆系统的质量、稳定性、API兼容性负责。
插件市场真的能接住被拆下来的功能吗
Teknium的推文里提到了一个关键前提：Hermes已经有了插件目录，几个月前就把所有集成做成了插件，现在可以开始把它们从核心安装包里移出去了。
这个插件目录叫Plugin Catalog，是一个经过人工审核的插件目录。每个目录条目是一个YAML文件，声明了插件名称、公共Git仓库、被审核的确切提交SHA、维护者、提供的能力、依赖的环境变量、最低Hermes版本要求。你可以在目录里搜索、按类别浏览、查看能力声明，然后用一条命令安装。
信任模型是这样的：每个条目都通过人工审核的合并请求进入目录，条目锁定到具体的提交SHA而不是分支，所以插件作者推送新代码不会改变目录安装的内容。目录还会维护一个已移除列表，被下架的插件会被记录原因和日期，安装器拒绝安装列表上的东西。
听起来很完善。但是有一个问题：插件目录解决的是发现问题，不解决功能回归问题。
Hermes记忆提供商的迁移已经在进行了。有一个叫Hindsight的记忆提供商，它的仓库官方迁移指南说明了如何把已弃用的pip插件平滑迁移到Hermes内置的原生Hindsight记忆提供者，保留同一个bank_id和后端就能无损继承历史记忆。操作方式是运行hermes memory setup选择hindsight，或者手动更新原生配置。
这说明迁移在技术上是可行的。但它需要用户主动操作。你需要知道记忆提供商被拆出去了，需要知道去哪里找替代品，需要手动运行迁移命令，需要验证迁移后记忆没有丢失。对于那些每天跑一次hermes update就当日常维护的用户来说，这个变化可能直接就让他们卡住了。
更关键的是，Hermes官方文档里有一条政策已经明确写着：内置记忆提供商目录已经关闭，新的记忆后端必须以独立插件仓库的形式发布，用户手动安装到~/.hermes/plugins/目录。现有的内置提供商保留，但新的一律不再进核心代码库。
这个政策意味着，Hermes的核心代码库里的记忆提供商列表被冻结了。Honcho、Mem0、OpenViking这些现有的提供商还能用，但它们的更新、维护、bug修复，Hermes团队不再直接负责。以后出了问题，你得去找提供商自己的维护者。
精简核心是对的，但记忆不是普通插件
Teknium的推文串里反复强调一个词：leaner core。精简核心。这个方向本身在软件工程上是对的。任何快速迭代的项目到了一定规模都会面临臃肿的问题。OpenClaw 2.0一个版本近17000个合并请求，你可以想象这个代码库的复杂程度。把功能从核心拆出去、变成可选插件，是控制复杂度最有效的手段之一。
但记忆系统和其他插件有一个本质区别。一个消息平台的集成插件出问题了，你换个平台用就行。一个技能包出问题了，你禁用那个技能就行。记忆系统出问题了，你丢的是过去几个月积累的上下文。你纠正过的每一个错误、你建立起来的每一个工作习惯、你让Hermes学会的每一个偏好，都在那个记忆系统里。
有一个用户的评论精准地戳到了这个差异：I think my agent got hacked n is killing my ram。他的问题可能不是记忆提供商的问题，但他的话里有一个隐含的假设：他默认Hermes的代理状态是一个整体，出了问题就是这个整体出了问题。当记忆提供商从核心拆出去之后，这种“整体感”就消失了。你面对的是一堆互相连接但各自独立的组件，任何一个组件出问题都需要你自己去排查是哪个环节出了问题。
Pi的设计师Mario Zechner在Harness v3里做了一件事：状态持久化。系统在模型请求和工具调用前后保存执行状态，让代理在崩溃或升级之后能从上次中断的地方继续干活。重启之后Pi知道哪些任务已经完成、哪些可以重跑、哪些有副作用不能重复执行。这个能力对于长时间运行的任务至关重要。
Pi做这件事的时候，是把状态管理放在harness核心里的。因为状态是代理干活的基础，不是一个可选插件。Hermes现在的做法是把记忆从核心拆出去，这和Pi的设计逻辑是相反的。
Teknium在推文里说，精简核心意味着更少的人在不该走的路上走偏。这句话针对的是那些配置错了插件导致Hermes出问题的用户。但记忆的问题不是配置错了才出的，记忆的问题是：如果你不配置它，它就完全不存在。一个没有记忆的Hermes，和一个没有记忆的Pi，是两种完全不同的东西。Pi从一开始就不承诺记忆，用户知道要自己搞。Hermes承诺了记忆，用户习惯了记忆，现在要把它拿走。
用户面对的选择比官方想象的要残酷
Teknium的推文获得了大量关注，社区的反应两极分化明显。支持者说这是正确的方向，精简核心加插件是成熟开源项目的最终形态。反对者的担忧集中在一点：Hermes的核心卖点之一是“懂你”，而“懂你”依赖于记忆。把记忆拆出去之后，Hermes还能不能“懂你”，变成了一个用户需要自己去解决的问题。
有一个事实值得注意。Hermes的记忆提供商目录已经关闭了，新的记忆后端必须以独立插件仓库的形式发布，用户手动安装到plugins目录。这意味着现有的八个提供商——Honcho、Mem0、OpenViking、Hindsight、Holographic、RetainDB、ByteRover、Supermemory——它们的更新和维护责任已经转移了。Hermes团队不再直接负责这些记忆系统的质量。
插件目录里已经有一个独立提供商了，叫openbrain，通过MCP Streamable HTTP连接。这说明迁移在技术上已经可行了。但可行和好用之间有一个距离。Hindsight的迁移指南提到，迁移后需要运行hermes memory status，然后在next turn测试recall，not the same turn。这个细节说明记忆的生效有延迟，你需要等一轮对话才能确认它工作正常。对于一个每天跑一次hermes update就当维护的用户来说，这个延迟可能意味着他们在不知情的情况下丢掉了记忆。
Nous Research的开发者做了一次公开复盘，把Hermes大规模重构中的每一个框架bug都找出来，开了13个修复合并请求。其中一个专门做了一件事：自动检测代码中有没有公开名称被意外删除，这个检测脚本18秒就能跑完。如果这个保险在重构之前就存在，大约52个返工提交根本不会发生。
但那个故事里没有人提出一个更根本的问题：如果一个AI工具把自己拆成了核心加插件，然后核心又变薄了，那么当用户升级之后发现记忆没了、技能失效了、之前写好的自动化脚本报错了，他们会怪谁。怪Hermes团队？怪记忆提供商的维护者？怪自己没看迁移指南？
插件目录的信任模型是这样的：每个条目通过人工审核的合并请求进入目录，条目锁定到具体的提交SHA而不是分支，安装器拒绝安装已下架列表上的东西。这个模型解决的是发现问题，不解决功能回归问题。如果Honcho明天改了API，Hermes的核心代理可能连“记住用户昨天说了什么”这种最基本的事都做不到。Hermes团队不再对这件事负责，因为Honcho现在是一个独立插件了。
而对于那些当初选择Hermes就是因为不想自己组装的人来说，这个变化可能比任何代码重构都难以接受。你选择Hermes是因为它什么都记得，现在它把记忆变成了一个可选项。你打开Hermes，它问你：你装了记忆插件吗？你没装？那我不记得你昨天说过什么。
拆完了之后，Hermes还剩下什么
回到最开始的那个问题。如果记忆提供商拆出去了，消息集成拆出去了，技能包拆出去了，Hermes的核心还剩下什么。
根据Teknium的推文，核心剩下的是代理本身的干活逻辑：读文件、写文件、执行命令、调用插件、管理会话。这些是Pi的四个工具加上插件调度层。Hermes的闭环学习能力还在，但它现在学到的技能需要用户自己选择存在哪里、用什么记忆系统来支撑。
Pi的路线在技术社区里被验证是可行的，10万星标说明有一大批开发者愿意接受极简核心加自己组装的模式。但Pi的用户和Hermes的用户不完全是同一批人。Pi的用户是那些愿意在终端里敲命令、自己写扩展、自己调配置的开发者。Hermes的用户里有一大批是想要一个开箱即用的个人助理、不想折腾配置的普通用户。
Teknium说Hermes不会变成编码代理，它还是一个个人助理代理。但一个个人助理的核心能力是记住你、了解你、越来越懂你。如果记忆系统变成了用户自己安装的第三方插件，这个助理的“了解”能力就变成了一个可选项，而不是一个内置承诺。
有用户在评论区里说了一句值得琢磨的话：我大概两个月前就停止更新Hermes了，这东西已经相当结实了。这句话的潜台词是，他不需要最新功能，他需要的是一个不会突然坏掉的东西。
Teknium的这次转向，在技术架构上可能是正确的，核心精简加插件市场是很多成熟开源项目的最终形态。但在用户体验上，它把一个开箱即用的产品变成了一个需要自己组装的产品。对于那些当初选择Hermes就是因为不想自己组装的人来说，这个变化可能比1703个公开接口被删还要难以接受。
插件目录里已经有240多个工具，社区技能市场已经上线，迁移路径文档已经写好。技术层面，Hermes正在变成一个更干净、更可控、更容易维护的系统。
但当一个用户打开Hermes，发现它不再记得自己昨天说了什么，因为记忆插件还没装的时候，他会不会想起当初选择Hermes的原因，恰恰是因为它什么都记得。
Hermes把记忆系统拆出去之后，用户得自己组装第二大脑了
Hermes学Pi做极简核心，但它忘了Pi从一开始就不承诺记忆
Hermes宣布移除所有内置记忆提供商，一万七千人围观背后是同一个问题
一个AI助手把记忆变成可选插件，这事对吗