文章总结： Difyv1.16.0-rc1引入DifyAgent实验性功能，这是一个基于Linux沙箱的AI工作者，支持Capability/Task分离设计，可独立运行或嵌入Workflow。其他改进包括WebApp增强、性能优化和关键Bug修复。当前版本安全风险显著，沙箱未隔离且shellctl无认证，仅适合测试环境。升级前必须备份数据并运行数据库迁移。建议在测试环境体验，生产环境等待正式版。 综合评分： 87 文章分类： 其他

Dify v1.16.0-rc1 重磅前瞻：Linux 沙箱 Agent 登场，Workflow 正式进化为”会动手”的协作体

内存泄漏

2026年7月12日 09:39 辽宁

在小说阅读器读本章

去阅读

以下文章来源于阿强学AI ，作者阿强学Ai

阿强学AI .

玩转AI开发，从小白到高手！专注分享 Dify与Coze两大热门AI应用平台的学习心得、实操技巧与最新玩法，手把手教你快速构建智能应用。紧跟AI前沿，助你高效掌握AI工具，释放生产力！🔥 关注我，一起探索AI的无限可能！ 🚀

本文内容整理自 GitHub Release Notes。

🏆 头号特性详解：Dify Agent（实验性）

如果你一直在关注 Dify 的演进路线，你会发现一个清晰的信号：Workflow 正在从”编排引擎”向”协作体”进化。v1.16.0-rc1 引入的 Dify Agent，就是这步棋的关键落子。

这不是之前你在 Dify 里用过的那种”选几个工具挂到 LLM 上”的经典 Agent 应用。它是一个基于 Linux 沙箱运行的全能型 AI 工作者——能跑命令、装软件、读写文件，真正”动手”干活。

官方文档用了一个很精准的类比：你招聘一个人，是看中他的能力（capability），然后给他分配具体任务（task）。Dify Agent 把这两件事彻底拆开了。

⚠️ 重要提醒：这是 rc1（Release Candidate 1）实验性版本，所有 Dify Agent 功能标记为 Beta，不适合直接用于生产环境。请仅用于测试和体验。

核心架构：Capability 与 Task 分离

Dify Agent 的设计哲学是”能力与任务解耦”，这一点从官方文档的架构描述中可以清晰看到：

| 维度 | 说明 | 类比 | | — | — | — | | Capability（能力） | Agent 的”灵魂”：角色设定、Prompt、模型选择、知识库、Skills、Dify 工具、文件 | 你招的那个人本身具备的技能 | | Task（任务） | 每次运行时交给 Agent 的具体指令 | 你给他派的某一项活儿 |

构建一次，两种用法——这是 Dify Agent 最关键的产品设计决策：

| 使用方式 | 场景 | 说明 | | — | — | — | | 独立运行 | 作为 Chat App 或 Web App | 适合单一 Agent 就能搞定的场景：客服查答、研究汇总 | | 嵌入 Workflow | 作为 Agent 节点参与工作流 | 适合需要多步骤编排、条件分支、多 Agent 协作的场景 |

五大核心能力拆解

1. Agent 构建器（Agent Builder）

UI 驱动的可视化构建体验。你不用写代码，通过界面就能：

• • 设置基础 Prompt 和角色设定
• • 上传 Skills（技能文件）和工作文件
• • 连接 Dify 生态中的工具和知识库

一句话理解：以前你搭 Agent 是”写配置”，现在是”搭团队”。

2. 智能助手 Agent（Assistant Agent）

这是一个”帮你构建 Agent 的 Agent”——听起来套娃，但非常实用。

它能通过对话帮你完成：

• • 配置 Linux 沙箱环境
• • 安装运行所需的包和依赖
• • 创建新的 Skills 和文件

实际意义：你不需要懂 Linux 运维，跟助手聊着天就把环境搭好了。这大幅降低了 Agent 构建的门槛。

3. Dify Workflow 集成

这是我认为对现有用户影响最大的一项改动。工作流中现在可以：

• • 调用已构建好的 Dify Agent 作为节点
• • 临时创建内联 Agent（Inline Agent）处理特定子任务
• • Agent 执行完毕后，输出自动传递给下一节点

| 集成模式 | 说明 | 适用场景 | | — | — | — | | 引用已有 Agent | 在工作流中插入已构建的 Agent | 需要复用标准化能力 | | 内联 Agent | 工作流内临时创建一次性 Agent | 仅在此工作流中需要的特殊任务 |

这意味着 Workflow 不再只是”节点编排”，而是变成了”Agent 协作”——多个专业化 Agent 各司其职，在流水线中接力完成复杂任务。

4. 全新 Web App 体验

构建好的 Dify Agent 可直接发布为 Web 应用。用户体验保持熟悉的聊天界面，但底层引擎已切换为 Dify Agent 驱动——用户无感知，能力却上了台阶。

5. 完整文档支持

官方已上线完整文档，地址如下：

📖 官方文档：https://docs.dify.ai/en/self-host/use-dify/build/new-agent/overview

冷静看待：当前限制与安全风险

作为技术公众号，必须把丑话说在前面。Dify Agent 的安全模型目前还不成熟，这是 rc1 阶段最大的风险点。

| 风险项 | 详情 | 影响 | | — | — | — | | 沙箱未隔离 | 所有 Agent 运行在同一沙箱中，未实现严格隔离 | Agent 间可互相读取或干扰环境和数据，包括用户数据 | | 软隔离而非硬隔离 | Community Edition 依赖软隔离而非按用户/按运行的文件系统硬隔离 | 恶意 Prompt 或工具执行可能访问目标工作目录之外的数据 | | Workflow DSL 导出不可用 | 当工作流包含 Dify Agent 节点时，无法导出 DSL | 影响工作流备份和迁移 | | 功能未完全就绪 | 部分功能仍处于开发中 | 体验不完整，可能遇到 Bug | | shellctl 无内置认证 | shellctl 组件没有内置认证机制 | 必须在容器内运行，且仅提供给受信任用户 |

🔒 安全建议：当前版本仅应提供给受信任的、非恶意用户使用。对于严格的安全或合规要求，官方建议使用 Dify Cloud 或 Enterprise Edition，或部署独立的强化基础设施隔离。同时，生产环境必须将 DIFY_AGENT_SERVER_SECRET_KEY 替换为你自己的随机值。

快速上手：如何启用 Dify Agent

Docker Compose 部署的用户，v1.16.0-rc1 默认开启 Dify Agent，运行时已内置。源码部署需要额外启动 dify-agent 和 shellctl 两个服务：

# Docker Compose 用户：默认已启用，无需额外操作
# 源码部署用户：需要手动启动 dify-agent 和 shellctl
# ⚠️ shellctl 无内置认证，强烈建议在容器内运行

✨ 其他新功能

除了 Dify Agent 这个头号特性，v1.16.0-rc1 还带来了一批实用改进。

应用与 UI 增强

| PR | 功能 | 说明 | | — | — | — | | #37345 | Web App 应用描述显示 | 应用描述信息现在会在 Web App 中展示，提升用户体验 | | #37790 | 可自定义输入占位符 | 支持自定义输入框占位符文本，灵活适配不同场景 |

工作流与权限

| PR | 功能 | 说明 | | — | — | — | | #38134 | Snippet 侧边栏改进 + RBAC | 代码片段侧边栏体验优化，新增基于角色的权限控制 | | #37980 | Workflow Provider 配置缓存 | 缓存 Provider 配置以提升工作流执行性能 | | #37915 | Agent-v2 夜间更新同步 | Agent-v2 分支的夜间更新已同步到主分支 |

⚡ 性能与基础设施

| 改进项 | 说明 | | — | — | | 已发布工作流检索优化 | 通过 app.workflow_id 进行检索，显著提升工作流查询性能 | | Workflow Provider 缓存 | Provider 配置缓存机制，减少重复加载开销 |

这两项性能改进对工作流数量较多的实例效果尤为明显——你建的 App 越多，检索越快。

🐛 关键 Bug 修复

| PR | 问题 | 修复说明 | | — | — | — | | #37936 | 部署访问控制耦合 | 将部署访问控制逻辑解耦，提升安全性和可维护性 | | #37944 | Marketplace URL SSR 安全 | 修复 Marketplace URL 的服务端渲染（SSR）安全问题 | | #38007 | HITL 输入框保存按钮 | 修复 Human-in-the-Loop 输入框保存按钮异常 | | #38138 | Unicode 字符支持 | 修复 Unicode 字符处理问题，多语言场景更稳定 | | #38080 | 多模态分段附件索引 | 修复多模态内容的分段附件索引问题 | | #38004 | ADB-PG 7.0 兼容性 | 修复与 ADB-PG 7.0 的兼容性问题 | | #38030 | Markdown 文件预览链接 | 修复 Markdown 文件预览链接被当作附件下载的问题 |

其中 #37936 部署访问控制解耦和 #37944 Marketplace URL SSR 安全属于安全相关修复，建议所有用户关注。

♻️ 代码重构与工程质量

| 方向 | 说明 | | — | — | | 部署访问控制解耦（#37936） | 将访问控制从部署逻辑中剥离，降低耦合度 | | Workflow 检索路径重构 | 从全量扫描优化为基于 workflow_id 的索引检索 | | Agent-v2 同步主分支（#37915） | 夜间构建分支代码回流，保持主分支与 Agent 迭代同步 |

🚀 升级指南

⚠️ 升级前必读：本版本包含新的数据库迁移和环境变量变更，请务必完整阅读以下步骤。

升级注意事项清单

| 事项 | 级别 | 说明 | | — | — | — | | 数据库迁移 | 🔴 必须 | 升级时必须运行数据库迁移脚本 | | 环境变量变更 | 🔴 必须 | 需查看变更说明并更新 .env 文件 | | Docker Compose 配置变更 | 🟡 重要 | 配置文件已更改，需重新应用本地自定义 | | Agent 功能启动 | 🟢 可选 | 如需体验 Agent，需额外启动 dify-agent 和 shellctl | | shellctl 安全 | 🔴 必须 | shellctl 无内置认证，必须在容器内运行 |

Docker Compose 升级步骤

cd docker

# 1. 备份当前配置
cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak
cp .env .env.$(date +%s).bak 2>/dev/null || true

# 2. 拉取新版本代码
git fetch --tags
git checkout 1.16.0-rc1

# 3. 停止服务
docker compose down

# 4. 备份数据卷（非常重要！）
tar -cvf volumes-$(date +%s).tgz volumes

# 5. 检查 .env 文件变更并重新应用本地自定义
#    ⚠️ 务必对比新旧 .env 文件差异！

# 6. 启动服务
docker compose up -d

源码部署升级步骤

# 1. 停止所有服务
#    停止 API 服务器、Worker 和 Web 前端服务器

# 2. 拉取新版本代码
git fetch --tags
git checkout 1.16.0-rc1

# 3. 更新依赖并执行数据库迁移
cd api
uv sync
uv run flask db upgrade

# 4. 重启所有服务

# 5. 如需 Agent 功能，启动 dify-agent 和 shellctl
#    ⚠️ shellctl 必须在容器内运行，无内置认证！

💡 阿强建议：不管你多着急想体验 Agent，升级前先备份 volumes 目录。数据丢了再哭就来不及了。另外，强烈建议先在测试环境跑一遍完整升级流程，确认无误后再动生产环境。

📝 总结

Dify v1.16.0-rc1 是一个方向意义远大于实用价值的版本。Dify Agent 的引入，标志着 Dify 正式踏入”Shell-based LLM Agent”赛道——Workflow 不再只是被动编排工具，而是进化为能主动”动手干活”的协作体。Capability/Task 分离的设计、Agent Builder 的 UI 驱动构建、Workflow 内嵌 Agent 节点，这些设计思路都值得肯定。

但也要清醒看到：沙箱隔离缺失、shellctl 无认证、DSL 导出不可用——这些限制意味着当前版本只能用于受控环境的体验和测试，离生产可用还有距离。如果你是 Dify 重度用户，建议在测试环境升级体验，感受 Agent 范式的变化方向；如果是生产环境，请继续等待正式版发布。

一句话总结：方向令人兴奋，现状需要冷静。rc1 是用来”看未来”的，不是用来”上生产”的。

关注我，持续追踪 AI 应用平台的最新技术动态。

免责声明：

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

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

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

本文转载自：内存泄漏 《Dify v1.16.0-rc1 重磅前瞻：Linux 沙箱 Agent 登场，Workflow 正式进化为”会动手”的协作体》