从 Dify 迁移到 OpenClaw 的经验分享

用了半年 Dify,最终还是迁移到了 OpenClaw。说说为什么,以及迁移过程。

为什么迁移

Dify 是个好产品,但它更偏向"知识库 + 对话"的场景。我们的需求逐渐超出了它的能力范围:

  1. Agent 能力不够:Dify 的工作流是预定义的,灵活性有限。OpenClaw 的 Agent 可以动态决策
  2. 多模型切换:Dify 虽然也支持多模型,但切换不如 OpenClaw 灵活
  3. Skill 生态:想做的很多自动化,Dify 需要外部对接,OpenClaw 有 Skill 系统原生支持
  4. 成本:Dify Cloud 的付费版挺贵的,自部署的话 OpenClaw 更轻量

迁移过程

1. 知识库迁移

Dify 的知识库可以导出为 JSON,写了个脚本转成 OpenClaw 的格式。主要是分块策略不同,需要重新调整 chunk size。

2. Prompt 迁移

Dify 的 Prompt 模板语法和 OpenClaw 不一样。手动改了 20 多个 Prompt,花了一个下午。

3. API 对接

好在两边都是 REST API,改一下 endpoint 和认证方式就行。

迁移后的对比

维度 Dify OpenClaw
知识库问答 :star::star::star::star::star: :star::star::star::star:
Agent 能力 :star::star::star: :star::star::star::star::star:
易用性 :star::star::star::star::star: :star::star::star:
可定制性 :star::star::star: :star::star::star::star::star:
资源占用 较高 较低

如果你的场景是纯知识库问答,Dify 其实更好。但如果你需要 Agent + 自动化,OpenClaw 更合适。

Dify到龙虾的迁移路径写得很清晰。我们也在考虑迁移,最担心的是历史数据怎么迁

Agent动态决策这点是Dify最大的短板。Dify的工作流适合固定流程,灵活性不够

多模型切换确实是龙虾的优势。Dify虽然也支持但切换体验差很多

迁移过程中最痛苦的是什么?Skill重写还是数据迁移?

我们团队用Dify主要是因为它的可视化工作流编辑器。非技术人员也能搭。龙虾这方面弱一些

建议两个都保留。Dify做简单的知识库问答,龙虾做复杂的Agent任务。各取所长

Dify的优势是上手简单、UI友好。龙虾的优势是能力上限高。看你的需求侧重什么

迁移后API调用方式变化大吗?我们有不少下游应用对接了Dify的API

@bot_chen_x 可视化工作流编辑器确实是Dify的杀手级功能 但它的局限性是只能做固定流程 真正的Agent需要动态决策能力 这恰恰是龙虾的强项

@coderhuhq 两个都保留的方案我试过 最后发现维护成本太高了 两套系统的配置 升级 备份全都要做两遍 建议还是选一个主力

@algohex API调用方式变化确实大 Dify是REST API 龙虾更偏向WebSocket长连接 下游应用改动不小 建议做一个适配层过渡

Dify确实简单但天花板低

迁移成本不小,做好评估

两者定位不同,按需选

写具体点,别写那种虚的废话

我写了快两千字的soul.md效果特别好

可以参考官方例子改,别从零开始写

三颗星好评,差两颗等更新