▶ 原文链接

生产级AI行动手册：在企业规模部署智能代理 — Sandipan Bhaumik, Databricks

来源： YouTube | Sandipan Bhaumik | Jun 18, 2026 播客： AI Engineer 分类： 其他 原文发表： Jun 18, 2026 纪要生成： 2026-06-22

---

嘉宾/话题简介

Sandipan Bhaumik（桑迪潘·鲍米克） 是 Databricks 数据和AI技术主管，此前在 Amazon Web Services 担任了5年的数据与AI首席架构师。他在过去几年里专注于使用分布式系统构建和扩展数据与AI平台，并投入大量精力帮助客户解决一个核心问题：如何将 AI 从演示阶段真正投入大规模生产。本集分享的是他基于在 B2B 软件和金融等受监管行业的实战经验，总结出的一套包含五大支柱的生产级 AI 部署框架和手册。

---

分节详述

00:00 序言：AI 部署的常见误区与三大洞察

本节重点

• 介绍主讲人背景（现任职 Databricks，前 AWS 首席架构师）。
• 描述了企业 AI 项目通常的失败路径：从选择模型开始，构建受限的演示环境，最后在生产中失控。
• 深刻揭示了导致 AI 生产失败的三大鸿沟：可观测性差距、评估差距和治理差距。

详细精要

• 主讲人的背景与核心问题：Sandipan Bhaumik，现任 Databricks 数据和 AI 技术主管，前 Amazon Web Services 数据与 AI 首席架构师（有 5 年经验）。
• 近两年，他观察到 AI 技术虽早已存在，但近来大家的实验呈指数级增长。
• 他通过在不同客户（如 B2B 软件行业、金融服务业等受监管行业）中工作，学到了从构建演示到将其投入生产的深刻教训。

• 本次演讲旨在分享他在一线工作中总结出的可操作框架，供听众在将 AI 系统投入生产时应用。

• 典型的失败项目流程：两年前每次与客户交流都遵循一个导致失败的模式。

• 第一步：选择模型。所有对话都从“该用 GPT 还是 Claude”的争论开始，这是由于市场和新技术趋势导致的，并非任何人的错。
• 第二步：构建功能。在一个受控环境中（可预测的数据集、有限场景），基于选定模型构建功能。
• 第三步：演示成功与批准。演示效果很好，领导层满意并签字批准。
• 第四步：生产失控。投入生产环境几周后，大家开始质疑AI的行为，发现其回答与演示时的预期不符。

• 最终结果：不仅投资回报未能实现，而且投入构建的这些无法扩展到生产的演示还造成了金钱和精力的双重损失。

• 三大核心洞察（三大差距）：

• 可观测性差距 (The Observability Gap)：将 AI 投入生产后，如果无法“看见”它在做什么，无法追踪它做出的每一个决定，那么这个系统在生产中是毫无用处的。
• 评估差距 (The Evaluation Gap)：人们总是在谈论准确性、延迟、扎根性等指标，但没有定义那一个对业务真正重要的东西是什么。缺乏一个能持续衡量 AI 系统是否在改进的系统。
• 治理差距 (The Governance Gap)：没有考虑 AI 在生产中失败时会发生什么。谁是责任人？凌晨三点出问题时找谁？谁拥有喂养 AI 响应的数据资产？AI 对客户胡言乱语时怎么办？完全缺乏问责和治理。

💬 精华片段（中文）

“The first one is the observability gap... if we can't see what it is actually doing, if we can't trace every decision that it's making, it's no use in production.”

“第一个是可观测性差距……如果我们不能看到它实际上在做什么，不能追踪到它所做的每一个决定，那么它在生产中就毫无用处。”

“The second is the evaluation gap... we were not defining what is that exact thing... that matters to the business, and how can we build a system that can continuously measure that.”

“第二个是评估差距……我们没有定义那个对业务真正重要的东西到底是什么，也没有定义如何构建一个能够持续衡量它的系统。”

04:42 五大支柱框架登场

本节重点

• 提出了应在项目开始前就需要思考的五大支柱框架。
• 五大支柱分别是：评估、可观测性、数据基础、编排、治理。
• 理想情况下应按顺序逐步构建，但现实中它们是必须同时考虑的关键领域。

详细精要

• 框架的理念与五大支柱概览：基于前述三大洞察，Sandipan 构建了一个框架，已在多个客户组织中实施。这五大支柱是启动任何项目前就需要考虑的绝对必要元素。
• 理想状态是按顺序逐步构建，尽管他承认在现实中这种顺序往往难以实现。
• 支柱一：评估 (Evaluation)。在触及任何代码、讨论任何模型或功能之前就要思考。需要定义如何衡量，成功的标准是什么，以及构建什么样的系统来持续衡量成功。
• 支柱二：可观测性 (Observability)。核心是追踪 AI 所做的每一个决策。这不仅对于性能优化至关重要，对监管也必不可少。在欧洲或许多受监管行业，没有追踪和可观测性就根本无法将 AI 引入生产，这是“必需品”。
• 支柱三：数据基础 (Data Foundation)。从两个维度来思考。
  • 问题数据 (Question Data)：AI 回答用户问题所需的数据，包括预训练数据、后训练数据、通过 API 连接获得的数据等。
  • 追踪数据 (Tracking Data)：与可观测性中的追踪相关，但从数据策略角度看，当企业运行成百上千个代理时，需要一整套数据策略来处理这些追踪数据。
• 支柱四：编排 (Orchestration)。单个代理可以运行得很好，无需考虑编排。但当引入五个代理时，复杂性会指数级增加。多个协调模式、代理间相互通信、等待彼此响应等问题随之出现，此时就必须考虑编排模式和如何在特定系统中协调代理。
• 支柱五：治理 (Governance)。考虑当事情失败时会发生什么。谁负责？如何治理数据？如何保障系统安全？如何确保没有人能向代理注入指令导致其行为不端或声誉受损？

💬 精华片段（中文）

“These are the five pillars, and these are absolutely what you need to think about even before starting a project... Then you start build them gradually, preferably in sequence, but in real life, I know that this sequence don't work.”

“这就是五大支柱，即使是启动项目之前，你也绝对需要考虑这些……然后你开始逐步构建它们，最好是按顺序，但在现实生活中，我知道这个顺序是行不通的。”

07:21 支柱一：评估 — AI 系统的规格说明书

本节重点

• 详述评估的第一要务：用业务数字定义成功，而非泛泛谈论准确性。
• 阐述了构建黄金测试数据集的方法：与领域专家合作，收集包括灰色区域和边缘案例在内的真实答案。
• 提出自动化评估流水线，用以在生产环境中持续评估 AI 的性能。
• 深入解析评估的三个架构层：确定性层、非确定性语义层、行为层。

详细精要

• 用数字定义成功：评估本质上是 AI 系统的“规格说明”。这不仅仅是讨论准确性，而是要用数字来定义什么是对业务用例有利的准确性。
• 需要定义能接受怎样的误报率，合理的偏离率是多少等。

• 案例说明（零售银行聊天机器人）：实现 AI 代理的一个主要目标就是将简单查询从人工坐席转移走（deflection），因此必须追踪这些查询及其对应的数字，并建立相应的系统。

• 构建评估数据集（测试用例库）：这就是所谓的“黄金数据集”。

• 必须与领域专家交流，了解真实场景中发生了什么。例如，一位人工客服对特定问题给出的答案是什么。
• 必须收集灰色区域和边缘案例的信息。例如，当客户提出含糊不清的问题时，人类专家是如何处理的。

• 将这些信息收集到数据集中，然后自动化你的 AI 测试。

• 自动化评估流水线：构建一个流水线，将一个提问输入给 AI，获取答案，将此答案与测试集进行比较，并自动化整个流程。

• 当 AI 投入生产后，该流水线可以获取实时响应，并根据构建的测试数据集进行评估。

• 最终给出 AI 在已定义的数字和目标方面表现如何的结果。

• 评估系统的三个架构层：

• 第一层：确定性评估 (Deterministic)。这些是简单、廉价的工作，我们多年来一直在做。包括检查邮件格式、电话格式，使用正则表达式等。还可以使用经典机器学习模型进行命名实体识别、意图分类、人名姓氏识别、个人身份信息即 PII 检测等。这一层的核心目的是把这些简单工作先处理掉。
• 第二层：非确定性语义评估 (Non-deterministic Semantic)。这是处理扎根性等的领域，其技术实现是 LLM即裁判 (LLMs as a Judge)。
  • 工作原理：使用一个独立的二级 LLM 来评判主模型的响应。您会告知裁判模型应从哪些角度评判，例如安全、扎根性、答案相关性等。
  • 裁判模型可以依赖已建立的评估数据集，检查预期答案与生成答案的匹配程度。
  • 例如，在 Databricks 的 MLflow 中，可以找到自动 LLM 作为裁判的功能，创建自定义的裁判模型，让它自动在追踪记录上运行。
• 第三层：行为评估 (Behavioral)。这是最容易被忽视但非常重要的层，关注的是代理的工具调用行为。
  • 例如，一个用户提问“我的账户余额是多少”，第一层检查没有格式问题，第二层检查答案正确（“您的余额是XX美元”），但行为检查会发现代理为了找到这个答案，对数据库发起了三次调用。
  • 在演示环境中，三次 API 调用没问题，但在每天处理成千上万查询的生产环境中，重复调用的成本极高。这就是行为评估需要思考和解决的问题，例如检查代理是否调用了正确的工具，是否陷入循环等。

💬 精华片段（中文）

“The third layer is behavioral, right? This is where you think about tool calls, like is our agents calling the right tool? Are they getting into loops? ... This layer is very, very important. I see a lot of organizations, a lot of teams miss them.”

“第三层是行为评估，对吧？这是你思考工具调用的地方，比如我们的代理是否在调用正确的工具？他们是否陷入了循环？……这一层非常非常重要。我看到很多组织，很多团队都忽视了它。”

12:34 支柱二：可观测性 — 用追踪照亮 AI 决策黑箱

本节重点

• 通过一个零售银行的实际场景，阐释了追踪 AI 决策全过程（从意图分类到最终回复）的重要性。
• 说明如何利用追踪数据检测低效和错误行为（如重复 API 调用），并优化性能。
• 强调在线监控与故障转移策略的结合，例如在检测到问题时自动重试或转接人工。

详细精要

• 可观测性的核心：收集 AI 的所有决定。即通过追踪机制，捕获代理的每一个决策步骤。

• 实际应用场景展示（零售银行聊天机器人）：

• 场景：用户询问“我被收取了透支费，能帮我免除吗？”，因为用户认为这笔收费不合理。
• AI 的处理全流程（通过可观测性捕获）：
  1. 意图分类：代理对用户意图进行分类，并记录了耗时和置信度分数。
  2. 获取账户信息：连接客户数据库（可能通过 API），获取账户详情。
  3. 检索政策文件：从 RAG（检索增强生成）向量数据库中检索与透支相关的政策文件，核实客户声称的合理性。
  4. 推理：基于信息进行推理，决定如何回应客户。
  5. 护栏检查：进行最终的护栏检查。
  6. 生成回复：最终回应客户。
• 如果没有可观测性：当客户提出争议时，你将无从查证 AI 到底做了什么，最终只能说“我不知道，给客户打个折让 ta 开心吧”。

• 监管原因：这也是为什么监管机构强制要求可观测性，因为如果不能实现这些，就根本没有生产系统。

• 追踪数据的应用：性能问题检测：

• 检测重复调用：启用追踪后，可以直观地看到并发现像重复 API 调用这样的问题，并据此采取行动。
• 在线监控与主动干预：在生产环境中，可以设置在线监控。一旦发现代理在进行重复调用或某个调用失败了，可以应用预定义的策略。
• 故障转移策略示例：“去重试，但不要超过三次。如果超过三次，就上报到某个地方，或者转交给人工处理。”

💬 精华片段（中文）

“If you did not set up a system that helps you look visualize all of these traces, when the customer comes to you and raises a dispute, you have no way to check what the AI did. Right? You have nowhere to go.”

“如果你没有设置一个系统来帮助你查看可视化所有这些追踪，当客户来找你并提出争议时，你根本没有办法检查 AI 做了什么，对吧？你无处可查。”

15:09 支柱三：数据基础 — 代理时代的最大挑战

本节重点

• 强调数据基础是最重要的支柱，通常占据 60% 的项目时间。
• 解释了为何 AI 代理对数据质量零容忍：数据过去是为宽容的人类准备的，但代理会自信地给出基于错误数据的错误答案。
• 将数据策略分为两大类：问题数据（服务 AI 结果所需）和追踪数据（可观测性数据），并强调追踪数据也需要一套完整的策略。
• 介绍 Databricks 的技术栈如何帮助构建统一的数据基础，包括 Delta Lake 和 Unity Catalog 在数据治理、发现和数据共享上的作用。
• 提出统一追踪数据中心的构想，以支持来自不同框架和云平台的 AI 代理，服务于运营仪表盘、一线支持等多样化用例。

详细精要

• 数据基础是最重要的支柱：在 Sandipan 的典型项目中，他花费 60% 的时间在数据基础上，很多组织也是。
• 根本原因：没有人预料到代理会突然出现并开始查询数据。数据向来是为人类构建的，而人类总是宽容的（发现报告里有错误数据，问问人就能更正）。代理不会宽容你，它会找到错误数据，自信地给你一个错误答案，而你对此毫不知情。

• 这就是为什么数据质量和制定正确的数据策略对现在的企业如此重要。

• 数据策略的两个维度：

• 问题数据 (Question Data)：为 AI 提供最终结果所需的数据。

• 追踪数据 (Tracking Data)：即可观测性数据。需要一个完善的计划来收集这些数据，并将其提供给审计员、监管者，用于进行在线监控、在追踪之上运行 LLM即裁判 等。这需要对接下来的数据 Schema 等有合适的策略。

• Databricks 的数据基础构建方式：

• 技术栈基座：Databricks 建立在 Apache Spark, MLflow, 和 Delta Lake 等开源技术之上。
• 底层存储：最底层是云存储，Databricks 可运行在三大主流云上：Google Cloud, AWS, Azure。
• Delta Lake：在原始数据之上引入类似数据库的特性。可以帮助你在图片、文本、视频等原始文件上创建表结构（使用 manifest 文件），并帮助你以结构化方式增量加载数据和执行数据管理任务。
• Unity Catalog：一个数据目录，可以集中对数据应用权限、使用 Delta Sharing 共享数据。其核心价值在于实现数据发现、所有权标记和元数据（如列描述、标记其为 PII 列）打标。这使得 AI 在查询Unity Catalog 上的表时，能轻松获得这些上下文。

• 上层应用：包括用于构建和调优 LLM 及 AI 应用的 Mosaic AI、数据仓库和 BI 能力、文本转 SQL 的 Genie 等。所有数据都通过 Unity Catalog 这一层进行治理。

• 统一的追踪数据中心策略：

• 挑战：企业不会只在一个框架上运行 AI，他们会用 CrewAI, LangChain 等不同框架，也会用不同云平台。
• 解决方案：需要有一个集中层来收集所有这些追踪数据，以服务于右侧的多种用例：
  • 操作仪表盘：供一线支持或一线防御团队进行健康监控。
  • 文本转SQL查询：一线团队可以使用 Databricks Genie 进行自然语言查询。
  • 定制UI：使用编码代理构建 Databricks Apps，为不同用例创建通用工作区或定制界面。
  • 主动监控：利用 Agent Bricks 和 MLflow 提供的开箱即用的 LLM即裁判 功能。
• 核心理念：无论您的 AI 在何处运行，您都可以采用这种策略，将数据汇集到一个公共位置，并从单个共享位置为不同团队提供服务。

💬 精华片段（中文）

“Data was always built for humans, and humans are always forgiving... Agents don't forgive you, right? Agents will go, find it wrong, they'll give you the wrong answer confidently.”

“数据总是为人类而建，而人类总是宽容的……代理可不会原谅你，对吧？代理会发现错误，然后自信地给你一个错误的答案。”

20:00 支柱四：多代理编排模式

本节重点

• 引出多代理场景复杂性的指数级增长问题。
• 介绍三种核心编排模式：集中式的编排器-工作者模式、合唱式的对手模式、以及人机协同模式。
• 简要提及他在 YouTube 上的深度视频，涉及状态管理、容错、大规模扩展等实际应用时需要考虑的问题。

详细精要

• 为什么需要编排：一个代理运行得很好，但你引入五个代理时，复杂性会指数级增加。你需要思考在特定系统中如何协调这些代理。

• 三种核心编排模式：

• 模式一：编排器-工作者模式 (Orchestrator Worker Pattern)。
  • 工作原理：有一个中央“编排器”，负责从统一的控制平面编排所有工作，然后根据专业技能将工作分发给不同的代理。所有请求都经过编排器，实现了集中控制。
  • 优势：当出现问题时，可以去查看编排器的日志，检查发生了什么事。
• 模式二：对手模式 (Choreography Pattern)。
  • 工作原理：每个代理都是独立、自主的，不依赖于编排器。它们都与一个消息总线通信，监听自己感兴趣的事件，可以并行运行，而非顺序依赖。
  • 应用案例：以抵押贷款申请为例，一个代理监听客户详情事件，另一个监听审批详情事件，它们可以并行工作。
  • 优势：由于不依赖编排器来回传递消息，延迟更低。

• 模式三：人机协同模式 (Human-in-the-Loop Pattern)。

  • 工作原理：当代理的置信度超过或低于某个阈值时，将人工引入工作流程，查看代理的处理情况并采取相应行动。

• 相关的深度内容：主讲人为此次会议的线上环节录制了一个关于多代理编排模式的深度视频，已在 YouTube 发布。

• 该视频讨论了考虑多代理模式时的实际影响，包括：
  • 状态管理
  • 容错处理：当事情失败时如何管理
  • 不同的处理模式
  • 如何在企业环境中大规模扩展

💬 精华片段（中文）

“One agent would work pretty well. You don't need to think about orchestration. But when you onboard five agents, the complexity increases exponentially, right?”

“一个代理可以运行得很好，你不需要考虑编排。但当你引入五个代理时，复杂性就会指数级增加，对吧？”

22:25 支柱五：治理 — 代码化、过程化与风险管控

本节重点

• 明确此处讨论的是 AI 治理（非数据治理），但数据治理是基础。
• 提出监管要求下的审计追踪、PII 预验证（并举例说明测试阶段就发现 47 起泄密事件）的重要性。
• 提出将提示视为代码，进行严格的变更管理。
• 提出模型变更管理，即要有一套系统来评估模型供应商的升级是否对你的具体用例和数据有效。

详细精要

• AI治理的核心要素：
• 监管与审计追踪：是否拥有系统中每个操作、用户连接、请求的所有记录？是否捕获了一切？
• 个人身份信息预验证：使用命名实体识别等简单方法进行拒绝处理。Sandipan 分享了他正在合作的客户案例，仅通过在测试阶段应用这一层，就检测到了 47 起 PII（个人身份信息）违规事件，这非常重要。
• 提示版本化：必须将提示的版本化管理视为企业级解决方案中的变更管理。不能只是改一个提示然后提交到 Git，它必须像代码一样，经过正式的变更管理流程。基本理念是将提示视为代码 (Treating Prompt as Code)。

• 模型变更管理：模型供应商会升级模型，你必须有一个系统来理解升级后的模型是否适合你的用例和数据。供应商会在公开基准测试上发布评估分数，但这对你企业自身环境的帮助不大。

  • 解决方案：利用你构建的评估数据集，将不同的模型在这些数据上进行测试，以了解哪个模型在你的场景下表现更好。
  • 从风险角度看，不能只依赖单一模型，必须具备切换到不同模型的灵活性，并能在你自己的数据上测试它们。这需要进行管理。

• Databricks 的整合方案：Databricks 正在构建 Agent Bricks，旨在将所有这些支柱的点开箱即用地提供出来，以便在您的企业中轻松实现生产级 AI 应用。

💬 精华片段（中文）

“You have to treat prompt versioning as change management in enterprise grade solution. It cannot be just change to a prompt and commit to get. It has to go through proper change management processes as you do with code. So, basically treating prompt as code.”

“你必须将提示版本化视为企业级解决方案中的变更管理。不能只是改一个提示然后提交了事。它必须像处理代码一样，经过适当的变更管理流程。所以，基本上就是‘把提示当作代码’。”

24:27 案例研究：银行聊天机器人的成功转型

本节重点

• 详细介绍一个零售银行聊天机器人的真实案例，他们最初投入 8.5 万美金、6 个月的概念验证失败了。
• 展示了按照框架执行的关键时间线：前几周（1-2周）建立评估层、定义指标、收集数据；中间几周（2-6周）建立数据基础和可观测性基础；第七周才开始选择模型。
• 分享项目成功的具体指标和上线后6周内的一个真实故障闭环案例，证明了整个体系的价值。

详细精要

• 项目背景与初始失败：约18个月前，一家零售银行客户想要构建一个聊天机器人。
• 他们要解决的问题：每月约有 20,000 个客户咨询来电，其中 60% 是简单查询（如“我的账户余额是多少”、“透支了怎么办”），他们希望减少这类查询对人工坐席的依赖。
• 失败的概念验证：他们花费 8.5 万美元，耗时 6 个月进行概念验证，但没有成功。当 Sandipan 他们介入时，发现了之前提到的三大洞察：无人知晓生产环境中到底为何失败，无法衡量为何不成功，无法厘清责任归属。

• 设定的目标：AI 代理能处理 60% 的简单用户查询，并有识别和追踪它们的办法。

• 项目执行时间线（颠覆传统）：

• 核心区别：他们是在为期 8 周的 POC 的第 7 周才开始选择模型。
• 第 1-2 周：构建评估层
  • 收集了 200 个真实人工坐席回答简单客户问题的案例，创建了评估数据库。
  • 定义了成功指标，包括准确率目标（约 85%）、延迟、以及其他操作性目标。
  • 创建了自动化评估流水线：捕获用户问题和 AI 响应 -> 与评估数据集进行比较 -> 评分 -> 低于阈值的由人工检查，找出是提示问题还是工具调用问题 -> 修复后，将该测试用例加入测试数据集。核心思想：评估数据集是一个“活系统” (living system)，会随着时间不断增长，越大越好。
• 第 2-6 周：构建数据基础与可观测性
  • 梳理问题数据：API 连接是否正确？是否有追踪 API 连接的系统？是否安全？
  • 建立分布式存储，开始收集追踪。
  • 在测试阶段就捕获了重复 API 调用等性能问题，发现了客户满意度下降的原因。

• 第 7-8 周：选择模型

  • 由于已经有了评估数据集，可以用不同模型在该数据集上运行，将响应与预期响应进行比较，计算出准确的准确率数字。
  • 这极大地加速了模型选型决策，避免了前期花费数周进行无休止的辩论。

• 上线后6周的成果与闭环案例：

• 最终结果：在启动六周后，他们计算了准确性、偏离率、响应时间、客户满意度 (CSAT) 等运营指标。
• 故障闭环案例（政策变更）：银行更改了一些与利率相关的政策，并通过邮件或应用内通知告知了客户。但当客户就新政策到聊天机器人上提问时，他们无法得到正确答案，并给出了“踩”的反馈，导致 CSAT 反馈下降。
• 闭环过程：
  1. 检测：由于有持续的测量系统，他们立即检测到了 CSAT 分数的下降。
  2. 诊断：通过查看追踪，他们发现代理正在查找一个过时的政策文件。原因是新的政策文件没有被更新到向量数据库，导致嵌入未能生效，代理给出了过时答案。
  3. 修复：问题得以定位并修复。
• 结论：这一切之所以成为可能，正是因为他们构建了让 AI 变得可见、可衡量、可追责的系统。

💬 精华片段（中文）

“The summary of that story is that your evaluation data set is a living system. You start with 200... This will keep growing. And the bigger it grows, the better your system will be.”

“这个故事的核心是，你的评估数据集是一个活生生的系统。你从 200 个案例开始……它会不断增长。它增长得越大，你的系统就会越好。”

“We could actually look into the tracing decisions and see that the agent was looking at a policy document that was outdated... It was all possible because we built that those systems that led us to detect this.”

“我们实际上可以查看追踪决策，并看到代理正在查看一份过时的政策文件……这一切之所以成为可能，正是因为我们构建了那些让我们能发现这一点的系统。”

30:46 生产事故处理手册 & 结语

本节重点

• 分享了可在会中下载的“生产事故处理手册”的概念。
• 详细描述了事故处理四步闭环：检测、诊断、控制、修复，其中特别强调了利用提示版本进行流量回退或用模式进行故障恢复。
• 给出了“明天就可以开始”的行动建议：从定义业务成功和建立简单评估流水线开始。
• 分享了三个极易被忽视的实践经验：对测试用例库进行分类治理、对提示版本进行严格的注释管理、以及对成本高昂的行为层评估做策略性降本。

详细精要

• 生产事故处理手册 (Production Incident Playbook)：
• 很多人做 AI 项目时会忽略它，它定义了生产环境中出现问题时需要做什么。
• 四步处理闭环：
  1. 检测 (Detect)：使用评估仪表盘发现问题。
  2. 诊断 (Diagnose)：使用前面提到的追踪系统进行诊断。
  3. 控制 (Contain)：利用提示版本化，如果有问题的提示就立刻回退并修改。或者将流量直接转给人类坐席 (Deflect it to a human)。主讲人在他的多代理编排视频中还提到了 Saga模式、补偿模式 和熔断模式等容错恢复机制。
  4. 修复 (Fix)：使用测试用例库。查看 LLM即裁判 的报告，查看评估数据报告。找到并修复问题后，将新的测试用例放入评估数据集，创建一个不断成长的评估套件，持续改进 AI 系统。

• 这个手册需要与企业现有的 ITSM（信息技术服务管理）系统集成，以便在合适的时间向正确的人发出告警，并确保下游系统不受影响。

• 从明天就可以开始的行动指南：

• 第一步：如果你有项目想法，首先从定义成功开始。不是从技术角度，而是从业务角度定义成功意味着什么。
• 第二步：提出几个“好答案”是什么样子的示例，创建一个示例数据集。

• 第三步：用简单的 Python 代码构建一个自动化流水线，当 AI 给出响应时，能够将该答案与你的数据集进行比较，并将结果交付。

• 三个极易被忽视的经验教训 (The Three “Easily Miss” Lessons)：

• 治理你的测试用例库：测试用例库是一个不断成长的系统，因此需要治理。你需要有负责人，需要弄清楚哪些测试用例关联哪种问题（如安全类、登录类），并对数据集的行进行分类，以便当系统发生变化时，可以选取相关类别的测试用例进行对比。
• 强化提示版本化的注释：当用 Git 对提示进行版本控制时，提交信息通常会很简单。但必须施加治理，要求在提交信息中明确记录：更改这个提示的“确切原因”是什么？因为什么故障导致了这个更改？这个新版本会解决什么故障、纠正什么问题？ 如果事后追溯时无法弄清为何修改，跟踪问题将变得非常困难。
• 控制昂贵的第三层评估（行为评估）成本：行为评估（检查工具调用等）在评估数据集增长时可能变得非常昂贵。例如，修复了一个错误工具调用后，需要针对拥有三五百行数据的数据集反复运行一遍，代价高昂。
  • 降本策略：在持续集成流水线中，当有提示更改时，可以设置检查点，只选取评估数据集的一个小子集进行测试。只有当代码合并到主分支时，才执行全量测试。通过这种方式来控制成本。

💬 精华片段（中文）

“You need to put governance around what kind of commit messages you are putting in when you're changing these prompts because you need to understand when a prompt was changed, for exact what reason it was changed, right? What was the failure that caused this prompt to be changed?”

“你需要在你更改这些提示时，围绕你输入的提交信息类型加入治理，因为你需要了解一个提示是何时被更改的，以及更改的‘确切原因’是什么，对吧？是哪个失败导致了这个提示需要更改？”

---

专业术语注释

术语	解释
可观测性差距 (Observability Gap)	指 AI 投入生产后，缺乏追踪和可视化其内部决策步骤的能力，导致无法理解和排查问题。
评估差距 (Evaluation Gap)	指没有定义与业务目标对齐的、可量化的成功标准，并且缺乏一个持续自动衡量 AI 系统是否在改进的评估系统。
治理差距 (Governance Gap)	指缺乏对 AI 失败时的问责制、数据资产所有权和安全机制的定义与管控。
偏离 (Deflection)	在客服场景中，特指将本应由人工处理的查询，成功转移到 AI 代理处并完成处理。
LLM即裁判 (LLMs as a Judge)	一种评估方法，使用一个独立的、能力强的大语言模型来评判另一个模型的输出结果，评估其安全性、扎根性、相关性等。
扎根性 (Groundedness)	指 AI 生成的内容是否忠实于所提供的源材料或事实依据，不凭空捏造。
PII (Personally Identifiable Information)	个人身份信息，如姓名、地址、电话号码等，在治理和评估中必须被检测和保护。
Delta Lake	Databricks 开源的一种存储层，为数据湖 (Data Lake) 带来可靠性、ACID 事务等数据库特性。
Unity Catalog	Databricks 提供的统一数据治理解决方案，能够对数据和AI资产进行集中的发现、权限管理、元数据标记和血缘追踪。
Mosaic AI	Databricks 用于构建、训练、部署和治理 AI/ML 模型的平台。
Genie	Databricks 提供的自然语言接口，允许用户用英语提问，系统自动生成 SQL 查询。
编排器-工作者模式 (Orchestrator Worker Pattern)	一种通过中央控制器（orchestrator）统一接收请求、分发任务并协调多个专业代理工作的模式。
对手模式 (Choreography Pattern)	一种去中心化的协调模式，各个独立代理监听共享的消息总线，各自对感兴趣的事件做出反应，彼此无需中央协调即可并行工作。
ITSM (Information Technology Service Management)	信息技术服务管理，企业中用于设计、交付、管理和改善 IT 服务使用的系统，常与告警和事故响应流程集成。
熔断模式 (Circuit Breaker Pattern)	一种故障恢复模式，当调用某个服务（如 API）失败次数达到阈值时，会自动切断通路以保护系统，防止故障蔓延。

---

延伸思考

• “以终为始”的 AI 投入： 这个框架的核心颠覆点是，将模型选择放在了项目后期。这要求团队和业务方有能力在项目初期就进行高强度的业务价值定义和指标拆解，对于习惯了“先跑个模型看看”的组织来说，这本身就是一种文化和能力上的巨大挑战。
• “活体”评估系统的人力成本： Sandipan 强调评估数据集需要不断更新和人工审核（human-in-the-loop），这意味着在 AI 系统上线后，需要一个持续的、具备领域知识的团队的投入来维护和增长这个数据集，预算模型必须覆盖这部分长期成本。
• 追踪数据的成本与价值博弈： 对所有代理的每一步决策进行全量追踪会带来巨大的存储和计算开销。如何设计采样策略、设置合理的保留周期，并在海量追踪数据中高效提取价值，而不是被数据淹没，是企业级部署的技术难题。
• 编排与解耦的权衡： 编排器-工作者模式带来了集中控制和可审计性，但引入了单点瓶颈；对手模式提升了性能和弹性，但使得端到端的追踪和调试变得异常复杂。在实际大型应用中，是否应该设计一种混合模式来取长补短？

原文发表：Jun 18, 2026  ·  纪要生成：2026-06-22