一句话：agent 有动手偏好，该收手时偏要动
苏黎世联邦理工 SRI Lab 的新基准 FixedBench 戳中编码智能体一个少被正视的盲区：当工单里的 bug 其实早已修好、根本不需要改代码时，agent 仍然倾向于动手。在 200 个人工核验的任务上，覆盖 5 个近期模型与 4 种 agent harness，即便最克制的配置也有约 35% 的概率提出不想要的改动，最弱的配置高达约 65%。这不是偶发失误，而是一种系统性的「行动偏置」。
机制拆解：inaction 必须被显式框成成功路径
FixedBench 的设定很巧妙：它把任务设计成「什么都不改才是对的」，以此测试 agent 能否识别「已经解决」并 abstain（收手）。结果发现，显式要求先在本地复现问题再动手，能部分缓解乱改，却引出新的失败模式——当问题只修好了一部分时，agent 反而连本该补的 patch 也不提交了。结论指向一个训练层面的病灶：当前模型过度依赖人类的逐步引导，把「采取行动」当默认，而「不行动」需要被明确训练成一条通向成功的路径，否则模型不会主动选择它。
为什么值得注意：反向测「该不该动手」
今年的编码智能体评测大多在测「能不能修好」——给定一个问题，看 agent 能否生成通过测试的 patch。FixedBench 补的是相反的一维：当没有代码要改时，agent 能否忍住不动。这两件事听起来相关，实则不同：前者奖励动手能力，后者要求克制。现实工程里，陈旧工单、误报告警、重复 issue 长期存在，一个见活就干的 agent 会在这些场景里持续制造技术债。把这一维补进评测，比单纯堆 SWE-bench 分数更接近真实生产。
辩证看：规模有限，真实比例待统计
需要打折看的地方有三点。其一，200 个任务与 4 个 harness 的样本仍有限，跨 harness 的表现差异很大，结论需更大规模复现；其二，实验用的是「工单已解决」的合成设定，真实仓库里陈旧 issue 的比例与分布尚未被充分统计；其三，论文给出的缓解手段（先复现再修）本身带来新的权衡，并非银弹。关于是否在更多语言与代码库上验证，作者及行业暂未披露更多细节。
行业含义：把 abstain 做成一等动作
FixedBench 给部署编码 agent 的团队一个直接提示：在奖励与评测里，不能只在「能改」时给正反馈，也要把「正确收手」当成一等动作来设计与衡量。否则 agent 会在生产环境里把已修复的工单再改坏、把误报再折腾一遍。对评测方，这意味着基准要从「修得好不好」扩展到「该不该动手」，否则分数越高、越盲目。
结语
FixedBench 用 200 个无需改代码的任务，暴露了编码智能体普遍存在的行动偏置：35% 至 65% 的概率在该收手时乱改。它的价值在于把「该不该动手」这一反向维度推进评测与训练的正中央。至于这一偏置能否在更多真实仓库里被系统性抑制，仍要看后续的大样本验证。