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

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

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

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

@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 中找到项目群，进群咨询。

我们团队今年年初开源了一款 Java 的编程框架，支持聚散部署（微服务和单体应用的无缝切换），有兴趣可以来看看，项目地址： https://github.com/ModelEngine-Group/fit-framework

就算是来改改文档，修修错别字也欢迎！

这个项目里面还包含了一款类似于 LangChain 的 AI 框架，FEL ，欢迎探索。

项目群中还有一个类似 Dify 的 AI 编排框架，项目地址是： https://github.com/ModelEngine-Group/app-platform

也欢迎来关注，各种修改，再小都是帮助！

我们团队搞了高代码的 AI 编程框架（ https://github.com/ModelEngine-Group/fit-framework ）和低代码的 AI 框架（ https://github.com/ModelEngine-Group/app-platform ），才开源没有多久，欢迎尝试，然后也弄了一个简单的官网（ http://modelengine-ai.net/），里面有下载部署安装指南。

希望能帮忙 Star 一下，感谢~

我会每次问大模型问题时，最后带一个“谢谢”，希望他以后记得，有一个小碳基还是很有礼貌的。

看完这个问题以及上面所有的讨论，我想提出一种全新的思路，大家可以一起讨论下。

首先，在微服务出现以前，大多数服务是以单体应用的形式存在的，后续由于各种原因（项目变大，需求变多等等）演变为微服务。单体应用有单体应用的优点与缺点，微服务也有微服务的优点和缺点。这两种模式的争论其实一直存在，正如 @micean 说的，“从一个极端到另一个极端”，这句话一点不错。我觉得其实是有解决方案的，是不是可以在这两个“极端”中找一个平衡点呢？

记得 2023 年的时候，google 开源了一款软件，叫 service weaver ，他有一个口号，“以单体形式编码，以微服务形式部署”，他的这个思路非常新颖，主要想告诉大家的一点就是，编码的时候可以按照一个模块一个模块来开发，互相没有耦合，但是最终部署的时候可以选择是单体应用一起部署，或者是微服务分开部署。

其实，我们团队在这之前也一直在做这方面的探索，但是一直没有开源，直到 2025 年春节前，我们的项目也开源了，我们以 Java 为主，推出了一套插件化的开发框架，每一个模块都可以以插件进行开发，插件之间互相不感知，但是我们参考 OSGI 的思想（@ioufev ），做到了插件可以聚合成一个进程部署（单体应用形态），或者分开部署（微服务形态）。

如果做到了这一步，是不是可以解决楼主的问题呢？其实微服务并不是一个错误的方向，而是在技术的螺旋式上升演进过程中的一个关键点。

以下是我在知乎上回答的类似问题的回答： https://www.zhihu.com/question/11654944781/answer/96580243167
这个是我们这个插件化框架的社区地址： https://github.com/ModelEngine-Group/fit-framework

我们项目刚开源不久，欢迎来讨论单体应用和微服务之间的相关问题，如果有同学们喜欢，也可以给我们点个 Star ，鼓励一下我们，感谢~

个人备案也需要一点时间，最近刚好在备案，看了看流程，流程理论上来说也不复杂，就是费时，注册完域名，需要邮箱实名（这步很快，阿里云上 20min 搞定了），然后是个人实名（这步稍微慢一点，但也是小时级完成的），接下来的步骤稍微麻烦一点，首先，个人实名之后，这个实名信息会发送给管理局，但是管理局不清楚周末上不上班，反正就是等待 3 个工作日再往下做成功率最高，等了 3 个工作日之后，需要在云上购买一个 ECS ，时间至少需要满 90 天（不清楚是不是所有云都是这个要求，但是云厂商肯定还是希望购买他们服务的，记住，这个是 90 天不是月，比如 2 月购买的机器，买一个月就没有 30 天，我就是前几天买的，买完真心疼），然后弄个弹性公网 ip 就可以正式备案了，备案说的是 1-20 个工作日吧，就是等。

我也是最近在搞开源社区推广，要弄一个域名，才想到的备案，才正好研究了下这个流程，楼主要是觉得有用可以点我个人信息给我项目加个 star 哈~

这个需要结合业务一起来看，就比如你说的这个打卡的例子，显然是一个实时性并不高的业务场景，每天刷新一下结果就可以了，那么用 MySQL 存储每个人的打卡记录，每天定时任务离线计算结果，同时，对一定时间之前的打卡数据转移至冷数据表，保证热数据表数据量不会无限增长。

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

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

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

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

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

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

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

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

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

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

感谢

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

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

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

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

欢迎讨论~

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

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

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

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

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