datainfra前沿动态 · Vol.26

Databricks开源Omnigent元编排AI代理编码工作流；Genie App Builder+App Spaces+Serverless Micro Apps三件套开启Governed Vibe Coding时代；阿里云AgentRun英文博客发布Function Compute驱动的AI代理可抛弃工作空间；Databricks 7/1-7/3释放Okta自动身份GA+Lakeflow Connect行过滤GA+Gemini 3.1 Flash Image+Veeva Vault+MySQL集成CDC等多项平台升级

第二十六期聚焦DataInfra四条动态：7月4日Databricks开源Omnigent元编排框架——通过共享会话+护栏+人在回路协调多个AI编码代理，让开发者把每个子任务路由到最合适的模型，单一模型无法应对复杂编码工作流的痛点被'meta-harness'架构系统化解决；7月3日Databricks通过X公告开放Genie App Builder私有预览——配合App Spaces（治理边界）+Genie App Builder（数据感知AI应用构建器）+Serverless Micro Apps（scale-to-zero轻量运行时）三件套，把'vibe coding'从'消费者工具'提升为'受治理的企业开发模式'，Databricks Apps活跃运行数近翻倍+3倍周活用户数印证'无治理vibe coding'已到企业采用临界点；7月3日阿里云发布英文博客'Giving Your AI Agent a Disposable Workspace with Alibaba Cloud AgentRun'——以函数计算（FC）为底座，为AI代理提供Serverless可抛弃执行工作空间，单次沙箱最长存活数小时+空闲即时回收+每次任务全新基线+MicroVM内核级隔离，把'沙箱'从'虚拟化附属品'演化为'Agentic AI基础设施原生形态'，让'运行未信任代码+响应未信任输入'的经典威胁模型在结构上不可能；7月1-3日Databricks 7月平台release notes多连发——Okta自动身份管理GA（无需SCIM即可在identity-federated工作区直接搜索和添加用户+组，Okta为群组成员关系单一信源）+Lakeflow Connect行过滤GA（WHERE子句式条件选择性摄取，初始加载+增量更新均生效，支持Google Analytics/Salesforce/ServiceNow及所有查询型连接器）+Gemini 3.1 Flash Image+Gemin 3 Pro Image作为Databricks托管模型上线Model Serving（通过Foundation Model APIs访问）+Veeva Vault连接器Beta（Direct Data API摄取标准/自定义/系统/审计表，OAuth 2.0 M2M经Microsoft Entra ID认证）+MySQL集成CDC管道Beta（单管道融合提取+应用，免去独立摄取网关）+Unity AI Gateway预算7月GA（跨AWS/Azure/GCP，共享+每用户上限，邮件告警+使用阻断）+7月初Genie Spaces更名为Genie Agents（功能名更准反映能力）。四条动态共同指向数据基础设施的'AI代理生产化'主线：Omnigent把'多代理协调'从单点工具演化为'meta-harness系统架构'，Genie App Builder三件套把'vibe coding'纳入'治理边界+数据感知+成本可控'的企业轨道，阿里云AgentRun把'可抛弃执行工作空间'从'虚拟化附属'提升为'Agentic AI基础设施原生形态'，Databricks 7月release notes把'身份治理+行级摄取+多模态模型+行业连接器+集成CDC+AI预算+品牌一致性'七件事并行推进——AI代理正从'演示与试点'走向'企业生产'。

DataInfra Databricks Omnigent Open Source Meta-Harness Multi-Agent Coding Orchestration Shared Sessions Guardrails Human-in-the-Loop AI Coding Agent Meta-Harness Architecture Genie App Builder Governed Vibe Coding App Spaces Serverless Micro Apps AppKit TypeScript SDK Unity Catalog Semantics scale-to-zero Enterprise Vibe Coding Data-Aware AI Builder Alibaba Cloud AgentRun Disposable Workspace Function Compute MicroVM Kernel-Level Isolation Serverless Sandbox Agentic AI Infrastructure Untrusted Code Execution Per-Task Sandbox Bounded Blast Radius Databricks Release Notes Okta Automatic Identity Management SCIM-less Identity Federated Workspace Lakeflow Connect Row Filtering WHERE Clause Google Analytics Salesforce ServiceNow Gemini 3.1 Flash Image Gemini 3 Pro Image Foundation Model APIs Veeva Vault OAuth 2.0 M2M Microsoft Entra ID MySQL Integrated CDC Single Pipeline Unity AI Gateway Budgets Per-User Limits Spend Controls Genie Spaces Genie Agents AI Agent Production 数据基础设施 DataInfra前沿动态 Vol.26

第二十六期追踪到DataInfra领域四条重要动态：7月4日Databricks开源Omnigent元编排框架——通过共享会话+护栏+人在回路协调多个AI编码代理，让开发者把每个子任务路由到最合适的模型，单一模型无法应对复杂编码工作流的痛点被’meta-harness’架构系统化解决；7月3日Databricks通过X公告开放Genie App Builder私有预览——配合App Spaces（治理边界）+Genie App Builder（数据感知AI应用构建器）+Serverless Micro Apps（scale-to-zero轻量运行时）三件套，把’vibe coding’从’消费者工具’提升为’受治理的企业开发模式’，Databricks Apps活跃运行数近翻倍+3倍周活用户数印证’无治理vibe coding’已到企业采用临界点；7月3日阿里云发布英文博客’Giving Your AI Agent a Disposable Workspace with Alibaba Cloud AgentRun’——以函数计算（FC）为底座，为AI代理提供Serverless可抛弃执行工作空间，单次沙箱最长存活数小时+空闲即时回收+每次任务全新基线+MicroVM内核级隔离，把’沙箱’从’虚拟化附属品’演化为’Agentic AI基础设施原生形态’，让’运行未信任代码+响应未信任输入’的经典威胁模型在结构上不可能；7月1-3日Databricks 7月平台release notes多连发——Okta自动身份管理GA（无需SCIM即可在identity-federated工作区直接搜索和添加用户+组，Okta为群组成员关系单一信源）+Lakeflow Connect行过滤GA（WHERE子句式条件选择性摄取，初始加载+增量更新均生效，支持Google Analytics/Salesforce/ServiceNow及所有查询型连接器）+Gemini 3.1 Flash Image+Gemin 3 Pro Image作为Databricks托管模型上线Model Serving（通过Foundation Model APIs访问）+Veeva Vault连接器Beta（Direct Data API摄取标准/自定义/系统/审计表，OAuth 2.0 M2M经Microsoft Entra ID认证）+MySQL集成CDC管道Beta（单管道融合提取+应用，免去独立摄取网关）+Unity AI Gateway预算7月GA（跨AWS/Azure/GCP，共享+每用户上限，邮件告警+使用阻断）+7月初Genie Spaces更名为Genie Agents（功能名更准反映能力）。四条动态共同指向数据基础设施的’AI代理生产化’主线：Omnigent把’多代理协调’从单点工具演化为’meta-harness系统架构’，Genie App Builder三件套把’vibe coding’纳入’治理边界+数据感知+成本可控’的企业轨道，阿里云AgentRun把’可抛弃执行工作空间’从’虚拟化附属’提升为’Agentic AI基础设施原生形态’，Databricks 7月release notes把’身份治理+行级摄取+多模态模型+行业连接器+集成CDC+AI预算+品牌一致性’七件事并行推进——AI代理正从’演示与试点’走向’企业生产’。

Databricks开源Omnigent元编排框架：让多个AI编码代理在共享会话+护栏+人在回路中协同工作

事件概述

7月4日，Databricks通过X官方账号正式发布Omnigent开源项目——“Say hello to Omnigent 👋 Databricks’ open-source meta-harness helps developers orchestrate AI coding workflows across multiple coding agents, making it easy to use the right model for each task.” Omnigent是Databricks6/16 Data + AI Summit 2026上宣布的Managed Omnigent on Databricks（Beta版）的开源基础——当时作为Unity AI Gateway Agent Registry的托管组件出现（Vol.25已报道），但其开源元编排框架本体直到7/4才在X上正式亮相。Omnigent的核心定位是”meta-harness”——这是一个”元编排层”概念：传统的AI编码代理是单一模型完成单一任务（Claude Code、Codex、Cursor等都遵循此模式），但复杂编码工作流（如多文件重构+测试生成+文档更新+PR创建）需要多个不同能力的代理协同。Omnigent正是”在多个AI编码代理之上的协调层”——支持共享会话、护栏（guardrails）、人在回路（human-in-the-loop），让开发者把每个子任务路由到最合适的模型。Databricks同时发布YouTube视频（@cole_medin讲解meta-harness为何成为现代AI编码的重要组成部分）。Omnigent开源意味着多代理协调从’Databricks专有产品’走向’开源生态基础设施’——任何开发者都可以基于Omnigent构建自己的多代理编码工作流。

技术解析

  • Meta-harness：从”单一代理”到”代理之上”的架构跃迁：传统AI编码代理的架构是”单一模型+单一上下文窗口”——开发者输入需求，单一模型在单一上下文窗口中完成所有工作（理解需求、规划步骤、生成代码、运行测试、修复错误）。这种架构的问题在于单一模型无法在所有任务上都最优——例如，Claude Sonnet 4.5擅长长程推理但代码生成速度一般，GPT-5擅长代码生成但调试能力弱，Gemini 2.5 Pro擅长多模态但响应时间长。Meta-harness的核心思想是”让每个子任务由最合适的代理完成”——例如，任务规划由Claude Sonnet 4.5完成（强推理），代码生成由GPT-5完成（强代码），测试生成由Codex完成（强测试模式），错误诊断由Gemini完成（强多模态可读截图）。所有代理共享同一会话上下文——一个代理的输出对其他代理可见，避免”每个代理都要重新理解整个项目”的低效。这与Vol.10报道的阿里云AgentTeams（基于Matrix协议异构智能体统一治理+Leader-Worker协作）是同一思路——“异构代理协同”是AI代理时代的核心架构。Meta-harness是AgentTeams的”编码工作流特化”——把”多代理协调”从通用Agent框架落实到具体的编码场景。

  • Shared Sessions：让多个代理在统一上下文中协同：Omnigent的核心技术亮点是Shared Sessions——多个AI编码代理共享同一会话状态（包括文件状态、终端输出、错误日志、用户输入历史）。这意味着一个代理修改了文件，下一个代理立即可见（无需重新读取或同步）；一个代理产生的错误日志，下一个代理可以基于此分析（无需重新运行）；用户在一个代理中提供的输入，所有代理都可以参考（无需重复输入）。Shared Sessions的技术实现是”统一的状态存储层”——Omnigent维护一个中央状态库，所有代理通过该状态库读写。对比传统多代理架构（每个代理有独立状态）：传统架构要么需要”显式状态传递”（代理A完成→序列化结果→传递给代理B），要么需要”共享文件系统”（代理A写文件→代理B读文件），要么需要”完全独立的代理”（每个代理只做自己的部分不协同）。Shared Sessions让”多代理”真正成为”协同的多代理”而非”独立工作的多个代理”。这与Vol.7报道的Databricks Instructed-Retriever-1（并行测试时计算替代序列Agent推理）的”测试时计算扩展”形成”运行时架构扩展”——前者是单一模型的并行推理，后者是多模型的协同工作。

  • Guardrails：让AI代理在企业安全边界内工作：Omnigent内置Guardrails机制——定义AI代理可以做什么、不能做什么、需要什么审批。典型guardrails：（1）代码修改范围限制——代理只能修改指定目录的文件；（2）命令执行限制——代理只能执行白名单内的shell命令；（3）外部网络访问限制——代理不能访问特定域名；（4）敏感文件保护——代理不能读取.env、secrets.yaml等敏感文件；（5）审批触发条件——当代理尝试”删除文件”或”推送到主分支”时触发人类审批。Guardrails在meta-harness层执行——所有代理的所有操作都必须通过guardrails检查，即使是”最强大”的代理也不能突破guardrails。这与Vol.25报道的Databricks Unity AI Gateway升级为Agent Registry的Contextual Service Policies（基于用户/代理/模型/MCP/工具/请求响应内容的策略判定）是同一思路——“AI代理治理”需要在执行层强制执行，而非依赖代理的”自觉”。

  • Human-in-the-Loop：让人类在关键决策点介入：Omnigent支持Human-in-the-Loop（HITL）工作流——在关键决策点（如删除文件、合并PR、修改配置、推送代码），系统暂停并请求人类审批。HITL的实现方式：（1）代理发起操作→（2）Omnigent检查是否需要HITL→（3）如果是，向用户展示操作详情+风险评估→（4）用户批准/拒绝/修改→（5）代理继续执行。HITL不是”事后审计”，而是”事前审批”——避免”AI代理做出错误决策后只能回滚”的被动。HITL的触发条件可配置——简单的”添加日志”操作无需HITL，“修改数据库schema”操作必须HITL，“删除生产数据”操作需要多人HITL。HITL与Guardrails的差异：Guardrails是”绝对禁止”（某些操作根本不允许），HITL是”需要审批”（某些操作允许但需要人类判断）。两者配合使用形成”绝对边界+弹性判断”的AI代理安全体系。

  • Omnigent开源的战略意义：从Databricks产品到生态基础设施：7/4开源的Omnigent与6/16 DAIS宣布的Managed Omnigent on Databricks（Beta）形成”开源核心+托管增强”的双层架构：开源Omnigent提供”meta-harness的开放实现”——任何人都可以免费使用、修改、贡献；Managed Omnigent提供”Databricks平台增强”——共享历史记录、远程访问、协作功能、基于Lakebox的隔离云执行、Unity AI Gateway治理集成。开源+托管的双层模式与Databricks的Delta Lake策略完全一致——Delta Lake开源核心+Databricks平台托管增强。当Omnigent成为开源标准时，未来可能出现”基于Omnigent的第三方多代理产品”——类似Delta Lake的开放生态。Meta-harness是否会成为”多代理协调”的标准协议（如OpenTelemetry之于可观测性、AgentSkills之于代理技能）值得长期关注。

行业影响

Databricks开源Omnigent的深层意义不是”又一个AI编码工具发布”，而是“多代理协调”从”单点工具”演化为”meta-harness系统架构”的范式跃迁。

此前AI编码代理的格局是”一个代理统治一切”——Claude Code、Codex、Cursor、Aider等各自争夺”AI编码代理的No.1”位置。但复杂编码工作流的现实是”没有任何一个代理能在所有任务上都最优”——长程推理、代码生成、测试生成、错误诊断、文档生成、PR管理每个任务都有”最适合的代理”。Meta-harness的出现把竞争焦点从”哪个代理最强”转向”哪个meta-harness最会协调多个代理”——这与Vol.10报道的阿里云AgentTeams（异构智能体统一治理）和Vol.13报道的Pulumi Agent基础设施时代（临时云账号+Neo集成目录）是同一方向：“AI时代的竞争是生态竞争而非单点工具竞争”。

将本期与Vol.25报道的Databricks Unity AI Gateway升级为Agent Registry对比，Omnigent是”协调多个AI代理”（runtime层），Agent Registry是”治理多个AI代理”（governance层）。两者都是”多代理”时代的Databricks布局——一个解决”代理怎么协同”，一个解决”代理怎么治理”。当Omnigent开源+Agent Registry托管时，Databricks在多代理领域形成了”开放协调层+集中治理层”的双层架构。

将本期与Vol.7报道的Databricks Instructed-Retriever-1（并行测试时计算替代序列Agent推理）对比，Instructed-Retriever-1是”单一模型的测试时扩展”（让一个模型在推理时并行多次），Omnigent是”多模型的运行时扩展”（让多个模型在执行时协同）。两者都是”AI代理从单一走向多样”的路径——前者通过”同一模型做多次”提升性能，后者通过”不同模型各做一次”提升质量。当Instructed-Retriever-1的”并行推理”+Omnigent的”并行执行”组合时，AI代理的”质量+速度”可以同时优化。

将本期与Vol.17报道的阿里云Agent Infra（AgentTeams基于Matrix协议异构智能体统一治理）对比，AgentTeams是”通用Agent的多代理协调”（适用于任何Agent场景），Omnigent是”编码Agent的多代理协调”（特化于编码场景）。两者都体现”异构代理协同”是AI代理时代的关键能力——但AgentTeams的目标是”任何Agent都能协同”，Omnigent的目标是”编码Agent的协同效果最好”。当通用多代理框架（AgentTeams/Matrix协议）+专用多代理框架（Omnigent/编码场景）同时演进时，“多代理”从概念走向完整产品形态。

相关链接

Databricks Genie App Builder三件套开启Governed Vibe Coding时代：App Spaces+Serverless Micro Apps+AppKit SDK让企业vibe coding受治理

事件概述

7月3日，Databricks通过X官方账号正式公告Genie App Builder进入私有预览——“Introducing Genie App Builder for AI-assisted creation with all Databricks context. Genie App Builder is a purpose-built AI app authoring tool with native awareness of your data assets, Unity Catalog semantics and workspace context.” 这是继6/16 Data + AI Summit 2026上首次宣布Governed Vibe Coding战略后，首次正式开放私有预览申请。Genie App Builder不是单一产品，而是三件套：（1）App Spaces——新的治理边界，为应用组配置资源、访问管理、安全策略；（2）Genie App Builder——数据感知的Databricks原生AI应用构建代理，理解数据资产、Unity Catalog语义、工作区上下文；（3）Serverless Micro Apps——scale-to-zero轻量应用运行时，空闲时自动停止计费。底层技术是AppKit TypeScript SDK——处理缓存、遥测、重试、Databricks数据资源集成，让AI构建代理专注于”把用户意图转化为结构化应用逻辑”。关键数据——Databricks Apps活跃运行数近翻倍+3倍周活用户数。这意味着“无治理vibe coding”已经触达企业采用临界点，Databricks需要为”已经大量采用vibe coding”的企业提供”治理轨道”，否则这些应用会成为”无监管的数据资产”。

技术解析

  • App Spaces：让治理从”按应用”演化为”按空间”：传统Databricks Apps的治理模型是”每个应用单独配置”——管理员需要为每个应用单独设置资源限制、访问控制、安全策略、API scopes。当应用数量增加时，这种”按应用”的治理模式不可扩展——100个应用意味着100次单独配置、100次单独审计、100次单独合规检查。App Spaces的解决思路是”按空间治理”——管理员在App Space级别配置资源配额、访问管理、API scopes、安全策略，所有该空间内的应用自动继承这些配置。关键技术：（1）资源继承——App Space的CPU/内存/存储配额自动应用到所有内部应用；（2）访问管理继承——App Space的访问控制列表（ACL）自动应用到所有内部应用；（3）API scopes继承——App Space的on-behalf-of-user API scopes自动应用到所有内部应用；（4）安全策略继承——App Space的PII防护、提示注入防御、合规审计自动应用到所有内部应用。App Spaces让”治理”从”应用级”提升为”空间级”——管理员一次性配置，整个空间内的所有应用都受治理。这与Vol.25报道的Databricks Unity AI Gateway Agent Registry（Contextual Service Policies基于请求/响应内容的运行时策略判定）是同一思路——“治理对象”从”单个资产”提升为”空间内所有资产”。

  • Genie App Builder：数据感知的AI应用构建代理：Genie App Builder是Databricks原生的AI应用构建代理——开发者（业务分析师、领域专家、运营负责人）用自然语言描述应用需求（或上传截图），Genie自动生成开发计划+可工作的应用预览，开发者可以迭代调整直到结果符合预期。关键技术差异——Genie App Builder原生感知三层Databricks上下文：（1）数据资产层——理解Lakehouse中的表、视图、Metric Views、Vector Search索引；（2）Unity Catalog语义层——理解业务定义、访问控制、数据血缘、Owner；（3）Workspace配置层——理解工作区资源限制、用户权限、连接器配置。对比通用vibe coding工具（如v0、Lovable、Bolt）：通用工具不感知Databricks数据资产，生成的代码需要”导出→手工适配→导入Databricks”；Genie App Builder直接在Databricks上生成可运行的应用，无需导出导入。Genie App Builder的”数据感知”是Databricks相对于通用vibe coding工具的核心差异化——通用工具生成”通用应用”，Genie生成”Databricks原生应用”。这与Vol.17报道的Databricks Instructed-Retriever-1（并行测试时计算替代序列Agent推理）的”数据感知”是同一方向——“AI代理对数据/上下文的感知深度”决定AI代理的实用性。

  • Serverless Micro Apps：scale-to-zero让应用组合的经济性大幅提升：传统Databricks Apps使用长期运行的serverless runtime——应用启动后保持运行状态，即使空闲也持续消耗资源。Serverless Micro Apps是新的轻量运行时**——基于micro-VMs，应用启动时间短（毫秒级），空闲时自动scale-to-zero（不消耗资源），有请求时自动启动。这意味着”应用组合的成本”从”持续运行成本”变为”按需运行成本”——企业可以部署1000个应用而不需要为1000个应用持续付费，只需为”实际被使用”的应用付费。典型应用场景：（1）低频内部工具——每月只被使用几次的工具；（2）季节性应用——只在特定季节/事件期间被使用的应用；（3）实验性应用——正在评估是否有用的应用；（4）长尾应用——少数用户使用但对企业重要的应用。Serverless Micro Apps让”广泛部署应用”在经济上可行——企业不再因为”应用空闲成本”而限制应用数量，可以让业务用户根据实际需求自由构建应用**。这与Vol.10报道的ClickHouse Open House 2026 Day 1的多阶段分布式查询执行（私有预览）和Vol.24报道的OpenSearch Service新日志分析引擎GA（97%代码从零重写）是同一方向——“按需付费+闲置不收费”成为云原生基础设施的新标准。

  • AppKit TypeScript SDK：让AI构建代理专注于业务逻辑：Genie App Builder的底层技术是AppKit TypeScript SDK——处理缓存、遥测、重试、与Databricks数据资源的集成。AppKit让AI构建代理不需要关心”技术细节”——AI代理只需要”把用户意图转化为应用逻辑”，应用的技术实现（如何调用Databricks数据资源、如何缓存、如何监控）由AppKit处理。AppKit的核心价值：（1）加速AI代理的开发——AI代理不需要”重新发明轮子”调用Databricks API；（2）保证应用质量——所有应用都使用统一的”最佳实践”SDK（缓存策略、错误处理、监控告警）；（3）简化应用维护——AppKit升级时所有应用自动获得新能力。这与Vol.5报道的MinIO MemKV（终结AI重计算税）和Vol.9报道的LoongCollector+ACS Agent Sandbox是同一方向——“AI代理基础设施抽象”让AI代理专注于业务而非技术。

  • 关键数据印证：Databricks Apps已达企业采用临界点：Databricks公开数据——Databricks Apps活跃运行数近翻倍（past 6 months）+3倍周活用户数。这意味着”无治理vibe coding”已经触达企业采用临界点——业务用户、运营负责人、领域专家已经开始大量使用vibe coding工具构建应用。问题是：这些应用是”在Databricks上”还是”在Databricks外”？ 如果Databricks不提供受治理的vibe coding环境，企业用户会绕开Databricks使用v0/Lovable/Bolt等通用工具，生成的应用脱离Databricks数据资产治理。Governed Vibe Coding的推出是Databricks的”防御性创新”——通过在Databricks平台内提供受治理的vibe coding能力，把vibe coding的工作流留在Databricks生态中。这与Vol.18报道的腾讯云三层Agent-Ready数据平台（DataBuddy+WeData+AI原生底座）的”Agent-Ready基础设施”是同一战略——“让AI代理工作在企业数据基础设施内”而非”让AI代理在企业数据基础设施外”。

行业影响

Databricks Genie App Builder三件套的深层意义不是”vibe coding的企业版”，而是“vibe coding从消费者工具演化为受治理的企业开发模式”的范式跃迁。

此前vibe coding的定位是”个人开发者的快速原型工具”——开发者用v0/Lovable/Bolt快速生成应用原型，但这些应用缺乏企业级治理（无统一认证、无访问控制、无审计日志、无成本控制）。结果是：vibe coding应用是”企业数据资产的黑洞”——绕过IT部门、绕过安全团队、绕过合规审计，企业的关键业务流程运行在无治理的应用上。Databricks的Governed Vibe Coding是“把vibe coding拉回企业治理轨道”——通过App Spaces的”空间级治理”+Serverless Micro Apps的”成本可控”+AppKit SDK的”企业级质量”三件套，让vibe coding从”消费者工具”演化为”受治理的企业开发模式”。

将本期与Vol.25报道的Databricks Unity AI Gateway升级为Agent Registry对比，Agent Registry是”已有AI代理的治理”（如何管理已存在的AI资产），Genie App Builder三件套是”新AI应用的治理”（如何管理新创建的应用资产）。两者都是”AI资产治理”的Databricks布局——前者管”AI代理”，后者管”AI应用”。当AI代理+AI应用都纳入Databricks治理时，企业的AI资产从”无序”走向”系统化治理”。

将本期与Vol.7报道的Databricks Instructed-Retriever-1（并行测试时计算替代序列Agent推理）对比，Instructed-Retriever-1是”测试时计算扩展”（让推理更准），Genie App Builder是”测试时应用构建”（让开发更快）。两者都是”AI代理从单点能力走向系统能力”——前者提升”AI代理的推理质量”，后者提升”AI代理的开发效率”。当AI代理既”更准”又”更快”地构建应用时，AI代理时代的”应用爆发”成为可能。

将本期与Vol.18报道的腾讯云DataBuddy+WeData Agent-Native统一控制面对比，DataBuddy是”业务数据智能体”（让业务用户通过自然语言操作数据），Genie App Builder是”业务应用智能体”（让业务用户通过自然语言构建应用）。两者都是”业务用户直接构建”的AI能力——前者让业务用户消费数据，后者让业务用户生产应用。当业务用户既能消费数据又能生产应用时，AI代理时代”业务用户的数字化能力”得到根本提升——这是”AI平民化”在企业落地的重要里程碑。

相关链接

阿里云AgentRun英文博客发布：函数计算驱动的可抛弃AI代理工作空间重新定义Agentic AI基础设施原生形态

事件概述

7月3日，阿里云印度尼西亚团队解决方案架构师Rizky Andriawan在Alibaba Cloud Community发布英文技术博客’Giving Your AI Agent a Disposable Workspace with Alibaba Cloud AgentRun’——介绍阿里云AgentRun产品的Serverless可抛弃执行工作空间设计哲学。AgentRun是阿里云函数计算（Function Compute，FC）团队推出的一站式Agentic AI基础设施平台——以高代码为核心，开放生态、灵活组装，为企业级Agent应用提供开发、部署、运维全生命周期管理。核心创新是**“可抛弃执行”（disposable execution）——AI代理每次执行任务都获得全新的、隔离的、运行后即销毁的执行工作空间**，空闲时不产生成本，无任务时不占用资源。关键设计原则：（1）保证清洁基线——每次任务从相同的已知良好基线开始，无”上次运行遗留”；（2）有界爆炸半径——代理填满磁盘、运行可疑命令、删除自己的文件，影响范围被隔离在单个沙箱内；（3）任务间无污染——单任务沙箱结构上不可能出现”上次任务遗留凭证”导致下次任务泄露；（4）成本跟随工作而非日历——基于Serverless，没有空闲成本，按使用付费。AgentRun的发布意味着阿里云把’Agentic AI基础设施’作为’云原生基础设施’的下一形态——把”Serverless”的极致弹性+按量付费与AI原生应用场景深度融合。

技术解析

  • 可抛弃执行的四大设计原则：从”妥协”到”升级”的范式：传统沙箱的设计是”持久化+隔离”——一个长期运行的虚拟机/容器，代理在其中执行任务。这种设计的痛点：（1）“上周二能跑这周五挂”——上次运行的残留文件、安装的包、修改的环境变量导致下次运行结果不同；（2）“一个任务的错误影响其他任务”——磁盘填满、内存泄漏、配置污染可能跨任务传播；（3）“空闲也收费”——1000个代理的1000个长生命周期VM，即使空闲也产生费用；（4）“凭证泄露”——上次任务的凭证可能存储在文件系统中，下次任务可以读取。AgentRun的”可抛弃执行”用”每次任务全新沙箱+运行后立即销毁”同时解决这四个问题。Rizky在博客中给出精辟总结——“‘disposable’ sounds like a compromise. For execution, it’s an upgrade”（“可抛弃”听起来像妥协。对于执行，它是升级）。

  • 安全隔离的MicroVM内核级隔离：AgentRun基于阿里云函数计算（FC）构建——FC使用神龙裸金属+RunD安全容器技术，每个执行环境运行在独立的MicroVM中。MicroVM隔离相比传统Docker容器隔离：（1）内核级隔离——每个MicroVM有独立内核，容器逃逸攻击无法跨MicroVM传播；（2）硬件级资源隔离——CPU/内存/网络资源在硬件层分配，无资源争抢；（3）独立文件系统——每个MicroVM有独立文件系统，跨任务文件不可见。这意味着AgentRun的沙箱是”工业级安全隔离”——未信任代码（AI代理自己生成的代码）运行在MicroVM中+未信任输入（用户提供的网页/文档）由AI代理在MicroVM中处理——即使AI代理被”提示注入”攻击（poisoned web page）执行了恶意命令，恶意命令的影响范围被限制在单个MicroVM内，该MicroVM在任务结束后被销毁，恶意代码的痕迹全部消失。这是”运行未信任代码+响应未信任输入”经典威胁模型的结构性解决方案——不是”检测恶意行为”（事后），而是”恶意行为无法跨沙箱传播”（事前）。这与Vol.10报道的华为云AgentSphere（100ms沙箱启动10万级/分钟批创）和Vol.9报道的阿里云LoongCollector+ACS Agent Sandbox是同一方向——“为AI代理提供安全的执行环境”是Agentic AI基础设施的核心能力。

  • 从Copilot到Agent：执行能力的质变：博客深刻指出AI应用从Copilot到Agent的质变——Copilot模式是”AI生成建议，人类执行”，Agent模式是”AI自动执行，人类监督”。这种质变对基础设施的影响：（1）执行环境——Copilot只需要LLM推理，Agent需要完整的执行环境（文件系统、终端、网络、浏览器）；（2）工具调用——Copilot只需要生成文本，Agent需要调用外部工具（API、数据库、浏览器）；（3）状态管理——Copilot无状态，Agent需要维护会话状态；（4）错误处理——Copilot生成错误建议可被人类忽略，Agent的错误执行可能产生真实副作用（删文件、发邮件、转账）。AgentRun的”可抛弃执行”正是为Agent模式设计——沙箱+工具+状态+错误处理都是Agent的”执行能力”，这些能力需要在受控环境中运行。

  • “一次性沙箱+持久化记忆”的两层架构：博客提出AI代理的两层架构：（1）一次性沙箱（disposable sandbox）——执行环境是临时的，任务结束后销毁；（2）持久化记忆（persistent memory）——学习成果是永久的，存储在沙箱外。这个架构的核心思想：“Trial-and-error happens in a cell you discard; the lessons are filed in a store you keep”（试错发生在你丢弃的牢房中；教训存放在你保留的存储中）。对比传统架构（执行环境+记忆都在同一VM中）：传统架构的问题在于”错误实验的痕迹污染未来实验”——例如，代理在调试时安装了错误的Python包，这些包残留在VM中，未来任务可能因为残留包而失败。AgentRun的两层架构让”试错”和”学习”彻底分离——试错在沙箱中进行（每次全新），学习在外部存储中进行（永久保留）。这与Vol.10报道的ClickHouse Open House 2026 Day 1的ClickHouse Agents（基于Claude的完全托管代理分析服务）的”记忆+多Agent工作流+沙箱代码解释器”是同一思路——“AI代理的’执行’和’记忆’需要分离”是AI代理时代的关键架构。

  • 代码解释器+浏览器沙箱+工具市场的开箱即用能力：AgentRun提供开箱即用的执行模板——Code Interpreter（代码解释器）、Browser Use（浏览器沙箱）、All In One（一站式）。这些模板的意义：（1）降低AI代理开发的门槛——开发者不需要”从零搭建Python环境+安装Jupyter+配置浏览器自动化”，直接使用AgentRun提供的模板；（2）保证执行环境的一致性——所有AI代理的代码执行环境都是相同的（相同的Python版本、相同的库版本、相同的系统配置），避免”在我机器上能跑”问题；（3）支持快速迭代——开发者可以专注于AI代理的业务逻辑（如何规划、如何决策、如何调用工具），不关心基础设施细节。这与Vol.17报道的Databricks AI Search（Vector Search更名+全文搜索+混合搜索）的”开箱即用能力”是同一方向——“AI代理时代的平台竞争”从”提供原始能力”转向”提供开箱即用的最佳实践”。

行业影响

阿里云AgentRun英文博客发布的深层意义不是”又一款沙箱产品”，而是“可抛弃执行工作空间”从”虚拟化附属”演化为”Agentic AI基础设施原生形态”的范式跃迁。

此前”沙箱”在云计算中是一个相对边缘的产品——主要用于”运行未信任的第三方代码”（如AWS Lambda的execution environment、Google Cloud Run的sandbox、Azure Container Apps的isolation）。这些沙箱是”虚拟化的附属”——为安全需求而存在，不是云的核心抽象。AgentRun把”可抛弃执行”作为Agentic AI基础设施的原生形态——沙箱不是”安全的附属”，而是”AI代理运行的基础”。这与Vol.10报道的ClickHouse Open House 2026（Postgres Managed+多阶段查询+ClickStack+Agents）的’Agentic Data Stack’是同一趋势——“Agentic”成为新的产品前缀，标志着一类新产品形态的诞生。

将本期与Vol.10报道的华为云AgentSphere（100ms沙箱启动10万级/分钟批创）对比，AgentSphere是”沙箱+CCE容器服务”的集成（让企业可以在Kubernetes上快速创建沙箱），AgentRun是”沙箱+函数计算”的集成（让企业可以在Serverless上快速创建沙箱）。两者都把”沙箱”作为Agentic AI基础设施的核心能力，但实现路径不同：AgentSphere走”Kubernetes+沙箱”路径（适合已有K8s基础设施的企业），AgentRun走”Serverless+沙箱”路径（适合希望”零运维”的企业）。两条路径并行演进，企业可以根据自己的基础设施现状选择。

将本期与Vol.7报道的Databricks Instructed-Retriever-1（并行测试时计算替代序列Agent推理）对比，Instructed-Retriever-1是”测试时计算的扩展”（让推理在沙箱中并行多次），AgentRun是”测试时执行的扩展”（让执行在沙箱中可抛弃进行）。两者都是”测试时”的能力扩展——前者提升”AI代理的推理质量”，后者提升”AI代理的执行质量”。当AI代理既”想得更准”又”做得更安全”时，AI代理时代的”高质量输出”成为可能。

将本期与Vol.18报道的阿里云Dragonwell Native Acceleration AI（AI驱动JFR分析自动发现Java/Scala优化机会）对比，Dragonwell是”Java应用的AI优化”（用AI优化现有应用），AgentRun是”AI代理的应用基础设施”（为AI代理提供应用基础设施）。两者代表”AI+应用”的双向融合——Dragonwell是”AI for Applications”（AI优化应用），AgentRun是”Applications for AI”（应用为AI服务）。当这两个方向同时演进时，AI与应用的关系从”AI嵌入应用”演化为”AI与应用共生”。

相关链接

Databricks 7/1-7/3平台release notes多连发：Okta自动身份GA+Lakeflow Connect行过滤GA+Gemini 3.1 Flash Image+Veeva Vault Beta+MySQL集成CDC Beta+Unity AI Gateway预算7月GA+Genie Spaces更名Genie Agents

事件概述

7月1-3日，Databricks 7月平台release notes多连发——七项平台升级并行推进。（1）Okta自动身份管理GA（7/3）——无需SCIM即可在identity-federated工作区直接搜索和添加用户+组，Okta为群组成员关系单一信源（source of record）；（2）Lakeflow Connect行过滤GA（7/2）——WHERE子句式条件选择性摄取，初始加载+增量更新均生效，支持Google Analytics/Salesforce/ServiceNow及所有查询型连接器；（3）Google Gemini 3.1 Flash Image和Gemini 3 Pro Image作为Databricks托管模型上线Model Serving（7/1）——通过Foundation Model APIs访问；（4）Veeva Vault连接器Beta（7/1）——Direct Data API摄取标准/自定义/系统/审计表，OAuth 2.0 M2M经Microsoft Entra ID认证；（5）MySQL集成CDC管道Beta（7/1）——单管道融合提取+应用，免去独立摄取网关；（6）Unity AI Gateway预算7月GA——跨AWS/Azure/GCP，共享+每用户上限，邮件告警+使用阻断；（7）7月初Genie Spaces更名为Genie Agents——功能名更准反映能力。七项升级体现Databricks平台在身份治理+行级摄取+多模态模型+行业连接器+集成CDC+AI预算+品牌一致性七个维度的同步演进。“7月GA的项目几乎覆盖了数据基础设施的每一层”——这是Databricks平台”成熟化+AI化”的标志性月份。

技术解析

  • Okta自动身份管理GA：去掉SCIM摩擦的统一身份体验：传统Databricks身份管理的痛点是”必须配置SCIM（System for Cross-domain Identity Management）才能同步用户+组”——SCIM配置复杂、运维成本高、对小团队不友好。Okta自动身份管理GA让”无需SCIM”——Databricks在identity-federated工作区（已通过OIDC/SAML联邦身份的工作区）中直接搜索Okta的用户+组，直接添加到工作区，Okta作为群组成员关系的单一信源（source of record）。关键差异：（1）无SCIM配置成本——管理员不需要在Okta侧配置SCIM应用；（2）即时用户添加——用户请求加入工作区时管理员实时搜索Okta添加，无需等待SCIM同步；（3）Okta为唯一信源——用户角色/组变更在Okta侧完成，Databricks自动跟随，避免”Okta+Databricks两个系统数据不一致”。这与Vol.20报道的Databricks External Lineage GA（注册外部资产Salesforce/MySQL/Tableau/Power BI）是同一思路——“让外部系统作为权威信源”是Databricks的统一战略，从身份到数据资产。

  • Lakeflow Connect行过滤GA：让数据摄取从”全量”走向”精准”：传统Lakeflow Connect的摄取模式是”全量+增量”——首次加载全量数据，之后增量同步新数据。痛点——很多场景不需要全量数据：（1）敏感数据——只摄取非PII数据，过滤PII数据；（2）历史数据——只摄取最近N天的数据，过滤历史数据；（3）特定子集——只摄取特定地区/产品线/客户群的数据。行过滤GA让用户用WHERE子句定义过滤条件——例如WHERE region = 'APAC' AND created_date > '2026-01-01'，只在初始加载+增量更新时摄取满足条件的行。关键能力：（1）性能提升——摄取数据量减少，摄取速度加快；（2）成本降低——摄取的数据量减少，存储成本降低；（3）数据最小化——满足”数据最小化”原则（GDPR、CCPA等合规要求）。支持范围——Google Analytics、Salesforce、ServiceNow三个SaaS连接器+所有查询型连接器。这与Vol.22报道的Databricks Liquid Clustering（行级并发替代文件级）和Vol.16报道的Databricks Cross-Engine ABAC（行级访问控制）是同一思路——“行级”是Databricks数据治理的细化方向。

  • Gemini 3.1 Flash Image+Gemin 3 Pro Image：多模态模型的Databricks原生化：Gemini 3.1 Flash Image和Gemini 3 Pro Image作为Databricks托管模型上线Model Serving——通过Foundation Model APIs直接访问。关键价值：（1）数据本地化——模型推理在Databricks平台内完成，数据不离开Databricks环境；（2）统一计费——通过Databricks统一计费，无需单独管理Google Cloud计费；（3）Unity Catalog治理——所有模型调用通过Unity AI Gateway治理（成本控制+payload logging+guardrails+tracing）；（4）即开即用——开发者不需要”申请Google Cloud访问+配置API key+管理凭证”，通过Databricks一键启用。Gemini 3.1 Flash Image是Google最新的轻量多模态模型——擅长快速图像理解+生成；Gemini 3 Pro Image是Google最新的高质量多模态模型——擅长复杂多模态推理。两者形成”速度+质量”的双选择。这与Vol.25报道的Databricks Unity AI Gateway升级为Agent Registry（管理MCP+技能+LLM端点+代理）是同一方向——“Databricks平台内的AI能力不断扩展”是平台AI化的核心。

  • Veeva Vault连接器Beta+MySQL集成CDC Beta：行业连接器+集成数据摄取的并行推进：Veeva Vault连接器Beta——为生命科学行业提供数据摄取能力，通过Direct Data API摄取标准对象、自定义对象、系统表、审计跟踪表；OAuth 2.0 M2M经Microsoft Entra ID认证。Veeva Vault是生命科学行业的事实标准——全球Top 20制药公司都在使用Veeva Vault管理临床试验、监管提交、质量管理。Databricks的Veeva Vault连接器让”生命科学行业数据进入Databricks”成为标准化能力。MySQL集成CDC管道Beta——传统的MySQL CDC需要”MySQL Gateway+Databricks Ingest”两个组件，集成CDC管道让”单管道融合提取+应用”——免去独立摄取网关。关键优势：（1）简化架构——无需部署+管理独立的Gateway；（2）降低延迟——提取和应用在同一管道，端到端延迟降低；（3）降低成本——无需为Gateway付费+运维。两个连接器代表Databricks在”行业连接器+集成数据摄取”两个维度的并行推进——前者扩展数据来源的多样性，后者简化数据摄取的架构。

  • Unity AI Gateway预算7月GA：AI代理的”成本可控”从Beta走向GA：Unity AI Gateway引入预算（Budgets）概念——管理员定义通过Unity AI Gateway和Genie管理的请求的支出阈值，包括共享上限和每用户上限，可配置邮件告警或使用阻断等动作。关键技术：（1）共享上限——整个工作区的总AI预算；（2）每用户上限——单个用户的AI预算；（3）告警+阻断——达到阈值时邮件告警或自动阻断。7月GA意味着预算功能从Beta进入生产可用——企业可以正式依赖AI预算做AI代理的成本治理。这与Vol.3报道的Unity AI Gateway初始Cost Controls（成本归因+智能路由）和Vol.25报道的Hard spend caps（硬性支出上限自动停止请求）是同一主线的演进——从”看见成本”→“限制成本”→“预算+告警”→“自动阻断”，AI代理的成本治理成为”系统级”而非”手动级”。

  • 7月初Genie Spaces更名为Genie Agents：品牌一致性的微妙调整：7月初，Databricks将Genie Spaces更名为Genie Agents——功能名更准反映能力。语义变化：（1）**“Spaces”强调”空间”（一个Genie Space是一个对话空间），偏重”容器”概念；（2）“Agents”**强调”代理”（一个Genie Agent是一个AI代理），偏重”AI能力”概念。品牌一致性：Databricks的AI代理品牌矩阵——Genie One（统一代理产品）+Genie Agents（原Genie Spaces，独立代理空间）+Genie App Builder（应用构建代理）+Genie Code（编码代理）+Agent Bricks（块状代理构建工具）——所有都以”Agent”为核心命名，品牌一致性显著提升。这是看似微小的品牌调整，实际是Databricks对”AI代理时代”的战略承诺——所有AI能力都以”Agent”命名，意味着”AI代理”是Databricks的核心定位。

行业影响

Databricks 7/1-7/3平台release notes的深层意义不是”七项功能升级”，而是Databricks平台在”身份治理+行级摄取+多模态模型+行业连接器+集成CDC+AI预算+品牌一致性”七维度同步演进的”平台成熟化+AI化”里程碑。

此前Databricks平台的升级模式是”每月几个重大功能”——例如Vol.22报道的Delta Lake 4.3、Vol.16报道的Cross-Engine ABAC、Vol.13报道的Lakebase CDF+弹性架构。7月release notes的特别之处是”七项并行推进，覆盖平台每一层”——从身份（Okta自动身份GA）到摄取（Lakeflow Connect行过滤+Veeva Vault+MySQL CDC）到模型（Gemini 3.1 Flash Image+3 Pro Image）到AI治理（Unity AI Gateway预算GA）到品牌（Genie Agents）——“全栈”升级。这意味着Databricks平台已经成熟到可以”每月系统性升级每一层”的程度——平台不再是”几个明星功能”，而是”系统化的全栈演进”。

将本期与Vol.25报道的Databricks Unity AI Gateway升级为Agent Registry对比，Agent Registry是”AI代理治理的运行时扩展”（治理对象从LLM扩展为代理），Unity AI Gateway预算GA是”AI代理治理的成本扩展”（治理对象从代理扩展为成本）。两者都是Unity AI Gateway的产品演进——前者管”代理能做什么”，后者管”代理花多少”。当Unity AI Gateway同时管理”代理行为”+“代理成本”时，AI代理的”运行时治理”成为完整闭环。

将本期与Vol.17报道的Databricks AI Search（Vector Search更名+全文搜索+混合搜索）对比，AI Search是”搜索能力的多模态化”（文本+向量混合搜索），Gemini 3.1 Flash Image/3 Pro Image托管是”生成能力的多模态化”（图像理解+生成）。两者都是”Databricks平台的多模态演进”——前者管”读多模态数据”，后者管”生成多模态数据”。当Databricks平台同时具备”读多模态”+“生成多模态”能力时，Databricks成为”多模态AI平台”。

将本期与Vol.12报道的Databricks Iceberg v3 GA（VARIANT全面支持）对比，Iceberg v3是”开放表格式的多模态化”（VARIANT支持任意半结构化数据），本期Veeva Vault+MySQL CDC+Lakeflow Connect行过滤是”数据接入的多样化”（行业SaaS+关系型数据库+行级精度）。两者都是”Databricks数据接入能力的扩展”——前者管”湖仓表格式”，后者管”外部数据源”。当Databricks平台同时具备”开放表格式”+“多样化数据接入”时，Databricks成为”全方位数据基础设施”。

相关链接

编者评

第二十六期的四条动态，从不同层面共同指向数据基础设施的”AI代理生产化”主线——通过多代理协调+受治理vibe coding+可抛弃执行工作空间+平台全栈升级四大支柱，让AI代理从”演示与试点”走向”企业生产”。

第一个层面是多代理协调的系统架构化：Databricks开源Omnigent把多代理协调从单点工具演化为meta-harness系统架构。 Omnigent的”meta-harness”概念把竞争焦点从”哪个代理最强”转向”哪个meta-harness最会协调多个代理”——Shared Sessions让多代理在统一上下文中协同，Guardrails让多代理在企业安全边界内工作，Human-in-the-Loop让多代理在关键决策点接受人类审批。开源+托管的双层架构与Delta Lake策略完全一致——开源核心+Databricks平台托管增强。当meta-harness成为多代理协调的标准架构时，AI编码从”单一代理统治一切”演化为”多代理按能力分工协作”——这是AI代理时代的”分工专业化”。

第二个层面是vibe coding的企业化：Databricks Genie App Builder三件套把vibe coding从消费者工具演化为受治理的企业开发模式。 App Spaces让治理从”按应用”演化为”按空间”——管理员一次性配置，整个空间内的所有应用都受治理；Genie App Builder让业务用户用自然语言直接构建Databricks原生应用——无需”导出→手工适配→导入”的中间步骤；Serverless Micro Apps让应用组合的成本从”持续运行”变为”按需运行”——企业可以部署1000个应用而无需为1000个应用持续付费。关键数据印证——Databricks Apps活跃运行数近翻倍+3倍周活用户数，意味着”无治理vibe coding”已触达企业采用临界点。Governed Vibe Coding是Databricks的”防御性创新”——把vibe coding的工作流留在Databricks生态中。

第三个层面是Agentic AI基础设施的原生形态：阿里云AgentRun把可抛弃执行工作空间从虚拟化附属演化为Agentic AI基础设施原生形态。 MicroVM内核级隔离+每次任务全新沙箱+运行后立即销毁的”可抛弃执行”设计哲学，结构上不可能让”运行未信任代码+响应未信任输入”的威胁模型跨沙箱传播。一次性沙箱+持久化记忆的两层架构让”试错”和”学习”彻底分离——试错在沙箱中（每次全新），学习在外部存储中（永久保留）。代码解释器+浏览器沙箱+工具市场的开箱即用能力让AI代理开发者专注于业务逻辑而非基础设施细节。AgentRun与华为云AgentSphere（K8s路径）+阿里云AgentRun（Serverless路径）并行演进——企业可以根据基础设施现状选择。

第四个层面是平台全栈的同步演进：Databricks 7/1-7/3 release notes在七维度同步推进。 Okta自动身份管理GA去掉SCIM摩擦，Lakeflow Connect行过滤GA让数据摄取从全量走向精准，Gemini 3.1 Flash Image+3 Pro Image托管让多模态模型成为Databricks平台原生能力，Veeva Vault连接器为生命科学行业提供数据接入，MySQL集成CDC管道让单管道融合提取+应用免去独立网关，Unity AI Gateway预算7月GA让AI代理成本治理从Beta走向GA，Genie Spaces更名Genie Agents提升品牌一致性。七维度并行推进意味着Databricks平台已经成熟到可以”每月系统性升级每一层”的程度——平台从”几个明星功能”演化为”系统化的全栈演进”。

将二十六期与近期（Vol.23-25）串联，DataInfra正在从”AI代理试点”走向”AI代理生产化”的关键阶段。 AI代理试点阶段（Vol.21-23）——AI代理作为新功能被引入到各数据平台（Snowflake CoCo/CoWork、Databricks Genie Ontology/One、ClickHouse Agents、阿里云AgentTeams/STAROps），企业开始尝试AI代理的能力。AI代理扩张阶段（Vol.24-25）——AI代理能力在各平台迅速扩展（Snowflake Cortex Sense、Databricks Agent Registry+Genie App Builder三件套、LanceDB v0.31.0/v0.34.0企业级能力、AWS Redshift AI Performance Advisor），企业开始扩大AI代理的使用范围。AI代理生产化阶段（Vol.26-）——AI代理从”演示与试点”走向”企业生产”，关键支撑是多代理协调的系统架构（Omnigent）、受治理的vibe coding（Genie App Builder三件套）、可抛弃执行工作空间（阿里云AgentRun）、平台全栈同步演进（Databricks 7月release notes）。当AI代理从”演示与试点”走向”企业生产”时，DataInfra的下一阶段挑战是”AI代理规模化”——如何让AI代理在企业级规模下保持质量、成本可控、安全可治理。这对DataInfra从业者的启示是：未来1-2年的核心竞争力是”让AI代理在企业级规模下可靠运行”——通过meta-harness架构让多代理协调、通过Governed Vibe Coding让应用构建受治理、通过可抛弃工作空间让执行安全、通过平台全栈升级让基础设施成熟。当AI代理成为”数据访问+应用构建+执行执行”的统一入口时，掌握”如何让AI代理在企业级规模下可靠运行”的工程师将成为最有价值的人才——他们是”AI代理时代的数据基础设施规模化架构师”。