Agent 双层记忆仓库

要解决的问题

Agent 的上下文窗口在会话结束后就清空了。平台注入的 working memory 只是当前会话摘要，既没有跨轮的决策理由，也没有排障根因；把有用信息随手写进对话或文件，下次接手时要么找不到，要么找到一堆重复、过期、互相矛盾的记录。更麻烦的是「该不该记」这件事没有规则：什么值得跨会话保留、什么只是噪声，往往靠临时判断，结果是记忆库越堆越脏，检索回来还要人工再过滤一轮。

这个技能怎么做

它是一个纯 Node.js CLI，记忆分两层：workspace（项目内进度、决策、排障、交接）与 global（跨项目偏好和通用事实）。Agent 只负责判断语义价值和摘要分类，校验、存储、过滤、排序、归档全部由 CLI 完成。

写入前先看策略档位，off / explicit / balanced / proactive 分别决定是否允许自动检索、自动存储以及单次对话上限。用户明确要求的走 --intent explicit，策略触发的必须走 --intent automatic，自动存储还要带上稳定的 --source-conv-id，CLI 会直接拒绝不符合当前档位的操作。

检索有明确优先级：先显式检索，再策略检索，问题自包含就跳过。提取 2–3 个稳定关键词并始终带 Agent 身份，任务交接优先查工作区共享记忆。只把与当前问题直接相关的结果用于回答；新旧记忆冲突时优先时间更晚、标记为最终决策且与当前实现一致的那条，并主动向用户说明推断。只读环境直接用 search 摘要，避免调用会更新访问计数的 recall。

存储前过三问：跨会话或交接后仍有用吗、能压成清晰标题加约 200 字摘要吗、不记会丢关键信息吗。三问全「是」才写，且不要存原始对话全文，优先更新既有记忆。同时按信号打类型和优先级：decision、debug_solution、workflow、preference、fact、state、event、relation。

适用边界

多 Agent 协作靠稳定的 --as-agent / --agent-id 或 MEMORY_AGENT_ID 做过滤，接手任务先消费 shared 记忆，完成阶段后再贡献新状态。需要精确过滤或归档恢复等高级能力时才读 references/cli.md，策略与并发、损坏恢复问题看 references/operations.md，直接改字段看 references/memory_schema.json。

几个硬性限制值得记住：private 只是基于 agent-id 的协作过滤，不是加密、不是操作系统权限、更不是可信安全边界，CLI 不会自动检测或脱敏密钥、凭据、令牌和个人信息，不要把秘密写进记忆库。项目层面的改动严禁用 --scope global。除非 CLI 不可用且已备份，否则不要手工改写 memories.json，并发环境下尤其不要。记忆无命中时如实说明无命中，再从代码、文档或用户提供的信息继续调查，不要猜测历史。