当你的 Agent 连接了 Slack、Google Drive、CRM，你问它"谁负责这个客户关系"，它返回的是 Gmail 里找到的最新邮件线程中出现的名字。从另一个工具问同样的问题，得到不同的名字。再问"本季度核心优先级是什么"，它从找到的第一个战略文档里取答案——哪怕那份文档是六个月前的，中间已经 pivoted 三次了。
这不是信息找不到的问题。这是信息太多、无法判断哪个是最新的、无法解决来源冲突、 confidently 把碎片当成完整真相的问题。
Conor（contextconor）在 X 上发布了这篇关于公司级 Agent 上下文架构的长文，是当天 Agent 领域最有深度的分享之一。
#行业把问题框架设错了
现在的行业框架是检索 ：
如何在正确的时间把正确的信息传递给 agent？
RAG pipelines、vector databases、semantic search、MCP servers——都是 retrieval 基础设施。本质都是同一件事：agent 需要什么的时候，去找。
检索是一场 scavenger hunt。每次 agent 需要 context，都从零开始搜索。没有先前的理解，没有积累的知识，没有"上次看之后发生了什么"的概念。每次都从零开始。
想象每天早上雇一个新人，给他所有系统的完整权限，让他在午饭前做决定。他能找到东西。有一半会 confidently wrong。下午你花在纠正他的时间比省下的还多。
#替代方案：合成理解（Synthesized Understanding）
不是搜索，是提前建模 。
Retrieval 说：有人问的时候找答案。 Synthesized Understanding 说：维护一个持续更新的现实表征，让答案在任何问题被问之前就已经存在。
Retrieval 给你碎片。Synthesis 给你世界观。
这听起来像文字游戏。实际上它改变了一切。
#合成大脑需要解决五个行业还没认真处理的问题
1. 数据矛盾 Slack 说项目 deadline 是周五。Linear 说是下周三。上次会议记录里 PM 说"月底"。检索系统返回它先找到的那个。理解系统解决冲突，确定哪个来源最权威，给出一个带推理过程的单一答案。
2. 身份统一 Lisa.Chen@acme.com（邮件）、@lisa.chen（Slack）、"Lisa Chen"（CRM）、"Lisa from Acme"（会议记录）、"L. Chen"（日历邀请）。对检索系统来说，这是五个不相关的文本字符串。对理解系统来说，这是同一个人，她说的所有内容在每个渠道里统一归到同一身份下。
3. 信息衰减 1 月的战略文档已经过时。团队页面自上次重组后没更新过。wiki 里的项目状态两个 sprint 前是准确的。检索系统把六个月前的文档和十分钟前发的消息以同等置信度处理。理解系统追踪每个信息上次被确认的时间，知道哪些可能已经 stale。
4. 来源权威层级 CEO 的邮件说一件事，随机的 Slack 讨论串说另一件，CEO 的邮件赢。签了的合同说一件事，CRM 字段说另一件，合同赢。理解系统需要一个来源权威层级。检索系统对这个概念完全没有。
5. 跨来源综合 没有人写过一份文档说"基础设施迁移面临风险，因为 lead engineer 下周不在，对支付团队的依赖问题未解决，原始时间线假设我们会在现在之前让新 hire 入职"。这种理解只有在综合项目追踪、日历、招聘 pipeline 和上周 standup 笔记时才会出现。
#文件系统是交付机制，也是架构选择
当构建了上下文图谱——合成的、冲突解决的、来源追踪的——如何把它交给 agent？
答案是文件系统 。
每个 agent 都已经知道如何读取文件。Claude Code 从项目目录读。Cursor 从 codebase 读。OpenClaw 从本地文件系统读。文件系统是每个 agent 都已经支持的唯一接口。
把上下文层以文件系统形式暴露，意味着任何 agent——来自任何 vendor、使用任何框架——无需 custom integration 就能读取。磁盘上的文件，结构化的、实时的，agent 启动时读取。
上下文层与任何特定 agent、vendor 或 workflow 解耦。你公司对自身的理解存在于一个地方。每个 agent 都从那里读。切换 agent、添加工具或改变技术栈时，上下文持久存在。
#基准测试的空缺
代码生成有 benchmark。数学推理有 benchmark。长上下文 recall 有 benchmark。工具调用有 benchmark。指令遵循有 benchmark。
没有任何 benchmark 问：给定一家公司跨真实工具的真实数据，这个系统能否准确回答关于这家公司的基本问题？
- 工程团队有谁？
- 活跃项目有哪些？
- 谁负责 Acme 的关系？
- 上周发生了什么变化？
- 基础设施迁移的当前状态是什么？
- 当 Slack 和 CRM 说的不一致时，哪个是对的？
任何有能力的员工几周后都能回答这些问题。今天没有任何 agent 能可靠地回答，因为它们都没有在做合成理解的工作。
行业正在建 benchmark 来测试这件事。Early results are humbling for everyone, including them. 但至少有办法衡量进步了。
#真正的护城河
上下文图谱每天都在变好。第一天只知道一点点。第三十天已经吸收了数千条消息、数百份文档、几十次会议记录。它解决了冲突、建立了身份图谱、追踪了什么变了什么没变。第三十天和第一天的理解质量完全不同。
每个新数据点让现有图谱更有价值。一条新 Slack 消息不只是增加一个事实——它可能确认了项目状态、更新了关系、揭示了优先级转变、解决了两个旧来源之间的冲突。
这件事没法快进。你没法写一张支票就跳到第六个月。理解必须积累。
等待的代价不是"我们还没有"。是"我们每天都在落后更多"。
今天开始构建的公司，六十天后会有六个月积累的理解——这是多少钱都买不来的。
Not the technology, which can be replicated. The accumulated understanding of your specific company. That's proprietary. That compounds. And it only grows with time.
这是真正的护城河。不是技术（可复制），是积累的公司特定理解（不可复制）。