BeyondSWE: Can Current Code Agent Survive Beyond Single-Repo Bug Fixing?

Paper: arXiv:2603.03194 Code: AweAI-Team/BeyondSWE Code reference: main @ e4ce16e2 (2026-05-15)

1. Motivation (研究动机)

当前 code-agent benchmark 的核心问题是：它们主要验证“在单个目标仓库里修一个局部 bug”的能力，而真实软件工程经常不是这种闭卷题。SWE-bench Verified / Live / Pro 这类任务通常给定一个仓库、一个 issue 和一组测试，agent 的主要挑战是定位本仓库里的修改点；但真实维护任务往往还要求理解外部仓库的行为、领域知识、依赖升级文档，甚至从规格说明直接搭建一个新仓库。

BeyondSWE 要解决的具体目标是：把 code agent evaluation 从 single-repo localized bug fixing 扩展到两个维度。第一是 knowledge scope：解题信息是否只在目标仓库里，还是需要 cross-repo artifacts、domain knowledge、official docs 或 human spec。第二是 resolution scope：最终修改是局部函数修复，还是 repository-wide migration，甚至 full repository construction。这个设计让 benchmark 不只是“更难的 SWE-bench”，而是把实际软件工程里被低估的外部知识整合、全局一致性修改、从文档生成代码等能力显式拆出来。

这件事值得研究，因为当前 frontier code agents 在 SWE-bench-style 任务上已经很强，但这不能保证它们能做真实工程维护。论文显示 BeyondSWE 的 500 个实例来自 246 个真实 GitHub repositories，平均每个目标解影响 10.9 个文件和 1039.6 行；相比 SWE-bench Verified 的 1.3 个文件 / 11.6 行，任务粒度明显更接近真实项目维护。即使最强 OpenHands-based agent 也只有 46.12 AVG，Codex harness + GPT-5.4 (xhigh) 在 SearchSWE prompt 下达到 56.65 AVG，仍远未饱和。

2. Idea (核心思想)

核心洞察是：code-agent 能力不能只用“目标仓库内定位 + patch”衡量，而应同时测 外部知识能否被可靠转化为本地代码修改 和 修改范围能否从局部扩展到仓库级/仓库生成级。BeyondSWE 因此不是单一任务，而是一个由 CrossRepo、DomainFix、DepMigrate、Doc2Repo 组成的能力矩阵。

关键创新有两层。第一，benchmark construction 把每个实例都绑定到 Docker environment、P2P/F2P 或 Doc2Repo test suite，使 broader SWE tasks 仍然可以 executable evaluation。第二，论文额外构造 SearchSWE 作为 controlled diagnostic baseline：在保持本地 coding workflow 的同时给 agent web search / browser-fetch 能力，并用 blocklist 防止直接检索 gold issue/PR，从而测试“搜索可用”是否真的能转化为“代码修对”。

与 SWE-bench Verified 的根本区别是，SWE-bench 的默认假设更接近 closed-book single-repo repair；BeyondSWE 则故意让部分必要信息落在目标仓库之外，或让修复需要跨很多文件保持一致。与简单的 web-enabled coding agent evaluation 也不同，SearchSWE 的目的不是提出一个全新 agent architecture，而是诊断 current agents 在 search-to-code pipeline 上的断点：证据粒度、版本约束、语义过滤和本地验证。

3. Method (方法)

3.1 总体框架：二维能力矩阵 + 可执行验证

Figure 1 解读：图 1 把 BeyondSWE 放在两个维度上：knowledge scope 从 within-repo 扩到 cross-repo / domain / docs / spec，resolution scope 从 local function fix 扩到 repository-wide transformation 和 full repository construction。CrossRepo 与 DomainFix 主要扩展知识范围，DepMigrate 与 Doc2Repo 主要扩展修改范围；四类任务合起来覆盖了论文想测的“超出单仓局部修 bug”的核心能力。

每个 BeyondSWE instance 都包含三个部分：problem statement、Docker environment、test suite。CrossRepo / DomainFix / DepMigrate 沿用 issue-resolution 格式，并使用 SWE-bench-style 的 pass-to-pass (P2P) 与 fail-to-pass (F2P) 测试；Doc2Repo 从空 workspace 开始，由自然语言规格说明定义 API 和行为，最终用完整 test suite 的通过率评价生成仓库是否满足规格。

3.2 四个任务族

CrossRepo：跨仓库 issue resolution

CrossRepo 保留局部修复格式，但要求 agent 查阅外部仓库、linked artifacts 或 upstream discussion。构造时作者扫描 Python-dominant GitHub repositories 中带外部链接的 merged PR，得到约 3,000 个 candidates；环境构造和稳定性过滤后剩约 800 个；人工验证外部链接是否真的与 issue 相关、问题陈述是否保留任务上下文且不泄漏 solution，最终得到 200 issues / 67 repositories，平均每个 issue 1.3 个外部链接。

DomainFix：领域知识驱动的 issue resolution

DomainFix 测试 agent 是否能把 code reasoning 与 scientific / engineering domain knowledge 结合起来。目标项目来自 11 个研究领域，包括 astronomy、bioinformatics、computational chemistry、plasma physics、quantum physics、seismology、convex optimization、geospatial、materials science、molecular dynamics、photonic IC design。作者与领域专家筛选 21 个高质量 repositories，收集约 800 个 candidate PR；环境构造后约 200 个通过稳定性检查，每个剩余实例由 3 位领域专家独立审核，只有一致接受的实例保留，最终 72 issues / 12 repositories。

DepMigrate：依赖升级导致的仓库级迁移

DepMigrate 关注 breaking upstream dependency change 下的全仓库协调修改。agent 需要理解上游 API 变化、找到所有受影响 call sites、保持代码库一致。作者识别 23 个广泛使用且有显著升级的 packages，收集 PR 描述或 commit message 中提到这些 packages 与版本号的迁移任务；LLM filtering 后约 7,000 个 candidates，环境稳定性检查后约 1,000 个，4 位软件工程专家验证 migration validity，最终 178 issues / 120 repositories。每个实例在环境中安装升级后的依赖，但仓库代码 checkout 到 migration patch 之前，因此 agent 必须主动适配新依赖行为。

Doc2Repo：从自然语言文档生成完整仓库

Doc2Repo 不再是修复已有代码，而是从规格说明构建 functional repository。作者收集 2025 年 1–11 月创建、8 月之后仍活跃、至少 3 contributors、超过 20 stars 的 Python repos；Gemini 3 Pro 探索原仓库并生成 spec，覆盖目的、usage examples、public classes / functions、参数、返回类型和行为，同时移除实现细节与目录结构。仓库名被 mask 为 target_repo，agent 需要从 import paths 等上下文推断结构。测试由原仓库 tests 经过 LLM assistance 与人工审核改写，环境构造后剩 60 candidates，最终选 50 high-quality instances。

3.3 环境构造与验证协议

Figure 2 解读：图 2 展示了从候选采集到 Docker 环境构造再到稳定性检查的 pipeline。关键点不是简单下载仓库，而是 agent-assisted Docker construction：从 Ubuntu base container 开始，clone repo、checkout pre-PR commit、迭代安装缺失包/编译器/系统库，直到测试可运行；之后把成功命令历史蒸馏成 reproducible Dockerfile。

环境验证比普通 benchmark 更严格。CrossRepo / DomainFix / DepMigrate 要求 reference patch 前 P2P 通过、F2P 失败；reference patch 后 P2P 与 F2P 都通过；该过程重复运行 5 次以排除 flaky behavior。Doc2Repo 则把 adapted test suite 跑在 reference implementation 上，并人工审查那些比原仓库更严格的测试要求是否已经写入 instance metadata。

最终评估时，agent 在自己的 Docker workspace 中工作并输出 patch 或 generated repo；评分阶段会把改动抽取出来，应用到独立 fresh container。这避免了 agent workspace 中的 cache、环境副作用或本地配置污染最终分数。论文还会移除 target commit 之后的 git commits / logs / metadata，并在验证前恢复 test files，防止 agent 通过改测试或偷看未来历史作弊。

3.4 SearchSWE：受控的 search-augmented coding baseline

Figure 3 解读：图 3 把 SearchSWE 分成两个阶段：Phase 1 在本地 Docker context 中进行 coding，同时允许 Search Tool / Browser Tool 获取外部信息；Phase 2 把 proposed patch 放到 fresh Docker container 中运行 test suite。图中的 blocklist 是关键：它阻止 agent 直接访问 target repository 的 solution-revealing GitHub/GitLab/raw/API/git artifacts，使 search 只能提供间接证据，而不是直接复制 gold PR。

SearchSWE 的直觉是：真实开发者会查文档、上游讨论和相似实现，但查到信息之后仍要把它约束到本仓库的版本、测试和架构里。单纯“能搜索”并不等价于“能做 search-grounded coding”；agent 必须判断什么时候搜索、搜什么、读哪个结果、如何把证据翻译成本地 patch，并用测试验证。因此 SearchSWE deliberately simple：它不是检索模块优化论文，而是一个诊断工具，用来暴露 current agents 在 evidence retrieval、version grounding、semantic filtering、local verification 中哪一步断裂。

论文公式与 released code 实现差异：论文与 README 描述 SearchSWE 为 SearchTool + BrowserTool，并说明 browser tool 使用 Jina Reader 抽取网页内容；AweAgent main@bd178143 的 SearchSWEAgent 实际在 enable_search=True 时添加 SearchTool 与 LinkSummaryTool。这更像“读取并总结链接”的工具命名差异，而不是评估语义差异；note 中的 pseudocode 以 released AweAgent 代码为准。

3.5 评分公式与指标

CrossRepo、DomainFix、DepMigrate 使用 Resolved Rate： $ResolvedRate = \frac{# { i : P2P _{i} \land F2P _{i} all pass in fresh container }}{N} \times 100%.$ Doc2Repo 使用 Pass Rate 与 (Almost) Correct Count： $PassRate = \frac{# passed tests}{# expected tests}, AlmostCorrect = # {repos with pass rate \geq 90%} .$ 论文的 AVG 是四个 task-level scores 的均值，其中 Doc2Repo 用 pass rate 作为任务分数： $AVG = \frac{S _{CrossRepo} + S _{DomainFix} + S _{DepMigrate} + S _{Doc2Repo}}{4} .$ SearchSWE 的 paired gain 可写为： $Δ_{m, t} = S_{m, t}^{SearchSWE} - S_{m, t}^{OpenHands},$ 其中 $m$ 是 model， $t$ 是 task family。Figure 4 的 improved / tied / regressed 统计就是在这些 matched model-task comparisons 上聚合。

3.6 Released code-grounded pseudocode

3.6.1 SearchSWE agent tool assembly

def build_searchswe_tools(enable_search, search_constraints, yaml_blocklist):
    always_blocked = [
        r".*git log.*--all.*",
        r".*git verify-pack.*",
        r".*git fsck.*",
        r".*git cat-file.*",
        r".*git fetch.*",
        r".*git pull.*",
    ]
    non_search_blocked = [
        r".*git clone.*",
        r".*api\.github\.com.*",
        r".*github\.io.*",
        r".*githubusercontent.*",
    ]
 
    blocklist = list(always_blocked)
    if not enable_search:
        blocklist += non_search_blocked
    blocklist += dedupe(yaml_blocklist)
    if search_constraints is not None:
        blocklist += search_constraints.get_bash_blocklist_patterns()
 
    tools = [
        ExecuteBashTool(timeout=1200, blocklist=blocklist),
        StrReplaceEditorTool(),
        ThinkTool(),
    ]
    if enable_search:
        tools += [
            SearchTool(constraints=search_constraints),
            LinkSummaryTool(constraints=search_constraints),
        ]
    tools.append(FinishTool())
    return tools

3.6.2 Repo-specific anti-cheating constraints

def constraints_from_repo(owner_repo: str):
    owner, repo = owner_repo.split("/", 1)
    escaped_owner, escaped_repo = re.escape(owner), re.escape(repo)
    blocked_url_patterns = [
        rf".*github\.com/{escaped_owner}/{escaped_repo}(/|$|\?).*",
        rf".*gitlab\.com/{escaped_owner}/{escaped_repo}(/|$|\?).*",
        rf".*raw\.githubusercontent\.com/.*/{escaped_repo}/.*",
    ]
    return SearchConstraints(blocked_patterns={"url": blocked_url_patterns})
 
 
def filter_results(results, constraints):
    kept = []
    for result in results:
        blocked = any(
            re.match(pattern, result.get(field, ""), re.IGNORECASE)
            for field, patterns in constraints.blocked_patterns.items()
            for pattern in patterns
        )
        if not blocked:
            kept.append(result)
    return kept

3.6.3 BeyondSWE instance loading and prompt filling

def to_beyondswe_instance(raw, test_suite_dir):
    task_type = normalize_task_type(raw.get("task", "domainfix"))
    base_commit = (
        raw.get("base_commit")
        or raw.get("pre_agent_commit_id")
        or raw.get("parent_commit")
        or raw.get("base", {}).get("sha", "")
    )
    return Instance(
        id=raw["instance_id"],
        repo=raw.get("repo", ""),
        base_commit=base_commit,
        workdir=raw.get("workdir", "/workspace"),
        problem_statement=raw.get("problem_statement", ""),
        gold_patch=raw.get("patch", raw.get("fix_patch", "")),
        metadata={
            "task_type": task_type,
            "FAIL_TO_PASS": raw.get("FAIL_TO_PASS", ""),
            "PASS_TO_PASS": raw.get("PASS_TO_PASS", ""),
            "REPO_DOCUMENT_CONTENT": raw.get("REPO_DOCUMENT_CONTENT", ""),
            "f2p_patch": raw.get("f2p_patch", ""),
            "f2p_script": raw.get("f2p_script", ""),
            "test_suite": raw.get("test_suite", ""),
            "test_suite_path": test_suite_dir,
            "test_suite_num": raw.get("test_suite_num", 0),
        },
    )

3.6.4 Evaluation for issue-resolution tasks and Doc2Repo

async def eval_issue_resolution(instance, session):
    workdir = instance.workdir
    if instance.metadata["f2p_patch"]:
        ok = await session.apply_patch(workdir, instance.metadata["f2p_patch"])
        if not ok.success:
            return EvalResult(accepted=False, score=0.0, details={"error": "f2p_patch_failed"})
 
    if instance.metadata["f2p_script"]:
        await session.upload_file(f"{workdir}/test_fail_to_pass.py", instance.metadata["f2p_script"].encode())
 
    f2p = parse_test_ids(instance.metadata["FAIL_TO_PASS"])
    p2p = parse_test_ids(instance.metadata["PASS_TO_PASS"])
    all_passed, raw_output, details = await run_tests_with_runner(session, workdir, f2p + p2p)
    return EvalResult(accepted=all_passed, score=1.0 if all_passed else 0.0, details=details)
 
 
async def eval_doc2repo(instance, session):
    workdir = instance.workdir
    await session.execute("pip install -e .", cwd=workdir, timeout=300)
    zip_bytes = Path(instance.metadata["test_suite_path"], instance.metadata["test_suite"]).read_bytes()
    await session.upload_file("/tmp/_awe_test_suite.zip", zip_bytes)
    await session.execute("unzip -o /tmp/_awe_test_suite.zip", cwd=workdir, timeout=600)
    result = await session.execute("python realswe_eval_script.py", cwd=workdir)
 
    all_passed = "<pytest>true</pytest>" in result.output
    summary = parse_pytest_summary(result.output)
    total = instance.metadata["test_suite_num"] or summary.total_run
    pass_rate = summary.passed / total if total > 0 else 0.0
    return EvalResult(accepted=all_passed, score=1.0 if all_passed else pass_rate)

3.7 Code-to-paper mapping

Code reference: main @ e4ce16e2 (2026-05-15); SearchSWE implementation AweAgent/main @ bd178143 (2026-03-16) — pseudocode and mapping based on these commits

Paper Concept	Source File	Key Class/Function
Official benchmark release, dataset links, leaderboard/project links	`AweAI-Team/BeyondSWE/README.md`	Hugging Face dataset links, Harbor data format, trajectory release notes
SearchSWE scaffold and tool selection	`AweAgent/awe_agent/scaffold/search_swe/agent.py`	`SearchSWEAgent`, effective blocklist construction, `get_tools`
Search result filtering and target-repo blocklist	`AweAgent/awe_agent/core/tool/search/constraints.py`	`SearchConstraints.from_repo`, `is_url_blocked`, `filter_search_results`, `get_bash_blocklist_patterns`
Web search tool	`AweAgent/awe_agent/core/tool/search/search_tool.py`	`SearchTool.execute`, `_search_single`, `_format_results`
URL/content reader used by released scaffold	`AweAgent/awe_agent/core/tool/search/link_reader_tool.py`, `link_summary_tool.py`	`LinkReaderTool.execute`, `LinkSummaryTool`
BeyondSWE JSONL to runtime instance	`AweAgent/awe_agent/tasks/beyond_swe/task.py`	`BeyondSWETask._to_instance`, `get_prompt`, `prepare_session`
BeyondSWE verification logic	`AweAgent/awe_agent/tasks/beyond_swe/evaluator.py`	`BeyondSWEEvaluator._eval_beyondswe`, `_eval_doc2repo`
SearchSWE runtime config	`AweAgent/configs/tasks/beyondswe_searchswe.yaml`	Docker backend, `max_steps=200`, `enable_search=true`, `bash_timeout=1200`, CPU/memory limits
Harbor evaluation route from official README	`AweAI-Team/BeyondSWE/README.md`	`harbor run --path data/beyondswe --agent claude-code ... --ak max_turns=200`

4. Experimental Setup (实验设置)

4.1 数据集规模

BeyondSWE 共 500 instances / 246 GitHub repositories，四个任务族如下：

Task	Resolution Scope	Knowledge Scope	Repos	Instances / average scale
CrossRepo	Local Function	Cross Repo	67	200 issues，平均 4.1 files / 190.7 lines
DomainFix	Local Function	Domain	12	72 issues，平均 4.2 files / 157.6 lines
DepMigrate	Global Repository	Official Docs	120	178 issues，平均 8.4 files / 281.6 lines
Doc2Repo	Global Repository	Human Spec	50	50 repos，平均 26.8 files / 3528.4 lines
BeyondSWE overall	Mix	Mix	246	500 instances，平均 10.9 files / 1039.6 lines

对照 benchmark：SWE-bench Verified 为 12 repos、平均 1.3 files / 11.6 lines；SWE-bench Live 为 223 repos、平均 2.7 files / 65.1 lines；SWE-bench Pro 为 41 repos、平均 4.1 files / 107.4 lines。BeyondSWE 的平均修改规模显著更大。

4.2 Baselines 与 agent settings

论文评估四类设置：OpenHands、SearchSWE、Codex default prompt、Codex with SearchSWE-style prompt。OpenHands 是标准 open-source code-agent scaffold；SearchSWE 保持本地 coding workflow，但增加 search / fetch 工具；Codex 使用 Codex harness v0.118.0，分别测 default coding prompt 与明确鼓励 search-aware workflow 的 prompt。

模型包括 GPT-5.4 (xhigh)、DeepSeek-V4-Pro(Max)、GLM-5、Qwen3.5-Plus、Gemini 3 Pro、GPT-5.4、Kimi-K2.5、Seed-Coder-2.0、MiniMax-M2.5；附录还报告 GLM-4.7、DeepSeek-V3.2、Kimi-K2、GPT-5.2、Seed-Coder-1.8、Qwen3-Coder-Plus、Qwen3-235BA22B 等。

4.3 Metrics

CrossRepo / DomainFix / DepMigrate 使用 %Resolved，即 fresh container 中所有 P2P 与 F2P 测试都通过的实例比例。Doc2Repo 使用 Pass Rate，即测试通过比例，并报告 #(Alm.) Corr.：括号内是 pass rate ≥ 90% 的 almost-correct repositories，斜杠后是 100% 通过的 fully correct repositories。AVG 为四个 task-level scores 的平均值。

4.4 运行与配置细节

论文附录 C.2 说明 OpenHands / SearchSWE 最大 interaction turns 为 200；OpenHands 工具为 ExecuteBashTool、StrReplaceEditorTool、FinishTool；SearchSWE 增加 SearchTool 与 BrowserTool，search 由 SerpAPI / Google Search 支撑，browser 内容抽取使用 Jina Reader，并用 DeepSeek-V3.2 做 summarization。released AweAgent config configs/tasks/beyondswe_searchswe.yaml 对应 Docker backend、timeout=14400、CPU 4、memory 8Gi、agent type=search_swe、max_steps=200、enable_search=true、bash_timeout=1200。Doc2Repo 在 released code 中还对 LLM 覆盖 max_completion_tokens=16384。

5. Experimental Results (实验结果)

5.1 Main results

Setting / Model	CrossRepo	DomainFix	DepMigrate	Doc2Repo Pass Rate	#(Alm.) Corr.	AVG
Codex GPT-5.4 (xhigh), SearchSWE Prompt	55.17 (+8.9)	61.11 (+19.4)	48.59 (+4.2)	61.74 (+0.1)	(7) / 2	56.65 (+8.2)
Codex GPT-5.4 (xhigh), Default Prompt	46.23	41.67	44.38	61.64	(7) / 2	48.48
OpenHands DeepSeek-V4-Pro(Max)	44.00	38.89	44.38	57.20	(5) / 1	46.12
OpenHands GLM-5	44.67	33.33	42.13	56.76	(7) / 3	44.22
OpenHands Qwen3.5-Plus	41.50	38.89	41.01	52.41	(3) / 1	43.45
SearchSWE DeepSeek-V4-Pro(Max)	48.50 (+4.5)	43.06 (+4.2)	47.19 (+2.8)	56.16 (-1.0)	(5) / 2	48.73 (+2.6)
SearchSWE GLM-5	43.88 (-0.8)	35.94 (+2.6)	47.13 (+5.0)	60.05 (+3.3)	(7) / 3	46.75 (+2.5)
SearchSWE GPT-5.4	45.00 (+2.0)	31.94 (+4.2)	38.76 (+1.3)	58.35 (+2.1)	(7) / 4	43.51 (+2.4)

最重要的结论是 benchmark 远未饱和。OpenHands scaffold 下最强模型 DeepSeek-V4-Pro(Max) 只有 46.12 AVG；Codex GPT-5.4 (xhigh) 默认 prompt 为 48.48；同一 Codex configuration 用 SearchSWE-style prompt 后达到 56.65，但仍离完全解决很远。Doc2Repo 尤其暴露“pass rate 不等于完整成功”：最强设置虽然 pass rate 61.74，但 50 个仓库里只有 2 个 fully correct。

5.2 Search 有帮助，但不是越搜越好

Figure 4 解读：图 4 聚合了 8 个 matched model pairs × 4 个任务族。整体 62.5% 比较项改善、6.2% 持平、31.2% 退化；DomainFix 改善比例最高，为 75.0%，符合它依赖外部领域知识的设定；CrossRepo、DepMigrate、Doc2Repo 仍有 37.5% 左右退化，说明 search access 本身并不保证修复质量。

Figure 5 解读：图 5 比较 Codex GPT-5.4 (xhigh) 默认 prompt 与 SearchSWE-style prompt 的平均工具调用。web_search 从 2.84 增到 8.01，约 2.82×，而 shell / editor / apply_patch 等本地 coding tools 保持相近。这支持论文判断：search 不是 self-activating 的能力，frontier harness 也需要明确 prompt 才会更积极地把外部信息纳入 coding workflow。

Figure 6a–6b 解读：图 6 对比 DomainFix 与 Doc2Repo 中 search calls 与 SearchSWE gain 的关系。DomainFix 上许多模型 gain 为正，但 Doc2Repo 聚集在小幅或负收益；同一任务内部，更多 search calls 并不单调带来更大提升。这说明瓶颈不是搜索次数，而是检索到的证据是否 relevant、version-compatible、locally actionable。

5.3 Cost / token budget 不是主要解释变量

Figure 7a–7b 解读：图 7 展示 API cost 与 average tokens per trajectory 相对 AVG 的 Pareto frontier。高成本并不稳定对应高分，一些较低成本配置仍在 frontier 附近；token 图中的 LOWESS trend 在低 token 区间上升，但到高 token 区间趋平甚至下降。论文据此认为，关键瓶颈是 token productivity，而不是单纯增加预算；许多高 token 运行把预算花在重复探索、噪声搜索或无效修补循环上。

5.4 Doc2Repo 规模与构造难度

Figure 8 解读：图 8 把 50 个 Doc2Repo 仓库按 Python code lines 分成三档：≤1500 行 19 个、1500–4000 行 16 个、≥4000 行 15 个。这说明 Doc2Repo 不是只生成玩具脚本，而包含相当数量的中等规模仓库。

Figure 9 解读：图 9 按代码行数排序显示每个 Doc2Repo repository 的规模，长尾仓库达到上万行级别。结合最终只有 2 个 fully correct repos 的结果，可以看出 current agents 在“从规格生成可测试项目结构、API 行为和边界条件”上仍主要停留在 partial functionality。

5.5 失败模式与限制

论文附录 B 总结了 search-augmented coding 的三个 recurring failure modes。第一，source-level evidence 很难检索：在 unidata_siphon_pr234 中，搜索返回 high-level documentation，但真正需要的是 backend source logic，agent 只实现了文档字面解释而漏掉边界情况。第二，retrieved knowledge 必须 version-grounded：在 behave_behave-django_pr162 中，agent 采用与本地 legacy Django 生命周期不兼容的新模式，把 _pre_setup 改成 @classmethod，破坏 instance-level state。第三，keyword matches 会污染上下文：在 abravalheri_validate-pyproject_pr105 中，“family / review”等词把搜索结果带到 Revit、RelativityOne 等无关领域，agent 最后套用了 generic plugin-registration prior，导致 plugin 被注册两次。

整体结论是：BeyondSWE 证明当前 code agents 已能在 broader SWE tasks 上取得部分进展，但还不能稳定完成需要外部证据、本地版本约束、仓库级一致性和执行验证的任务。SearchSWE 表明 search access 通常有用，尤其对 DomainFix，但收益不稳定；下一步更关键的是 source discrimination、version grounding、semantic filtering 与 verification-aware editing，而不是简单增加搜索次数、tokens 或成本。

Paper Notes

探索

BeyondSWE: Can Current Code Agent Survive Beyond Single-Repo Bug Fixing?

BeyondSWE: Can Current Code Agent Survive Beyond Single-Repo Bug Fixing?

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 总体框架：二维能力矩阵 + 可执行验证

3.2 四个任务族

CrossRepo：跨仓库 issue resolution

DomainFix：领域知识驱动的 issue resolution

DepMigrate：依赖升级导致的仓库级迁移

Doc2Repo：从自然语言文档生成完整仓库

3.3 环境构造与验证协议

3.4 SearchSWE：受控的 search-augmented coding baseline

3.5 评分公式与指标

3.6 Released code-grounded pseudocode

3.6.1 SearchSWE agent tool assembly

3.6.2 Repo-specific anti-cheating constraints

3.6.3 BeyondSWE instance loading and prompt filling

3.6.4 Evaluation for issue-resolution tasks and Doc2Repo

3.7 Code-to-paper mapping

4. Experimental Setup (实验设置)

4.1 数据集规模

4.2 Baselines 与 agent settings

4.3 Metrics

4.4 运行与配置细节

5. Experimental Results (实验结果)

5.1 Main results

5.2 Search 有帮助，但不是越搜越好

5.3 Cost / token budget 不是主要解释变量

5.4 Doc2Repo 规模与构造难度

5.5 失败模式与限制

目录