不知道大家平时在用大模型写代码的时候有没有一种糟心感受。不管问题简单还是烧脑模型的思考深度基本是固定死的。简单的文件查找、列出目录这种 routine 的常规任务它照样吭哧吭哧疯狂输出一大段内部思考白白烧掉一堆token等到真正遇到复杂难题卡壳的时候思考又好像不够深入三下五除二就草率给出错误答案。要么无脑使劲想花钱要么少思考容易错。很长一段时间我们好像只能二选一。最近社区流传的 Jev 思路就有意思了任务运行的中途动态调整 GPT‑6Codex的 reasoning effort思考投入程度。逻辑说起来并不复杂。Agent 在跑任务的时候自己做判断现在是不是卡住了如果陷入难题就立刻调高思考力度让模型多想一想如果只是普通、重复性的例行步骤就降低思考开销不要无谓地胡思乱想。下面直接来看看怎么使用首先使用/model选择模型选择jev先打个招呼再让他找bugjev会根据实际情况来选择codex的不同努力级别而不是一味的使用某一个级别最亮眼的数据是什么我用自己的项目实测直接把整体调用成本直接下降50%。而且更厉害的一点这套玩法并没有破坏 prompt caching提示缓存。很多做过Agent开发的朋友应该懂这里的含金量。但凡你中途随便改系统提示、乱改头部的参数前面已经缓存好的上下文直接失效。缓存一没每一轮都重新跑完整输入token开销瞬间暴涨省下来那点思考token全部亏回去。很多动态改思考参数的早期尝试就是栽在这里。Jev 的方案绕开了这个大坑可以继续享用缓存带来的提速省钱红利。放到Agent写代码这个场景来看就非常贴切。Agent执行的时候大量工作其实就是执行shell命令、查文件、grep检索源码这些步骤根本不需要深度推理只有遇到分析报错、梳理复杂逻辑、重构代码的时候才真正需要模型沉下心深度思考。以前是“一刀切”全程维持最高档位的思考。现在变成了弹性策略该猛想的时候使劲想该摸鱼的时候就少想。按需分配算力。当然也要冷静看待Jev目前还属于社区传出的玩法并不是OpenAI官方开放的API能力。它更偏向一套上层调度思路并不是什么黑魔法补丁。并不是打开开关就直接半价需要上层Agent逻辑识别当前任务状态再动态下发推理强度指令。以后Agent开发单纯堆模型能力不一定是出路。这种上层动态调度、弹性控制思考资源的思路说不定会成为优化Agent成本的主流方向。不知道后续会不会有更多项目跟进这套模式