Logic Apps 过去是"连线工"——用预置连接器把 SaaS 服务串起来，逻辑靠条件分支和表达式拼凑。现在它多了一项硬能力：沙箱代码解释器。工作流中的 Agent 可以在运行时动态生成 Python、JavaScript、C#、PowerShell 代码，并在 Hyper-V 隔离会话中执行。这意味着 Logic Apps 从"编排引擎"正式跨入"Agent 执行平台"的行列，与 Azure Foundry、Copilot Studio 形成三线并进。
不再只是"触发→连接器→响应"
传统 Logic App 工作流处理复杂逻辑时，要么拆成几十个嵌套条件，要么外挂一个 Azure Function。两种路径都有代价：前者维护困难，后者需要额外部署和权限管理。
沙箱代码解释器直接在工作流内部解决问题。一个典型场景：Agent 从外部系统拿到一段非结构化日志，需要实时解析、过滤、聚合后写入数据库。以前要写一个 Function 来做正则提取和 pandas 处理；现在 Agent 可以在流程中生成一段 Python，丢进沙箱跑完拿结果，继续下一步。
支持的语言覆盖了四类常见需求：
| 语言 | 适合做什么 |
|---|---|
| Python | 数据清洗、pandas 聚合、机器学习推理脚本 |
| JavaScript | JSON 转换、字符串处理、轻量计算 |
| C# | 强类型业务规则、.NET 库调用 |
| PowerShell | Azure 资源查询、系统管理操作 |
Hyper-V 隔离：不是容器，是真正的硬件级沙箱
"沙箱"这个词容易被滥用。Logic Apps 这次用的是 Hyper-V 隔离会话——每个代码执行请求跑在一个独立的轻量虚拟机里，不是共享内核的容器隔离。这带来几个关键区别：
- 内核级隔离：即使代码里尝试提权或访问宿主内核，虚拟机边界直接阻断。
- 一次性生命周期：会话执行完毕即销毁，不存在状态残留或跨请求泄露。
- 网络受限：沙箱默认不出网，代码解释器只能处理传入数据，不能悄悄调用外部 API。
对架构师来说，这意味着可以把"让 Agent 写代码并执行"这个听起来风险极高的操作，放进生产流程而不必担心逃逸。代价是冷启动延迟比容器高——Hyper-V 虚拟机启动需要几秒，适合批处理和中等频率调用，不适合毫秒级热路径。
模型选择：每个工作流独立控制
另一个容易被忽略的细节：架构师可以按工作流单独选择模型。
在 Foundry 或 Copilot Studio 里，模型选择往往是全局配置或项目级设置。Logic Apps 的做法更细粒度——同一个租户下，工作流 A 用 GPT-4o 做复杂代码生成，工作流 B 用 GPT-4o-mini 做简单字符串处理，成本和延迟各自优化。这在大规模集成场景中很实用：不是所有 Agent 都需要最贵的模型。
实战：在 Logic App 中配置代码解释器动作
下面是一个简化的 Logic App 工作流定义，展示如何在一个 HTTP 触发流程中调用代码解释器，让 Agent 用 Python 处理传入的日志数据。基于当前公开的功能描述，动作名称和结构为合理推断，实际发布时可能略有调整——部署前请对照官方文档确认 schema 版本。
# logic-app-code-interpreter.yaml
definition:
$schema: "https://schema.management.azure.com/providers/Microsoft.Logic/2016-06-01/workflowdefinition.json#"
triggers:
manual:
type: "Request"
kind: "Http"
inputs:
schema:
type: "object"
properties:
rawLogs:
type: "string"
description: "原始日志文本，每行一条记录"
actions:
# 第一步：Agent 用选定模型生成处理代码
GenerateCode:
type: "ApiConnection"
inputs:
operation: "generateCode"
model: "gpt-4o" # 按工作流独立选模型
prompt:
# 把触发器传入的日志喂给 Agent
rawLogs: "@triggerBody().rawLogs"
instruction: >
写一段 Python 代码，从传入的 rawLogs 中提取所有包含 ERROR 的行，
按时间戳排序，返回 JSON 数组。代码只使用标准库，
不要 import 第三方包。输出变量名必须是 result。
# 第二步：沙箱执行生成的代码
RunInSandbox:
type: "CodeInterpreter"
inputs:
language: "Python"
code: "@body('GenerateCode').generatedCode"
inputVariables:
rawLogs: "@triggerBody().rawLogs"
# 沙箱配置：超时和资源限制
timeoutSeconds: 30
maxMemoryMB: 512
# 第三步：把结果写入存储
SaveResults:
type: "ApiConnection"
runAfter:
RunInSandbox: ["Succeeded"]
inputs:
operation: "createBlob"
body: "@body('RunInSandbox').result"
path: "/processed-logs/error-logs.json"
部署前需要改的地方：
operation字段名——正式 API 可能用不同路径，请对照 Azure Logic Apps REST 参考。model值——替换为你租户中已部署的模型资源 ID。SaveResults的连接器——示例用了 Blob Storage，实际替换成你用的存储连接器引用。- 如果你的 Logic App 使用新的标准版（单租户），动作类型可能写法不同，确认所用 schema 版本。
部署命令：
# 先创建 Logic App（标准版示例）
az logicapp create \
--name my-agent-workflow \
--resource-group rg-integration \
--plan my-app-service-plan \
--storage-account my-storage
# 部署工作流定义
az logicapp workflow create \
--name my-agent-workflow \
--resource-group rg-integration \
--workflow-name process-error-logs \
--definition @logic-app-code-interpreter.yaml
什么时候该用，什么时候别碰
适合的场景：
- 集成流程中有不可预测的数据格式，需要 Agent 实时生成解析逻辑。
- 已有 Logic App 工作流在跑，不想为每个数据转换单独部署 Azure Function。
- 安全合规要求代码执行必须在隔离环境中，不能共享宿主。
不适合的场景：
- 高频低延迟热路径（每秒数百次调用）——Hyper-V 冷启动开销不可忽略。
- 需要持久状态或文件系统写入的长时间任务——沙箱是一次性的。
- 纯确定性逻辑——如果每次跑的代码都一样，直接写 Function 更便宜更可控。
落地检查清单：
- [ ] 确认租户已开通代码解释器功能（目前为新增预览能力，可能需申请）。
- [ ] 为每个工作流选定模型，避免全部默认用最贵选项。
- [ ] 测量沙箱冷启动延迟，确认在业务 SLA 内。
- [ ] 审计 Agent 生成代码的 prompt——防止注入导致沙箱内资源耗尽。
- [ ] 规划错误路径：代码执行失败时工作流如何回退或通知。
Logic Apps 加上代码解释器，本质上是在"连线"能力上补了"计算"能力。对已经在用 Logic Apps 做集成的团队，这是最小摩擦的 Agent 化路径——不需要换平台，只需要在工作流里多加一个动作。