CodeCaster 最近的时间轴更新
CodeCaster

CodeCaster

V2EX 第 736478 号会员,加入于 2025-02-24 11:22:43 +08:00
全职开源,跪谢各位V友,求一个Star,项目地址:https://github.com/ModelEngine-Group/fit-framework
CodeCaster 最近回复了
@kevinmatt 你说的场景,我理解其实在替换字符串的地方就是一个判断,就相当于是流程分叉了,这个场景在 FEL 中可以定义出来。

你说在你们的实践中,字符串的匹配几乎必不可少,我同意当前的看法,因为当前市面上 langgraph 出来之后告诉大家就是这么连的,然后 Eino 出来仿照 langgraph 也写了一个 go 的,langchain4j 仿照写了一个 java 的,大家都是按照这个思路在走,并没有另一个工具告诉大家可以不这么做。而 FEL ,的确是采用了另一种方法,或许这样实践一下,可能可以有不一样的写法。

当然,你提到了多 Agent 动态计划生成,靠纯响应式的确是有点困难,但是 FEL 我们不仅仅使用了响应式,我们还有一个特点就是结合了 BPM ,因为在传统响应式中是不存在条件判断关键字的,就正如上面例子中的“.condition()”关键字,这个关键字可以做到流程的分叉。

我感觉这样就可以实现你说的动态了。

其实,动态的情况正式我们下一步的规划内容。

非常感谢你的讨论提供的观点。
3 天前
回复了 CodeCaster 创建的主题 Claude Claude Pro 账户如何使用 Claude Code?
@TimePPT #3 我在看这个之前,各种重启,然后去掉了几个莫名其妙的 token ,自然就好了,我也不知道是哪一步起的作用,还是很感谢
3 天前
回复了 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"}
```
@Isuxiz #5 我觉得你可能言重了,这篇文章本意是选择了另一种编程范式进行实现,对比一下,并没有表达谁优谁劣,只是想说是不是不同场景用不同方式会更合适。所以我没有想引战,没有想分胜负。

另外,当前的确是针对两个框架在比较,的确 Eino 是通过字符串来连接 ID 的,这个是事实而已。

我觉得讨论没有问题,但是问题上升了可能需要适可而止了。求同存异。感谢支持~
@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 ,理论能力差不多,但开发体验天差地别。

还是非常感谢你的讨论~
@mightybruce 对于开发 AI Agent ,使用现有的各个 AI 基础框架都可以,比如 LangChain 、Eino 、SpringAI ,我们的框架也提供了一套 Java 的 AI 原语,条条大路通罗马,我们并不是说开发 AI Agent 只能用我们的,用其他优秀的框架也可以的~ 只不过,我们想提供一种新的思路,因为当前的框架构建 AI 流程的过程基本都是通过图的,我们结合了响应式的写法,从写法上不一样,只是这样而已,提供代码示例供大家参考,来讨论一下而已。
我觉得如果这样写简单,本身也是好的
6 天前
回复了 Ketteiron 创建的主题 程序员 2025 年,我对"单体 vs 微服务"的预测
@Aresxue #93 我们的代码仓库准备拆分啦,因为现在 AI 太火了,所以介绍中是提到 AI 的,AI 相关的是另外一个模块,基于 fit 框架长出来的,最近正准备写一篇文章呢。拆库就是为了把底层框架和 AI 相关的模块分离开。

最底层的框架的确是为了传统软件工程的,fit 框架的第一行代码是 19 年底诞生的,此时 AI 并没有火。

你提到了成熟的 SofaBoot 的模块化,这个的确阿里巴巴出品的非常优秀的框架呢,只不过 fit 背后的思想指导者,正是此前在阿里巴巴中的软件大拿,Sofa 最初设计的时候也是请教了我们框架的设计者的。fit 的前身已经摸索过了相关模块化的路线,最终重新出发,走了插件化的道路,插件化和模块化还是有一些区别的。打个比较简单的比方,模块化,各个模块需要组合在一起,在编译打包一次,有点像不少预制半成品,还是需要有一次简单的烧的过程的,但是插件化,各个插件已经完全烧好了,打包就像一起装盘的过程。

感谢看了一眼我们的项目~
7 天前
回复了 Ketteiron 创建的主题 程序员 2025 年,我对"单体 vs 微服务"的预测
看到上面大家对微服务和单体讨论了很多,有非常多优秀的见解。如果把微服务和单体服务看做两个极端,那么微服务的出现就是为了解决之前单体服务的一些问题的,只不过,微服务架构本身也有自身的问题,因此,我们团队此前也有思考过是否有一种模式,可以让微服务和单体服务兼而有之,于是,我们开源了一款基础框架,fit 。

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

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

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

我们的框架是今年初开源的,希望大家能够支持一下,如果觉得我们的框架的这个设计思路有帮助,最好帮我们点的 star ,链接: https://github.com/ModelEngine-Group/fit-framework
7 天前
回复了 Ketteiron 创建的主题 程序员 2025 年,我对"单体 vs 微服务"的预测
@ebony0319 我们团队写了一个开源框架,fit ,就是做的这个,在我们框架中,可以按照微服务的方式写一个一个的插件,插件与插件之间没有任何耦合关系,通信全部是接口,每一个插件都可以单独部署,就像微服务一样,也可以聚合在一起部署,形成一个单独的进程,就是单体架构,关键的一点是,这个从微服务到单体,或者从单体到微服务的转换过程,每一个插件是不用修改任何代码的。这个在我们框架中,叫聚散部署,欢迎来我们的开源项目参观点星,链接: https://github.com/ModelEngine-Group/fit-framework
13 天前
回复了 moverinfo 创建的主题 程序员 Open AI 的对接问题
我觉得 @lnbiuc @andyskaura 说的挺对的呀,@moverinfo 你描述调用 OpenAI 发生了 400 错误,那么根据 http 的约定,直观理解就是调用参数存在问题,那么就需要看一下调用参数是什么,你发起的 http 请求,参数可能有 query ,form ,header 等等,的确是需要看一下你的参数情况的呀,我觉得你只是说了对接 OpenAI 有问题,发生 400 错误,但是不提供调用情况,和可能的 400 错误的详细信息,却说信息很充分,这个逻辑不成立呀。

当然,你自己已经通过尝试发现是网络问题了,解决问题了就好。
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   870 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 17ms · UTC 18:21 · PVG 02:21 · LAX 11:21 · JFK 14:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.