个人的 OpenCode 的跨会话记忆配置+会话内不失真压缩裁剪上下文（compact）方案

省流版

- claude-mem 负责全部将细节注意记住，跨会话记忆存储当前 top 方案

- magic-context 负责会话内上下文裁剪，和近期记忆保存。记忆方面不强，但是会话内保持任务目标和遵守规范行为进行进行上下文裁剪压缩

- Strict-Doc 负责记录固化的项目文档文件，记忆文件。主要是方便人类进行阅读查看

- AGENTS.md 添加一小段 tail 来规范行为

- 自制 load-mem 和 save-mem 以及 migrate-mem 的 skill 来和上面的功能进行呼应

具体配置

安装配置 claude-mem```
npx claude-mem install --ide opencode
``运行这个官网上的命令就能直接安装了，不过需要注意一点。这个是在 ~/.config/opencode/plugins 下面安装了一个 claude-mem.js 的插件脚本。同时对应的服务是运行在 ~/.claude/plugins/cache/thedotmack/claude-mem 的一个目录下。同时这个 claude-mem.js 只是提供了一个 search 工具。假如想要更多工具，可以在 opencode.jsonc 中配置 mcp 服务器。``
{
"mcp": {
"claude-mem": {
"type": "local",
"command": ["~/.bun/bin/bun", "~/.claude/plugins/marketplaces/thedotmack/plugin/scripts/mcp-server.cjs"],
"enabled": true
},
}
}
``然后在 ~/.claude-mem/settings.json 中的配置就如下所示，大家基本都是自定义API，比如使用 NewAPI，所以初始化配置的时候选择 OpenRouter，API那里随便输入字符串就行了，可以自己去 json 文件中进行细节配置，这里的 openrouter 背后的格式就是 openai-compatible 了``
{
"CLAUDE_MEM_RUNTIME": "worker",
"CLAUDE_MEM_PROVIDER": "openrouter",
"CLAUDE_MEM_OPENROUTER_BASE_URL": "BASE URL",
"CLAUDE_MEM_OPENROUTER_MODEL": "model name",
"CLAUDE_MEM_CONTEXT_OBSERVATIONS": "20",
"CLAUDE_MEM_OPENROUTER_API_KEY": "API Key"
}
``自行替换这里的路径即可，目前的 claude-mem 的插件脚本并没有注册全部 mcp 工具，要使用更多的 mcp 工具就需要把本地运行这个 mcp-server.cjs` 的脚本

安装配置 magic-context```
curl -fsSL https://raw.githubusercontent.com/cortexkit/magic-context/master/scripts/install.sh | bash
```运行这个官网提供的命令即可。

对应的配置文件为 ~/.config/cortexkit/magic-context.jsonc```
{
"$schema": "https://raw.githubusercontent.com/cortexkit/magic-context/master/assets/magic-context.schema.json",
"historian": {
"opencode": {
"model": "提供商/模型"
}
},
"execute_threshold_percentage": 65, // 模型 input 的百分比，达到 65% 开始进行记忆存储，后续还会有裁剪
"embedding": {
"provider": "openai-compatible",
"model": "text-embedding-3-large",
"endpoint": "BASE URL",
"api_key": "API KEY"
},
"dreamer": {
"opencode": {
"model": "提供商/模型"
}
},
"sidekick": {
"disable": true
}
}
```配置 historian 和 dreamer 两个 Agent 的模型，这里使用 opencode.jsonc 中配置的提供商和模型即可，然后再单独配置一下 embedding

注意：一定要记得禁用 opencode 内置的 compact 功能，不然和 magic-context 冲突，opencode.jsonc 的配置如下```
{
"compaction": { "auto": false, "prune": false },
"plugin": [
"@cortexkit/opencode-magic-context@latest",
]

}
```Strict Doc 配置

这个配置没啥好说的，主要是配置个 python 环境，让 Agent 去配置就行了。

定期让 Agent 更新一个项目文档，要人能够看懂，claude-mem 和 magic-context 本质是面向 Agent，面向会话上下文的，而 Strict Doc 是面向开发者用户的

Skill & AGENTS.md 配置

下面是 load-mem 的 SKILL.md```

name: load-mem
description: load all memory layers (injected memory, StrictDoc project_memory, claude-mem history) plus core files to understand the project

Build an understanding of this project from all available memory layers, then verify against core files and directory structure.

Memory layers (in priority order):

1. Injected project memory — the <project-memory> block in your system prompt is already loaded. Do NOT re-fetch it. It is the authoritative source for constraints, config values, and conventions.
2. File memory (StrictDoc) — docs/ is one StrictDoc project with two trees: project_memory/ (memory: decisions.sdoc for 口径+初衷, journal.sdoc for progress) and handbook/ (durable documents: specs, research, evaluations). Read the .sdoc files directly:
- Nodes carry UID (stable anchor), STATUS, STATEMENT (the decision itself), RATIONALE (why it was made).
- STATUS discipline: only Active nodes are current canon. Deprecated/Superseded/Proposed nodes are history — never quote them as current practice. When a node is Superseded, follow the relation to its successor.
- To query precisely instead of reading everything: strictdoc export --formats=json . in docs/, then e.g. jq '.DOCUMENTS[].NODES[] | select(.STATUS=="Active")' output/json/index.json.
3. Action history (claude-mem) — a passive log of past tool activity with semantic search. If the files look stale or you need "what was actually done recently", use the claude_mem_search tool (fallback: curl http://127.0.0.1:37700/... worker API). Treat results as leads, not gospel — verify against files/git before acting on them.

Then ground it in code:

• Glob the directory structure and read core files to confirm the memory matches reality.
• In projects not yet migrated, legacy markdown may still exist in other subdirectories under docs/ (e.g. old superpowers/, research/). Skim for context but treat as historical until migrated into docs/handbook/.

You can use ripgrep and naive grep, and load relevant skills as needed.
``下面是 save-mem 的 SKILL.md``

name: save-mem
description: save memory according to current state and progress — durable facts to ctx_memory, narrative to StrictDoc project_memory

Record the current state so the next session can resume quickly. Extract the most core and important content. Be concise and to the point.

Route by content type — do not dump everything into files:

1. Durable operational facts (constraints, config values, naming conventions, architecture facts, hard-won workarounds) → write to ctx_memory. These are auto-injected into every future session.
2. Project narrative (progress, decisions with rationale, next steps) → the docs/project_memory/ tree (see below).
3. Durable documents (specs, research reports, evaluations, design docs) → the docs/handbook/<topic>/ tree (see below).
4. Follow-ups for later → ctx_note.
5. Action details (which commands ran, which files were touched) → do NOT record. claude-mem captures tool activity automatically.

Writing to docs/project_memory/ (memory tree):

• Decisions go to decisions.sdoc as [DECISION] nodes: UID (DEC-XXX-NNN), STATUS (Proposed/Active/Deprecated/Superseded), TITLE, STATEMENT (the canon), RATIONALE (the original motivation — always fill this; losing it is a known pain point).
• Progress entries go to journal.sdoc as [TEXT] nodes with a date UID (e.g. JOURNAL-2026-08-26), referencing decision UIDs where relevant.
• Never delete or rewrite a node. To retire one: set STATUS: Deprecated or Superseded and add a RELATIONS: - TYPE: Parent / VALUE: <successor UID> / ROLE: Supersedes link from the successor node.
• Validate after every write: run strictdoc export . in docs/ (covers both trees). A parse error must be fixed immediately — never leave the tree broken. Environment: prefer plain strictdoc from the currently activated Python env (the agent shell usually inherits the user's conda/uv/venv env). If it's not on PATH, detect the project's env (e.g. .venv/bin/strictdoc, uv run strictdoc, or a named conda env) — do not assume .venv.
• SDoc strict rules: one empty line between nodes, no content outside grammar elements, no empty optional fields (omit them). Sections use ONLY the double-bracket form [[SECTION]]/[[/SECTION]] — the single-bracket [SECTION] was removed in strictdoc 0.28.3 (processor error). If export fails with "[SECTION] elements are no longer supported", some file uses the single-bracket form — fix with: find . -name '*.sdoc' -exec sed -i -e 's/^\[SECTION\]/[[SECTION]]/g' -e 's/^\[\/SECTION\]/[[\/SECTION]]/g' {} +

Writing to docs/handbook/ (document tree):

• One .sdoc per document under a topic subdir (e.g. handbook/research/, handbook/specs/).
• [DOCUMENT] header has no UID field — use TITLE: + DATE:; add OPTIONS: with MARKUP: Markdown (the default RST chokes on ``fences and backticks`).
• Map ## headings to [[SECTION]] + [TEXT] nodes; every section must be closed with [[/SECTION]].
• Keep the content verbatim; structure is the only thing you add.

Chinese is preferable for node content, but English is acceptable; you may mix. Clarity matters most.```

下面是 migrate-mem 的 SKILL.md

name: migrate-mem
description: migrate an existing project's scattered/flat legacy memory files and documents into the three-layer memory system (ctx_memory + StrictDoc project_memory/handbook). Use when adopting the memory stack in a project that already has accumulated messy memory notes or docs.
---

Migrate legacy memory files into the three-layer system WITHOUT losing information or misjudging what is still current. Work in phases; the classification plan must be reviewed by the human before any writing.

**Prerequisites (verify first, stop if missing):** strictdoc env installed (pin the version, e.g. `strictdoc==0.28.1`, and keep it identical across machines — GitHub releases run ahead of PyPI and 0.28.3 removes single-bracket `[SECTION]`), `docs/` StrictDoc skeleton exists in the v2 layout (config at `docs/strictdoc_config.py` + `project_memory/` + `handbook/` trees), project `AGENTS.md` trigger block in place. If the skeleton is absent or a different layout, stop and ask the human — do not improvise a restructure.

## Phase 0 — Safety

- Copy every legacy memory file to `docs/_memory_archive/` (OUTSIDE the two sdoc trees, preserving paths). Originals are only moved, never deleted, and only after the final report is accepted.

## Phase 1 — Inventory

- Find all memory-bearing files: old `docs/project_memory/*.md`, scattered NOTES/TODO files, spec/plan/research/evaluation docs under `docs/` subdirectories, root-level notes.
- Read them fully (chunk large files; keep a ledger file so compaction loses nothing). Extract discrete items, each tagged: operational fact / decision / progress / durable document / action trivia / obsolete — with its source file path.

## Phase 2 — Classification plan (HUMAN CHECKPOINT)

- Route each item per the standard rules: durable operational fact → `ctx_memory`; decision → `[DECISION]` node; progress/status → `journal.sdoc`; durable document (spec/research/evaluation/design doc) → `docs/handbook/<topic>/` via md→sdoc wrapping (see Phase 3); pure action trivia → drop (claude-mem covers it).
- Contradictions: pick the current canon, mark losers as `Superseded` with a relation to the winner. If you cannot tell which is current, mark the item `STATUS: Proposed` and flag it — do NOT guess.
- **Never fabricate a RATIONALE.** Only write one when the original motivation is discernible from the source text; otherwise omit the field. An invented rationale is worse than a missing one.
- Present the plan as a table (item → destination → STATUS → reason) and STOP for human approval. On first migration of a project, always stop; on later runs, stop only if conflicts or Proposed items exist.

## Phase 3 — Execute (after approval)

- UIDs: scan existing nodes, continue the sequence; topic prefixes (DEC-MEM-*, DEC-AUTH-*, ...).
- Write `decisions.sdoc` / `journal.sdoc` nodes. STATEMENT keeps the original wording of the canon (light clarity edits only).
- **Document wrapping (md → handbook sdoc)**: one md file → one `.sdoc` under `docs/handbook/<topic>/`. `[DOCUMENT]` header: `TITLE:` + `DATE:` (no UID field exists) + `OPTIONS:` with `MARKUP: Markdown`. Map `##` headings to `[[SECTION]]` + `[TEXT]` nodes (double brackets ONLY — single-bracket `[SECTION]` is removed in 0.28.3+); close every section with `[[/SECTION]]`. Content stays verbatim — you add structure, not prose.
- Write `ctx_memory` entries for operational facts — list existing memories first to avoid duplicates.
- Validate after EVERY file edit: `strictdoc export .` in `docs/`. Fix parse errors immediately. Prefer plain `strictdoc` from the activated Python env (conda/uv/venv — the agent shell usually inherits it); if not on PATH, detect the project's env instead of assuming `.venv`.

## Phase 4 — Report & archive

- Report: counts by destination, conflicts resolved (and which side won), `Proposed` items awaiting human confirmation, dropped trivia.
- Move originals into `docs/_memory_archive/`. Confirm `strictdoc export .` still passes.```

 

还有一个就是 `AGENTS.md` 的 tail 内容

 

```<!-- memory-system:start -->
## Project Memory System

This project uses a three-layer memory system (Magic Context + StrictDoc + claude-mem).

- **At session start**: run the `load-mem` skill before doing substantial work.
- **At milestones and before ending work**: run the `save-mem` skill.

### Rules that always apply (even if the skills are not loaded)

1. `docs/` is a single StrictDoc project with two trees: `project_memory/` (memory: decisions, journal) and `handbook/` (durable documents). Only nodes with `STATUS: Active` are current canon; `Deprecated`/`Superseded`/`Proposed` nodes are history — never quote them as current practice.
2. Never delete or rewrite memory nodes. Retire via `STATUS` change plus a `Supersedes` relation to the successor node.
3. After editing any `.sdoc` file, validate immediately: run `strictdoc export .` inside `docs/`. Prefer the `strictdoc` on PATH (the activated conda/uv/venv env is inherited by the agent shell); if absent, detect the project env (e.g. `.venv/bin/strictdoc`, `uv run strictdoc`) — do not assume a specific env manager. Never leave the tree broken.
4. On conflict between memory sources, `ctx_memory` (the injected `<project-memory>` block) wins.

(Procedures for reading/writing memory live in the `load-mem`/`save-mem` skills — keep this file short.)
<!-- memory-system:end -->```

 

这几个 SKILL.md 是我自己的一些 artifacts，每个人都有自己的爱好，这个是我个人迭代出来的，专门做了一个 `migrate-mem` 来将我之前的一些老项目迁移成我想要的这种记忆文档系统的框架。这里的 AGENTS.md 力的这段用 `<!-->` 包裹起来的，就是放到 AGENTS.md 的结尾处的，用于诱导 Agent 使用这些规范而已。

 

总结

 

我主要是设计了一个 `docs/project_memory` 用来存储项目相关的记忆，让人能够知道这个项目发生了什么，做过什么。然后又设计了一个 `docs/handbook` 专门来搭建项目文档。然后都通过 Strict Doc 来方便进行可视化，既方便人类阅读，也方便 Agent 来探索。

 

然后 `claude-mem` 会通过 hook 的系统来一步步在后台进行记忆的 dump，这里会记住许许多多的细节信息，但是这个系统并不知道任务主线，项目细节是怎样的，只是有什么就记下来，这套记忆系统做的很好。

 

`magic-context` 也有记忆功能，不过他这个记忆功能肯定做的没有 `claude-mem` 好，但是他还有一个好处就是能够在上下文超限的时候，由模型来进行合适的上下文裁剪，并且在上下文累积的时候，也会进行记忆的 dump，不过不是 `claude-mem` 那样机械式的进行存储，而是由Agent通过工具调用自主决策记忆什么内容。所以他维护近期记忆，和长期规范的能力比较好，也就是说你给他一大段的规范文本，着重强调之后，即使经过裁剪，它能够延续你的这个任务主线和目标进行开发，因为 `magic-context` 本质上是挑选哪些块留下，哪些块压缩，但同时能给出一个 context 的索引，因为之前存储过，以及用户给的输入基本上也都能留下来。不像 opencode 内置的 compact，真的就是全盘替换内容，替换成他压缩的那么一套 `Details, Next Move` 那一套文本，那套基本上全乱套了，各种细节全没了。

 

然后通过 `load-mem` 和 `save-mem` 的 SKILL 搭配 `AGENTS.md` 尾部的这一个提醒块，进行一个逻辑口径的闭环，让 Agent 知道咱们有这么多工具可以用。用来让 Agent 更积极的进行记忆的保存和取出。

 

目前的想法就是这样，现在这样 gpt-5.6-sol 的 372K 上下文是完全够用的，并且全程用下来就是不会失忆的。并且能够在一个会话中，进行一次次的任务发布，细致修理，完成，再到下一阶段任务的发布。综合用起来，不用再频繁的进行 HANDOFF 然后去新的会话中进行 HANDOFF 的转接了。

 

所以推荐在进行所有的任务操作前都进行一次细致的 grilling 操作，做完之后，Agent 基本就能死死记住这些内容，后续的上下文都由 `magic-context` 来控制，用不到 opencode 内置 `compact` 了。哪怕是非常长的同质化的内容操作，比如对一个批量的目录下面的代码做成相同语义的更改，这样也不会因为爆上下触发 `compact` 而导致最初的任务语义发生更改。这一点是我最喜欢 `magic-context` 的一点。

 

Agent 能从设计的 `docs/` 目录中找回记忆，找回规范，也能从 `magic-context` 提供的工具中找回记忆，最后还能从 `claude-mem` 中找回之前精准的都做过什么。再通过这一套插件式闭环的 SKILL 文本引导系统，感觉这下做的挺不错了，真的不虚 codex 和 claude code 了~~~

 

所以大家记得在对话中有意无意的，超绝不经意的加一句的，`记得在明确所有规范后保存一下记忆`，或者 `记得在完成所有的任务内容后，也更新一下记忆`，`你感觉你踩了哪些坑，也可以记录一下`。基本能做到 Agent 不会在同一个坑里面踩两次了。比如某个 `LD_LIBRARY_PATH` 变量没设置导致哪个 `libxx.so` 找不到的报错，减少上下文噪声，模型智商也就能感觉到噌的一下变高了~

 

嗯，大概就是这么多了，干项目在Agent转呀转呀的时候去并行的陪人熬夜打游戏，起来之后牙没刷，饭还没吃想着来发个帖子，饿了，觅食~~