案例:给企业 AI Agents 装上“长期记忆”和“企业上下文”:V7 如何用 Context Graph 跑通复杂商业工作流

企业智能体为什么总像第一天上班的新员工?V7 把散落文件整理成可追溯的 Context Graph,再让 Luna、Terra、Sol 与 Astra 分工完成从抽取到复杂推理的工作。

作者:OpenAI09-23 · 约 8 分钟
🎧 听播客版0:00 / --:--
0:00 / --:--

OpenAI 发布的案例研究展示了欧洲初创企业 V7 打造的企业级智能体平台 V7 Go。它要解决的不是“怎样再造一个更聪明的聊天机器人”,而是一个更具体的企业问题:怎样让 AI 知道公司内部发生过什么、不同文件里的实体怎样关联,以及一项结论究竟来自哪份材料。

V7 的答案可以概括成一条完整链路:先把散落的企业文件整理成带来源引用的 Context Graph,再让不同能力与成本档位的模型分工执行,最后把检索、推理、工具调用和审计串进同一条工作流。

  • 企业智能体的主要障碍常常不是不会推理,而是不知道哪份文件最新、不同系统里的名称是否指向同一实体,以及一项结论应追溯到哪份证据。
  • V7 预先抽取实体、关系、事实和引用:常见关系走 Context Graph,图谱信息不足时回到底层文档做 RAG;近期对话留在模型上下文,较早材料进入图谱按需取回。
  • 高通量抽取、复杂工具调用和极难图谱查询分别交给 Luna、Terra/Sol 与 Astra。V7 报告成本、错误率和复杂查询准确率均有改善。
  • 这套架构最适合跨文档关系密集、实体定义相对稳定、且每项结论必须回到原始证据的业务。普通问答库若用基础 RAG 已能解决,建图谱反而会增加维护成本。

1. 核心痛点:AI 容易“失忆”,也不懂公司的内情

在严肃的企业业务中,一位合格的资深分析师从来不会只看手头的一份 PDF。他知道某家被投企业去年剥离过核心子公司,知道三份看似矛盾的估值表中哪一份才是审计后的定稿,也知道不同业务系统里名称各异的部门其实由同一个人负责。这些维系业务运转的历史、关系和判断依据,就是企业的“制度记忆”。

通用大模型不会天然拥有这些记忆。企业报告、数据室、财务表格、邮件和内部系统散落各处;同一家机构可能有多种名称,同一个指标也可能存在多个版本。对金融、保险、房地产等行业而言,工作流中的检索准确性是不可妥协的刚性要求;智能体即使会推理,也无法自动知道哪些材料属于同一条业务链、哪个数字更新,以及一项判断应该引用什么证据。

如果没有结构化记忆,智能体在处理每个新任务时,都要重新搜索、阅读并拼接相关文件。这种每次请求都要重新发现上下文的方式会增加调用时间和 token 消耗,也可能漏掉藏在跨文件关系里的关键事实。

基础检索增强生成(RAG)可以按照语义相似度找出相关段落,超长上下文窗口也可以一次容纳更多材料,但真正困难的往往是关系型问题。例如,要判断某只基金投过的项目中哪些会受一项新规则影响,答案可能分别藏在基金台账、项目尽调报告和行业合规备忘录里。找到三个相关片段只是第一步,还必须确认其中的基金、项目和规则确实指向同一条业务链。

2. V7 的解法:用 Context Graph 补上企业记忆

V7 Go 的核心机制叫 Context Graph,即“上下文图谱”。它不是等用户提问后才临时翻找全部文件,而是在材料进入系统时就先整理其中的实体、关系、事实和来源。

企业接入 SharePoint、Google Drive 等云端存储后,每当新文件到达,V7 Go 会扫描文档,并依据预设的业务本体(Ontology,也就是业务认可的实体类别和关系规则)识别公司、基金、关键人物、合同条款和资产指标等本体实体。系统将提取出的每项事实连接并挂接到新记录或已有记录上,同时保留指向原始文档具体位置的引用证据。

[原始文档接入] (SharePoint / Google Drive)
       │
       ▼
[实体与事实抽取] (识别公司、人员、基金、条款、指标)
       │
       ├──────────────────────────────┐
       ▼                              ▼
[图谱直接查询]                 [底层原文 RAG 兜底]
(沿实体关系查询历史记录)         (图谱信息不足时检索原文档)
       │                              │
       └──────────────┬───────────────┘
                      ▼
            [生成带精准引用的业务结果]

智能体由此获得两条取数路径。常见的关系查询直接沿图谱寻找关联事实;如果结构化信息不足以回答细节问题,系统再回到底层原文做 RAG 检索。V7 称,图谱遍历的成本和速度相较长上下文方案具有数量级优势:实体消歧与关系连接提前完成,查询直接沿已知节点和边取数,避免了每次重新把大量文档塞进长上下文。

记忆本身也被分成两层:近期对话留在模型的即时上下文中,保证当前任务连续;较早的材料进入 Context Graph,需要时再按实体和关系取回。这样,长期记忆不必一直占据上下文窗口,旧信息也不需要在每次任务中从头搜索。

在针对企业异构数据检索连接的 HERB 基准测试中,V7 报告其检索系统超过官方基线 69%,不可回答问题上的幻觉减少 38%。这组结果主要说明:把企业信息的关系提前整理出来,可能同时改善检索和拒答表现。

3. OpenAI 多款模型“组团打怪”:不同难度交给不同模型

把企业记忆整理出来,还不等于复杂任务就能稳定完成。一次长流程往往由确定性代码、小模型交接、文件生成步骤、外部系统集成和模型步骤共同组成,可复用工作流甚至能横跨数百步。在这类长链条中,如果上游一次工具调用失败或理解出错,错误就会向后层层传播,导致后续步骤一起偏离,造成昂贵代价并破坏对系统的信任;但若所有步骤都调用最强、最贵的模型,成本又难以控制。

为了支持模型路由,V7 持续评测引用准确率、数百种文档类型的抽取质量、答案正确性、指令遵循、延迟、成本和真实企业工作流,以此将工序划分档位并路由模型:

  • GPT-5.6 Luna 负责高通量抽取。 V7 用它从数百万份文件中抽取信息并沉淀至图谱,报告准确率提高 11.6 个百分点,单文档处理成本相较 GPT-5.4 mini 降低 78%。
  • GPT-5.6 Terra 和 Sol 负责复杂流程。 多步推理、跨应用工具调用、人机对话和一些原本需要人类数十小时的复杂指令进入这一层。在 V7 的 Context Graph 基准中,GPT-5.6 Sol 的工具调用错误率为 0.2%,GPT-5.5 为 2.7%。V7 称 Terra 让团队删除了过去只为迁就弱模型而存在的中间步骤,节省数天交付工作,并经常让工作流第一版直接跑通。
  • GPT-6 Astra 负责最难的跨文档查询。 V7 用包含数千份复杂文档的数据建立四档难度测试;在最难一档中,Sol 得到 78%,Astra 达到 89%,两者在简单、中等和困难档都接近 100%。

这套分工把“模型越强越好”改成了“让合适的模型处理合适的步骤”。大量重复抽取由轻量模型优先控制单位成本,涉及工具和决策链的步骤优先保障稳定性以防错误向后传播,真正困难的图谱推理才调用最高档模型。在此过程中,系统清晰区分事实引用与每次运行的决策轨迹两类审计:前者保留事实在原始文档中的精确出处,后者完整记录每次运行中模型的决策轨迹。

在私募股权交易的初筛演示中,这种分工不再表现为一个单独的聊天框。系统读取机密信息备忘录(CIM),把财务指标、交易条款、管理团队和风险等内容放进结构化字段;工作流画布上的“竞品交易指标”“重大风险标志”“交易机会评估”等节点依次处理材料,最终评估按维度得分和指标生成结论,并引用相应来源文件。

官方 29.8 秒无声演示:结构化交易记录、分步分析面板与相互连接的工作流节点。它展示的是产品如何组织任务与证据。

V7 还把图谱能力接进企业已有工具。Context Graph 的查询和数据摄取能力被封装成 MCP 服务,客户可以从 ChatGPT 等兼容客户端查询图谱,也可以在 Codex 中通过 MCP 创建 V7 Go 工作流。V7 称,这项接入连同更简单的工作流设计,使一条中等长度工作流的搭建时间从约 1 小时缩短到约 20 分钟。

底层接口也从 Chat Completions API 转向 Responses API。V7 的测试显示,一些 PDF 密集工作流的 token 消耗减少约 5%,缓存可靠性有所改善;在最新运行框架中,包含多次外部调用的关键工作流最快缩短了 50% 的完成时间。在具体供应商经历方面,OpenAI 在数小时内便完成了其产能扩容需求,而 V7 使用的其他供应商通常需要数周。

4. 真实商业价值:时间、成本和错误率具体改善多少?

Context Graph 与模型路由最终要回答的,是企业是否真的少花时间、少出错、少消耗专家人力。OpenAI 的案例研究列出了三组客户结果:

  • 资产管理: 私募交易初筛提速 21 倍,从全天缩短到 15 分钟。
  • 金融服务: 审查时间从 100 多小时降到 10 小时以内,每项任务节省约 1.2 万美元专家成本。
  • 保险: 在引入历史理赔与既有保单知识后,处理差错相较人工基线降低 13.5%。

这些数字描述的是特定客户的工作流,不等于所有企业部署后都会得到同样结果。把技术基准和客户结果放在一起看,更容易理解每项数字回答的究竟是什么问题:

指标项目 V7 公布的表现 它回答的问题 使用时需要知道的条件
文档抽取成本 相比 GPT-5.4 mini 降低 78% Luna 是否更适合高通量文档处理 来自 V7 的文档处理负载
工具调用错误率 GPT-5.6 Sol 为 0.2%,GPT-5.5 为 2.7% 模型升级是否改善多步流程的工具稳定性 来自 V7 的 Context Graph 基准
工作流整体精度 V7 称 50–100 步工作流达到 99.9% 准确率 V7 是否把长流程作为整体质量对象管理 页面没有给出准确率的完整计算口径
复杂图谱查询 Astra 最难题得分 89%,Sol 为 78% 更强模型是否改善最复杂的跨文档查询 V7 自建四档难度测试,使用数千份文档
业务初筛提速 从全天降到 15 分钟,提速 21 倍 图谱工作流是否减少人工初筛时间 特定资产管理客户案例

这组结果说明,V7 的收益并非只来自更强模型。预先整理上下文减少了重复检索,模型路由控制了成本和错误,结构化工作流让每一步可以复用,来源引用则让结果能够回到原始材料审查。

5. 下一步:从“被动查询”走向“主动提醒”

当前的 Context Graph 主要在收到查询或工作流任务后提供记忆。V7 正在开发的下一步,是事件驱动的主动记忆:当图谱里的事实发生变化,系统自动触发工作流、标出矛盾,并提示哪些旧分析需要重做。

例如,一份基金报告被追溯重述后,系统可以找出仍在使用旧数字的分析并发出提醒。这样,企业记忆就不再只是“需要时去查的知识库”,还会成为持续检查业务状态的触发器。

这仍是 V7 描述的长期研发方向。它真正重要的地方,是把企业智能体的竞争重点从“部署多少个 Agent”转向“是否拥有可更新、可追溯、能驱动行动的业务上下文”。

什么企业值得采用:三个判断标准

Context Graph 并非所有企业 AI 项目的必选项。构建图谱需要定义实体和关系,也需要持续维护。是否值得做,可以从三个具体问题判断。

业务是否高度依赖跨文档关系?

如果需求主要是独立规章、操作手册或常见问答,基础的文档切片和向量 RAG 通常已经够用。只有当分析必须频繁串联多个系统和多个年份的实体关系,例如金融尽调、投资穿透或复杂保单理赔,预先整理图谱才更可能抵消建设成本。

企业是否有稳定的实体和关系定义?

图谱需要先知道什么是公司、基金、项目、条款和责任人,以及它们怎样关联。业务本体越稳定,抽取结果越容易检查和维护。如果术语和流程仍频繁变化,图谱中会不断产生重复或错误节点,反而可能误导后续推理。

结论是否必须回到原始证据?

在灵感生成或开放式摘要中,输出合理往往已经足够;在合规、财务、法务和核保等场景中,错误会直接影响业务判断。此时可以检查一个信号:审查人员能否从生成结论沿引用回到对应文档,并确认使用的是正确实体、正确版本和正确指标。做不到这一点,再整齐的图谱也很难成为可信的企业记忆。

实操带走包

滚动查看原始 Markdown,复制后可按团队实际系统与政策修改。

Markdown · 会员
正在载入 Markdown…
来源
How V7 gives AI agents institutional memoryOpenAI·2026-09-21·查看主材料
本站说明
产品机制、基准数字与客户结果来自 OpenAI 发布的 V7 案例研究;其中多数为 V7 自测或客户案例,页面未披露完整样本量与评测协议。
↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。