1920_Codex简单试用

关于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的推理加工。