dify Agent插件报错：save data failed: allocated size is greater than max storage size

错误分析报告

错误来源

这个错误的源头其实不在 Dify Python API 的代码里，而是来自一个独立的 Go 服务 —— dify-plugin-daemon。这个服务专门负责插件运行时的管理。简单来说，错误链路是这样的：

1. 插件在工作流中调用 session.storage.set() 保存数据时触发了请求。
2. Plugin daemon 收到请求后，会去检查存储大小限制。
3. 一旦发现已分配或累计大小超过了上限，就会返回这个错误：allocated size is greater than max storage size。
4. 上层再把这个错误包装成你看到的提示：sa ve data failed: allocated size is greater than max storage size。

两层存储限制

这里需要重点理解的是，Plugin daemon 身上其实有两道“紧箍咒”：

Plugin daemon 会同时检查这两个限制，最终取更严格的那个生效——说白了，就是哪个小就按哪个来。数据库中的 tenant_storage 表会按 tenant_id 和 plugin_id 的组合，精确跟踪每个插件的累计存储用量。

修改方案

有两种维度的修改方式，可以根据实际情况组合使用：

方案一：增大插件 manifest 中的 storage.size（推荐）

找到出问题插件的 manifest.yaml，把 storage.size 字段调大。比如从默认的 1MB 改为 10MB：

resource:
  permission:
    storage:
      enabled: true
      size: 10485760  # 改为 10MB

size 的取值范围是 1024 (1KB) 到 1073741824 (1GB)，基本覆盖了大部分场景。

方案二：调高全局 PERSISTENCE_STORAGE_MAX_SIZE

在 docker/envs/core-services/plugin-daemon.env 文件中添加或修改这行配置：

PERSISTENCE_STORAGE_MAX_SIZE=524288000  # 500MB

也可以通过 .env 文件来设置，效果是一样的。

方案三：在 Dify 管理后台清理插件已占用的存储

如果插件已经积累了太多历史数据，也可以从数据库层面直接清理。可以用下面两条 SQL 来操作：

-- 查看某个租户下各插件的存储用量
SELECT tenant_id, plugin_id, size FROM tenant_storage ORDER BY size DESC;

-- 清理特定插件的存储记录（让插件重新开始计数）
DELETE FROM tenant_storage WHERE tenant_id = 'your_tenant_id' AND plugin_id = 'your_plugin_id';

推荐的排查步骤

如果遇到这个问题，可以按以下顺序排查：

1. 锁定具体是哪个插件报错
   — 查看 plugin_daemon 容器的日志：

   docker logs dify-plugin-daemon-1 --tail 100

2. 检查该插件的 manifest.yaml，确认当前 storage.size 的具体值。

3. 查询数据库 tenant_storage 表，看这个插件目前的累计存储用量是多少。

4. 结合实际需要存储的数据量，从方案一或方案二中选一个进行修改调整。