Coding Agent 评测：为何要看模型与执行框架组合

评测概述

本文的评测对象是”智能体执行框架（Agent Harness）对编码类智能体（Coding Agent）实际能力的影响”。核心问题是：当我们评价一个编码智能体的表现时，究竟应该只评价底层大模型，还是应该评价”模型 × 执行框架”这个整体组合。

本文适合开发者、架构师、技术负责人以及正在做模型/工具选型的团队阅读。它不会简单告诉你”哪个更好”，而是帮助你建立一套可复现、可解释的评测框架，回答”换一套执行框架会带来多大差异””评测榜单能不能直接指导选型””token 到底花在哪里”等实际问题。

需要提前说明：评测的目的不是得出”执行框架比模型更重要”这种片面结论，而是要指出一个更深的现象——进入编码智能体阶段后，脱离具体执行框架单独评价模型，其结论的可迁移性会大幅下降。换句话说，评测一个编码智能体，本质上是在评测一个”系统”，而不是一个孤立的”组件”。

评测目标

本次评测重点验证以下几个问题：

1. 同一模型在更换执行框架后，任务完成率（如一次通过率）的波动幅度有多大；
2. 不同执行框架在不同模型上的排名是否稳定，是否具有可迁移性；
3. 智能体在完成任务过程中，token 消耗主要花在”读代码”还是”写代码”上；
4. 评测结论在什么条件下成立、在什么条件下失效。

这些问题的价值在于：如果只测模型不测框架，团队很可能把一个”组合效果”错误地归因到模型本身，从而在选型时做出错误决策。

评测对象说明

可以把编码智能体拆解为：

Coding Agent = 模型 + 执行框架（Harness）

其中：

• 模型是”大脑”，负责推理、生成代码、判断和纠错；
• 执行框架相当于”眼睛 + 手 + 工作台 + 记忆系统 + 工作流程 + 项目经理”。

当把一个待修复的 issue 交给模型时，它自身并不能直接完成”打开仓库 → 搜索代码 → 读取文件 → 修改代码 → 运行测试 → 发现报错 → 重新修改 → 生成差异补丁 → 确认问题解决”这一整套动作。真正把这些动作串联起来、决定每一步输入给模型什么上下文的，是执行框架。

因此，执行框架绝不是一个单纯的”UI 壳”。它决定了模型的智力究竟能发挥出来多少，是评测中不可忽视的核心变量。

为什么同一框架在不同模型上效果完全不同

一次公开基准测试显示：同一模型仅更换执行框架，任务的一次通过率可以从约 23% 提升到约 52%（模型 A），或从约 15% 提升到约 36%（模型 B）。更关键的是，10 个执行框架在两个模型上的排名相关系数仅约 -0.05，基本等同于”完全无关”。

这意味着：在模型 A 上表现最好的执行框架，换到模型 B 上可能直接掉到后排。其技术原因在于，不同框架在”上下文管理”上差异巨大——哪些历史记录继续保留、如何截断过长上下文、何时触发代码检索、如何组织工具调用顺序，这些策略与模型自身的指令遵循能力、上下文窗口利用率、工具调用稳定性存在强耦合。一个框架对某类模型是”扬长”，对另一类模型就可能是”补短失败”。

相关研究进一步发现，编码智能体的 token 大量消耗在”读取、定位、探索代码库”而非最终写代码上：在某种组合下读操作的 token 占比约 76.1%，换一类模型后也仍有约 67.5%。这说明”模型如何获得上下文”本身就是编码能力的重要组成部分，也进一步解释了为什么框架会成为决定性变量。

评测维度设计

一个只回答”能不能用”的评测是不够的。建议把编码智能体拆成以下可观察、可验证、可解释的维度：

评测维度	关注点	验证方式
任务有效性	一次通过率、多轮修正后通过率	同一批任务在不同框架下对比
排名稳定性	框架跨模型的排名是否可迁移	计算排名相关系数
上下文管理	历史/检索信息如何注入与截断	观察注入策略、截断行为、检索触发时机
Token 效率	读/写/推理各阶段消耗占比	分类统计 token 使用情况
稳定性	长任务、异常输入、网络波动下的表现	边界输入与故障注入
可观测性	日志、链路、可复现性	全流程记录与回放
成本与可维护性	资源消耗、配置复杂度、升级成本	单位任务资源统计、配置项审计

评测环境与前提

在开始前必须明确边界条件，否则结果不可比：

• 数据集：使用同一批具有代表性的任务（如真实仓库修复任务），任务难度分布一致；
• 模型配置：固定模型的推理参数（温度、最大 token 等）；
• 执行框架：每次只改变一个框架，其余变量保持不变；
• 运行环境：固定的计算资源、超时时间、并发度、网络条件；
• 评分口径：统一”通过”的判定标准，避免主观打分。

评测方法

核心思路是控制变量、建立基线、分维度记录。参考伪代码如下：

# 控制变量：固定模型配置与环境，遍历框架
def evaluate(models, harnesses, tasks, env):
    results = {}
    for model in models:                 # 每个模型单独跑
        for harness in harnesses:        # 每次只换一个框架
            scores, tokens = [], []
            for task in tasks:           # 同一批任务、同一评分口径
                score, tok = run_agent(model, harness, task, env)  # 固定超时/资源
                scores.append(score)
                tokens.append(tok)
            results[(model, harness)] = {
                "pass_at_1": aggregate(scores),
                "token_profile": classify_tokens(tokens),  # 读/写/推理分类
            }
    return results
# 判断框架效果是否可迁移：看跨模型排名相关性
corr = spearman_rank_correlation(
    ranking(results, "模型A"),
    ranking(results, "模型B")
)
# corr 接近 0 → 框架效果不可迁移，必须"模型×框架"联合选型

配套动作包括：分维度验证功能与效率、记录每步错误与日志、对异常输入做容错测试、分析 token 结构，并明确说明结论适用的条件。

结果解读

解读结果时要避免绝对化判断：

• 若某框架在多个模型上都排在前列，说明其上下文策略较为通用，可作为默认基线；
• 若框架排名在模型间波动很大（如相关系数接近 0），说明效果强依赖模型，必须联合选型；
• 若 token 主要消耗在读取而非生成，说明优化重点应放在检索与上下文压缩策略，而非单纯提升模型生成能力；
• 差异背后的技术原因可能来自资源配置、缓存策略、并发模型、上下文注入方式或依赖组件差异，需要结合日志进一步定位。

适用场景分析

• 生产系统集成：优先关注稳定性、可观测性和成本可控性，而非单纯刷通过率；
• 大规模自动化修复：重点看排名稳定性与 token 效率，控制单位任务的资源开销；
• 内部工具/低并发场景：可更关注易用性与配置复杂度；
• 对数据安全要求高的场景：需重点关注权限控制、日志审计与敏感信息保护。

风险与限制

评测结论存在明显边界：样本偏差（任务分布不代表真实业务）、环境差异（资源与网络不同导致结果不可复现）、数据质量（数据集过拟合或难度不均）、以及长期运行的不确定性（模型或框架升级后排名可能改变）。因此单次榜单不宜直接作为长期选型依据。

选型与使用建议

• 不要脱离框架单独评价模型，应按”模型 × 执行框架”组合评测；
• 建立自己的小规模、贴合业务的评测集，而非只看公开榜单；
• 固定变量、多次复现，关注排名稳定性而非单次通过率；
• 把 token 结构、稳定性、可观测性纳入常规评测清单；
• 关注云侧通用能力的配合，如云服务器、容器平台、日志服务、监控告警、身份认证与安全防护，用于保障评测与运行的资源、可观测和安全边界。

总结

编码智能体的评测对象应从”模型”转向”模型 × 执行框架”的组合。评测需覆盖任务有效性、排名稳定性、上下文管理、token 效率、稳定性、可观测性与成本等维度，并通过控制变量、建立基线和分维度记录来保证可复现。结论必须条件化表达：在高并发自动化场景应重点验证吞吐与稳定性，在数据敏感场景应重点关注权限与审计。最终，评测的价值在于帮助团队理解边界、做出稳健的联合选型决策，而非给出”谁最好”的简单答案。