Dify 1.17 的重头戏是把 Agent 的代码执行搬上了云。以前 Dify 的 agent 要跑 shell 或代码，只能在本地沙箱里；这版加了 E2B 云沙箱后端，让执行能跑到远程隔离环境里。跟它一起进来的还有 Home 快照、工作区级技能管理和上下文感知的历史压缩，都是奔着"让 agent 跑得更可控、更省上下文"去的。这篇重点讲执行后端这条线。
执行后端：本地沙箱与 E2B
agent 的 shell/code 执行现在有两个后端可选：原来的本地沙箱，和新的 E2B 云沙箱。切换靠一个环境变量：
DIFY_AGENT_RUNTIME_BACKEND=e2b
配套的是官方给了一份 docker-compose.e2b.yaml 把 E2B 栈带起来，E2B 的流量是认证的，E2B 模板在每次 release 时同步。选 E2B 的意义在于隔离性：代码不再跑在宿主进程能碰到的环境里，而是跑在一个远程、按需销毁的沙箱里，出了事也炸不到主服务。
Home 快照
这版有个容易被忽略但很实用的机制：构建时 Home 快照。当 agent build 被应用（发布）时，agent 沙箱的 home 目录——装的包、准备的文件、工作状态——会被捕获成快照；之后每次运行这个已发布 agent，都从快照恢复 home 目录。也就是说，agent 每次启动都精确回到它构建那一刻的文件系统状态，不会因为上一次运行留下的脏状态而产生不确定行为。这对"发布即固化"的 agent 尤其重要：你发布的那个版本，行为是确定的。
技能管理
Skills 是可复用、版本化的能力，打包代码和工具定义，agent 能发现并调用。这版加的是工作区级技能管理，带 draft → publish → version 的完整生命周期，配套一个 web UI（技能列表、builder 面板、文件编辑器）。这意味着技能不再是一次性的 prompt 片段，而是一个可以被版本化、被 agent 发现、被团队复用的单位。
上下文感知的历史压缩
长 agent 对话不再撑爆上下文窗口。Dify 会解析每个模型的有效窗口，然后分层压缩——先清掉旧的工具结果，再摘要更早的历史——让运行待在预算内，又不丢最近的上下文。这解决的是 agent 长跑场景里最实际的痛点：工具结果越积越多，把真正重要的对话挤出去了。
其它值得注意的改动
这版还塞了不少周边。可复用的 LLM 环境变量让你定义一次 provider/model/参数组合（比如 for_summarize、for_research），再被任何 LLM 节点引用，模型切换不用逐节点改。统一追踪（OPS_TRACE_UNIFIED_ENABLED，默认关）把父子 span 树在 core 里组装一次，只把传输交给轻量适配器，Phoenix 和 LangSmith 适配器先行。Human-in-the-loop 表单现在能在 Loop 和 Iteration 节点里用了。还有 ⌘K 命令面板、Cloudflare Turnstile 验证码、Azure Key Vault 的 KMS 抽象，以及把 APP_MAX_EXECUTION_TIME 和 WORKFLOW_MAX_EXECUTION_TIME 默认值从 1200 秒提到 3600 秒——这条对跑长工作流的用户很实在。
本地沙箱 vs E2B：选型
| 维度 | 本地沙箱 | E2B 云沙箱 |
|---|---|---|
| 隔离强度 | 进程级，受宿主影响 | 远程隔离，按需销毁 |
| 部署成本 | 零，开箱即用 | 需部署 E2B 栈 |
| 网络与资源 | 用宿主 | 独立云资源，可扩容 |
| 适合 | 内网、低敏感、快速原型 | 多租户、需强隔离、生产 |
选型的判断其实就一条：你信不信得住本地隔离。单机自用、内网环境、图省事，本地沙箱够了；一旦 agent 要跑不可信代码、要面对多租户、或者执行环境要跟服务本身物理隔离，就上 E2B。E2B 的额外成本是部署运维，但它把"代码执行"从宿主里摘了出去。
不适合谁
几类人从这版收益有限。一是根本不用 agent 代码执行、只用 workflow 和聊天流的用户，E2B 和 Home 快照跟他们关系不大。二是不想再维护一套云沙箱栈的小团队，E2B 的部署成本可能比隔离收益还高，本地沙箱继续用。三是已经在用别的方式管技能（比如 Git 仓库加自建目录）的团队，Dify 的技能管理要迁移和重新组织，短期是额外工作。这版值得升级的人群很明确：重度用 agent、跑不可信代码、或者被长对话撑爆上下文困扰的人。