📋 目录
- [📊 先把基本盘核对清楚](#📊 先把基本盘核对清楚)
- [⚠️ 一个数字，五个版本](#⚠️ 一个数字，五个版本)
- [🏗️ 技术在做什么：从文档块到决策图](#🏗️ 技术在做什么：从文档块到决策图)
- [🔐 真正值得看的设计：权限跟着数据走](#🔐 真正值得看的设计：权限跟着数据走)
- [📈 落地情况：三个客户，一个可查的专利](#📈 落地情况：三个客户，一个可查的专利)
- [⚖️ 一条被忽略的判断：这个需求会不会被平台吃掉](#⚖️ 一条被忽略的判断：这个需求会不会被平台吃掉)
- [📌 最后](#📌 最后)
📊 先把基本盘核对清楚
10 月 14 日，一家以色列公司 Uvi 宣布完成 750 万美元种子轮。CT Innovations 领投，Cardumen、Mana VC、91 Ventures 参投。
公司正式名是 Naboo Research Ltd.，2023 年在特拉维夫成立，创始人是 CEO Gilad Salinger 和 CTO Dror Wolmer。
已公开的生产客户有三个：Lemonade（保险）、monday.com（协作软件）、Melio（支付，后被 Xero 以 25 亿美元收购）。
Uvi 主张的问题一句话就能说清：
每当公司部署一个新的 AI 智能体，它对部署它的公司一无所知。这些智能体必须从零开始学习公司的一切业务流程和运营方式，而这个过程被一遍遍重复，持续消耗算力资源。
CEO Salinger 把这个问题的性质说得很直接：
原因是结构性的，不是智能问题。 大公司运行着几十种数据形态完全不同的工具，而同时从 Snowflake 和 GitHub 里各拉一份数据、并对两者进行推理的能力，对它们来说并不存在。所以即使一个智能体已经完成过一次任务，下次它还是会失败------因为它从来没有保留住这项工作是怎么做的。
最后半句是整篇文章的核心：「它从来没有保留住这项工作是怎么做的」。这不是模型问题，是记忆问题。
⚠️ 一个数字，五个版本
这是我核实这家公司时发现的最值得写的问题。
同一个「贵了多少倍」，在五份报道里有五个说法：
| 说法 | 出处与口径 | 倍数 |
|---|---|---|
| 内部自建比应有成本高约 8 倍 | SiliconANGLE，官方基准原话 | 8× |
| 同一批问题，DIY 智能体每正确答案贵约 5 倍 | chipdispatch，官方基准描述 | 5× |
| 开放式问题上最高便宜 46 倍 | 多份报道，官方基准 | 46× |
| 标题写「run at eight times lower cost」 | worldprogramming.org | 8× |
| 「让 Agent 学习业务上下文，成本降低八倍」 | agent5.news 中文编译 | 8× |
更乱的是单次回答成本：
| 版本 | 出处 |
|---|---|
| 0.75 ~ 1.41 美元，有时超过 2 美元 | SiliconANGLE（Salinger 原话） |
| 75 美分 ~ 2.41 美元 | agent5.news 中文编译 |
| 0.75 ~ 1.41 美元，有时超过 2.00 美元 | chipdispatch |
| 经 Uvi 后为 10~16 美分 | 多份报道一致 |
注意 agent5.news 那个 2.41 美元的上限。 其他三家都写「超过 2 美元」，只有它写 2.41。这更像翻译时把范围写成了具体值，但也可能是原始数据。我没有查到 Uvi 官方发布的基准报告原文，因此无法判定哪个是准确口径。
那为什么会有 5 倍和 46 倍这么大的差距？chipdispatch 那篇交代了计算方式，这是目前最详细的解释：
Uvi 用同一批问题跑了两遍------一遍走它的上下文层，一遍走 DIY 智能体，测的是每次正确答案的成本：总模型花费除以答对的问题数，不是答了的 。DIY 智能体每个正确答案大约贵 5 倍，因为在搜索一个结构化地图本可以直接提供的上下文时烧掉了 token。差距在开放式问题上会拉大，因为 Agent 会在搜索循环里卡住------那里 Uvi 声称最高便宜 46 倍。
这段解释清楚了三个关键点，这三点比倍数本身更重要：
| 要点 | 说明 |
|---|---|
| 分母是「答对」不是「答了」 | 这个基准测的是有效产出，不是调用量。口径比多数厂商严格 |
| 5 倍是平均值 | 同一批问题上整体的平均差距 |
| 46 倍是开放式问题的极值 | 搜索循环卡住时的最坏情况，不是典型情况 |
所以 46 倍是一个最好情况下的极值，不是可用来做预算的数字。 如果一家企业按 46 倍做财务规划，而实际业务大部分是结构化查询，实际差距可能只有 5~6 倍。
据 Uvi 的说法，DIY 智能体跑一次回答要 0.75~1.41 美元，有时超过 2 美元；经 Uvi 层之后平均 10~16 美分。
对照一下：0.75 ÷ 0.10 = 7.5 倍，1.41 ÷ 0.16 ≈ 8.8 倍。8 倍这个数字和这个区间对得上。 这是「8 倍」最可信的原因------它是成本区间中位数的直接除法结果。
而 5 倍和 46 倍都出自「每次正确答案成本」这个不同的分母。五个数字不是矛盾，是五套口径。
🏗️ 技术在做什么：从文档块到决策图
Uvi 对 RAG 的批评是这个技术路线的立论基础，值得完整引用：
RAG（检索增强生成）是让大模型基于企业数据的主流技术，它对静态知识库 效果良好，但在活着的研发环境中 会失效。开发者的 AI 助手不需要「10 个最相似的文档块」，它需要知道涉及哪些代码、谁负责、做过什么决策、最近改了什么，以及这个开发者被允许看什么。
这段话指出了 RAG 在企业场景下的一个结构性错配：RAG 是按「相似度」检索的，而企业里的很多关键问题不是「找相似的文档」，是「找这件事的来龙去脉」。
Uvi 的核心抽象叫 Decision Graph（决策图）：
决策被建模为一等公民节点，携带负责人、触发条件、阻塞项、依赖关系和支撑证据。
对比一下就明白差别了：
| 维度 | RAG | Decision Graph |
|---|---|---|
| 返回什么 | 10 个最相似的文档块 | 一条相关决策的结构化链条 |
| 组织单位 | 文档 / 切片 | 决策 |
| 携带的信息 | 文本内容 | 负责人、触发条件、阻塞项、依赖、证据 |
| 跨系统 | 基本做不到 | 实时 join + ETL |
| 追溯性 | 能追到源文档 | 每个答案都能追到具体决策及其证据 |
数据源覆盖 Slack、代码库、编码会话、会议记录、Jira、Confluence 等。Agent 通过 GraphQL 或 MCP 查询。
有一个细节我认为是这套设计里最见功力的地方：
它还分析历史上下文，比如在 Slack 里做出的某个决策，后来在某个文档的评论里被推翻，用来重建 Agent 的推理过程。
推翻了的历史决策才是上下文。 一个只记录「当前有效状态」的知识库，无法回答「为什么当初这么做后来改了」------而后者恰恰是开发者最常问的问题。
这里还有一个容易被带偏的地方。决策图和「带时间戳的文档库」看起来相似，但结构完全不同：
| 返回什么 | 回答的问题 | 风险 |
|---|---|---|
| 最相关的 10 个文档块 | 「现在都写了什么」 | 可能包含已作废的规定 |
| 一条决策链路（依据 + 反例 + 其他视角） | 「当时为何这么判」 | 需要实时同步才不会引用过期结论 |
第二行的「反例」是这套结构里最值钱的部分。它返回的不只是结论，还包括当时考虑过但否决了的方案。这恰恰是人做决定时真实的信息结构，而绝大多数知识库系统会把这些「被否决的方案」当成噪声丢掉------因为它们没有出现在最终结论里。
企业里一个很常见的现象是：一份文档写着 A 方案，但半年前的会议记录里写的是 B 方案，而且 A 已经被推翻了。 如果检索系统只按语义相似度排前十条，很可能返回那份文档而不返回推翻记录------答案看起来有依据，但依据已经过期了。
还有一个容易被忽略的商业角度：知识存在任何单一模型之外，所以公司换模型时不需要让新模型重新学业务。 这一条对正在多模型并存的采购方，价值可能超过成本节省本身。
🔐 真正值得看的设计：权限跟着数据走
这是我认为 Uvi 这条路线里最有分量的一段，也是它区别于「又一家知识图谱公司」的地方。
Salinger 的原话：
我们给数据打标签，这样一个人离开了某个工具、或者离开公司之后，他就不会在以后被 Agent 呈现出来 。这是大部分 RAG 管道做错的部分------它们只管把数据吸进来，然后忘了谁有权看什么。 我们的图谱跨平台重建关系并把权限一起带上，所以不需要事后单独做安全改造。
这半句话点出了一个在企业场景里非常实际的问题：RAG 一旦接进业务流程，权限就不是可选项。
传统权限模型是「谁在什么系统里能看什么」------它长在系统边界上。而 RAG 的做法是把数据抽出来、切片、存进向量库，然后检索。
问题就在这一步：数据被抽出来的瞬间，权限信息通常跟着丢了。 结果是一个查不到「谁看过这条内容」的检索层------在政务、金融、医疗场景里，这个东西根本过不了评审。
Uvi 的解法是把权限作为数据的一部分来管理：图谱重建跨平台的关系时，把权限一起携带。
配套的技术条件也说明了为什么这个设计不容易被复制：它要求系统能同时访问 Slack、Jira、Confluence、代码库、会议记录并做实时关联，而每一步都要保留原有的权限语义。这不是在检索层打补丁，是在数据层解决。
部署形态上，它支持本地或客户私有云，检索时原生执行 RBAC（基于角色的访问控制），零数据出域。
📈 落地情况：三个客户，一个可查的专利
生产客户这一块信息量不大但都是硬的：
| 客户 | 行业 | 公开细节 |
|---|---|---|
| Lemonade | 保险 | 未披露细节 |
| monday.com | 协作软件 | 让 Agent 理解 Jira 工单、PR、feature flag 之间的关系 |
| Melio | 支付 | 未披露细节，母公司 Xero 以 25 亿美元收购 |
CT Innovations 的 Gwen Cheni 有一个说法很值得记：
我们接触的每一家企业都已经花了一年时间和相当真实的预算，试图构建规模化上下文，而且大多数仍然离目标很远。
这句话等于说：这个需求不是被创造出来的，是每家做 AI 的企业都已经自己踩过一遍的坑。
技术侧有一个可查的记录：CTO Wolmer 持有美国专利 12468695-B1，2025 年 11 月 11 日授权，主题是基于 LLM 的知识图谱查询。
另外在融资方结构上有个小细节：CT Innovations 同时领投并运行 Venture IQ Fund，参与方名单在不同报道里略有差异（worldprogramming.org 提到领投方写的是 CT Innovations 和 Cardumen 两家，另提 Gaingles VC 参投）。这类差异不影响事实主干。
⚖️ 一条被忽略的判断：这个需求会不会被平台吃掉
这条我得说，因为它跟前面那些正面材料形成对照。
Uvi 的定位是刻意跟两类产品区分开的：Glean 式的企业搜索 ，以及标准知识图谱。
但要看到一个现实：它依赖的那些数据源------Slack、Jira、Confluence、Salesforce------背后都是平台公司。平台自己正在做「企业搜索 + Agent 上下文」这件事。
对采购方来说，这意味着一个现实问题：如果平台自己提供上下文能力，这层独立供应商的价值取决于平台开放多少。 这不是 Uvi 一家的风险，是整个「Agent 基础设施」赛道的共同风险。
它能给的差异化护城河有两处，都写在明面上：
一是跨平台中立性------平台自己的方案只能覆盖自己的生态，Uvi 可以同时接 Slack 和 Jira 再加上代码库。
二是决策图这个抽象------它不是文档检索，是决策链路的建模。这个模型如果成立，理论上平台自己也难做（因为它缺少跨平台视角）。
但这两个护城河都是「需要时间验证」的，不是「已经确立」的。
📌 最后
如果这篇文章只留一句话，我想留的是这个：这家公司最值得注意的数字不是 46 倍，是 0.75 到 1.41 美元这个绝对值。
一次业务问答花掉接近一美元------这个数字比任何倍数都更能说明问题。企业 AI 落地的成本，大部分不花在模型调用上，花在「让模型知道自己公司的事」这件事被反复重做上。
而它给出的解法里，最值得抄的是那个不太性感的部分：权限跟着数据走。
「先吸进来再想办法做安全」这个顺序，在企业里是行不通的。这句话无论买不买 Uvi 的产品都成立------一个查不到谁看过什么的检索层，在任何有合规要求的场景里都是不能上线的。
至于那些倍数，我的建议是：别按 46 倍做预算，按 5~8 倍算，然后留出上行空间。 因为 46 倍是搜索循环卡住的极值，而你的业务里大部分查询不会卡住。
你们公司自己做 Agent 的时候，是每次让模型重新学业务，还是已经建了统一的一层？成本对比下来差多少？评论区报个数，我帮你判断这个差距是不是正常水位。 