Databricks：企业 Agent 规模化需统一上下文与管控层
Databricks 提出企业 Agent 规模化要靠选择、上下文、控制三层共享底座，避免每个 Agent 都变成独立的集成与治理项目。
构建单个 Agent 越来越容易，但在企业内运营大量 Agent 是另一回事：各团队各自接线，会造成集成重复、策略不一致、成本上升、上下文割裂。Databricks 联合 OpenAI、Stellantis 讨论后认为，规模化的关键是共享的选择、上下文与控制三层基础设施。
正文摘录
当 agent 从回答问题走向跨数据、模型与业务系统执行动作时，企业需要一套共享底座，来支撑选择（choice）、上下文（context）与控制（control）。 构建一个 agent 正变得越来越容易。能力更强的模型和 coding agent 让构建与迭代速度大幅提升。但在整个企业范围内运营大量 agent，是另一个问题。 当 agent 从回答问题转向执行动作，它们越来越依赖一张由模型、企业数据、业务语义、工具和应用织成的网。一个 workflow 可能需要检索受治理的数据、选择模型、调用多个工具、把工作交接给另一个 agent，最后更新某个业务系统 —— 全程都要以正确的权限运行，并留下足够的 trace（追踪记录），以便事后理解究竟发生了什么。 当每个团队各自独立地拼接这些环节时，一种新的 AI sprawl（AI 蔓延，指集成与治理的重复膨胀）就会出现：重复的集成、不一致的策略、膨胀的 AI 支出、碎片化的上下文，以及随着 agent 数量增长而越来越难改动的应用。 难点在于：如何扩展这些应用，而不是让每个应用背后的基础设施成倍增长。 我们最近邀请 Databricks、OpenAI 和 Stellantis 一起探讨：在生产环境中扩展 agentic 应用究竟需要什么。一个核心主题是：agent 越强大、越自主，它周围的基础设施就越重要。 在企业级规模上，这套基础设施需要提供三样东西：选择（choice），让团队能随着技术演进使用合适的模型、工具和框架；上下文（context），让 agent 能在受治理的企业数据和业务语义上工作；控制（control），让权限、策略、评估、可观测性和成本管理在应用增长时保持一致。 在 Databricks 上，这套底座把 Agent Bricks、Omnigent 和 Unity Gateway 整合在一起。