10 月 6 日提交 arXiv 的 ParanoiaEval（编号 2610.08662，10 月 8 日更新到第二版）对准了编码智能体一类不太被讨论的行为：面对证据已经排除的风险，它仍然照方抓药。仓库注释里明明白白写着「这是终版」，智能体还是会给那段代码再裹三层检查；任务证据显示风险归属 CI 或评审，它照样在本地加一遍防御。论文把这类行为称为「不必要的风险处理」，并且用一个统一基准头一回把它称了重。
同一个任务，两个只差一条证据的版本
基准的设计思路干净利落。研究团队从 50 个真实仓库整理出 200 个仓库级任务，每个任务做两个变体，两个变体只差一条「风险该怎么处理」的证据：一个变体里风险仍在，加防护是合理动作；另一个变体里风险已被证据排除，继续施工就是过度。四种风险处理（规避、转移、缓解、接受）来自软件工程风险管理里成熟的 ATM 框架，被原样搬到编码智能体场景。
测量规模也够看：400 个可跑变体、8 种智能体配置、每种跑 3 轮，合计 9600 次运行，打分用的是人类校准过的智能体裁判，配套「处理违规率」与「证据响应度」两个专用指标。
三个读数，一个比一个不舒服
读数一：不必要的风险处理出现在 11.2% 到 58.7% 的运行里，证据明摆着也没用，不同配置之间差异很大。读数二更关键：任务成功率一直停在 88.3% 到 97.6% 的高位，与违规率不相关——92.7% 含过度处理的运行照样通过测试。功能正确性这次站在了过度防御那边：oracle 看不见的浪费，测试全绿。
读数三把代价摆到明面上：800 次人工评分研究里，开发者给含过度处理的运行满意度低 1.27 分（5 分制），原样接受的比例只有 38%，对照组的 78%。其中「缓解」类最遭反感——加检查、加兜底那种——低 1.55 分，接受率仅 28%。论文的结论因此很直接：更强的任务能力不保证更得当的风险处理，风险处理是一条独立的能力维度。
诊断与药方：给「停不下来」一个停止点
论文的诊断借自风险管理文献：降低风险这件事没有天然停止点。加检查加到哪算够？智能体手里没有准则，就只能一直加。实验佐证了这一点——把写明的边界（数量、范围）撤掉，8 种配置的过度率全部上升，至多抬 68.7 个百分点。
可操作的药方藏在证据的形式里，而且有点反直觉：有效的是以事实口吻写出的停止点（「这是终版」），不是以禁令口吻写出的指令（「别加检查」）。前者几乎不改变行为的尝试在论文里只做了轻量对照，但「把状态写清楚，让智能体自己推出边界」这条思路，与本站报道过的多篇指令遵循研究是同方向的。
放进赛道里看
这个方向和本站此前关注的「智能体超报完成度」（OverClaimBench 一类）正好构成对偶：一个是干得比说的少还报喜，一个是干得比需要的多还自称稳妥。两者共同指向同一件事——智能体的输出不只在「质量」维度失守，也在「分寸」维度失守，而后者此前的基准基本空白。
需要保留的怀疑
几条边界：裁判是单次调用的智能体，人类校准降低了偏差但没有消除；论文自己承认，「证据放在哪」会显著影响智能体读不读得到——仓库里的固定事实（比如钉死的解释器版本）与任务描述里的事实，可达性完全不同，这部分差距可能被算进了能力账上；事实与规则的效果对比只做了轻量测量，未分离变量。八个配置覆盖主流编码智能体，但结论外移到长程任务仍是开放问题。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。但对被智能体交付物里的「防御性代码」折磨过的团队，这篇论文给了一句能马上用的话：把止损点写成事实，别写成禁令。