Databricks 于 2026 年 9 月 28 日发布 Genie One 落地手册：分四阶段推广，先文档化 25 到 50 个已知答案问题，再试点。 这份手册落在企业级 AI 与数据系统在真实客户环境里落地交付的语义层与推广这一段：把一个通用的数据智能体变成业务部门默认使用的工具，靠的不是模型能力，而是语义层治理与分阶段推广。前置部署 Forward Deployed Engineer（FDE）在客户现场最常被问的正是这件事：一个团队的试点跑通了，为什么推广到第三个部门就散架。 文章由 Josh Rosenberg 署名，2026 年 9 月 28 日 16:30 UTC 发布在 Databricks 官方博客，归类为 Best Practices，正文里链到 15 个 Databricks 官方文档页，也就是说每一个配置项都能找到对应的产品文档，不是纯经验谈。 需要说明与本站 2026 年 9 月 29 日那条 Databricks 内部新模型 Day 1 上线打法的差异：那条讲的是给自己员工放开前沿模型、按人均预算限流、三天内定去留；这篇讲的是把 Genie One 交付给业务用户，重点是语义层、分阶段推广与治理闸门。两篇没有重复的数字与步骤，看过前作的不必跳过这篇。 一、先把落地对象拆成四个组件，权重随阶段变化 Genie One 是业务用户的主入口：用户用自然语言提问、拿到带来源引用的答案，并把后面多步的工作接着跑下去。Genie Agents 是按域限定的智能体，例如一个限定在合同分析的智能体，可以一次把 PDF 里的续约日期抽出来、与营收表做连接、标出有风险的客户。 Genie Ontology 把业务术语、指标与关系映射成一张活的图谱，并按来源权威度加权。其中最关键的地面真值概念通过 metric views、Pages 与 Domains 来治理，剩下的由 Genie 自己推断，覆盖那些没人手去逐条文档化的角落。 Unity Catalog 是治理底座，在查询时强制执行权限、掩码与血缘（lineage），并留下审计记录，用户与智能体只能访问被授权的数据。 先说前置条件：手册假定企业已经有 Unity Catalog 治理栈、并且语义层有一个能拍板的 owner。如果客户环境是遗留数仓加硬编码报表堆出来的，Phase 0 的工作量会完全不同，手册没有覆盖这种起点。 二、Phase 0：1 到 2 周，先把语义层与治理闸门建起来 Phase 0 只有一个目标：证明数据与洞察确实可以通过 Genie 被访问到。原文的说法是在这里投一周，能换回长期的顺利。 第一步是选一个团队，加一组明确的问题。判据是这个团队有一个反复发生、当下就在痛的诉求。原文的场景是一个区域销售总监想知道东北区（Northeast）的管道本季度为什么发软，示例团队是销售运营，问题集是管道健康度：漏斗里有什么、什么在移动、什么有风险。 第二步是定义语义层，顺序不能反。Domains 先建，因为 Pages 必须归属于某个 Domain，不先建 Domain 会被直接卡住。Domains 是按业务用途组织资产的方式，建一个 Sales Ops 域，机会表、管道看板与 Genie Agents 就都放在用户会去找的地方。 第三步是 metric views，覆盖 10 到 20 个「人们会争论的数字」：bookings、管道覆盖率、赢单率、阶段转化率。度量只写一次，用户查询时仍可按销售、区域或季度切片，这样所有人取的是同一定义，而不是某个看板里硬编码的那一份。 第四步是 Pages，用来解释这些数字背后的概念。一个「合格机会」的 Page 里放定义、人们叫它的其他名字，以及它引用的资产。Genie One 会先去找这个 Page 而不是猜，并且在答案里引用它，任何人都能去核对。 第五步是给每个资产指定 owner。每个目录资产、每个本体片段、每个智能体都要能追溯到人，或者一个有真实受理路径的团队。原文点名了失败模式：所有权只写在纸面上；定义漂移（definition drift）没有修复通道。 第六步是治理与可观测，这一段是全文最可直接照抄的配置清单：账号级开通试点用户、工作区级授予 Consumer access entitlement、通过组授予资产权限（例如 metric views 背后的 Unity Catalog 对象的 SELECT 权限）、一个 SQL warehouse 的 CAN USE、列掩码（column masking）确认、审计日志开启、Ontology Snippets 打开、Unity Gateway 用量与成本可见性打开。作者给的理由很具体：这些事在 5 个用户的时候做最省事，不要等到 500 个用户。 第七步是定义什么叫「好」。做法是记录 25 到 50 个团队真实会问的问题，并附上已知正确答案。原文的销售运营示例是「Q3 我的覆盖率是多少」「哪些单子滑出了本季度」「EMEA 的赢单率与去年相比如何」。原文的判断很硬：你自己答不出来，就没有资格给 Genie 的答案打分。 第八步是在试点前、以及语义层每次变更之后各打一次分。原文有一句关键的话：失分点才是有价值的部分，因为它们指向语义定义的缺口。Genie 交回一个看起来不对的覆盖率比值时，原因通常不是模型，而是没有人把管道覆盖率定义成 metric view，于是 Genie 用一个合理但错误的东西把空补上了。每个失分点都是下一个该治理的对象。 前置部署 Forward Deployed Engineer（FDE）可以直接把这一步变成合同里的交付项：在 SOW 里写明客户要提供一份带已知正确答案的问题集，否则验收时会陷入「谁说了算」的争论。 三、Phase 1：4 到 6 周，用三条行为信号决定能不能扩张 Phase 1 的目标是把一个域里 Genie Agents 的回答做到可信任。动作有三条：招 5 到 10 名愿意说真话的试点用户；每周跑一次评估；记录每一个错误答案与每一句「我不知道」，然后去修根因，通常是缺一个定义、列名有歧义、或者本体里有缺口。 退出标准（exit criteria）必须提前写死。原文给了三条要观察的信号：准确率稳定在一个你敢拿来押真实决策的门槛上；试点用户在没有被要求的情况下主动选择 Genie 而不是老流程；定义修复的 backlog 在缩小而不是在变大。 原文认为最清晰的信号是行为层面的：某个试点用户被同事问到问题时，转发了 Genie 的回答，而不是去提交一个取数需求。这条信号比任何满意度打分都硬，也最容易在周会上被验证。 四、Phase 2：下一个季度，扩张靠提升共享定义而不是复制配置 Phase 2 的目标是证明智能体能扩到第一个试点之外。做法是加 2 到 3 个相邻的域，每个域自带语义、owner 与评估集，直接复用 Phase 1 的模板。 扩张的第一件事是把共享定义提升进本体，让 revenue 与 active customer 在每个智能体那里是同一个意思；只属于某个团队的定义留在自己的域里。 扩张必须过一次轻量评审：新域只有在 owner 过了评估门槛、并且通过了覆盖权限、掩码与敏感列的治理检查之后才上线。原文特意强调「轻量」，因为重流程会把扩张拖死。 防漂移是这一段最实用的部分。给每个 Page 指定 owner 与评审节奏，并且主动评审 metric view 的变更，而不是事后才发现。原文给出了一句可以直接背下来的判断：一个与源查询分叉的定义不是产生一个错误答案，它会在所有引用这个定义的地方传播错误答案。 另一件事是建社区：一个专门的 Slack 频道、每月的 office hours、一份「怎么问出好问题」的短指南。原文的判断是采纳靠同事说「这个能用」传播，公开频道是让这件事被看见的最省力方式。 前置部署 Forward Deployed Engineer（FDE）在客户现场做扩张时，最容易漏掉的是新域上线前的治理检查——权限、掩码、敏感列三项缺一项，后面每加一个域都要还一次债。 五、Phase 3：再往后 1 到 2 个季度，把它变成组织默认的 AI coworker Phase 3 的三个动作：账号级开通 Genie One 访问，让用户跨域只有一个 AI coworker，必要时跨工作区；打开自动身份管理（automatic identity management），向企业身份提供方里已有的组授权，用户首次登录就已经就位；给每个对话加上工作区级 instructions，规定聊天该怎么回答。 所有权要联邦化（federate ownership）：中央平台团队管本体、标准与护栏，域团队管自己的智能体与定义。原文对两个极端都有判断：全部集中在中央会产生排队，什么都不标准会产生互相矛盾的智能体，而矛盾的智能体会侵蚀信任。 治理要延伸到工具面。Unity Gateway 把治理从数据扩展到 Genie One 使用的工具：MCP server 变成可以授权的 securables、工具过滤（tool filtering）收窄 Genie 能调用的范围、服务策略（service policies）检查进去和回来的内容。 最后一件事是在用户已经在的地方出现：打开 iOS 与 Android 应用让用户在路上聊；如果团队在 Slack、Teams、Excel 或 Google Sheets 里工作，把 Genie 嵌进去；如果团队已经标准化在另一个智能体里，用 Genie MCP App 让它继续吃到 Genie Ontology。 六、时间线与按证据推进 原文给出的时间线是：Phase 0 用 1 到 2 周，Phase 1 试点用 4 到 6 周，Phase 2 扩张放在下一个季度，Phase 3 全组织放在之后的一到两个季度。原文明确说不要按日历推进，要等证据说可以了再走；如果试点需要更多时间理清定义，就把多出来的时间投到定义上，而不是硬推进度。 七、作者承认的局限与我方补充的局限 作者承认的第一条局限是反向的：原文把「第一周就上十几个数据域、四个团队有四套 active customer 定义、语义层没有具名 owner、没有核对答案正确性的机制」直接列为会失败的做法，但它没有给出踩了这些坑之后如何回退。 作者承认的第二条局限更隐性：全文没有给出任何准确率、延迟或成本数字。三条退出标准全部是定性的，「你敢押真实决策的门槛」没有可核对的基线，两个团队照同一份手册做，很可能得出完全不同的判定。 我方补充的第一条局限是全文仅有的量化建议：10 到 20 个指标、25 到 50 个问题、5 到 10 个试点用户、1 到 2 周与 4 到 6 周的阶段时长。手册没有解释这些数字从哪里来，也没有说明团队规模或域数量变化后该怎么缩放。 我方补充的第二条局限是整套流程隐含绑定 Databricks 的自有组件：Genie One、Genie Ontology、Unity Catalog、Unity Gateway。可迁移的只有阶段划分、退出标准结构与治理闸门的设计，具体配置项换栈即失效。 我方补充的第三条局限是存量环境成本没算：对已有存量报表与既有 BI 语义层的企业，Phase 0 的 1 到 2 周大概率不够，单是把 10 到 20 个「争论中的指标」的所有权盘清楚，就常常超过两周。手册是厂商视角的方法论，天然偏向先治理、后扩张。 八、实用结论：该行动的是谁、怎么做、什么时候别做 该行动的是两类人。第一类是正在把智能体交付给业务部门的 FDE（前置部署 Forward Deployed Engineer）与交付架构师，第二类是企业内部的数据平台负责人，他们要回答「试点跑通了，为什么推广不动」。 最小可执行版本可以压缩成五步。第一步只选一个团队与一组问题集，问题不超过 50 个，且每个问题都有已知答案；第二步先建 Domain，再建 metric views，最后建 Pages，顺序反了会被 Pages 的归属要求卡住；第三步在 5 个用户规模上把权限、列掩码（column masking）、审计日志、Ontology Snippets 与 Unity Gateway 成本可见性一次配齐；第四步招 5 到 10 名试点用户，每周评估，记录错误答案与「我不知道」；第五步在写死退出标准之后再决定是否扩到相邻的 2 到 3 个域。 验收门槛建议直接抄原文的三条行为信号，并把它写成可以判定的条款：准确率在一个季度内不掉；试点用户在未被要求时主动使用；定义修复 backlog 连续两周净减少。三条同时满足再进下一个阶段。 回滚与退出方式有五条，都不需要重做架构。一是权限面小：试点用户在账号级开通、权限通过组授予，收回时只需调整组成员或撤销 Consumer access entitlement。二是定义层：语义层任何变更后重跑那次评分，用评分结果决定是回退定义还是继续。三是漂移止损：每个 Page 有 owner 与评审节奏，主动评审 metric view 变更。四是工具面：Phase 3 的 MCP server 是 securable，配合工具过滤与服务策略可以单独关掉一个 server 而不影响其他。五是节奏面：Phase 1 三条退出标准任一不达标就不要进 Phase 2，把时间投回定义治理。 适用条件也要写清楚：客户已经有统一的身份提供方并且能按组授权；语义层有一个能拍板的 owner；数据资产在同一个治理目录下。缺任何一条，先补这一条，再谈分阶段推广。 原始来源： - https://www.databricks.com/blog/how-roll-out-genie-one-step-step-enterprise-playbook - https://docs.databricks.com/aws/en/genie/genie-ontology - https://docs.databricks.com/aws/en/uc-semantics/domains - https://docs.databricks.com/aws/en/ai-gateway/budgets - https://github.com/pierpaolo28/Awesome-FDE-Roadmap