让 Coding Agent 更靠谱：Model 和 Effort 怎么选

我们用 Claude Code、Codex 这类 Coding Agent 时会遇到两个设置Model 和 Effort。它俩都能让我们的交付成品变好Model 往上调采用更聪明、智能的模型Effort 往上调让模型更充分地思考。虽然在结果上Model 和 Effort 殊途同归但它俩管的事情并不相同。如果说 Model 是在问“这次任务交给谁来做”那么 Effort 就在解决“这个 Agent 愿意为这件事花多少工夫”考虑到成本开销我们不能简单粗暴地把模型切换成最强模型再把 Effort 拉满。毕竟这样不划算。对账单友好的方式是先判断交付结果不佳是能力不行还是任务拆解不够细。模型选择的原理我们先从你在 Claude Code 里按下回车开始。Claude Code 会把你的消息、system prompt、工具定义、CLAUDE.md、对话历史以及已经放进上下文的文件一起打包成一次 API 请求。这些请求信息到了服务端文本会先经过 Tokenizer被切分成 token并映射成一串 token ID。const会被映射成一个数字await也会被映射成另一个数字。从这一步开始你的 prompt 就变成了一串整数。接下来模型就能基于当前这串 token预测下一个 token 最可能是什么。一个充分训练的模型会把下一个可能 token 是fetch的概率排得比较高而把banana这种无关 token 的概率排得接近 0。而把输入 token 变成这些概率的背后机制是模型权重。模型权重是模型训练后固定下来的经验。它们是组织在矩阵里的大量数字。模型每预测一个 token都要把输入经过这些权重最后得到下一个 token 的概率分布。值得一提的是一旦训练结束模型权重就是固定的。你的 prompt、CLAUDE.md、上下文文件都会影响这一次模型怎么回答但不会改变模型权重。因此你把真实代码放进上下文能很好地引导本次任务完成。但只是在当前请求里引导它模型本身并没有在本次任务中写入新知识。如果开发用到的某个库在模型训练时还不存在你可以把文档放进上下文Claude 就能根据文档使用该库。但这种方式更像一次性的知识补充模型并没有真正学会这个库也不会把这些信息写入自己的参数。所以当 Claude 自信地调用一个不存在的 API 时通常是模型根据已有训练模式生成了一段看起来合理的结果。此时继续补充上下文可以帮助 Claude 理解当前任务但并不会改变模型本身的能力。如果希望改变模型处理问题的能力范围就需要切换 Model。本质上切换 Model 就是在换一组不同的模型权重重新处理同一个请求。模型生成 token 的方式模型并不会一次性生成完整答案。它会先预测一个 token把这个 token 接到序列后面再继续预测下一个 token。一个 200 token 的回复这个过程要重复 200 次。这也是输出成本和等待时间的重要来源之一。模型设置决定了哪一组权重处理请求也决定了每个输出 token 的成本。但模型本身不会去决定最终生成多少 token。同一个 prompt 下模型生成多少 token取决于它决定为这次任务做多少工作。也就是接下来要说的 Effort。Effort 的作用Coding Agent 在处理任务时生成出来的 token 大致可以分成这三类第一类是 thinking就是你看到的中间思考第二类是 tool call比如调用 Read、Edit 这类工具以及对应的参数第三类是 text to you比如计划、进度更新、最后总结。这些本质上都是同一个生成循环产生的 token。thinking 是 token工具调用也是 token最后写给你的文字也是 token。它们的区别在于 token 内容不同Claude Code 会把工具调用解析出来并执行。Effort 决定了 Claude 在这个过程中投入多少工作。Effort 会和你的 prompt 一起作为请求的一部分发送给模型。模型在训练中已经学会了不同 effort level 下应该如何行动这种行为模式也存在固定权重里。当请求来到时Effort 就像 prompt 里的其他信息一样会影响 Claude 的行为。Effort 越高Claude 对“任务完成”的要求就会越高。它会更倾向于多做检查、多读文件、多验证结果也更可能在多步骤任务里推进得更远。Claude 团队给了一个示意案例同样是修一个失败测试低 Effort 可能只读测试文件、做修改再给出一个简单结果高 Effort 可能会读测试文件、读源码、读配置、思考、修改源码、跑测试再重新读取文件确认。图注低 effort 大约 400 tokens高 effort 大约 2,800 tokens。不过高 Effort 并不代表 Claude 会故意把简单任务做复杂。如果一个三假设调试计划里第一个检查已经找到 bug后两个检查可能就没有必要继续。Claude 通常会更新任务列表并说明为什么跳过剩余检查。所以 Effort 更像是一个“工作投入倾向”它会让 Claude 更愿意多检查、多验证但不会把每个简单任务都强行拖长。如何选择 Effort对大多数任务先使用模型默认的 Effort 即可。默认值兼顾了任务完成度、token 消耗和响应速度。只有当工作流对速度或验证程度有明确要求时再主动调整 Effort。Anthropic 也建议把 Effort 看作一种长期使用偏好无需为每个小任务反复切换。你可以把 Effort 当成一个手动覆盖项。当你对速度或彻底程度有明确偏好时再去调整它。如果当前工作流非常看重验证那你可以用更高 Effort。如果你只是想要快速响应那可以偏向低 Effort。模型出错该调整什么当 Claude Code 出错时第一反应应该检查你给它的上下文而不是调设置。可以根据下面顺序进行检查你的 prompt 是否太模糊Claude 是否连上了正确的工具它是否具备正确的 SkillsCLAUDE.md、上下文、任务范围是不是有问题如果一个任务本来不用提高 Effort却要靠更高 Effort 才能完成那问题往往在上游上下文、CLAUDE.md或者任务范围本身。当你确认上下文已经足够清楚Claude 还是做错了再问一个关键问题它是没有足够努力还是没有足够能力怎么选换 Model 还是 Effort如果问题本身确实很难就应该考虑更大的模型。这里的典型情况包括隐蔽 bug、不熟悉领域、架构决策。如果 Claude 已经拿到了相关上下文也明显尝试过最后仍然自信地做错这就是换更大模型的信号。更大的模型往往更擅长处理模糊问题。相对来说小模型更适合明确指令和清晰执行路径。日常任务就没有必要总用大模型。对于要求明确的小改动、重复性较强的机械修改以及基于现有代码的简单问答较小模型通常已经够用。任务不需要那部分能力时我们没必要为它付费。如果 Claude 做错是因为它没有读某个文件、没有跑测试、没有 double-check那就更像是 Effort 问题。这时候你可以提高 Effort。尤其是你本来就选了低于默认值的 Effort结果它跳过了关键检查那么提高 Effort 会更合理。在 Claude 中Model 和 Effort 的组合可以参考以下内容Fable 像一位专家型人才适合处理那些其他人都解决不了的问题Opus 像一位资深专家拥有更丰富的经验Sonnet 像一位能力很强的通才适合大量日常开发任务Effort 决定的是他们愿意在你的任务上投入多少时间低 Effort 的 Opus就像只给一位资深专家 5 分钟。他经验丰富能够迅速发现一些关键问题但不会仔细读完所有文件。高 Effort 的 Sonnet就像给一位能力很强的通才一整个下午。他会文件、运行程序、反复检查最终更充分地理解你的代码。Fable 更适合留给那些真正需要专家型能力的任务。它的成本最高也更应该用在确实需要它的地方。这里没有一个设置永远更好。Model 大致决定能力Effort 大致决定彻底程度。真实任务通常需要两者配合。Token 成本变化Model、Effort 和 token 消耗之间的关系要看任务难度。在简单任务上大模型和小模型通常都能很快达到质量线。继续花更多 token买到的主要是额外检查而不是显著质量提升。这就是为什么简单任务可以用较小模型。质量不一定受影响速度和成本通常会更友好。一般来说较小模型需要更多轮尝试才能逐渐逼近较大模型用小步骤达到的质量。虽然大模型单个 token 的价格更高但面对真正逼近小模型能力上限的复杂任务它往往能用更少的步骤完成因此整体成本未必更高。更关键的是有些任务即使把小模型的 Effort 调到最高它依然无法完成而大模型可以。这一点在 Fable 上尤其明显。它在长程、多步骤任务里优势更大也最贵所以更适合留给真正需要的任务。这里最重要的理解是Model 选择的是哪条能力曲线Effort 选择的是 Claude 愿意沿着这条曲线走多远。但 Effort 并不是一个 token 上限。真正的硬限制是 max_tokens它有点像 API 开发里的硬截断。对日常使用来说让 Claude 控制预算、保持简短通常比硬截断更有用。小结Model 决定 Claude 的能力边界Effort 决定它愿意为任务投入多少工作。当结果出错时先检查 prompt、上下文、工具和任务范围。上下文充足、已经认真尝试却仍然判断错误就换更大的 Model漏读文件、没跑测试、缺少验证就提高 Effort。