Databricks 在安全审查流程中引入 agent 层
一篇 Databricks 工程实践：用同一平台上的多个 agent 自动分流安全审查的常规请求，把专家时间留给真正高风险的决策。
Databricks 工程师在既有安全审查自动化之上再加一层 agent：由 Unity Catalog 托管安全标准与请求数据，平台托管基础模型负责分类和推理，用对话式应用替代静态表单做受理，自动处理标准明确的常规请求，把高风险、模糊的决定留给人。
正文摘录
我如何在 Databricks 上构建基于 agent 的安全审查 一套受治理约束、职责聚焦的 agent 集合，如何减少例行审查工作量、提升 intake 质量，并把人类判断保留给风险更高的决策 我们的安全审查流程中，部分环节早就有了自动化。它确实有用，但没能把人工工作量降到足够低。 我在队列里反复看到同一个模式：一个采用熟悉设计的例行集成，可能就排在一个真正新颖、高风险的架构旁边，两者都在等待同一种稀缺资源 —— 一位有经验的审查者。 问题不在于现有自动化失败了，而在于它已经触到了上限。我们仍然把专家时间花在可预测的工作上，留给真正需要专家判断的决策的空间就更少了。 于是我构建了一个基于 agent 的层，用来扩展我们已有的能力。目标不是取代流程，也不是取代流程背后的人，而是帮助系统理解一个请求、套用我们的标准、主动追问缺失的信息，并识别出什么时候需要人介入。 第一个基于 agent 的版本只聚焦一条审查路径。我的团队看到了更普适的模式，把它扩展成一组 agent，如今支撑着我们安全 intake（请求进入安全团队受理流程的入口）与审查流程的更多环节。第一个版本我完全构建在 Databricks 上 —— 也就是我们客户使用的同一个平台。 我能快速推进，是因为核心组件都已经在同一个环境里可用。 Unity Catalog 为我们的安全标准、请求数据、支撑证据、决策和系统输出提供了一个受治理的空间。Databricks 托管的 foundation model（基础模型）提供了用于分类和推理的模型层。Lakeflow Jobs 在 serverless compute 上编排基于 notebook 的工作流。Databricks Apps 交付了 intake 体验和高管看板。