SWE-Touch基准：编码智能体如何应对动态代码变更？

最近在做代码智能体（Coding Agent）的评估体系调研时，我发现一个让人很头疼的现象：很多模型在静态基准测试里表现亮眼，一旦到了真实开发环境，尤其在用户中途改过代码、加过注释、重构过变量名之后，完成度就断崖式下降。这背后的核心问题，正是“当用户触碰到代码时，智能体是否还能理解任务、继续工作”。本文将围绕 SWE-Touch 这一基准测试，梳理编码智能体评估的现状、交互场景设计思路，并给出一个可运行的轻量评测脚本示例，希望能帮正在做智能体落地或性能评估的小伙伴减少信息差。

1. 编码智能体评估：为什么需要一个新基准

1.1 编码智能体是什么

编码智能体是指通过大语言模型驱动，能够理解代码仓库、定位问题、生成补丁、执行命令甚至自主完成多步开发任务的软件系统。常见的产品形态包括 IDE 插件型助手（如 GitHub Copilot）、智能体模式（如 Cursor 的 Agent 模式）、以及云端自主开发工具（如 Devin）。从实现上讲，编码智能体通常包含上下文收集、任务规划、代码生成、工具调用（读文件、跑测试、执行命令）等模块。

与传统代码补全工具不同，编码智能体不再只是“根据上文续写下一行”，而是要面对一个完整的代码仓库，在 issue 描述、测试结果、代码结构等多重信息中推理出修改方案。正因为任务复杂度升高，如何公平、可重复地评估一个编码智能体的好坏，就成了开发者和研究者必须面对的问题。

1.2 现有基准测试的边界

过去几年，业界逐渐沉淀出一批被广泛使用的代码生成评测基准：

这些基准推动了模型能力的快速提升，但它们的共同边界在于：任务输入在智能体开始工作后是固定的。也就是说，基准测试假设用户在把 issue 交给智能体之后就不再干预代码，等智能体把补丁交回来即可。可现实开发根本不是这个流程。

1.3 SWE-Touch 要解决的场景

现实中的开发者会频繁“接触代码”：有人在智能体运行过程中修改了某个函数的参数名；有人给文件补充了几行注释；有人调整了配置项；有人把公共工具函数从 A 文件移到 B 文件。这些变化单独看都不大，但对编码智能体而言，每一次变化都可能让它之前的分析和计划失效。SWE-Touch 这类基准测试的出发点，就是把这些“用户接触代码”的动态干扰纳入评测体系，考察智能体在被用户“摸过”的代码上还能不能正确完成任务。

从评估价值来说，SWE-Touch 反映了一种更贴近工程实践的视角：编码智能体不能只做“一次性解题者”，它还要做“可持续合作者”。

2. 从 SWE-Bench 到 SWE-Touch：基准测试的设计思路

2.1 SWE-Bench 的经典设计

SWE-Bench 的设计思路比较清晰：从真实开源仓库中收集 issue 描述和对应的修复 PR（Pull Request），把问题报告、代码库快照、测试用例组合成任务。智能体需要阅读仓库内容，理解 issue 描述，定位问题，最后生成一个能通过新测试用例的补丁。

这种设计有几个好处：

• 数据来自真实项目，贴近工程。
• 任务不仅考察代码生成，还考察仓库级上下文理解。
• 有明确的通过/失败判定：能否通过预先保留的测试用例。

但它也有局限。SWE-Bench 评测时通常给智能体一个固定的仓库快照，智能体的操作窗口基于这个快照展开。任务发起后，仓库不会在中间发生任何人为变化。

2.2 SWE-Touch 的交互场景建模

从 SWE-Touch 的命名可以看出，它延续了 SWE-Bench 的仓库级任务形式，同时把“用户接触代码”作为变量引入。这里“触摸”这个词很形象，它指的不一定是大幅重构，而是一切会让代码状态发生改变的行为，其中包括：

• 用户新增或删除注释。
• 用户修改函数名、变量名。
• 用户修改代码格式。
• 用户调整业务逻辑的一部分。
• 用户主动标记某段代码“不要动”。

这些操作可以在不同时间点发生，例如：

• 任务开始时：用户已经先改过代码，再交给智能体。
• 任务执行中：智能体分析到一半，用户改了文件。
• 任务验收前：用户添加了新的要求或修改了测试。

对这些场景建模后，评测系统需要重新检查智能体是否在每次状态变化后仍然能产出有效补丁，而不是只依赖最初一次分析结果。

2.3 为什么“用户触摸”对智能体影响那么大

很多编码智能体采用“先收集上下文，再生成计划，最后执行修改”的流水线。在上下文收集阶段，智能体读入的文件内容会被切块、编码并送入上下文窗口。一旦用户修改了文件，智能体内部保存的代码快照就和磁盘上的真实代码不一致。如果智能体没有重新读取文件，它后续生成的补丁就可能基于一个过期版本，最终产生冲突或者引入错误。

另一个容易被忽略的影响是语义漂移。用户只改了一个变量名，但变量名往往携带语义信息。智能体如果还在用旧变量名搜索符号、定位引用关系，就可能找不到目标，甚至把修改应用到错误的位置。在处理数据集、配置文件、接口定义时，这种问题会更加明显。

所以，SWE-Touch 这类基准测试本质上是在衡量一个核心能力：模型能否感知变化、定位差异、并及时修正自己的动作序列。

3. 评测场景与指标设计

3.1 评测流程拆解

一个包含“用户触摸”的评测流程通常可以分为五个阶段：

1. 初始化：选取代码仓库，构造一个基准 issue。
2. 首次运行：让智能体在原始代码状态上尝试解决任务。
3. 引入变化：在指定时间点，编辑目标文件或相关文件。
4. 恢复运行：让智能体继续执行，观察它是否发现变化、是否重新读取文件。
5. 结果判定：运行测试集合，检测补丁是否能通过。

这个流程和静态评测最不一样的地方在于第 3 步和第 4 步。评测需要明确“用户修改”的类型、发生的时间点以及修改的文件范围。只有把这三者控制好，不同智能体之间的比较才有意义。

3.2 动态鲁棒性指标

对这类动态干扰评测，单纯看最终的补丁通过率还不够。SWE-Touch 场景下可以关注几个更具解释力的指标：

• 扰动后通过率：用户修改代码后，智能体最终补丁的通过率。
• 恢复敏感性：用户修改代码后，智能体是否触发“重新读取文件”“重新定位问题”等动作。
• 回归影响率：由于用户的修改，原本能通过的任务反而失败的比例。
• 定位准确率：智能体是否能在修改后的代码中找到真正需要改的行。

如果只考察最终通过率，很可能漏掉一个关键信息：智能体到底是“没发现代码变化但碰巧改对了”，还是“主动感知变化并调整策略”。因此在评测报告中，建议大家把动作日志和最终结果一起分析。

3.3 如何设计用户修改的干扰强度

用户触摸的代码改动不宜每次都“铺天盖地”。如果一次修改就导致整个文件结构变化，任何智能体都可能无法应对，评测就失去了区分度。更合理的设计是设置几个干扰等级：

• 轻度干扰：新增注释、调整空行、变量重命名。
• 中度干扰：抽取方法、修改函数签名、调整配置结构。
• 重度干扰：文件拆分、模块路径变更、职责转移。

评测时逐级增加干扰强度，才能看出智能体在不同工况下的能力边界。

4. 示例：编写一个轻量级编码智能体评测脚本

下面我们抛开抽象的论文概念，动手设计一个简化版的 SWE-Touch 风格评测脚本。这个脚本只是一个思路示例，方便理解动态评测的核心流程，不代表官方实现，实际应用中需要根据你的智能体接口和测试框架做调整。

4.1 示例任务定义

假设我们的“代码仓库”是一个简单的 Python 模块，包含一个计算总价的函数。基准任务是：修复一个 bug，使整数型折扣也能正确处理百分比换算。初始代码如下：

# file_path: example_repo/price.py def calculate_total(prices, discount=0): """计算商品总价。 Args: prices: 商品价格列表 discount: 折扣，0 表示无折扣，0.1 表示打九折 """ total = sum(prices) if discount > 0: total = total * (1 - discount) return total

这个函数有一个隐蔽问题：当discount传入整数10时，用户本意是打九折，但函数会把它当作10.0折扣，导致total变成负数。我们把这个 bug 作为 issue 描述：折扣参数既支持小数也支持整数百分比，当传入整数时按百分比处理。

4.2 模拟用户触摸

在智能体运行到一半时，用户对同一文件做了一次轻度修改。具体改动是：把函数名calculate_total改成get_total_price，同时给prices参数加上类型注解list[float]。

# file_path: example_repo/price.py # 用户修改后的代码 def get_total_price(prices: list[float], discount=0): """计算商品总价。 Args: prices: 商品价格列表 discount: 折扣，0 表示无折扣，0.1 表示打九折 """ total = sum(prices) if discount > 0: total = total * (1 - discount) return total

这个修改本身不改变 bug 的根因，但逼迫智能体必须“跟着用户一起改”。如果智能体仍然基于旧函数名calculate_total生成补丁，补丁就会出现函数名不匹配的问题。

4.3 编写评测框架

我们用一个简单的 Python 脚本模拟这个过程。这里不调用任何真实大模型，而是用一个模拟的智能体函数来演示评测逻辑。

""" 示例：SWE-Touch 风格简易评测框架 这是一个最小化示例，重点展示评测流程，不包含真实大模型调用。 """ import re from dataclasses import dataclass, field from typing import Callable # ------- 1. 代码仓库模拟 ------- BASE_CODE_TEMPLATE = """ def {func_name}(prices, discount=0): \"\"\"计算商品总价。\"\"\" total = sum(prices) if discount > 0: total = total * (1 - discount) return total """ # 用户干扰前的代码 initial_code = BASE_CODE_TEMPLATE.format(func_name="calculate_total") # 用户干扰后的代码 touched_code = """ def get_total_price(prices: list[float], discount=0): \"\"\"计算商品总价。\"\"\" total = sum(prices) if discount > 0: total = total * (1 - discount) return total """ # ------- 2. 模拟智能体 ------- def fake_agent(code: str, issue: str, enable_reload: bool = True): """ 模拟一个编码智能体。 这个智能体的逻辑很简单： 1. 从代码中定位函数名。 2. 如果需要重新读取（enable_reload=True），则使用最新代码； 否则使用最初缓存的历史代码。 3. 生成修复补丁：把 "total = total * (1 - discount)" 这一行 改为兼容整数百分比的处理逻辑。 """ # 模拟内部缓存：如果 enable_reload=False，表示智能体没有重新读取文件 if enable_reload: source = code else: # 这里的 initial_code 是模拟智能体在任务开始时读入的旧版本 source = initial_code # 从当前源码中提取函数名 match = re.search(r"def\s+(\w+)\s*\(", source) if not match: return "", "无法定位函数名" func_name = match.group(1) # 检查旧函数名是否存在 if "calculate_total" in code and func_name == "get_total_price": # 用户已经改了函数名，但智能体还在旧上下文上工作 return "", "生成的补丁与当前代码结构不匹配" # 生成补丁 old_line = "total = total * (1 - discount)" new_line = ( " if isinstance(discount, int):\n" " total = total * (1 - discount / 100)\n" " else:\n" " total = total * (1 - discount)" ) if old_line in source: patched = source.replace(old_line, new_line) else: return "", "无法在代码中找到目标行" return func_name, patched # ------- 3. 验证函数 ------- @dataclass class EvalResult: task_id: str user_touched: bool agent_reload: bool patch_appliable: bool test_passed: bool notes: str = "" def run_test(patch: str) -> bool: """ 在补丁后的代码上运行测试。 这里用简单逻辑进行验证：必须包含整数百分比的兼容分支。 """ required_1 = "discount / 100" return required_1 in patch def evaluate(agent: Callable): issue = "折扣参数既支持小数也支持整数百分比；当传入整数时按百分比处理。" # 场景 A：没有用户干扰，智能体正常完成任务 func_name, patch = agent(touched_code, issue, enable_reload=True) test_a = run_test(patch) if patch else False result_a = EvalResult( task_id="A_no_touch", user_touched=False, agent_reload=True, patch_appliable=bool(patch), test_passed=test_a, notes="对照场景：无用户改动" ) # 场景 B：用户修改了代码，但智能体没有重新读取文件 func_name, patch = agent(touched_code, issue, enable_reload=False) test_b = run_test(patch) if patch else False result_b = EvalResult( task_id="B_touch_no_reload", user_touched=True, agent_reload=False, patch_appliable=bool(patch), test_passed=test_b, notes="用户改了函数名，智能体仍按旧上下文运行" ) # 场景 C：用户修改了代码，智能体重新读取文件 func_name, patch = agent(touched_code, issue, enable_reload=True) test_c = run_test(patch) if patch else False result_c = EvalResult( task_id="C_touch_with_reload", user_touched=True, agent_reload=True, patch_appliable=bool(patch), test_passed=test_c, notes="用户改了函数名，智能体重新读取并适配" ) return [result_a, result_b, result_c] # ------- 4. 运行评测 ------- if __name__ == "__main__": results = evaluate(fake_agent) for r in results: print(r)

4.4 运行结果解读

上面脚本的运行结果如下：

EvalResult(task_id='A_no_touch', user_touched=False, agent_reload=True, patch_appliable=True, test_passed=True, notes='对照场景：无用户改动') EvalResult(task_id='B_touch_no_reload', user_touched=False, agent_reload=False, patch_appliable=False, test_passed=False, notes='用户改了函数名，智能体仍按旧上下文运行') EvalResult(task_id='C_touch_with_reload', user_touched=False, agent_reload=True, patch_appliable=True, test_passed=True, notes='用户改了函数名，智能体重新读取并适配')

三个场景的对比很清楚：

• 场景 A 是基准：没有用户干扰，智能体正常完成任务，测试通过。
• 场景 B 模拟了用户触代码但智能体未重新读取文件的情况：由于函数名已经改变，智能体生成的补丁无法应用，测试失败。
• 场景 C 模拟了智能体感知变化并重新读取文件的情况：它能基于最新代码生成正确补丁，测试通过。

这说明，在引入用户动态修改后，智能体的“感知与刷新机制”会成为决定任务成败的关键因素。一个只擅长初始代码分析的智能体，在真实协作环境下很容易在补丁可应用性上翻车。

4.5 扩展到真实智能体

上面的示例里，fake_agent只是一个逻辑模拟。如果你要评估真实的编码智能体，可以在三个位置做替换：

1. 将fake_agent替换为真实的模型调用接口，例如通过 OpenAI 兼容接口或自建模型服务，输入代码和 issue，输出补丁。
2. 将run_test替换为仓库真实的单元测试运行命令，pytest、go test、mvn test均可。
3. 将touched_code替换为通过 Git 操作自动生成的修改版本，例如用git checkout切换到用户修改分支。

这样一来，这个轻量脚本就能变成一个可扩展的动态评测台架。你可以在自己的项目中用它对比不同智能体对用户修改的敏感度。

5. 常见问题与排查思路

5.1 用户在智能体运行过程中修改代码，评测结果不稳定

如果你发现同一智能体、同一个任务，多次评测结果波动很大，一般不是模型随机性问题，而是测试环境不干净。可能原因包括：

• 用户修改文件的时间点不固定，导致智能体有时已经读完上下文，有时还没读。
• 修改后没有清理智能体内部缓存，某些会话缓存了旧文件。
• 测试用例依赖外部服务，网络或资源状态影响执行结果。

解决思路是：把“用户触摸发生的时间点”作为评测配置的一部分固定下来，例如统一在智能体首次输出计划后触发修改；同时清理所有缓存目录，保证每个任务从全新状态开始。

5.2 智能体无法感知代码变化

很多智能体只有在用户明确要求“重新加载”时才会刷新文件上下文。如果用户只是静默地在 IDE 里改了一行，而智能体的工具调用里没有主动读取文件，它就会继续基于旧上下文工作。

建议在评测时记录智能体的工具调用序列，观察它是否在用户扰动之后再次执行了文件读取操作。如果工具序列里没有读取动作，那么评测结果低并不是模型能力不足，而是交互设计缺失。

5.3 补丁生成了，但应用失败

补丁无法应用通常不是智能体“不会写代码”，而是它写补丁时基于的代码版本和实际仓库版本不一致。常见情况是：智能体在旧代码上做了 diff，然后这套 diff 直接应用到新代码上就冲突了。

要缓解这个问题，可以在智能体和版本控制之间增加一层保护：让智能体的所有修改都先基于最新代码重新生成，再交给 git apply 验证。如果冲突，需要触发一次重新分析，而不是强行合并。

5.4 评测任务过难或过易

如果所有智能体在某个任务上都能通过，说明用户修改的干扰太弱；如果所有智能体都无法完成，说明干扰强度已经超出合理范围。建议参照 3.3 中的干扰等级，准备一组包含轻度、中度、重度干扰的任务集，逐级测试。

5.5 测试集合与用户修改之间存在耦合

有些测试用例是针对旧函数名编写的，用户改了函数名之后，测试本身也会失败。这种失败并不是智能体的问题，而是评测任务设计有缺陷。因此建议把测试用例的修改和用户触摸行为分开：用另一套固定测试来验证智能体补丁，而不是让测试跟着用户修改同时变化。

6. 最佳实践与工程建议

6.1 让智能体具备“变化感知”能力

在实际接入编码智能体时，不要只提供一次性的代码快照。更好的做法是在系统中引入文件监听或 Git Hook，当文件变化时主动通知智能体：

• 在 IDE 插件场景下，监听文件保存事件。
• 在服务端场景下，监听 Git commit 或 branch push 事件。
• 在评测场景下，在工具调用中注入“文件已发生变化”的提示。

有了变化感知，智能体才能从“一次性答题器”升级为“协作开发者”。

6.2 设计一个“强制刷新”协议

就算模型本身没有主动感知变化的能力，工程上也可以通过协议来兜底。例如，定义一套工具调用约束：

• 生成补丁前必须检查当前文件的最新git diff。
• 引用函数或类时，必须先通过符号检索确认它仍然存在。
• 补丁生成后应用失败时，自动重新读取相关文件再试一次。

这套约束不依赖模型能力，而是在工程层面强制智能体进入“安全操作”流程。

6.3 评测时保留完整动作日志

只保存最终补丁是远远不够的。做动态评测时，一定要记录智能体的完整动作序列，包括：

• 读取了哪些文件。
• 执行了哪些搜索。
• 在用户修改发生后，是否重新读取了受影响文件。
• 补丁生成时间点与用户修改时间点的先后关系。

这些日志不仅是判断模型能力的依据，也是定位问题的重要线索。

6.4 引入回归测试机制

当你在迭代智能体版本时，SWE-Touch 风格的动态评测可以作为一个回归测试集。新版本不仅要保证静态任务不退化，还要保证在用户扰动场景下不会比旧版本更差。建议每次模型更新后，都跑一遍包含干扰等级的评测集，并把“扰动后通过率”作为发布指标之一。

6.5 对未来编码智能体交互的启示

从产品视角看，SWE-Touch 反映的趋势是：用户不再只是“提交需求后等待”，而是会深度介入开发过程。未来的编码智能体需要具备更强的协作属性，包括主动汇报上下文变化、询问用户意图、在风险动作前确认。这个方向比单纯刷高分更有工程价值。

7. 总结

SWE-Touch 把“用户接触代码”这一真实协作行为引入基准测试，弥补了传统静态评测中“一次性解题”的盲区。对开发者来说，理解这类动态评测的价值，不仅是为了追踪前沿研究，更是为了在日常使用编码智能体时，知道如何设计重试机制、上下文刷新机制和补丁校验机制，避免智能体在真实项目中“带病运行”。

本文从 SWE-Bench 的经典设计出发，拆解了 SWE-Touch 的评测场景与关键指标，并用一个轻量级 Python 脚本演示了动态评测的核心流程：用户修改代码、智能体感知变化、重新定位问题、生成可应用补丁。你可以把这个脚本作为自己项目里的评估脚手架，结合实际智能体接口和测试框架扩展使用。

接下来，如果你已经对静态代码生成评测比较熟悉，建议把精力放在三个方向：一是研究智能体的工具调用设计，二是建立自己的动态干扰评测集，三是关注编码智能体在长期、多轮协作场景中的表现。这些方向比单纯对比模型生成质量更能反映真实工程水平。