Hyper 公司知识库：AI Agent 记忆的工程化设计

你用 Claude Code 改代码，它不知道三个月前为什么删了那个分支。你问 ChatGPT 项目决策，它得重新读完所有文档才能回答。每次调用都要重新解释项目历史，这是 Agent 和普通 RAG 的一个关键差异：后者擅长检索静态文档，但公司知识有三个维度它原生不处理——事实有效期、权限范围、决策推理链。

Hacker News 上 Hyper 说要做”公司大脑”，听起来像营销词，但创始人在发布帖里透露的架构细节有技术价值：双层记忆（episodes + facts）、typed edges、时间戳模型、hooks 与 MCP 两条注入路径。下面的分析不写产品评测，而是用这些公开信息拆解”公司记忆”的设计问题，给你五层设计清单、7 天试点路径和选型风险判断表。

普通 RAG 接不住的三类上下文

RAG 检索文档、返回片段、让模型回答。这套流程对静态知识库有效，但公司知识有三个维度 RAG 原生不处理。

维度	RAG 默认行为	实际问题	Company brain 需要的机制
事实有效期	返回最新匹配片段	旧文档≠失效事实，三个月前的决策可能已被推翻	introduced_at / invalidated_at 时间戳，标记事实生命周期
权限范围	检索不区分用户身份	全员可见≠项目组可见，Agent 可能读到不该读的内容	access-control tags 过滤，按团队/角色裁剪结果
决策原因	返回结论片段	知道结果≠知道推理链，无法追溯”为什么这样决定”	Episodes 保留原始对话，事实层注明 derived from 来源

传统 RAG 按 recency 或 relevance 排序，无法判断这条信息是否已被 newer fact supersedes（替代）。Hyper 给每个 fact 配两个时间戳：introduced_at 记录首次出现，invalidated_at 记录失效时间。检索时过滤已失效事实，不依赖文档更新日期。

权限范围在多人组织中更敏感。Agent 调用时可能代表某个团队成员，它不应该读到该项目组之外的内容。Hyper 使用 access-control tags 标记每条事实的可见范围，检索层在返回结果前会根据调用者身份过滤。这点比”企业搜索”更精细——后者通常只做文档级权限，而 company brain 需要事实级裁剪。

决策原因是普通 RAG 最难接住的。你问”为什么选 PostgreSQL 而不是 MongoDB”，RAG 可能返回架构文档里的结论段落，但那段文字不会包含三个月前的技术讨论、权衡过程和最终决策逻辑。Hyper 的 episodes 层保留原始对话节点，facts 层用 derived from typed edge 指向来源 episode，这样检索时能沿关系找到推理链，而不只是结果。

Hyper 双层记忆架构拆解

Hyper 用双层结构组织记忆：Episodes（原始存储）和 Facts（结构化层），之上用知识图谱连接。

Episodes 层：保留原始对话节点，不丢弃上下文，作为事实的溯源锚点。Agent 需要追溯决策过程时，能从 fact 沿 derived from edge 找回原始对话片段，不只读摘要后的结论。

Facts 层：采用 subject-predicate-object 三元组结构化。每条 fact 包含主体、关系、对象三个字段，加上时间戳和 typed edges。创始人披露的三类 typed edges：

Typed edge	含义	使用场景
derived from	事实来自哪条 episode	追溯决策推理链
supersedes	新事实替代旧事实	标记失效事实，过滤旧结论
tension	事实之间存在冲突或矛盾	提醒人工纠错，避免模型采信矛盾信息

时间戳模型：每条 fact 有两条时间线。T 线记录事件发生时间（“决策是在3月做的”），T’ 线记录系统摄入时间（“这条 fact 在6月写入知识库”）。两者分离是因为公司知识经常有延迟输入——会议结论可能一周后才录入，系统需要区分”事实发生时间”和”我们知道这条事实的时间”。

架构核心要点：

• Episodes 不做摘要，保留原始对话节点（HN 创始人称 + Zep 论文支撑）
• Facts 结构化为三元组，每条带时间戳和 typed edges（HN 披露）
• introduced_at / invalidated_at 标记事实生命周期，检索层过滤已失效内容
• 知识图谱用 typed edges 解决”关系”而非只存”事实”，这是与普通向量库的关键差异

这套架构的目标不是存储更多数据，而是让 Agent 能沿关系找到上下文。普通向量库返回相似片段，但不知道片段之间的逻辑依赖、替代关系和冲突点。typed edges + 时间戳的组合让检索结果能附带”这条事实从哪里来、是否仍有效、有没有被替代”的元信息。

检索与注入的两条路径

知识写入后，Agent 有两条使用路径：检索（主动查询）和注入（被动接收）。

检索机制（HN 创始人披露）：

• Postgres 全文检索：关键词匹配，适合精确查询（如”某个 API endpoint 的定义”）
• Embedding 语义检索：向量相似度搜索，适合模糊查询（如”上次讨论性能优化是什么结论”）
• Reciprocal Rank Fusion（RRF）：融合全文和语义两路召回结果，按综合排序返回
• Access-control tags 过滤：根据调用者身份裁剪结果，保证权限边界

这套组合与纯向量库不同——后者只做语义召回，可能在精确关键词查询时漏掉结果。Hyper 用 RRF 融合两种召回方式，在排序阶段综合考虑关键词命中和语义相似度。

注入路径对比：hooks 与 MCP 是两条不同的数据通道。

维度	Hooks	MCP
机制	实时注入 Agent 上下文（推送）	标准化工具调用协议（拉取）
透明度	HN 评论质疑安装提示不够明显	OpenAI SDK 要求显式声明 MCP server
适用场景	上下文自动注入（如当前项目文档）	Agent 主动调用工具（如查询数据库）
技术依赖	需要客户端侧安装拦截层	需 Agent 框架支持 MCP 协议（OpenAI/Anthropic）
治理风险	用户可能不知道哪些数据被注入	管理员可控制 MCP server 权限范围

两条路径可以并存。Hyper 创始人称 hooks 用于实时注入 Agent 上下文（如你打开 Claude Code 时自动加载项目文档），MCP 用于 Agent 主动调用外部工具（如查询 Notion 或 Gmail）。但 HN 评论中有人质疑 hooks 的透明度——用户是否清楚知道哪些数据被自动注入到 Agent 对话里。

选型时需要检查两点：hooks 是否有明确的安装提示，MCP server 是否由管理员控制权限范围。OpenAI 的 developer mode 文档提到，MCP apps 需要安全验证，Enterprise 计划可用 RBAC 控制访问。这意味着 MCP 的治理框架相对成熟，而 hooks 的透明度依赖产品设计。

Company brain 五层设计清单

自建或选型时，检查这五层是否都有方案。每层的缺失都会在实际使用中暴露问题。

第一层：数据源接入

• 工具选择：Notion、Gmail、Slack、GitHub、Linear、Jira（按团队工作流选择）
• 接入方式：webhooks（实时）或 polling（定时轮询），webhooks 响应快但需目标系统支持
• 数据清洗：过滤噪音（如 Slack 的闲聊频道）、标记敏感信息、统一编码格式
• 初始导入：全量历史 vs. 仅新数据，历史数据可能有大量过时事实

第二层：事实层 Schema

• Fact 结构：subject-predicate-object 三元组，每条事实用统一格式存储
• 时间戳：introduced_at（首次出现）+ invalidated_at（失效时间），缺一会导致无法判断事实生命周期
• Typed edges：至少包含 derived from（溯源）、supersedes（替代）、tension（冲突）三类关系
• 冲突处理策略：自动标记 tension 供人工审核，或按时间戳取 newer fact

第三层：检索层

• 召回组合：全文（关键词）+ 语义（embedding）+ RRF 融合，纯语义召回可能在精确查询时漏结果
• 权限过滤：事实级 access-control tags，根据调用者身份裁剪结果
• 排序策略：综合 recency、relevance 和 fact validity，过滤已失效事实
• 延迟目标：检索响应 < 500ms（实测），否则 Agent 调用体验会明显下降

第四层：注入层

• 路径选择：hooks（实时注入上下文）vs MCP（Agent 主动调用），两条路径可并存
• Agent 兼容性：Claude Code、Cursor、ChatGPT、Codex 是否支持所选路径
• 治理框架：hooks 是否有透明安装提示，MCP 是否由管理员控制 server 权限
• 数据量控制：注入上下文长度上限（避免 token 超限），优先注入高 relevance 事实

第五层：治理层

• 权限继承：数据源权限如何映射到事实级可见范围，Slack 私有频道的事实不应被全员读
• 审计日志：谁在何时注入了哪条事实、Agent 在何时读取了哪些事实，出问题时可追溯
• 人工纠错机制：标记错误事实、设计 invalidated 流程、支持手动添加澄清事实
• 数据导出：是否能导出完整事实库（JSON/CSV），供应商锁定风险评估

这套清单的核心逻辑：每层都解决一个具体问题。数据源层决定”从哪里来”，事实层决定”存什么结构”，检索层决定”怎么找”，注入层决定”怎么给”，治理层决定”谁来管、如何纠错”。缺任何一层，公司知识库在实际使用中都会卡住。

7 天试点路径

小团队第一周不要接全量 Slack、邮箱或 CRM。权限复杂、噪音大，容易在试点阶段就暴露治理问题。先从低风险数据源开始，验证召回率和纠错机制后再扩展。

Day 1-2：选低风险数据源

• Notion 公开文档（产品路线图、技术规范）
• GitHub README 和 Wiki（项目架构、API 文档）
• 排除：Slack 私有频道、邮箱历史邮件、CRM 客户数据（权限敏感，噪音大）

Day 3：设计 Fact Schema

• 3-5 字段：subject、predicate、object、introduced_at、source
• 不追求完美：试点阶段重点是验证检索路径，Schema 后续可迭代
• 约定命名：subject 用统一格式（如”ProjectX”），predicate 用动词（如”uses”）

Day 4-5：检索与注入测试

• 检索测试：准备 5-10 个查询，检查召回率（能否找到关键事实）
• 注入测试：选一个 Agent（Claude Code 或 Cursor），验证能否读到注入的上下文
• 记录延迟：检索响应是否 < 500ms，注入后 Agent 是否能正确引用事实

Day 6-7：回放与人工纠错

• 回放历史查询：检查检索结果中是否有错误或过时事实
• 记录错误：列出需要 invalidated 的 fact，设计标记流程
• 设计纠错机制：人工添加澄清事实 + 标记错误事实的 invalidated_at 时间戳

首周禁止项：

• 不接 Slack、邮箱、CRM（权限复杂，噪音大）
• 不追求完美 Schema（先验证检索路径，Schema 可迭代）
• 不接生产数据源（用测试数据或公开文档验证流程）

试点结束时，你应该有：一个可工作的检索+注入流程、5-10 条验证过的事实、一套纠错标记流程。这三点是扩展数据源的前提——先验证”能找到、能读、能纠错”，再考虑接入更多工具。

选型风险判断表

决策时检查七个风险维度，每个维度标注信息来源和置信度。

风险维度	公开信息	来源	置信度	选型时需确认
数据导出	创始人称支持导出	HN 评论	medium	导出格式（JSON/CSV）、完整性、迁移成本
隐私承诺	FAQ 称”不训练用户数据、AES-256 加密”	Hyper FAQ	medium	是否有 SOC 2/ISO 27001 时间表、数据存储位置
供应商锁定	无自托管选项	HN 评论	high	导出格式是否完整、备选方案是否可替代
Hooks 透明度	评论质疑安装提示不够明显	HN 评论	medium	用户是否清楚知道哪些数据被注入
权限继承	access-control tags	HN 创始人披露	high	数据源权限如何映射到事实级、继承规则未公开
知识图谱上下文	typed edges 保留关系	HN 创始人披露	high	Episode 是否会摘要导致丢意图（HN 评论担心）
冲突处理	人工纠错机制未公开	HN 评论	low	是否有标记错误事实的流程、是否支持手动澄清

七个维度里，数据导出和供应商锁定是决策时最需要检查的点。HN 评论中创始人称支持导出，但没有官方承诺全文。这意味着选型时需要确认：导出格式是否是结构化的（JSON/CSV），能否导出完整事实库（包括 typed edges 和时间戳），迁移到其他系统时是否需要额外清洗。

Hooks 透明度是另一个容易被忽略的风险。hooks 在客户端侧注入上下文，用户可能不清楚哪些数据被自动加载到 Agent 对话里。选型时需要确认：产品是否有明确的安装提示，用户能否查看和控制注入的数据范围。

权限继承的技术方案（access-control tags）有披露，但继承规则未公开。实际问题是：Slack 私有频道的事实如何映射到事实级可见范围，CRM 客户数据如何按团队裁剪。选型或自建时需要设计这套映射逻辑。

下一步与延伸阅读

想继续深入 Agent 与知识库的结合，可以看这些相关内容：

• RAG + Agent：下一代 AI 应用架构 — RAG 与 Agent 的组合架构，如何让检索结果驱动 Agent 决策
• AI Agent 记忆系统：让智能体记住上下文 — Agent 个人记忆的架构设计，与公司级共享记忆的差异
• Workers AI + Vectorize RAG 教程 — Cloudflare Vectorize 向量库实战，搭建小型 RAG 系统的技术细节
• AI Agent 监控与自恢复：从失败到可控 — Agent 执行失败时的监控与自恢复机制，把记忆和执行连成闭环
• Agent 工具调用实战：让 AI 调用外部 API — MCP 协议与工具调用的技术细节，注入路径的实践参考

结论

Hyper 仍是早期产品，公开架构细节（双层记忆、typed edges、时间戳模型、hooks 与 MCP 双路径）是学习”公司记忆”设计的好案例。小团队选型或自建时，重点检查数据导出、hooks 透明度、冲突处理这三个风险点。

试点阶段先做窄工作流：从 Notion 公开文档或 GitHub README 开始，验证检索召回率和纠错机制，再考虑接入 Slack 或邮箱。不要一开始就追求完美 Schema——事实生命周期、权限继承、人工纠错流程都需要在实测中迭代。

如果你已经在用 Claude Code 或 Cursor，可以先试试用 hooks 注入项目文档，观察 Agent 是否能正确引用事实。下一步是把记忆和执行连成闭环：Agent 监控与自恢复机制，让失败能被自动发现和重试。