关于AI的一些工具还有技术我自己个人接触的相对来说比较晚。这个在我上一次总结我用AI来写树莓派的一些小脚本的时候也大概说过。最近尝试补充一下自己这方面的短板因此看了一些材料也看了一些付费的教程。从这些信息里面发现又有一个趋势是使用Agent来完成一些工作或者是处理的诉求。在agent的选择上又有很多个不同的类别和门派很难说谁好谁坏尤其是在我现在连这个东西是水都没有试水过的情况之下我更加分辨不清。于是我找了一个有过这方面经验的人咨询了一下初步给了我一个建议就是使用codex。然而由于种种原因在咱们这片神奇的土地上有很多互联网相关的东西使用起来还是有一些困难的。我不想为了这些困难而去付出过多的时间因此如果是有这样的拦路虎的时候我通常就是此路不通直接放弃。然而让我去搜索别人这方面的使用经验的时候发现除了官方的这种方式之外其实我们还可以选择本地的大模型比如说DeepSeek这个也是我这一段时间用的比较多的一个大模型。而我自己又有硅基流动这方面的头ken可以用那么就可以做一个初步的尝试了。我看了看Codex如果是接入Deep seek ApI其实也有两个常用的方案第一个是使用一个叫做cc的插件还有一个就是使用codex。我选择了后者自己尝试了一下发现的的确确走通这条路子并不是特别困难。目前简单的验证了一下当前的技术方案是可以通的。我也没有做什么生物的探索尝试只是提供了一个交互式的语言看一下回答的效果。我问的这个问题很简单我就检查了一下第2天无锡的天气。就这么一个简单的问题也给了我一个小小的震撼。因为使用了同样的推理模型得出来的结果是完全不一样的使用了codex之后得到的结果排版精良可读性非常好非常人性化。相比之下网页版本的chat窗口得到的这个结果就没有那么详细。我不仅仅测试了DeepSeek而且测试了豆包和阿里的千问得到的结果是三个网页得到的信息都是差不多的。都没有codex得到的这种结果排班和内容丰富且美观。当然我看了一下后台ApI Token的消耗量Codex的消耗量的的确确是不小的。然而当我们具备本地部署的可能性之后或许这样的问题就不是什么大的问题了。从另外一个角度上来讲即使是我们不使用自己的本地部署API直接使用第三方的服务或者是官方的服务。来实现这样的推理那么使用Codex其实也是给了我们一个质量金钱之间性价比的另外一个选择。下面是我的两个查询之间的对比由于 Codex上面的推理模型我选择了DeepSeek。那么这个对比的截图我就只放DeepSeek豆包和阿里千问的就不放了。上面的这个结果是来自于DeepSeek官方网站的查询结果。上面的这个结果则是来自于codex的推理加工。
