大家是否不太需要 Java 版本的 AI 开源项目？

[multiarrow]

先上链接： https://github.com/moyangzhan/langchain4j-aideepin

如题，本人在维护一个基于 langchain4j 的 AI 项目，工作流那块参考了 dify 和 ragflow ，图谱相关的参考了 graphrag 。

整个项目维护至今，根据 issue 或群里的反馈，感觉大部分的用户都是简单尝试，少部分是为了理解技术细节，至于实际营运，没有明确的数据，不好下定论，但应该是很少的。

github 上目前 java 版本开源的 AI 工作流是很少的，就算只用来参考，点赞也不应该只有几百 star ，所以挺疑惑的， 希望大家能给点答案，thx~

[zuotun]

Java 就不是拿来干这个的，首先语言就选错了，另外几百 star 也很多了。社交媒体玩多了，这里没有点赞这个东西，用词就不严谨。
个人看法：简单看了一下，项目中文味太重，我看到这种 README 基本都是跳过的。排版也不太好，一眼看过去有点难受。你不是都参考了吗，为什么不去参考一下别人的项目 README 怎么写的呢。
此外例如`adi-bootstrap/Dockerfile`里明明`EXPOSE 9999`结果给的运行命令却是
```bash
docker run -d \
--name=aideepin \
-e APP_PROFILE=[dev|prod] \
-v="/data/aideepin/logs:/data/logs" \
aideepin:0.0.1
```
你的端口映射呢？

[lqw3030]

工作流和 ai 不是强绑定关系，spring ai 在 trend 上热度就挺高的

[paranoiagu]

关注，

[Mandyer]

说实话，在企业工作中，还是没看到很好的应用场景，联系了多家 AI 公司(包括大厂)，压根没有提供很好的亮点案例

[jarry777]

公司的项目直接外挂 dify ，让产品自己先去试。
几乎每个月都有功能更新，从实用角度出发，有接口可以调的，不一定非得再造轮子（又不是不能用）。反正外挂的组件已经很多了，也不差这一个。
自己的项目用的 Spring AI ，跟着文档看看源码。

[ychost]

Java 做工作流太复杂了，尤其是像 Dify 这种全链路都是流式函数的模式，Java 要是用 Flux 那套去实现的话成本得翻几倍

[BestPix]

最近看一个新开源项目 AIFlowy ，也是对标 dify ，也是 java 开发的，走一步看一步吧

[mmdsun]

支持. 本人最近也在写 ai 应用,对比过 langchain4j 目前用的 spring ai 。
企业知识库、智能客服这些还是有人用的。

https://www.v2ex.com/t/1123682

[proxyai]

是的, 完全没必要, 原生 API 非常简单

[Demon7z]

前段时间用了几天的 langchain4j 做测试用,还挺好用的

[wenssss]

点赞了哈，加油

[CodersZzz]

@BestPix github 没有搜到呢。有链接吗

[catamaran]

ai 这块的资料用到编程的地方基本都是 python

[xiaomushen]

@lqw3030 本来就是不强绑定的关系，但是偏偏有些人喊着和 python 强绑定
不就是调包侠么，啥编程语言都可以做啊，居然愣生生分出个高低贵贱

[conn457567]

我司从去年开始做 AI 项目就选的 java ，因为已经存在的各种中间件都是优先适配 java 的，努力了快一年，今年已经开始转 python 了。因为现在 ai 这个方向变化太快了，生态上 python 和 js 已经领先太多。别人开源项目都已经在搞 agentic MCP 了，java 还在折腾 workflow ，而 workflow 是 23 年热点。现在除非大公司选择 java 并投入大量人力去丰富生态。小公司根本就不可能对抗整个 python 在 ai 领域的生态了。

[xiaomushen]

@conn457567 但搞来搞去，钱是赚不到的。。。

[conn457567]

而且 java 语音天生的缺陷，处理起 sse 这种流式业务实在太麻烦了，如果用 flux 那一套的话业务复杂起来根本玩不动，目前真正使用了 flux 的大型项目我知道的只有网关，其他的都是玩具类的。在里面折腾这些远不如换语言，python 的协程天生适合处理 sse 这种流式的业务

[multiarrow]

@lqw3030 我说的不高是相对 python 类似项目而言的，确实是差距挺大的

[multiarrow]

@jarry777 觉得你说的很有道理，再结合 @Mandyer 的评论，其实就是因为没有好的应用场景，不值得再造轮子。docker 起一个 dify 的服务，这样的话公司内部即使只有 java 团队，使用接口调用也算是把 dify 的服务集成到自己的项目中了，至于是否要进行 dify 的二次开发，找到应用场景再说~~

[multiarrow]

@xiaomushen 是的，AI 应用本来就是什么语言都可以写的，我用 java 实现也是考虑到国内使用 java 的人非常多

[multiarrow]

还有一点，看到有人提到 java 做工作流太复杂，但就我个人而言，语法层面确实 python 相对简洁，但实际上大部分时间是花在整体架构设计上，至于编码实现，python 可能会比 java 快，但也没有快到非 python 不可的地步

[xiaomushen]

@multiarrow 可能都是初哥吧？工作流这种东西做了几十年的玩意儿，各种语言都实现过不知道多少遍的轮子，在 2025 年，居然还有人拿出来作为说辞...

[xiaomushen]

@multiarrow Dify 本身的工程质量一塌糊涂，不过现阶段也不是大问题：1. 本身还是大玩具阶段 2. AI 应用，除了做擦边，灰产，其他的都是雷声大雨点小，挣不到钱。市面上预算不够，确实不值得再造轮子。