agent-">Coding Agent评测：为什么不能只看模型，还要评“模型×执行框架”

一、评测概述：一个被榜单掩盖的关键变量

在Coding Agent（编码智能体）的评测实践中，一个越来越明显的现象是：同一款模型，在不同的执行框架（Harness）下，任务通过率可能出现成倍差异；而同一套执行框架，套用到不同模型上，效果排名又可能完全重排。这意味着，传统“只给模型打分”的评测范式，在Agent阶段已经不足以支撑技术选型。

本文要评测的对象不是某一款具体模型或某一个具体工具，而是“模型 + 执行框架”这一组合单元的整体效能。读者通过本文可以获得三方面判断：第一，理解执行框架为何会显著改变模型的实际表现；第二，掌握一套可操作的组合式评测方法，包括维度设计、变量控制与结果解读；第三，明确在自身业务场景下应如何设置评测边界，避免被单一榜单误导。

本文适合开发者、系统架构师、技术负责人、运维与平台工程团队，以及正在做AI编码能力选型的企业技术决策者。评测的目的不是给出“哪个好”的绝对结论，而是建立一套条件化的判断框架：在什么任务分布、什么上下文规模、什么工具链约束下，哪种组合更匹配业务目标。

二、评测对象说明：Coding Agent到底由什么构成

要设计合理评测，先要拆解评测对象。一个可用的Coding Agent大致可抽象为两层：

• 模型层（“大脑”）：负责理解需求、推理、生成代码与决策下一步动作；
• 执行框架层（Harness）：负责把模型能力落地为可执行流程，包括上下文管理、工具调用编排、文件读写、命令执行、结果回传、失败重试、状态记忆与流程控制。

模型本身并不能直接完成“打开仓库→检索代码→读取文件→修改代码→运行测试→发现报错→再次修改→比对差异→确认修复”这一整条链路。真正把动作串起来、决定每一步给模型看什么信息、什么时候截断历史、什么时候触发工具、失败后如何重试的，是执行框架。因此执行框架不是简单的“界面壳”，而是决定模型智力能释放多少的能力放大器或衰减器。

一个值得注意的技术事实是：在Coding Agent的token消耗结构中，大量token并非花在最终写出代码上，而是花在读取、定位和探索代码库上。行业公开的 agent 实践观察显示，读取类操作的token占比常在六成以上。这直接说明：“模型如何获得上下文”本身就是Coding Agent能力的组成部分，而这恰恰由执行框架主导。评测若不控制这一层，测到的就只是被框架过滤后的残余能力。

三、评测维度设计：建立组合式评测框架

针对“模型×执行框架”组合，建议从以下维度建立评测框架。每个维度都需要明确“观察什么”和“如何解读”。

维度	观察指标	解读要点
功能完整性	任务链路覆盖度、工具调用成功率	是否支持检索、编辑、执行、验证的完整闭环
任务有效性	任务通过率、修复正确率	需区分“通过”是真实修复还是测试绕过
上下文效率	有效token占比、上下文截断频率	读取占比过高说明定位能力弱或框架检索策略差
稳定性	长任务完成率、异常恢复率	多轮失败后能否自恢复，而非陷入循环
易用性	接入配置复杂度、调试可观测性	日志是否可追溯每一步决策
兼容性	与现有仓库结构、构建体系、依赖环境的适配	换仓库后表现是否大幅波动
安全性	命令执行边界、权限约束、敏感信息处理	是否限制危险操作与越权读写
成本结构	单任务token消耗、重试次数、人工干预成本	通过率高但token翻倍需综合权衡

其中上下文效率是最容易被忽视、却对结果影响最大的维度。同一模型在两种框架下通过率差异显著，常见技术原因就包括：框架A采用更精细的代码检索与上下文裁剪，把有限窗口留给高相关信息；框架B简单堆叠历史，导致关键信息被稀释、模型在噪声中迷失。评测时必须把这类框架策略作为变量记录，否则无法解释结果差异。

四、评测环境与前提：控制变量是可信度的基础

组合式评测最容易犯的错误，是“换了框架也换了环境”。可信评测需先固定以下前提：

1. 任务集一致：使用同一批任务样本，覆盖缺陷修复、功能新增、重构、测试补全等类型，并记录难度分布；
2. 仓库与环境一致：同一代码库快照、同一构建与测试环境、同一依赖版本；
3. 模型接入参数一致：同一模型版本、同一温度与采样策略、同一最大上下文限制；
4. 资源与网络条件一致：同等算力配额、同等超时设置、同等并发度；
5. 评价口径一致：通过判定规则、测试用例集合、是否允许人工介入，都需事先固化。

只有在此前提下，观察到的差异才能归因于“模型×框架”的组合效应，而非环境噪声。建议在正式评测前先跑一轮基线，记录基础通过率与token消耗，作为后续对比参照。

五、评测方法：分维度验证与过程记录

评测方法应体现“可复现、可解释”。建议流程如下：

第一步，功能链路验证。 构造典型任务，观察组合是否完成“定位—修改—执行—验证”闭环。记录每一步工具调用是否成功、失败后是否重试、重试是否收敛。

第二步，有效性验证。 对每个任务记录最终结果，并做二次核验：通过测试是否等价于问题真正解决。可用伪代码示意判定逻辑：

for task in task_set:
    result = agent.run(task)
    if result.tests_passed and not result.hack_detected:
        record(task, "pass", tokens=result.token_usage)
    else:
        record(task, "fail", reason=result.failure_reason)

第三步，上下文效率分析。 统计读取类操作与写入类操作的token占比、上下文截断次数、重复读取同一文件的频率。读取占比异常高，往往指向框架的检索策略或记忆机制存在瓶颈。

第四步，稳定性与异常测试。 注入异常输入，如不存在的文件路径、失败的命令、超时依赖，观察组合是否能识别并恢复，而非无限重试或静默失败。

第五步，安全边界检查。 验证命令执行是否受约束、是否限制越权访问、日志是否记录敏感操作。

第六步，成本核算。 汇总单任务平均token消耗、平均重试次数、人工干预比例，形成成本画像。

整个过程需保留日志与中间状态，确保结论可回溯。

六、结果解读：排名相关系数低说明了什么

原文提及的一个关键现象值得从评测角度解读：多个执行框架在两个不同模型上的排名相关性极低，接近无关。这在评测上意味着框架与模型之间存在显著的交互效应，即框架的优劣高度依赖所搭配的模型。技术原因可能包括：不同模型的指令遵循风格、工具调用格式偏好、上下文利用方式不同，导致同一框架的提示组织与重试策略对某些模型友好、对另一些模型不适配。

因此解读结果时必须坚持三条原则：

• 不做单点结论：某组合在某任务集上通过率高，只能说明在该任务分布与该环境下有效；
• 区分能力与适配：通过率差异既可能来自模型推理能力，也可能来自框架与模型的适配度，需通过交叉实验分离；
• 关注方差而非均值：稳定性差、长任务完成率低的组合，即使平均通过率尚可，也不适合生产环境。

七、适用场景分析与选型建议

不同业务场景应侧重不同维度：

• 日常缺陷修复类场景：重点看任务有效性与上下文效率，关注单任务成本；
• 大型仓库长链路任务：重点看稳定性与长任务完成率，关注失败恢复能力；
• 受监管或高安全要求场景：重点看命令执行边界、权限控制与日志审计；
• 平台化集成场景：重点看兼容性、可观测性与接入改造成本。

选型建议上，应坚持“先定场景、再定指标、后做对比”的顺序，把评测单元设为“模型×框架”组合，而非孤立模型。对候选组合做交叉矩阵测试，记录每个组合在多类任务上的表现与成本，再结合业务约束做条件化选择。

八、风险与限制

组合式评测存在固有边界：任务集规模有限可能带来样本偏差；仓库结构差异会影响框架检索策略的发挥；模型版本迭代会使历史结论快速失效；资源配额与网络波动会引入噪声；短期评测难以反映长期运行中的漂移与维护成本。因此评测结论应标注适用条件与时效，并建立定期复评机制。

九、总结

Coding Agent的评测单元已经从“模型”演进为“模型×执行框架”。执行框架通过上下文管理、工具编排与流程控制，直接决定模型能力的释放程度；同一模型换框架表现大幅波动、框架排名跨模型重排，都是这一交互效应的直接体现。可信的评测需要固定环境与任务集、分维度验证、记录过程数据，并对结果做条件化解读。对技术决策者而言，与其追问“哪个模型最强”，不如追问“在我的任务分布与约束下，哪个组合更稳、更省、更可控”。