Uvi 为 AI Agent 提供企业上下文，但难点在于确保决策真实可靠
Uvi 通过一套新近获得融资的系统为 AI Agent 提供企业上下文；该系统建模的是决策，而不只是文档。这家特拉维夫创业公司表示，正是这一缺失的层级，导致 Agent 浪费时间、消耗 token，并基于碎片化证据采取行动。
该公司已完成由 CT Innovations 领投的 750 万美元种子轮融资，Cardumen Capital、Manu VC 和 91 Ventures 参与投资。Uvi 计划扩充其美国团队、产品研发及市场运营。
这一消息之所以重要，是因为将 Agent 接入 Slack、Jira、GitHub 和内部数据库，并不会自动形成对组织的理解。Model Context Protocol，即 MCP，可以提供对这些系统的访问；检索软件可以找到相关文件。但两种方式都不一定能够还原某项决策为何产生，或判断它是否仍然适用。
Uvi 希望掌握这一重建层。其产品构建了该公司所谓的 Decision Graph，将决策与负责人、触发因素、阻塞项、依赖关系和支持性证据关联起来。
这让 Uvi 与一种常见的企业策略形成对比：连接更多数据源、检索更多文本，然后让模型推断其余内容。Uvi 认为，这种方法会反复让企业为重新发现员工本已理解的关系而付费。
这一主张切合当下需求，但其最难回答的问题仍未解决。决策图必须保持最新、保留权限设置、呈现相互矛盾的证据，并区分有效决策与已被放弃的决策。如果这些控制措施失效，结构化上下文可能会让错误答案显得更具权威性。
Uvi 通过决策图为 AI Agent 提供企业上下文
Uvi 销售的是一张持续存在的组织推理地图，而非又一个用于搜索公司文档的界面。
根据原始的企业上下文报道，Uvi 由 CEO Gilad Salinger 和 CTO Dror Wolmer 于 2023 年创立。该公司最初以 Naboo 之名运营。
其核心论点始于一个企业中常见的问题：重要知识很少存在于单一系统或一份经过精心维护的文档中。
一项产品决策可能始于 Slack 对话。实施工作会出现在一个 pull request 中，而 Jira 则将该任务记录为已完成。后续事故可能导致回滚，但原始工单仍保持关闭状态。
传统 Agent 可以检索到每一项工件，但仍必须判断哪一条记录反映当前状态，以及团队为何改变方向。
Uvi 表示，其 Decision Graph 将决策表示为一类一等对象。每项决策都可以包含负责人、触发事件、阻塞项、依赖关系、状态，以及指向支持性材料的链接。
这不同于将组织视为一组语义相似的段落。向量索引会根据数学相似性表示文本，但它并不天然表示责任、因果、审批或决策背后的顺序。
Uvi 将其产品背后的架构描述为双层结构。第一层是 Topic Graph，它会索引公司各系统中的信息，并解析人员、代码仓库、工单和服务之间的连接。
第二层是 Decision Graph。它将组织的私有定义应用于其下层发现的关系。
例如，一家公司可能将“shipped”定义为代码已合并至生产分支；另一家公司则可能要求全面向客户开放、完成监控配置并获得正式批准。
这些定义会影响一个基础运营问题的答案。如果 Agent 不理解该公司内部对发布就绪状态的定义，就无法可靠地识别被阻塞的发布。
Uvi 表示，专家会与客户合作，对这些概念和决策关卡进行编码。随后，Agent 可以通过 GraphQL 或 MCP server 使用该图谱。
GraphQL 支持来自应用程序的结构化查询，这些应用程序已知自己需要哪些字段和关系。MCP 则提供标准化连接，Agent 可借此表达意图并请求相关上下文。
该公司称，该产品可连接 GitHub、GitLab、Jira、Linear、Slack、Confluence、Notion、Datadog 和 Splunk 等系统，也支持包含特定业务状态的内部服务。
这一设计面向需要多次关联的问题。发布 Agent 可能会询问哪些审批仍未完成、由谁负责，以及什么事件将清除每个阻塞项。
事故 Agent 可能会询问某个 feature flag 为何发生变更，以及哪项客户承诺影响了这一选择。搜索可以找到有关该标志的提及；决策图则尝试重建形成其当前状态的链条。
这一区别解释了 Uvi 为何将自己定位为现有 Agent 之下的基础设施。它并不要求企业替换 Claude、Gemini、GPT 或其内部 Agent 界面。
相反，Uvi 希望企业一次性构建组织上下文，并将其暴露给多个模型。该公司的主张是，模型的变化速度会快于公司系统底层含义的变化速度。
这是一个颇具吸引力的架构边界。它将模型选择与定义归属、运营术语和决策历史的工作分离开来。
但这也带来重大责任。这个共享上下文层会成为每一个依赖它的 Agent 的依赖项。
更多连接器无法解释一项决策为何发生
压力将落在那些把数据访问视为与组织理解相同问题的团队身上。
Anthropic 于 2024 年 11 月推出Model Context Protocol，将其定位为连接 AI 系统与工具和数据源的开放标准。MCP 降低了为每个助手和应用程序设计独立集成模式的需求。
这种标准化解决了一个重要的接口问题。Agent 可以通过通用协议发现可用工具、请求信息并调用受支持的操作。
MCP 不会决定公司内部术语的含义，也不会判断一个已关闭工单是否已被在其他地方讨论的回滚所取代。
Uvi 的论点始于连接器终止之处。访问让 Agent 获得更多证据，而推理层则试图围绕运营意图组织这些证据。
当 Agent 从摘要转向行动时，这一区别尤为重要。搜索助手可以返回多份文档，让人工解决其中的不一致之处。
自主 Agent 则必须在修改配置、升级阻塞问题或更新客户工作流之前，选择应信任哪条记录。这一选择既需要上下文，也需要权限。
传统的检索增强生成，即 RAG，会检索与查询相关的材料并将其提供给模型。当答案存在于检索系统能够识别的文档中时，它的效果很好。
企业任务往往依赖于没有任何单一文档直接说明的关系。答案来自工单、代码变更、对话、遥测数据以及公司对完成状态的定义。
Microsoft 的 GraphRAG project 展示了行业正从孤立文本块迈向更丰富表示的更广泛趋势。GraphRAG 结合提取文本、网络分析、提示和摘要，以构建数据集的更丰富表示。
Microsoft 还支持基于图的上下文提供程序，它们检索相连的子图，而不是孤立段落。其 Neo4j integration 结合了向量、全文、混合搜索和图遍历。
这些发展验证了 Uvi 前提的一部分：关系能够提供仅靠相似性搜索无法获得的信息。
然而，它们也表明 Uvi 正进入一个活跃的技术领域，而非开创一个没有竞争的类别。企业可以组合图数据库、Agent 框架、搜索平台和自定义数据管道。
因此，Uvi 必须证明，决策建模能带来比设计良好的 GraphRAG 系统更高的价值。它还必须说明，其托管层的运营成本低于内部替代方案。
竞争分野并不只是 Uvi 与 RAG 之间的对立。大多数严肃的企业系统将继续使用多种检索方法。
文档搜索仍然适用于政策、报告和规范。当用户不了解相关术语时，向量检索仍然很有帮助。对话记忆可以保留偏好和近期互动。
决策图解决的是另一种需求。它应识别决定 Agent 下一步能够安全执行何种操作的选择、依赖关系和责任归属。
可能的架构会结合这些层。Agent 可以使用搜索定位支持性材料，使用图谱导航依赖关系，并通过源系统验证实时状态。
这种组合会给企业搜索供应商和内部平台团队带来压力。仅返回相关链接已无法满足所有 Agent 工作流。
搜索产品将需要更丰富的关系模型、更强的权限执行能力，以及专为采取行动的机器设计的输出。内部团队在维护自定义连接器和数据管道的同时，也面临同样的需求。
Uvi 的机会在于让这种复杂性能够被复用。其挑战则是证明专业供应商能够足够准确地理解每位客户私有的运营语言。
这一机制依赖于实时关联、意图与权限
Uvi 的技术优势较少取决于图谱术语，更多取决于其关系是否保持最新并得到正确的范围控制。
该产品提出的工作流首先是对运营系统中的信息进行索引。它识别显式链接，例如在 pull request 中引用的 Jira 工单。
它还会尝试解析隐式关系。这些关系可能包括同一服务的不同名称、由多个账户表示的员工，或描述同一发布流程的内部表述。
实体解析意味着将这些引用映射为一致的身份。没有这一能力，图谱可能会将同一个人、代码仓库或功能视为多个无关对象。
下一步引入公司特定的含义。Uvi 表示，专家会与客户合作，定义负责人、阻塞项、部署、审批和交付等概念。
这种人工参与值得注意。该系统并不假定通用模型能够从原始通信中推断出每一条运营规则。
这种方法类似于构建可靠知识库所需的工作。实用的组织记忆依赖于定义、来源、维护和访问边界。
随后，Uvi 使生成的图谱可供查询。Agent 可以请求包含决策、负责人、状态、依赖关系和支持性证据的结构化链条。
这种输出不同于按排名列出的文档。它为 Agent 提供了一个更小的运营对象，可用于指导其下一步行动。
设想一个在项目跟踪器中看似已完成的发布。代码仓库显示相应的拉取请求已合并，但监控数据记录到部署后错误增加。
随后的一次对话称，该发布在仅部分可用时便已停止。决策图谱应当关联这些事件，并防止智能体将该发布描述为已完成。
意图也会改变所需的上下文。审查发布架构需要设计文档、依赖信息和历史权衡。
诊断失败的发布则需要近期遥测数据、回滚细节、变更代码和当前负责人信息。两个查询都提到了同一次发布，但所需证据不同。
Uvi 表示，其层会根据任务收窄图谱范围。若这一机制有效，智能体收到的无关材料会更少，也会减少用于探索彼此无关联来源的模型调用轮次。
该公司在官网上报告了显著的性能提升。Uvi 称，在 Global-e 基准测试中，它在与一个启用 MCP 的 GPT 系统进行的 100 次正面对比查询中赢得了 97 次。
该公司还声称，其速度是 RAG 基线方案的两倍；与使用相同模型、自行搭建的智能体相比，查询成本降低了八倍。这些是供应商自行报告的结果，并非独立基准测试。
已发布的材料没有提供足够的方法论细节，无法将这些结果推广到不同公司。工作负载选择、图谱准备、答案评分、来源复杂度和基线配置都会显著影响结果。
不过，这一基准指向了正确的衡量单位。企业应使用答案正确性、延迟、模型调用总数和人工验证时间来比较系统。
如果员工必须核查每一个答案，更低的 token 数量意义不大。当智能体遗漏当前决策状态时，高检索准确率同样意义有限。
安全性是另一项核心机制。Uvi 表示，它可以在本地部署，或运行在客户控制的虚拟私有云中。
该公司还称，权限会在检索期间得到执行。智能体应只接收请求背后那个人有权获取的信息。
这种控制很重要，因为图谱会建立通往敏感事实的间接路径。用户可能无权访问机密文档，却能通过相连节点推断其内容。
安全部署必须同时保护底层材料及其派生出的关系。即使是隐藏项目、负责人或依赖项的存在，也可能泄露敏感信息。
源级权限也可能彼此冲突。Slack 频道、代码仓库和项目跟踪器可能会为同一个人分配不同的权限。
推理层必须计算有效的权限交集，同时避免泄露受限上下文。每当角色、群组成员资格或来源权限发生变化时，它都必须重复这一计算。
因此，Uvi 的企业应用场景依赖四项能力协同运作：新鲜数据摄取、准确的实体解析、任务感知选择，以及保留权限的检索。任何一层薄弱，都可能削弱最终答案。
决策图谱同样可能固化错误，而不只是保存知识
Uvi 最重要的风险在于，结构化上下文可能会将不确定的组织记忆转化为看似确定的机器指令。
企业决策很少是清晰的记录。团队会产生分歧，例外情况不断累积，临时变通方案也可能在预定期限之后继续存在。
产品经理可能在一个频道批准发布，而安全负责人会在别处阻止它。最终结果可能取决于高管之间一场未被记录的对话。
图谱必须呈现这种不确定性，而不是强行将每个工件归入某个唯一确定的状态。否则，输出看似连贯，却掩盖了真实冲突。
该公司还表示，其系统能够重建从未被明确记录的推理过程。这很有用，但也引入了一条买方应仔细审查的推断边界。
由工单引用支持的关系，与模型对多段对话作出的解释不同。两者都可能在图谱中呈现为边，但其证据权重并不相同。
企业需要知道哪些链接直接来自源记录。对于推断出的关系，它们还需要置信度评分、时间戳和审查路径。
决策的有效性会随时间变化。紧急例外可能到期，服务可能在团队之间转移，审批政策也可能被替换。
图谱必须保留历史，而不能将旧规则与当前规则混淆。它还应解释为什么当前状态取代了早先的证据。
仅靠新鲜数据摄取无法解决这一问题。新消息可能是最新的，但仍可能并非官方信息、带有推测性，或根本不正确。
权威性与时效性同样重要。系统必须区分承担决策责任的人，与讨论可能结果的参与者。
这些问题使评估变得困难。基准测试可以检验系统是否返回预期答案，但预期答案本身可能也存在争议。
客户应在评估中纳入相互矛盾的案例、被撤销的决策、机密关系以及刻意过时的记录。围绕文档齐全的项目提出简单问题，无法揭示系统的失效模式。
他们还应测试 Uvi 如何处理缺失证据。安全的系统应披露不确定性，而不是编造某项决策背后未被记录的理由。
对于后果重大的行动，人工审查仍然不可或缺。图谱可以减少探索工作，但不应取消针对生产变更、财务承诺或安全决策的审批控制。
这正是一个可搜索的工程知识库仍然具有价值的原因。人们在审查智能体提出的行动时，需要能够访问底层工件。
供应商锁定带来了另一项担忧。Uvi 主张，公司应拥有一个可跨模型运行的统一上下文层。
这种可移植性只有在客户能够导出图谱数据、定义、溯源信息和评估记录时才有价值。切换模型很容易，相比之下，重建多年编码而成的运营知识则困难得多。
部署模式同样需要审视。在客户环境中运行可减少部分数据暴露，但并不会自动保证行为安全。
买方应审查管理访问权限、连接器凭据、日志记录、更新流程、加密和事件响应。他们还应验证每个已集成来源的权限行为。
Uvi 的基准测试主张同样值得进行严格审查。报告的结果显示出潜力，但并不能证明其在不同组织或工作流中的表现。
拥有一致工单实践的客户，与依赖私信和非正式审批的客户所处环境不同。图谱质量会反映这些运营习惯。
这一限制并不会否定该产品。它澄清了 Uvi 实际在销售什么。
该公司不只是部署一个数据库。它是在帮助企业将决策、职责归属、证据和权限之间的连接关系正式化。
即使在智能体采取行动之前，这一过程也能产生价值。它还可能揭示有多少关键知识仍停留在非正式状态，或无法被访问。
风险在于将由此形成的图谱视为客观真相。更恰当的理解是，它是一个具有明确来源和未解决不确定性的、持续维护的运营模型。
三个信号将表明 Uvi 的上下文层是否有效
Uvi 现在需要证明，其决策模型能在生产环境中保持准确、可在不同智能体间迁移，并经受企业安全审查。
第一个信号是独立评估。Uvi 已发布客户案例和由供应商运行的对比测试，其中包括其宣称的 Global-e 结果。
下一步是建立可复现的基准测试，记录问题、基线、评分规则、延迟、模型使用情况和图谱准备过程。外部验证将使效率主张更容易评估。
该基准测试不应只考察检索能力。它还应涵盖需要多个系统、不断变化的状态、相互冲突的证据和权限边界的问题。
有意义的结果将强化 Uvi 的主张，即结构化决策优于由连接器驱动的探索。较弱的结果则表明，定制图谱准备的贡献可能大于通用架构本身。
第二个信号是超越受控试点的持续客户采用。Uvi 将 Melio 和 Global-e 列为生产用户，并展示了其高管的表述。
未来的案例研究应说明哪些智能体使用图谱、它们支持哪些行动，以及员工多频繁地推翻其结论。还应报告部署后所需的维护工作。
在多个智能体界面中的采用将支持 Uvi 的模型无关立场。这将表明，一个上下文层能够服务于编码助手、工作流智能体和内部应用。
如果仅限于单一搜索体验中的使用，则会削弱这一主张。这可能意味着图谱在知识发现方面表现良好，但不适用于运营行动。
第三个信号是更大平台如何回应。Microsoft、Anthropic、云服务提供商、图数据库公司和企业搜索提供商都已占据相邻层级。
它们可以整合连接器、图谱检索、模型托管、权限和智能体框架。一些客户会更青睐这种集成式技术栈，而不是另一家专业供应商。
Uvi 必须在决策建模、部署速度或运营准确性方面建立持久优势。仅靠连接器数量无法保护其市场地位。
该公司的 750 万美元种子轮融资为其追求这一验证提供了资源。但这并不能决定推理层是否会成为一个独立的企业软件类别。
买方应关注有关图谱更新、推断关系、访问控制和数据可移植性的更清晰文档。这些细节比精致的演示更重要。
他们还应询问系统在证据冲突时的行为。一个有用的答案必须展示来源、保留不确定性，并明确谁能够解决分歧。
对开发者而言，Uvi 的出现强化了一个更广泛的架构经验：工具访问、检索、记忆和组织上下文解决的是相关但彼此独立的问题。
MCP 可以将智能体连接到公司系统。RAG 可以找到相关文本。图谱检索可以揭示相连实体。持续维护的决策模型则可以加入责任归属、因果关系和运营状态。
没有任何单一层能够保证行动正确。生产级智能体需要所有这些能力，以及评估和人工控制。
对于企业买方而言，眼下的问题很实际：识别一个工作流，其中员工反复需要跨多个系统重建同一条决策链。
衡量当前的模型调用次数、延迟、错误率和审查工作量。然后测试持续维护的图谱是否改善了完整工作流，而非仅仅改善经过筛选的答案集。
Uvi 通过将分散记录转化为关于工作如何流动的结构化描述，为 AI 智能体提供企业上下文。它的未来取决于这种描述在演示结束后能否继续保持可信。
在让智能体基于组织记忆采取行动之前，请问三个问题：它能展示证据吗？它能遵守每一项权限吗？它能承认不确定性吗？
