CM - CASS 记忆系统 是做什么的？
专为 AI 编码代理设计的程序性记忆。将零散的会话转换为持久的、跨代理的记忆。采用三层认知架构，模拟人类专业技能的发展过程。
为什么存在
AI 编码代理积累了宝贵的知识，但这些知识通常：
- 困在会话中 - 会话结束时上下文丢失
- 特定于代理 - Claude 不知道 Cursor 学到了什么
- 非结构化 - 原始日志不是可操作的指导
- 容易崩溃 - 简单的摘要会丢失关键细节
这个月你已经在不同的代理中解决了三次认证 bug。每次你都得从头开始。
CM 通过跨代理学习解决了这个问题：在 Cursor 中发现的模式可以立即被 Claude Code 使用。
三层认知架构
┌─────────────────────────────────────────────────────────────────────┐
│ 情节记忆 (cass) │
│ 来自所有代理的原始会话日志 — “基本事实” │
│ Claude Code │ Codex │ Cursor │ Aider │ PI │ Gemini │ ChatGPT │ ...│
└───────────────────────────┬─────────────────────────────────────────┘
│ cass search
▼
┌─────────────────────────────────────────────────────────────────────┐
│ 工作记忆 (Diary) │
│ 结构化的会话摘要：成就、决策等。 │
└───────────────────────────┬─────────────────────────────────────────┘
│ reflect + curate（自动化）
▼
┌─────────────────────────────────────────────────────────────────────┐
│ 程序记忆 (Playbook) │
│ 经过置信度跟踪和衰减提炼的规则 │
└─────────────────────────────────────────────────────────────────────┘
每个代理的会话都会输入到共享记忆库。在 Cursor 中发现的模式自动在下一次会话中帮助 Claude Code。
你需要的一个命令
cm context "<你的任务>" --json
在开始任何非平凡任务之前运行此命令。 返回：
- relevantBullets - 根据任务相关性评分的 Playbook 规则
- antiPatterns - 已经引起过问题的内容
- historySnippets - 过去的会话（你自己的和其他代理的）
- suggestedCassQueries - 更深入的调查搜索
按来源过滤历史记录
historySnippets[].origin.kind 是 "local" 或 "remote"。远程命中包括 origin.host：
{
"historySnippets": [
{
"source_path": "~/.claude/sessions/session-001.jsonl",
"origin": { "kind": "local" }
},
{
"source_path": "/home/user/.codex/sessions/session.jsonl",
"origin": { "kind": "remote", "host": "workstation" }
}
]
}
置信度衰减系统
规则不是永生的。如果没有重新验证，置信度会衰减：
| 机制 | 效果 |
|---|---|
| 90 天半衰期 | 每 90 天在没有反馈的情况下置信度减半 |
| 4 倍有害乘数 | 一次错误相当于四次成功的影响 |
| 成熟度递进 | candidate → established → proven |
分数衰减可视化
初始分数：10.0（今天10次有用的标记）
90天后（半衰期）： 5.0
180天后： 2.5
270天后： 1.25
365天后： 0.78
有效分数公式
effectiveScore = decayedHelpful - (4 × decayedHarmful)
// 其中衰减系数 = 0.5 ^ (daysSinceFeedback / 90)
成熟度状态机
┌──────────┐ ┌─────────────┐ ┌────────┐
│ candidate│──────▶│ established │───▶│ proven │
└──────────┘ └─────────────┘ └────────┘
│ │ │
│ │ （有害 >25%） │
│ ▼ │
│ ┌─────────────┐ │
└────────────▶│ deprecated │◀─────────┘
└─────────────┘
转换规则：
| 转换 | 标准 |
|---|---|
candidate → established | 3+ 次有用，有害率 <25% |
established → proven | 10+ 次有用，有害率 <10% |
any → deprecated | 有害率 >25% 或显式废弃 |
反模式学习
坏规则不只是删除。它们会变成警告：
"缓存认证令牌以提高性能"
↓ （3次有害标记）
"陷阱：不要在没有过期验证的情况下缓存认证令牌"
当一个规则被多次标记为有害（>50% 有害率且 3+ 次标记）时，它会自动被反转为反模式。
ACE 管道（规则创建方式）
Generator → Reflector → Validator → Curator
| 阶段 | 角色 | 使用 LLM? |
|---|---|---|
| Generator | 任务前上下文水合（cm context） | 否 |
| Reflector | 从会话中提取模式（cm reflect） | 是 |
| Validator | 针对 cass 历史进行证据门控 | 是 |
| Curator | 确定性增量合并 | 否 |
关键： Curator 不使用 LLM，以防止因迭代漂移导致的上下文崩溃。LLM 提出模式；确定性逻辑管理它们。
科学验证
在规则加入你的 Playbook 之前，它会针对 cass 历史进行验证：
提议规则："总是在认证调试前检查令牌过期"
↓
证据门控：搜索 cass 中应用此规则的会话
↓
结果：找到 5 个会话，4 个成功结果 → 接受
没有历史证据的规则会被标记为候选，直到被证明。
命令参考
上下文检索（主要工作流）
# 主要命令 - 在非平凡任务前运行
cm context "实现用户认证" --json
# 为节省 token 预算限制结果
cm context "修复 bug" --json --limit 5 --no-history
# 使用工作空间过滤器
cm context "重构" --json --workspace /path/to/project
# 自文档化解释
cm quickstart --json
# 系统健康检查
cm doctor --json
cm doctor --fix # 自动修复问题
# 查找相似规则
cm similar "错误处理最佳实践"
Playbook 管理
cm playbook list # 所有规则
cm playbook get b-8f3a2c # 规则详情
cm playbook add "总是先运行测试" # 添加规则
cm playbook add --file rules.json # 从文件批量添加
cm playbook add --file rules.json --session /path/session.jsonl # 跟踪来源
cm playbook remove b-xyz --reason "已过时" # 移除
cm playbook export > backup.yaml # 导出
cm playbook import shared.yaml # 导入
cm playbook bootstrap react # 将启动器应用到现有规则
cm top 10 # 最有效的规则
cm stale --days 60 # 没有最近反馈的规则
cm why b-8f3a2c # 规则来源
cm stats --json # Playbook 健康指标
学习与反馈
# 手动反馈
cm mark b-8f3a2c --helpful
cm mark b-xyz789 --harmful --reason "导致回归"
cm undo b-xyz789 # 撤销反馈
# 会话结果（位置参数：状态，规则）
cm outcome success b-8f3a2c,b-def456
cm outcome failure b-x7k9p1 --summary "认证方法失败"
cm outcome-apply # 应用到 Playbook
# 反思（通常是自动化的）
cm reflect --days 7 --json
cm reflect --session /path/to/session.jsonl # 单个会话
cm reflect --workspace /path/to/project # 项目特定
# 验证
cm validate "总是在解引用前检查 null"
# 审计会话中的规则
cm audit --days 30
# 永久废弃
cm forget b-xyz789 --reason "已被更好的模式取代"
入职（代理原生）
使用你现有的代理实现零成本的 Playbook 构建：
cm onboard status # 检查进度
cm onboard gaps # 类别缺口
cm onboard sample --fill-gaps # 优先处理的会话
cm onboard sample --agent claude --days 14 # 按代理/时间过滤
cm onboard sample --workspace /path/project # 按工作空间过滤
cm onboard sample --include-processed # 重新分析会话
cm onboard read /path/session.jsonl --template # 丰富上下文
cm onboard mark-done /path/session.jsonl # 标记为已处理
cm onboard reset # 重新开始
Trauma Guard（安全系统）
cm trauma list # 活跃模式
cm trauma add "DROP TABLE" --description "批量删除" --severity critical
cm trauma heal t-abc --reason "有意的迁移"
cm trauma remove t-abc
cm trauma scan --days 30 # 扫描创伤
cm trauma import shared-traumas.yaml
cm guard --install # Claude Code 钩子
cm guard --git # Git pre-commit 钩子
cm guard --install --git # 两者
cm guard --status # 检查安装状态
系统命令
cm init # 初始化
cm init --starter typescript # 使用模板
cm init --force # 重新初始化（创建备份）
cm starters # 列出模板
cm serve --port 3001 # MCP 服务器
cm usage # LLM 成本统计
cm privacy status # 隐私设置
cm privacy enable # 启用跨代理丰富
cm privacy disable # 禁用丰富
cm project --format agents.md # 导出用于 AGENTS.md
启动 Playbook
从一个空的 Playbook 开始很艰巨。启动器提供了精选的最佳实践：
cm starters # 列出可用启动器
cm init --starter typescript # 使用启动器初始化
cm playbook bootstrap react # 应用到现有的 Playbook
内置启动器
| 启动器 | 重点 | 规则数 |
|---|---|---|
| general | 通用最佳实践 | 5 |
| typescript | TypeScript/Node.js 模式 | 4 |
| react | React/Next.js 开发 | 4 |
| python | Python/FastAPI/Django | 4 |
| node | Node.js/Express 服务 | 4 |
| rust | Rust 服务模式 | 4 |
自定义启动器
在 ~/.cass-memory/starters/ 中创建 YAML 文件：
# ~/.cass-memory/starters/django.yaml
name: django
description: Django Web 框架最佳实践
bullets:
- content: "始终使用 Django 的 ORM 进行数据库操作"
category: database
maturity: established
tags: [django, orm]
内联反馈（在工作期间）
在代码注释中留下反馈。会在反思期间被解析：
// [cass: helpful b-8f3a2c] - 这条规则让我避免了浪费时间
// [cass: harmful b-x7k9p1] - 这个建议对我们的用例是错误的
代理协议
1. 开始： cm context "<任务>" --json
2. 工作： 在遵循规则时引用规则 ID（例如，“遵循 b-8f3a2c...”）
3. 反馈： 当规则有帮助/有害时留下内联注释
4. 结束： 只需完成。学习会自动进行。
你不需要：
- 运行
cm reflect（自动化会处理） - 手动运行
cm mark（使用内联注释） - 手动向 Playbook 添加规则
差距分析类别
| 类别 | 关键词 |
|---|---|
debugging | error, fix, bug, trace, stack |
testing | test, mock, assert, expect, jest |
architecture | design, pattern, module, abstraction |
workflow | task, CI/CD, deployment |
documentation | comment, README, API doc |
integration | API, HTTP, JSON, endpoint |
collaboration | review, PR, team |
git | branch, merge, commit |
security | auth, token, encrypt, permission |
performance | optimize, cache, profile |
类别状态阈值：
| 状态 | 规则数 | 优先级 |
|---|---|---|
critical | 0 规则 | 高 |
underrepresented | 1-2 规则 | 中 |
adequate | 3-10 规则 | 低 |
well-covered | 11+ 规则 | 无 |
Trauma Guard：安全系统
“热炉”原则——从过去的事件中学习并防止再次发生。
工作原理
会话历史 创伤注册表 运行时防护
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ rm -rf /* (哎呦)│ ──────▶ │ 模式：rm -rf │ ──────▶ │ 已阻止：此命令 │
│ “抱歉，我犯了 │ 扫描 │ 严重度：致命 │ 钩子 │ 匹配了一个创伤 │
│ 一个错误...” │ │ 会话：abc123 │ │ 模式 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
内置的毁灭模式（20+）
| 类别 | 示例 |
|---|---|
| 文件系统 | rm -rf /, rm -rf ~, 递归删除 |
| 数据库 | DROP DATABASE, TRUNCATE, DELETE FROM 没有 WHERE |
| Git | git push --force 到 main/master, git reset --hard |
| 基础设施 | terraform destroy -auto-approve, kubectl delete namespace |
| 云服务 | aws s3 rm --recursive, 破坏性 CloudFormation |
模式存储
| 范围 | 位置 | 目的 |
|---|---|---|
| 全局 | ~/.cass-memory/traumas.jsonl | 个人模式 |
| 项目 | .cass/traumas.jsonl | 提交到仓库供团队使用 |
模式生命周期
- 活跃: 阻止匹配的命令
- 已治愈: 临时绕过（带有原因和时间戳）
- 已删除: 移除（可以重新添加）
MCP 服务器
作为 MCP 服务器运行以便代理集成：
# 仅本地（推荐）
cm serve --port 3001
# 使用认证令牌（用于非回环）
MCP_HTTP_TOKEN="<随机数>" cm serve --host 0.0.0.0 --port 3001
暴露的工具
| 工具 | 方法 | 描述 |
|---|---|---|
context | get_context | 获取任务上下文（Playbook 规则、反模式、历史记录片段） |
record_outcome | record_outcome | 记录成果（成功、失败、部分成功）并关联规则 |
add_rule | add_rule | 手动向 Playbook 添加规则 |
mark_feedback | mark_feedback | 提供关于规则的反馈（有用、有害） |
trauma_heal | trauma_heal | 治愈创伤模式（带原因） |
trauma_scan | trauma_scan | 扫描过去的会话以发现创伤 |
stats | get_stats | 获取 Playbook 健康指标 |