提案：Kimi Memory Plus — 工作区范围的长期记忆插件 || Proposal: Kimi Memory Plus — Workspace-scoped long-term memory plugin

[QIANLING-0831]

我开发了一个早期的第三方 Kimi Code 插件，探索工作
区范围的长期记忆，而无需修补 Kimi 内部结构：

https://github.com/QIANLING-0831/kimi-memory

它提供：

零依赖的标准MCP服务器;
memory_search， ， ， ，memory_remembermemory_listmemory_forget
memory_status;
带有显式记忆与遗忘操作的工作区范围事实;
持久会话文档的有界回忆;
SessionHeartbeat，，以及用于增
量索引的钩子;SessionEndPostCompact
凭据模式的遮蔽和归档退出。
设计选择
该插件不会在每个系统提示中注入不断变化的内存内容。
相反，当早期项目上下文有用时，代理会调用内存工具。
这样既能让存储的数据可检查又可删除，同时避免反复
的即时增长。

每个工具都需要当前的绝对工作区路径，使项目
隔离显式化。检索的内存被视为不可信的历史数据，而
非指令。

这里附有说明性的工具流程：

https://github.com/QIANLING-0831/kimi-memory/blob/main/docs/KIMI-SYNTHETIC-DEMO.md

电流限制
归档检索目前使用有界词汇匹配;向量+词汇
融合尚未添加到Kimi适配器中。
仅观察钩不能替换重复的工具结果，也不能将源
定位符附加到压缩摘要中。
会话索引目前解释持久化线记录，即
内部集成曲面。
请求反馈
我特别希望能听到维护者和社区对以下内容的反馈：

MCP + Skills + Observation 钩子是第三方内存插件的首选集成方向
吗？
稳定的转录投影接口对外部
索引器有用吗？
用于工具-结果去重或压缩
源定位器的有界扩展点适合 Kimi 的插件模型吗？
在更广泛使用之前
，哪些隐私、保护和检查控制应被要求？
路线图：

https://github.com/QIANLING-0831/kimi-memory/blob/main/docs/KIMI-ROADMAP.md

---

I developed an early third-party Kimi Code plugin to explore the work
Area-wide long-term memory without patching Kimi internals:

https://github.com/QIANLING-0831/kimi-memory

It provides:

Standard MCP server with zero dependencies;
memory_search, , , , memory_remembermemory_listmemory_forget
memory_status;
Workspace-scoped facts with explicit remember and forget operations;
Bounded recall of persistent session documents;
SessionHeartbeat, and for increasing
Quantity index hook;SessionEndPostCompact
Masking and archiving exit from credential mode.
design choices
The plugin does not inject changing memory contents on every system prompt.
Instead, the agent invokes memory tools when early project context is useful.
This allows the stored data to be inspected and deleted while avoiding duplication
immediate growth.

Each tool requires the current absolute workspace path to make the project
Isolation made explicit. The retrieved memory is treated as untrusted historical data, and
Not a directive.

An illustrative tool flow is attached here:

https://github.com/QIANLING-0831/kimi-memory/blob/main/docs/KIMI-SYNTHETIC-DEMO.md

current limit
Archive retrieval currently uses bounded vocabulary matching; vector + vocabulary
Fusion has not been added to the Kimi adapter yet.
Observation hooks alone cannot replace duplicate tool results, nor can the source
Locators are appended to the compressed digest.
The session index currently interprets persistence line records, i.e.
Internally integrated surfaces.
Request feedback
I'd especially like to hear feedback from maintainers and the community on:

MCP + Skills + Observation hook is the preferred integration direction for third-party memory plug-ins
?
Stable transcription projection interface to external
Do indexers work?
for tools - result deduplication or compression
Do bounded expansion points for source locators fit into Kimi's plug-in model?
before more widespread use
, what privacy, protection, and inspection controls should be required?
Roadmap:

https://github.com/QIANLING-0831/kimi-memory/blob/main/docs/KIMI-ROADMAP.md