Company Brain 到底是什么：企业上下文的四层基础设施

Company Brain 首先要让企业知识保持准确

Company Brain 仍处在定义快速变化的阶段。Slite 问受访者如何理解它，53% 选择“持续更新的知识库”，18% 选择“由团队活动自动维护的 Wiki”，13% 选择“跨工具的 AI 搜索”，12% 选择“Agent 的记忆层”，另有 4% 不知道。

来源原图 · Slite Company Brain Survey 2026样本：149 名受访者；公开页面未披露调查方法

Slite 把前两项合并，得到“71% 的团队首先期待知识保持准确”。这个合并有编辑判断成分，但它抓住了材料的核心：Company Brain 的第一任务是让组织知识变得可依赖，Agent 只是把这一要求推到更高风险的执行环境里。 如果一套系统只能从多处搜到答案，却不能说明答案来自哪里、何时更新、谁有权修改，它仍然只是搜索层。

这本书追溯了几个相邻概念：个人“第二大脑”、用实体关系组织业务语境的 Context Graph、由模型生成和更新的 Wiki、开源 GBrain，以及 YC 在创业方向中提出的 Company Brain。YC 的公开定义尤其清楚：它位于原始企业数据与可靠 AI 自动化之间，负责提取、组织、更新知识，并让 Agent 能调用这套上下文。

把这些说法收束起来，可以得到一个不依赖厂商的工作定义：

Company Brain 是组织级上下文基础设施。它持续吸收工作信号，把信号整理为可追溯的共享记忆，处理过期、冲突和权限，再向人或 Agent 提供答案与可执行上下文。

这个定义比“AI 知识库”多了两个硬条件：维护闭环和机器调用。也比“Agent Memory”更宽，因为它保存的是组织真相，而非某个 Agent 的对话历史。

知识分散不会消失，Agent 会把旧文档的代价放大

传统知识管理总爱承诺“单一事实源”，现实却是垂直 SaaS 越多，知识越分散。Slite 的样本中，83% 使用专门知识库，79% 同时使用两个或更多系统，64% 使用共享盘，56% 依赖 Slack 或 Teams，30% 仍依赖邮件。这些比例很可能允许多选，但书中没有公布题目原文。

来源原图 · Slite Company Brain Survey 2026样本：149 名受访者；公开页面未披露调查方法

分散本身不等于失败。CRM 适合保存客户状态，工单系统适合保存问题处理，聊天适合快速协调，设计工具适合保存创意过程。真正的问题是：同一个事实分布在不同速度、不同权限、不同生命周期的系统里，而组织通常没有一层机制持续处理它们的关系。

文档会经历一个熟悉的循环：有人写下规则，团队开始使用；现实变化，页面没有同步；读者逐渐失去信任，于是在聊天或新文档里重新解释。于是知识库越积越厚，可信知识反而越来越难辨认。

人类面对这种混乱，常靠隐性判断补洞。我们会看日期、辨认作者、发现语气不对，或者直接问同事。Agent 没有这种默认的组织常识。它可能把检索排名靠前的旧页面当成权威，用一段缺少地区、客户等级或生效日期的规则去生成报价、回复客户甚至执行后台动作。

来源原图 · Slite Company Brain Survey 2026样本：149 名受访者；公开页面未披露调查方法

同一份坏知识，对人的后果可能是多花十分钟核对；对自动执行系统的后果可能是同时向数百个客户做错事。Company Brain 因而承担着自动化系统的风险控制职责：来源、时间、权限和置信边界必须与答案一起进入执行链。

人先少拼上下文，Agent 才能安全进入后台

Slite 的调查没有显示企业只想服务 Agent。4% 的受访者只想为自己获得答案，34% 想服务自己和团队，54% 想同时服务人和 Agent，只有 7% 只为 Agent。书中把前几类相加后强调，约九成需求仍包含人类使用场景。

来源原图 · Slite Company Brain Survey 2026样本：149 名受访者；公开页面未披露调查方法

对人，Company Brain 减少的是每项任务开头的“上下文拼装税”：新人不用在五个工具里重建项目历史；销售不用追问产品规则；工程师能找到某次架构决定的依据；跨团队协作少依赖“谁还记得”。这类收益并不炫目，却是任何 Agent 自动化的地基。

对 Agent，风险随自主性上升。聊天助手答错时，人还在回路里；编码、客服、销售和内容 Agent 开始制作可交付结果；运营、人力和知识维护 Agent 会修改系统状态；后台环境 Agent 在无人值守时持续行动，对完整上下文、权限边界和异常升级机制的要求最高。

不同 Agent 需要的并非同一份“公司资料”。编码 Agent 需要架构决策、事故记录、内部约定以及当初为什么这样做，否则它可能写出技术上成立、却违反团队全部隐性规则的代码。客服 Agent 需要已知问题、政策边界与语气规范，否则错误答案会被规模化发给客户；销售 Agent 需要定价规则、历史交易和当前定位，否则可能擅自给折扣，继续使用两个季度前的说法。内容 Agent 还必须区分已经发布的功能与路线图，知识维护 Agent 则需要知道哪些事实正在变旧。

后台 Agent 把这些要求叠在一起，而且现场没有人发现异常。Company Brain 因而不能只返回“相关文字”，还要按任务交付正确的知识切片，并保留来源、权限、时间和冲突状态。

来源原图 · Slite Company Brain Survey 2026样本：149 名受访者；公开页面未披露调查方法

这里要警惕样本偏差。Slite 的受访者中，57% 已部署自己的 Agent 或技能文件，其中 25% 自称“agent-native”；另有 23% 主要把 AI 当聊天工具。这样的样本显然比一般企业更接近 Agent 前沿，会放大对机器可调用知识的需求。它能告诉我们早期采用者在担心什么，不能证明所有公司已经到了同一阶段。

四层架构：信号、记忆、修剪、调用

书中最有用的部分，是把各种产品名抽掉后留下四个系统问题。任何 Company Brain，无论用 Markdown、知识库、向量数据库还是知识图谱，都逃不开这条路径。

第一层，获取信号。 信息可以定时从业务系统拉取，可以在事件发生时推送，可以由 Agent 把一次工作总结写入，也可以等到查询时再实时读取。定时同步覆盖面稳定，但会滞后；事件捕获新鲜，却容易产生噪声；查询时读取最及时，却受外部接口速度、权限和限流约束。

第二层，形成记忆。 纯文件透明、可版本控制；文档知识库对人友好；向量索引擅长语义相似；知识图谱擅长实体关系和时间变化。没有一种存储天然等于“公司真相”。选型决定系统能回答哪类问题，也决定权限继承、迁移和维护难度。

第三层，整理与修剪。 这是大多数“接上 RAG 就完成”方案缺失的一层。常见机制包括定期合并、时间衰减、漂移检测、冲突标记和人工审阅队列。它持续判断什么仍然有效、什么已经被替代、什么必须由责任人确认。

第四层，调用。 人需要聊天、搜索、引用和可读的解释；Agent 需要稳定的 API、MCP 或专用工具，还需要在权限不足、来源冲突或置信不足时停止。一个答案能被找到，不代表它适合被执行。

四层之间没有“完成一次就结束”的箭头。调用结果会暴露知识缺口，缺口应回到捕获和维护队列；维护决定下一次调用的质量。把 Company Brain 看成闭环，才会看见真正的成本中心。

{{related:related-context-engineering}}

十个样本说明：根本没有唯一技术路线

电子书列出的实现样本横跨开源项目、记忆 SDK、垂直产品、企业内部系统与极简 DIY。它们的共同点很少，恰好证明 Company Brain 不能被某一种数据库或界面垄断。

GBrain 用 Markdown/Git 作为记录层，以 PGLite 或 Postgres/pgvector 建索引，再用夜间“dream cycle”维护关系和引用。mem0 从应用提交的对话中提取值得保存的事实，并把向量与实体信号用于检索。Letta 让 Agent 管理上下文内记忆、外部档案和完整消息历史，再由后台 Agent 整理共享记忆。Zep/Graphiti 则强调带时间的知识图：新事实让旧关系过期，而非简单删除。

另外几种路线把人类批准放得更重。Sylph 直接把 Git 树当作 Brain，Agent 修改先进草稿，审核后才合并。Claude Code + Git 的 DIY 路线用 CLAUDE.md、规则、技能文件和 runbook 组成知识层，压缩与更新通过工程师和 PR 完成。Carrara 把 Postgres 里的共享记忆复制到本地应用，每条记忆都由人批准。

垂直系统则把“公司”缩小为特定工作域。Pletor 组织品牌规则、创意参考与效果数据；Gorgias Cortex 用大量类型化 Markdown 节点连接客服知识，并从对话轨迹发现缺口；Slite Agent 以现有文档为底层，加入负责人、验证标签、过期窗口、引用回答与 MCP。最后一项是厂商自述，本轮没有独立实测这些产品的当前行为。

比较十个样本，应该先看四件事：什么能进入，什么被当成记忆，更新由谁批准，答案怎样进入工作。路线差异最终会收敛到责任分配，技术名词反倒居于次要位置。

Build or buy 的真正分界，是谁永久维护这层上下文

Slite 称样本中只有 17% 已经拥有“可工作的” Company Brain。受访者的主要顾虑是答案准确性 77%、权限与隐私 63%、维护负担 58%、日常摄取与维护成本 58%、设置工作 33%。这些数字适合比较本样本中的优先级，不适合计算市场规模或普遍发生率。

在已经尝试建设的人中，Slite 称约一半采用 Claude 或 Codex 连接知识库的定制方案，另有约五分之一使用 GBrain。电子书没有说明这组比例的具体分母与调查方法，它只能说明受访早期采用者偏爱可自行控制的技术路线，不能证明自建方案在市场中占主流。

书中把市场画成两个维度：Company Brain 是独立于业务应用的一层，还是某个产品的附属能力；它由企业自己维护，还是交给厂商维护。于是形成四类：自托管独立层、厂商维护的专门产品、企业维护的记忆 SDK，以及大型套件内置且由厂商维护的功能。

来源原图 · Slite Company Brain Survey 2026厂商提出的市场分类，不代表独立基准

这个四象限有明显的 Slite 立场，却提出了一个很硬的问题：你是在买软件，还是在永久外包组织上下文的维护权？ 自建远超“把向量库跑起来”，它意味着长期承担连接器、权限映射、检索评估、冲突处理、人工审核和成本优化。采购也没有消灭这些工作，只是改变了谁做、企业能看到多少过程、离开时能带走什么。

原页的选型器把判断压缩成三个变量：团队规模、最担心的是错误答案／权限／维护／成本中的哪一项，以及内部负责人是否具备技术能力。这个框架比产品名单有用：小团队有工程能力、主要受成本约束时，自托管更可行；规模扩大、权限复杂、维护无人负责时，专门产品更有现实优势；Memory SDK 适合给某个产品或 Agent 增加记忆，不自动等于全公司的共享上下文。页面还为这些答案计算匹配百分比，但没有公布验证方法，因此这些数字只是 Slite 编写的选型启发式，不是效果概率。

Slite 把后一组问题称为“上下文主权”。Company Brain 若真正跨越多个业务系统，它会逐渐形成比任何单一 SaaS 更完整的公司画像。企业至少应做三项尽调：

1. 原始记忆能否完整导出？ 不只导出回答，还要能导出来源、版本、关系与权限元数据。
2. 模型和调用层能否替换？ 如果知识结构只对某个模型或套件开放，切换成本会不断上升。
3. 上游平台收紧接口时会怎样？ Slack 在 2025 年对部分非 Marketplace 应用的历史消息接口设置每分钟一次、每次最多 15 条的限制，并明确反对为外部索引而无约束批量提取对话。依赖查询时抓取的方案必须面对这种平台边界。

独立层因此有战略吸引力，但不能被写成唯一正确答案。小团队可能更适合套件内置能力；监管或高度定制场景可能必须自建；专门厂商可能在维护与权限上更成熟。电子书没有提供准确率、总拥有成本、ROI 或跨方案基准，无法证明哪一类普遍更优。

构建者已有四项共识，四个问题仍无答案

Slite 归纳出的近期共识相当克制：Company Brain 需要永久维护；现阶段 AI 不应在无人审核下任意改写企业知识；捕获最好成为工作过程的副作用；Agent 产生的查询量将远高于人类，因此权限、成本和可观察性都要按机器规模设计。

“永久维护”来自技术路线仍在快速变化。书中研究的系统使用五种 reranker、三套检索思路，却没有共享基准；它们连是否需要知识图谱都没有共识。Zep 把时间图谱放在核心，Gorgias 建了约 12,000 个类型化节点，Slite 和 Letta 则没有采用图谱。Gorgias 的架构文章甚至在发表后到接受本书采访之间已经过时。自建团队承担的因此是一项持续产品工作：采集、检索、权限、评估、调试和治理都要长期有人负责。

知识写回已经形成几种可操作的人审模式。Pletor 把修订建议放进 amendment inbox；Gorgias 的图谱修复必须经过 PR 审阅；Sylph 的 Agent 只能提交草稿，不能自行晋升为正式知识；Slite 用 Agent Triage 展示建议更新。它们解决的是同一个风险：Agent 很难判断一段文字究竟是局部计划、讨论中的设想，还是已经生效的公司决定。错误若直接进入共享记忆，会被后续检索反复调用并逐步放大。

捕获也不能依赖员工想起来再写文档。nao Labs 在每个 Agent skill 结束时增加日志步骤，让知识沉淀成为完成任务的一部分；Gorgias 每晚分析对话轨迹，寻找知识图谱缺失的内容；Slite 观察连接工具中的活动，再提出更新建议。三种做法分别对应任务后记录、从失败轨迹反推缺口、从工作事件捕获信号，目标都是让维护跟着正在发生的工作走。

调用入口也在改变。mem0、Guru 和 Slite 已提供 MCP 服务，Gorgias 也在把内部 Brain 暴露给代码优先的团队。Agent 不必像人一样打开知识库搜索；它会在每次任务开始前自动查询上下文。查询从人的偶发动作变成机器例行步骤后，缓存、权限检查、调用成本、失败日志和异常停止都必须按更高频率设计。

困难的问题集中在组织怎样定义知识，而非模型能否再多检索一些文字。员工与 Claude、ChatGPT 的对话往往保存了最浓缩的推理过程，也可能包含最不愿公开的试探、争论与个人判断。把它们全部排除，组织会失去大量决策上下文；默认汇入共享 Brain，又会越过隐私和授权边界。

冲突版本也不能简单合并。市场团队和销售团队对同一定位可能各自在自己的场景中成立；模型若自动保留声音更大或文档更新更近的一方，实际上替组织选择了立场。当前方案最后往往依赖一个可信的人裁决，这个人同时成为维护瓶颈和单点故障。Company Brain 需要表示“谁在什么范围内认为它成立”，而不只是留下一个看似确定的答案。

书中有位构建者判断，约 80% 的运营知识仍在人脑中。这个数字没有独立研究方法，只能当作受访者观点。它指出了 Company Brain 的一层硬天花板：系统只能治理自己能够观察、能够授权、能够审阅的知识。

没有写下来的部分已经出现一种尝试：Ontora 用结构化、AI 主导的访谈追问员工，把经验背后的理由整理进 Brain。它把问题从“连接哪些系统”推进到“怎样取得从未进入系统的知识”，但来源也承认，这套方法还没有解决规模化、审核负担与员工接受度。

所以，Company Brain 最合理的落地起点是一个错误成本可控、来源边界清楚的工作域。先逐项回答四个问题：信号从哪里来，谁负责确认，权限怎样继承，记忆能否迁移。系统若无法回答，搜索再聪明也只是把旧知识更快地送到人和 Agent 面前。