AI 编程工具为何忘记团队决策：跨工具上下文共享方案

同时跑 Cursor 和 Claude Code 的团队会遇到同一堵墙。

CLAUDE.md 只适用于单席位。它无法跨席位传递决策。一个 agent 搞清楚了为什么当初弃用了 Redis，另一个 agent 第二天又建议用 Redis。

规则文件是静态的。团队上下文不是。

模型质量突飞猛进。共享上下文没有跟进。

每周仍在浪费时间的场景：

• 每次 session 开始都要重新解释同一个架构决策
• 切换工具（Cursor 切到 Claude Code，或 Codex）后丢失上一个 agent 学到的东西
• Alice 周一修了一个迁移 bug；Bob 的 agent 周二又重新发现了一遍
• 明知团队受 GDPR 约束、采用本地部署、或有客户 NDA，却把第三方"记忆 SaaS" 当作没问题

内置记忆通常是按机器或按代码库来的。规则文件靠手工维护，容易分歧。两者都不是跨工具的共享团队存储。

值得持久化的内容

聊天记录不是好的主记忆。它们冗长、嘈杂，充满了被废弃的想法。

应该用小而持久的记录：

• Decision - 你选了哪个方案
• Reason - 为什么（能改变答案的约束条件）
• Scope - 适用于哪个代码库、服务或环境
• Provenance - 谁或哪个 agent 写的，以及什么时候

"使用 Postgres" 会被忽略或覆盖。

"使用 Postgres 因为我们需要行级锁来处理计费" 才能真正改变下一个 agent 的行为。

用同样的方式存储约定：命名规范、错误处理、"永远不要从 X 调用 Y"、已知的坑。除非你明确标记为决策，否则跳过那些临时头脑风暴。

何时需要共享记忆

本地记忆对于单人工作流是够用的：一台机器、一个开发者、一套工具链。

共享记忆在以下情况下变得有用：

• 不止一个人在同一个代码库上运行 agent
• 你在客户之间跳转，而他们不共享私有存储
• 你需要 agent 被告知内容的审计追踪

"共享"不一定是"别人的云"。对很多团队来说，正确的形态是个人本地优先，加上自己基础设施上的可选团队存储。

一个最小的 MCP 记忆形态

如果你通过 MCP 暴露记忆，保持工具表面小而精。几个任务形态的工具比镜像每个存储 API 要好。

write - 存储一条记忆，包含 decision、reason、scope、tags
search - 通过查询检索（混合词向量的方式效果很好）
recall - 通过 id 或最近记录获取某个 scope 的记忆
forget / supersede - 标记过时条目，让 agent 不再将其视为真理

返回结果时永远要带上 provenance。Agent（和人类）需要知道一条命中是来自上周还是去年，以及是谁写的。

需要设计的失败模式

过时的记忆。 六个月前的决策可能现在已经是错的了。优先用 supersede 而不是静默覆盖，并在 recall 时暴露时间戳。

过度召回。 把二十条记忆塞进每次 prompt 会浪费上下文并让模型困惑。用 top-k 检索并设置相关性阈值；需要的话让 agent 再次查询。

无所有权。 如果任何人都可以写入且没有审核机制，垃圾就会积累。团队存储需要有席位，最好还有高影响约定的轻量审核路径。

把聊天当记忆。 持久化完整 transcript 看起来很完整但效果很差。提取决策；其余留在 session 里。

错误的层级。 把密钥、原始 PII 或完整客户数据放入 agent 记忆是策略 bug，不是功能。除非你有明确的合规故事，否则只保留工程决策和项目约定。

一个简单有效的习惯

当一个 agent（或人类）做出一个长期有效的决定时，在继续之前按这个格式写一行：

Decision: X. Reason: Y. Scope: Z.

这个习惯会持续生效，无论你把笔记存在代码库文件、ticket 还是记忆服务器里。格式比产品重要。

我在做 Palace，一个本地优先的 MCP 记忆层（开源核心），支持可选的在你自己的基础设施上自托管的 Team 模式。详情见 palacememory.com。