Home

1. 核心理念：把企业看作一个会学习的 Agent

如果把整个企业抽象成一个巨型 Agent，它的运转应当是一个闭环，而不是一条从输入到执行的单向流水线。核心由五个功能模块加一个贯穿全局的编排 / 治理层构成，对应 Agent 的经典循环：感知 → 记忆 → 推理 → 行动 → 学习。

关键判断：单向链只是自动化；只有加上⑤这条回流线，企业才真正成为一个会学习、能进化的 Agent。 这是本架构区别于普通”数据自动化平台”的根本。

六个组成部分一览

两个层级：Agent 单元 vs Agent 网络

“企业 = 一个 Agent”是有用的思维起点，但真实企业更像一个多 Agent 系统——财务、供应链、客服、风控、市场……每个领域都是一个独立 Agent，各自拥有自己的①~⑤。因此需明确区分两层，避免落地时颗粒度混乱：

• 微观层（Agent 单元）：本文第 2–7 节描述的五模块 + 编排层，刻画单个领域 Agent 的内部构造。
• 宏观层（Agent 网络）：多个领域 Agent 之间的协作、任务分派、共享知识与统一治理。

同一套五模块框架在两层都成立——宏观层可视为”由 Agent 组成的 Agent”。这正是这套抽象的价值：可递归、可扩展。

宏观演进：面向多部门的域隔离与能力契约（Domain Federation）

当企业膨胀至数十个目标高度独立的部门时，宏观层不能靠「再加几个硬编码路由」扩容，而应走 域驱动（Domain-Driven）联邦：

1. 能力契约（Capability Contract）：每个部门 Agent 暴露标准的输入/输出协议与能力声明（类比 OpenAPI / MCP Tools）。跨部门协同按契约调度，而不是写死「找某某部门的某某 Job」。
2. 联邦治理（Federated Governance）：各域保持目标与执行自治，同时共享中央编排层的安全门禁、成本配额、出口管控与基础血缘——去中心化敏捷执行，中心化风控与安全。

人员路由（组织图 → 送对人）与能力路由（契约 → 调对 Agent）必须分开，详见 §5.2。域内学习可以快；跨域契约与全局安全仍走中央闸门，详见 §6.5。

---

2. 模块① 动态信息输入（感知）

2.1 两大数据形态

所有持续输入闭环的信息，按处理方式大致分两类。边界确有模糊地带（链上数据、社交网络本身是半结构化的），但作为工作切分足够用。

结构化数据——可落表、可打 tag、可分类查询：

非结构化数据——更多是”企业上下文（Context）“，难以直接落表：企业年度/季度 OKR 与业务规划、各业务部门运转信息、新产品/功能信息、企业内项目进度、竞争对手信息、外部宏观社会信息等。其中，时效性强、不宜预先入湖的公开外部信息，也可作为感知侧补充通道（落地层对应 Genie Code Web Search 等实时检索能力），与已入湖的企业 Context 区分置信度与溯源。

两类数据价值密度不同：结构化数据回答”发生了什么”，非结构化上下文回答”为什么、在什么背景下”。前者驱动实时反应，后者决定判断的准确性。

2.2 入湖与组织方式

结构化数据相对好处理：落成不同数据库/数据表，赋予不同 tag 分类，并区分流式（埋点、交易需即时反应）与批式（周期汇总）两条路径入湖。

非结构化数据（企业 Context）是难点，也是本模块设计核心。思路是用拓扑 / 图空间而非平表来组织：把每条上下文当作网状结构中的一个节点，节点间以语义与引用关系连边，再用权威性评分加权。这一步可直接借助 Databricks 的 OntoRank 算法（Genie Ontology 背后的排序算法）。

关于 OntoRank 的两点澄清：

1. 它评估的是”权威性 / 可信度”而非狭义的数据质量。 OntoRank 类比 PageRank，但排的是企业异构资产（代码、文档、结构化表、非结构化文件）的权威分，信号包括资产所有者可信度、使用广度、与已认证资产的关联、时效性等。它回答”哪条定义最可信、最该被 Agent 采纳”，与数据完整性/准确性意义上的”质量”互补而非等同。
2. 组织结构 OntoRank 已部分内建。 它本身就把组织图作为权威性信号之一（谁访问什么、频率、组织角色）。因此真正的增量维度是”工作流程结构”——一条信息在什么流程节点产生、流向哪个决策环节。把它作为附加信号注入图空间，能让节点空间从”组织维”升到”组织 × 流程”的高维，更贴合企业真实运转结构。

2.3 一条收敛线索

结构化表与非结构化上下文，最终会汇入同一层本体（Ontology）/ 知识图谱（Databricks 的 Ontobricks 会把 Unity Catalog 的结构化表也物化成图节点）。也就是说，本模块”两类数据”的区分是采集与处理阶段的区分；到了模块②，它们统一成一张受治理、可检索的图。这条收敛线索把模块①接向模块②。

没有这一层会怎样：Agent 只能靠通用常识和过时快照做判断，业务信号严重滞后、决策脱离现实；各部门数据各自为政、重复采集、口径互相打架，且没人说得清数据从哪来。

---

3. 模块② 知识与记忆（记忆）

3.1 本质：从”输入”到”可信知识”的提炼层

本模块不产生新的业务 / 生产数据——它对模块①的动态输入做提炼 + 人工复核的精确提取，把”海量原始数据”转化为”可被 Agent 信任、可检索的知识”。用 Agent 的话说，这是它的长期记忆：模块①解决”接进来”，模块②解决”记下来、且记得对”。

一点澄清：Agent 运转过程中会产生 Memory、Trace、Evaluation 等元数据，理想情况下这些也应沉淀回湖，成为后续学习的原料。所以更准确的说法是——本模块不产生新的业务数据，但会持续产出并沉淀关于自身运转的数据，而这部分正是模块⑤学习的燃料。

记忆分两类本质不同的子类，落地方式完全不同：

前者是 Agent 的”制度与法律”，后者是它的”经验与直觉”。二者共同构成 Agent 判断时的上下文。

3.2 结构化数据：一条可追溯的映射链路

• Unity Catalog 血缘（Lineage）= 每张表、每个字段列的”身份证”：任何数值都能回溯来源与加工过程，是知识可信度的底座。
• 人工按业务需求预先治理 raw 数据：对 bronze/ODS 层参考业务口径清洗建模，沉淀中间层（silver），再在其上构建 Metric Views 作为指标语义层。
• 这条 medallion + Metric Views 链路，给结构化数据一条 “海量数据 → 信息 → 知识” 的可追溯映射。
• 关键价值：Metric Views 提供指标的单一事实来源，避免 Agent 拿到互相打架的口径——正好承接模块① OntoRank”采纳最权威定义”的诉求。

3.3 非结构化数据：预制 + 持续 sync + 周期复核

• 预制：对原始上下文做预处理、切分、嵌入，落成可检索的知识节点。
• 持续 sync：不断同步模块①的新信息，实现知识增量更新。
• 人工周期性复核：保证”更新输入 → 知识”的转化 pipeline 准确，防止错误上下文污染记忆。
• 不只是”加”，还要能”改 / 退役”：旧知识被取代时需版本与失效机制，否则上下文越积越脏。周期复核也要负责废弃过期知识。

3.4 复核策略：按权威性 / 风险分层

人工复核是瓶颈，不能全量。建议高权威、高风险的知识走人工精审，其余先 AI 预筛、再抽样人工把关——复用模块① OntoRank 的权威分作为复核优先级排序，让有限人力用在最该被信任的知识上。

3.5 对下游的接口

模块③消费本层的方式：结构化知识经 Metric Views / SQL 调用，非结构化知识经向量检索获取。二者可以落在同一张受治理的本体 / 知识图谱上——这是采集阶段结束后的物理收敛。

默认消费语义不是「全图联合检索」。 图可以物理统一，检索必须逻辑隔离（见 §3.6）：部门 Agent 默认只看到本域知识 + 集团公共知识；跨域联合检索是编排层授权后的例外，不是模块②对外的缺省接口。

没有这一层会怎样：未经治理的原始数据直接进决策，幻觉与错误口径被当成事实；每次都从零开始、经验无法沉淀；合规与审计无从谈起——这是风险与信任成本最高的一层。

3.6 针对多部门的上下文命名空间（Context Domains）

在业务部门繁多且独立的巨型企业中，非结构化上下文（OKR、SOP、项目进度等）若全量打平检索，会导致极其严重的噪信比（Noise-to-Signal ratio）上升。结构化指标同样如此：各部门「转化率」「活跃」若混在同一语义层，Advisor 会拿到打架的口径。

• 域隔离（Domain Partitioning）：为不同部门/项目划定 Context Namespace（非结构化）与 Metric Scope（结构化）。默认情况下，部门 Agent 仅检索本域知识 + 集团级公共知识（如 HR 政策、合规条款、集团级 Metric Views）。
• 跨域授权检索：仅当模块④发起跨部门协作或涉及跨职能任务时，由编排层基于权限校验临时开启跨域图空间联合检索。若两域对同一概念的权威定义冲突，以集团公共定义优先，其次按 OntoRank 权威分 + 请求域优先级裁决，而不是简单把 Filter 打开。
• 跨域只读视图：部门指标不默认全局可见；对外只暴露契约化的只读 Metric / 结论，避免把域内口径泄漏成「全公司事实」。

---

4. 模块③ AI 处理逻辑（推理）

4.1 核心立场：先自动化改造，而非放任 AI 执行

本模块不是让 AI 大范围自由执行，而是先基于业务实际运转流程，把流程抽象化、模块化，做大量自动化改造。设计原则一句话：确定性的归确定性（工作流），判断性的归 AI（监督与决策）。

4.2 识别自动化机会的三条路径

三条路径构成互补三角，覆盖”声明的需求 + 涌现的行为 + 观测的真实使用”：

方法论要点：三条路径的产物往往不一致——员工”说的、搭的、用的”常有出入。三者交叉比对，是发现”真需求 vs 伪需求”的最佳方法。

4.3 从”探索性 AI 用法”到”生产级自动化”：固化判据

识别出的自动化，部署为一个个 cron job 或互相带依赖的 DAG——这一步把员工工作流与模块①（数据）、模块②（知识）真正链接起来。

必须设一道闸门：一个反复出现的 AI 问答，何时该被固化为确定性 job？建议明确 promotion criteria（晋升判据），例如按 频率 × 稳定性 × 风险 评分达标才固化。这是把 skill/trace 沉淀为生产级自动化的核心工艺。

4.4 AI 在这一层的两个角色

• 监督者（Supervisor）：对每条 workflow pipeline 做监督——对其 output 与 sensor 信息做汇总 / 概括 / 监控 / 学习。这些 output 和 sensor，本质是对模块①数据输入的业务化处理与 transform。pipeline 出错或漂移时，异常信号如何上报应对接编排 / 治理层；本模块只需定义”异常信号的产生与上报口径”。
• 决策顾问（Advisor）：基于模块②的 context 及其核心逻辑，对企业的任务 / objective / OKR 做 loop review，输出业务执行建议与商业决策建议。

4.5 与相邻模块的分工边界

• 模块③：产出加工后的情报与评审（发生了什么、偏离了什么、建议往哪走）。
• 模块④：把建议包装成可执行方案并分级交付。
• 模块⑤：执行之后回写成败与经验。

三者是”分析 → 行动 → 复盘”的接力，不应互相越位。

没有这一层会怎样：要么员工继续手工重复劳动（人力成本高、易错、难扩展），要么放任 AI 自由执行（不可控、不可审计）；自动化收益无法规模化，AI 永远停在”聪明的玩具”。

---

5. 模块④ 面向业务的执行策划（行动）

5.1 本质：把情报”送对人、能行动、可追溯”

本层大量依赖企业 Context：组织架构、部门层级、当前 Lark（Meegle）等项目管理进度。以此作背景，把处理结果路由到具体问题对应的部门 leader 或具体负责员工。

5.2 两条路由：送对人 ≠ 调对 Agent

规模化后，「找人」和「找能力」是两套映射，不能共用一张硬编码表。

人员路由（组织图 → 人）：用来「找对人」的组织架构，正是模块①/② 里 OntoRank 已维护的组织图。模块④应直接消费它，而非另建一套人员映射。路由必须保持新鲜——人员变动、部门重组会让「送对人」变成「送错人」。始终读模块②的最新组织图，而非硬编码。

能力路由（契约 → Agent）：当部门数量庞大时，仅靠组织架构图做静态映射会失真。跨部门任务应结合宏观层的 Capability Contract，按业务意图动态匹配并发现对应部门的 Agent / 服务接口（Agent Discovery），再调用其公开能力。组织图回答「通知谁」；契约回答「调用哪个 Agent 做什么」。

发现失败时的降级：找不到匹配契约 → 只送人、不自动调对方 Agent；切勿回退到写死部门 Job 名。

5.3 交付有两个方向：对内协调 + 对外触达

对内——把建议送给员工与部门 leader，通道如下：

通道选择原则：由紧急度 × 交互性 × 可审计性决定——本质是 push（邮件/通知/IM）与 pull（App/任务系统/表格内协作）的取舍，服务于”接收方最可能采取行动”的路径。优先让结论出现在员工已经打开的界面（表格 / Slack·Teams），再落到需审批或项目跟踪的系统。

对外——直接对客户 / 用户做自动化触达与活动运营，可依托 Databricks CustomerLake（Agentic CDP）：

• CustomerLake 是原生构建在 Databricks 上的智能体化 CDP，统一客户数据、身份识别、受众构建与激活。
• 其核心概念 “infinity campaigns”：用持续的 agentic loop 实时响应客户 context，取代一次性活动——很多原需人手动 trigger 的用户触达 / 运营反应因此可自动化。
• 经前三个模块处理后的情报，可直接驱动 CustomerLake 做出自动反应。

结构洞察：CustomerLake 的 “infinity campaign” 本身就是一个微缩的企业 Agent 闭环（感知客户 context → 决策 → 激活 → 学习），相当于 Databricks 预置好的”客户运营 Agent”，正是宏观层”多 Agent 网络”里的一个节点。模块④对外这支应直接编排它，而非从零自建。 落地提醒：CustomerLake 目前处于 Private Preview，属”近期可期但受限”的组件——规划纳入，短期保留兜底方案（自建激活 job / 手动触达），待可用后切换。

产品矩阵提醒（通道选型时）：业务侧协同同事用 Genie One（含上述 Native Apps）；受治理对话分析用 Genie Agents（原 Genie Spaces）；开发侧代码/检索辅助用 Genie Code；平台构建 task-first Agent 用 Agent Bricks——勿混称。

5.4 交付内容

包含但不限于：经营报告、会议建议、项目进度追踪与分析、业务改进点，并做全业务部门链路传达（产品 / 开发 / 运营等一并规划、通知）。这种”全链路传达”本质是跨职能协调，对应宏观层的多 Agent 协作。

5.5 三条设计要点

• 执行分级在这里落地：全自动 / 人工审核 / 仅建议三档。高风险动作（尤其触及资金、对外承诺）默认走人工确认。
• 交付通道同时是传感器：交付不是 fire-and-forget，要拿到回执 / 状态（Meegle 任务状态、App 的 approve/reject、邮件响应、表格/Slack·Teams 内协作痕迹、客户反应），这些都是模块⑤的反馈信号。
• 每条建议带”依据 / 血缘”：附上来源与推理依据（复用模块② Unity Catalog lineage）。人力桥接的前提是可解释——能核对、能信任，才会采纳。

没有这一层会怎样：再好的洞察也烂在报表里、无人行动（“分析瘫痪”）；信息送错人或说不清依据，员工不信任、不采纳；对外错失实时触达的商业机会——投入的算力最终没变成业务结果。

---

6. 模块⑤ 评估 / 反馈 / 学习（闭环）

这是把 ③→④→⑤ 闭合、让企业从”自动化”升级为”会学习的 Agent”的最后一环。

6.1 三类反馈源 → 三个不同的学习层

反馈不是一团，它有明确的作用对象：

三类信号到达速度不同，学习节奏应随之匹配——快信号驱动自动微调，慢信号走周期性人工评审（复用模块②周期复核机制）。

异构评估体系（Domain-Specific Evaluation）

部门间业务性质差异巨大（如风控重「精确度与合规」，创新业务重「迭代速度与转化」），模块⑤的评估不可使用单一全局指标衡量：

• 局部评估自治：允许各部门 Agent 针对模块⑤定义域内专属的 Domain Evaluation Metrics（如风控的拒贷率/误伤率，营销的 ROI/转化率），独立驱动域内的软/硬学习。
• 全局评估收拢：中央治理层监控全局安全合规、算力成本配额、模型漂移告警以及跨部门协同成功率。

这两套指标正交：全局侧（如 CLEARS）衡量质量、安全与成本；域内指标衡量业务结果。后者不能替代前者，前者也不能拿来给所有部门打业务分。

6.2 反馈的三种落地形态

• 更新非结构化文档 → 软学习：沉淀进模块②的经验记忆（慢、累积、低风险）。
• 直接升级流程中的某些环节 → 硬学习：改动模块③的工作流 / 模型（快、结构性、有风险）。
• 更新结构化知识与规则口径 → 当反馈揭示某个指标定义或规则本身有误时，改模块②的领域知识 / Metric Views，而不仅是文档。

6.3 CI/CD + VCS：让”学习”安全可回退的安全带

学习 = 对线上系统做改动，而改动是危险的。 CI/CD + 版本控制（VCS）正是让持续学习可版本化、可回退的安全带。

这层安全带应对齐两条改动面，形成双重保护：

硬学习若改的是模块③工作流背后的管道，不得只过模型评估就上线——管道逻辑同样要绿通。回流升级前：模型变更好 + 数据管道仍正确，缺一不可。

对称判据：模块③有”晋升（promote）“判据；模块⑤应有对称的“降级 / 回滚（demote / rollback）”判据——某环节表现变差或漂移时，能自动告警并回退到上一个已知良好版本。有了 VCS，回滚才是一个动作而非一场事故。

6.4 归因纪律（关键缺口）

持续运转的系统里很多东西同时在变，很难把”业务结果好坏”干净地归因到”某个决策”。不解决归因，“学习”就退化成追逐相关性、逐渐漂移。

建议：在对外触达 / 活动运营侧引入实验纪律——holdout 对照组、A/B 测试（CDP 通常原生支持受众 holdout）。只有能测出因果增量，回写才是”学习”而非”噪声固化”。

6.5 闭环合上：⑤ 回写 ② 与 ③，治理层按范围守门

模块⑤的两条回流箭头——回写模块②（知识与记忆） 和 升级模块③（工作流 / 模型）——正是那条把单向链变成闭环的回流线。会学习和受治理必须同时成立，但闸门按改动范围分级，否则联邦会被「所有改动都过中央审批」一句话收回去：

没有这一层会怎样：系统只会”自动化”、不会”进化”，同样的错误反复犯；无法证明 AI 到底创造了多少价值（ROI 不可测）；模型漂移无人察觉，风险在暗处累积。

---

7. 编排 / 治理层（神经中枢）

模块之间谁调度、按什么条件触发、失败如何回退，需要一个显式的控制层，否则能力散落各处、无法治理。它承担六件事：

1. 编排（Orchestration）：定义模块间的触发条件、依赖、重试与回退逻辑。
2. 权限与安全：谁 / 哪个 Agent 能访问哪些数据与工具（最小权限）；跨域检索与调用必须经此授权。
3. 可观测性与评估：全链路日志、追踪（Trace）、指标，外加对每一次决策质量的持续评估（Evaluation）。评估应与追踪并列为一等支柱——用 MLflow Evaluation / Trace 把”决策做得对不对”变成可量化、可回归、可回放的指标，而不只是记录”决策发生过”。没有评估，可观测性只能告诉你系统在动，却告诉不了你它在变好还是变坏。全局 CLEARS / Safety 在这一层收拢；域内业务指标不下放到中央打分。
4. 成本与配额控制：算力 / 调用成本的监控与限流；联邦场景下按域设配额，避免一域打爆全局账单。
5. 契约注册与发现：维护各部门公开能力的注册表（发布、版本、废弃）；为模块④的 Agent Discovery 提供可检索来源。破坏性变更走中央闸门。
6. 域隔离策略：Context Namespace / Metric Scope 的默认边界，以及跨域授权的例外通道。

企业级与玩具级 Agent 的差别，几乎全在这一层。

一个贯穿全架构的副产品——数据安全：员工执行工作流时不需要完整知道底层业务数据（如集团营收，本就该走严格权限）。数据留在云上、出口被严格管控（契合 Unity Catalog 权限 + Unity AI Gateway 出口管控），只让”结论 / 动作”流出、原始数据不流出。双重收益：既减少员工数据处理工时，又极大提高数据安全性——员工在”信息最小必要”原则下工作。

没有这一层会怎样：权限失控、数据泄露；算力与 token 账单失控；出了问题无法回放、无法追责、无法回退——这正是”玩具级 Agent”上不了生产、一上线就翻车的根本原因。企业级与玩具级的差别，几乎全在这一层。

7.1 部署边界：逻辑联邦 ≠ 物理共仓

Domain Federation 解决的是「看见什么、能调谁」；工作区与算力解决的是「谁把集群打满、账单算到谁头上」。两层不要混：Catalog / schema 是逻辑边界，Workspace / 预算是故障与配额边界。

三条原则即可，切法和旋钮见落地文档：

1. 共享控制面、隔离数据面：UC metastore、Gateway、Secrets、契约注册表尽量一套；重负载 Serving 与作业计算按域限流或拆开，避免一域拖死全家。
2. 先垂直做实一个域的闭环，再水平加域：吞吐与配额先在试点域证明，再复制；不要按部门数一上来开 N 套平台。
3. 跨域是经授权的少量调用，不是广播：发现与契约已经倾向这一点；运行时禁止无上限扇出，否则联邦会在峰值时把被调域打爆。

切 Workspace 不重新发明 Context 隔离——Namespace 永远在 UC。

---

8. 端到端闭环：一个完整周期怎么转

以”某产品线转化率下滑”为例，串一遍整套架构如何协同：

1. ①感知：埋点与交易数据（流式）显示某产品线转化率连续下滑；OKR 文档（Context）表明该产品线是本季度重点。
2. ②记忆：经 Metric Views，“转化率”有唯一口径；血缘可回溯到具体字段。相关历史案例（经验记忆）被检索出来。
3. ③推理：监督 pipeline 捕获异常信号并汇总；决策顾问结合 OKR 上下文做 loop review，产出”下滑归因 + 改进建议”。
4. ④行动：人员路由到该产品线负责人（对内，经 Meegle 派任务，附依据与血缘）；若改进依赖供应链库存策略，则经能力契约发现对方部门 Agent 并调用其公开接口，而不是写死对方 Job。同时对受影响用户群启动 CustomerLake 挽回触达（对外）。高风险动作走人工确认。
5. ⑤学习：Meegle 任务完成情况 + 员工总结 + CustomerLake 触达效果（带 holdout 对照）回流——本域经验回写②，验证有效的挽回流程经本域晋升判据固化进③；若涉及共享口径或跨域契约变更，走中央闸门。全程可审计、可回滚。

一个周期结束，企业 Agent 比上一轮更”懂”这类问题。

---

9. 设计原则总纲

贯穿全架构的核心原则，可作为落地时的判断基准：

1. 闭环优先：反馈回流才是会学习的 Agent，单向链只是自动化。
2. 确定性归工作流，判断归 AI：可标准化的固化为 job/DAG，需判断的交给 AI 监督与决策。
3. 先自动化改造，而非放任 AI 执行：从真实流程出发，抽象、模块化、自动化。
4. 三路径交叉识别需求：员工”说的 / 搭的 / 用的”交叉比对，筛出真需求。
5. 数据留云上，只让结论流出：最小必要 + 出口管控，安全与效率兼得。
6. 权威分驱动优先级：OntoRank 权威分用于知识复核排序与路由。
7. 每个改动可版本化、可回退：VCS + CI/CD 是持续学习的安全带；模型/Agent 与 DAG/ETL 管道走双重门禁（评估 + 单元测试）。
8. 归因纪律防漂移：holdout / A-B 让学习测的是因果而非相关。
9. 会学习与受治理同时成立：结构性自我修改必过闸门；域内低风险可自治，跨域契约与全局安全走中央。
10. 复用而非自建：组织图、CustomerLake、Genie One 办公插件等已有能力直接编排消费。
11. 域自治、中央守门：默认本域 Context / 指标 / 评估；跨部门只通过能力契约协同，不靠硬编码路由或全量打平检索。
12. 逻辑联邦 ≠ 物理共仓：看见什么用 Catalog；算力与账单用 Workspace / 域配额。控制面共享，数据面按负载隔离。

---

10. 落地映射文档

概念架构至此完整。具体 Databricks 落地件、可用性状态与分阶段实施路径见：

《Databricks 企业级 Agent 落地映射与实施路径》（v1.4，2026-08）

该文覆盖各模块组件对照、预览/Beta 兜底、以及与《高维逻辑的拓扑连线与现实锚点》的理论映射（含平台留白）。产品状态变更时优先更新落地文；本文仅在概念层通道与闭环原则变化时修订。

概念层与落地层的粗映射（便于导航，细节以落地文为准）：

• ①输入：Delta Lake / Auto Loader / Lakeflow Connect / SDP（含文件类 SaaS Connector）；可选 Genie Code Web Search 补外部实时 Context
• ②记忆：Unity Catalog（血缘、治理、域 schema）/ Metric Views（集团级 + 域作用域）/ Vector Search（带 domain Filter）/ Genie Ontology（OntoRank）/ Ontobricks；业务侧对接 Genie Agents
• ③推理：Workflows（Jobs / DAG）/ Model Serving / Mosaic AI Agent Framework / Agent Bricks / Managed MCP（经 Unity AI Gateway）/ Unity AI Gateway；部门能力以 UC Tools / MCP 契约发布
• ④行动：Databricks Apps / 通知与 alert / Genie One Native Apps / Lark-Meegle 集成 / CustomerLake；人员路由走组织图，能力路由走契约发现
• ⑤学习：Lakehouse Monitoring / MLflow / Inference Tables / CI/CD（Asset Bundles）+ VCS / Pipeline 单元测试；域内 Custom Judges + 中央 CLEARS
• 编排/治理层：Unity Catalog 权限 + UC Secrets / Unity AI Gateway / 契约注册与跨域授权 / 域配额与 Serving 上限 / 工作区策略（默认单仓 + 一域一 Catalog） / 可观测性与成本治理

---

附录：来源

以下关于 Databricks 产品与算法的说明基于公开文档与报道核实：

• ITdaily — Not pagerank, but ontorank: Databricks Genie Ontology brings context and authority to AI — https://itdaily.com/blogs/cloud/databricks-genie-ontology/
• Atlan — What is Genie Ontology? Databricks’ Context Layer, Explained — https://atlan.com/know/ai-agent/databricks/genie-ontology/
• GitHub — databrickslabs/ontobricks — https://github.com/databrickslabs/ontobricks
• Databricks Docs — AI governance with Unity AI Gateway / AI Gateway-enabled inference tables — https://docs.databricks.com/aws/en/ai-gateway/
• Databricks Blog — Introducing CustomerLake: The Agentic CDP embedded in Databricks — https://www.databricks.com/blog/introducing-customerlake-agentic-cdp
• Databricks Newsroom — Databricks Enters the Marketing Industry with CustomerLake — https://www.databricks.com/company/newsroom/press-releases/databricks-enters-marketing-industry-customerlake-agentic-customer

v1.4 增量：§7.1 部署边界（逻辑联邦 ≠ 物理共仓）；原则第 12 条。切法与 Serving 旋钮见落地文。

v1.3 增量：将 Domain Federation 挪到「微观/宏观两层」之后；明确检索默认逻辑隔离、人员路由与能力路由分离、域内/跨域分级闸门；编排层补契约注册与域隔离职责；原则第 11 条「域自治、中央守门」。

v1.2 增量：补充 Genie One 办公生态原生嵌入（Excel / Google Sheets / Slack / Teams）；模块⑤明确模型侧 MLflow 与管道侧单元测试的双重 CI/CD；第 10 节指向已成文的落地映射文档。