大家都是如何选择Agent所使用的LLM的呢？是懒得选，比如直接用cursor的auto模式？还是会进行详细的前期调研？那又该如何调研呢？又或者说可以根据哪些指标量化LLM生成代码质量的好坏呢？
一、我要说的是，其实「没有 universally 意义上最好的模型」
不同 LLM 在推理深度、代码能力、上下文长度、多模态、工具调用、延迟、价格、合规与部署形态上取舍不同。任何选型的本质都是：在约束条件下最大化任务成功率与可维护成本。
那么我们就需要理一下我们的需求，再选模型：
| 维度 | 你要问自己的问题 |
|---|---|
| 任务类型 | 是闲聊、摘要、翻译，还是写代码、做 Agent、处理长文档？ |
| 上下文规模 | 单次输入是否超过几万～百万 token？是否需要整库索引？ |
| 延迟与吞吐 | 在线交互能否接受数秒级首 token？批处理可否异步？ |
| 成本 | 按 token 计费还是按年/月订阅？输出 token 往往比输入贵得多。 |
| 合规与数据 | 是否允许数据出境？是否必须私有化部署（开源权重 / 本地推理）？ |
| 生态 | 是否深度绑定某 IDE（如 Cursor、Copilot）、某云（Vertex、Azure OpenAI）？ |
二、市面上常用的模型家族（部分，排名不分先后）
1. Anthropic — Claude 系列
- 常见定位：长文理解与写作、复杂指令遵循、代码与重构场景口碑较好；不同档位（如 Haiku / Sonnet / Opus）通常对应「更快更省」到「更强更贵」
- 适用：代码助手、文档密集型任务、需要较强「说明理由与分步」的场景
2. OpenAI — GPT（Codex） 系列
- 常见定位：通用能力强，工具调用与生态（ChatGPT、API、部分第三方插件）成熟
- 适用：通用对话、企业集成。
3. Google — Gemini 系列
- 常见定位：多模态与长上下文（部分版本强调超大窗口）
- 适用：图文混合、长文档等
- 注意：Flash 类通常偏速度与成本，Pro / Ultra 偏能力
4. 其他
- 如 Grok、 Qwen（通义千问）、DeepSeek 等，国内大模型更适合内网部署、成本可控、可微调。
部分模型 API 参考价格（美元 / 百万 tokens，Standard 档为主）
以下为各厂商公开 API 文档中的标价，便于粗算成本；以下数字随官方调整而变化，仅供参考哈
Anthropic Claude（官方定价）
| 模型 | 输入 ($/MTok) | 输出 ($/MTok) | 备注 |
|---|---|---|---|
| Claude Sonnet 4.6 / 4.5 | 3 | 15 | 编程与 Agent 常用档；Batch API 约为输入 1.5 / 输出 7.5（约五折） |
| Claude Opus 4.6 / 4.5 | 5 | 25 | 更强推理； |
| Claude Haiku 4.5 | 1 | 5 | 高吞吐、低成本 |
OpenAI GPT（官方定价）
| 模型（示例） | 输入 ($/MTok) | 输出 ($/MTok) | 备注 |
|---|---|---|---|
| gpt-4o | 2.50 | 10.00 | 多模态通用；另有 Batch / Priority 等档位 |
| gpt-4.1 | 2.00 | 8.00 | — |
| gpt-5.4 | 2.50 | 15.00 | 旗舰迭代；同页含 mini / nano / pro 等多档 |
| gpt-5.2 | 1.75 | 14.00 | — |
| gpt-5-mini | 0.25 | 2.00 | 轻量 |
| gpt-4o-mini | 0.15 | 0.60 | 低成本场景 |
Google Gemini（Gemini API 定价）
| 模型（示例） | 输入 ($/MTok) | 输出 ($/MTok) | 备注 |
|---|---|---|---|
| Gemini 3.1 Pro Preview（短提示档：不超过约 200k tokens） | 2.00 | 12.00 | 更长提示时输入/输出单价更高（同页分段计价） |
| Gemini 3 Flash Preview | 0.50（文本/图/视频） | 3.00 | 平衡速度与能力 |
| Gemini 3.1 Flash-Lite Preview | 0.25 | 1.50 | 高量、低成本 |
产品与 API 的区别
- ChatGPT / Claude 网页版 / Gemini 应用：多为订阅（如按月），与上表 按 token 的 API 计价不同。
- Cursor、IDE 插件：通常打包在订阅中或按厂商协议，不一定等于上表单价，比如cursor pro 年包是$20 / mo.。
三、如何「系统化」选择：
- 定义成功标准：例如「单测通过率」「CR 可合并率」「P95 响应时间」「每月 API 预算上限」
- CR 可合并率：Claude Code、OpenAI Codex、GitHub Copilot 等都会用 合并率 衡量表现，例如：Claude Code PR 合并率约 59%，OpenAI Codex 约 82.6%
- 准备小样本基准集：10～50 个与你业务高度相关的真实任务（脱敏），覆盖典型与边界情况
- 多模型盲测或 A/B：同一提示词与同一评测脚本，对比正确性、可维护性、成本与延迟
- 分层路由：简单补全/格式化 → 小模型或本地模型；架构设计、疑难 Bug → 大模型或更强档位
- 持续回归：模型升级后重复跑基准集，避免「静默退化」
四、如何量化「生成代码」的质量
代码质量不能只凭主观感觉，建议结合自动化指标与人工评审，并区分「单次生成」与「进入仓库后的长期成本」。
1. 功能正确性（最硬核）
- 单元测试 / 集成测试通过率：在沙箱中运行测试套件；可报告
pass_rate、失败用例分类（逻辑错误、边界、并发等）。 - 黄金用例集（Golden tasks）：来自生产或近生产的小任务，验收标准明确（输入输出、性能、副作用）。
2. 可维护性与安全
- 静态分析与 Lint：如 ESLint、Ruff、mypy、Sonar 等；统计告警数量、严重级别、新增债务。
- 类型与接口契约：TypeScript/静态语言下，「无类型逃逸」「公共 API 变更」可量化。
- 安全扫描：依赖漏洞（SCA）、密钥泄露检测、危险 API 使用（
eval、拼接 SQL 等）。
3. 行业基准（横向对比模型能力，仅供参考）
公开基准可帮助理解模型相对强弱，但不应该作为在实际工作中表现的评判标准：
- HumanEval / MBPP：AI 代码能力的 “高考” 和 “基础会考”，函数级小任务补全（经典但偏窄）
- SWE-bench 等：衡量 LLM 能否成为 合格软件工程师 的终极试金石：它不只考 “会不会写代码”，更考 “能不能在真实项目里解决问题
使用方式：把基准当作粗筛，最终以你团队的真实任务集为准，
毕竟高考不等于工作能力一定强~
4. 人机协同指标
- Code Review 结果：一次 PR 中「需大改 / 小改 / 可直接合」的比例；评审耗时。
- 返工率：合并后短期内因缺陷回滚或 hotfix 的比例。
- 开发者主观评分：可维护性、可读性、与项目风格一致性。
5. 成本与效率
- 单位任务总成本：API 费用 + 人工审查时间折算。
- 迭代轮数：从提示到可合并 PR 的平均往返次数。
量化方式汇总表
| 类别 | 指标示例 | 说明 |
|---|---|---|
| 正确性 | 测试通过率、Golden task 通过率 | 权重高 |
| 质量 | Lint/静态分析、复杂度、重复代码 | 防技术债 |
| 安全 | SCA、密钥与注入类规则 | 生产必备 |
| 效率 | 首 token 延迟、总耗时、迭代轮数 | 影响体验与成本 |
| 人的反馈 | CR 修改密度、合入难度 | 真实体验也很重要 |
五、结语
选型 LLM 不是直接选大家觉得好的，需要拿自己实际的业务场景去测试，用起来好才是真的好。
还有就是AI在飞速发展，模型名称与能力每天都可能变化，固定内部基准集与流水线，每隔一段时间测评一次，及时调整才是合理的。
