SWE-agent 是普林斯顿大学 NLP 团队（Princeton NLP）开源的自主软件工程（Autonomous Software Engineering）框架。它解决的问题很具体：给一个 GitHub 仓库和一个 issue 描述，让大语言模型（LLM）自主完成「读代码 → 定位缺陷 → 修改源码 → 运行测试 → 产出补丁（patch）」的完整流程，最终输出可直接评审、应用的代码变更。它与评测基准 SWE-bench 出自同一团队：先用 SWE-bench 定义「什么是修好了」，再用 SWE-agent 回答「怎么让模型修好」。其核心论文《SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering》发表于 NeurIPS 2024，首次系统提出「为 LLM 定制工具界面（Agent-Computer Interface, ACI）」的思想——不是把模型丢进完整 shell 让它自由发挥，而是设计一套模型容易学会、容易调用的受限命令集。2025 年 3 月发布的 v1.0 完全重写了代码库，弃用 ACI 抽象层、回归原生 bash 环境，同时把「开发（run）」与「部署（deploy）」两个阶段分离，命令与配置和旧版不兼容。本文按「速览 → 安装 → 上手 → 能力拆解 → 生产部署 → 选型对比 → 应用场景 → 误区 → 面试题 → 资源」的顺序，基于官方文档与发布记录整理，让读者拿到即可跑通第一条修复流水线。
掌握 SWE-agent，意味着你拥有把「LLM 改代码」从玩具 demo 变成可评估、可批量化、可接 CI 的工程基建的能力，是构建自动修 bug 流水线与评测模型编程能力的关键技能。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 SWE-agent：对话式补丁治标，自主修复流水线治本
传统方式下，让模型修 bug 有两条路，都有硬伤。第一条是人工搬运：工程师阅读 issue、复现问题、定位文件，再把相关代码片段手工粘贴给对话式编程助手（如 ChatGPT、Cursor），拿到建议后自己改、自己测。整个过程高度依赖人的上下文整理能力，仓库一大，人就成了「人工 RAG（检索增强生成）管道」，大量时间耗在找文件和拼上下文上。第二条是「给模型整个仓库」：直接把 repo 全部塞进上下文，受限于 LLM 上下文窗口，大型仓库根本放不下；即便放得下，模型在一台完整的 Linux shell 里自由浏览时，极易迷失在目录树、长输出和无关文件里——SWE-agent 论文的实验数据表明，LLM 在默认 shell 界面中完成代码导航任务的效率很低，这是当时自主 agent 落地的主要瓶颈。
SWE-agent 的方案是把「模型与计算机的交互界面」当作一级设计对象。它不追求让模型像人一样用终端，而是封装一组高信号密度的工具命令——文件查看、按需翻页、搜索、编辑、执行测试——每一条都针对「解决 issue」这一目标做过裁剪，模型学会调用它们远比学会逛 shell 容易。v1.0 之后这一思路进一步演进：移除定制抽象层，直接基于原生 bash，但通过精选命令、脚本和补丁系统（patch system）保证模型的行为可控、产物标准化。
与同类工具相比，SWE-agent 的气质差异在于「离线批处理」与「评测同源」：它不追求交互式结对编程体验，而是把「给定 issue 产出补丁」做成可批量、可复现、可打分的流水线，并直接对接 SWE-bench 基准，让每一次配置改动都能用同一套标准衡量解决率。
安装与环境配置：3 步就绪
第一步安装：SWE-agent 以 PyPI 包形式分发，要求 Python 3.9 及以上版本。建议使用虚拟环境（venv 或 conda）安装，避免污染系统 Python。
第二步配置：安装完成后需要配置 LLM 的 API Key。SWE-agent 通过 LiteLLM 统一接入各家模型服务（LiteLLM 是一个开源的模型网关库，把 OpenAI、Anthropic 等厂商的 API 格式统一成一套），因此只需设置对应的环境变量。默认推荐 Anthropic 或 OpenAI 的密钥。
第三步验证：运行 swe-agent run --help 能正常打印参数列表即安装成功。另外推荐本机安装 Docker：agent 在执行测试等命令时默认在容器内运行，没有 Docker 时基于容器的功能不可用。
# 1. 安装（Python 3.9+）pip install swe-agent # 2. 配置模型 API Key（二选一，或都配）export ANTHROPIC_API_KEY=sk-ant-xxxxexport OPENAI_API_KEY=sk-xxxx # 3. 验证安装swe-agent run --help
快速上手：10 分钟跑通第一个 Issue 修复
最小可用流程只需要一条 swe-agent run 命令：指定模型、指定仓库、指定问题描述，agent 就会自主完成「分析 → 改码 → 测试 → 产出补丁」的全流程。仓库参数既支持 GitHub 的 git 地址，也支持本地目录；问题描述直接写在 --problem_statement 参数里，简明扼要地说明缺陷现象即可，不需要给出修复方案——定位和修复是 agent 自己的工作。
操作步骤如下：
1. 设置模型环境变量（见上文安装节），任选一个你已有 API 额度的服务商。
2. 执行 swe-agent run，按上表传入 --model、--repo、--problem_statement 三个核心参数。
3. 运行期间 agent 会依次输出「思考 → 调用命令 → 观察结果」的循环，可实时查看它浏览了哪些文件、改了什么、测试是否通过。
4. 运行结束后，在默认输出目录（~/.swe-agent/ 下以时间戳命名的目录）中查看产物：.patch 文件是最终的代码补丁，.trajectory 文件是完整执行轨迹。
5. 使用 swe-agent deploy --path <输出目录> 将补丁应用到干净仓库副本，生成标准化的 diff，供评审或直接提交 PR。
进阶技巧：--model 参数使用「提供商/模型名」格式（如 anthropic/claude-sonnet-4-20250514、openai/gpt-4o），切换不同模型会显著影响解决率与成本；把 swe-agent run 包进 CI 或定时任务，即可把「人工提 issue → 人工修」升级为「issue 自动触发 → 自动产出 draft PR」。
# 示例：让 SWE-agent 修复 test-repo 仓库中的一个 issueswe-agent run \ --model openai/gpt-4o \ --repo "https://github.com/SWE-agent/test-repo" \ --problem_statement "The greeting function in greet.py crashes when passed an empty string. Fix it to return a default greeting instead of raising an error." # 完成后查看 ~/.swe-agent/ 下最新输出目录，将补丁应用到仓库：swe-agent deploy --path ~/.swe-agent/<运行时间戳目录>
核心能力详解：5 大支柱
支柱一：Agent-Computer Interface（ACI）设计思想。ACI 是 SWE-agent 论文提出的核心概念，指「为 LLM 使用而专门设计的计算机工具界面」。论文的实验结论是：模型在通用 shell 中导航代码库的成功率很低，而把文件查看、搜索、编辑封装成高信号密度的专用工具后，解决率显著提升。v1.0 之前的版本直接基于这一抽象层构建；v1.0 重写后，这一思想的载体从「定制接口」转变为「受限但高效的原生 bash 环境 + 精选脚本」，核心理念不变：交互界面的设计质量，直接决定 agent 任务完成度。
支柱二：与 SWE-bench 评测体系同源。SWE-bench 是普林斯顿团队同期发布、目前学术界与工业界事实标准级的软件工程评测基准（从真实 GitHub 仓库的 issue 与修复 PR 中构造任务，要求 agent 产出能通过隐藏测试的补丁）。SWE-agent 既是 SWE-bench 的「考生」，也是为这类任务优化的「考生框架」，二者共享数据生态与评测脚本，这让 SWE-agent 的每一次版本迭代都有可量化的进步曲线（详见「版本迭代与评测对比」一节），这是多数同类工具不具备的资产。
支柱三：多模型、多提供商接入。通过 LiteLLM 网关，SWE-agent 不绑定任何单一厂商：OpenAI 的 GPT 系列、Anthropic 的 Claude 系列、本地通过 vLLM 或 Ollama 部署的开源模型均可作为推理后端。这使团队可以在「API 成本」与「解决率」之间自由调优，也可以在公司内网用私有化模型跑完整流水线，满足数据合规要求。
支柱四：可配置工具与可扩展流水线。v1.x 提供配置文件驱动的工作流定制：工具集、模型参数、提示词（prompt，即给模型的指令模板）、执行步骤均可通过配置调整。官方提供多套针对不同模型调优的默认配置，用户也可以注册自定义工具或后处理 hook（钩子，在特定流程节点自动执行的逻辑），把「跑测试」「打日志」「发通知」等动作接入既有工程体系。
支柱五：可复现实验与轨迹回放。每次运行都会落盘完整的 trajectory（执行轨迹）——模型每一步的输入、输出、命令结果全部结构化记录，可回放、可审计、可统计分析。配合固定的容器镜像，同一 issue 可在不同模型、不同配置间横向对比，是评测模型编程能力、排查 agent 失败原因的基础设施级能力。
生产部署与监控：从上线到运维
部署方式一：Docker 沙箱隔离执行。生产环境建议为每个任务启动独立容器，隔离文件系统与依赖，避免 agent 的改动污染宿主机。仓库的构建依赖（编译工具、系统库）需提前固化进自定义镜像，官方默认镜像只覆盖通用场景，复杂 repo 需要在 Dockerfile 中预装项目依赖。SWE-bench 的标准评测模式（镜像 + 任务集）可直接复用到企业内部仓库。
部署方式二：多 Worker 并行批量运行。SWE-agent 的定位是批处理而非交互，天然适合横向扩展：以脚本或任务队列的方式并发启动多个 swe-agent run 进程，每个任务独立容器、独立输出目录。可以按 issue 优先级排队，也可以对接定时触发。官方提供的批量评测模式支持一次提交整个任务集合，便于定期回归评测「当前模型在历史 bug 集上的解决率」。
可观测性。swe-agent run 默认输出推理日志，可通过 --log_level 调至 DEBUG 查看每一步工具调用的完整输入输出。生产监控建议关注三类指标：① trajectory 完整性——是否正常落盘，用于失败复盘；② 单任务 token 消耗与费用——不同模型成本差异可达数倍，需设预算上限；③ 解决率回归——定期用固定 issue 集（或 SWE-bench 子集）跑分，防止模型或配置变更导致能力倒退。
<p class=“para-label“>避坑清单：</p><ul class=”dash-list”><li>版本混淆：v1.0 是完全重写版本，网上大量 v0.x 教程（涉及 --env_file 参数、老配置格式、ACI 工具名）在 v1.x 上直接报错，查资料务必以官方文档「latest」为准。</li><li>容器环境缺依赖：默认 Docker 镜像不含目标仓库的构建依赖，直接跑复杂项目会卡在「无法编译/无法跑测试」，需预先定制含依赖的镜像并测试。</li><li>补丁必须人工审查：agent 可能「修好测试但破坏功能」或钻评测空子，自动合并前必须有工程师评审 diff，生产环境切勿无人值守全自动合入。</li></ul>
| 维度 | SWE-agent | OpenHands | Aider | AutoCodeRover |
|---|---|---|---|---|
| 定位 | 自主软件工程 Agent：批量解决 issue 产出补丁 | 通用软件工程 Agent 框架：交互 + 自主双模式 | 终端结对编程助手：对话驱动代码编辑 | 程序分析驱动的自动程序修复（学术导向） |
| 编排范式 | 为 LLM 定制工具界面，v1 回归原生 bash 补丁系统，离线批处理 | 事件流架构 + 通用 bash/IPython 工具，交互式沙箱 | Repo Map + 增量 diff 编辑，会话内实时应用修改 | AST 符号搜索 + 代码库分析引导 agent 定位 |
| 类型约束 | 强约束：GitHub issue → patch 的标准流水线 | 弱约束：通用软件工程任务均可编排 | 弱约束：任意仓库的逐行编辑 | 强约束：面向 bug 定位与修复场景 |
| 学习曲线 | 中等：CLI 参数多但有默认配置与官方示例 | 中等：有 GUI 界面，API 使用需读文档 | 较低：单条命令启动，git 流程透明 | 中等：以脚本与配置文件驱动 |
| 生态集成 | 与 SWE-bench 评测深度绑定，支持 Docker 沙箱 | 插件体系、Docker/云端部署、Headless 模式 | 深度集成 git 工作流，支持多编辑器 | 与 SWE-bench 评测绑定，无 UI |
| 生产部署 | Docker 隔离 + 多 worker 并行 + 轨迹落盘 | Docker 沙箱 + 云部署 + 事件日志 | 本地 CLI 运行，无沙箱隔离 | 本地批量脚本运行，无沙箱 |
| License | MIT | MIT | Apache-2.0 | MIT |
| 适合谁 | 建自动修 bug 流水线、跑模型编程能力评测的团队 | 需要通用任务编排与可视化调试的工程团队 | 日常开发中想要 AI 结对编程的个体工程师 | 做程序分析研究、复现学术实验的研究者 |
选型建议：目标是「稳定产出可评审补丁、接 CI 批量处理 issue」，选 SWE-agent，它的测评同源与批处理定位最贴合；需要交互式调试复杂任务、看 agent 逐步操作，选 OpenHands；个人日常写代码要最快上手、紧跟 git 流程，选 Aider；做学术研究或专注「缺陷定位 + 修复」的算法对比，选 AutoCodeRover。
版本迭代
SWE-agent 的演进主线是从「学术原型」走向「工程化产品」。v0.x 系列验证了 ACI 思想并逐步补齐 Web 界面、配置系统等工程能力；v1.0 是一次彻底的重写，方向性地从「定制接口」转向「原生 bash + 补丁系统」，并拆分 run/deploy 阶段；v1.1 继续打磨安装与运行体验。截至训练数据（2025-05），可能已有更新版本。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v0.1.0 | 2024-04 | 与 NeurIPS 论文同步开源初版 | 提出 ACI 概念；支持 GPT-4 经定制命令集解决 SWE-bench 任务 |
| v0.7.0 | 2024-10 | 配置系统与 Web 界面 | 引入新版配置模型（ConfigModel）、Web 界面启动入口、工具集可插拔 |
| v0.8.0 | 2024-12 | 界面抽象重构 | 统一 Human-Web-Computer（HWC）抽象；官方公开 SWE-bench Verified 40% 成绩 |
| v1.0.0 | 2025-03 | 完全重写（破坏性升级） | 移除 ACI 层改用原生 bash 补丁系统；run/deploy 流程分离；配置与命令行全面更新 |
| v1.1.0 | 2025-05 | 安装与稳定性优化 | 简化安装流程、改进容器镜像加载与批量运行稳定性 |
| 基准 | v0.1.0 | v0.8.0 | v1.1.0 | |
|---|---|---|---|---|
| SWE-bench Lite（GPT-4 Turbo） | 12.5% | — | — | 论文原始报告的开发集解决率 |
| SWE-bench Full（GPT-4 Turbo） | 10.4% | — | — | 论文原始报告的完整集解决率 |
| SWE-bench Verified（Claude 3.5 Sonnet） | — | 40% | — | 2024-12 官方技术博客公布的成绩 |
解决率随「模型能力 + agent 设计」双轮驱动快速上升——同一定位下，从论文时期的 12.5%（GPT-4 Turbo）到官方公布的 Verified 40%（Claude 3.5 Sonnet），主要增量来自模型换代与配置调优。选型建议：新项目直接用 v1.x；v1.0 起 run/deploy 分离让流水线集成更规范，v0.x 时代的配置与命令不应再参考。
AI 应用场景
开源仓库 Issue 自动化分流与补丁预生成
阶段：RAG 管道构建 / Agent 编排
解决的问题：开源维护者每天面对大量 issue，逐个复现、定位、修复耗时巨大。SWE-agent 接到新 issue 后自主浏览代码、定位疑似缺陷、修改并跑测试，产出的补丁以 draft PR 形式提交，维护者只需评审 diff 而非从零排查。官方在 SWE-bench Verified 上公布的最高配置解决率约 40%，意味着相当比例的缺陷报告可被自动转化为可评审补丁。
具体案例：仓库维护者配置 CI 工作流，新 issue 触发 swe-agent run 自动尝试修复；能稳定产出补丁的任务自动开 draft PR，无法完成的自动打标签转人工。修复流程从「维护者手动复现定位」变为「agent 出草稿 + 维护者审码」，单 issue 的人工投入从小时级降至分钟级。
企业内部缺陷修复流水线
阶段：Agent 编排
解决的问题：企业内部仓库通常涉及私有依赖与合规要求，无法直接把代码交到外部对话工具。SWE-agent 支持本地部署模型（vLLM/Ollama）与自定义 Docker 镜像，可在内网闭环运行：工单系统（如 Jira）同步 issue 描述给 agent，agent 在预置依赖的容器中自主修复，产出补丁进入人工评审流。
具体案例：某后端团队把历史高频缺陷按模块整理成回归任务集，每周用 SWE-agent 批量跑分，跟踪模型配置调整前后的解决率变化；新缺陷则进入按优先级排队的自动修复队列，工程师只保留代码审查与合入权限，缺陷修复的「根因定位」环节由 agent 承担。
模型编程能力评测与选型
阶段：RAG 管道构建
解决的问题：团队采购或自研 LLM 时，「能不能真的改好代码」需要可复现的量化指标。SWE-agent 与 SWE-bench 同源，天然适合作为「模型编程能力」的标准化评测载体：固定 agent 配置，替换模型，对比同一任务集上的解决率，即可得到横向可比的结果。
具体案例：参考公开数据，SWE-agent 论文阶段（GPT-4 Turbo）在 SWE-bench Lite 上解决率 12.5%，2024 年底官方配合 Claude 3.5 Sonnet 在 Verified 集达到 40%——这种同框架下的跨模型对比，正是选型团队需要的「控制变量」评测方式。
常见误区
误区「装上 SWE-agent 就能全自动修好所有 issue，挂个机器人就不用管了。」
正解最高配置在 SWE-bench Verified 上的解决率约 40%，意味着超过半数 issue 无法独立解决——包括无法复现的、跨模块强依赖的、需要外部交互的缺陷。SWE-agent 的定位是「自动化补丁草稿生成器」，产出必须经人工评审，绝不能视为无人值守的自动修复机器人。
为何常见：官方 demo 与论文展示的都是成功案例，用户容易以点概面忽略失败面与人工审查环节。
误区「这是 OpenAI 出的工具吧？没用 OpenAI 的 key 就跑不了。」
正解SWE-agent 通过 LiteLLM 网关统一接入多个模型厂商，Anthropic Claude 系列、OpenAI GPT 系列、本地 vLLM 与 Ollama 部署的开源模型均可作为推理后端。模型选择只是 --model 参数的一个值，且多数官方默认示例使用 Claude 型号。
为何常见：早期论文实验以 GPT-4 为主，加上 OpenAI 生态宣传声量大，容易让人误以为存在绑定关系。
误区「搜到一篇 SWE-agent 教程，照着敲 `--env_file` 命令怎么一直报错？」
正解v1.0 是对代码库的完全重写：命令结构（run/deploy 分离）、配置体系、模型参数格式全部变更，v0.x 时期的教程、配置文件与自定义工具写法在 v1.x 上基本不可用。查资料时务必以官方文档的 latest 版本为准，并检查文章标注的版本号。
为何常见：SWE-agent 早期热度高、教程多，搜索引擎优先展示旧内容，而项目本身经历了破坏性升级。
误区「下载下来应该像 Cursor 一样，我边写代码它边给建议。」
正解SWE-agent 是离线批处理框架：输入「仓库 + issue 描述」，输出「补丁文件 + 执行轨迹」，全程无实时对话、无 IDE 插件界面。它的使用方式是跑完整流程后审阅产物，适合流水线集成与批量评测，而非结对编程。
为何常见：工具被归入「AI 编程」大类，用户自然按交互式助手的交互习惯去期待，忽略了其批处理定位。
面试题
Q1. SWE-agent 由哪个机构的研究团队开发并开源？
- A.普林斯顿大学← 正确答案
- B.斯坦福大学
- C.清华大学
- D.加州伯克利
答案：A。SWE-agent 由 Princeton University 的 NLP 团队（Princeton NLP）开发并开源，其官方 GitHub 仓库由该团队维护。同时，其同源的 SWE-bench 评测基准也由同一团队发布。斯坦福、清华、伯克利均无此项目的发布记录。
Q2. 安装 SWE-agent 的正确命令是？
- A.pip install swe-agent← 正确答案
- B.conda install agent
- C.npm install swe-agent
- D.apt install swe-agent
答案：A。SWE-agent 以 Python 包形式发布在 PyPI 上，包名为 swe-agent，官方文档推荐的安装方式是 pip install swe-agent（要求 Python 3.9+）。conda 包管理的包名不叫 agent，npm 是 Node.js 生态的包管理器，apt 是系统级包管理器，均非官方安装途径。
Q3. SWE-agent 的核心任务是解决以下哪类问题？
- A.修复 GitHub Issue 并产出补丁← 正确答案
- B.生成代码文档
- C.训练基础模型
- D.管理云服务器集群
答案：A。SWE-agent 的定位是自主软件工程 agent，输入是 GitHub 仓库与 issue 描述，输出是经过定位、修改、测试的补丁（patch）文件。生成文档、训练模型、管理服务器均不在其能力边界内，这些任务也有各自专业的工具。
Q4. v1.0 版本相对 v0.x 系列最核心的架构变化是？
- A.原生 bash 取代 ACI 定制界面← 正确答案
- B.新增网页图形化界面
- C.移除离线批处理 CLI 模式
- D.项目更名并且闭源发行
答案：A。v1.0 是完全重写版本，最大的变化是移除 v0.x 时代的 ACI（Agent-Computer Interface）抽象层，改用原生 bash 环境 + 补丁系统，同时将 run 与 deploy 流程分离。它未改名、未闭源，且仍以 CLI 批处理为主要使用方式，网页界面是辅助而非核心变化。
Q5. SWE-agent 与 SWE-bench 的关系是？
- A.同源团队发布的评测基准← 正确答案
- B.前身机构改名而来
- C.完全无关的两个独立项目
- D.商用的私有数据集
答案：A。SWE-agent 与 SWE-bench 均出自 Princeton NLP 团队：SWE-bench 定义评测任务（从真实 PR 构造的 issue + 测试集），SWE-agent 是面向这类任务优化的 agent 框架，二者共享数据生态与工具链。SWE-bench 是公开基准，并非商用私有数据。
Q6. SWE-agent 执行测试等命令时，默认的隔离运行环境是？
- A.Docker 容器沙箱← 正确答案
- B.裸机直接执行
- C.虚拟机快照
- D.远程物理服务器集群
答案：A。SWE-agent 默认在 Docker 容器内执行测试等命令，以隔离文件系统与依赖、避免污染宿主机。裸机直接执行存在污染风险，虚拟机快照与远程物理服务器集群均非官方默认机制。
Q7. v1.x 中 swe-agent run 与 swe-agent deploy 的分工是？
- A.run 产出补丁，deploy 应用补丁← 正确答案
- B.run 部署模型，deploy 训练数据
- C.两者功能完全一致可互换
- D.deploy 用于生成问题描述
答案：A。v1.0 起将「开发」与「部署」分离：swe-agent run 负责读 issue、改代码、跑测试并产出补丁文件；swe-agent deploy 负责把补丁应用到干净的仓库副本，生成标准化 diff 供评审合入。二者职责不可互换，也不涉及模型部署或问题描述生成。
Q8. SWE-agent 支持以下哪些模型接入方式？
- A.Anthropic 与 OpenAI 的 API 模型← 正确答案
- B.本地 vLLM 与 Ollama 部署模型← 正确答案
- C.仅支持 GitHub Copilot 专有接口
- D.仅支持 OpenAI 自家模型
答案：AB。SWE-agent 通过 LiteLLM 网关统一接入多家模型服务，既支持 Anthropic/OpenAI 等云端 API，也支持通过 vLLM、Ollama 部署的本地模型，便于内网与合规场景使用。它不绑定 Copilot 专有接口，也不只支持 OpenAI 一家。
Q9. 将 SWE-agent 用于生产环境时，下列哪些做法是正确的？
- A.Docker 容器沙箱隔离执行← 正确答案
- B.trajectory 轨迹日志落盘回放← 正确答案
- C.多 worker 并发批量运行← 正确答案
- D.依赖 GPU 大规模训练模型
答案：ABC。生产部署三要素是：容器隔离（Docker 沙箱保证环境一致性）、可观测（trajectory 落盘用于审计与失败复盘）、可扩展（多 worker 并发处理批量 issue）。SWE-agent 是推理侧 agent 框架，依赖外部模型 API，本身不承担模型训练职责。
Q10. 关于 SWE-bench 数据集的构造，以下描述正确的是？
- A.从真实 GitHub PR 提取 issue 与测试← 正确答案
- B.由算法随机生成合成缺陷
- C.仅挑选文档类简单任务
- D.全部由人工标注生产环境
答案：A。SWE-bench 的数据来自真实 GitHub 仓库中已修复的 PR：从 PR 关联的 issue 提取问题描述，从 PR 本身提取测试与修复补丁，模型需产出能通过隐藏测试的补丁。它不含随机生成的合成缺陷，也剔除了纯文档类任务；数据是自动化构造 + 人工审核校验，而非纯人工标注。
参考来源
- webpageSWE-agent GitHub 仓库源码、Issue 跟踪与 Release 记录
- webpageSWE-bench 官网评测基准说明与 Leaderboard
- webpageSWE-bench GitHub 仓库数据集构造与评测工具
- webpage官方 X 账号 @SWEagent版本动态与研究成果发布