要回答一些关于你们公司的棘手问题，例如： “关于 X 什么是真的、从什么时候开始、依据谁的说法，以及各个账号之间在哪里存在分歧？” 你需要的是一种派生的、可引用的事实层，置于所有沟通与文档之上 它是“公司或组织所知道的内容”的系统化记录，这与包含已完成工作产出结果的系统化记录是不同的 会计里的 Jack 知道为什么供应商发票被支付了，但这份发票并不符合采购订单（PO），而会计系统里只是包含数据要素——PO 和付款 所以如果你想知道“为什么我们支付的金额与 PO 上的不一致”，你就得去问 Jack 除非你有一个共享上下文层，它能连到 Slack 和邮件线程，并显示 Jack 已与业务经理确认：订单已被更改且付款已获批准 要让共享上下文层真正有用，它必须以证据为基础，能够暴露矛盾，并用新信息覆盖旧的定论 它必须回答： - 这是谁？会计里的 Jack，而不是工程部门的 Jack - 当前状态是什么？PO 与发票不匹配，且在问题解决前无法支付 - 各个账号在哪里存在分歧？最初的 PO 是由 Jane 在邮件中批准的，但变更单是由 Bob 在 Slack 中提出的 - 发生了什么变化？Bob 需要增加席位数量，以纳入一个额外的群组 基于检索的系统在这些问题上并不可靠：它们擅长查找文本，但在处理诸如“这张发票为什么会在不匹配 PO 的情况下被支付？”这类需要判断原因的主张时就不太擅长了 要让共享上下文层正常运作，其架构需要考虑： 1. 证据——原始数据，且来源明确 2. 事实——公司内部的实体与主张 3. 判断——基于证据与事实的推理 4. 访问——哪些证据与事实可以被 AI 推理利用 当然，这是一种简化的拆解，因为构建一个可靠的共享上下文层可能会相当复杂；但如果你把它做对了，它就会成为工作流自动化的基础 会计里的 Jack 不需要去追踪 Jane 和 Bob 来判断这张发票是否应当支付——一个代理可以做到，而 Jack 可以专注于更具战略性的工作，比如规划与分析 重点是：如果你想自动化工作流，并在试点之外部署代理，你需要先把精力放在共享上下文层上，让代理拥有可靠的信息来执行行动
我们来聊聊共享上下文层，通常也被称为“公司大脑”
要回答一些关于你们公司的棘手问题，例如：
“关于 X 什么是真的、从什么时候开始、依据谁的说法，以及各个账号之间在哪里存在分歧？”
你需要的是一种派生的、可引用的事实层，置于所有沟通与文档之上
它是“公司或组织所知道的内容”的系统化记录，这与包含已完成工作产出结果的系统化记录是不同的
会计里的 Jack 知道为什么供应商发票被支付了，但这份发票并不符合采购订单（PO），而会计系统里只是包含数据要素——PO 和付款
所以如果你想知道“为什么我们支付的金额与 PO 上的不一致”，你就得去问 Jack
除非你有一个共享上下文层，它能连到 Slack 和邮件线程，并显示 Jack 已与业务经理确认：订单已被更改且付款已获批准
要让共享上下文层真正有用，它必须以证据为基础，能够暴露矛盾，并用新信息覆盖旧的定论
它必须回答：
- 这是谁？会计里的 Jack，而不是工程部门的 Jack
- 当前状态是什么？PO 与发票不匹配，且在问题解决前无法支付
- 各个账号在哪里存在分歧？最初的 PO 是由 Jane 在邮件中批准的，但变更单是由 Bob 在 Slack 中提出的
- 发生了什么变化？Bob 需要增加席位数量，以纳入一个额外的群组
基于检索的系统在这些问题上并不可靠：它们擅长查找文本，但在处理诸如“这张发票为什么会在不匹配 PO 的情况下被支付？”这类需要判断原因的主张时就不太擅长了
要让共享上下文层正常运作，其架构需要考虑：
1. 证据——原始数据，且来源明确
2. 事实——公司内部的实体与主张
3. 判断——基于证据与事实的推理
4. 访问——哪些证据与事实可以被 AI 推理利用
当然，这是一种简化的拆解，因为构建一个可靠的共享上下文层可能会相当复杂；但如果你把它做对了，它就会成为工作流自动化的基础
会计里的 Jack 不需要去追踪 Jane 和 Bob 来判断这张发票是否应当支付——一个代理可以做到，而 Jack 可以专注于更具战略性的工作，比如规划与分析
重点是：如果你想自动化工作流，并在试点之外部署代理，你需要先把精力放在共享上下文层上，让代理拥有可靠的信息来执行行动