如何规模化Agent应用而不产生AI蔓延

构建智能体正变得越来越容易。能力更强的模型和编码智能体正在让构建和迭代变得更快。然而，在整个企业范围内运行大量智能体则是另一个问题。

随着智能体从回答问题转向采取行动，它们越来越依赖于由模型、企业数据、业务语义、工具和应用程序构成的网络。一个单一工作流可能会检索受治理的数据、选择模型、调用多个工具、将工作移交给另一个智能体，并更新业务系统——而这一切都要在拥有正确权限并留下足以理解所发生情况的充分追踪的前提下进行。

当每个团队各自独立地将这些部分连接起来时，就会出现一种新型的 AI 蔓延：重复的集成、不一致的策略、增加的 AI 支出、碎片化的上下文，以及随着智能体数量增长而变得越来越难以变更的应用程序。

挑战在于如何扩展这些应用程序，而不必为每一个应用程序成倍增加周边基础设施。

我们最近与 Databricks、OpenAI 和 Stellantis 齐聚一堂共同探讨在生产环境中扩展智能体应用程序需要具备哪些条件。一个核心主题是：随着智能体变得能力更强、更加自主，其周边基础设施也变得更加重要。

在企业规模下，该基础设施需要提供三样东西：选择，以便团队随着技术演进使用合适的模型、工具和框架；上下文，以便智能体能够使用受治理的企业数据和业务含义；以及控制，以便权限、策略、评估、可观测性和成本管理在应用程序增长时保持一致。

在 Databricks 上，该基础将 Agent Bricks、Omnigent和 Unity Gateway汇聚在一起。Agent Bricks 提供了用于构建、治理和优化智能体集群的统一平台。Omnigent 为团队提供了一个跨智能体运行框架工作的通用层，而 Unity Gateway 则集中管理这些应用程序所用模型、智能体和工具的访问、成本控制和可观测性。

借助这些在应用程序之间共享的能力，团队可以添加新的智能体和工作流，而不必将每一个都变成单独的集成和治理项目。

上下文应当共享，而不是重建

企业智能体需要的不仅仅是对模型的访问。它需要理解当前任务所需的数据、业务定义、文档、应用程序和工具。

这些上下文通常已经存在于整个组织之中。挑战在于如何以受治理、可复用的形式将其提供给智能体。

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

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

Agent Bricks 依托于一个围绕受治理的企业数据和业务语义构建的共享上下文层。Unity Catalog治理对数据和 AI 资产的访问，而 Genie Ontology则为智能体提供对业务概念和关系的共同理解。Document Intelligence、AI Search和 Agent Memory等能力可以通过文档理解、检索和记忆为更复杂的工作流扩展该上下文。

随后，团队可以在不同应用程序之间复用同一套受治理的业务上下文，而不必每次都重新创建。

选择不应造成碎片化

最适合某项任务的模型、工具或智能体运行框架不太可能一成不变。

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

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

Omnigent在智能体运行框架之上添加了一个通用层，使团队可以组合用不同运行框架构建的智能体，并在它们之间切换，而减少返工。Unity Gateway 在模型和运行框架层面处理选择，为专有模型和开放模型提供一致的访问，以及 Smart Routing、容量和成本控制。

这些层共同让团队可以更换应用程序背后的模型和智能体技术，同时保持周边基础设施一致。

控制必须跟随每一个操作

随着智能体从生成响应转向采取行动，对控制的需求也在增长。

智能体可能会读取公司数据、调用业务系统、执行代码、更新工作流或调用另一个智能体。每增加一项能力，都会扩展应用程序能够做的事情，并产生更多需要治理的交互。

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

这需要贯穿整个 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 基础设施上的 Runtime，以及由 MLflow 提供支持的智能体追踪。