Dify 1.16.0 引入 Dify Agent Beta：把可复用能力接入沙箱与工作流

一分钟读懂

Dify 在 7 月 17 日发布的 1.16.0 中把 Dify Agent 作为 Beta 功能引入。官方将它定义为可一次配置、反复调用的 AI worker：它可以运行命令、安装程序、读写文件，并携带角色提示词、模型、知识、Skills、Dify 工具和文件。

这不是把原有聊天 Agent 多加几个工具。Dify 为这一能力新增了 Agent 后端与本地沙箱服务，并把同一个 Agent 放进两条执行路径：它既可以作为独立聊天 Web 应用，也可以作为工作流中的一个节点接收任务并把结果交给后续节点。

官方同时明确了边界：Dify Agent 仍处于 Beta。社区版对多终端用户采用的是软隔离，底层容器或基础文件系统可能共享；恶意提示、工具执行或类似攻击仍可能越过预期工作目录。因此，发布方建议将此能力仅提供给可信、非恶意用户，并在严格安全或合规场景使用更强的隔离方案。

背景

Agent 平台常在两种需求之间取舍：一类把模型、工具和提示词直接绑定到单次应用；另一类让能够执行命令和处理文件的运行时承担开放式任务。前者容易配置，后者更适合长链任务，但也引入了环境、权限和复用边界。

Dify Agent 的设计将“能力”和“任务”分开：能力包含模型、角色、知识、Skills、工具和文件，任务则是一次聊天请求或工作流节点的指令。这个划分让同一组能力可以在不同入口复用，而不是为每个流程重新配置一个相近的 Agent。

变化

1.16.0 的发布说明显示，Dify Agent 使用 Linux 沙箱；用户可在界面中设定基础提示词、上传 Skills 与文件，并连接既有工具和知识。发布包还新增 agent_backend 与 local_sandbox 服务，以及对应的运行时、Redis、Shell 控制和密钥配置项。

文档说明，独立使用时，Agent 可以作为聊天应用发布或经服务 API 调用；嵌入工作流时，工作流节点只提供本次任务，Agent 则保留自身能力。这使工作流能够把开放式执行交给一个可复用 worker，再继续编排条件分支、其他节点或多个专业 Agent 的交接。

发布方还把 Agent App 默认开启，并在升级说明中要求自托管部署检查新增服务、环境变量与数据库迁移。这些是一次运行时和部署拓扑的改变，而不只是界面中新增一个 Agent 模板。

影响

观智录认为，值得记录的是 Dify 把可执行 Agent 从“某个应用中的一次配置”推进为可跨应用与工作流复用的运行单元。能力—任务分离能够让团队分别维护 Agent 的长期配置和每次流程的短期目标；它也让 Skills、知识、工具与文件成为可组合的运行时输入，而不只是一段提示词的附属信息。

这条路径也把 Agent 平台的系统责任暴露得更清楚：能运行命令和写入文件的 worker 需要明确的服务、沙箱、密钥、存储与生命周期边界。对使用 Dify 自托管工作流的团队，升级不应只看功能入口，还应把新增服务和隔离模型纳入部署评审。

安全边界

官方文档没有把社区版描述为硬隔离：它明确提示，多用户场景中可能共享底层容器或基础文件系统，恶意输入或工具执行仍可能触及预期目录之外的数据。发布说明还要求生产环境替换 Agent 服务密钥，并列出路径隔离、Shell 输出脱敏和 Landlock 保护等配置与改动。

因此，不能从“Linux 沙箱”推断所有部署都具备独立的每用户或每次运行安全边界。对处理不可信输入、敏感文件或多租户任务的场景，发布方建议使用 Dify Cloud、Enterprise，或部署单独加固的基础设施；具体隔离强度仍应由部署者自行验证。

仍待观察

Dify Agent 仍是 Beta，公开材料尚未给出与既有 Agent 应用相比的任务成功率、资源开销、并发隔离测试或独立安全评测。社区版软隔离在不同 Docker、内核与自定义部署中的实际边界，也不能仅凭发布说明推断。

后续值得观察的是：能力—任务分离能否减少跨工作流的重复配置；新增服务在生产升级中的运维成本；以及 Dify 是否提供可复现的隔离、权限和审计证据来支撑更广泛的多用户使用。