很多AI agent的问题不是prompt里塞的文本不够多，而是它们根本没法查阅、遍历和审计自己的记忆。

现在的解决方案大致三类：向量数据库做语义检索、把历史对话塞进上下文窗口、或者让agent自己写总结。这些方法在简单场景够用，但一旦agent开始干正经活，光靠找相似文本就不行了——你需要的是重建整个过程。

打开网易新闻 查看精彩图片

关键问题变成：这事是谁干的？基于什么证据？从哪步走到哪步？中间改过什么主意？最后怎么拍板的？

Underpass KMP最初想解决的事更小：只找回必要的上下文，让agent不用重读整段对话就能继续任务。作者叫它"上下文再水合"——从已记录的记忆里，只重建下一步需要的那部分。

但测试后发现真正的坑更深。不是prompt准备得不够好，而是缺一层能记录"发生了什么、何时发生、谁干的、证据在哪、事后怎么追溯"的记忆层。

于是有了Kernel Memory Protocol（KMP）：一套小而明确的API，用来写入、查询、遍历、追踪和检查agent的记忆。

最初的错误是把记忆当成搜索引擎。搜索引擎能返回跟你问题相似的文本，适合找零散信息，但无法理解工作过程。agent完成任务时，重要的不是找到相似句子，而是能重建：从哪开始、试过什么、证据在哪、何时变的、谁参与、怎么结束的。

这个区别塑造了KMP的核心。它不是另一个文本搜索机制，而是可导航的记忆。

所以KMP不暴露向量数据库API，暴露的是记忆动作：

  • ingest → 注册记忆
  • wake → 找回继续所需状态
  • ask → 向记忆提问并带证据
  • goto → 跳到某个具体时刻或引用
  • near → 查看某时刻周围发生了什么
  • rewind/forward → 前后移动
  • trace → 解释关系路径
  • inspect → 检查记忆节点

核心设计是保持系统中心够小。KMP不做agent，也不决定最终答案。它的职责只有三样：存结构化记忆、支持确定性遍历、返回可审计的证据。最终答案生成、业务规则、领域插件都可以包在KMP外面，不必塞进核心。

KMP的中心对象叫"about"——一个案例、主题或记忆世界，可以是一次事故、一个任务、一个客户、一个benchmark、一个代码仓库、一个用户，或者agent的某个长期进程。