HN 热议：现有编程 Agent 基准测试可能都在「作弊」。DeepSWE 用 91 个仓库、5 种语言重新定义了什么是真正的代码能力。
为什么你需要学会评测 AI 编程 Agent
先看两组数据：
数据一：DeepSWE 团队分析了 SWE-bench Verified（当前最流行的编程 Agent 基准），发现很多高分 Agent 实际上在「背题」——训练数据污染率惊人。他们提出了一种无污染替代方案，提示词只有 SWE-bench Pro 的一半，但需要生成的代码量是 5.5 倍。
数据二：2026 年 5 月，AI 编程工具市场有至少 15 个主流选项：Claude Code、Cursor、Windsurf、Hermes Agent、OpenClaw、GitHub Copilot、Codex CLI、Replit Agent、Devin……每个都声称自己最强。
作为 AI 创业者，你面临一个残酷的现实：选错工具的成本不是几十美元订阅费，而是整个产品的开发效率。
这篇教程给你两样东西：
1. DeepSWE——一个刚发布的、更诚实的编程 Agent 基准测试
2. 四维自测框架——不依赖任何外部基准，你可以在 30 分钟内完成的自评方法
第一部分：DeepSWE 是什么
核心设计
DeepSWE 由 AugmentedSWE 团队开发，2026 年 5 月 27 日在 HN 上获得 33 分、9 条评论。它的设计原则非常激进：
| 对比维度 | SWE-bench Verified | DeepSWE |
|---|---|---|
| 测试仓库 | 12 个（Python 为主） | 91 个仓库 |
| 语言覆盖 | 1 种 | 5 种（Python/JS/TS/Go/Rust） |
| 提示词长度 | 长（~3000 tokens） | 短（~1500 tokens） |
| 所需代码量 | 1x | 5.5x |
| 污染风险 | 高（数据已在训练集） | 低（新构造任务） |
关键洞察：DeepSWE 用更短的提示词要求 Agent 生成更多代码。 这直接测试 Agent 的「自主编程能力」，而不是「指令执行能力」。
为什么现有基准不可信
SWE-bench 的问题不是个例。几乎所有流行基准都有类似问题：
- 数据泄露：测试集的问题描述和解决方案已在训练数据中出现过
- 过度优化：Agent 开发者专门为基准调优，但真实场景表现下降
- 任务单一：只测试「修 bug」，不测试「从零写功能」「重构」「写测试」
DeepSWE 的解决方案：从 GitHub 上 91 个活跃仓库中提取真实 issue，确保这些仓库的代码在 LLM 训练截止日期之后有显著更新。
第二部分：如何运行 DeepSWE（实操）
环境准备
# 1. 克隆仓库
git clone https://github.com/AugmentedSWE/deepswe
cd deepswe
# 2. 安装依赖
pip install -r requirements.txt
# 3. 配置你要测试的 Agent
# 编辑 config.yaml，设置 API key 和模型
配置你的 Agent
DeepSWE 支持通过统一接口接入任何编程 Agent。以下是一个接入 Claude Code 的配置模板：
# config.yaml
agent:
name: "claude-code"
type: "cli"
command: "claude"
args: ["--print", "--output-format", "text"]
max_tokens: 16000
timeout: 300 # 每个任务 5 分钟超时
benchmark:
subset: "full" # 可选: full, mini (10个任务快速测试), lang_specific
languages: ["python", "javascript", "typescript"]
max_tasks: 20 # 首次测试建议 10-20 个任务
运行测试
# 快速测试（10个任务，约15分钟）
python run.py --subset mini --agent claude-code
# 完整测试（91个任务，约2-3小时）
python run.py --subset full --agent claude-code --output results/
# 多 Agent 对比
python run.py --subset mini --agent claude-code --output results/claude/
python run.py --subset mini --agent cursor --output results/cursor/
python run.py --subset mini --agent windsurf --output results/windsurf/
解读结果
运行后会生成 results/summary.json：
{
"agent": "claude-code",
"total_tasks": 20,
"passed": 14,
"pass_rate": 0.70,
"by_language": {
"python": {"total": 8, "passed": 7, "rate": 0.875},
"javascript": {"total": 7, "passed": 5, "rate": 0.714},
"typescript": {"total": 5, "passed": 2, "rate": 0.400}
},
"avg_tokens_per_task": 4200,
"avg_time_per_task_sec": 87
}
关注三个关键指标：
1. Pass Rate：整体通过率，>70% 算优秀
2. 语言差异：如果 Python 95% 但 TypeScript 40%，说明 Agent 对静态类型理解不足
3. Tokens/Task：效率指标——同样通过率下，token 消耗越少越好
第三部分：四维自测框架（不依赖任何基准）
基准测试告诉你 Agent 在「理想条件」下的表现。但你的项目不是理想条件。这里有一套 30 分钟自测框架：
维度一：上下文理解（10 分钟）
测试方法：给 Agent 一个你真实项目中的复杂文件（500+ 行），问三个递进问题：
测试文件：你项目中最复杂的业务逻辑文件
问题 1（定位）：「这个文件中处理支付的逻辑在哪里？请指出具体函数名和行号。」
问题 2（推理）：「如果用户在支付过程中刷新页面，可能会出什么问题？」
问题 3（修改）：「请给 payment_callback 函数加一个幂等性保护，避免重复扣款。」
评分标准：
- 3/3 正确且代码可运行：优秀
- 2/3 正确：可用
- 1/3 或更少：不可用于生产项目
维度二：跨文件修改（10 分钟）
测试方法：给一个需要同时修改 3+ 个文件的任务。
任务示例：「把项目中的用户认证从 Session 改为 JWT。
需要修改的文件至少包括：auth middleware、login handler、API 路由守卫。」
评分标准：
- 自动识别所有需要修改的文件：+30 分
- 修改后类型检查通过（TS项目）/ 语法正确（JS项目）：+30 分
- 修改后现有测试仍然通过：+40 分
维度三：代码审查能力（5 分钟）
测试方法：给一段故意有 5 个 bug 的代码（含逻辑错误、安全漏洞、性能问题），让 Agent 做 Code Review。
# 故意埋了 5 个问题的代码
def process_order(user_id, items, coupon_code=None):
# Bug 1: SQL 注入风险
query = f"SELECT * FROM users WHERE id = {user_id}"
user = db.execute(query)
# Bug 2: 未处理空列表
total = sum(item['price'] for item in items) / len(items)
# Bug 3: N+1 查询
for item in items:
stock = db.execute(f"SELECT stock FROM products WHERE id = {item['id']}")
# Bug 4: 优惠券逻辑错误（未验证）
if coupon_code:
total *= 0.8 # 所有优惠券都是 8 折？
# Bug 5: 竞态条件
db.execute(f"UPDATE inventory SET count = count - 1")
return total
评分标准：
- 找出 5/5 个 bug：优秀（具备 Senior 级别的代码嗅觉）
- 找出 3-4 个：可用（能覆盖大部分问题）
- 找出 <3 个：不适合用于代码审查
维度四：技术决策能力（5 分钟）
测试方法：提一个架构选型问题。
问题：「我们正在做一个实时协作编辑器（类似 Google Docs）。
前端用 React，后端还没定。请推荐技术栈并说明理由。
需要考虑：并发冲突解决（OT vs CRDT）、WebSocket 方案、数据库选型。」
评分标准：
- 给出 OT vs CRDT 的具体对比，且推荐有依据：+40 分
- WebSocket 方案提到具体库（如 y-websocket、PartyKit）：+30 分
- 数据库选型考虑了实时协作场景（如 Yjs + SQLite/PostgreSQL）：+30 分
第四部分：真实场景下的 Agent 选择决策树
测试完四个维度后，用这个决策树选择工具：
你的项目类型是什么？
│
├─ 后端 API / 微服务（Python/Go）
│ └─ 关注维度一（上下文理解）+ 维度二（跨文件修改）
│ ├─ 两者优秀 → Claude Code 或 Hermes Agent
│ └─ 仅维度一优秀 → Cursor（交互式开发更友好）
│
├─ 前端 SPA（React/Vue/TypeScript）
│ └─ 关注维度二（跨文件）+ 维度四（技术决策）
│ ├─ 两者优秀 → Windsurf（前端生态集成好）
│ └─ 维度四优秀 → Claude Code + Cursor 组合
│
├─ 全栈 SaaS（Next.js/Remix）
│ └─ 四个维度都需要
│ ├─ 全部优秀 → Claude Code（全栈能力最均衡）
│ └─ 维度一弱 → 补充 OpenClaw 的多 Agent 协作
│
└─ 数据处理 / AI Pipeline（Python）
└─ 关注维度一 + 维度三（代码审查）
├─ 两者优秀 → Hermes Agent（MCP 工具生态强）
└─ 维度三弱 → 永远不要让 Agent 独立操作数据库
总结：三个立刻能用的行动
-
今天：花 30 分钟跑一遍四维自测框架。你不需要 DeepSWE 或任何外部工具——只需要你正在用的 AI 编程 Agent 和一个真实的项目文件。
-
本周：如果团队在用多个 Agent，用 DeepSWE 的
mini模式（10 个任务）做一个横向对比。数据比直觉可靠。 -
持续：每当你升级 Agent 版本或换模型时，重新跑一次基准。Agent 的能力会随着模型更新而变化——上个月表现好的，这个月可能被反超。
核心认知：AI 编程 Agent 不是「用了就赢」的魔法工具。它们是能力差异巨大的生产力杠杆——选对和选错之间的差距，可能是一个季度交付 vs 三个季度延迟。
用数据选工具，而不是用营销文案选工具。这就是评测的意义。
本文基于 DeepSWE 基准测试（github.com/AugmentedSWE/deepswe）和 HN 社区讨论。DeepSWE 覆盖 91 个仓库、5 种语言，提示词仅为 SWE-bench Pro 的一半但要求 5.5 倍代码量。