文章总结： Dify1.17版本通过引入E2B云沙箱，将Agent执行环境从本地迁移至云端，实现任务级隔离、弹性扩容与状态快照复现，解决了本地沙箱隔离不净、状态不可复现、资源无弹性及安全边界模糊等核心痛点。同时新增技能管理、可复用LLM环境变量、循环内人工输入、统一追踪及多项安全加固。升级前需注意数据库迁移、环境变量改名及超时调整等事项。 综合评分： 85 文章分类： 安全建设,解决方案,安全工具,应用安全

Dify 1.17：把Agent关进云沙箱，解决了我半年的坑

内存泄漏

2026年9月3日 00:00 辽宁

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

先说个我自己的糗事。上个月我用Dify搭了个能自动跑Python脚本的数据分析Agent，上线第三天它就给我闯了祸——为了装一个依赖库，它直接在共享的本地沙箱里改了全局环境，结果同一台机器上另外两个应用跟着崩了，我排查到半夜。

这不是Dify的错，是所有”会动手的Agent”共同的尴尬：当AI不再只是跟你聊天，而是真的要执行代码、跑shell、装依赖、读写文件，第一个要命的问题就来了——这些代码，到底该在哪儿跑？

8月28日Dify发布了1.17.0版本。很多人盯着那一串更新列表看花了眼，但我刷完官方release notes后只盯住了一件事：这次它重构了整个Agent运行时，还把Agent的执行环境搬进了E2B云沙箱。我踩了半年的那个坑，终于被官方从架构层面填上了。

今天不写流水账式的更新清单，只讲清楚三件事：这个版本到底解决了什么本质问题、哪些功能真正值得你升级、以及升级前必须避开的几个坑。

先说本质：Agent的”手”伸得越长，越需要一个笼子

先把背景讲透，不然你理解不了这次更新的分量。

过去一年Agent进化得特别快，从”动嘴”到”动手”：它要写代码、执行命令、调用工具、操作文件。但代码这东西是有破坏力的——一段死循环能吃光CPU，一个rm -rf能删光文件，一次失控的网络请求能摸到你的内网。我前阵子写OpenAI那700个Agent攻破Hugging Face的事，它们第一步就是从执行环境里”越狱”摸到公网的。

所以Agent必须跑在沙箱里，这是共识。问题是，本地沙箱有一堆先天毛病，都是我实打实踩过的：

一是隔离不干净。多个Agent共用一个本地执行环境，你装的包、写的临时文件会互相污染，也就是我开头那个事故。

二是状态不可复现。Agent这次运行时装了一堆东西，下次重启环境全没了，同样的任务跑两遍结果不一样，调试全靠玄学。

三是资源没弹性。本地沙箱跟主服务抢CPU和内存，并发一上来就卡，扩容还得手动加机器。

四是安全边界模糊。Agent理论上能从沙箱探测到内网地址，SSRF防护稍不留神就是窟窿。

这四个问题，靠在本地沙箱上打补丁是治标不治本的。

容器隔离原理：每个应用独立运行环境

Dify 1.17给出的答案很干脆：别在本地硬扛了，上云沙箱。

核心更新：E2B云沙箱，一次性的”独立工位”

1.17引入了E2B云沙箱后端。简单说，你现在可以通过一个环境变量DIFY_AGENT_RUNTIME_BACKEND，选择Agent的代码到底跑在本地沙箱还是E2B云端，官方甚至直接给了docker-compose.e2b.yaml一键拉起整套组件。

这东西解决问题的思路特别朴素：给每个Agent任务发一个一次性的、完全隔离的云端”工位”。

任务来了，秒级开一个干净的沙箱，装包、跑代码、读写文件都在里面折腾，跟你的主服务、跟其他Agent彻底物理隔离；任务结束，工位直接销毁，什么污染都留不下来。要并发？同时开一百个工位，弹性扩容，本地机器一点压力都没有。

配合这次一起上的还有个Home Snapshots（主目录快照），这是我最喜欢的设计。Agent在构建发布时，系统会把沙箱主目录的完整状态——装了哪些包、准备了哪些文件——拍一张快照存起来。之后每次运行这个已发布的Agent，都从这张快照精确还原。

听明白了吗？这一下就把”不可复现”这个老大难解决了。以前是薛定谔的运行环境，现在是每次都从同一个确定的起点出发，线上出了问题你能100%复现，这对生产环境来说是刚需，不是锦上添花。

当然我也得说句公道话：云沙箱不是银弹。E2B是按用量收费的，高频调用会产生额外成本；代码和数据要上云端执行，对数据出域敏感的企业得先过合规这一关；网络往返也比本地多那么一点延迟。所以1.17很克制地保留了本地选项——敏感、低频、要省钱的场景用本地，高并发、强隔离、要弹性的场景上云，把选择权留给你。这个设计我给好评，没有一刀切。

第二个被低估的更新：技能管理，Agent能力开始”npm化”

如果说云沙箱解决的是”在哪跑”，那工作区级的Skill技能管理解决的就是”会什么”。

1.17里，Skill是一种可复用、带版本控制的能力包，里面装着代码和工具定义，Agent可以自己发现并调用。它有完整的草稿→发布→版本生命周期，还配了Web管理界面和文件编辑器。

这事儿的趋势意义比功能本身更大。你回想一下，程序员早年写代码都是各写各的工具函数，后来有了npm、pip，能力被打包、版本化、复用、共享，整个行业的效率才上了一个台阶。现在Agent的能力正在走同一条路：把一段成熟的能力（比如”查快递””读PDF表格””调内部ERP”）封装成一个带版本的Skill，全工作区的Agent都能调用，改一处，处处生效。

这条线其实和DeepSeek Harness的”一切皆插件”、和MCP协议，是同一个大方向——Agent的能力正在从”每次现写”变成”按需组装”。 Dify这次算是把这套东西在平台层补齐了。

顺带说几个真正实用的，和一个安全大礼包

除了两个主角，这几个功能做实战的同学也值得知道：

可复用LLM环境变量：以前一个复杂工作流里十几个LLM节点，要换模型得一个个点过去改，改漏一个就出bug。现在可以定义for_summarize、for_research这种共享变量，所有节点引用它，换模型只改一处。维护过大型工作流的人，懂这个有多救命。

循环内人工输入：以前人工审核只能加在主流程，现在Loop和Iteration节点内部也能暂停等人确认了。批量处理一百条数据、每条都要人过目的场景，终于不用拆成一百个流程。

统一追踪：开启后能把工作流、节点、循环、嵌套流程拼成一棵完整的调用树，直接对接Phoenix和LangSmith。Agent的每一步推理、每次工具调用、TTFT延迟都能看清楚——Agent越复杂，可观测性越重要，不然出问题你根本不知道它哪一步想歪了。

安全方面这版也下了猛料：登录加了Cloudflare人机验证、一堆资源被严格绑定到所有者（堵了多个越权访问的洞）、出站HTTP连接限时5秒防SSRF、还支持了Azure Key Vault管理密钥。结合我前面说的行业背景你就懂了，当Agent开始大规模动手，安全加固不是可选项，是生死线，Dify这波是踩在了点上。

升级前，这几个坑我替你踩过了

最后是给运维同学的实战提醒，这版环境变量变动不小，别直接拉起来就升：

第一，有数据库迁移，必须执行flask db upgrade，好在官方说不用手动回填。但注意add_conversation_cleanup_index会给对话表建索引，如果你的对话表特别大，这一步会跑比较久，挑业务低峰期操作。

第二，环境变量改名了，EDITION改成了DEPLOYMENT_EDITION，旧的ENTERPRISE_ENABLED、几个agent runtime相关变量被移除或替换，自定义过.env的一定要逐条核对，不然起来一堆报错。

第三，默认执行超时从1200秒提到了3600秒，如果你之前依赖旧的超时做任务限制，记得重新评估。

第四，务必先备份。备份docker-compose和.env，再tar一份volumes数据卷，这是任何大版本升级的标准动作，别嫌麻烦。

写在最后

我从Dify 0.x版本一路用过来，看着它从一个套壳的Prompt工具，长成现在能承载生产级Agent的平台。1.17这个版本最让我认可的地方，是它没有急着堆花哨的模型功能，而是沉下心把”Agent到底怎么可靠、安全地跑起来”这件基础设施的事做扎实了。

这其实也是整个行业下半年的缩影：上半年大家比谁的Agent更聪明、更会说，下半年开始比谁的Agent更可靠、更安全、能真正进生产。云沙箱、技能复用、全链路追踪、安全加固——这些不性感，但它们才是Agent从Demo走向干活的必经之路。

我已经在测试环境把1.17跑起来了，那个爱闯祸的数据分析Agent，现在每次都在独立的云工位里干活，跑完即焚，再也没污染过别人。等我再压测一周，就把生产环境也升上去。

如果你也在用Dify搭Agent，这个版本，值得找个周末认真升一次。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：内存泄漏 《Dify 1.17：把Agent关进云沙箱，解决了我半年的坑》