github copilot的路线选择
copilot去年二月到七月在vscode insider中是可以无限使用的, 我在这期间见证了copilot的agent能力的逐步衰弱.很难想象, copilot的首月预览版竟然是效果最好的, 之后agent能力逐步下降. 具体是什么变化? 那就是copi…
copilot去年二月到七月在vscode insider中是可以无限使用的, 我在这期间见证了copilot的agent能力的逐步衰弱.很难想象, copilot的首月预览版竟然是效果最好的, 之后agent能力逐步下降. 具体是什么变化? 那就是copilot的开发演进方向, 在过去一年多里是"省token".早期大家的agent读文件就是一次性全读, qwen cli/claudecode/gemini/copilot早期都是这样, 效果非常好, 只是token消耗估计有点大, 上下文也会迅速填满, 如果重构上下文, 缓存命中率则会降低.后来大家都往片段读取方向走, 有的是grep后读上下几十行, 不够再读, 有的是使用LSP这样的代码结构化工具来读.copilot的agent使用文件从上往下读的方法, 每次读50行, 偶尔读个200行, 但一直从上往下读.配合默认50次的工具调用限制, 以及不到200k的输入上下文, 它能完成的工作比较有限. 早期各厂商的服务都是亏的, 预期以低价占领生态位, 后期想办法把成本降下来, 只是这一年多时间里终于发现成本降不下来, 强行降成本会导致自己的产品成为三流产品. 所以不用指责copilot太多, 各能上牌桌的agent都已是按token计费, copilot已是落后的一个.抛掉计次的历史负担后, 希望copilot好好改进自己的agent, 跟上大部队, 毕竟它还是和vscode集成最好的.做AI工具可以贵, 但不能太菜.
