Databricks 实践：研发数据入湖仓，为 AI Agent 构建受治理上下文层
用湖仓架构把研发数据治理好，让 AI Agent 在安全边界内访问上下文，是工业 AI 落地的关键。
Daimler Truck 与 Volvo 合资公司 cellcentric 用四年时间在 Databricks 上构建数据基础，将 Unity Catalog、Lakehouse Federation 与数据产品工程沉淀为 Data Hub。它向员工提供统一 UI，向 Agent 提供 MCP 服务器——确保 AI 能基于受治理的研发数据推理，而非绕开权限。
正文摘录
Why R&D Data Belongs in the Lakehouse - and Why Agents Need It There 四年 Unity Catalog 规范、Lakehouse Federation 与数据产品工程实践，如何沉淀为一个受治理的 AI 上下文层：对人提供统一 UI，对 Agent 提供 MCP 服务器。 作者：Sebastian Eberhardt、Dominik Bentele 和 Jonathan Bräuer 在 cellcentric——Daimler Truck 与 Volvo Group 的合资企业——我们为重型应用开发和制造氢燃料电池系统。我们的工作高度依赖研发、工程和数据。团队提出的问题很少能在一个源系统内解决。它们跨越产品层级、制造历史、返工记录、实验室证据、测试遥测数据和领域知识。 这正是工业 AI 在研发领域的核心挑战。一个 Agent 只有能够基于工程师信任答案所需的同一受治理上下文进行推理，它才有价值：数据来自哪里、含义是什么、完整性如何、哪些注意事项重要、以及用户是否有权查看。将这一切转化为 AI-ready 上下文，起点是数据工程，而不是模型选择。 这就是为什么我们花了四年时间在 Azure 和 Databricks 上构建数据基础。Unity Catalog 从一开始就是架构的一部分。Lakehouse Federation 将本地 SQL 数据源纳入 lakehouse 模式。Delta Sharing 帮助我们跨边界交换数据。Declarative Automation Bundles 为管道和数据产品提供了生产路径。最终成果是 Data Hub：我们的受治理数据与 AI 上下文层，为员工提供用户界面，为 Agent 提供 MCP 服务器。 Data Hub 最初是一个数据产品平台。