我要投稿

我们为什么选择 Spring AI 开发智能体，而不是 Dify？

发布日期：2025-11-12 08:18:48 浏览次数： 1535

作者：7sh科技

微信搜一搜，关注“7sh科技”

在大模型Agent智能体开发热潮中，工具选型成为每个技术团队的关键决策。

面对开源低代码平台 dify 这类低代码开发平台与 Spring 官方推出的 Spring AI 和大家熟知的Langchain这类代码级别框架，我们最终坚定选择了后者。

今天这篇文章，我将从架构、可控性、集成能力等维度，深入剖析这一选择背后的逻辑。有些内容可能存在争议，请大家在评论区文明的表达出自己的想法，谢谢。

一、智能体开发的两条路径

当前，构建 LLM 驱动的智能体主要有两类路径：

低代码/可视化平台：如 Dify、LangFlow、n8n等，强调“拖拽即用”，快速搭建对话机器人。

代码优先框架：如大名鼎鼎的 LangChain，支持Python/JS/Java，还有LlamaIndex、以及今天重点想聊的 Spring AI —— Spring 官方项目，强调工程化、可维护性与深度定制。

由于我们公司作为一家以 Java 技术栈为核心、对系统稳定性与安全合规有严苛要求的软件服务提供商，在评估了 Dify 与 Spring AI 后，还是放弃了“看起来更快”的低代码方案，转而拥抱 Spring AI。

二、Dify 的“快”是短期便利，也是长期枷锁

Dify 确实很“香”——开箱即用、界面友好、支持知识库上传、Prompt 编排、多模型接入，甚至能一键部署 Web 聊天界面。但深入使用后，我们发现了几个难以忽视的问题：

黑盒逻辑，调试困难

Dify 的核心流程，比方说 Prompt 拼接、工具调用、记忆管理，这些封装在前端配置和后端服务中，而后端是 ‌Python，基于 Flask 框架写的，对于我司技术团队大部分成员而言，一旦出现异常，比如 RAG 结果不准、工具未触发，排查只能靠“猜”和反复试错，无法像写代码一样打日志、断点调试。

扩展性弱，难以集成业务系统

我们的智能体需要对接内部采购系统很多业务数据，本身对智能体运行结果的展示也与业务功能融为一体。

Dify 虽然支持“Function Call”、MCP等，但其工具注册机制僵化，无法灵活处理复杂数据的逻辑处理、向量数据库数据的高级操作、异步回调或事务一致性等。更别说与 Spring 、MyBatis、Redis、MQ等现有组件无缝协作。

部署与运维成本被低估

Dify 依赖 PostgreSQL + Redis + 向量数据库 + 前端 + 后端多个服务，并作为一个独立系统运行。这意味着：

需要额外维护一套基础设施，对于我们的客户而言，需要多出不少的资源部署成本；

我们很多智能化场景其实与业务系统本身的逻辑、数据高度关联，Dify作为独立运行的系统，意味着业务服务与其之间的交互都要通过RPC方式通信，效率低下。

未来升级版本时，或客户要求对接他们自建的大模型平台（可能是非标API）、智能体平台时，功能不可控，因为这类智能体平台各自的接口均互不兼容，还存在数据迁移风险。

无法复用公司已有的 CI/CD、监控告警、日志收集体系；

三、Spring AI 才是基石

Spring AI 是 Pivotal，现在叫 VMware Tanzu哈，于 2023 年启动、2024 年正式 GA 的官方项目，目标明确：让 Spring 开发者以熟悉的方式构建 AI 应用，可以说是为 Java 生态的企业量身打造的 智能体基石。

无缝融入 Spring 生态，零学习成本

使用 @Service、@Component 编写 Agent 逻辑；

通过 application.yml 配置模型参数、向量存储；

支持 Spring Boot Actuator 监控、Micrometer 指标、OpenTelemetry 链路追踪；

@Servicepublic class CustomerSupportAgent {      @Autowired      private ChatClient client;      public String answer(String question) {            return client.chat(question).getResult().getOutput();      }}

这段代码，任何一个 Spring 工程师都能秒懂。

代码即配置，高度可控

所有 Prompt 模板、文档处理、工具函数、记忆策略都以 Java 代码或资源文件形式存在，同样也支持：

Git 版本管理；

单元测试（Mock AiClient）；

A/B 测试（通过配置切换不同 Prompt）；

动态加载（结合 Spring Cloud Config 实现热更新）。

企业级集成能力

向量数据库及模型：原生支持 Milvus、Qdrant、PGVector及主流的Embedding模型，如BGE系列等；

模型提供商：OpenAI、Ollama、DeepSeek、通义千问、智谱AI的GLM等；

批处理与流式响应：支持 Reactor Flux 实现 SSE 流式输出。

四、开发方式对比

维度	Dify	Spring AI
开发方式	可视化配置	Java 代码 + 注解
调试能力	仅日志查看	断点调试 + 单元测试
对接 CRM	需写 Webhook，逻辑受限	直接注入 Service，事务一致
权限控制	全局角色，无法按会话隔离	结合 Spring 自己实现字段级控制
部署形态	独立系统	嵌入现有微服务

在我们的实际项目中，基于 Spring AI 构建的客服 Agent、智能评审Agent、文件智能编审Agent等，可以复用大量现有业务服务的能力，而且在后续迭代中展现出极强的灵活性。

比如临时增加“专有名词替换”、“意图判断”、“知识粗筛”、“查询业务数据库表数据”、“联网搜索”、“结果重排”、“第三方系统API调用”、“自定义文档切片逻辑”、“自定义Word、PDF文件中的图片及表格解析”、“智能体执行结果回调给业务服务”等等功能，因为是代码级别的开发，这些需求都较为容易扩展。