摘要：Dify 实际上已经具备与 Manus 相同的能力，只是被沙盒环境的权限管理锁死了。

Dify 实际上已经具备与 Manus 相同的能力，只是被沙盒环境的权限管理锁死了。

这篇文章，教你解锁 Dify 沙盒环境的各种限制。

一旦解锁，你可以使用 Dify 做这些事：

1. 正常安装任意第三方 Python 库，不再报错operation not permitted

2. 扩展：使用代码节点，完成 Python 能做的任意工作

3. 正常处理本地文件，不再报错No such file or directory

4. 扩展：像 Manus 一样创建一个ToDo.md来维护更新任务

5. 扩展：配合 Python，可以生成任意文件，包括但不限于 Excel、Word、PPT 等

条件：需要私有部署的 Dify，官方云端版本不行。

Dify 配有一个沙盒环境，本质上跟 Manus 之类 Agent 操作的那个“电脑”是一个东西。

1. 那个“电脑”关联你电脑的某个文件夹，可以存储工作流应用产生的文档

2. 预装了 Python 和 nodejs 环境，理论上能实现任意你想要的“电脑”操作

这个沙盒环境在 Dify 的入口是代码执行器工具和代码节点。

你在代码节点写的 Python 或 JavaScript 代码，运行时相当于在这个台电脑的终端里使用python3 daima.py指令。

理论上，你可以像上面截图一样，通过这个 Python 脚本，读取那个“电脑”文件夹里的文件、编辑内容或者生成一个新文件。

但是 Dify 的原生配置考虑到安全性，锁死了这个沙盒环境的大部分权限。

所以常规版本，我们使用沙盒环境里的 Python 只能完成成一些变量转换、http 请求之类的几乎不需要任何系统权限的“低级”功能。

这很不好玩。

接下来，我们把这些权限都放开，彻底解锁 Dify 的创造力！

首先是权限问题，这个问题有两个解法：

1. 按需解锁，但是需要频繁折腾；

2. 一次性解锁，别玩风险操作就好了。

官方其实是给了放行权限入口的，在dify/docker/volumes/sandbox/conf/config.yaml这个文件中，通过allowed_syscalls列表来扩展。

一共包含 500 个权限分类，对应编号 0-499，部分编号对应的权限如下：

# 基础文件操作

-0 # read – 从文件描述符读取数据

-1 # write – 向文件描述符写入数据

-2 # open – 打开文件

……

# 系统操作

-13 # rt_sigaction – 检查或修改信号处理

-14 # rt_sigprocmask – 检查或修改阻塞信号

-15 # rt_sigreturn – 从信号处理程序返回

……

# 内存保护

-331 # pkey_free – 释放内存保护键

-332 # statx – 扩展的文件状态

你可以根据官方 FAQ 的介绍，根据自己的需求改写官方提供的那个text.py脚本，里面包含你想要执行的代码，然后运行官方提供的main.go代码，程序会输出你缺失哪些权限，对应编号是什么。

这个显然有点麻烦。

我是用的方式是“一把梭哈”：把所有权限都放行。

也就是，我把config.yaml配置文件中allowed_syscalls的值里，把0-499全写上了。

在确保只有自己用、不会有啥危险操作的情况下，问题好像也不大？

Tip

以数组的形式写，并且注意配置文件的格式，冒号和数组之间留一个空格

到这里，你可以在dify/docker/volumes/sandbox/dependencies/python-requirements.txt填写任意你需要的第三方库，重启 sandbox 就可以正常运行了。

但是还不能正常读取和生成文件。

因为有两个问题：

1. 沙盒环境里 Python 运行生成的文件，需要跟你电脑的文件进行映射，否则你看不见它们；

2. 在工作流上传文件，进入到沙盒环境后，文件会被重命名，这个命名方式使用了一种不可逆的加密算法。

先解决第一个问题。

沙盒环境运行代码后生成的文件会被存在/var/sandbox/sandbox-python/tmp文件中，这个文件与我们的电脑文件没有进行映射，所以我们看不见他。

修改dify/docker/docker-compose.yaml大概 739 行处的 sandbox 配置信息就好了。

加这么一行：- ./volumes/app/storage/upload_files:/var/sandbox/sandbox-python/tmp/upload_files

修改后大概这样：

然后解决第二个问题：怎么找到刚上传的文件。

因为 Dify 用的那个文件命名算法是不可逆且随机的，所以完全没办法根据你原来的文件名推断出它上传进工作流以后对应谁。

大家可以测试一下，在本地部署的工作流中上传一个文件后，在你dify/docker/volumes/app/storage/upload_files/6**随机数命名的文件夹下面会多出一个随机字符串命名的文件。

有一位博主（找不到原始出处了）分享了一个使用文件大小+时间，在沙盒中查找匹配的方式，迂回解决了这个问题。

下面是代码：

import os

import time

from datetime import datetime, timedelta

def main(filesize):

# 存储符合条件的文件

matched_files =

# 获取当前时间

current_time = time.time

# 检查 upload_files 文件夹

upload_dir = ‘/tmp/upload_files’

# 递归遍历文件夹中的所有文件

for root, dirs, files in os.walk(upload_dir):

for filename in files: # 只处理文件，忽略文件夹

file_path = os.path.join(root, filename)

# 获取文件状态信息

file_stat = os.stat(file_path)

# 获取文件修改时间

file_mtime = file_stat.st_mtime

# 计算文件时间差（分钟）

time_diff = (current_time – file_mtime) / 60

# 检查文件大小和修改时间是否符合条件

if file_stat.st_size == filesize:

matched_files.append((file_path, file_mtime))

if matched_files:

# 按修改时间排序，取最新的文件

newest_file = max(matched_files, key=lambda x: x[1])

return {“file_path”:str(newest_file[0])}

else:

return {“file_path”:upload_dir}

把它们放在代码节点中，其中输入变量名为filesize，对应开始节点中的文件-大小；输出变量为file_path，字符串类型。

然后连到后面其他会用到文件处理的节点，直接用 Python 或者 JavaScript 处理就好了。

至此，所有 Dify-sandbox 被锁死的权限就全解开了。

我之前使用 Dify 的 Agent 策略，给大模型配了一个代码解释器和图表 MCP，让它帮我做了一个非常详实的数据分析报告。

这里让 Agent 分析表格，就必须在 Python 里调用上传的 Excel 文件以及使用 Pandas 库，不解锁的话是没法玩的。

我在 AI 学习行动圈知识星球里发过不少 Dify 的工作流 DSL 和玩法。扫码加入星球搜索Dify就能找到。

这是一个我和人人都是产品经理社区共同运营了超过 500 天的 AI 交流圈子。

我的各种 AI 研究心得、发现的好应用、开发的小项目都会在里面分享，目前圈子有核心三个交流学习平台。

7 个微信群，早报和日常交流

微信群里每天一早有 AI 早报，上下午还有“读报时间”，以及我每天不定期刷屏级的各种 AI 工具体验、提示词编排思考、行业新闻解读同步。

以及，你可以在群里讨论任何与 AI 相关的工具、应用问题，几乎都能找到答案。

腾讯文档-圈友空间

用来沉淀体系化、深度的 AI 文章和超长的工程化提示词，不定期更新。

当前包括：Claude code、Cursor、Manus等顶级产品的系统提示词和工具列表，各种深度的 Agent 白皮书和实践指南

知识星球-每日报告、工具和实战经验分享

我在星球里主要维护「实战分享」「工具箱」和「情报局」三个标签

实战分享是可以在日常工作和生活中直接应用的提示词和效率工具。上面截图里的 Step-Back 提示词就非常好用，堪比 o4。在公众号、直播中演示的所有 AI 实战应用的提示词也都在这个标签下。

AI 工具和鲜知道就是好用的、热门的 AI 工具、资讯分享，我把那些太技术、太浮夸的都筛选了，放进这个标签的都是可以直接用来的好玩儿！

星球还有一个“专栏”体系，目前的定位跟标签差不多。

本文的项目源代码已经发布在星球，扫码加入搜索提示词增强系统即可。

来源：人人都是产品经理