Launch HN: Hyper (YC P26) 首发评测——为 AI Agent 装上「公司大脑」的知识图谱引擎
新闻背景：AI Agent 的「信息孤岛」困局
2026 年 6 月 3 日，YC P26 批次的新创公司 Hyper 在 Hacker News 上发布了他们的产品——一个名为 Hyper 的「公司大脑」（Company Brain）。短短数小时，帖子获得 78 个 upvote 和 76 条讨论。
这个热烈的回应并非偶然。如果你是一个每天都在用 Claude Code、Codex 或 Cursor 的开发者，你一定遇到过这样的场景：你让 Agent 帮忙写一份 PRD 或回复客户邮件，但它不知道你们公司上周在 Slack 里讨论过什么方案，也不知道你的 CTO 在 All Hands 上重申过什么设计原则。于是 Agent 要么从头瞎编，要么等你手动粘贴一堆上下文——而这正是我们想用 AI 来省下的时间。
Hyper 试图解决的就是这个问题：给 AI Agent 一个持续更新的、结构化的公司知识图谱，让它在每次对话中都带着完整的公司上下文工作。
为什么需要「公司大脑」？
当前 AI Agent 获取上下文的主流方式是 MCP（Model Context Protocol）。但 Hyper 的创始人 Shalin 和 Kanyes 指出了 MCP 的三个根本局限：
- 会话即生死：MCP 的上下文只在当前会话有效，一旦对话结束，Agent 下一次又得从零开始挖掘信息。
- 碎片化收集：团队的信息分布在 Slack 消息、白板讨论、Google Docs 和各种聊天记录中，MCP 无法做全面关联。
- 缺乏元推理：即使 Agent 拿到了所有文档，它也不会自动理解你的设计风格、决策逻辑或因果关系——这些是需要推理才能获取的「隐性知识」。
Hyper 的核心思路：不再让 Agent 每次从头去翻文档，而是建立一个持续更新的知识图谱，Agent 通过 API 或 Hook 直接查询。
技术原理：混合记忆系统
Hyper 的架构核心是一个混合记忆系统，包含两个层次：
记忆层 1：Episodes（原始事件）
Episodes 是信息的原始来源——每一封邮件、每一条 Slack 消息、每一份文档的原始内容都被保留为 Episodes。这是知识图谱的「事实依据」，也是审计追溯的凭证。
记忆层 2：Facts（结构化事实）
Facts 是从 Episodes 中提取的结构化信息，存储为 Subject-Predicate-Object 三元组。例如：
Subject: 张三, Predicate: works_at, Object: 公司ASubject: 项目X, Predicate: deadline, Object: 2026-06-30Subject: 设计规范, Predicate: supersedes, Object: 旧版规范
每个 Fact 都带有时间戳（引入时间和作废时间），以及来源追溯（追溯到原始 Episode）。最关键的是，Facts 之间通过类型化边形成一张知识图谱：
“X is in tension with Y”（X 与 Y 存在矛盾） “A is derived from B”（A 从 B 衍生而来） “J supersedes K”（J 替代了 K）
当一个新 Fact 进入时，Hyper 自动更新其相邻 Fact 的状态。比如「我们周五发货」后来被「我们周一发货」替代，旧 Fact 自动打上 invalidated 标记，但不会删除——你可以随时查询「为什么最后选了周一」。
检索机制：混合查询
在 Agent 查询时，Hyper 使用查询扩展 + 语义搜索 + 全文搜索三合一策略：
- 先用语义嵌入（embedding）做语义搜索
- 配合 PostgreSQL 全文搜索做精确匹配
- 使用 Reciprocal Rank Fusion（RRF）融合结果
- 最终结果经过访问控制过滤——不同权限的人查询同一个问题，得到不同的结果
数据接入：Hook + MCP 双通道
Hyper 支持两种集成方式：
| 集成方式 | 适用场景 | 特点 |
|---|---|---|
| Lifecycle Hooks | Claude Code、Cowork、Codex、Cursor | 自动注入上下文，自动提取新事实 |
| MCP 工具调用 | 不支持 Hook 的 Agent | 按需查询，行为可控 |
对于支持 Hook 协议的主流编码 Agent，Hyper 在每次 Prompt 时注入相关上下文，并从每次 Response 中提取新事实。这意味着 Agent 用着用着，知识图谱会越来越丰富。
数据源接入方面，Hyper 支持 Docs、Slack、Email、Calendar、Granola 等内部信息源，通过 webhook 实时推送或轮询检查变更。
实战场景
场景 1：CEO 代写邮件
一位 CEO 用户用 Hyper 来代写邮件——用他本人的语气和完整的公司上下文来起草回复。「以前每周要花几小时的事，现在只需要几分钟，而且 Hyper 学得越多，写得越准。」
场景 2：Launch 视频脚本
一位 YC 创始人用 Hyper 一次性完成了产品上线视频脚本。因为 Hyper 已经积累了数月来产品功能、品牌定位和团队讨论的知识，不需要再从头解释。
场景 3：Agent 参与决策
如果 Agent 需要知道「为什么我们放弃了方案 A 选择了方案 B」——传统的向量搜索可能找不到答案。但知识图谱中「A 被 B supersedes」这条关系让 Agent 能直接追溯决策链。
与同类产品的区别
| 能力 | Hyper | MCP 裸用 | Glean 等企业搜索 |
|---|---|---|---|
| 知识持久化 | ✅ 跨会话 | ❌ 会话级 | ❌ 搜索级 |
| 结构化推理 | ✅ 知识图谱 | ❌ 纯文档 | ❌ 纯搜索 |
| 时效性管理 | ✅ 自动失效标记 | ❌ 无 | ⚠️ 部分 |
| Agent 原生集成 | ✅ Hook 注入 | ✅ MCP | ❌ 无 |
注意事项
- 云部署：Hyper 目前运行在自己的云基础设施上，适合对便利性要求高的团队。对于强监管行业（政府、医疗），Hyper 表示正在满足合规要求中，但当前并非最佳选择。对数据敏感的企业可以联系团队寻求私有化方案。
- 免费试用：提供 3 天免费试用。
- 定价：详见官网 heyhyper.ai/pricing
- 隐私与安全：Hyper 只提取有意义的信号（决策、见解、关键事实），不复制原始邮箱或 Notion 空间至其服务器。
总结
Hyper 解决的是一个很朴素但很实际的问题：AI Agent 需要知道你的公司具体在做什么、怎么做的、为什么这么做。它不是又一个 AI 编码工具，而是一个「AI Agent 的信息基础设施」——你用得越久，它积累的知识越多，Agent 的工作质量就越好。对于团队规模在 10 人以上、重度使用 AI Agent 的开发团队，Hyper 值得一试。
官方链接：heyhyper.ai | HN 讨论：https://news.ycombinator.com/item?id=48387095