微软向Azure Logic Apps agent工作流添加了沙箱化代码解释器,Python、JavaScript、C#和PowerShell在Azure Container Apps(ACA)会话池上的Hyper-V隔离会话内运行。对构建者重要的底层细节:这是VM级隔离,而非容器级——比典型的Docker或gVisor沙箱对breakout和prompt-injection驱动的恶意代码提供更强的保证。支持每工作流的模型选择,因此除了Azure平台本身之外,没有锁定到特定LLM提供商。
沙箱化代码执行一直是需要计算、转换或可视化的agent工作流的慢性瓶颈。直到最近,构建者还在拼接E2B、Modal、OpenAI的代码解释器,或者用Firecracker或microVM自己滚一个。Logic Apps集成将解释器定位为agent loop内的工具——LLM生成代码、在隔离中执行、返回结果、继续。在ACA会话池上启用网络隔离时,"数据从不离开定义的网络边界",这是用于将企业数据保持在agent泄漏面之外的compliance表述。公告中的架构师框架瞄准多企业系统编排——ERP、CRM、数据库、带重试逻辑和审计trails的API——不是greenfield的agent tooling。
生态系统解读是VM隔离的代码解释器正在成为云原生原语,而不是自己构建的line item。Hyper-V比容器更重——冷启动更慢、每次执行成本更高,但安全架构是企业agent部署在tool-use表面上的prompt-injection攻击变得真实之后所需要的。AWS和GCP在不同成熟度上有类似的原语(带隔离的App Runner、Cloud Run sandboxing、Sandbox API),云提供商在VM级代码解释器原语上的趋同意味着"我们应该使用E2B还是滚自己的"问题获得了第三个答案:如果你已经在那里,使用云原生原语。锁定成本是真实的——Logic Apps + ACA = Azure-only——但对于已经在Azure上有审计和合规需求的组织,它消除了"滚自己的沙箱"风险类别。
如果你周一早上在Azure上构建agent:这是使"agent执行代码"成为复选框而不是服务集成项目的变化。如果你在AWS或GCP上构建:跟踪等效物,并期待相同的架构模式。转变是沙箱化代码执行从agent构建者的责任转向云提供商原语,这种转变是结构性的。