直接答案
编码代理评测应使用具有代表性且冻结的仓库任务,预先定义验收测试、安全边界与审查标准;同时记录结果和过程证据,在行为存在波动时重复试验,保留失败尝试,并避免把正确性、成本、速度、安全和可维护性压成一个无法解释的总分。
关键结论
- 使用真实任务类别、冻结输入和独立编写的验收标准。
- 分别报告正确性、安全、过程成本和可维护性。
- 保留失败试验与人工干预,不能只报告最佳一次。
- 对评测框架、仓库快照、客户端配置和证据来源进行版本化。
关键事实
这篇内容解决什么问题
帮助团队在选择或扩大编码代理工作流之前建立可审计评测。
核验范围与限制
- 证据类型
- 官方文档协议规范
- 核验范围
- 框架把通用评测指南映射到仓库变更、命令执行、测试、审查与权限边界。
- 限制与失效条件
- - 不发布基准分数或产品排名。
- - 结果不能外推到未测试任务和配置。
- - 人工审查量表需要校准。
从真实维护工作建立任务集
覆盖不同工作类别:代码解释、局部 Bug 修复、补测试、受约束重构、依赖调查和安全审查。移除凭据与私人数据,冻结起始 commit,并确保维护者能独立完成和验证每个任务。
不能让一个合成 Issue 代表所有仓库工作。明确报告覆盖空白,并且只在验收条件可独立审查时增加任务。
运行代理前先写验收标准
把可执行检查与人工量表结合。测试确认行为与类型,维护者评估范围纪律、可读性、架构适配和开放风险。还要列出禁止路径与安全要求,避免功能正确但不安全的补丁通过。
- 必需行为与回归测试
- 允许和禁止的文件范围
- 权威命令与运行环境
- 安全与秘密处理检查
- 人工审查标准与拒绝原因
在不收集秘密的前提下记录过程证据
记录客户端和配置版本、起始 commit、任务 ID、权限、脱敏工具动作、退出码、最终 diff、测试输出、重试、人工干预与处置结论。只有政策允许且完成脱敏时才保存原始提示或源码片段。
基础设施故障与代理错误必须分开。网络中断、基线测试损坏、夹具无效和补丁错误需要不同处理。
把评测维度分开报告
分别报告任务完成、测试正确性、审查发现、越界、人工纠正、请求、用量和耗时。如需总分,必须公开权重和底层结果,让使用者能应用不同取舍。
重复试验并审查框架漂移
运行足够次数以暴露不稳定,但没有合适统计设计时不能声称置信度。保留全部试验、可获得的随机设置和准确框架版本。客户端、模型、网关、权限策略或仓库发生重要变化后重新运行。
官方来源与核验范围
本文以公开官方文档为事实依据;命令和配置可能随客户端版本变化,执行前请同时核对对应来源。
查看技术核验方法