How to scale agentic applications without creating AI sprawl

如何在不造成 AI 延伸的情况下扩展智能代理应用 | Databricks 博客

跳至主要内容

Agent Bricks

2026 年 9 月 30 日

如何在不造成 AI 延伸的情况下扩展智能代理应用

当智能代理从回答问题转向跨数据、模型和业务系统的操作时，企业需要一个共享的基础来实现选择、上下文和控制。

作者：Julia Powell 和 Sirui Sun

摘要

• 随着智能代理应用变得越来越自主，企业需要共享的基础设施来提供上下文、模型和工具访问权限；治理；评估；以及可观测性，而不是为每个代理重新构建这些能力。

• 选择使团队能够根据生态系统的变化采用合适的模型、工具和框架，而上下文则让代理基于受控的企业数据和业务含义进行操作。

• 当代理执行操作时，控制变得尤为重要，需要范围限定的权限、一致的策略、追踪、评估和跨应用的操作可见性。

构建一个代理正在变得更容易。更强大的模型和编码代理使构建和迭代的速度加快。然而，在企业中运营多个代理却是一个不同的问题。

当代理从回答问题转向执行操作时，它们越来越依赖于模型、企业数据、业务语义、工具和应用的网络。一个工作流可能需要检索受控数据、选择模型、调用多个工具、将工作交给另一个代理，并更新业务系统——所有操作都需在正确的权限下进行，并留下足够的追踪记录以理解发生了什么。

当每个团队独立地将这些组件连接在一起时，可能会出现一种新型的 AI 延伸：重复的集成、不一致的策略、增加的 AI 开支、碎片化的上下文，以及随着代理数量增加而变得难以更改的应用程序。

挑战在于在不增加每个应用周围基础设施数量的情况下扩展这些应用。

我们最近联合 Databricks、OpenAI 和 Stellantis，探讨了在生产环境中扩展智能代理应用所需的关键因素。一个核心主题是，随着代理变得越来越强大和自主，围绕它们的基础设施变得更为重要。

在企业规模上，该基础设施需要提供三方面内容：选择，使团队能够根据发展使用合适的模型、工具和框架；上下文，使代理能够基于受控的企业数据和业务含义进行操作；控制，使权限、策略、评估、可观测性和成本管理在应用增长时保持一致。

在 Databricks 上，这一基础结合了 Agent Bricks、Omnigent 和 Unity Gateway。Agent Bricks 提供了构建、治理和优化代理舰队的统一平台。Omnigent 为团队提供了一个通用的层，用于跨代理框架进行协作，而 Unity Gateway 则集中管理这些应用所使用的模型、代理和工具的访问权限、成本控制和可观测性。

通过在应用之间共享这些能力，团队可以添加新的代理和工作流，而无需将每个代理都变成一个独立的集成和治理项目。

上下文应共享，而非重复构建

企业代理需要的不仅仅是模型的访问权限。它需要理解当前任务所需的数据、业务定义、文档、应用和工具。

这些上下文通常已经在组织内部存在。挑战在于如何以受控且可重复使用的方式使其对代理可用。

考虑两个服务于不同团队的代理。销售代理和客户支持代理都可能需要了解谁属于活跃客户、该客户拥有哪些产品，以及账户层级是如何定义的。如果每个应用程序都独立地重新创建这些定义，相同的企业概念在不同工作流程中可能会产生不同的含义。

这种碎片化还会在团队将代理分别连接到客户数据、产品定义、指标和内部文档时，增加更多需要维护的基础设施。

Agent Bricks 基于围绕受控企业数据和业务语义构建的共享上下文层。Unity Catalog 管理对数据和 AI 资产的访问权限，而 Genie 本体论则为代理提供对业务概念和关系的统一理解。文档智能、AI 搜索和代理记忆等能力可以通过文档理解、检索和历史记录来扩展该上下文，以支持更复杂的流程。

这样，团队可以在不同应用程序中重复使用相同的受控业务上下文，而无需每次重新创建。

选择不应导致碎片化

对于某个任务来说，最佳的模型、工具或代理框架很可能不会一成不变。

代理应用程序中的不同步骤可能需要在推理质量、延迟和成本之间做出不同的权衡。新的模型和框架不断涌现，复杂的流程可能同时结合多个框架。

当每个框架都有自己的接口、会话、策略和运行方式时，这种灵活性会变得难以管理。

Omnigent 在代理框架之上添加了一个通用层，使团队能够组合使用不同框架构建的代理，并在它们之间切换时减少重复工作。Unity Gateway 在模型和框架层处理选择，提供对专有和开源模型的一致访问，以及智能路由、容量和成本控制。

这些层共同使团队能够在不改变周围基础设施的情况下，更改应用程序背后的模型和代理技术。

控制必须贯穿每个操作

当代理从生成响应转向执行操作时，对控制的需求会增加。

代理可能会读取公司数据、调用业务系统、执行代码、更新工作流或调用其他代理。每增加一种能力，应用程序能做的事情就更多，需要治理的交互也更多。

例如，处理客户退款的代理。发起请求的员工可能对客户账户有广泛访问权限。但与此同时，代理只需要订单详情、相关的退款政策以及执行特定交易的权限。其权限应与其被要求完成的任务相匹配。

这需要覆盖整个 AI 交互的控制机制。

Unity Gateway 提供了一个跨模型、代理、MCP 服务器、工具和技能的集中控制平面。团队可以应用访问策略和防护措施，管理预算和速率限制，控制可用的 AI 资产，并在这些交互中保留追踪信息。结合 Unity Catalog，这些控制可以反映请求背后的标识、数据权限和上下文。

对于执行代码或工具的工作负载，Databricks Sandbox 添加了一个隔离的执行环境，并对代理所需的数据和系统进行降级访问控制。

结果是更清晰的边界，明确了代理可以访问的内容、可执行的操作，以及随着应用规模扩大，这些决策如何被强制执行。

控制还需要对发生了什么具备可见性

一旦应用程序能够获取上下文、选择模型、调用工具并协调多个步骤，其最终响应只能讲述故事的一部分。

看似正确的答案可能隐藏了检索失败、错误的工具调用或意外的执行路径。当出现问题时，团队需要重建应用程序如何得出结果的全过程：使用了哪些信息、调用了哪些工具、哪个模型处理了任务、应用了哪些策略，以及行为与预期的偏差点在哪里。

Unity Gateway 在 AI 交互中集中了遥测数据，包括追踪信息、使用情况、成本和工具活动。MLflow 通过追踪和评估工作流，补充了这种操作可见性，使团队能够检查应用程序行为、在数据集中捕获代表性交互，并评估提示词、模型、工具或编排的变更。

这些反馈可以指导应用程序的下一次迭代。团队可以在全面推广前比较变更内容，识别回归问题，并利用生产环境行为逐步提升质量、可靠性和成本效益。

共享的基础设施使组合更简单

更广泛的业务流程通常会涉及多个代理、模型或工具。一个组件可能理解用户请求，另一个可能分析数据，而一个确定性系统可能执行计算或更新业务流程。

当这些组件周围的基础设施已经共享时，组合这些组件的能力变得更有价值。Omnigent 为使用不同框架构建的代理提供通用接口，而 Agent Bricks 则为构建和运营最终代理舰队提供更广泛的平台。相同的受控上下文和控制机制可以贯穿整个工作流。

随着团队构建更多应用，代理、工具、技能和业务上下文可以成为可复用的构建模块。新的工作流可以利用现有、受良好治理且可观测的基础设施，而不是创建另一个孤立的堆栈。

为选择、上下文和控制而构建

随着代理能力的提升，围绕它们的架构需要承担更多在企业级规模上确保其可靠性的责任。

选择为团队提供了在生态系统变化时采用新模型、框架和工具的空间。

上下文将这些应用扎根于受控的企业数据和业务语义中。

控制则在整个代理舰队中提供一致的治理和操作，从权限和策略到预算、追踪、评估和成本。

Agent Bricks 将这些能力整合为一个统一平台，用于大规模构建、治理和优化代理舰队，Omnigent 支持跨框架的组合，Unity Gateway 则在 AI 交互中提供统一的控制平面。

模型和框架将持续变化。企业无需标准化其中某一个即可实现成功扩展。他们需要标准化周围的基础设施——这样新代理可以继承相同的上下文、控制和运营模式，而不会产生另一层 AI 混乱。

了解更多

观看《Agents at Work: Shipping Agentic Apps at Scale》点播视频，深入探讨企业级智能代理应用背后的基础设施、运营模式和生产实践。

快速入门

通过 Agent Bricks CLI，快速入门变得简单。只需几行代码，您就可以开发一个集成了 Agent Bricks 所有功能的代理程序，包括用于模型容量的 Unity Gateway、部署在 Databricks 基础设施上的运行时环境，以及由 MLflow 提供支持的代理追踪功能。

订阅最新文章

订阅我们的博客，将最新文章直接发送到您的邮箱。

注册

查看所有博客文章

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"