S&P Global 用 Databricks Genie+MCP 实现数据对话

S&P Global 的目标是从根本上改善客户在我们的数据和研究产品中发现和消费洞察的方式。虽然 AI 驱动的搜索和摘要很重要，但更大的商业价值来自于通过自然语言访问可信数据、更丰富的跨大宗商品分析，以及连接传统上存在于不同业务线中的洞察，从而实现更快的决策。AI 智能体帮助客户发现关系、更高效地生成研究，并从比以往更广泛的信息集中获取可付诸行动的智能。——Priyanka John，S&P Global Energy 副总裁

如果你曾尝试将大型、复杂的结构化数据资产提供给 AI 智能体和助手使用，你很可能遇到与我们相同的障碍：智能体的能力取决于它们所能触及的上下文，而企业数据很少存在于一个整洁、文档齐全的地方。

在S&P Global Energy，我们的数据涵盖化学品、原油、精炼产品、天然气与电力、液化天然气（LNG）等——而且每种大宗商品本身就是一个丰富的数据集家族。仅 LNG 就包括设施规格、货物、停产、供需基本面、净回值、历史与预测价格以及合同。化学品涵盖产能、生产、利用率、贸易、按终端用途和衍生物划分的需求、库存变化以及国家和区域层面的供需平衡。我们的其他大宗商品也遵循类似模式。这些数据分布在 Databricks 和多个非 Databricks 数据源中。

我们的目标雄心勃勃但表述简单：通过模型上下文协议（MCP）使我们整个结构化数据资产可供 AI 智能体外部消费——这样我们客户的智能体和助手，以及我们自己的智能体和助手，都可以用自然语言提问并获得可信、受治理的答案。

我们评估了几种方法。对我们来说效果最好的，且优势明显的是Databricks Genie Agents，以托管MCP 服务器的形式暴露，并通过 MCP 代理层组合成特定领域的捆绑包。

在本文中，你将了解到：

• 我们的领域专家（SME）如何策划聚焦的 Genie Agents——每种大宗商品内每个数据集组一个——而无需编写一行智能体代码。
• 每个 Genie Agent 如何自动成为一个受治理的 MCP 服务器，随时可接入任何兼容 MCP 的客户端或智能体。
• 我们如何使用基于 FastMCP 的代理将多个 Genie MCP 服务器组合成复合端点，以支持跨领域问题。
• 为什么这种架构大大缩短了我们 AI 驱动数据产品的上市时间。

Genie Agents 让我们的领域专家能够直接将他们对数据的知识产品化。过去需要一个完整开发周期的工作现在只需几天，而且每个答案都留在我们的治理边界内。——Priyanka John，S&P Global Energy 副总裁

挑战：结构化数据易于存储，却难以对话

大型语言模型在对话和推理方面非常出色，但除非你为数据搭建一座桥梁，否则它们无法回答关于你数据的问题。对于结构化企业数据，这座桥梁历来意味着以下方式之一：

1. 手工构建的 text-to-SQL 管道——功能强大，但很脆弱。每一次模式变更、每一个含糊的列名、每一个特定领域的指标定义（“什么算作停产日？”）都会变成一项工程任务。
2. 按用例定制的 API——每一种新的问题模式都需要一个新端点、一个新冲刺、一个新版本。
3. 将数据导出到外部 AI 工具——这会复制数据、破坏新鲜度，并跨出你的治理边界。

这些方法都有同一个问题：最了解数据的人——我们的领域专家和分析师——并不是构建访问层的人。每个洞察都必须经过工程积压。我们推出一种新对话式数据体验的上市时间以月计。

我们需要一种方法，让领域专家能够直接策划并发布数据的对话式访问，让工程团队能够标准化智能体的连接方式，同时保持治理集中化。这正是 Genie Agents 加 MCP 为我们带来的。

架构：Genie Agents 作为语义层，MCP 作为契约

我们的架构有三层，每一层都由最适合的人拥有。上图展示了端到端流程——包括 S&P Global Energy 网络内部的内容以及外部客户端环境中的内容。

第 1 层：领域专家为每个数据集组策划一个 Genie Agent

魔力从这里开始，而且值得注意的是，它不需要任何代码。

我们的领域专家首先选择与业务领域相关的表：

• 如果表已经位于 Databricks 中，他们通过 Unity Catalog 直接使用它们。
• 如果数据位于非 Databricks 数据源中，他们通过Lakehouse Federation连接器将其引入——无需数据移动，无需重复管道。联邦表与原生表一起出现，并继承相同的治理。

然后他们将相关的表分组，并创建每个数据集组一个 Genie Agent——而不是每种大宗商品一个巨型智能体。大宗商品的每个子类别都成为自己聚焦的 Genie Agent。例如，在 LNG 内部：

• LNG 资产与合同 Genie Agent——资产、运营商、产能预测和长期合同
• LNG 货物 Genie Agent——货物跟踪、租船协议、始发地/目的地和商业条款
• LNG 招标 Genie Agent——包含发行方、数量和交付窗口的招标
• LNG 停产 Genie Agent——停产和维护事件及其产能影响
• LNG 供需 Genie Agent——包含区域拆分和情景历史的基本面
• LNG 净回值 Genie Agent——来自枢纽价格、运费、蒸发气和损耗的净回值
• LNG 价格 Genie Agent——历史与预测价格曲线

所有其他大宗商品也遵循相同模式，拥有自己的子类别。例如，化学品有组级别的 Genie Agents 用于产能、产量、产能利用率、贸易、按最终用途和按衍生品的需求、库存变化，以及国家和区域层面的供需平衡表；原油、成品油以及天然气与电力也以类似方式组织。其结果是一支由范围界定清晰的小型 Genie Agent 组成的舰队，而不是少数几个庞大而彼此割裂的 AI 工具。

在每个 agent 内部，SME 补充了让 text-to-SQL 在现实世界中真正可用的上下文：表和列的描述、示例查询、用于高风险指标的受信任资产，以及业务定义（例如“浮仓被定义为在船舶以低于某一阈值速度航行时滞留 3 天或以上的货物”）。这一步正是通用 text-to-SQL 解决方案所跳过的——也正是决定用户是否信任答案的那一步。

关键的组织层面的洞见：策展成为一项领域活动，而非工程活动。 在 LNG 语境下知道“浮仓”含义的人，正是教 Genie 它含义的人。

第 2 层：每个 Genie Agent 自动就是一个 MCP 服务器

Databricks 在这里替我们承担了繁重的工作。每个 Genie Agent 开箱即被暴露为一个 Databricks 托管的 MCP 服务器，端点形式如下：

https://<workspace-hostname>/api/2.0/mcp/genie/{genie_space_id}

无需部署任何东西，也无需托管任何东西。每个服务器暴露一组小巧、干净的工具接口——本质上每个 agent 两个工具：

1. 一个查询工具（genie_query_space）——agent 向该 agent 提交自然语言问题。
2. 一个响应工具（genie_poll_response）——agent 使用相同的会话和消息 ID 轮询，以在响应就绪后检索完整响应，包括生成的 SQL 和结果集。

这种“两个工具、先问后轮询”的模式非常适合 agentic 工作负载：问题针对 SQL 仓库异步运行，agent 使用查询工具返回的会话和消息 ID 进行轮询，直到响应就绪。

同样重要的是，这些托管服务器受 Unity Catalog 治理。一个 Genie Agent——或其背后的用户——只能访问他们有权查看的 agents 和底层表。身份验证由平台处理。我们无需围绕 AI 访问构建安全层；我们继承了已有的安全层。

第 3 层：使用 FastMCP 代理将组级 Genie Agents 组合为大宗商品包

每个数据集组一个 Genie Agent 可使每个 agent 保持专注和准确。但真实的业务问题经常跨越多个组：“Sabine Pass 最近的停工如何影响了运往亚洲的货物溢价？”同时涉及 Outages 和 Cargo 两个 Genie Agent；而跨大宗商品的问题，如“石脑油价格如何影响化工生产利润率？”，则触及 Refined Products 和 Chemicals 两个 Genie Agent。

我们没有构建一个巨型 agent（这会降低答案质量），也没有强制每个客户端配置十几个独立服务器，而是使用 FastMCP 的代理和组合能力来创建复合 MCP 端点——通常每种大宗商品一个，将那种大宗商品的组级 Genie MCP 服务器挂载在一个具有命名空间工具的单一服务器之后。更高层级的复合端点可以以同样方式捆绑多种大宗商品：

from fastmcp import FastMCP

# 每个组级 Genie Agent 都是 Databricks 上的一个托管 MCP 服务器 cargo = FastMCP.as_proxy(genie_mcp_config(“lng_cargo_agent_id”), name=“cargo”) outages = FastMCP.as_proxy(genie_mcp_config(“lng_outages_agent_id”), name=“outages”) netbacks = FastMCP.as_proxy(genie_mcp_config(“lng_netbacks_agent_id”), name=“netbacks”)

# 将组级 Genies 组合为一个大宗商品包 lng = FastMCP(name=“lng-composite”) lng.mount(cargo, prefix=“cargo”) lng.mount(outages, prefix=“outages”) lng.mount(netbacks, prefix=“netbacks”)

# 同样的模式在 Chemicals、Crude Oil、Refined Products、Coal…… 中重复

（示意性代码片段——请根据你的 FastMCP 版本和认证设置进行调整。）

结果：agent 连接一个每种大宗商品的复合端点，并看到一组经过策展的组级工具——cargo_genie_query_agent、outages_genie_query_agent、netbacks_genie_query_agent 等等，每个都配有其对应的 genie_poll_response。agent 的 LLM 决定将问题路由到哪个组级 Genie，或将一个跨组问题扇出到多个，然后综合结果。

这让我们兼得二者之长：底层是范围窄、高精度的组级 Genie Agents，顶层则是广泛覆盖大宗商品和整个资产组合的对话式访问。

业务层面发生了什么变化

对我们的业务利益相关者而言，上述技术细节转化为几个非常切实的成果。

上市时间大幅缩短。 此前，搭建一个新的对话式数据体验意味着一个完整的开发周期：需求、API 设计、text-to-SQL 工程、测试、部署。采用这一架构后，启动一个新的数据集组——或一整个大宗商品——只需一名 SME 创建并策展相应的 Genie Agents——agent 一存在，MCP 端点就存在。

SME 成为发布者，而非请求者。 了解 LNG 货物或化工供需平衡的领域专家不再需要提交工单来让自己的数据被暴露；他们策展一个 Genie Agent，它就上线了。工程投入从构建定制访问层转向维护一个薄而可复用的代理层。

治理内建。 agent 提出的每个问题都经过 Unity Catalog 权限，在受治理的表（原生或联合）上运行，并具备完整可审计性。让数据可供 AI 使用，并不意味着让数据脱离我们的控制范围。

一种集成模式，多种消费者——公司内外皆然。 由于 MCP 是一个开放标准，相同的复合端点既服务于我们的内部 agents、面向客户的 AI 体验，也——至关重要地——服务于我们的外部客户，他们可以将自己的 MCP 兼容 agents 和助手直接连接到受治理的 S&P Global Energy 数据。我们只建了一次桥；每个 MCP 客户端，无论内部还是外部，都可以跨过它。

答案质量是可衡量的，并且始终保持如此。在一个定价、供应和合同数据驱动真实决策的领域中，用户需要信任每一个回复和计算。Genie Agent Benchmarks 为我们的 SME 提供了一种内置方式，让他们能够定义与用户实际提问方式相匹配的测试问题（包括同一问题的多种表述），并针对经过验证的答案自动为 agent 的准确性打分。同样重要的是，在对指令、数据或业务逻辑进行任何优化之后，基准测试都可以重新运行，因此准确性能够长期保持。其结果是形成一个高效的持续质量循环：整理、基准测试、改进、再基准测试，以确保我们的 agent 随着数据和客户问题的演变始终保持准确。

经验教训与最佳实践

以下是我们在这一历程中得出的一些实用经验，供考虑走类似道路的团队参考：

1. 让 Genie Agents 保持范围狭窄且精心整理。 当一个 agent 以清晰的指令和示例查询覆盖一个特定的数据领域时，答案质量最高。不要经不住诱惑去为每种大宗商品构建一个 agent——更糟的是，构建一个统治一切的 agent。相反，应在 MCP 层将多个数据领域汇聚在一起。
2. 在构建管道之前先使用 Lakehouse Federation。 对于非 Databricks 来源，federation 让我们无需任何新的 ETL 作业就实现了“对话式”能力。你之后随时可以将热路径物化。
3. 投资于语义层。 列描述、业务定义和可信的示例查询，正是区分演示与产品的关键。这是值得投入 SME 时间的地方。
4. 为你的组合工具清晰划分命名空间。 当一个 agent 看到来自许多分组 Genie 的工具时，像 cargo_ 和 outages_ 这样的前缀能帮助 LLM 正确路由问题。
5. 衡量信任，而不仅仅是延迟。 我们在整理过程中跟踪了 SME 对 Genie 生成的 SQL 的认同频率——这是判断业务用户是否会采用这一体验的最佳领先指标。

结论

我们的目标是让我们整个结构化数据资产——涵盖 LNG、化学品、原油、成品油、天然气与电力等——可供 AI agents 使用：安全、准确且快速。以 Databricks Genie Agents 作为由 SME 整理的语义层，以托管 MCP 服务器作为零部署的集成契约，并以 FastMCP 代理进行跨领域组合，我们正是实现了这一点：

• 速度： 新的对话式数据领域可在数天内上线，而不是按开发周期计算——极大加快了我们的上市时间。
• 准确性： 领域范围明确、由 SME 整理的 agents 提供业务用户真正信任的答案。
• 治理： Unity Catalog 保护每一个问题，无论是原生数据还是联邦数据，无需维护平行的安全栈。
• 开放性： 一座 MCP 标准桥梁服务于每一个当前和未来的 agent，无论是内部还是外部。

然而，更深层的转变是组织层面的：理解数据的人，如今也成了发布数据访问权限的人。这一点，比任何单一技术都更能将我们的结构化数据从用户需要查询的东西，转变为用户可以直接与之对话的东西。