Skip to main content
Devin 可以像一位异步协作的同事一样在你的 Databricks workspace 中工作:浏览 catalog、调试失败的 job、调优 SQL、编写并测试笔记本,以及通过你日常的 Git 工作流程交付变更。本指南将介绍如何通过一个专用的 Databricks service principal 完成这项配置——Devin 以该身份进行身份验证,并受 Unity Catalog 治理。
该集成由三个完全由你掌控的部分构成:一个 Databricks service principal、通过环境蓝图安装的 Databricks CLI,以及 (可选的) Databricks 技能 plugin。Databricks、其 workspace 及所有权限始终保留在你的账户中。

选择 Devin 的身份验证方式

Devin 以 service principal 身份向 Databricks 进行身份验证,有两种方式。两者使用相同的 service principal、由蓝图安装的 CLI 以及 Unity Catalog 授权,区别仅在于所用的凭据。 如果你希望今天就让 Devin 跑通 Databricks,请从方案 A 开始。后续可随时改用方案 B,无需改动 service principal 及其授权。

为什么要将 Devin 连接到 Databricks?

  • Devin 直接在你的数据平台上干活。 Databricks 上的工作大多不只是在代码仓库里编辑笔记本,还包括排查 job 为什么失败、查看表的 schema、对数据仓库执行 query,或检查流水线。把 CLI 交给 Devin,这些原本要找人解答的问题,就变成了 Devin 自己就能搞定的事。
  • 单一可审计身份。 Devin 以你创建的 service principal 身份执行操作,因此每一次 API call、query 和 job 运行都会以该身份记录在 Databricks 的 audit logs 和 Unity Catalog 血缘中,而不是挂在某位工程师的个人令牌名下。
  • Devin 能碰什么由 Unity Catalog 说了算。 OAuth 决定 Devin 能否通过身份验证;Unity Catalog 的授权和 workspace 权限则决定它能读取或更改什么。你可以先在生产环境中以 read-only 起步,给 Devin 一个 sandbox catalog 用于构建,等看清它的行为表现后再放宽作用域。
  • 通向零存储 secrets 的路径。 采用 OIDC 令牌联合 (方案 B) 时,Devin 完全不存储 Databricks 令牌或客户端密钥。每个会话都会用一个有效期 60 秒的 Devin 身份令牌换取一个 short-lived 的 Databricks OAuth 令牌。

概述

配置分为四个部分: Databricks 技能 plugin 是第五层,可选:它在 CLI 之上,让 Devin 掌握 Databricks 特有的工作流程 (Asset Bundles、jobs、SQL、Unity Catalog) 。

前置条件

Databricks
  • 一个位于 AWS、Azure 或 GCP 上的 Databricks 账户,且执行配置的人员拥有 account admin 访问权限。创建 service principal、OAuth secrets 和联合策略都在账户级别完成。
  • 一个或多个启用了 Unity Catalog 的 workspace。本指南假设 Devin 需要访问的数据由 Unity Catalog 管控。
  • 在 admin 自己的 machine 上安装 Databricks CLI,用于执行下文的账户级别命令,任意较新版本均可。Devin 所用的副本会在步骤 2 中单独安装。
Devin
  • 编辑你的组织的环境蓝图 (Settings > Environment > Blueprints) 的权限。
  • 若采用方案 A,需要添加 Devin Secrets 的权限。
  • 若采用方案 B,需要你的 Devin OIDC 签发方 URLorganization ID。步骤 2 将说明如何从 Devin 会话内的令牌中读取这两项。相关背景请参阅 Cloud Authentication with OIDC
网络
  • Devin 会话必须能通过 HTTPS 访问你的 workspace 主机 (例如 https://dbc-xxxx.cloud.databricks.comhttps://adb-xxxx.azuredatabricks.nethttps://xxxx.gcp.databricks.com) 。如果你的组织启用了 Devin 网络策略,请将该 workspace 主机加入放行范围;若要执行账户级别命令,还需加入账户主机 (accounts.cloud.databricks.comaccounts.azuredatabricks.netaccounts.gcp.databricks.com) 。
  • 若采用方案 B,Databricks 必须能通过公共互联网访问 https://<your-devin-host>/.well-known/jwks.json 获取 Devin 的 JWKS,以验证令牌签名。

步骤 1:创建 service principal

请为 Devin 单独创建一个 service principal,不要复用其他自动化所依赖的主体。专用主体能让审计日志和权限审查保持清晰。 在一台已登录 Databricks 账户 (而非 workspace) 的机器上执行:
记录输出中的两个值: 然后,将该 service principal 分配给 Devin 需要使用的每个 workspace。你可以在 account console 的 User management → Service principals 中操作,也可以使用 CLI:
使用 USER,而非 ADMIN。Devin 不需要 workspace admin 权限。

步骤 2:将 Devin 连接到 service principal

请按下面两个选项中的其中一个操作。每个选项都可单独完成:它会通过 Settings > Environment > Blueprints 下的蓝图安装 Databricks CLI,并将该 CLI 配置为以步骤 1 中创建的 service principal 身份进行身份验证。
  • 选项 A:OAuth 客户端密钥。标准的 OAuth M2M 方式:为 service principal 生成一个客户端密钥,并将其存储在 Devin Secrets 中。这是最快的上手方式。
  • 选项 B:OIDC 令牌联合。每个 Devin 会话都可以签发一个由 Devin 签名的短期 OpenID Connect 令牌。借助 Databricks 令牌联合,service principal 可以信任该签发方,Devin 便能用自己的身份令牌换取 Databricks OAuth 令牌。全程不会创建或存储任何 Databricks secrets,因此 Databricks 强烈建议在自动化 workloads 中采用这种方式。
无论选择哪个选项,都不建议使用与人工用户绑定的个人访问令牌 (PAT) 。它们会绕过 service principal,过期时间难以预测,还会把 Devin 的操作归到某个人名下。

方案 A:OAuth 客户端密钥

不想管理 Databricks secrets?可直接跳至 方案 B:OIDC 令牌联合。你也可以先按本方案配置,之后再切换:换用方案 B 的蓝图,创建联合策略,然后删除 OAuth secrets 及 DATABRICKS_CLIENT_SECRET 这个 Devin Secret。

1. 生成 OAuth secret

在账户 console 中,打开步骤 1 中创建的 service principal,生成 OAuth secret。有效期请设置为轮换流程所能支持的最短时长 (最长 730 天) ,并将该 secret 限制在 Devin 所需的 API 作用域内,例如 sqljobsunity-catalog,不要选择全部作用域。

2. 添加 Devin secrets

在 Devin 中,将以下内容作为 Devin secrets 添加到你接下来要编辑的蓝图 (组织级或代码仓库级) 的 Secrets 选项卡中: 当同时存在 client ID 和客户端密钥时,CLI 会自动选择 OAuth M2M,因此无需设置 DATABRICKS_AUTH_TYPE。只有当你想明确排除其他所有认证方式时,才将其设为 oauth-m2m Secrets 会在每个新会话开始时以环境变量的形式注入,因此 CLI 不需要 Profile 文件。轮换后的 secret 无需重建即可在下一个新会话中生效。

3. 添加蓝图

仅安装 CLI。身份验证完全依赖上述三个 secrets。
不要在 initialize 阶段将 secrets 写入文件;写入其中的任何内容都会被固化到快照中。
另外,请勿设置 DATABRICKS_TOKEN,也不要在快照中保留 ~/.databrickscfg Profile。凭据冲突是导致 M2M 身份验证失败最常见的原因。

4. 构建快照

保存蓝图,等待构建状态显示为 Success,然后启动新会话。已有会话仍使用旧快照。接下来请继续步骤 3

方案 B:OIDC 令牌联合

Devin 会话会签发短期身份令牌 (isssubaud) ,而 service principal 上的联合策略会让 Databricks 信任这些令牌。蓝图会安装 devin-oidc CLI,并对 databricks 进行封装,使每次调用都携带一个全新的令牌,同时写入一个指向你的 service principal 的 profile。之后,你从会话中读取令牌的 claims,并创建与之匹配的 policy。
想先走最短路径?可以从方案 A 开始,等你准备好不再依赖存储的 secrets 时再回到这里。

1. 添加蓝图

Profile 中有两个占位符必须替换为你自己的值:
该 Profile 不含任何 secrets,因此可以安全地在 initialize 阶段写入。如果你是从方案 A 切换过来的,请在下方策略配置就绪后删除 DATABRICKS_CLIENT_SECRET 这一 Devin Secret,以免 CLI 同时看到两份凭据。

2. 构建快照

保存蓝图,等待构建状态变为 Success。蓝图中没有任何内容依赖于你接下来创建的联合策略,因此之后无需重建。

3. 创建联合策略

蓝图构建完成后,Devin 会话即可签发身份令牌。先用一个令牌读取 Databricks 需要信任的确切 claims,然后在 service principal 上创建与之匹配的联合策略。
1

读取你的签发方和 subject

启动一个新的 Devin 会话,让它运行以下命令。该命令只会打印令牌的身份 claims,不会打印令牌本身。
预期输出格式:
在企业部署中,iss 是你的自定义 Devin URL (例如 https://yourcompany.devinenterprise.com) 。请严格按打印结果复制 isssub。不要把原始令牌粘贴到工单或文档中;在接下来的 60 秒内,它就是一份 bearer 凭据。
2

编写联合策略

将以下内容保存为 devin-federation-policy.json,并替换为上一步获得的值:
这三个字段都要精确匹配:
  • issuer 必须与令牌的 iss 完全一致,包含协议前缀,且结尾不带斜杠。
  • audiences 必须包含 Devin 请求的 audience (本指南中为 databricks) 。
  • subject 必须与令牌的 sub 完全一致。默认的 subject 是你的组织 ID,因此该组织中的每个会话都能以此主体进行身份验证。对 Databricks 来说这是合适的粒度,因为联合策略是按字面字符串匹配 subject 的。像 devin_id 这类会话级 claims 每个会话都不同,静态策略无法匹配。
请不要设置 subject_claimjwks_urijwks_json。Databricks 默认使用 sub claim,并从签发方的 /.well-known/openid-configuration 发现 JWKS。
3

将策略附加到 service principal

确认策略已存在:
蓝图写入的 profile 已指向该 service principal,因此无需重建。继续进行步骤 3

重建与版本固定

Databricks 安装脚本和 setup-devin-oidc@main 都跟随各自上游的 main 分支,因此完整构建会拉取到新版本;而差分构建会跳过 initialize,在蓝图发生变更之前一直沿用快照中已有的版本。如果你需要可复现的构建,请从发布标签而非 main 获取安装程序 (例如 .../databricks/setup-cli/v1.17.0/install.sh) ,这样安装的就是指定的那个 CLI 版本;同时将 action 固定到某个提交 SHA (setup-devin-oidc@<sha>) 。

步骤 3:授予权限

身份验证只能证明 Devin 的身份。Devin 能查看或更改哪些内容,则由 workspace 权限和 Unity Catalog 授权决定;你可以随时调整这些设置,无需改动蓝图。建议从满足当前工作所需的最小 Profile 起步,再有针对性地逐步扩大。

权限 Profile

授权 statement 通过应用程序 ID 指定 service principal:
如果你更倾向于基于组的管理方式,可以将 service principal 添加到某个组 (例如 devin-agents) ,然后改为向该组授权。
代码修改仍应通过拉取请求进行。Devin 可以读取生产数据来了解问题,并在沙盒中验证修复,但笔记本、job 定义或 Asset Bundle 的变更仍需经由你常规的评审流程合入,而不是直接改动生产环境。

步骤 4:安装 Databricks 技能 plugin (可选)

Databricks 发布了 Agent Skills,可以让代码 Agent 掌握 Databricks 的各类工作流程:Asset Bundles、jobs、SQL、Unity Catalog 和 Spark。将它们安装为 Devin 的 plugin 后,Devin 就能在 CLI 的基础上具备这些专业知识。
  1. 打开 Customize → Plugins,选择 Add plugin → From repository
  2. 输入代码仓库 databricks/databricks-agent-skills 和子目录 plugins/databricks/claude。plugin 清单位于该子目录中,因此从 repository root 安装会提示 No plugin manifest found
  3. 如果你在步骤 2 中使用了 organization blueprint,请在 Organization 作用域下安装;如果使用的是 repository blueprint,则改为在该代码仓库的 .devin/config.json 中声明该 plugin (参见继承与级别) ,这样只有装有 CLI 的会话才会获得这些技能。
  4. 确认 plugin 正常工作后,将 plugin 固定到某个 commit,以免上游变更未经审查就进入你的会话。
该 plugin 的核心技能建议运行 databricks auth login 来设置 profile。这一交互式浏览器流程无法在无人值守的 Devin 会话中完成,这里也不需要执行;步骤 2 中的 knowledge 条目已告知 Devin,CLI 已完成身份验证。

步骤 5:验证

待蓝图构建成功后,启动一个新会话,让 Devin 运行:
current-user me 应返回该服务主体 (service principal) ,且其 userName 等于该应用程序 ID。要确认 CLI 使用了哪种身份验证方式:
选项 A 会报告 oauth-m2m,选项 B 则报告 env-oidc 身份验证成功并不代表 Devin 就能访问你的数据。请确认步骤 3 中的授权已生效:
<catalog-name> 替换为你在步骤 3 中授权的 catalog (那里的示例使用 analytics) 。然后让 Devin 对它拥有 CAN USE 权限的仓库运行一个小型只读 query;如果你配置了 Build profile,还可以让它在 devin_dev 中创建并删除一张表。而对 Devin 没有 SELECT 权限的生产表执行 query 应当失败——这次失败恰恰说明权限边界正在生效。

故障排查

支持

Databricks 侧的设置 (service principal、OAuth secrets、联合策略、Unity Catalog) 请参阅 Databricks 身份验证文档 (可按需切换到 Azure 或 GCP 版本) 。Devin 侧的设置 (蓝图、OIDC、plugin、网络策略) 请联系 support@cognition.ai 或你的账户团队。