给 Coding Agent 选模型的方法
给 Codex、Claude Code 这类 coding agent 选模型，不应该只问“哪个模型最强”。更实用的问题是：
这个任务失败的代价有多高？需要读多少上下文？是否要改代码？能不能快速验证？我愿意等多久、花多少钱？
同一个 agent，在不同任务上可以用不同模型。查一个函数、生成一段脚本、重构权限系统、排查生产故障，不应该用同一套配置。
先按任务风险分层
我会先把任务分成四类。
低风险：问答、解释、定位
例子：
- 解释一个函数做什么。
- 找某个配置在哪里。
- 总结最近一次 diff。
- 给测试失败原因做初步判断。
这类任务通常不直接改文件，失败成本低。模型不一定要最强，关键是便宜、快、上下文够用。
建议：
- 用中等模型或便宜模型。
- 限制输出长度。
- 要求它引用文件路径和行号。
- 不给写权限，先让它只读。
中风险：小范围修改
例子：
- 修一个表单校验。
- 补一个单元测试。
- 改一个 API 参数名。
- 调整一段样式或文案。
这类任务需要 agent 写文件，但影响范围明确。模型要有稳定的代码理解和工具调用能力，不一定要最高推理档。
建议：
- 用稳定的主力 coding 模型。
- 明确写入范围。
- 要求跑相关测试或构建。
- 让 agent 汇报改了哪些文件。
高风险：跨模块重构
例子：
- 改认证和权限边界。
- 拆服务层和数据访问层。
- 重构缓存失效策略。
- 调整数据库迁移和 API 契约。
这类任务不是“代码生成”，而是工程判断。模型需要更强的推理、长上下文、稳定工具调用和较好的错误恢复能力。
建议：
- 用更强模型。
- 先让 agent 读代码、给计划，再动手。
- 分阶段提交或分 PR。
- 每个阶段都跑验证。
- 对关键逻辑做人工 review。
极高风险：生产、账务、安全、数据迁移
例子：
- 生产数据库修复。
- 支付、余额、钱包、权限。
- 删除数据、迁移数据。
- 修改安全策略或密钥处理。
这类任务不要只靠“模型更强”。强模型也可能误读边界。你需要审批、备份、回滚、最小变更和可观测性。
建议：
- 让 agent 先做只读调查。
- 禁止直接执行破坏性命令。
- 要求列出风险和回滚方式。
- 关键命令逐条确认。
- 用真实日志、trace id、备份和验证结果说话。
再看上下文：不是越长越好
coding agent 的上下文需求比普通聊天复杂。它可能需要：
- 当前文件。
- 相邻模块。
- 调用链。
- 测试文件。
- 配置文件。
- 错误日志。
- 最近 diff。
- 用户最新指令。
长上下文有价值，但不是越长越好。上下文越大，成本越高，延迟越高，模型也更容易被无关文件干扰。
更好的做法是按任务收缩上下文：
- 查 bug：读错误栈、入口函数、相关测试。
- 改 UI：读组件、样式、数据来源、路由。
- 改 API：读 controller、service、mapper、schema、测试。
- 改缓存：读写入点、读取点、失效点、并发路径。
如果 agent 一上来把整个仓库塞进上下文，成本会高，结论未必更准。好的 agent 工作流应该先搜索，再有选择地读文件。
延迟：交互任务和后台任务不一样
模型延迟会改变工作方式。
如果你在交互式调试，希望 agent 每 10 到 30 秒给一次反馈，太慢的模型会打断节奏。解释、定位、小补丁可以用延迟低的模型。
如果是复杂迁移、跨模块重构、PR review，等待更久是可以接受的。此时你更在乎分析质量、工具调用稳定性和减少返工。
可以这样拆：
| 场景 | 延迟优先级 | 适合模型 |
|---|---|---|
| 快速问答 | 高 | 快速、便宜、上下文够用 |
| 小补丁 | 中 | 稳定 coding 模型 |
| 大重构 | 低 | 强推理、长上下文 |
| 批量生成 | 中 | 便宜、可重试、输出稳定 |
| 生产排障 | 视情况 | 强推理，但必须受控执行 |
不要为了“最强”让所有任务都慢下来。也不要为了省几秒，把高风险任务交给明显不够稳的模型。
成本：看总任务成本，不只看单价
模型单价只是成本的一部分。coding agent 的真实成本还包括：
- 读了多少文件。
- 重试了多少次。
- 输出了多少无用解释。
- 是否因为误改导致返工。
- 是否触发限流。
- 是否需要人工花更多时间 review。
一个便宜模型如果反复失败，可能比贵模型更贵。一个强模型如果被用于简单搜索，也是在浪费。
实用策略：
- 低风险只读任务用便宜模型。
- 写代码用稳定模型。
- 关键设计和复杂重构用强模型。
- 批量任务限制输出长度。
- 长任务拆小，不要让一次请求承担所有上下文。
如果你经常遇到 429 或额度问题，可以参考 /zh/posts/debug-ai-api-401-429-500，先判断是余额、RPM、TPM 还是并发。
工具调用能力比聊天能力更重要
coding agent 不只是聊天模型。它需要稳定地：
- 搜索文件。
- 读取文件。
- 修改文件。
- 运行测试。
- 理解命令输出。
- 保持任务边界。
- 不覆盖用户未要求改的文件。
有些模型聊天很强，但工具调用不稳定；有些模型总结能力不错，但遇到大型 diff 容易漏细节。选 coding agent 模型时，要用真实任务测试，而不是只看问答榜单。
一个简单评估集：
- 让它解释一个真实函数调用链。
- 让它修一个小测试失败。
- 让它只改指定文件。
- 让它在脏工作区里不回退别人的改动。
- 让它跑测试并根据失败继续修。
这比问它“写一个 todo app”更接近真实使用。
不同任务可以用不同 profile
如果工具支持 profile，可以准备几套：
fast-read: 便宜、快、只读为主
code-edit: 稳定、适合小到中等修改
deep-refactor: 强推理、长上下文、用于复杂任务
batch: 便宜、输出短、适合批量处理
然后按任务切换，而不是把所有事情都交给一个默认模型。
配置 profile 前，先确认 key、base_url、model 和 endpoint 都对齐。相关检查可以看 /zh/posts/ai-tool-config-checklist。
一个可执行的选择流程
你可以按这个顺序问自己：
- 这个任务是否会改文件？不改文件，优先便宜快速模型。
- 改动是否跨模块？跨模块，提升模型能力并先要计划。
- 错误代价是否高？高风险任务先只读调查。
- 是否需要长上下文？需要时优先会搜索和筛选上下文的 agent，而不是盲塞全仓库。
- 是否能自动验证？能验证的小任务可以用中等模型快速迭代。
- 是否对延迟敏感？交互任务用低延迟，后台任务用强模型。
- 是否经常触发限流？拆任务、限并发、限制输出。
最后的原则很简单：模型选择要服务于任务风险，而不是服务于模型排名。
最贵或最新的模型不一定是每次 coding agent 的最佳选择。真正稳的配置，是把低风险任务跑快，把高风险任务跑准，把不可逆操作放进人工确认和验证流程里。