在Databricks上构建Agent化安全审查

我们的安全审查流程中已经有一部分实现了自动化。它很有用，但没有足够减少人工工作量。

我在队列中不断看到同样的模式：一个采用熟悉设计的常规集成，可能就挨着一个真正新颖、高风险的架构，两者都在等待同样稀缺的资源——一位经验丰富的审查人员。

问题不在于我们现有的自动化失败了。它只是达到了极限。我们仍然在可预测的工作上花费专家时间，留给真正需要专家判断的决策的空间就更少了。

所以我构建了一个基于代理的层，来扩展我们已有的东西。目标不是取代流程或流程背后的人，而是帮助系统理解请求、应用我们的标准、询问缺失的信息，并识别何时需要人工介入。

第一个基于代理的版本只专注于一条审查路径。我的团队看到了更广泛的模式，并将其扩展为一组代理，现在支持我们安全受理和审查流程的更多部分。我完全在 Databricks 上构建了第一个版本，这正是我们客户所使用的平台。

为什么平台很重要

我能够快速推进，是因为核心组件已经在一个环境中可用。

Unity Catalog 为我们的安全标准、请求数据、支持性证据、决策和系统输出提供了一个受治理的空间。Databricks 托管的基础模型提供了用于分类和推理的模型层。Lakeflow Jobs 在无服务器计算上编排基于笔记本的工作流。Databricks Apps 提供了受理体验和高管仪表盘。

各部分如何组合在一起

从高层来看，一个请求通过平台沿着一条连续的路径流动，每一步都从同一组受治理的表读取并写入：

1. 受理 - 一个基于 Databricks Apps 构建的对话式应用，将自然语言描述转换为结构化请求，并附加任何支持性设计文档。
2. 推理 - Databricks 托管的基础模型（Claude Haiku、Sonnet 和 Opus）对请求进行分类、评估风险并起草要求，始终以我们的安全标准为依据。Haiku 处理轻量级分类，Sonnet 处理大多数审查工作，Opus 则保留用于最繁重的推理。
3. 编排 - Lakeflow Jobs 在无服务器计算上运行审查代理，按计划让每个请求经过其各个阶段。
4. 记录系统 - Unity Catalog 将标准、请求数据、证据、模型输出和决策作为受治理的表保存，并对所有这些采用统一的权限和血缘模型。
5. 可观测性 - 第二个 Databricks App 读取这些相同的表，报告数量、风险构成、自动化率和节省的时间。

这让我们在数据、模型、工作流和应用程序之间拥有了一致的治理和运营模型。我不必去组装具有不同权限、日志和数据路径的独立服务，而是可以专注于审查逻辑和用户体验。

实际差别在于速度。我在不到两小时内就有了一个可运行的系统。用连接独立服务的方式做同样的事情则需要数周。

并非每次审查都需要相同的路径

大多数安全队列中既包含可预测的请求，也包含真正的例外情况。

一个使用已批准身份验证模式且不处理敏感数据的集成，与一个面向互联网、处理敏感信息并拥有广泛管理访问权限的服务，并不是同一个决策。然而，传统队列可能会让两者经过同一条人工路径。

我并不打算将每次审查都自动化。我将可重复的部分自动化，并在风险或不确定性较高时保留人工判断。

这引出了一条简单的规则：对于明确定义范围内的、已充分理解的案例采用自动化；对于新颖、高风险或模糊的决策则由人来处理。

更好的入口

审查质量取决于开始时可获得的信息。

静态表单要求请求者知道自己需要哪种审查、理解安全术语，并预判审查人员会要求哪些证据。当他们做不到时，请求到达时就是不完整的，审查又以另一轮提问开始。

我用 Databricks Apps 构建了一个对话式受理应用。请求者用自然语言描述他们想做的事情。应用会识别可能的审查路径，提出依赖上下文的后续问题，并可以使用内置设计文档作为支持性上下文。它会突出显示缺失的信息，并在创建正式请求之前提供初步风险指示。

一旦它获得足够的上下文，就会为安全团队创建一个结构化请求。

该应用还拥有一个以我们的安全标准为依据的咨询模式。并非每个问题都需要变成工单。团队可以在仍在设计阶段时获得指导，只有在确实需要时才开启正式审查。

这成为了系统中最有用的部分之一。它让人们能够更早取得进展，而不是将队列视为与安全团队互动的唯一方式。

代理如何工作

受理应用背后是一组在 Databricks Notebooks 中实现、并通过 Lakeflow Jobs 编排的专注代理。

我刻意避免构建一个拥有广泛权限、充当安全审查员的单一代理。每个代理都有明确的职责范围：收集上下文、评估风险、将请求映射到相关标准、起草要求、管理后续跟进，或准备移交人工处理。

七个专注代理，每个只做一件事

这是一组专注代理——不是一个通用代理，也不是一个单一脚本——每个都有狭窄的职责，作为受理应用背后的计划任务进行编排：

• 受理代理 - 运行对话式入口：识别审查路径、提出依赖上下文的问题，并组装结构化的请求。
• 风险评估代理 - 分配风险等级并提供支持性证据，当情况不完整时默认分配更高的等级。
• 要求代理 - 将请求映射到相关标准，并为已充分理解的案例起草针对具体实现的要求。
• 专业审查代理 - 处理需要专门逻辑的请求类型，例如浏览器扩展威胁建模和第三方供应商评估。
• 验证代理 - 在任何事项关闭之前，为较高风险的请求构建逐项验证清单。
• 工作流代理 - 处理后续工作：澄清、提醒、确认跟踪和人员上报。
• 学习代理 - 定期将审查者的编辑与原始输出进行比较，以发现对提示词和标准的改进。

每个代理都有明确的职责边界，因此其行为保持可检查、可测试，且对一个代理的更改不会悄然影响另一个代理。

系统首先评估请求的风险，并记录支持该评估的证据。仅有一个风险标签是不够的。

当信息缺失或相互矛盾时，系统会要求澄清或将请求转交给审查者。它不会通过推断来获得批准。

对于常规请求，代理会根据实际架构和适用标准生成要求，而不是返回通用模板。请求者确认这些要求并提供必要的证据。符合条件的中低风险请求一旦满足既定标准和验证，即可通过自动化路径完成。

一个示例

以一个常见案例为例：一个使用已批准的单点登录模式且不处理敏感数据的内部集成。要求代理不会生成通用模板，而是生成与该项目架构相关的具体、可核查的条目——例如：

• 通过已批准的身份提供商进行身份验证，并禁用任何本地或共享凭据。
• 将集成的访问范围限制在必要的最小范围，并记录这些范围。
• 将应用程序和访问日志发送到中央日志管道。
• 确认数据分类级别，并在引入任何敏感数据之前重新审查。

请求者确认这些条目并附上证据。如果一切检查无误且该案例符合资格标准，则可以通过自动化路径完成。

高风险、关键、异常或模糊的请求会转交给人工处理。到那时，审查者会收到结构化摘要、支持性证据、适用标准以及任何剩余的未决问题。

代理还处理审查相关的大量行政工作：收集缺失的详细信息、发送提醒、跟踪确认，并在有人寻求帮助时进行上报。当请求变得模糊或需要判断时，会引入审查者。

自动化在我们定义的规则内运行。人员保留对例外和有重大影响的决策的控制权。

使系统值得信赖

最难的部分不是让模型生成一个答案。而是让该答案受到约束、可审查并适合采取行动。

这些代理以我们的安全标准为基础。风险评估必须包含支持性证据。缺失上下文会触发后续跟进或上报，而不是乐观假设。自动化完成仅限于预定义的请求类别和标准。工作流会记录与每个请求相关的输入、输出、证据和决策。

实践中的样子

有三件事使自动化决策可以安全地付诸行动：

• 预定义的请求类别。 只有已充分理解、较低风险的类别才有资格进行自动化完成——例如，使用已批准模式且不处理敏感数据的常规内部集成。任何超出这些类别的内容默认都会转交给人工处理。
• 可接受的证据。 决策的好坏取决于其依据。证据是指具体、可验证的产物：链接的设计文档、明确的数据分类级别，或展示已批准控制措施已到位的配置和参考资料。没有证据的断言会被视为缺失信息。
• 被拒绝或不确定的评估。 当证据缺失或相互矛盾时，系统不会猜测。它会默认采用更保守的风险层级，发布具体的澄清请求，或将请求连同未决问题一并交给审查者。它不会设法获得批准。

审查者反馈帮助我们识别差距并随着时间的推移改进系统。我们利用这些纠正来完善我们的标准、提示词和工作流逻辑，而不是让代理自行改变生产行为。

这些控制比模型本身更重要。强大的模型可以改进推理，但信任来自其周围的系统：明确的范围、显式的证据、保守的上报，以及赋予风险真正权重的人工权威。

我的团队将其推进到了何处

我构建了第一个基于代理的版本，以改进一条审查路径。我的团队认识到，同样的模式可以支持更多内容。

他们将架构扩展到更多请求类型，强化了工作流，改进了代理应用我们标准的方式，并添加了日常使用所需的控制。最初只是一个基于代理的工作流，如今已发展成为一个团队持续开发的共享系统。

我启动了它，但系统之所以变得有价值，是因为团队将其投入运营并使之成为他们自己的系统。

作为一名构建者，我为第一个版本能够运行而感到自豪。作为一名领导者，我更自豪的是团队看到了一个值得扩展的基础。

衡量成果

效率方面的说法很容易提出，但如果没有证据就很难令人信服。

我构建了一个高管仪表板，作为另一个 Databricks App。它读取审查工作流生成的同一 Unity Catalog 数据，并跟踪请求量、风险分布、自动化完成、人工上报、周期时间以及审查者估计节省的时间。

由于这些指标来自运营记录，我们可以将它们追溯到产生这些指标的请求和决策，而不是手动核对来自不同系统的导出数据。

它改变了与领导层的对话。我们可以展示自动化在哪里减少了人工投入，审查人员在哪里仍然参与，以及这种组合如何随时间变化。

数字

该仪表板跟踪一组一致的度量指标，全部源自相同的运营记录。

发生了什么变化

曾经在队列中等待数天的符合条件的常规请求，现在可以在几分钟内完成。团队可以在提交工单之前获得指导，而确实到达审查人员的请求也会带着更好的上下文信息。

我们的安全工程师可以将更多时间花在新颖的设计、有意义的风险以及需要经验的决策上。第一轮审核也更加一致，因为请求是依据相同的标准和证据要求来评估的。当系统不确定时，它会升级处理。

这并非没有人类参与的安全。这是一个旨在将专家注意力用在最有价值之处的系统。

我从这段经历中学到了什么

增加审查人员可以提升处理能力，但并不能消除重复性工作。

第一步是将流程与判断分开。只有在标准明确、系统以真实标准为依据、要求提供证据、不确定性会被升级处理，并且结果可以被衡量的情况下，才自动化可重复的步骤。

不要仅仅因为模型能够给出答案就自动化一项决策。只有当流程定义了什么样的答案是可接受的、什么证据支持它，以及当系统不确定时会发生什么，才将其自动化。

让人类掌控有重大后果的决策和例外情况。

我的意图并不是将人类从安全审查中移除。我的目标是减少他们花在受控系统能够一致处理的工作上的时间。在 Databricks 上构建为我们提供了实现这一目标的平台基础。看着我的团队接手第一个版本、加以强化，并使其成为他们自己的成果，这是最棒的部分。

从 Databricks 多智能体指南开始，然后将本文中的模式——Unity Catalog 中的受治理数据、Lakeflow Jobs 上的专注智能体，以及作为前门的 Databricks App——调整为你自己的可重复、基于证据的审查工作流。

在 Databricks Apps 上构建多智能体系统

从 Databricks 多智能体指南开始，然后将本文中的模式——Unity Catalog 中的受治理数据、Lakeflow Jobs 上的专注智能体，以及作为前门的 Databricks App——调整为你自己的可重复、基于证据的审查工作流。