最近团队开源了一款 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: ' api.siliconflow.cn/v1'
api-key: '${your-api-key}'
example:
model: 'deepseek-ai/DeepSeek-R1'

连上之后，通过调用问了一下“你好，DeepSeek”，就可以收到下面的回答：
{
"content": "\n\n\n\n 你好！我是 DeepSeek-R1 ，一个由深度求索公司开发的智能助手，我会尽我所能为你提供帮助。请问有什么可以为你服务的？",
"toolCalls": []
}

除了简单的连接大模型的方法，其实还有很多其他 AI 原语，在我们社区文档中有介绍。
那为什么要+BPM 呢？因为我觉得本质上通过类似 LangChain 的写法去写的 AI 应用目前大多数还是需要去编排的，通过低代码编排出的 AI 应用是较为通用的场景，有些复杂场景需要复杂写法的时候就可以使用编码的方式了。而且，加入 BPM 之后，在写法上，也可以支持人工的交互，类似于需要通过 AI 订票的 AI 流程中间可以有机会让大模型问下你的相关出行信息等。那么有 BPM 的代码大概长下面的样子：
AiProcessFlow<Tip, Content> retrieveFlow = AiFlows.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();

因为我们也是刚刚开源，希望能够得到更多的反馈，让项目更好的向前演进，我本人也是一名技术爱好者，对开源非常有热情。
我们的项目地址是： github.com/ModelEngine-Group/fit-framework
如果大家能够给我们提提意见，我们是非常开心的，会促使我们有更强的动力向前。
如果过程中有一些问题，欢迎给我们 Github 的项目提 Issue 。
如果有意愿或者喜欢，或者只是给我们鼓励一下，希望能给我们 github 项目点个小星星，真的感谢大家~

支持，先 star

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

有 RAG 相关的支持么？

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

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

star 了,支持

已经有人在做了，你搜 langchian4j

但我们已经在用 langchain4j 了

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

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

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

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

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

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

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

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

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

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

欢迎讨论~

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

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

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

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

感谢

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

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

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

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

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

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

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