本指南提供了一个起点，用于了解生成 AI 应用程序或 AI 代理的完整生命周期。 在整个本指南中，“AI 代理”是 GenAI 支持的系统的一个伞式术语，包括简单的 LLM 调用、AI 函数和基于代理的实现。
开发生命周期概述
1.了解用例、范围和成功指标
在构建任何东西之前，请明确 AI 代理的用途。 与包括批准部署到生产环境的人员在内的利益干系人协调一致。
- 代理将处理哪些类型的输入（“域”或“范围”）？ 哪些用户将提交输入？
- 代理应如何理想地响应常见输入？ 应使用哪些信息或上下文？
- 哪些标准定义了良好或错误的响应：音调、准确性、完整性、响应长度、安全、引文或其他要求？
- 生产中有哪些系统要求和约束：成本、延迟和可伸缩性？
- 什么是潜在的故障模式，代理应如何处理它们：错误的用户输入、信息不足、指示错误答案的用户反馈或其他问题？
选择最简单的可行方法。 许多用例不需要复杂的代理系统或多代理系统。 在生成之前，请评估问题在复杂性连续性上的位置。 简单的确定性逻辑或批处理 AI 函数是否足够？ 如果需要动态工具调用、推理或协调，请考虑使用工具调用代理或多代理系统。 有关更深入的指导，请参阅 代理系统设计模式。
通过此基础，你可以：
- 确定代理所需的数据源和工具
- 编写反映预期行为的初始说明或提示
- 确定可以提供代表性示例和早期反馈的域专家或测试人员
- 创建对评估条件进行编码并加速迭代的自动法官
在这个阶段，你不需要完美的清晰度，你的理解将在迭代时得到改善。 但更强的早期协调，特别是在质量测量标准以及“生产就绪”定义这两方面，能显著加快后期的质量改进和核准过程。
2.生成初始 AI 代理
在用例和目标定义明确后，即可构建 AI 代理的原型。 Databricks 提供基于 UI 的引导式路由和完全自定义的基于代码的路由，用于生成 AI 代理。
2.1. 准备数据和工具
AI 代理通常使用数据和工具来提供上下文和功能。 有关在 Databricks 上使用数据和工具的概述，请参阅 AI 代理工具 。
在创建新数据之前搜索现有数据和工具：
- 浏览 Unity 目录 或 工作区搜索 中的可用数据，了解已存在的受管理资产。 这有助于了解创建新资产之前可用的上下文和功能。
- 在 AI Playground 中，可以查看和选择已可用于代理的工具，例如矢量搜索索引、MCP 服务器或 UC 函数。
根据需要创建和管理新资产：
- 准备并提供结构化 数据 或 非结构化数据。
- 使用 托管或外部 MCP 服务器创建简单或复杂的工具。
所有这些数据资产和工具都在 Unity 目录中进行管理和版本控制，使它们在 AI 代理和应用程序中可发现和可重用。
2.2. 构建初始智能体
在创建自定义代理之前，请评估声明性 Agent Bricks 或现有的 Databricks 解决方案加速器 是否已满足您的用例。 对于常见模式，这些引导式方法可以显著减少设置、提高默认质量和加快生产速度。
如果仍需要自定义代理，则新生成器应以最快的方式开始试验。 使用 AI Playground 在不 编写代码的情况下创建代理的原型。 借助 AI Playground，可以尝试不同的模型、执行提示工程和测试工具，以便快速了解数据质量、代理行为以及方法的潜力。 然后，可以将代理导出为代码，以便进一步进行自定义和迭代。
如果已有代理代码，可以将 现有代码引入 Databricks 并将其部署为 Databricks 应用。
在构建代理时，应提前规划评估和部署：
- 使用 MLflow 跟踪 为代理进行仪表化，以记录和分析代理行为。
- 在此阶段，请专注于功能正确性：确保代理以端到端方式运行，并可以访问所需的数据和工具。
- Vibe 检查早期问题，例如错误的工具选择、缺少上下文或幻觉。
- 稍后，这些记录将用于评估代理质量。
- 在实现过程中，请考虑 为生产应用程序使用正确的身份验证方法。
3. 迭代改进 AI 代理质量
工作原型存在后，下一阶段是衡量、理解和提高质量的紧密循环。 Databricks 将 MLflow 评估 置于此循环的中心，由 MLflow 跟踪、评估数据集和 LLM 评委支持。
自动评分器和 LLM 评委提供规模和一致性，但 人类反馈 对于验证现实世界的有用性和理解微妙的失败至关重要。 人工反馈还指导 LLM 法官的开发和校准。 随着代理的成熟，人工反馈通常进入三个阶段：
- 早期开发人员和利益干系人验证
- 更广泛的领域专家评审
- 最终用户反馈
3.1. 验证早期行为
开发人员和一小组利益干系人或领域专家可以提供快速的早期反馈。 在进行扩展测试和评估之前，确保代理在显而易见的情况下做出正确的决定。
在原型开发阶段，开发人员常常通过手动查询代理完成非正式的“状态检查”，以确认代理能够端到端地运行并按照预期表现。 借助 MLflow 跟踪 UI，开发人员可以直接将反馈或期望附加到 跟踪，以标记质量问题、标记成功的示例，以及记录未来评估和迭代的笔记。
部署内部原型后， “审阅应用聊天”UI 提供了一个简单的 UI 来收集反馈。 与一组开发人员或领域专家共享原型的聊天 UI，这些人员可以提出既合理又有问题的询问。
MLflow 跟踪记录交互和反馈，以生成结果的初始数据集。 使用 MLflow UI 或代码分析跟踪 ，以了解代理的性能和行为。 如果结果不正确或意外，请使用跟踪进行调试：
- 分析代理中的质量问题，例如工具滥用、幻觉或缺少上下文。 应用修补程序，例如提示优化、工具使用情况或数据。 请参阅 3.4。修复问题并重新验证改进。
- 在迭代过程中，可以使用跟踪数据集作为代表性的用户输入来为您的新原型生成跟踪记录。
- 重复此循环：运行、检查、修复和重新运行，直到代理按预期处理所有或大多数代表性输入。
- 以后的迭代可能会发现和解决更多问题。 质量改进是迭代的，不限于这一早期阶段。
在此步骤之后，可以确信原型在常见情况下的行为合理，并在投入更广泛的测试之前达到合理的质量水平。
3.2. 扩展测试和反馈
在原型在简单情况下工作后，通过扩大 beta 测试人员集并收集更多自定义反馈来扩展质量评估。 此阶段揭示了意外主题、误解的查询、工具和检索差距或新兴使用模式等盲点。 它还扩展了评估数据集。
- 向更广泛的利益干系人和领域专家或 beta 版最终用户推出应用程序。 将他们的反馈融入其中，随着代理接触到更广泛的使用模式。
- 使用 “审阅应用”标记会话 和自定义架构来捕获更详细的反馈和期望，以获取专家反馈。
- 通过同步人工反馈和标记的跟踪来生成 评估数据集 ，并准备在下一步进行系统评估和监视。
- 若要进一步扩充评估数据集，请考虑 生成综合评估集。
3.3. 系统地进行质量评估和故障排除
随着评估数据集变得越来越大且更加多样化，你需要结构化和更自动化的方法来检测问题、显示最重要的故障并了解根本原因。
在实践中，可能会将数据划分为两种类型的评估数据集：
- 回归测试：具有高质量 AI 响应的数据有助于定义预期行为。 使用这些数据集来验证新版本的代理是否在一组广泛且多样化的预期方案中继续运行良好。
- 以问题为中心的调试：具有低质量 AI 响应的数据可能包括各种不需要的行为。 隔离表现出同类型质量不佳行为的跟踪日志组，以便你可以了解其根本原因并迭代进行针对性的修复。
下面的工具有助于生成和分析这两种类型的评估数据集。
运行回归测试
- 通过选择具有高质量 AI 响应或人类期望的代表性数据子集来生成回归测试。
- 使用 内置或自定义 LLM 评委和评分器定义评估标准。 自动化评估既可以单独使用 LLM 来评估响应质量，也可以将响应与参考标准响应或期望结果进行比较。
- 对新版本的代理运行评估，以确保更新不会降低以前良好的行为。
识别低质量响应的类型
- 使用自动评估和人工反馈来发现代理响应不佳的示例。
- 通过判断分数或用户反馈来筛选和分析 MLflow 跟踪，以隔离有问题的交互。 使用特定的评委和自定义反馈架构，可以隔离特定类型的问题，例如幻觉、缺少上下文或无关的响应。
- 对于代理调试，可以使用 MLflow AI Insights 或将自己的代理连接到 MLflow MCP 服务器。
提高自动检测的准确性
虽然可以主要使用人工反馈开始构建评估数据集，但可以使用自动化检测来扩大评估。 迭代时，投资 LLM 评审或专为您的应用和领域定制的基于代码的评分器。
- 从 内置法官开始，并根据需要添加 自定义法官 和 基于代码的评分器 。 观察内置判断器未捕获的故障模式时，可以使用旨在检测该特定故障类型的自定义判断或记分器自动执行将来的检测。
- 使用人工反馈使自定义评委与专家理解保持一致 。 调整法官以减少误报和负数将增加对自动评估和会审的信任。
- 新的评委和评分器可用于自动评估和监视，以及筛选跟踪以生成用于调试的数据集。
有效解决根本原因问题
确定失败后，需要确定它发生的原因。
-
使用 MLflow 跟踪 手动检查代理推理的每个步骤：
- 选择了哪些工具
- 如何使用工具输入和输出
- 检索是否返回了相关上下文
- 模型响应如何影响下游决策
- 应用 MLflow AI Insights 或 代理评判 来分析踪迹并指出可能的原因，如错误的基础理解、错误的提示词结构或不正确的工具参数。
- 比较 MLflow 评估 UI 中的版本，以查看问题在迭代之间是回归还是持续存在。
此步骤的理想结果是对失败的原因、失败的原因以及如何修复它进行结构化理解。 自动化和特定应用领域的评估工具使您能够在智能代理能力增强和测试集日渐复杂的情况下，反复评估和优化。
3.4. 修复问题并重新验证改进
正如问题特定于应用程序一样，必须根据应用程序定制修补程序。 常见修复的示例包括：
- 提示优化：手动优化代理的说明，或使用 数据驱动的提示优化。 对于更广泛的代理优化（例如优化多步骤推理或工具使用），请使用 DSPy 优化。
- 工具和数据：当追踪显示事实缺失或基础不稳时，改进工具或检索流程。
- 路由：当跟踪显示调用了错误的工具或子代理时，请改进工具或代理元数据、提示或路由模型。
- 护栏：响应违反安全规则或泄漏信息时，请在代理中使用 AI 网关防护栏 或自定义防护措施。
- 回退：使用备用 API 终结点或回退响应等回退机制正常处理极端情况、缺失数据或 API 调用失败。
在迭代修复程序时，请使用 应用版本控制 和 提示目录 来记录版本，以便进行更简单的比较和回归测试。
每个针对提示、检索、工具、数据或其他部分的修复应以发现问题时的相同方式进行验证。 在同一评估数据集上重新运行新的代理版本，以确认问题已修复，并且未引入任何回归。
4.在生产之前与利益干系人保持一致
在将代理发布到实际环境中之前，团队需要对其当前功能、限制和衡量质量有共同的理解。 达到这一点通常需要 在步骤 3 中多次迭代和质量改进。 在此阶段，将技术信号（如评估指标、系统指标和示例跟踪）转换为业务上下文，最终确定代理是否真正“就绪”。
- 将评估结果转换为明确的业务信号：以相关方可以采取行动的语言总结评估结果的准确性、稳定性、安全性和已知限制。
- 确认满足标准化质量检查：确保候选版本的所需评估指标、回归检查和数据集覆盖率阈值通过。
- 验证操作准备情况并获取登录：查看监视设置、防护措施和推出计划。 在生产之前记录风险和验收标准。
5. 发布到生产环境并持续监控质量
达到生产阶段是一个重要的里程碑！ 这意味着代理已准备就绪，可供实际用户和实际影响。 同时，生产也是新周期的开始。 代理上线后，它会进入持续监视和改进，因为实际使用情况将呈现新行为、边缘事例和问题。
- 收集 生产环境中最终用户的反馈。 将用户反馈链接到特定跟踪，以便可以与模型行为一起进行分析。 可以通过将反馈记录为附加到原始跟踪的评估来执行此操作。
- 利用 AI 网关 进行防护、路由和一致的日志记录。 确保可以根据实际流量评估每个新的代理版本，而不会发生操作摩擦。
- 通过对采样的生产迹线进行评估来监视实时流量的质量。 确认新版本的性能至少与以前的版本一样好，并在用户提交新类型查询时寻找新问题。 持续监视使代理在发展过程中可靠、安全且符合业务需求。 MLflow 提供监视仪表板，但由于 跟踪可以存储在 Unity 目录中，因此你可以自定义仪表板和警报：
- 生成 自定义仪表板 ，以便与业务利益干系人进行监视和共享。
- 设置 Databricks SQL 质量警报 以检测故障或出现的问题。
- 根据生产见解采取行动
- 对于高风险用例，请将监控与自动或受限回滚机制链接，以解决关键问题。
- 在下一次迭代中运用您的生产洞察力。 将实际故障转换为新的评估数据，并返回到 评估和调试循环 ，以生成下一个更好的代理版本。
后续步骤
- Azure Databricks 生成 AI 功能 - 查看适用于代理和 GenAI 的 Azure Databricks 平台功能
- 代理系统设计模式 - 了解从简单代理到复杂代理的范围
- 入门：无代码查询大型语言模型并打造 AI 代理原型 - 使用 AI Playground 创建代理原型