在大模型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 流式输出。
四、开发方式对比
在我们的实际项目中，基于 Spring AI 构建的客服 Agent、智能评审Agent、文件智能编审Agent等 ，可以复用大量现有业务服务的能力，而且在后续迭代中展现出极强的灵活性。
比如临时增加“专有名词替换”、“意图判断”、“知识粗筛”、“查询业务数据库表数据”、“联网搜索”、“结果重排”、“第三方系统API调用”、“自定义文档切片逻辑”、“自定义Word、PDF文件中的图片及表格解析”、“智能体执行结果回调给业务服务”等等功能，因为是代码级别的开发，这些需求都较为容易扩展。
快，不是唯一标准，稳，才是企业底线！
Dify 这类低代码平台降低了 AI 应用开发入门的门槛，快速实现一些智能体原型效果，这些确实值得肯定。但对企业级智能体而言，“可控、可测、可运维”远比“拖拽快”更重要。
五、课代表小结
选择Spring AI 这类代码级别的开发框架虽然不是最快的路，但一定是更稳妥的路。它让我们在享受大模型能力的同时，依然保持对系统的完全掌控，这正是我们这些 Java 企业开发者最珍视的价值。
如果你也正在Java web生态系统中，构建面向生产环境的智能体场景，不妨问问自己：
你是要一个看似灵活易用的“拖拉拽的低代码工具”，还是一个“真正自主可控、高度灵活、与业务结合更紧密”的企业级产品？
