今天告诉一个 Agent 的偏好，明天换个工具又要重说一遍；项目背景散在几段聊天里，新的助手只看到其中一半。这是很多人使用多个 AI 时真实遇到的麻烦。
Notion 本周提出让多个 Agent 共用记忆与 Skills，并在团队案例文章中介绍通过 MCP 把知识和工作方式集中保存的做法。
共享上下文很方便，也会让一个旧问题变得更重要：一条信息被所有工具反复引用以后，谁来判断它还对不对？
保存下来 不代表值得长期相信
聊天里的话有不同性质。有些是稳定偏好，有些只是本次任务的临时安排；有些是已经确认的结果，有些是模型为了推进工作提出的猜测。若它们都被写进同一份“记忆”，后来的工具很难知道区别。
设想一个求职准备案例。学生周一说想重点看英国，周三开始比较新加坡。Agent 若把前一句保存成“只考虑英国”，后续推荐就可能不断排除本来应该讨论的机会。
问题不只是记忆不够长，而是把临时倾向升级成了长期限制。记忆越容易复用，这种误解越可能扩散。
因此，设计共享记忆时，可以先规定哪些信息值得保存。一次性的任务参数未必需要进入长期背景；推测出来的个人偏好，更应当在采用前与本人确认。这里是工作流设计建议，并不表示产品会自动替用户完成这些判断。
一条记忆至少要能回答它从哪里来
给内容加上来源与状态，会让后续使用更清楚。是谁提供的信息，针对哪个项目，什么时候确认过，是否已经被新的决定覆盖？这些字段看起来普通，却关系到 Agent 能否正确解释上下文。
以团队项目为例，“客户喜欢蓝色”与“本次活动使用蓝色版本”不是同一条要求。前者像长期偏好，后者是特定版本的决定。若只保存一句压缩摘要，下一个人可能把活动设计延用到所有材料。
学生可以为一个模拟协作项目做一份记忆台账，保留原始表达、适用范围、确认者与更新时间。再设计几条容易混淆的信息，检查它们能否被分开使用。
练习的目标不是证明模型永远记不错，而是让一条错误有机会被追溯和纠正。不能找到来源的结论，就不该轻易成为下一轮自动执行的依据。
多个 Agent 同时写入 冲突该怎样处理
共享记忆的另一个难点，是多人或多工具会更新同一段背景。一个助手记录方案甲，另一个根据较新的讨论改成方案乙。最后保存下来的文字，不一定能反映实际决定。
可以把“提出更新”和“正式采用”分成两步。涉及目标、预算或对外承诺的变化，先形成可检查的修改，再由对应负责人确认。低影响的整理工作，则可以采用更轻的规则。
这里没有一套适用于所有团队的审批数量。重要的是决定与影响相匹配：修改一段草稿标签，与改变项目的交付日期，不应被当成同类操作。
作品集可以展示一次冲突处理：两条来源都看似合理，但时间和范围不同，你为什么保留其中一条，又怎样让另一条不再被误用。这比展示“接入了多个 AI”更能解释系统价值。
共享的知识 不必共享给所有人
一个团队的公共工作背景、个人求职记录和客户材料，未必应该放在同一个可访问范围。把连接配置好，只说明工具能够触达某些内容，并没有回答它是否应该在当前任务中使用。
做教学项目，可以用合成资料把三类内容分开：公开说明、团队内部记录、个人私有材料。再检查不同任务得到的上下文是否符合预期。不要用真实隐私数据来证明系统的权限设计。
还应考虑信息怎样被转述。一个 Agent 没有直接读取原始材料，却可能从另一段共享摘要得到同样内容。权限检查若只盯着文件入口，就可能遗漏后续传播。
对非技术候选人，这同样是可以参与的工作。整理信息分类、责任人和使用范围，能帮助工程团队把权限设计得更符合实际流程。
用一次偏好变更检查共享记忆
可以用合成资料安排一个小实验：最初记录“本次材料优先考虑英国”，完成一次整理后，再明确改成“开始同时比较英国与新加坡”。检查新任务是否仍被旧记录限制。
不要只看原条目是否改了。还要观察以前生成的摘要、待办和推荐里，有没有把旧条件继续当作事实。若没有能力检查全部派生材料，就交代哪些位置已经核对，哪些仍未知。
再让另一位使用者读记录，判断这次变化是永久偏好、阶段计划，还是只适用于一份材料。若不同读者理解不同，先改信息结构，不急着给系统增加更多记忆容量。
这个练习可以完全使用虚构人物和计划。它不需要真实申请资料，也不要求接入所有工具。最终交付是一份信息更新过程，以及你实际观察到的错误与修正。
删除和纠正 也要成为正常工作
共享记忆最有价值的时刻，可能不是成功记住，而是用户改变了想法之后，系统能跟着改变。需要知道旧记录是否还会被搜到，已有摘要有没有继续传播，以及后续任务是否确实采用了新版本。
可以给练习项目安排一个小测试：先保存一个模拟偏好，完成一轮任务，再明确撤回它。然后换一个 Agent、换一种问法，检查旧信息是否仍然影响结果。若只能删除原文，却无法确认派生内容的状态，就应当把这个限制写清楚。
这种练习连接了知识管理、产品运营和 Agent 工程。它不要求候选人自己训练模型，却需要理解真实用户怎样修改决定，以及团队怎样保持信息一致。
对求职者而言，一个有解释力的成果可以是一张信息生命周期图，配合实际做过的冲突与撤回检查。图上每一步都对应行为，而不是只画几个互相连接的工具图标。
多个 Agent 共享一个“大脑”，真正需要共同维护的是一套有来源、能更新、可以纠错的工作记录。记得更多只是开始，知道什么应该被忘记，也是一项能力。
也要准备一条不该被长期记住的信息。例如，用户只想让本次讨论更简短，并不等于今后所有项目都要删减细节。检查系统有没有把临时安排写成稳定偏好，可以帮助发现摘要压缩过程中的另一类误解。
读者常问
把聊天全部存起来 会不会更可靠
不一定。保存更多内容也可能增加冲突与过时信息。应先区分稳定背景、临时要求和未经确认的推断，再决定保存方式。检索得到一段旧话，并不代表它适合成为当前任务的约束。
非技术背景可以做共享记忆项目吗
可以从来源整理、信息分类和更新流程入手，明确谁确认、谁维护、什么时候失效。若涉及系统实现，再与工程能力结合。不要把设计了一套台账，写成已经解决全部权限与同步问题。
删除一条记忆后 还需要检查什么
需要结合实际系统查看旧内容是否仍存在于摘要、其他页面或后续任务中。删除原文与消除所有影响不是一个状态。如果只能确认部分位置，应如实说明，避免给用户超出证据的承诺。
- 提出让多个 Agent 共用记忆与 Skills· X / 原始帖文
- 团队案例文章· www.notion.com
结合目标岗位，梳理已有经历、本人贡献和可核查的项目成果，讨论下一步准备重点。