TL;DR: 共享上下文是整个团队及其 AI Agent 都可以查询的账户记忆，它必须回答四个问题并附上来源：承诺了什么、决定了什么、有什么风险、下一步是什么。它不是知识库，不是企业搜索，也不是 Agent 记忆。它解决的问题是有量化数据的：42% 的机构知识是个人独有的。它奏效时的成果就像 Aircall 的每位工程师 3 倍的部署数量（5 → 15）。
“共享上下文”不是我们创造的词。从业者们在任何厂商之前就给它起了这个名字。“共享上下文仍然是一个未解决的问题，”一家垂直金融科技公司的创始 FDE 告诉我们，他很惊讶在 2026 年仍然无法把自己的会议记录和工作笔记交给一位同事。一家垂直 AI 创业公司的 FDE 把他的团队正在构建的内部工具描述为面向所有人的“共享上下文仓库”。而 Claude Code 仓库上的一个公开功能请求则要求提供“一个共享层”，让项目记忆和技能触达团队工作的每一个界面。
当用户们不约而同地说出同一个缺失的东西时，它值得一个精确的定义。本页给出这个定义、检验它的四个问题，以及它常被混淆的类别。
问题的一面——随着团队成长，个人 AI 配置会失效——在面向 FDE 团队的共享上下文问题中讨论。本页只讲定义。
共享上下文的定义
共享上下文是整个团队及其 AI Agent 都可以查询的账户记忆，它回答四个问题并附上来源：承诺了什么、决定了什么、有什么风险、下一步是什么。
这句话中的每个短语都有其作用。“账户的记忆”指的是关于某一次客户合作的事实，而不是公司文档，后者按不同的节奏更新。“整个团队及其 AI Agent”意味着 FDE、第二位工程师、经理和销售得到相同的答案，编码 Agent 在会话进行中也一样。“查询”意味着你提问就能得到答案，而不是浏览后碰运气。“附上来源”意味着每个事实都能追溯到它所来自的通话、邮件线程或会话，让持怀疑态度的读者能在几秒钟内核实。
团队把“团队记忆”当作同义词使用，存储它的载体通常被称为项目大脑。得出 42% 这一数字的同一项 2018 年研究发现，知识工作者每周浪费 5.3 小时等待或重新创建同事已经拥有的知识。共享上下文就是让这种等待变得不必要的层。
共享上下文必须回答的四个问题
当账户上的任何人——无论是人还是 Agent——无需询问他人就能获得这四个问题的有来源的答案时，这个信息存储才算得上共享上下文。
承诺了什么
对客户做出的承诺：范围、日期、集成行为、每一步由谁负责。承诺是最可能只存在于某一个人脑子里的信息，因为它们通常是在电话中口头做出、在交谈中顺带确认的。当两个人给客户两个不同版本时，承诺也是代价最高的信息。
已决定的事项
决策及其原因。为什么这个客户用的是 webhooks 而不是轮询，为什么切换时间变了，为什么这个变通方案是有意为之。这些决策越来越多地发生在 AI 编程会话中，而在这里，原因比结果更重要，因为工程师和他们的编程 Agent 需要知道“为什么”才能避免把它拆掉。
存在哪些风险
延期的日期、不再成立的假设、客户只告诉了某个人的范围变更。在 Tandem 的客户大脑中，这个问题有专门的机制：风险检查会返回一份风险列表，每条风险都附带解释、原因，以及背后的来源和引文。Agent 针对风险提出的任何行动，都会先交由人工审批。
接下来做什么
该客户账户的下一步行动，按负责人划分。这是状态会议存在的意义所在要回答的问题，也是共享记忆无需开会就能回答的问题。
共享上下文不是什么
有三类相邻的产品常被当作这个问题的答案来推销。它们各自擅长不同的工作。
它不是知识库
知识库存放的是关于你的产品和流程的精选文档。它回答的是“我们的 API 如何处理重试”，而不是“我们在三月前向这个客户承诺了什么”。客户账户信息每周都在变化，而文档写完就不会再更新。
它不是企业搜索
企业搜索检索的是已写下的内容，无论写在哪里，并按相关性排序。这确实有用，但仍是另一项工作：搜索无法调和两条相互矛盾的状态更新，也无法回答从未被写成文档的内容。我们在企业搜索不是项目大脑中给出了更详细的论证。
它不是 Agent 记忆
Agent 记忆类产品对自身定位的描述很精确。Mem0 是“面向 AI Agent 和应用的即插即用记忆基础设施”，Supermemory 是“AI Agent 的记忆层”。它们以开发者基础设施的形式，存储单个 Agent 对单个用户的记忆，包括偏好和历史记录。这是真实的需求，它们也服务得很好。但这是另一个维度：Agent 记忆深化的是单个 Agent 与单个用户的关系，而共享上下文则横跨一个客户账户中的多个人和多个 Agent。完整对比见 agent memory vs team memory。
下面用表格呈现同样的区别，从大多数团队如今实际使用的工具开始。
- 电子表格 + Slack。存储内容：状态单元格和零散的对话线程。谁在查询：任何愿意翻聊天记录的人。能否回答“我们向这个客户承诺了什么？”：有时能，但时效性因团队而异。
- 知识库。它存放什么：经过整理的产品和流程文档。谁在查询：团队。能否回答“我们对这个客户承诺了什么？”：很少，账户变化的速度比文档快。
- 企业搜索。它存放什么：已写内容的索引。谁在查询：任何有权限的人。能否回答“我们对这个客户承诺了什么？”：只有当有人把它写成文档时才行。
- Agent 记忆（Mem0、Zep 这类）。它存放什么：一个 Agent 对一个用户的记忆。谁在查询：那个 Agent，通过其开发者的代码。能否回答“我们对这个客户承诺了什么？”：不能，它存储的是偏好和交互历史。
- 共享上下文（项目大脑）。它存放什么：带来源链接的账户事实。谁在查询：团队及其 Agent。能否回答“我们对这个客户承诺了什么？”：能，且附带来源。
共享上下文与上下文工程有什么关系？
上下文工程是相邻的学科，Sourcegraph 将其定义为“刻意设计大语言模型在每次推理调用时看到的内容”。这一表述面向运行单一流水线的平台构建者。共享上下文将同一学科扩展到团队层面：决定每个人和每个 Agent 在询问某个账户时看到什么，而不是某个模型在一条流水线中看到什么。
传输层已经存在。MCP 是一个用于将 AI 应用连接到外部系统的开放标准，其官方文档将其描述为“AI 应用的 USB-C 接口”，并得到 Claude、ChatGPT、VS Code 和 Cursor 的支持。值得记住的区别是：MCP 只负责传输上下文，它本身不记忆任何东西。必须有什么东西充当接口另一端的记忆，而那个东西就是共享上下文层。
共享上下文在实践中是什么样子
当你观察它运作时，这个定义就变得具体了。在 Spendesk，负责客户成功和客户管理的 Mathilde Hamy 这样描述：“一位工程师接手任何账户，五分钟内就知道承诺了什么、有什么风险。没有人需要维护任何东西。”在 Aircall，CPO Tom Chen 把整个定义压缩成一句话：“记忆属于团队，而不是个人。”
你可以在一个下午内测试你的团队是否拥有共享上下文。
- 从账户外部提问。找一位从未参与过该账户通话的同事，问他们“我们承诺了什么？”如果他们能在五分钟内不求助任何人就给出答案，那你就拥有共享上下文。如果他们去找负责人，那你拥有的只是一个人。
- 追溯一个事实到其来源。从你的跟踪工具中任取一条陈述，尝试找到它所来自的通话或讨论串。一个无法追溯的事实，就是在客户面前无法信任的事实。
- 从每个界面提问。 经理应能在 Claude 聊天中获得答案，工程师应能在 Claude Code 中获得答案，团队应能在 Slack 简报中获得答案。Tandem 的 账户大脑 就是这样工作的：可通过 Tandem MCP 查询，通过 AI 聊天界面编辑，简报可按需生成或定时发送，并可交付到包括 Slack 在内的任何地方。
- 让两个人在同一天写入。 共享上下文从定义上就是多人协作的。多人向同一个大脑推送内容，提醒接收者可自行配置。
- 询问本周有什么变化。 无法区分当前信息与已被取代信息的记忆还算不上共享上下文，那只是个存档。
哪些仍需人工完成
该定义承诺的是一个可查询的记忆，而不是一个自动运行的记忆，这个边界很重要。
由人来决定什么值得保留。将 Claude Code 会话同步到团队记忆是一个需要你触发的操作，由你选择推送什么内容。错误的事实需要人来纠正，聊天界面让这一过程变快，但并不会使其自动化。当客户在未告知你的情况下改变主意时，在有人或某个已连接的数据源发现之前，任何记忆层都不会知晓。
判断同样由人来完成。拥有相同上下文的两位队友仍可能对同一情况有不同解读，而共享上下文有意只传递事实，不传递决策。此外，Tandem Agent 提出的每一项操作在触达客户之前都必须经过人工审批。
从四个问题开始
这个定义足够简洁，今天就可以使用：账户的记忆，可供整个团队及其 Agent 查询，能够回答承诺了什么、决定了什么、有什么风险、下一步是什么，并附有来源。用这四个问题检验你当前的设置，一小时内你就会知道自己拥有的是共享上下文，还是一堆个人上下文。
如果答案是一堆个人上下文，请在演示中观看 Tandem 为你的一个实际实施项目标记风险，并针对你自己的账户回答这四个问题。
常见问题
共享上下文与单一事实来源是一回事吗？
两者相关，但共享上下文是更严格的检验标准。实施的单一事实来源 规定了事实应存放在哪里。共享上下文则增加了该来源必须回答的内容（四个问题），要求每条事实都有来源，并且要求 AI Agent 也能查询它，而不仅仅是人。
共享上下文与项目大脑有何不同？
共享上下文是一种能力，项目大脑是提供这种能力的载体。如果这个大脑能为团队中的每个人回答四个问题并附上来源，你就拥有了共享上下文。Tandem 的账户大脑是一个项目大脑，再加上风险检测、需人工审批的 Tandem Agent，以及一个客户工作区。
谁来维护共享上下文？
在像 Tandem 这样的产品中，来自通话、Slack、工单和编码会话的同步承担了大部分工作，编辑则通过聊天界面完成。Spendesk 的总结是“没有人需要维护任何东西”。而在自建系统中，维护就成了一项真正的工作：据我们观察，一个普通的“大脑”（Obsidian 之类）会在 500 到 1,000 条事实之间逐渐失准。
在客户面前，我能信任 AI 生成的客户账户状态吗？
要像信任同事的总结那样信任它：可验证，而非盲信。每个答案都附带其来源，因此你可以在通话前核查底层的原始引述。涉及客户的操作需经过人工审批。
AI Agent 是否让共享上下文变得必要？
它们提高了没有共享上下文的代价。Agent 会基于它所获得的任何上下文行事，因此没有共享层的团队，每个知情人只能拥有一个信息充分的 Agent，而其他地方的 Agent 则会自信满满地出错。请参阅为什么编码 Agent 需要 FDE 的上下文了解这一论点在工程领域的版本。
哪些工具提供共享上下文？
大多数以此为卖点的工具提供的其实是相邻的能力，这正是定义之所以重要的原因。我们在面向 FDE 和实施团队的共享上下文工具中诚实地比较了七种方案，包括每种方案在什么情况下才是正确选择。
关键术语
更多定义请参见客户入职术语表。
共享上下文： 整个团队及其 AI Agent 都可以查询的账户记忆，回答承诺了什么、决定了什么、有什么风险、下一步是什么，并附带来源。
团队记忆： 共享上下文的同义词，强调这份记忆属于团队而非任何单个成员。
项目大脑： 存储共享上下文的类别产物，一个持续维护、来源关联的账户事实存储库。
账户大脑： Tandem 的产品组成部分，即项目大脑加上风险检测、Tandem Agent（人工审批的操作）以及一个客户工作区。
前沿部署工程师（FDE）： 前沿部署工程师是指大约一半时间与客户在一起理解问题、另一半时间针对该特定客户构建解决方案的工程师。
来源关联事实： 一条带有指向其出处（通话、讨论串或会话）指针的存储声明，任何人无需询问记录者即可验证它。
Agent 记忆： 存储单个 AI Agent 对单个用户的记忆（如偏好和交互历史）的开发者基础设施。适用于个性化，与团队层面的账户记忆不同。
上下文工程： 刻意设计语言模型在每次调用时所见内容的实践。共享上下文将同样的规范应用于整个团队及其 Agent，而非单一管道。