CodeCaster 最近的时间轴更新 CodeCaster 最近的时间轴更新 |
CodeCasterV2EX 第 736478 号会员，加入于 2025-02-24 11:22:43 +08:00今日活跃度排名 10744 |
全职开源，跪谢各位V友，求一个Star，项目地址：https://github.com/ModelEngine-Group/fit-framework
| Claude Pro 账户如何使用 Claude Code？ Claude • CodeCaster • 17 小时 8 分钟前 • 最后回复来自 CodeCaster | 4 |
| 最近看 Coze Eino，对比下我们做的 FEL 框架，想听听大家意见 程序员 • CodeCaster • 19 小时 41 分钟前 • 最后回复来自 CodeCaster | 6 |
| 请问，有什么站点可以画简单草图出前端页面的？ 程序员 • CodeCaster • 208 天前 • 最后回复来自 zzNucker | 4 |
| 使用 Java 写了一版 LangChain，想听听大家的意见
1 Java • CodeCaster • 116 天前 • 最后回复来自 CodeCaster
|
32 |
CodeCaster 最近回复了
17 小时 8 分钟前 回复了 CodeCaster 创建的主题 › Claude › Claude Pro 账户如何使用 Claude Code？ |
@TimePPT #3 我在看这个之前，各种重启，然后去掉了几个莫名其妙的 token ，自然就好了，我也不知道是哪一步起的作用，还是很感谢
19 小时 4 分钟前 回复了 CodeCaster 创建的主题 › Claude › Claude Pro 账户如何使用 Claude Code？ |
@TimePPT 操作系统 Mac ，终端 Iterm2 ，选择了第一种登录方式之后，浏览器跳转登录授权，然后 iTerm2 弹出登录成功，看到登录的用户名的确是 Pro 的用户名，然后输入指令报错：
```
API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth authentication is currently not supported."},"request_id":"req_011CTajEmJNeKc3HL37Lf91d"}
```
```
API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth authentication is currently not supported."},"request_id":"req_011CTajEmJNeKc3HL37Lf91d"}
```
19 小时 41 分钟前 回复了 CodeCaster 创建的主题 › 程序员 › 最近看 Coze Eino，对比下我们做的 FEL 框架，想听听大家意见 |
@Isuxiz #5 我觉得你可能言重了，这篇文章本意是选择了另一种编程范式进行实现，对比一下，并没有表达谁优谁劣，只是想说是不是不同场景用不同方式会更合适。所以我没有想引战，没有想分胜负。
另外，当前的确是针对两个框架在比较，的确 Eino 是通过字符串来连接 ID 的，这个是事实而已。
我觉得讨论没有问题，但是问题上升了可能需要适可而止了。求同存异。感谢支持~
另外，当前的确是针对两个框架在比较，的确 Eino 是通过字符串来连接 ID 的，这个是事实而已。
我觉得讨论没有问题，但是问题上升了可能需要适可而止了。求同存异。感谢支持~
20 小时 41 分钟前 回复了 CodeCaster 创建的主题 › 程序员 › 最近看 Coze Eino，对比下我们做的 FEL 框架，想听听大家意见 |
@Isuxiz 感谢你的回复！你说得对，DAG 理论上确实表达能力更强，但我想从另一个角度来看这个问题。
响应式编程本身就是一种编程范式，FEL 使用响应式流来描述。就好比面向过程什么都能写，为什么要面向对象？面向对象并不是没有存在的必要，理论上图灵完备的语言都能实现相同功能，但不同范式解决的是开发效率和代码质量问题。
从实际开发体验看：
响应式流天然支持编译时类型检查，链式调用的上下游类型必须匹配才能编译通过。而 DAG 的节点连接往往依赖字符串 ID ，类型错误要到运行时才能发现。
语法验证：
``` java
// FEL - 编译时就知道类型不匹配
flow.prompt(xxx).generate(model).reduce(stringReducer).someIntMethod() // 编译报错
// DAG - 运行时才发现节点名写错了
graph.AddEdge("node_model", "nod_log") // 拼写错误，运行时才报错
```
然后是认知的问题，我觉得大家的确都学过图，但在日常业务开发中，我们更习惯"数据流转换"的思维模式。响应式编程让代码读起来更像业务描述："接收请求 → 处理 prompt → 调用模型 → 处理结果"。我不知道大家怎么看？
我们并不反对 DAG 设计，而是认为 **不同的工具应该匹配不同的场景**。就像 SpringMVC 的注解式编程和传统 servlet ，理论能力差不多，但开发体验天差地别。
还是非常感谢你的讨论~
响应式编程本身就是一种编程范式，FEL 使用响应式流来描述。就好比面向过程什么都能写，为什么要面向对象？面向对象并不是没有存在的必要，理论上图灵完备的语言都能实现相同功能，但不同范式解决的是开发效率和代码质量问题。
从实际开发体验看：
响应式流天然支持编译时类型检查，链式调用的上下游类型必须匹配才能编译通过。而 DAG 的节点连接往往依赖字符串 ID ，类型错误要到运行时才能发现。
语法验证：
``` java
// FEL - 编译时就知道类型不匹配
flow.prompt(xxx).generate(model).reduce(stringReducer).someIntMethod() // 编译报错
// DAG - 运行时才发现节点名写错了
graph.AddEdge("node_model", "nod_log") // 拼写错误，运行时才报错
```
然后是认知的问题，我觉得大家的确都学过图，但在日常业务开发中，我们更习惯"数据流转换"的思维模式。响应式编程让代码读起来更像业务描述："接收请求 → 处理 prompt → 调用模型 → 处理结果"。我不知道大家怎么看？
我们并不反对 DAG 设计，而是认为 **不同的工具应该匹配不同的场景**。就像 SpringMVC 的注解式编程和传统 servlet ，理论能力差不多，但开发体验天差地别。
还是非常感谢你的讨论~
1 天前 回复了 CodeCaster 创建的主题 › 程序员 › 最近看 Coze Eino，对比下我们做的 FEL 框架，想听听大家意见 |
@mightybruce 对于开发 AI Agent ，使用现有的各个 AI 基础框架都可以，比如 LangChain 、Eino 、SpringAI ，我们的框架也提供了一套 Java 的 AI 原语，条条大路通罗马，我们并不是说开发 AI Agent 只能用我们的，用其他优秀的框架也可以的~ 只不过，我们想提供一种新的思路，因为当前的框架构建 AI 流程的过程基本都是通过图的，我们结合了响应式的写法，从写法上不一样，只是这样而已，提供代码示例供大家参考，来讨论一下而已。
我觉得如果这样写简单，本身也是好的
我觉得如果这样写简单，本身也是好的
4 天前 回复了 Ketteiron 创建的主题 › 程序员 › 2025 年，我对"单体 vs 微服务"的预测 |
@Aresxue #93 我们的代码仓库准备拆分啦，因为现在 AI 太火了，所以介绍中是提到 AI 的，AI 相关的是另外一个模块，基于 fit 框架长出来的，最近正准备写一篇文章呢。拆库就是为了把底层框架和 AI 相关的模块分离开。
最底层的框架的确是为了传统软件工程的，fit 框架的第一行代码是 19 年底诞生的，此时 AI 并没有火。
你提到了成熟的 SofaBoot 的模块化，这个的确阿里巴巴出品的非常优秀的框架呢，只不过 fit 背后的思想指导者，正是此前在阿里巴巴中的软件大拿，Sofa 最初设计的时候也是请教了我们框架的设计者的。fit 的前身已经摸索过了相关模块化的路线，最终重新出发，走了插件化的道路，插件化和模块化还是有一些区别的。打个比较简单的比方，模块化，各个模块需要组合在一起，在编译打包一次，有点像不少预制半成品，还是需要有一次简单的烧的过程的，但是插件化，各个插件已经完全烧好了，打包就像一起装盘的过程。
感谢看了一眼我们的项目~
最底层的框架的确是为了传统软件工程的，fit 框架的第一行代码是 19 年底诞生的，此时 AI 并没有火。
你提到了成熟的 SofaBoot 的模块化，这个的确阿里巴巴出品的非常优秀的框架呢，只不过 fit 背后的思想指导者，正是此前在阿里巴巴中的软件大拿，Sofa 最初设计的时候也是请教了我们框架的设计者的。fit 的前身已经摸索过了相关模块化的路线，最终重新出发，走了插件化的道路，插件化和模块化还是有一些区别的。打个比较简单的比方，模块化，各个模块需要组合在一起，在编译打包一次，有点像不少预制半成品，还是需要有一次简单的烧的过程的，但是插件化，各个插件已经完全烧好了，打包就像一起装盘的过程。
感谢看了一眼我们的项目~
4 天前 回复了 Ketteiron 创建的主题 › 程序员 › 2025 年，我对"单体 vs 微服务"的预测 |
看到上面大家对微服务和单体讨论了很多，有非常多优秀的见解。如果把微服务和单体服务看做两个极端，那么微服务的出现就是为了解决之前单体服务的一些问题的，只不过，微服务架构本身也有自身的问题，因此，我们团队此前也有思考过是否有一种模式，可以让微服务和单体服务兼而有之，于是，我们开源了一款基础框架，fit 。
fit ，其思想正如其名字一样，我们希望每一个插件，作为单体服务的时候可以运行，组合（ fit ）起来之后依旧可以运行。假如有 N 个插件，那么每一个插件都可以像微服务一样作为一个一个单独的进程启动，对外提供服务，也可以把这 N 个插件，聚合在一起，形成一个单独的进程，启动，就像一个单体服务一样。这个过程中，插件的代码不需要做任何改变。当然，N 个插件可以自由组合形成 M 个进程。
当他们作为微服务互相调用的时候，他们之间的通信是 RPC 调用，存在网络消耗，但是一旦转换成微服务之后，调用可以自动识别变成进程内的内存调用，没有网络开销。这个特性在我们框架中称之为聚散部署。
也就是说，通过我们的框架写出来的代码，不需要经过重构，就可以在微服务和单体之间切换，完全由开发人员在部署阶段自由选择。
我们的框架是今年初开源的，希望大家能够支持一下，如果觉得我们的框架的这个设计思路有帮助，最好帮我们点的 star ，链接： https://github.com/ModelEngine-Group/fit-framework
fit ，其思想正如其名字一样，我们希望每一个插件，作为单体服务的时候可以运行，组合（ fit ）起来之后依旧可以运行。假如有 N 个插件，那么每一个插件都可以像微服务一样作为一个一个单独的进程启动，对外提供服务，也可以把这 N 个插件，聚合在一起，形成一个单独的进程，启动，就像一个单体服务一样。这个过程中，插件的代码不需要做任何改变。当然，N 个插件可以自由组合形成 M 个进程。
当他们作为微服务互相调用的时候，他们之间的通信是 RPC 调用，存在网络消耗，但是一旦转换成微服务之后，调用可以自动识别变成进程内的内存调用，没有网络开销。这个特性在我们框架中称之为聚散部署。
也就是说，通过我们的框架写出来的代码，不需要经过重构，就可以在微服务和单体之间切换，完全由开发人员在部署阶段自由选择。
我们的框架是今年初开源的，希望大家能够支持一下，如果觉得我们的框架的这个设计思路有帮助，最好帮我们点的 star ，链接： https://github.com/ModelEngine-Group/fit-framework
4 天前 回复了 Ketteiron 创建的主题 › 程序员 › 2025 年，我对"单体 vs 微服务"的预测 |
@ebony0319 我们团队写了一个开源框架，fit ，就是做的这个，在我们框架中，可以按照微服务的方式写一个一个的插件，插件与插件之间没有任何耦合关系，通信全部是接口，每一个插件都可以单独部署，就像微服务一样，也可以聚合在一起部署，形成一个单独的进程，就是单体架构，关键的一点是，这个从微服务到单体，或者从单体到微服务的转换过程，每一个插件是不用修改任何代码的。这个在我们框架中，叫聚散部署，欢迎来我们的开源项目参观点星，链接： https://github.com/ModelEngine-Group/fit-framework
11 天前 回复了 moverinfo 创建的主题 › 程序员 › Open AI 的对接问题 |
我觉得 @lnbiuc @andyskaura 说的挺对的呀，@moverinfo 你描述调用 OpenAI 发生了 400 错误，那么根据 http 的约定，直观理解就是调用参数存在问题，那么就需要看一下调用参数是什么，你发起的 http 请求，参数可能有 query ，form ，header 等等，的确是需要看一下你的参数情况的呀，我觉得你只是说了对接 OpenAI 有问题，发生 400 错误，但是不提供调用情况，和可能的 400 错误的详细信息，却说信息很充分，这个逻辑不成立呀。
当然，你自己已经通过尝试发现是网络问题了，解决问题了就好。
当然，你自己已经通过尝试发现是网络问题了，解决问题了就好。
17 天前 回复了 moverinfo 创建的主题 › 程序员 › 发现大多数的 Java 项目， JSON 已经是一个十分常用的格式。写了一个十分精简的解析器。 |
@moverinfo #41 你好，我发现你的回复都没有点击平台的回复，这样的话，别人都是不知道你回复了的，是没有提示的。我是特意关注了下，找了下之前的留言，才发现你的回复的。首先感谢能够得到回复。
然后，我也很高兴你可过我的项目（因为没有回复，我不确定是不是理解有错），之所以我比较感兴趣，就是因为你的框架也有模块化的特点，但是，模块化 != 插件化。
模块化，我们当前用任意框架写的代码，比如 Spring ，我也可以创建若干个 Module （模块），然后通过一个核心模块的 pom 来组织各个其他模块，这样也是分模块的。因为我看不到你的项目的整体架构图，所以我对此只能先交流来慢慢了解。
插件化，我实现的插件化和模块化的最大区别是没有 pom 的依赖，我不确定你的框架是不是如此。插件与插件之间的交互都通过接口来实现，因此，插件的业务逻辑不随插件的部署状态而改变，意思是，在 FIT 框架下，插件 A 和插件 B 可以作为一个 Mono （单体）服务聚合启动，同进程，此时，他们的通信为本地方法通信，他们也可以分别作为两个微服务分别启动，两个进程，此时他们的通信为 RPC 通信，但是插件的代码是完全不感知的。这个就是 FIT 框架的最大特点，支持插件的聚散部署，在此基础上，我用插件写了一个热插拔的插件，使得整个体系也支持了插件的热插拔。
也就是说，FIT 框架的设计是和 Spring 有比较大的区别的，但是和你说的模块化比较接近，正因为这个原因，所以我才想和你再多交流一下。感谢
PS：我看到你的项目之后，先点了一个 Star 支持了一下了
然后，我也很高兴你可过我的项目（因为没有回复，我不确定是不是理解有错），之所以我比较感兴趣，就是因为你的框架也有模块化的特点，但是，模块化 != 插件化。
模块化，我们当前用任意框架写的代码，比如 Spring ，我也可以创建若干个 Module （模块），然后通过一个核心模块的 pom 来组织各个其他模块，这样也是分模块的。因为我看不到你的项目的整体架构图，所以我对此只能先交流来慢慢了解。
插件化，我实现的插件化和模块化的最大区别是没有 pom 的依赖，我不确定你的框架是不是如此。插件与插件之间的交互都通过接口来实现，因此，插件的业务逻辑不随插件的部署状态而改变，意思是，在 FIT 框架下，插件 A 和插件 B 可以作为一个 Mono （单体）服务聚合启动，同进程，此时，他们的通信为本地方法通信，他们也可以分别作为两个微服务分别启动，两个进程，此时他们的通信为 RPC 通信，但是插件的代码是完全不感知的。这个就是 FIT 框架的最大特点，支持插件的聚散部署，在此基础上，我用插件写了一个热插拔的插件，使得整个体系也支持了插件的热插拔。
也就是说，FIT 框架的设计是和 Spring 有比较大的区别的，但是和你说的模块化比较接近，正因为这个原因，所以我才想和你再多交流一下。感谢
PS：我看到你的项目之后，先点了一个 Star 支持了一下了
Select Language