当你的 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.
这是真正的护城河。不是技术（可复制），是积累的公司特定理解（不可复制）。