MoonshotAI / MoonshotAI/kimi-cli

提案:Kimi Memory Plus — 工作区范围的长期记忆插件

Open
#2,613 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
11.4k
Forks
1.3k
Avg merge
9h 47m
Merged PRs (30d)
2

Description

What feature would you like to see?

Proposal: Kimi Memory Plus — workspace-scoped long-term memory plugin

Compatibility update (2026-08-21): Current Kimi Code CLI can register the explicit-memory tools as a stdio MCP server, but it does not recognize this repository's experimental kimi.plugin.json manifest. Automatic Skill and hook registration, including archive indexing, is not currently claimed as compatible. See the compatibility notes.

Summary

I built a small third-party Kimi Code plugin that explores explicit,
workspace-scoped long-term memory without patching Kimi internals:

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

The current release is v0.2.0.

It provides:

  • a zero-dependency stdio MCP server;
  • memory_search, memory_remember, memory_list, memory_forget,
    memory_audit, and memory_status;
  • workspace-scoped facts with explicit remember and forget operations;
  • provenance, revision, expiry, and content-free audit events for core facts;
  • bounded recall over persisted session documents;
  • SessionHeartbeat, SessionEnd, and PostCompact hooks for incremental
    indexing;
  • credential-pattern redaction and an archive opt-out.

Positioning

There are already more feature-rich community memory projects, including
kimi-mneme, as well as cross-agent
systems such as Mnemon,
Honcho, and
Supermemory. This project
deliberately takes a narrower path:

  • no inferred user profile;
  • no automatic fact extraction;
  • no external service or embedding dependency;
  • explicit workspace isolation;
  • inspectable provenance and removable facts;
  • strict storage and recall budgets;
  • a zero-dependency Node.js runtime and MIT license.

The goal is not to replace those systems. It is to explore whether Kimi users
also benefit from a minimal, auditable memory option with conservative defaults.

Design choices

The plugin does not inject changing memory content into every system prompt.
Instead, the Agent invokes memory tools when earlier project context is useful.
This keeps stored facts inspectable and deletable while avoiding repeated prompt
growth.

Every tool requires the current absolute workspace path, making project
isolation explicit. Retrieved memory is treated as untrusted historical data,
not as instructions.

Facts are limited to 2,000 characters. Recall shares one character budget across
all returned snippets. Temporary facts can be assigned an expiry, and lifecycle
events retain hashes and metadata rather than deleted fact text.

An illustrative tool flow is included here:

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

Current limitations

  • Archive retrieval currently uses bounded lexical matching. Semantic retrieval
    is intentionally not a runtime dependency in this version.
  • Observation-only hooks cannot replace duplicate tool results or attach source
    locators to a compaction summary.
  • Session indexing currently interprets persisted wire records, which is an
    internal integration surface.

Feedback requested

I would especially appreciate maintainer and community feedback on:

  1. Is MCP + Skills + observation hooks the preferred integration direction for
    a third-party memory plugin?
  2. Would a stable transcript projection interface be useful for external
    indexers?
  3. Would bounded extension points for tool-result deduplication or compaction
    source locators fit Kimi's plugin model?
  4. Which privacy, retention, and inspection controls should be required before
    broader use?
  5. Is an explicit-only, non-profiling memory mode useful alongside the existing
    automatic and semantic-memory projects?

Roadmap:

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

Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked compatibility notes, synthetic demo, and roadmap for the proposed Kimi Code integration. Review the five feedback questions about MCP, transcript projections, extension points, and privacy controls; this issue is complete only after maintainers define an accepted integration direction and concrete scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js
Domain
cli, devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.