编码 Agent 的测评不能只看“写出了多少代码”。一个模型可能生成得很快，却改了不该动的文件，甚至把测试一起改绿；真正决定交付质量的，是代码、范围、验证和人工返工能否同时过关。
如果未来 GPT-6 进入编码工具，最有价值的比较方式仍然是固定任务、权限和验收标准，再看它是否独立完成了工作。
一、先写任务协议
每项任务包含：
仓库提交。
完整需求。
允许修改目录。
禁止动作。
测试命令。
成功标准。
任务越具体，模型差异越容易解释。
二、准备三类任务
| 类型 | 示例 | 重点 |
|---|---|---|
| 受控修复 | 修复一个已有失败测试 | 定位和回归 |
| 陌生项目 | 找入口并补功能 | 探索和规划 |
| 批量变更 | 统一配置字段 | 范围和一致性 |
不要把所有任务合并成一个总分。
三、固定工具和权限
每次运行固定：
模型 ID 和推理档位。
Agent 客户端版本。
Shell 和文件工具。
联网权限。
仓库提交和依赖状态。
权限变化后，测到的不再只是模型差异。
四、结果状态要分级
| 状态 | 含义 |
|---|---|
| PASS | 所有硬性条件通过 |
| PARTIAL | 主流程完成但有明确缺口 |
| FAIL | 测试失败、越界或编造结果 |
| INFRA_ERROR | 网络、权限或环境无法判断 |
只有 PASS 样本进入主性能比较。
五、保存完整 Diff
每次运行结束保存：
git diff。
修改文件列表。
测试输出。
工具调用日志。
最终摘要。
Diff 是判断范围和副作用的核心证据。
六、测试不能被任务 Agent 随意修改
修复 Bug 时先提交失败测试，再限制 Agent 不得修改该测试。
如果修复后测试通过，且测试文件没有变化，证据强度明显高于“Agent 自己说已修好”。
七、记录人工修正时间
模型耗时不是交付耗时。
还要记录：
人工补充提示的次数。
人工修改 Diff 的分钟数。
人工回滚或重跑次数。
人工确认权限和发布的等待时间。
如果 Agent 少花 5 分钟、人工多花 20 分钟，整体效率并没有提高。
八、至少重复运行三次
单次运行只能称为一次观察。
建议每类任务运行三次，预算允许时运行五次，并交错执行不同模型，减少网络和服务时段带来的影响。
报告同时写出所有失败样本，不要只展示最短的一次。
九、用中位数而不是最好成绩
对通过样本计算：
中位墙钟耗时。
中位输入和输出 Token。
中位工具调用轮数。
中位数不能解决小样本问题，但比挑选单次最好成绩更稳妥。
十、编码 Agent 的最小评分卡
| 维度 | 0 分 | 1 分 | 2 分 | 3 分 |
|---|---|---|---|---|
| 正确性 | 未完成 | 大量人工修复 | 基本可用 | 验收通过 |
| 范围 | 明显越界 | 多处无关改动 | 少量需清理 | 范围准确 |
| 过程 | 无证据 | 反复失败 | 有部分记录 | 轨迹可回放 |
| 交付 | 无法运行 | 说明不完整 | 可复现 | 测试和 Diff 齐全 |
总分不能替代硬性失败项。
十一、如何写条件化结论
推荐写法：
在固定仓库提交、相同权限和三次运行条件下，
候选模型在受控修复任务中有 x 次 PASS，
通过样本中位耗时为 y。
该结果只代表本任务和环境，不能外推到陌生项目或生产发布。
不要写“GPT-6 编码能力全面领先”，除非有充分、公开、可复现的证据，而且截至本文并无已核验的 GPT-6 官方型号数据。
十二、结论
编码 Agent 的测评对象是完整交付：正确代码、准确范围、可回放轨迹和可接受的人工成本。
未来如果 GPT-6 正式开放，建议先从小任务和沙箱仓库开始，固定基线、重复运行、保存 Diff，并把失败和人工修正一起写进报告。