不靠共享记忆，也能共享上下文

最近，我在探索一个很简单的协同问题：两组人正在共同计划一件事，但双方都希望保留各自独立的 AI 对话。

我们有充分理由不把所有内容塞进同一个聊天窗口。每段对话里都有各自的私密细节、尚未成形的偏好和局部决定。与此同时，双方又需要对共同计划保持一致理解。如果一边的对话认为某个决定已经敲定，另一边却仍把它当作待定事项，那么 AI 助手制造的混乱可能比消除的更多。

最直觉的方案是共享记忆：让两个助手记住同样的事情。

但我认为，这个心智模型错了。

两段对话不需要共享同一个大脑。它们需要读取同一份契约。

这份契约是一份小而明确、带版本号的 Context Pack（上下文包）：它经过刻意整理，只包含双方都被允许使用的信息。两段对话仍然彼此独立，Context Pack 则承载双方共同依赖的状态。

这个区别听起来很细微，却会彻底改变系统的设计方式。

两段对话，一个协同问题

想象两个家庭正在一起计划一次旅行。每个家庭都有自己独立的 ChatGPT 对话。第一段对话可能知道一方的日程、限制和偏好，第二段对话则知道另一组信息。有些细节对双方都有用，另一些则应该继续保密。

两个助手都需要回答这些问题：

• 哪些事情已经确认？
• 哪些还只是提案？
• 哪些问题仍然需要人来决定？
• 哪些细节只属于其中一方，不应该越过边界？
• 自上次对话以来，是否发生了变化？

如果要求助手从两段漫长的聊天历史中自行推断答案，系统会立刻变得脆弱。对话天然充满模糊性。人们会脑暴、撤回、缓和语气，也会前后矛盾。上午十点看起来像决定的一句话，中午可能就已经失效。

更重要的是，任何一段对话都没有权利读取另一段对话的私有历史。

所以，真正的协同问题不是“怎样同步两份聊天记录”，而是：

两段对话可以共同依赖的最小共享状态是什么？谁有权改变它？

这个问题要容易处理得多。

共享记忆给出了错误的承诺

“共享记忆”这个说法暗示了一种连续的内部体验。它让人误以为，两个助手会自动知道对方知道的事情。

真正的协同不需要这么神奇的解释。它需要更明确的机制。

AI 对话可能检索到错误的记忆，也可能把一句试探性的表达总结成稳定偏好，或者把一个只适用于旧场景的决定带到新的上下文里。即使检索完全正确，用户也未必看得见究竟是哪段记忆正在影响答案。

对于低风险的便利功能，这或许可以接受。但它不适合作为共同承诺的基础。

Context Pack 给出的承诺更小。它只说：

在这项协同任务中，截至当前版本，这些是双方可以共同使用的事实、提案、问题和边界。

Context Pack 不声称代表任何一方知道的全部信息，不合并身份，也不暴露完整对话。它只创造一个范围狭窄、定义清楚的共享界面。

这个共享界面可以被检查，可以和上一版比较，也可以通过修改显式产物来纠正，而不必操纵看不见的模型状态。最重要的是，每个人都能确认两个助手是否从同一份材料出发。

Context Pack 的四类状态

最有价值的设计决定，是不再把每句话都当成同一种真相。

Context Pack 把共享信息分成四类。

Agreed：已确认

这是相关人员已经批准的决定。助手在回答问题或检查冲突时，可以把它们当作可靠依据。

例如，已经确认的日期范围、共同目标或无障碍要求。“已确认”并不意味着永远不变，它只表示：在当前版本里，这项决定有效，直到有人明确修改它。

Proposed：待讨论

这是某一方希望大家考虑的候选变更或选项。双方都可以看到，但助手不能把它描述成已经敲定的事实。

这个分类很重要，因为 AI 很擅长把听起来合理的建议说得像必然选择。一个明确可见的 Proposed 状态，能够保留“我们可以这么做”和“我们已经决定这么做”之间的差别。

Open：待决

这是仍然需要解决的问题。它们可以有负责人、截止时间或决策标准。

Open 并不意味着 Context Pack 不完整。它本身就是有价值的状态。它明确告诉两个助手，不确定性究竟在哪里，而不是鼓励它们用一个自信的猜测把空白填满。

Private：私有边界

这里共享的是边界，而不是私密信息本身。Context Pack 可以说明哪些类别的信息必须留在各自的对话里，但不应该包含这些私密信息。

例如：个人账户信息继续保密；个人偏好只有在本人明确将其纳入后，才能成为共享状态；一方的内部讨论不能被当成双方已经达成共识的证据。

这个类别阻止 Context Pack 变成一堆披着“共享”外衣的数据。

版本号比感觉更可靠

每一份 Context Pack 都需要一个版本标识。

在实验中，两段对话收到了同一个初始版本。这样我们就可以做一个基本的一致性检查：分别询问两个助手，哪些已经确认，哪些仍是提案，哪些问题尚未解决，以及哪些内容不允许披露。

有价值的结果并不是两个助手使用了完全相同的措辞。它们不需要这样做。真正有价值的是，它们的回答与同一份 Context Pack 保持一致。

版本机制也给出了清晰的更新规则。如果其中一段对话产生了一个合理的变更，这项变更不会悄悄流入另一段对话。它首先成为一项提案，由人来审阅；只有审阅通过后，新版本才能替换旧版本。

状态变化是这样的：

对话提出变更 → 记录为提案 → 人工审阅 → 发布新的 Context Pack 修订版 → 两段对话接收新版本

这比假装每条消息都会即时同步更慢，却也更容易理解和控制。

如果两个助手的回答不一致，先检查版本。如果旧决定再次出现，就检查 Context Pack。如果私密细节越过边界，就把这次违规和明确规则进行比较。显式产物给了整个协同系统一个可以落脚、可以核对的具体依据。

这项实验证明了什么，又没有证明什么

我想尽量准确地说明证据，因为小规模 AI 实验很容易被夸大。

这项实验表明：当两个独立对话拿到同一份带版本号的 Context Pack 时，它们可以对一组事先定义的协同问题给出一致回答。实验也表明，Agreed、Proposed、Open 和 Private 之间的分类边界足够清楚，可以指导助手回答问题。

这是机制层面的证据。它说明，这种模式在受控条件下可以工作。

但它没有证明所有未来对话都会遵守边界，没有证明几个月的持续修订之后 Context Pack 依然容易理解，也没有证明这个流程适合处理敏感信息。它更没有消除生产系统对身份验证、访问控制、日志、撤销机制和真实用户测试的需要。

它同样没有证明两个助手“理解了彼此”。它们并没有直接沟通。之所以能协同，是因为人给了它们同一份经过审阅的状态。

我认为这反而是一个优点。

拟人化的解释会让系统显得连贯，却把真实机制藏起来。Context Pack 模式让机制保持可见：独立对话、共同产物、由人控制的状态写入。

审阅，就是写入路径

最重要的规则是：任何一段对话都不能单方面改写双方共同依赖的状态。

助手可以读取 Context Pack，可以识别冲突、起草提案，也可以解释接受提案可能带来的影响。但只有通过审阅，一项会产生实际后果的变更才能进入共享状态。

这里有一个简单的分工：

AI 负责读取和提议，人负责批准并正式写入。

人的职责不是永远手工复制每一句话。审阅流程可以做得很轻：展示变更对比（diff）、指出受影响的决定、说明谁需要批准，并在接受后发布下一版本。

关键在于，写入路径必须始终清晰可见。

没有这条规则，一段对话可能会把局部偏好转化成共同决定。模型也可能因为某个建议听起来合理，就把它当成事实继续传递。另一方之后才遇到这项变化，却不知道它从哪里来。

只有经过明确审阅和写入，变更才会进入共享状态。这样，整条责任链就不会丢失：谁提出了变更、它会改变什么、谁接受了它，以及它从哪个修订版开始生效，都清清楚楚。

一个最小模板

这个模式不需要复杂平台。一份共享文档就足以开始早期实验。

下面是一个最小结构：

# Context Pack：[共同事项]

版本：r1
更新日期：YYYY-MM-DD
用途：[范围明确的协同任务]

## Agreed（已确认）
- [决定]
- [决定]

## Proposed（待讨论）
- [提案] — 由[某一方]提出，等待[审阅人]确认

## Open（待决）
- [问题] — 负责人：[姓名]，决定日期：[日期]

## Privacy boundaries（隐私边界）
- [信息类别]保留在本地对话中
- 不要从私有对话推断双方已经达成共识

## Change rule（变更规则）
- 助手可以提出修改建议。
- 只有经过人工审阅，才能发布新的修订版。

把同一个修订版交给两段对话，然后做一组小型一致性测试：

1. 分别让两个助手列出已经确认的决定。
2. 询问哪些事项仍是提案，而不是承诺。
3. 询问还有哪些问题没有解决。
4. 询问哪些信息不允许推断或披露。
5. 在其中一段对话中加入一个候选变更，确认它在人工审阅前始终只是提案。

目标不是让两个助手使用一模一样的措辞。目标是让它们拥有一致的状态，并遵守一致的边界。

它确实有成本

Context Pack 模式也有代价。

它增加了人工摩擦。 必须有人整理并审阅共享状态。对于随意的协同任务，这套流程可能显得过重。

它可能过期。 版本号只能告诉你手里拿的是哪一版，不能保证它仍然反映现实。重要的 Context Pack 需要负责人、更新触发条件和过期规则。

它可能重新长成聊天记录。 如果每一次讨论都被复制进产物，Context Pack 就会失去价值。它应该保存当前的协同状态，而不是记录每个人曾经如何看待这些问题。

它本身不提供安全保障。 写得很好的隐私边界并不等于访问控制。敏感场景仍然需要真实的身份、授权、审计和删除机制。

它依赖判断力。 必须有人决定什么应该进入 Agreed，什么仍然属于 Proposed，以及旧决定什么时候应该被移除。Context Pack 让这些判断变得可见，但不会替你自动完成判断。

正因为存在这些成本，我只会有选择地使用这个模式。共同承诺的后果越大，显式状态的价值就越高；任务越随意、越容易撤销，普通对话就越可能已经足够。

共享上下文，不是共享心智

AI 产品经常通过积累更多对话来获得连续性。更多历史似乎意味着更多理解。有时确实如此。但人与人之间的协同需要的不只是回忆。

它需要区分私有信息和共享信息，需要区分一个想法和一个决定，需要有办法看见发生了什么变化，也需要有人掌握写入路径的控制权。

Context Pack 是一种刻意克制的设计。它不试图让两个助手合并成同一种智能，而是为一项具体工作，给彼此独立的助手提供一份共同、可检查的契约。

正是这种克制，让这个模式变得有用。

当我思考能够长期运行的 AI 系统时，总会回到同样的分工：

• 对话，是可能性出现的地方。
• 记忆，帮助我们找回相关历史。
• 产物，保存经过审阅的状态。
• 人，决定什么可以被正式纳入。

两段 AI 对话不需要共享记忆，也能保持协同。它们需要的是同一版本、经过授权的共同事实，以及一条明确的规则：谁有权改变这些事实。