Databricks谈企业规模化Agent的三件基础设施：选择、上下文与控制

Databricks描述AI sprawl：重复集成、策略不一致、上下文割裂

文章称，当agent从回答问题转向采取行动，它依赖的是一张由模型、企业数据、业务语义、工具和应用组成的网。一个工作流可能检索受治理数据、选择模型、调用多个工具、把工作交给另一个agent，并更新业务系统，同时还要以正确权限运行并留下足够追踪来理解发生了什么。

当每个团队独立连接这些组件时，会出现一种“AI sprawl”：集成重复、策略不一致、AI支出增加、上下文割裂，以及应用随agent数量增长而变得更难改动。文章称，挑战在于扩展这些应用，而不是让每个应用周围的基础设施成倍增加。

• 文章列出的sprawl表现：duplicated integrations、inconsistent policies、increased AI spend、fragmented context、应用越来越难改。
• 触发条件：每个团队独立把模型、数据、工具、业务系统接在一起。
• 文章称Databricks、OpenAI、Stellantis三方讨论的中心主题是，agent越有能力、越自主，其周围的基础设施越重要。

上下文共享：销售和客服agent不该各自重造“活跃客户”定义

文章称，企业agent不只是要访问模型，还要访问理解当前任务所需的数据、业务定义、文档、应用和工具。这些上下文往往已经存在于组织中，难点在于以受治理、可复用的形式提供给agent。

文章举了两个agent的例子：一个销售agent和一个客服agent可能都需要理解谁算活跃客户、该客户拥有哪些产品，以及账户层级如何定义。如果每个应用独立重建这些定义，同一个业务概念在不同工作流中可能含义不同。这种割裂还会在团队分别把agent连接到客户数据、产品定义、指标和内部文档时，产生更多需要维护的基础设施。

按文章描述，Agent Bricks依托一个共享上下文层，该层围绕受治理的企业数据和业务语义构建。Unity Catalog治理数据和AI资产的访问，Genie Ontology给agent提供对业务概念和关系的共同理解。Document Intelligence、AI Search和Agent Memory等能力可以用文档理解、检索和历史来扩展上下文，支持更复杂的工作流。团队因此可以复用同一套受治理的业务上下文，而不是每次重建。

• 文章称需要共享的上下文包括：数据、业务定义、文档、应用、工具。
• Unity Catalog负责数据和AI资产的访问治理；Genie Ontology负责业务概念和关系的共同理解。
• 可扩展上下文的能力：Document Intelligence、AI Search、Agent Memory。

Omnigent与Unity Gateway：模型和harness可变，周边基础设施保持一致

文章称，一项任务最好的模型、工具或agent harness不太可能固定不变。agentic应用的不同步骤可能要在推理质量、延迟和成本之间做不同取舍。新模型和新harness持续出现，复杂工作流可能同时组合多个。

当每个harness都有自己的接口、会话、策略和运行方式时，这种灵活性会变得难以管理。Omnigent在agent harness之上增加一个公共层，让团队可以组合用不同harness构建的agent，并在切换时减少返工。Unity Gateway处理模型和harness层面的选择，为专有模型和开源模型提供一致访问，并带有Smart Routing、容量和成本控制。

文章称，这些层加在一起，让团队可以更换应用背后的模型和agent技术，同时保持周边基础设施一致。

• 不同步骤的取舍维度：推理质量、延迟、成本。
• Omnigent的定位：跨harness的公共层，用于组合不同harness的agent。
• Unity Gateway的定位：模型与harness层面的一致访问、Smart Routing、容量和成本控制。

退款agent的权限例子：控制要覆盖每一个动作

文章称，当agent从生成回复转向采取行动，对控制的需求会增加。agent可能读取公司数据、调用业务系统、执行代码、更新工作流或调用另一个agent。每增加一项能力，应用能做的事就更多，需要治理的交互也更多。

文章用退款agent举例：发起请求的员工可能拥有客户账户的宽泛访问权限，但agent只需要订单详情、相关退款政策，以及执行特定交易的权限。它的权限应与被要求完成的任务相匹配。

按文章描述，Unity Gateway提供跨模型、agent、MCP server、工具和技能的集中控制平面。团队可以应用访问策略和护栏、管理预算和速率限制、控制哪些AI资产可用，并保留这些交互的追踪。与Unity Catalog一起，这些控制可以反映请求背后的身份、数据权限和上下文。对于执行代码或工具的工作负载，Databricks Sandbox提供一个隔离执行环境，对agent所需的数据和系统采用降权访问。文章称，结果是给agent能访问什么、能采取什么行动，以及这些决策如何随应用增长执行，划出更清晰的边界。

• 退款agent例子中的权限差异：员工有宽泛账户权限，agent只需要订单详情、退款政策、特定交易权限。
• Unity Gateway的控制面覆盖：模型、agent、MCP server、工具、技能。
• 可配置项：访问策略、护栏、预算、速率限制、可用AI资产、交互追踪。
• Databricks Sandbox：隔离执行环境，对数据和系统降权访问。

可观测性：最终答案正确可能掩盖失败的检索或错误的工具调用

文章称，一旦应用可以检索上下文、选择模型、调用工具并协调多个步骤，它的最终响应只能说明部分情况。一个看起来正确的答案可能掩盖失败的检索、错误的工具调用或意外的执行路径。出问题时，团队需要重建应用如何得到结果：用了什么信息、调用了哪些工具、哪个模型处理了任务、应用了哪些策略，以及行为在哪里偏离预期。

按文章描述，Unity Gateway集中AI交互的遥测，包括追踪、使用量、成本和工具活动。MLflow用追踪和评估工作流补充运营可见性，让团队检查应用行为、把代表性交互捕获到数据集，并评估对提示、模型、工具或编排的改动。文章称，这些反馈可以用于下一次迭代：在更大范围推广前比较改动、识别回归，并利用生产行为随时间改进质量、可靠性和成本。

• 需要重建的内容：用了什么信息、调用了哪些工具、哪个模型处理任务、应用了哪些策略、行为在哪里偏离预期。
• Unity Gateway的遥测范围：追踪、使用量、成本、工具活动。
• MLflow的作用：追踪、评估、把代表性交互捕获为数据集、比较改动、识别回归。

组合与复用：新工作流可以继承已有的受治理基础设施

文章称，更广泛的业务工作流通常会涉及不止一个agent、模型或工具。一个组件可能理解用户请求，另一个分析数据，一个确定性系统可能执行计算或更新业务流程。当周围基础设施已经共享时，组合这些组件的能力会更有价值。

按文章描述，Omnigent为用不同harness构建的agent提供公共接口，Agent Bricks提供更广泛的平台来构建和运营由此产生的agent舰队。同一套受治理的上下文和控制可以贯穿工作流。随着团队构建更多应用，agent、工具、技能和业务上下文可以成为可复用的构建块，新工作流可以依托已有的、受治理且可观测的基础设施，而不是创建另一个孤立栈。

文章最后称，模型和harness会继续变化，企业不需要标准化到其中某一个就能成功扩展；需要标准化的是它们周围的基础设施，让新agent继承同一套上下文、控制和运营模式，而不制造新一层AI sprawl。文章还提到可通过Agent Bricks CLI用几行代码开发agent，并集成Unity Gateway的模型容量、Databricks基础设施上的Runtime，以及由MLflow支持的agent追踪。

需要说明的是，上述产品能力和定位均来自Databricks博客，文章没有给出部署规模、成本节省比例或生产效果的量化数据，也属于厂商视角的表述。

• 文章提到的可复用构件：应用、agent、工具、技能、业务上下文。
• Databricks的结论：不要求企业统一模型或harness，而是统一周围的基础设施。
• Agent Bricks CLI被描述为可用几行代码开发agent，并接入Unity Gateway、Runtime和MLflow追踪。