Hyper 公司大脑：AI Agent 知识库应该怎么设计

Hyper 让我停下来看的，不是 company brain 这个名字，而是它把很多团队已经遇到的问题说得很直：AI Agent 已经能连续改代码、写邮件、跑脚本，却经常不知道团队昨天刚把哪条方案否掉了。你让 Codex 改一个支付页，它可能拿的是旧 PR 里的产品口径；你让 Claude Code 查一个接口约束，它会重新翻 Drive，却不知道 Slack 里后面又改过。人类同事会顺手补一句“那个方案别用了”，Agent 不会自己长出这种默契。

我会先把 Hyper 当成一个架构案例看。它还很早，公开资料也不等于第三方验证过的产品效果；但 YC 页面和 Launch HN 讨论里露出的细节，刚好能帮我们把“AI Agent 的公司知识库”拆清楚：它不只是文档搜索，也不只是 MCP 连接器，而是让 Agent 在正确、最新、合权限的公司上下文里行动。

普通 RAG 卡住的地方

普通 RAG 很适合从文档里找片段。你把 Markdown、PDF、网页切块，做 embedding，问问题时召回相似内容，再让模型组织答案。BetterLink 之前写过 RAG + Agent 架构，那条路线对知识问答、客服 FAQ、代码库解释都够用。

公司上下文的问题更麻烦。Agent 不只要“找到相似内容”，还要知道这条内容现在能不能信、谁能看、为什么当时这样决定。

旧信息和新信息会挤在一起

想象一个很小的发布决策：周一会议说“周五上线”，周三客户反馈变了，产品负责人把上线改到下周一。向量库可能同时存着两段话，哪段排在前面取决于 query、embedding、chunk 和排序。Agent 如果只拿到“周五上线”的旧片段，就会继续写错误的公告、排错误的任务。

更稳的做法是保留两条事实，但让新事实明确取代旧事实：谁说的、什么时候说的、影响范围是什么、旧结论为什么失效。这样 Agent 回答“为什么延期”时还能追到过程，而不是把历史删掉。

权限不是回答之后才处理

公司知识库一旦喂给能执行动作的 Agent，权限就不是小事。销售、客服、工程、管理层问同一个客户，系统可能该返回不同范围的内容。OpenAI 在团队连接器里也强调，ChatGPT 只能看到用户已有权限能访问的内容，连接器会尊重现有权限边界。

这件事要发生在检索前，而不是模型拿到上下文之后再靠提示词自觉。先把不可见数据排除掉，再召回、排序、注入，才不会让 Agent 在日志、草稿、工具调用里漏出敏感信息。

Agent 还缺“为什么”

很多团队文档只记录结果，不记录理由。一个设计方案被否掉，可能因为品牌不合适、销售说客户不买账、技术债太重，或者只是某个时间点资源不够。Agent 只看结果，很容易在另一个场景里重复踩坑。

OpenAI 的 memory 研究更新把好记忆拆成延续上下文、遵守偏好、随时间保持新鲜这几个目标。放到公司级知识库里，还要再加一条：能解释决策背后的约束。没有这层，Agent 只是更快地翻资料，不一定更懂公司。

Hyper 公开资料里能看到的架构

Hyper 的公开说法里，我比较在意几个细节。它们不保证产品已经完美，但方向比“把 Slack 和 Drive 都塞进向量库”具体得多。

第一个细节是 episodes 和 facts 的拆分。HN 发布帖里，创始人把原始来源称为 episodes，比如文档、邮件、日历、Slack、Granola 记录等；facts 则是从 episodes 里抽出来的含义，形态接近 subject-predicate-object，还带 plain summary、引入时间和失效时间。原始材料保留为事实来源，抽取后的事实用于快速推理和检索。

第二个细节是 facts 之间有关系边。公开讨论里提到，某些事实可以处于 tension，某些事实 derived from 另一条事实，新的事实可以 supersede 旧事实。这个设计对 Agent 很要紧，团队上下文更像一串会变化的决定，而不是静态资料夹。

第三个细节是混合检索。Hyper 在 HN 中提到 query expansion、embedding semantic search、Postgres full-text search，以及 reciprocal rank fusion。这个组合并不神秘，但很务实：语义检索适合找相近含义，全文检索适合精确词、客户名、工单号、函数名，融合排序可以减少单一路径的偏差。

第四个细节是权限标签。每条 fact 都带 provenance 和 access-control tags，检索时只在提问者有权访问的 facts 与 episodes 上评估。这个设计如果做不到，company brain 很快会变成安全风险。

第五个细节是 hooks 和 MCP 的分工。MCP 官方文档把它描述为连接 AI 应用与外部系统的开放标准；OpenAI Agents SDK 也支持多种 MCP 接入方式。MCP 适合让 Agent 主动查工具，但它依赖 Agent 识别何时该调用。Hyper 在 HN 里说，对 Claude Code、Codex、Cursor 等工具还会用 lifecycle hooks，在会话开始、提交 prompt、Agent 回合结束等节点注入或抽取上下文。这个取舍有争议，尤其是 hook 安装透明度，但它点出了一个实际问题：很多上下文不能只靠 Agent 想起来才查。

自己做 company brain，先拆成几个可检查的部件

如果团队暂时不想引入新供应商，也可以先做一个小版本。别从“把所有数据接进来”开始，先把系统拆成几个能验收的部件。

Source：原始来源要能回放

来源层不追求一开始接全。更合适的起点是产品决策 Markdown、近期 PR 摘要、公开 issue、客服知识库这类低风险材料。Slack、邮箱、CRM 信息密度高，但噪音和权限也高，先晚一点。

每条来源要记录最小元数据：来源类型、原始 URL 或文件路径、创建时间、更新时间、作者、可见范围、hash。后面事实抽错了，必须能回到原文核对。

Fact：事实别只写一句摘要

一个可用 fact 我会给它这些字段：主体、谓词、客体、摘要、来源、引入时间、失效时间、权限标签、置信度、人工修正记录。这里不是为了凑字段，而是为了让 Agent 回答时有边界。

举个例子：

字段	示例	为什么需要
subject	checkout-redesign	知道事实关联哪个项目
predicate	supersedes	知道它和旧方案的关系
object	checkout-v1-layout	能追到被替换对象
source	PR #183 + product-note.md	回答时可溯源
valid_from	2026-06-03	判断新旧
acl	product, engineering	检索前裁权限

事实抽取很难一次做准，所以要有人工纠错入口。HN 评论里有人问“成熟公司资料又乱又矛盾怎么办”，Hyper 创始人提到可以通过 /correct 这类 MCP skill 做硬修正。这个方向可以借鉴：让人能明确说“这条不对，以这条为准”，并留下记录。

Retrieval：混合检索比单一路径稳

向量检索适合模糊语义，但客户名、SKU、工单号、函数名、合同编号这些信息经常靠关键词命中。我的建议是把检索拆成三步：

1. 先按用户身份、项目、数据源做权限和范围过滤。
2. 再并行跑语义检索、全文检索、图谱邻居扩展。
3. 最后用重排或规则融合结果，只注入少量高相关事实。

注入给 Agent 的内容越多越好这种想法很危险。上下文太宽，模型会把不相关事实也当成线索。更实用的策略是每次只给 5-15 条窄上下文，并附上来源和置信度；信息不足时，要求 Agent 先追问或回查原始来源。

Injection：MCP、hooks、手动上下文各有边界

MCP 是入口，不是完整记忆系统。它能让 Agent 访问工具和数据源，也能承载类似 search_company_facts、correct_fact、get_decision_history 的能力。你可以从 Agent 工具调用实战 那条路线扩展，把公司知识库作为工具接进去。

hooks 的优势是稳定：每次会话开始或提交 prompt 前自动注入，不依赖模型主动调用工具。它的风险也明显：用户必须知道什么被安装、什么时候运行、会读取什么、能不能关闭。这个点在 HN 评论里引发了争议，小团队自己做时尤其要把提示和开关放在明处。

手动上下文仍然有价值。对于高风险任务，先让人选择“本次允许使用哪些项目知识”，比全自动更安心。AI-first 不等于所有事情都无人确认。

Governance：纠错、导出和审计要早点设计

公司大脑越好用，迁移成本越高。HN 里有人担心供应商锁定，这个担心很现实：当所有 Agent 都依赖同一个知识层，导出、删除、备份和审计就不是附加功能。

我会在试点阶段就问清楚几件事：facts 能否导出为 JSON/CSV？原始 episodes 是否能删除？权限变更是否会触发重新裁剪？Agent 哪次使用了哪条事实有没有日志？人工修正是否会覆盖旧事实，还是保留历史链路？这些问题早问，后面少还债。

几个方案怎么选

不同方案解决的不是同一个问题，别被名字绕进去。

方案	适合解决	输入	优点	盲点
文档 RAG	从已有资料里找答案	Markdown、PDF、网页	成本低，容易做	难处理事实失效和冲突
企业搜索	员工自助找资料	Drive、Slack、Wiki	覆盖广，接入成熟	不一定适合 Agent 自动行动
MCP 工具	让 Agent 访问外部系统	API、数据库、工具	标准化，生态快	依赖 Agent 主动调用
个人记忆	记住单个用户偏好	对话、偏好、历史任务	个性化强	多人权限和团队事实弱
公司大脑	给 Agent 稳定共享上下文	文档、PR、会议、聊天、邮件	能处理事实、关系、权限和注入	架构和治理成本高

如果只是让员工问“报销流程在哪”，企业搜索或普通 RAG 就够了。如果是让 Agent 自动改代码、发邮件、写销售跟进、总结客户风险，系统就要知道更多：这条事实是否仍有效，来源是否可信，用户是否有权看，动作是否需要确认。

OpenAI 的团队连接器已经在做“把团队工具里的内容带进对话”，MCP 生态在做“让 Agent 能连接更多工具”。company brain 更像夹在两者之间的一层：它把零散内容整理成可持续更新、可追溯、可按权限裁剪的公司上下文，再交给不同 Agent 使用。

7 天试点：先做一个很窄的工作流

想验证 company brain，不需要一开始接全公司数据。选一个低风险但高频的 Agent 工作流，跑一周就能看到苗头。

第 1-2 天：选工作流和数据源

挑一个边界清楚的场景，比如“让 Codex 根据最新产品约束修改一个小功能”“让客服 Agent 根据近期 bug 记录生成回复草稿”。只接三类来源：产品决策文档、近期 PR 摘要、公开 issue。不要一开始碰全量 Slack、邮箱、CRM。

写下禁止范围：不允许发真实邮件，不允许改生产配置，不允许读取财务或 HR 数据，不允许把无来源事实当结论。

第 3-4 天：抽 facts 和冲突关系

从来源里抽 50-100 条 facts。先手工抽一部分，再用模型辅助抽取。每条 facts 都带来源、时间、权限、置信度。遇到冲突不要急着删旧内容，把关系标出来：取代、补充、冲突、待确认。

这里可以做一个很简单的 schema，不必上来就买复杂图数据库。Postgres 表、JSONB、全文索引、向量扩展都能做小试点。Hyper 公开讨论里也提到 Postgres 在这类场景仍然很方便，因为结构化元数据和图关系可以放在一起处理。

第 5-6 天：注入上下文并回放任务

给 Agent 加一个工具或 hook：输入当前任务，返回 5-15 条相关 facts，每条带来源。然后找 20 个真实任务回放，记录三类数字：

• 人工补充背景的次数有没有下降。
• Agent 引用旧事实或错事实的次数有没有下降。
• 是否出现越权事实、无来源事实、上下文过宽导致的跑偏。

别只看输出是否漂亮。company brain 的价值在于减少重复解释、减少旧信息误用、让 Agent 对不确定内容更谨慎。

第 7 天：决定扩大、暂停或改方向

如果 20 个任务里只有少数几个受益，先别扩到全公司。可能场景不适合，也可能 facts 抽取太粗。反过来，如果追问明显减少、错误引用下降、没有越权命中，可以再接一个数据源，比如会议纪要或精选 Slack 频道。

下一步再考虑和 AI Agent 监控与自恢复 结合：当 Agent 使用了低置信事实、冲突事实或高风险动作，就触发人工确认。

落地前，把风险讲明白

公司知识库一旦接到 Agent，不再是单纯的信息检索项目。几个风险需要提前写进方案。

第一是隐私和训练边界。Hyper 创始人在 HN 评论里回应说不会训练或出售托管数据，并指向 FAQ 与隐私政策。由于抓取不到官方隐私页正文，我不展开具体条款。团队选型时要看合同、数据处理协议、保留期限、删除流程，而不是只看发布帖。

第二是 hook 透明度。自动注入上下文确实比“希望 Agent 自己调用 MCP”稳定，但用户需要清楚知道本机安装了什么。安装提示、运行日志、关闭开关、可见配置，都应该摆出来。

第三是历史资料污染。成熟公司常常有很多互相矛盾的旧文档，新的不一定总比旧的权威。比如法律、财务、宗教、政府流程里，旧文件可能才是规范依据。系统不能简单按“越新越可信”一刀切，要允许不同来源和角色有不同权重。

第四是供应商锁定。company brain 使用越久，越像公司操作系统的一部分。导出格式、备份策略、自托管选项、灾难退出方案都要提前确认。没有这些，短期很顺，长期可能卡住。

结尾：先让系统学会说“不确定”

我喜欢 Hyper 这类产品抛出的方向：Agent 要继续往团队工作流里走，确实需要比普通文档检索更稳的公司上下文。可落地时别急着喊“全公司大脑”。先让系统能区分新旧事实、能回到来源、能按权限检索、能接受人工纠错，也能在证据不够时说“不确定”。

小团队可以从一个窄工作流开始：三类低风险来源、几十条 facts、二十个真实任务。跑完再决定是不是扩大。这样做不够酷，但对要交付结果的 Agent 来说，可能更接近可用。