使用 Java 写了一版 LangChain，想听听大家的意见

[CodeCaster]

最近团队开源了一款 Java 版本的 AI 原语，类似于 LangChain ，写法上支持响应式+BPM ，感觉目前应该没有类似的，看了看 SpringAI ，AI 原语部分内容是大差不差的，也是响应式的，但是并没有将 BPM 的内容集成进原语方法中。

同时，在我们开源社区中也增加了连接 DeepSeek 的例子，简单连接大模型的代码大概是下面的样子：

public ChatMessage chat(@RequestParam("query") String query) {
    ChatOption option = ChatOption.custom().model(this.modelName).stream(false).build();
    return this.chatModel.generate(ChatMessages.from(new HumanMessage(query)), option).first().block().get();
}

其中，stream可以调节是否是流式输出。

因为 DeepSeek 也支持 OpenAI 的格式，所以代码上没有特别的 DeepSeek 的痕迹，只需要按照下面的方式修改一下配置就可以连上了：

fel:
  openai:
    api-base: 'https://api.siliconflow.cn/v1'
    api-key: '${your-api-key}'
example:
  model: 'deepseek-ai/DeepSeek-R1'

连上之后，通过调用问了一下“你好，DeepSeek”，就可以收到下面的回答：

{
  "content":  "<think>\n\n</think>\n\n 你好！我是 DeepSeek-R1 ，一个由深度求索公司开发的智能助手，我会尽我所能为你提供帮助。请问有什么可以为你服务的？",
  "toolCalls": []
}

除了简单的连接大模型的方法，其实还有很多其他 AI 原语，在我们社区文档中有介绍。

那为什么要+BPM 呢？因为我觉得本质上通过类似 LangChain 的写法去写的 AI 应用目前大多数还是需要去编排的，通过低代码编排出的 AI 应用是较为通用的场景，有些复杂场景需要复杂写法的时候就可以使用编码的方式了。而且，加入 BPM 之后，在写法上，也可以支持人工的交互，类似于需要通过 AI 订票的 AI 流程中间可以有机会让大模型问下你的相关出行信息等。那么有 BPM 的代码大概长下面的样子：

AiProcessFlow<Tip, Content> retrieveFlow = AiFlows.<Tip>create()
        .runnableParallel(history(), passThrough())
        .conditions()
        .match(tip -> !tip.freeze().get(DEFAULT_HISTORY_KEY).text().isEmpty(),
                node -> node.prompt(Prompts.human(REWRITE_PROMPT))
                        .generate(chatFlowModel)
                        .map(ChatMessage::text))
        .others(node -> node.map(tip -> tip.freeze().get("query").text()))
        .retrieve(new DefaultVectorRetriever(vectorStore, SearchOption.custom().topK(1).build()))
        .synthesize(docs -> Content.from(docs.stream().map(Document::text).collect(Collectors.joining("\n\n"))))
        .close();

因为我们也是刚刚开源，希望能够得到更多的反馈，让项目更好的向前演进，我本人也是一名技术爱好者，对开源非常有热情。

我们的项目地址是： https://github.com/ModelEngine-Group/fit-framework

如果大家能够给我们提提意见，我们是非常开心的，会促使我们有更强的动力向前。

如果过程中有一些问题，欢迎给我们 Github 的项目提 Issue 。

如果有意愿或者喜欢，或者只是给我们鼓励一下，希望能给我们 github 项目点个小星星，真的感谢大家~

[wellCh4n]

支持，先 star

[heqingpan]

样例看起来还是比较简洁的，后面有空会愿意试试。
star+1

[lower]

有 RAG 相关的支持么？

[CodeCaster]

@wellCh4n 非常感谢支持，因为这部分代码还是比较多的，可以后面空了好好看一下~

[CodeCaster]

@lower 有的，其实上面的第二段代码 retrieveFlow 就是这方面的，我们社区的 example 中关于 fel 的部分例子就有，那边可以看代码和文档。不过因为我们现在刚刚开源，对于生态的一些支持还有限，打算接下来会像 LangChain 一样，对生态内容进行补齐，这样，开发者就比较方便实用了~

[lizhian]

star 了,支持

[ReinerShir]

已经有人在做了，你搜 langchian4j

[clf]

但我们已经在用 langchain4j 了

[CodeCaster]

@ReinerShir @clf ，非常感谢二位的提醒，我去大致看了一下 LangChain4J 项目的样例，这个项目拥有很多 Star ，的确是一个优秀的项目，但是我们的版本（我们这个模块叫 FEL ，项目整体叫 FIT ，这里是 FIT Expression for LLM 的缩写）相比之下还是有一些特点的：

1. 我看 LangChain4J 主要是流式处理+异步回调，而我们是采用了响应式编程，这意味着我们可以在编排的 AI 应用的任意节点间增加背压；
2. 我们在响应式的基础上增加了 BPM 的相关方法，比如支持并发流、条件判断等，这对于流程编排来说，更自然的在编码级别进行了支持。

非常欢迎讨论交流，我们也会吸取其他框架的优点，欢饮关注点 Star ，推动我们继续~

[INCerry]

这个和 Semantic Kernel 有什么异同没？它也有 java 版

[lower]

@CodeCaster 有个项目 agents-flex 也提供了执行链，类似 bpm 的功能，而且这个作者还自己搞了一套前端组件😂 感觉如果你想让别人项目集成进去的话，可视化的编排界面会是很大优势

[Suger828]

响应式编程不就是流式处理+ 异步回调结合的吗

[CodeCaster]

@lower 这个想法非常好呀，感觉大家都在这个方向思考，其实我没有介绍我们低代码部分，篇幅限制，我重点先介绍了一下我们高代码部分。实际上，我们的低代码编排部分也在开源进程中，大概再过 2 个月左右，也会在我们的社区出现，的确也有一套前端组件~欢迎持续关注

[CodeCaster]

@Suger828 这位同学对响应式还是挺有研究的，这个可以好好讨论一下。个人观点，流式处理+异步回调不完全等同于响应式，但是响应式里面包含了流式处理和异步回调的内容。

我们来看一下响应式编程的定义：“响应式编程（ Reactive Programming ）是一种以 数据流 和 变化传播 为核心的编程范式，其核心是通过 声明式 的方式构建异步、非阻塞且具备弹性的数据流处理管道。”

通过以上定义，可以看到，响应式会处理数据流，存在流式处理，后面提到需要声明式的方式（ map 、filter 、reduce 等算子方法）以及弹性的数据流处理（背压机制进行流量控制），所以，响应式的范围应该更大一些。

欢迎讨论~

[CodeCaster]

@INCerry 不好意思，这个软件我之前没有听说过，我刚刚去大致搜索了一下，感觉像是编排模型相关的。因为没有做过任何比较，所以不太好评论。但粗略感觉，我们应该不是在一个层次上的。抱歉

[wyntalgeer]

放弃的最好时机，一在调研，二在现在。惊讶于你写之前没有搜同类

[CodeCaster]

@wyntalgeer 感谢你的意见，但是我们团队还是会坚持的。我这里说明一下，我们开源的这个项目，在写之前，并不是没有调研行业周边，而是看了其他框架，设计的思路的确不一样，上面也列出了几个特别的点。

除了这个和 LangChain 比较类似的模块外，我们还有其他几个模块，同样设计理念和业内其他框架不同，比如底层还有一个插件化的编程框架（借鉴 OSGI 的思路）等。我们开源的目的是希望将我们觉得好的东西分享给所有人，在大家的意见之下不断去完善。哪怕能给大家带来一点点思考，也是有价值的。

感谢

[sighforever]

先支持，毕竟是很好的工作。不过 python 那边我也没觉得啥地方要用 langchain 的，java 这边就更算了。

另外我觉得实在没必要在 python 以外的语言上整和 AI 相关的事儿，毕竟无论你运行再快，调用一次大模型全找补回来了，但是在 python 上搞无论是问题解答还是 demo 或者现成的库都太多了。

[CodeCaster]

@sighforever 明白你的观点，也感谢你的支持~但是对于其中的一点，就是“实在没必要在 python 以外的语言上整和 AI 相关的事儿”我觉得这个有待商榷。

我的观点是这样的：当前的事实是，从事 AI 工作的人使用 Python 的最多，Python 方面的 AI 库又多又方便，至于运行的快不快的确不是一个关键点，关键点在于 Python 语言的工程性非常差，而这个工程性差直接导致了，遇到问题难以调试，一旦实际生产遇到一个问题，排查的成本是完全会掩盖之前快速开发的成本的。还有一点就是安全性，Python 语言实在太灵活，导致有很多很多黑科技可以改变语言本身的运行逻辑。当前 AI 实在太火，大多数人又都是“好人”，以至于所有人都忽略了其潜在的风险（之前某大厂大模型投毒事件就是一个真实的例子），所以选择一个工程性非常优秀的语言来做 AI 相关的事情并不是没有必要的。

最后，还是感谢你的支持~

[xiaomushen]

@CodeCaster 做应用，各种语言都可以选。就好比大部分数据库都是 C 开发的，难道说，C 语言是做基于 DB 应用的首选？

[JrD]

@CodeCaster 你这逻辑不通，在不涉及跨部门跨业务的独立团队里，python 的工程性完全可以通过开发规范、架构设计、review 等问题来保证

[CodeCaster]

@xiaomushen 不好意思，我不太明白你的重点讨论点是什么？我同意你说的“做应用，各种语言都可以”，但是我不太明白我上面提到的哪句话让你产生了“就好比大部分数据库都是 C 开发的，难道说，C 语言是做基于 DB 应用的首选？”这样的反问呢？谢谢指出，欢迎讨论

[CodeCaster]

@JrD 我上面提到的 Python 的工程性比较差，这个是相对 Java 语言的，所有语言都可以通过“开发规范、架构设计、review 等问题来保证”，对不对？只是这么做的成本不同语言是不一样的吧？ Java 是公认的工程性比较好的语言，Python 的确灵活性更强，相对的，工程性比 Java 差了不少。

感谢讨论，但是我也表达我的观点，我并不是想针对编程语言引战，我希望这个讨论可以相对客观的来看。Java 和 Python 各有特点，也都各有不足之处。

[xiaomushen]

@CodeCaster 我应该是点错了，不是对你话进行反问。而是针对那个做 AI 应用 Python 最适合，进行反问。
不同的语言适合不同的场景，如果按照这个说法，
1. 因为 Linux 内核是 C 写的，那么跑在 Linux 上的所有应用，C 才是最佳选择。
2. 因为浏览器是 C++写的，那么基于浏览器的前端应用开发，C++才是最佳选择
3. 因为 SAP 是 SAP 开发的，那么实施 SAP ，原厂才是最佳的
4. 因为地里的蔬菜是农民种的，所以最适合炒菜的人，也是农民

等等等~~

[CodeCaster]

@xiaomushen 理解，赞同，因此我们才在 Java 上发力，我们希望能够成功，但是不成功，也能带来一点思维碰撞的贡献也可以。 顺带求各位 V 友，可以给个 Star ，感谢

[xiaomushen]

@CodeCaster 至于那个朋友说通过严格的管理手段和软件系统，Python 大型项目一样可以达到完善的工程化，这个思路也是没错的。那么按照 BBC 的逻辑，我可以反问一句：那么代价是什么？
答案：代价不就是钱么？

不管是 JS ，Ruby ，还是 Python ，PHP ，缺乏了静态编译期强检查的动态编程语言（弱类型更是 debuff ），至少后期想重构，是很痛苦的。当然，通过严格管理，静态代码扫码，不肯重构就杀头....这些手段，也不是不行

[CodeCaster]

@xiaomushen 你说的很对，支持你的观点

[yibo2018]

op 大佬你好，我们目前在做一个 ai 搜房的功能，把客户的自然语言需求，进行 ai 解析成 json ，然后结合私有知识库，mcp （高德），综合分析客户的需求，以及推荐给他合适的房源，这个过程中会用到向量数据库，mcp ，rag ，然后我希望 ai 可以自动进行这几个步骤，而不是被编程。请问你们的项目可以满足吗？

[CodeCaster]

@yibo2018 你好，首先，我们这两天在紧急将 MCP 支持到框架中来，因为原计划社区路标是 6 月份做的，但是现在看优先级需要不断提升。其次，分析一下你的诉求：

1. “客户的自然语言需求，进行 ai 解析成 json”：标准的通过提示词访问大模型获取你要求的结果的过程，直接通过调用提示词模板，然后调用大模型即可；
2. “结合私有知识库”：代码仓库的知识库检索的例子有，当前恰好发现了一个内部 bug ，导致该例子启动失败了，正在修复中，待社区修复的 PR 合入之后，就可以正常检索；
3. “mcp （高德）”：正如上面所说，MCP 正在作为 feature ，最近紧急添加到下一个版本中，这么火的概念，一定会支持；
4. “rag ”：这个在我们的最后一个例子中有，是可以正常运行的，功能齐备。

综上，从功能点上来看，社区正在做一些演进，修复核心问题和增加 MCP 后，理论就可以支持你的诉求了。

但是，你提到了“ai 可以自动进行这几个步骤，而不是被编程”，这样的解决方案一般更趋近于“Manus”的解决方案，即“动态思维链”，是一个 Agent 级别的解决方案，我们的框架是类似 LangChain 的相对底层的 AI 编程框架，可以通过编程的手段来实现一个类似“Manus”的应用，但是直接达到你说的“不编程”，是做不到的。就好比，使用 LangChain 也需要通过一定的编程来做到。

话说回来，我们的项目群（ https://github.com/ModelEngine-Group ）中还有一个低代码编排 AI 应用的项目，暂时可以静态编排来完成你的诉求，代码量也不多，可以关注一下（ https://github.com/ModelEngine-Group/app-platform ）。而动态编排，这个属于社区的路标，需要未来演进。

感谢关注，希望可以点个 Star~有更多问题，可以在代码仓 readme 中找到项目群，进群咨询。

[windrun]

@yibo2018 #28 哥们，能加个绿泡泡吗？我们也在做类似的场景，可以一起交流。另外看你 id ，我有些恍惚了。。。
base64：SGVsbG9Vbmtub3du

[uselesswater]

看了样咧，还是蛮不错的，我很烦 Spring AI 那一套，很多 api 的使用让人非常难受，我想请问一下你们的生态支持，目前怎么样。

[CodeCaster]

@uselesswater 生态分两块，一块是基于的底层框架，一块是支持的外部模型等。

对于一，目前样例还是基于下面的 FIT 编程框架的（同一个代码仓库，另一个目录），而 FIT 编程框架是一款插件式的编程框架（支持聚散部署），可以去集成 Spring ，也可以独立运行，目前正在做这一块与底层框架的解耦，解耦之后就可以独立运行了。

对于二，目前代码正在做一次大的重构，你如果关注我们的代码仓的话，可以发现，我们现在一直在发里程碑版本（ M1 、M2 ，下面还会发一个 M3 ），正式版本版本在等这次重构之后再发（ API 不变，始终是流式的），而外部模型，目前人力不太够，因此仅支持了通用的 OpenAI 格式。

至于其他细节问题，欢迎来我们的相关群组讨论，在我们代码仓 readme 中有群组地址。我们这个项目开源了差不多 3 个月吧，现在在持续社区建设中，非常需要大家的 star 和关注。https://github.com/ModelEngine-Group/fit-framework