省流版
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转呀转呀的时候去并行的陪人熬夜打游戏，起来之后牙没刷，饭还没吃想着来发个帖子，饿了，觅食~~
xxxxt 08-29 19:301楼
xx_yy1 08-29 22:002楼