CodeCaster

看到上面大家对微服务和单体讨论了很多，有非常多优秀的见解。如果把微服务和单体服务看做两个极端，那么微服务的出现就是为了解决之前单体服务的一些问题的，只不过，微服务架构本身也有自身的问题，因此，我们团队此前也有思考过是否有一种模式，可以让微服务和单体服务兼而有之，于是，我们开源了一款基础框架，fit 。

fit ，其思想正如其名字一样，我们希望每一个插件，作为单体服务的时候可以运行，组合（ fit ）起来之后依旧可以运行。假如有 N 个插件，那么每一个插件都可以像微服务一样作为一个一个单独的进程启动，对外提供服务，也可以把这 N 个插件，聚合在一起，形成一个单独的进程，启动，就像一个单体服务一样。这个过程中，插件的代码不需要做任何改变。当然，N 个插件可以自由组合形成 M 个进程。

当他们作为微服务互相调用的时候，他们之间的通信是 RPC 调用，存在网络消耗，但是一旦转换成微服务之后，调用可以自动识别变成进程内的内存调用，没有网络开销。这个特性在我们框架中称之为聚散部署。

也就是说，通过我们的框架写出来的代码，不需要经过重构，就可以在微服务和单体之间切换，完全由开发人员在部署阶段自由选择。

我们的框架是今年初开源的，希望大家能够支持一下，如果觉得我们的框架的这个设计思路有帮助，最好帮我们点的 star ，链接： https://github.com/ModelEngine-Group/fit-framework

@ebony0319 我们团队写了一个开源框架，fit ，就是做的这个，在我们框架中，可以按照微服务的方式写一个一个的插件，插件与插件之间没有任何耦合关系，通信全部是接口，每一个插件都可以单独部署，就像微服务一样，也可以聚合在一起部署，形成一个单独的进程，就是单体架构，关键的一点是，这个从微服务到单体，或者从单体到微服务的转换过程，每一个插件是不用修改任何代码的。这个在我们框架中，叫聚散部署，欢迎来我们的开源项目参观点星，链接： https://github.com/ModelEngine-Group/fit-framework

我觉得 @lnbiuc @andyskaura 说的挺对的呀，@moverinfo 你描述调用 OpenAI 发生了 400 错误，那么根据 http 的约定，直观理解就是调用参数存在问题，那么就需要看一下调用参数是什么，你发起的 http 请求，参数可能有 query ，form ，header 等等，的确是需要看一下你的参数情况的呀，我觉得你只是说了对接 OpenAI 有问题，发生 400 错误，但是不提供调用情况，和可能的 400 错误的详细信息，却说信息很充分，这个逻辑不成立呀。

当然，你自己已经通过尝试发现是网络问题了，解决问题了就好。

@moverinfo #41 你好，我发现你的回复都没有点击平台的回复，这样的话，别人都是不知道你回复了的，是没有提示的。我是特意关注了下，找了下之前的留言，才发现你的回复的。首先感谢能够得到回复。

然后，我也很高兴你可过我的项目（因为没有回复，我不确定是不是理解有错），之所以我比较感兴趣，就是因为你的框架也有模块化的特点，但是，模块化 != 插件化。

模块化，我们当前用任意框架写的代码，比如 Spring ，我也可以创建若干个 Module （模块），然后通过一个核心模块的 pom 来组织各个其他模块，这样也是分模块的。因为我看不到你的项目的整体架构图，所以我对此只能先交流来慢慢了解。

插件化，我实现的插件化和模块化的最大区别是没有 pom 的依赖，我不确定你的框架是不是如此。插件与插件之间的交互都通过接口来实现，因此，插件的业务逻辑不随插件的部署状态而改变，意思是，在 FIT 框架下，插件 A 和插件 B 可以作为一个 Mono （单体）服务聚合启动，同进程，此时，他们的通信为本地方法通信，他们也可以分别作为两个微服务分别启动，两个进程，此时他们的通信为 RPC 通信，但是插件的代码是完全不感知的。这个就是 FIT 框架的最大特点，支持插件的聚散部署，在此基础上，我用插件写了一个热插拔的插件，使得整个体系也支持了插件的热插拔。

也就是说，FIT 框架的设计是和 Spring 有比较大的区别的，但是和你说的模块化比较接近，正因为这个原因，所以我才想和你再多交流一下。感谢

PS：我看到你的项目之后，先点了一个 Star 支持了一下了

看了 github 的项目，其中有提到模块化，方便交流一下么（方便的话，可以加一下我 wechat：jiyujie ）？我这边做了一个插件化的开发框架（ https://github.com/ModelEngine-Group/fit-framework ），上层搭载 AI 框架，同在推广求 star 中，感觉可以交流一下技术，感谢

@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

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