Dify 1.17.0 来了：Skill 管理、工作流变量复用，Agent 这次真能自己干活了
Dify 1.17.0 版本聚焦 Agent 工程化落地，核心更新包括 E2B 云沙箱支持、Home Snapshot 环境固化、Workspace 级 Skill 版本管理、上下文自动压缩；工作流新增 LLM 变量复用与 Loop/Iteration 中的人工介入能力；统一链路追踪支持 Phoenix/LangSmith；安全加固涵盖 Cloudflare Turnstile、Azure Key Vault 集成及 SSRF 防护。
Agent 运行时：从"能跑"到"能打"
这是 1.17 最核心的一块，四个功能组合在一起，Agent 的工程化程度直接上了一个台阶。
E2B 云沙箱：代码执行不用再自己维护沙箱了
以前 Dify Agent 的代码/Shell 执行只能跑在本地沙箱里，自部署用户得自己管沙箱容器的资源、安全和隔离。现在新增了 E2B 云端沙箱后端，通过环境变量 DIFY_AGENT_RUNTIME_BACKEND 切换。
几个实际变化：
- 新增了
docker-compose.e2b.yaml，E2B 技术栈一键拉起 - E2B 流量走认证，模板在发版时自动同步
- 配套加了一堆超时和连接池参数（
DIFY_AGENT_E2B_ACTIVE_TIMEOUT_SECONDS、DIFY_AGENT_OUTBOUND_HTTP_*），可以精细控制沙箱行为
什么场景有用？
- 不想自己维护沙箱基础设施的团队，直接用 E2B 云端跑代码
- 需要更强隔离性的多租户场景，云沙箱天然比本地容器安全边界更清晰
- CI/测试环境临时跑 Agent，不用长期占着本地资源
Home Snapshot：发布即固化，Agent 每次从同一状态启动
这个功能听起来不起眼，但解决了一个很烦的问题——Agent 运行环境的不确定性。
简单说：当你发布（build）一个 Agent 时，系统会把沙箱 home 目录打个快照——装好的依赖、准备好的文件、工作状态全部冻结。之后这个已发布 Agent 的每次运行，都会从这个快照恢复 home 目录。
这意味着：
- Agent 在构建时
pip install了什么包，线上跑的时候一定还在，不会因为沙箱重建就丢 - 准备好的配置文件、数据文件不需要每次运行重新下载
- 本地调试通过的环境状态，跟线上完全一致
对做生产级 Agent 的人来说，这才叫可复现。之前那种"我本地好好的，线上怎么挂了"的问题，少了一大半。
Workspace 级 Skill 管理：Agent 能力终于有了版本管理
Skill 不是新概念，但 1.17 把它做成了工作空间级的一等公民：
- 完整的 draft → publish → version 生命周期
- 新增 Web UI：Skill 列表页、Builder 面板、文件编辑器
- Skill 是带代码和工具定义的可复用、可版本化能力包，Agent 可以自动发现和调用
这跟 Dify 之前的工具体系最大的区别是：Skill 有版本，能灰度，能在工作空间内共享。你不再需要把同一段工具逻辑复制到每个 Agent 里，改一次，所有引用的 Agent 都能用上新版本。
配套新增了 UPLOAD_SKILL_FILE_SIZE_LIMIT 环境变量控制上传大小，数据库也加了 add_workspace_skill_management 迁移。
上下文自动压缩：长对话不再爆窗口
跑过长对话 Agent 的都懂，聊到一半突然报 context length exceeded 有多崩溃。1.17 加了上下文感知的历史压缩：
- 自动获取当前模型的有效上下文窗口
- 分层压缩：先清旧的工具调用结果（这些最占 token 且复用价值低），再对更早的历史做摘要
- 最近的对话上下文完整保留，不影响当前轮次的连贯性
这是个"开了就不用管"的功能，不需要你手动配置压缩策略，系统根据模型自动判断。属于典型的"没什么存在感但少了它不行"。
工作流：LLM 节点变量复用 + 循环里的人审
可复用 LLM 环境变量
这个功能非常实用，属于"早该有了"系列。
之前如果你在一个工作流里有 10 个 LLM 节点，想把模型从 GPT-4o 换到 Claude，就得逐个节点点进去改。现在可以定义一个共享的 LLM 配置变量（比如 for_summarize、for_research），把 provider/model/mode/参数打包，然后在任意 LLM 节点里引用。
好处很直接：
- 统一换模型：改一个地方，所有引用节点同步更新
- DSL 导入导出不丢引用：跟 snippet、RAG 管道、协作编辑都兼容
- 环境区分：开发和生产可以用不同的模型配置，切换不用改工作流
Loop / Iteration 里支持 Human Input
1.13 引入的 Human-in-the-Loop 一直只能在工作流主线上用，循环节点里不支持。1.17 补上了：
- HITL 表单可以放在 Loop 和 Iteration 节点内部
- 暂停/恢复在页面刷新后也能正确恢复（debug 和已安装应用都支持）
这打开了不少实际场景：
- 批量审核：Iteration 遍历一批待审内容，每一条都让人确认通过/驳回
- 循环审批流：Loop 里每轮生成结果后人审，不满意就继续迭代
- 数据标注：循环处理数据，每条都让人校验标注质量
另外，工作流和应用的最大执行时间从 1200 秒提到了 3600 秒（一个小时），长任务不用再担心被超时掐断。
统一链路追踪：终于不用接好几套观测系统了
如果你同时用 Phoenix 和 LangSmith，或者在多个环境用不同的 tracing 后端，1.17 的统一追踪会让你舒服很多。
核心机制：
- 新增
OPS_TRACE_UNIFIED_ENABLED开关（默认关闭，完全向后兼容） - Core 层统一组装完整的父子 span 树——工作流、chatflow、消息、节点、循环、迭代、嵌套工作流全部串起来
- 传输层只做轻量 adapter，首批支持 Phoenix 和 LangSmith
- 新增 GenAI span，能看到 LLM 的 TTFT（首 token 延迟）、Agent ReAct 步骤、工具调用、失败的 LLM 节点
对生产环境来说，这意味着你可以在一个地方看到完整的请求链路，不用在多个观测系统之间跳来跳去。TTFT 这种指标对排查"为什么这个 Agent 这么慢"特别有用。
安全与企业级能力：企业自部署必看
1.17 在安全上花了不少功夫，挑几个跟自部署相关的：
- Cloudflare Turnstile：登录和邮箱验证码登录支持人机验证，防暴力破解和接口滥用
- 邮箱验证码加固：新增尝试次数限制（
EMAIL_CODE_LOGIN_MAX_ATTEMPTS）和 token 过期时间（EMAIL_CODE_LOGIN_TOKEN_EXPIRY_MINUTES） - Azure Key Vault / 可插拔 KMS：加密密钥可以交给 Azure Key Vault 管理，支持密钥轮换，向"密钥不受应用控制"迈出一步
- 权限收敛：dataset、document、RAG、conversation、workspace credential、OAuth client 等资源统一绑定 owner 和 app scope，修了几个越权路径
- SSRF 加固：出站 HTTP 连接阶段加了 5 秒超时，Agent 下载和运行超时都可配置
如果你是企业自部署，这些更新建议认真过一遍，尤其是权限收敛那块。
其他值得关注的更新
快速过一下：
- TiDB Vector 全文/混合检索：
TIDB_VECTOR_ENABLE_FULLTEXT_SEARCH开启后，TiDB 向量库支持多语言全文索引 + 向量混合检索 - 多模态文件处理改进：LLM 节点和 Agent 可以直接把图片文件传给多模态模型；非视觉附件不再被静默丢弃
- ⌘K / Ctrl+K 全局跳转：命令面板新增 Agent 和 Skill 搜索，图标命令系统全量重构
- ODT 文档解析：支持 OpenDocument Text 格式
- 旧对话自动清理：
ENABLE_CONVERSATION_CLEANUP_TASK控制自动清理，防止数据无限增长 - Marketplace 内嵌：插件市场直接嵌入集成分类页，找工具更方便
- 工作流生成器偏好已安装工具：AI 生成工作流时优先推荐你已装已配的工具
升级注意事项
这次更新有几个 breaking change，升级前务必看一眼：
EDITION改名为DEPLOYMENT_EDITION——如果你在.env里设了这个变量，必须改ENTERPRISE_ENABLED被移除——企业版开关统一了AGENT_BACKEND_RUN_TIMEOUT_SECONDS改名——换成DIFY_AGENT_RUN_TIMEOUT_SECONDS- 新增数据库迁移——
flask db upgrade必须跑，其中add_conversation_cleanup_index在 conversations 表大的时候可能比较慢 - Docker Compose 配置变了——新增
docker-compose.e2b.yaml，如果你改过 compose 文件，重新合并时小心 - 默认执行时间翻倍——
APP_MAX_EXECUTION_TIME和WORKFLOW_MAX_EXECUTION_TIME从 1200 秒改到 3600 秒，注意资源占用
升级步骤官方给了标准流程：备份 compose 和 env → git pull → docker compose down → 备份 volumes → 改环境变量 → docker compose up -d。没什么花活，按步骤来就行。
写在最后
Dify 从 1.0 到 1.17，演进路线其实很清晰：早期解决"怎么搭 AI 应用"，后来解决"怎么让工作流更灵活"，现在开始啃"怎么让 Agent 真正可靠地跑在生产环境"。
E2B 沙箱 + Home Snapshot + Skill 版本管理 + 上下文压缩这一套组合拳，打的就是 Agent 工程化最硬的骨头——环境一致性、能力复用、稳定性。再加上统一链路追踪和安全加固，1.17 更像是一个"让你敢把 Agent 放上线"的版本。
如果你还在 1.16.x，建议先在测试环境跑一轮，确认环境变量和迁移没问题后再上生产。有什么踩坑经验，评论区聊聊。
JOTO 企业落地观察
- 对企业部署意味着：Agent 运行时能力升级大幅降低生产环境运维复杂度。E2B 云沙箱使代码执行脱离本地容器管理，Home Snapshot 固化环境状态，二者共同缓解了“本地能跑、线上失效”的典型交付风险，尤其利于缺乏专职 Infra 团队的中型企业快速上线。
- 这类系统的取舍在于：Skill 的 Workspace 级版本管理虽提升了能力复用效率，但也要求团队建立明确的 Skill 发布规范与灰度流程。若缺乏配套的权限隔离与变更评审机制，版本混用可能导致跨业务线 Agent 行为不可控，需在工程治理层面同步补位。
- 对 RAG 知识工程的影响是间接但关键的：统一链路追踪新增的 GenAI span（含 TTFT、工具调用、失败节点）使 RAG 检索-重排-生成全链路可观测。当知识召回效果不佳时，团队可精准定位是 Embedding 延迟、向量库响应慢，还是 LLM 对检索结果理解偏差，而非笼统归因于‘RAG 不好用’。
- AI 安全治理需关注权限收敛与密钥解耦的实际落地效果。Azure Key Vault 集成实现了密钥生命周期与应用解耦，但企业仍需验证其是否覆盖全部敏感凭证（如 RAG 数据源连接凭据、外部 API Token），并确保权限收敛后的 owner/app scope 绑定策略能匹配真实组织架构与最小权限原则。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们
