AI Coding 的蜜月期快结束了。真正的问题不再是“会不会用”，而是“用不用得起、用不用得稳、能不能规模化”。

当 token 成本开始进入采购视野，Coding Agent 选型就不再只是工具体验问题，而是工程效率和成本结构问题。

过去我们讨论 AI Coding，常问的是：它能不能写代码？

现在更现实的问题变成了：它能不能稳定交付？能不能控制成本？能不能在团队里规模化使用？

过去一年，AI coding 已经从“辅助编程”走到“工程系统”。越来越多团队开始让 agent 读完整仓库、理解需求、调用工具、跑测试、修 bug、做 code review，甚至在后台并行处理多个任务。问题也因此变了：不是它会不会写，而是它能不能稳定地产出可合入的结果。

深水区的第一个特征，是程序员开始离不开好模型。这句话听起来有点夸张，但很多重度用户应该都有类似体验：一旦习惯了强模型在复杂代码、跨文件推理、错误恢复上的表现，就很难退回到弱模型。这个比喻有点刺耳，但很贴切：token 像一种带成瘾性的燃料，好的模型像“高纯度燃料”，推理更稳、上下文更长、工具调用更聪明，用起来很爽，但账单也更快失控。

深水区的第二个特征，是好模型越来越贵。agentic coding 和普通 chat 不一样，它会反复读文件、搜索、调用工具、运行测试、根据错误重试。真正贵的从来不只是单次问答，而是整条任务链路上的反复读取、推理和验证。

这也是为什么企业开始重新审视 AI coding 的经济账。外部报道已经多次提到 GitHub Copilot、Claude Code、Cursor 等工具在 usage-based billing、premium requests、AI credits 上的调整；即使是微软、Uber 这样的公司，也会遇到“大家越爱用，账单越难控”的问题。AI coding 没有失败，恰恰相反，它正因为太有用，才把 token 成本从技术问题推到了采购和工程管理问题。

因此，coding agent 选型不再是“哪个工具体验好”这么简单。真正的问题变成了：好模型应该用在哪些任务上？便宜模型能不能承担低风险工作？agent 的工具链、上下文管理和验证闭环，能不能让同样的 token 产生更多有效 patch？

如果只记住三句话：

模型能力很重要，但 agent 的 harness、工具定义、上下文管理和验证闭环，同样会决定最终效果。

评测不能只看 pass rate，要同时看工具轨迹、人工接管率、review 时间和单位有效 patch 成本。

最佳选型通常不是单一工具，而是多条 lane：低成本 lane 覆盖简单任务，高可靠 lane 处理关键任务，后台 lane 承接长任务。

一、榜单为什么会误导选型

许多 AI Coding Agent 横评会把几个工具放在一起，比较体验、价格、SWE-bench 成绩或少量 demo 任务。这类信息有价值，但如果直接拿来做团队选型，很容易失真。原因不是 benchmark 没意义，而是 coding agent 本身已经不是一个单变量系统。

Coding agent 不是“模型 + 编辑器皮肤”。它至少由模型、harness、工具、运行时、权限、记忆、外部连接器和评分器组成。公开榜单把这些变量压成一个分数，方便传播，但牺牲了归因能力。一个 agent 高分，可能是模型强，也可能是 harness 强、工具定义好、预算更宽、评分器更容易被利用。

因此，更关键的问题不是“哪个 agent 最强”，而是：

如何判断某个 agent × model × runtime 组合，在真实工程任务上是否值得投入。

这里至少有三条公开证据值得记住：

LangChain 固定gpt-5.2-codex，通过 harness engineering 将 deepagents-cli 在 Terminal Bench 2.0 从 52.8 提到 66.5。分数不是模型裸能力，必须比较组合。

UTBoost 指出 SWE-bench 弱测试可能把错误 patch 误判为通过。pass rate 必须配合人工 review、失败分类和影响面分析。

Berkeley RDI 展示过修改测试、下载 gold file 等刷榜方式。评测环境必须隔离，评分脚本不能暴露给被测 agent。

所以，榜单可以拿来做初筛，但不能直接拿来做采购决策，更不能替代你自己的任务集。

二、四象限评测框架：结果、轨迹、能力栈、成本

要让评测真正指导选型，至少要拆成四个象限。只看任务成功率，会选出“会做但很贵、很慢、很难 review”的 agent；只看成本，会选出“便宜但关键任务不可靠”的 agent。

第一象限是任务结果。

这里看的是：它做成了吗。核心指标包括任务成功率、测试通过率、PR 接受率、人工接管率。它决定能力底线，但不是全部。

第二象限是轨迹质量。

这里看的是：它是不是聪明地做成。核心指标包括工具选择精度、必要步骤召回、失败恢复、无关 diff、重复调用。它决定这个 agent 能不能规模化使用。

第三象限是能力栈。

这里看的是：它能不能进入真实工作流。核心指标包括 Computer Use、Browser Use、MCP、Subagents、Memory、Background Tasks。它决定 agent 是否能拿到真实上下文并执行真实动作。

第四象限是成本效率。

这里看的是：它值不值得长期投入。核心指标包括 token 成本、wall time、review 时间，以及最关键的Cost per Accepted Patch。

这里最该记住的公式是：

Cost per Accepted Patch = 总 agent 成本 / 被人工 review 接受并合入的 patch 数

它比 pass rate 更接近工程价值，因为它同时惩罚失败、低质量 diff、高成本和高 review 负担。

换句话说，一个 agent 真正贵不贵，不是看单次调用多少钱，而是看它产出一个可合入 patch 的总成本。

三、怎么真正测起来：别只看榜单，要看真实任务

一套 agent eval 不需要一开始就很大。更好的起点，是 30 到 50 个真实任务、5 到 8 个任务桶、每条任务 2 到 3 次 trial。很多团队一上来就想做“大而全”的 benchmark，最后反而看不出问题。更实际的做法，是先拿真实任务跑起来。

任务集至少要覆盖几类工作：

小 bugfix：看定位和测试闭环。

复杂 bugfix：看上下文搜索、根因假设和失败恢复。

小功能：看需求理解和实现完整性。

重构：看影响面分析和 diff 克制。

前端验证或内网排障：看 browser、MCP、权限和证据整合能力。

同时，别只记录“成没成”，还要记录过程。至少要能回看：

它读了哪些文件、改了哪些文件

调了哪些工具、失败后有没有恢复

跑了什么验证、花了多少时间和 token

最后有没有被人工接受，review 成本高不高

如果这些都没有，你最后只能看到一个分数，却不知道分数是怎么来的。

更重要的是，汇报时别只放 pass rate。至少要把成功率、人工接管率、平均 review 时间、平均成本、Cost per Accepted Patch放在一起看。这样你才能分清：这个 agent 到底是真省钱，还是只是把成本从 API 账单转嫁到了人身上。

四、Computer Use、MCP、Subagents 这些能力怎么评估

2026 年的 coding agent 早已不只是“改代码”。Computer Use、Browser Use、MCP、Subagents、Memory、Background Tasks、Code Review Agent，都会改变真实生产力。它们不应该被当成“高级功能展示”，而应该被当成能力栈单独评估。

先说一个结论：

Computer Use 是最后手段，不是默认手段。

企业内网任务通常优先 MCP，因为 MCP 可审计、可限权、可复现；Computer Use 更适合必须看屏幕和点击真实 UI 的任务。

评估这类能力时，至少要问四个问题：

它是不是稳定，而不是偶尔能跑通 demo。

它的权限边界是否清晰，能不能审计。

它失败后能不能恢复，而不是直接卡死。

它带来的速度提升，是否真的大于成本膨胀。

拿 subagents 举例，至少要同时看两个公式：

Parallel Speedup = single_agent_time / multi_agent_time Cost Inflation = multi_agent_cost / single_agent_cost

只有当 speedup 明显高于 cost inflation，subagents 才值得用。比如 2.5 倍速度提升、1.4 倍成本增加是好交易；1.2 倍速度提升、3 倍成本增加，本质上只是把账单做大。

五、选型怎么做：先选模型，再选 Agent 承载层

更合理的技术选型，不是从“我喜欢哪个 IDE”开始，而是先选模型底座，再看哪些 agent 能把模型能力释放出来。模型决定推理、代码理解、长上下文和 token 成本；agent 决定工具调用、上下文压缩、文件编辑、权限边界和验证闭环。

这也是为什么同一个模型换 agent 后效果会差很多。DeepSeek、MiniMax-M3、GLM-5 这类模型本身不等于 coding agent。只有当 agent 正确保留工具调用历史、合理组织 repo context、能跑测试、能回收失败信号时，模型能力才会真正变成工程产出。

更实用的做法，是先按 lane 来理解模型，而不是按“谁贵谁便宜”粗暴分类。

低成本 lane：DeepSeek V4 Flash、部分 Qwen/GLM 低价模型，适合解释代码、生成测试、简单脚本、小 patch。

高可靠 lane：Claude、GPT-Codex、部分高档国产模型，适合关键 bugfix、复杂重构、review 成本高的任务。

长上下文 lane：MiniMax-M3 等，适合大 repo 阅读、长文档理解、多轮工具调用。

然后再看 agent 能不能把这些能力稳定承载出来。第二步不是问“这个 agent 火不火”，而是问：

它的工具调用稳不稳。

它的上下文组织是不是合理。

它能不能自己跑验证，并基于失败信号修回来。

它的权限边界、并行能力和成本路由是否可控。

从这个角度看，Codex、Claude Code、Cursor、Qoder、Qwen Code、CodeBuddy 这些工具的差别，不只是模型档位不同，而是它们承载模型能力的方式不同。有的更强在终端长任务，有的更强在 IDE 高频协作，有的更强在后台并行，有的更适合企业内统一推广。

所以更现实的配置，通常也不是“全员只用一个工具”，而是双轨或三轨：

主编辑流：承载日常编辑、补全、多文件修改。

高可靠流：处理关键 bugfix、复杂重构、架构决策。

低成本或后台流：覆盖解释、测试、小 patch 和异步长任务。

这套方案的核心原则是：用便宜模型买覆盖率，用强模型买可靠性，用长上下文模型买大 repo 理解，用云端 agent 买并行度，用 IDE agent 买低摩擦。

结论

评测 AI coding agent 的核心，不是找一个通用冠军，而是建立一套能服务自身任务分布的选型系统。公开 benchmark 可以做初筛，但不能替代真实 trace、任务桶、人工 review 和成本核算。

真正值得投入的 agent 组合，不一定是榜单第一，而是能在你的 repo、你的工具链、你的权限边界、你的预算和你的团队 review 习惯下，稳定降低Cost per Accepted Patch的组合。

如果你正在团队里推动 AI coding 选型，不妨先别急着问“谁最强”，先把这三件事补齐：

建一套真实任务集

留下可复盘的 trace

用单位有效 patch 成本做最终判断

当你开始这样评测时，很多“神话级榜单”会自动褪色，真正适合自己团队的组合反而会更清楚。