S&P Global Energy用Databricks Genie Agents和MCP把结构化数据变成对话式查询
S&P Global Energy将覆盖LNG、化工、原油等品类的结构化数据，通过每数据集一个Genie Agent、自动暴露为MCP服务器、再用FastMCP代理组合的方式，让外部客户的AI助手能用自然语言查询受治理的数据。
AI解读：S&P Global Energy想解决的不是“AI能不能查数据”，而是“谁能把数据上下文教给AI”。企业结构化数据分散在Databricks和多个外部来源，传统做法要么写脆弱的text-to-SQL管道，要么为每个问题造API，要么把数据导出到外部AI工具。这些路子的共同问题是：最懂数据的人（领域专家）不负责建访问层，每个新查询体验都要排工程队的期，上线以月计。
他们的做法是让领域专家在Databricks里按数据集分组创建Genie Agent，比如LNG下面拆出货、招标、停运、供需、净回值、价格等多个小智能体。专家不需要写代码，只填表列描述、示例查询、业务定义（例如“浮仓”指在低于某速度航行的船上闲置 3 天以上的货）。这一步决定了AI生成的SQL到底能不能信。
每个Genie Agent会自动变成一个Databricks托管的MCP服务器，只暴露查询和轮询两个工具，鉴权走Unity Catalog。跨组问题则用FastMCP代理把多个Genie MCP服务器组合成一个商品级别的复合端点，比如“Sabine Pass停运如何影响亚洲到岸溢价”会同时打到停运和货两个智能体，再由上层LLM路由和汇总。
对业务的直接影响是：以前上线一个新对话式数据体验需要完整开发周期，现在领域专家建好Genie Agent，MCP端点即刻存在，上线从天/周级缩短到天级；治理没有绕开Unity Catalog，原生表和联邦表都受同一套权限和审计约束；同一套MCP端点同时服务内部智能体、客户侧AI体验和外部客户自己的AI助手。
限制和边界在原文里写得很清楚：Genie Agent要窄而专，不能一个商品一个大智能体，更不能一个智能体包打天下；非Databricks数据先用Lakehouse Federation接进来，而不是新建ETL；准确率用Genie Agent Benchmarks持续测，包括同一问题的多种问法。这些是工程和治理约束，不是模型能力自动带来的。
S&P Global Energy在Databricks博客中披露，已将其覆盖LNG、化工、原油、成品油、天然气与电力等品类的结构化数据，通过Databricks Genie Agents和Model Context Protocol（MCP）对外开放，让外部客户的AI智能体可以用自然语言查询受治理的数据。
架构分三层：领域专家按数据集分组创建Genie Agent；每个Genie Agent自动暴露为Databricks托管的MCP服务器；再用基于FastMCP的代理把多个组级MCP服务器组合成商品级别的复合端点。
S&P Global Energy副总裁Priyanka John在博客中称，过去“需要一整个开发周期的事情现在只要几天，而且每个答案都留在我们的治理边界内”。
数据分散和传统访问方式的限制
S&P Global Energy的数据横跨Databricks和多个非Databricks来源，每个商品本身又是一个庞大的数据集家族。以LNG为例，包含设施规格、货物、停运、供需基本面、净回值、历史和预测价格以及合同；化工则覆盖产能、产量、开工率、贸易、按终端用途和衍生物划分的需求、库存变化以及国家和地区层面的供需平衡。
博客列举了三种常见桥接方式各自的问题：手工搭建text-to-SQL管道强大但脆弱， schema变化、列名歧义、业务指标定义（原文举例“什么算停运日”）都会变成工程任务；按用例定制API意味着每个新问题模式都需要新端点、新冲刺、新发布；把数据导出到外部AI工具则会复制数据、破坏新鲜度、脱离治理边界。
- 共同问题：最懂数据的领域专家和分析师不是构建访问层的人，每个洞察都要经过工程积压，新的对话式数据体验上线以月计。
- LNG下的Genie Agent示例：资产与合同、货物、招标、停运、供需、净回值、价格。
- 化工按组设置Genie Agent：产能、产量、开工率、贸易、按终端用途和衍生物划分的需求、库存变化、国家和地区供需平衡。
三层架构：专家策展、自动MCP服务器、FastMCP组合
第一层由领域专家操作，不需要写代码。如果表已经在Databricks里，直接通过Unity Catalog使用；如果数据在非Databricks来源，通过Lakehouse Federation连接器接入，不需要搬数据或重复管道，联邦表与原生表并列并继承同样的治理。专家把相关表分组，每个数据集组创建一个Genie Agent，而不是每个商品一个巨型智能体。
在每个智能体内部，专家补充表列描述、示例查询、高风险指标的受信资产和业务定义。原文给出的例子是：“浮仓定义为在低于某速度航行的船只上闲置 3 天或以上的货物”。博客称这是通用text-to-SQL方案会跳过、但决定用户是否信任答案的一步。
第二层是Databricks托管的MCP服务器。每个Genie Agent开箱即用，以https:///api/2.0/mcp/genie/{genie_space_id} 形式的端点暴露，不需要部署或托管。每个服务器只暴露两个工具：查询工具genie_query_space提交自然语言问题，响应工具genie_poll_response用同一对话和消息ID轮询结果，包括生成的SQL和结果集。鉴权由平台处理，权限继承Unity Catalog，Genie Agent或其背后的用户只能访问有权限的智能体和底层表。
第三层是FastMCP代理组合。真实业务问题经常跨组，例如“Sabine Pass最近停运如何影响亚洲到岸溢价”同时触及停运和货物两个Genie Agent；“石脑油价格如何影响化工生产利润”则跨成品油和化工。博客给出的做法是用FastMCP的代理和组合能力创建复合MCP端点，通常每个商品一个，把该商品下组级Genie MCP服务器挂载到同一个服务器后面并加命名空间前缀，比如cargo、outages、netbacks。上层LLM决定把问题路由到哪个组Genie，或者把一个跨组问题扇出到多个再综合结果。
- 托管MCP端点格式：https:///api/2.0/mcp/genie/{genie_space_id}。
- 两个工具：genie_query_space提交问题，genie_poll_response用对话和消息ID轮询完整响应。
- FastMCP组合示意：cargo、outages、netbacks等组级代理挂载到lng-composite，再按化工、原油、成品油、煤炭等重复同样模式。
上线时间、治理和外部客户接入
博客称，过去搭建一个新的对话式数据体验需要完整开发周期，包括需求、API设计、text-to-SQL工程、测试、部署；现在启动一个新数据集组或整个商品，意味着领域专家创建并策展对应的Genie Agent，MCP端点在智能体创建时即存在。工程精力从构建定制访问层转向维护一层薄的可复用代理。
治理方面，每个智能体提出的问题都经过Unity Catalog权限，在受治理的表（原生或联邦）上运行，并具有完整可审计性。博客强调，让数据对AI可用不等于让数据脱离管控。
因为MCP是开放标准，同一套复合端点同时服务内部智能体、面向客户的AI体验，以及外部客户——外部客户可以将自己兼容MCP的智能体和助手直接连接到受治理的S&P Global Energy数据。博客的原话是：桥建一次，每个MCP客户端，无论内部还是外部，都可以过。
回答质量用Genie Agent Benchmarks度量。领域专家可以定义模拟用户实际提问方式的测试问题，包括同一问题的多种问法，并自动对已验证答案评分。在指令、数据或业务逻辑任何调整之后可以重新运行基准测试，维持准确率。
- 变化：领域专家从提需求的人变成发布者，工程转向维护一层可复用代理。
- 治理：所有问题走Unity Catalog权限，无需维护平行的安全栈。
- 度量：标题里提到“测量信任，不只测量延迟”，S&P Global Energy跟踪策展期间专家认可Genie生成SQL的频率，作为业务用户是否会采用的领先指标。
博客列出的实践约束
博客在结尾列出了几条团队经验：Genie Agent要保持窄而精，一个智能体覆盖一个特定数据域并配清晰指令和示例查询时答案质量最高，不要每个商品建一个智能体，更不要一个智能体包打天下，跨数据域应该在MCP层组合。
非Databricks来源先用Lakehouse Federation，而不是新建ETL，热门路径以后可以再物化。语义层投入要把列描述、业务定义和受信示例查询当产品级工作，这是领域专家值得花的时间。组合工具要清晰命名空间，当智能体看到多个组Genie的工具时，cargo_和outages_这样的前缀帮助LLM正确路由。
- Genie Agent要窄而专，避免一个商品一个巨型智能体。
- 非Databricks数据先用联Federation，不要新建ETL。
- 语义层投入是领域专家的时间，不是可选装饰。
- 复合工具加清晰前缀帮助LLM路由；度量信任而不只度量延迟。