Code Agent 为什么会在文件编辑成功后仍然损坏内容？

Code Agent 调用文件编辑工具后收到 success，并不等于文件内容正确。工具层的成功通常只表示参数通过校验、写入系统调用完成或搜索替换命中；它不知道用户真正想保留哪些内容，也不一定检查语法、数据结构和业务行为。于是 Agent 可以宣布任务完成，diff 却包含大范围无关改写、遗漏或数据错位。

什么是执行末端失真

HIC AI 的文章把这种模式称为 Execution Slop：模型能复述合理计划，也能正常调用工具，但最后落盘结果损坏或出现远超任务范围的变化。问题发生在推理意图到文件变更的最后一段，因此单纯优化提示词或换更贵模型未必能消除。

“损坏”不只指文件无法解析。删除了不该删除的段落、覆盖并发修改、改变 CSV 列对应关系、重复插入代码、丢失文件尾换行，或者为了小改动重写整份文件，都属于内容层错误。它们可能通过工具的成功判定。

为什么字符串替换容易出问题

常见 edit 工具要求模型回显一段旧文本和新文本。旧文本必须与文件匹配，模型因此需要复制大量上下文。复制过程中可能改变空格、引号、换行或注释；若为了确保唯一匹配扩大范围，输出 Token 增加，遗漏风险也随之提高。

精确匹配失败后，一些系统会尝试空白归一化或模糊匹配。容错可以解决缩进差异，却可能在重复函数、模板和表格中命中错误位置。如果工具只确认“替换了一个片段”，它仍无法判断这个片段是不是用户意图对应的区域。

整文件覆盖避开匹配失败，但引入更大风险。模型必须重建所有未修改内容，任何截断、上下文缺失或格式化变化都会被写回。文件越大，变更面与审阅负担越大。

为何表格和结构化文本更脆弱

CSV、固定宽度文本和大型配置文件依赖位置关系。移动一列需要同步标题与每一行数据，简单搜索替换很难表达“把这个区域搬到另一个坐标”。模型若逐行重写，容易漏行、错列或改变转义。

代码也有类似结构约束。移动函数不仅涉及文本，还可能影响导入、导出、作用域和引用。工具只处理字符，不理解语法树时，局部成功可能造成全局不一致。

并发修改怎样造成静默覆盖

Agent 读取文件后到写入前存在时间窗口。用户、格式化器或另一代理可能已修改文件。如果工具没有版本标识或内容哈希，旧补丁可能应用到新文件的相似位置，整文件写入则会直接覆盖最新变化。

可靠工具应把读取时版本带入编辑请求，提交时进行乐观并发检查。版本不一致就停止并要求重新读取，而不是尽力猜测。对多个文件的变更，还要统一预检后原子提交。

“成功”应该分成多个层级

工具执行成功只是第一层。第二层是目标区域与预期变更一致，第三层是文件能够解析和通过静态检查，第四层是相关测试通过，第五层才是业务验收。Agent 的完成条件必须明确到所需层级。

例如移动 CSV 列时，写入成功远远不够。系统应验证行数未变、每行列数一致、标题与数据对应，并与目标样例或不变量比较。代码变更则应检查 diff 范围、语法、类型和行为测试。

坐标与区域编辑有什么不同

HIC Mouse 提供行和坐标驱动的编辑，模型声明区域边界与操作，而不必回显周围全部文本。它试图减少输出冗余和转录错误，并让插入、删除、移动等操作更直接。

多操作或大操作会先在内存中暂存，Agent 可以查看、细化、保存或取消。若某一步失败，系统支持原子回滚；批次大部分成功时，也可针对失败项修正。这类设计把“先预览再提交”纳入工具协议。

坐标编辑也有边界。行列位置会因前序变更漂移，Unicode 字符、制表符和不同换行格式会影响列计算。实现必须规定坐标单位、基准版本和批次应用顺序，并在提交前验证区域内容。

厂商研究提供了哪些证据

厂商页面报告了三项预注册确认性研究，共 67 组配对试验。每组在隔离容器内执行相同任务，一侧使用 GitHub Copilot 内置编辑工具，另一侧在相同 Agent 配置上增加 Mouse 工具；模型版本、温度和任务内容保持一致。

简单删除任务有 23 组试验，Mouse 条件报告为约 3.58 倍更快、1.58 倍更便宜。中等难度的近 600 行重构任务有 25 组，首次完美完成率为 56% 对 0%；但预注册的总体成功率差异在意向治疗分析中未达到显著，因此后续每次成功成本指标没有继续确认检验。

困难的 CSV 列移动任务有 19 组，Mouse 条件成功 17 次，基线在 240 秒内没有成功。成功判定要求结果与答案文件逐字节一致，未匹配时允许 Agent 根据 diff 继续迭代。

这些结果不能怎样解读

研究由产品厂商发布，比较的是特定版本 GitHub Copilot 基线与自家工具，任务只有三类，模型主要为 Claude Haiku 4.5 和 Sonnet 4.5。它不能证明所有内置编辑工具都已损坏，也不能证明坐标编辑对所有语言和代码库都更好。

中等任务中总体成功率未显著这一结果尤其重要，不能只引用首次成功率。后续研究还需要更多独立团队、其他编辑工具、模型和真实仓库，并做消融实验判断收益来自坐标、暂存、反馈还是工具数量。

不过，实验支持一个更一般的工程观点：保持模型不变，仅改变编辑工具架构，也可能显著影响准确率、速度和成本。工具不是模型能力之外可以忽略的管道。

如何防止工具成功后内容仍损坏

• 编辑前记录文件哈希和必要的不变量。
• 多项操作先在内存或临时快照中预演。
• 提交前生成 diff，限制与任务无关的变更范围。
• 对重复目标和低置信匹配停止自动应用。
• 写入后重新读取并验证目标片段。
• 运行解析、lint、类型检查和相关测试。
• 失败时原子回滚，并提供结构化诊断。

对于结构化数据，应使用 CSV、JSON、YAML 或语法树解析器执行变换，而不是依赖裸字符串。解析器理解列、字段和节点边界，可以在保存前检查结构完整性。

怎样限制无关大范围改写

系统可以根据任务估计变更预算，例如允许修改的文件数、行数和区域。若实际 diff 超出预算，就进入人工确认或要求模型解释。格式化造成的大范围变化应与语义修改分开提交。

还可以比较未触及区域的哈希，确保局部编辑没有改变其他内容。对必须整文件重写的场景，先将模型输出与最新文件做结构化 diff，再阻止意外删除公共 API、注释或数据行。

验证闭环应该如何实现

一个稳健流程是读取并锁定版本、生成编辑计划、在快照中应用、验证结构和 diff、运行目标测试，全部通过后再提交。任何阶段失败都返回错误代码、位置、预期与实际内容，供 Agent 在有限重试预算内修正。

验证失败不应直接在已损坏文件上叠加下一次猜测。可以回到上一快照，或让新补丁明确基于当前失败状态。系统必须记录选择，否则重试会因状态不清继续扩大损坏。

如何评估编辑工具

评测应同时覆盖小范围删除、多处重构、结构化数据移动、并发漂移和故意失配。成功标准使用字节级答案或可执行的不变量，不能以工具返回 success 为准。

指标包括首次正确率、最终成功率、误改行数、耗时、Token、回滚次数和结果方差。配对运行能减少模型随机性影响，预注册假设和完整报告未显著结果则能降低选择性汇报。

结论

Code Agent 在编辑工具成功后仍损坏内容，是因为执行成功与语义正确之间缺少验证。字符串替换、整文件覆盖、模糊回退和并发漂移都可能让工具完成写入，却改变错误区域或丢失无关内容。

解决方案不是只要求模型“更小心”，而是改进工具契约：区域化定位、版本检查、内存暂存、原子提交、diff 预算、结构化解析和写后验证。厂商研究提供了值得关注的初步证据，但仍需独立扩展验证。生产系统应把最终文件和测试结果，而不是工具返回值，作为真正的完成依据。