Code Agent 的 exact、anchor、patch 和 LSP 编辑工具如何对比评测？

对比 Code Agent 的编辑工具，不能只准备几个字符串替换样例并统计工具是否返回成功。编辑接口会改变模型读取代码、规划修改、处理错误和验证结果的整条轨迹。可靠评测应固定模型、任务和 Agent 执行框架，只切换 exact、anchor、patch、LSP 或原生 fuzzy 工具，再用真实软件任务的最终测试结果衡量。

edit-tool-bench 研究什么

edit-tool-bench 是基于 OpenCode 的可复现实验框架，用相同 SWE-bench Pro 任务、相似模型配置和相同执行流程，对比不同编辑接口。它记录上下文、Token、成本、工具调用、模型生成的补丁和官方评测结果。

仓库提供五个实验臂：OpenCode 原生 legacy 编辑、精确替换 exact、文本锚点 anchor、类 Codex 补丁 patch，以及 LSP 符号辅助的 lsp_symbol。自定义工具通过选择器隔离；运行某个实验臂时隐藏其他编辑工具，减少模型自行换工具造成的混杂。

五种工具分别代表什么

legacy 使用实验所基于 OpenCode 版本的原生 edit，默认采用 fuzzy 策略。精确失败后还会尝试逐行裁剪、块锚点、空白归一、缩进宽松、转义归一等多种回退。

exact 提供精确字符串替换和多编辑事务。old text 不存在就明确返回 OLD_TEXT_NOT_FOUND，多个修改可在事务中统一处理。它牺牲部分首次应用便利，换取更清楚的状态。

anchor 在 exact 基础上加入按锚点选择范围和插入能力。模型不必完整回显大段旧代码，但锚点不唯一或范围不合法时需要重新读取与收窄。

patch 接受显式补丁形状的修改，先验证区块再写入，并把解析或应用失败直接反馈给模型。仓库明确说明它只是类 Codex 交互，并非与 Codex apply_patch 语法逐字节相同。

lsp_symbol 使用语言服务器按符号查找位置，再结合精确替换和事务。它适合以函数、类或变量为目标的修改，但依赖语言服务器索引和项目配置。

如何做到相对公平的隔离

实验应固定任务清单、模型标识、系统提示、时间与成本上限、容器镜像和评测器。唯一主动变化是暴露给模型的编辑工具集合。搜索、读取、测试与 shell 能力也应保持一致。

工具描述本身属于实验变量，因为模型根据描述决定如何调用。不能让一个实验臂获得额外解题提示，另一个只有参数 schema。每个工具的错误反馈虽不同，却正是接口设计的一部分，应保留并记录。

运行目录要保存原始事件流、会话、Token 指标、最终 patch、stderr 与官方 verdict。只保存汇总表无法解释失败为何发生，也难以审计模型是否真的使用了目标工具。

为什么选择高编辑量任务

当前 README 报告的实验选择了 23 个 SWE-bench Pro 任务，每个任务要求修改至少 10 个文件、总变更行数至少 400。大范围任务能放大编辑接口对跨文件一致性、重试和上下文管理的影响。

这种选择也限制了外推。结果更能说明高编辑量修复，不代表一行配置修改或新文件生成。工具在小任务上的成本与可靠性排序可能不同。

pass@5 应该怎样理解

每个任务和实验臂最多运行五次，只要任意一次通过就计为解决，因此结果是 pass@5，不是单次成功率。它降低模型随机性导致的偶然失败，但也增加总试验成本，并可能掩盖首次尝试稳定性。

报告中 anchor 解决 9 个任务，exact、patch 和 lsp_symbol 各解决 8 个，legacy 解决 7 个，对应 39.1%、34.8% 和 30.4%。23 个任务上的一两个成功差异很小，不能据此断言 anchor 普遍优于其他接口。

更稳妥的解读是：在同一模型与高编辑量样本中，工具接口能够改变任务轨迹和最终通过情况；需要扩大样本、模型和重复次数才能建立稳定排名。

Token 结果揭示了什么

除 anchor 外，其他实验臂的平均 Token 约为 331 万至 363 万，最大差距约 9%。anchor 平均约 476 万，比 exact 高约 31%，比 patch 高约 44%。

轨迹分析认为，大部分 Token 并非直接用于编辑工具输出，而来自重复读取、搜索、测试日志和长修复循环积累的上下文。任务身份解释的差异往往大于编辑接口本身。

anchor 的高均值由一些锚点不唯一和范围失败后的反复读取拉高，但并非每个任务都昂贵。个别任务中 anchor 反而低于其他工具。报告均值时应同时看中位数、分布和异常轨迹。

工具调用次数如何比较

报告的平均工具调用约为：anchor 80.5 次、legacy 70.2 次、exact 69.7 次、lsp_symbol 67 次、patch 63.8 次。patch 在该实验中调用较少，但不能单独解释为效率最高，因为一次 patch 可能包含多个操作。

应把调用次数与每次载荷、失败率和最终成功结合。一个调用很重的事务工具可能比多个轻量替换更省上下文，也可能在解析失败时丢掉整批工作。

为什么 fuzzy 的局部成功会误导模型

原生 fuzzy 工具对轻微漂移很宽容，经常返回编辑成功。问题不是它必然改错位置，而是连续局部成功会让模型相信跨文件方案已经完整，弱化重新检查假设的机会。

NodeBB 案例中，legacy 轨迹进行了 24 次 fuzzy edit，没有编辑工具错误，模型最终宣称相关权限逻辑已完成，但官方测试仍在同一函数附近失败。exact、anchor、LSP 和 patch 实验臂在该任务均通过。

exact 轨迹反而遇到 OLD_TEXT_NOT_FOUND 和事务冲突等显式错误。这些短期摩擦迫使模型重新定位、缩小范围或重建编辑计划，最终获得一致结果。失败信号有时是有价值的认知反馈。

anchor 为什么可能更贵却通过

OpenLibrary 案例中，legacy、exact、patch 和 LSP 均失败，只有 anchor 通过。anchor 使用更多 Token 和工具调用，经历多次锚点失败，但约束迫使模型反复选择精确范围，最终完成跨层行为。

这说明“低 Token”与“成功”需要共同评价。如果低成本轨迹没有解决任务，每次成功成本可能更高。反之，极昂贵的成功也未必适合生产，需要根据错误代价和预算选择。

LSP 工具应评估哪些特有风险

LSP 能按语义符号导航，理论上比文本搜索更稳，但结果依赖语言服务器是否启动、索引是否新鲜、项目能否加载，以及动态语言的类型信息是否完整。符号重载和同名定义也可能产生多个候选。

评测应单独记录 LSP 初始化失败、查询延迟、无结果和过期位置。若失败后自动退回文本替换，这个回退也必须属于实验定义，不能让不同运行获得不同工具能力。

一个完整评测应记录哪些指标

• pass@1 与 pass@k，而不只报告最佳尝试。
• 输入、输出、缓存 Token 和真实费用。
• 编辑、读取、搜索、shell 和测试调用次数。
• 首次应用率、解析失败、歧义和事务冲突。
• 最终 patch 文件数、行数和无关变更。
• 任务总时长、尾延迟和超时比例。
• 每个成功任务成本与失败轨迹分类。

如何复现实验

仓库要求准备 Python 环境、模型供应商配置、打过自定义编辑工具补丁的 OpenCode 二进制，以及 SWE-bench Pro 评测器和原始样本。模型 ID 要包含 provider 前缀，API 密钥环境变量只负责注入凭据，并不选择供应商。

先用两个实验臂和一个任务做 smoke test，确认容器、事件解析、patch 导出和 verdict 正常，再运行完整集合。每次实验保存配置与版本摘要，避免框架、模型或数据更新后仍把结果放进同一表。

评测设计还需要哪些改进

23 个高编辑量任务只能形成探索性证据。后续应扩大任务数量，按语言、文件数、变更密度和故障类型分层，并测试多个模型。工具与模型可能存在交互效应，一个模型适合 patch，另一个更适合 exact。

还要报告置信区间和配对差异，避免只比较百分比。相同任务在所有实验臂运行，适合使用配对统计；多次尝试则要说明随机种子、停止规则和费用聚合方式。

如何把结果用于工具选型

若团队重视清晰失败和事务一致性，可优先评估 exact 或 patch。符号导航成熟的静态语言项目可以测试 LSP。文件经常漂移且目标区间容易用锚点描述时，anchor 值得考虑，但要监控重试造成的上下文成本。

不要因为 legacy fuzzy 在一组实验中分数最低就完全禁用模糊匹配。小型局部编辑可能从容错中获益。更合理的做法是按任务选择工具，并让模糊成功接受 diff 和测试验证。

结论

对比 exact、anchor、patch 和 LSP 编辑工具，需要固定 Agent、模型和真实任务，只切换工具接口，并从最终测试、Token、调用次数与失败轨迹共同判断。工具的价值不只在是否把文本写入文件，还在它给模型提供怎样的成功和失败信号。

edit-tool-bench 的 23 任务结果表明接口会影响解决路径，但样本不足以给出普遍冠军。生产选型应复用自身任务集做配对实验，关注每次成功成本、显式错误质量和跨文件一致性，而不是只比较局部编辑成功率。