SWE-agent 竞技模式实战指南：面向 SWE-bench 的大规模基准评测配置与运行策略-平芜编程栈

SWE-agent 竞技模式实战指南：面向 SWE-bench 的大规模基准评测配置与运行策略

【免费下载链接】SWE-agentSWE-agent takes a GitHub issue and tries to automatically fix it, using your LM of choice. It can also be employed for offensive cybersecurity or competitive coding challenges. [NeurIPS 2024]项目地址: https://gitcode.com/GitHub_Trending/sw/SWE-agent

本篇技术指南基于 SWE-agent 官方文档《Competitive runs》，系统讲解如何以"竞技模式"在 SWE-bench 等大规模基准上运行 SWE-agent：包括官方提交配置的结构解析、多 API Key 轮换、多 worker 并行下的内存与 Docker 容器管理，以及分辨率与成本之间的权衡策略。读完本文，你将掌握一套可复现、可裁剪的基准评测运行方案，并能直接套用仓库中现成的竞争配置进行大规模批量求解。

前置要求

竞技模式依赖两个核心能力，请确保已熟悉对应文档：

命令行基础：掌握sweagent run/run-batch的 CLI 用法，参见命令行教程与批处理模式；
Docker 沙箱：默认示例会在 Docker 沙箱中执行代码，需要预先安装 Docker；遇到问题可参考 Docker 排障。

当前官方竞争配置解析

官方所有基准提交配置统一存放在仓库的 config/benchmarks 目录下，每个配置文件顶部都附有对应的运行命令。以下是两个最典型的提交配置。

单次尝试配置：`250225_anthropic_filemap_simple_review.yaml`

这是官方当前默认的**单次尝试（one-attempt）**配置，使用claude-3-7-sonnet-20250219，完整文件见 config/benchmarks/250225_anthropic_filemap_simple_review.yaml。其运行命令（针对 SWE-bench lite）为：

sweagent run-batch \ --num_workers=20 \ --instances.type=swe_bench \ --instances.subset=lite \ --instances.split=test \ --instances.shuffle=True \ --instances.evaluate=True \ --instances.deployment.docker_args='--memory=10g' \ --config config/benchmarks/250225_anthropic_filemap_simple_review.yaml

该配置的核心结构如下：

agent: type: default templates: system_template: |- You are a helpful assistant that can interact with a computer to solve tasks. instance_template: |- <uploaded_files> {{working_dir}} </uploaded_files> I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description: ... tools: execution_timeout: 300 bundles: - path: tools/registry - path: tools/edit_anthropic - path: tools/review_on_submit_m - path: tools/diff_state enable_bash_tool: true parse_function: type: function_calling registry_variables: USE_FILEMAP: 'true' SUBMIT_REVIEW_MESSAGES: - | Thank you for your work on this issue. Please carefully follow the steps below to help review your changes. ... history_processors: - type: cache_control last_n_messages: 2 model: name: claude-3-7-sonnet-20250219 api_key: $CLAUDE_API_KEY_ROTATION per_instance_cost_limit: 2 per_instance_call_limit: 150 total_cost_limit: 1000.0 temperature: 0.0 delay: 0.0

关键设计点：

提示模板：instance_template采用 Anthropic/OpenHands 风格，明确要求 Agent 先"找到并阅读相关代码 → 编写复现脚本 → 修改源码 → 重跑复现脚本验证 → 考虑边界情况"，并要求"修改最小化、不要改动测试文件"；
工具捆绑：通过tools.bundles挂载了 registry、edit_anthropic、review_on_submit_m、diff_state 四套工具，并开启USE_FILEMAP文件地图与提交前自审（SUBMIT_REVIEW_MESSAGES会在提交时要求 Agent 复查修改、还原测试文件、重新确认 diff）；
提示缓存：history_processors使用cache_control，last_n_messages: 2，这是降低 Claude 成本的关键，详见 models.md 的 Claude 章节；
成本与调用上限：单实例成本上限$2、单实例调用上限150次、总成本上限$1000，temperature: 0.0保证确定性输出。

多尝试配置：`250212_sweagent_heavy_sbl.yaml`

这是官方 2025-02-12 的 SWE-bench lite 提交配置，以 5 种略有差异的配置各运行一次，再用 o1 模型作为裁判挑选最佳 patch。配置结构为agent.type: retry，完整文件见 config/benchmarks/250212_sweagent_heavy_sbl.yaml，运行命令：

sweagent run-batch \ --num_workers=12 \ --instances.type=swe_bench \ --instances.subset=lite \ --instances.split=test \ --instances.shuffle=True \ --instances.evaluate=True \ --instances.deployment.docker_args=--memory=10g \ --config config/benchmarks/250212_sweagent_heavy_sbl.yaml

其agent_configs中定义了 5 个default子代理，主要差异在于：

+filemap：带文件地图 + 提交自审 + diff 状态；
vanilla anthropic：不注入 diff 的"朴素"版本；
+state：在next_step_template中通过 Jinja 条件注入累积 diff（{% if diff %}...{% endif %}），并配套remove_regex历史处理器定期从上下文中清除<diff>...</diff>，避免上下文膨胀； 4-5. 其余尝试在此基础上进一步组合微调。

所有子代理共用同一模型锚点（&model：claude-3-7-sonnet-latest，单实例成本上限$1.5、调用上限75次、temperature: 0.0、delay: 1.0）。

外层retry_loop采用chooser裁判机制：

retry_loop: type: chooser cost_limit: 6.0 max_attempts: 10 min_budget_for_new_attempt: 1.0 chooser: model: &chooser_model name: o1 top_p: null temperature: 1. per_instance_cost_limit: 30 completion_kwargs: reasoning_effort: "high" instance_template: | You will be given a problem statement and a list of patch submissions. Pick the most reasonable patch. ... <IMPORTANT>The last line of your response should be the index of the patch you chose.

裁判会拿到问题描述、每个候选 patch 以及"带 30 行上下文的最终编辑文件"（{{edited_files30}}），并按要求输出所选 patch 的索引。

⚠️ 配置结构与 CLI 参数冲突警告：多尝试（retry）配置的内部结构与默认单代理配置完全不同。如果在这种配置上继续传--agent.model.name之类的参数，会触发（令人困惑的）报错。请务必以配置文件顶部注释中的命令为准，先查看 250212_sweagent_heavy_sbl.yaml 了解结构。

从源码实现看，RetryAgent会在每次新尝试前根据剩余预算动态下调子代理的per_instance_cost_limit（sweagent/agent/agents.py），并检查总成本是否超过retry_loop.cost_limit的 1.1 倍（L336），从而在成本与多次尝试之间保持平衡。

多 API Key 轮换：突破 Claude 并行上限

用 Claude 在多个 worker 上并行跑基准时，会受限于Anthropic 每 key 仅 4 个缓存断点的限制：单次 Agent 运行需要占用其中 2 个断点（分别用于读取与写入缓存），因此每个 key 同时只能支撑 2 个并行实例。要支撑更多并行，需要配置多个 key。

在运行前设置如下环境变量（用:::连接多个 key）：

# concatenate your keys export CLAUDE_API_KEY_ROTATION="KEY1:::KEY2:::KEY3"

这正是配置文件中api_key: $CLAUDE_API_KEY_ROTATION的取值来源。轮换机制保证每个 worker（线程）在整个任务期间固定使用同一个 key，从而不破坏提示缓存。更多细节参见 models.md 的多 key 章节。

内存消耗管理：避免 OOM 与服务器锁死

官方提交配置运行在一台32GB 内存、8 核的机器上。为避免单实例内存超限（OOM），推荐给每个 Docker worker 设置内存上限：

--instances.deployment.docker_args=--memory=10g

即把每个 worker 的容器最大内存限制为 10GB。在官方实践中，这一设置完全消除了 OOM 的发生。

但 OOM 极端情况下可能直接把你锁在服务器外（系统无响应、无法登录），因此官方建议再加一道"第二层防线"：用一个哨兵脚本监控系统内存，杀掉任何内存占用过高的进程（注意：该脚本会作用于所有进程，而不仅仅是 swe-agent）。

仓库已提供完整实现 docs/usage/memory_sentinel.py，核心逻辑：

每秒通过psutil.virtual_memory()检查可用内存（不含 swap）；
当可用内存低于5GB 阈值时，找出 RSS 占用最高的进程并对其发送SIGKILL；
全程记录日志到memory_sentinel.log。

直接运行即可：

python memory_sentinel.py

残留 Docker 容器清理哨兵

swe-agent 正常退出时会清理自己创建的容器，但被强制 kill（如 OOM 被杀、频繁 Ctrl-C 中止）时可能遗留大量容器。此时可以周期性地用哨兵脚本清理（同样会影响所有长期运行的容器）。

仓库提供的 docs/usage/containers_sentinel.sh 实现如下：

#!/bin/bash while true; do echo "Checking for long-running containers..." # List all running containers with their uptime docker ps --format "{{.ID}} {{.RunningFor}}" | while read -r id running_for; do # Extract the number and unit from the running time if [[ $running_for =~ ([0-9]+)\ (hour|hours) ]]; then hours=${BASH_REMATCH[1]} if (( hours >= 2 )); then echo "Killing container $id (running for $running_for)..." docker kill "$id" fi elif [[ $running_for =~ ([0-9]+)\ (day|days) ]]; then # If it's running for at least a day, it's definitely over 2 hours echo "Killing container $id (running for $running_for)..." docker kill "$id" fi done echo "Sleeping for 10 minutes..." sleep 600 # Wait 600 seconds (10 minutes) before running again done

脚本每 10 分钟扫描一次，凡是运行时长达到 2 小时以上的容器一律docker kill，作为大规模并行跑批的兜底卫生保障。

分辨率与成本的权衡策略

官方在长时间跑基准后总结出三条经验，直接适用于大规模评测：

多尝试配置必然非常昂贵：retry类配置（如 heavy_sbl）会多次完整运行 Agent 再交由 o1 裁判，成本显著高于单次尝试。若成本敏感，不要使用这类配置；
务必设置成本/轮次上限：不加限制的话，Agent 会无限迭代下去，平均成本会趋向无穷大。最简单的成本控制手段是设置单实例成本上限（per_instance_cost_limit）或轮次上限（per_instance_call_limit）；
Claude 3.7 的保守建议值：单实例成本上限$1或更低、调用次数上限50次。官方 SWE-bench 提交使用的限额略高（参见上文两个配置中的具体取值）。

SWE-agent 竞技模式实战指南：面向 SWE-bench 的大规模基准评测配置与运行策略