7月9日消息,Kimi Code 现已可通过一句提示词接入 EverMe Memory。接入后,Kimi Code 可在不同会话与不同 Agent 之间携带上下文,把学到的内容复用为 Skills,降低每次从零开始的成本。EverMe 官网与安装契约文档已将 Kimi Code 列入支持范围;npm 上的原生插件包 @everme/kimicode 于 7 月 2 日发布。 一句话安装,但 Kimi Code 实际是两步落地
EverMe 对外统一入口仍是一句安装提示:让 Agent 读取官方 Skill 文档并按说明完成安装与配置。官网称该方式适用于 Claude、Claude Code、Cursor、ChatGPT 等 Agent。对 Kimi Code,官方安装契约写得更细:先由 evercli 执行 kimicode 插件安装,写入本机凭证文件并暂存插件包;再在 Kimi Code 终端界面内用插件安装命令完成注册,并重载或新开会话。契约明确指出,Kimi Code 没有无头安装命令,因此与 Claude Code、Cursor 等主机不同,必须「CLI 暂存 + 终端注册」两步完成。 插件包说明显示,接入后能力分两层。一层是生命周期钩子:会话开始时注入近期画像与情节记忆,用户提交提示前检索相关记忆,停止时把刚结束的一轮对话写入记忆库。另一层是捆绑的记忆 MCP 服务,提供上下文读取、语义搜索、保存事实与保存对话轮次四类工具,并附带记忆召回与工具使用相关 Skills。EverMe 文档强调,记忆按用户账户共享,而非按工作区隔离,因此同一人在多台设备、多个 Agent 上可读写同一记忆池。
补的是跨会话连续性,不是 Kimi Code 的模型能力本身
Kimi Code 是月之暗面面向终端与 IDE 的编程 Agent,支持仓库级任务规划、命令执行与多文件改动。社区与第三方记忆方案近期反复提到同一问题:编程 Agent 在会话之间默认不保留状态,项目约定、排障结论与个人偏好往往要重新交代。月之暗面开源仓库里也有关于跨会话持久记忆的功能讨论。EverMe 这次宣布的,是把外部记忆层接到 Kimi Code 工作流里,而不是发布新的编程模型。
EverMe 产品页把自身定位为个人记忆中枢:跨 Agent 同步、自动生成结构化记忆目录、记忆可追溯可导出可回滚。官网举例称,告诉 Hermes 的技术方案,可由 Claude Code 直接执行。把 Kimi Code 纳入同一记忆池后,叙事上指向的是「上下文跟人走,不跟单个编程工具走」。需要克制的是,发文中的「降低从零开始的成本」目前没有公开的耗时、Token 或任务成功率对比数据;Skills 复用也取决于记忆抽取质量与召回相关性,不能直接等同于稳定的工程资产沉淀。
真正值得看的是记忆层正在变成 Agent 标配接口
单独看这条更新,信息量是「又一个编程 Agent 接上第三方记忆」。放在 2026 年的工具生态里,更清楚的信号是:跨会话记忆正在从各家自建文件方案,转向可安装的外部记忆服务。Mem0 等方案也在讨论如何给 Kimi 编程模型补持久记忆;EverMe 的差异在于同时强调跨 Agent 共享,以及把经验沉淀进 Skills 与结构化目录。对开发者而言,这意味着个人偏好与项目经验有机会在 Kimi Code、Cursor、Claude Code 之间复用;对月之暗面而言,这是生态侧补齐,不等于官方原生记忆系统已经上线。
市场容易误读的地方有两处。一是把 EverMind 发文写成「Kimi 官方发布共享记忆」——目前可核验的是 EverMe 支持 Kimi Code。二是把「一句话安装」理解成对 Kimi Code 也完全零操作;官方契约已写明,Kimi Code 还需在终端内完成插件注册与重载。安全边界同样写进契约:Agent Token 等凭证只应落在受控本地文件,不应写入可同步到云端或 Git 的记忆笔记。
接下来要看召回质量,以及月之暗面是否给出原生记忆路线
后续首先要看实际使用中的召回是否稳定:跨会话能否准确带回项目约定与排障结论,跨 Agent 时会否出现错误迁移或噪声注入。其次要看安装摩擦:两步流程是否会成为 Kimi Code 用户的主要流失点,后续是否出现无头注册能力。再次要看月之暗面是否推出官方记忆方案,或对第三方记忆插件给出更明确的兼容说明。共同的验证标准很具体:同一开发者换会话、换 Agent 后,是否还需要反复重述同一批上下文;如果答案长期仍是「需要」,共享记忆就还停留在接入完成,而不是工作流真正变短。