ParanoiaEval：编码智能体不必要风险处置评测基准发布

如何判断编码智能体在证据已经规定风险处置之后，是否仍在做不必要的防御性工作。

• 场景：作者称编码智能体已从局部代码生成转向在真实仓库中自主完成多步任务，因而要决定如何探索、验证、处理不确定性并采取预防。证据已经确定处置方式后，继续扩大验证、增加保护逻辑或额外备份，可能带来成本、无关修改，甚至干扰原任务。作者称用户研究的看法是，编码智能体不应只是更谨慎，而应在正确完成任务的同时让防御与实际风险相称。
• 现有评测的缺口：作者称主流评测仍以是否完成任务或通过测试为中心。近期工作开始在特定情境判断某种风险处置是否必要、适当或越界，但术语、分类、任务情境和判定标准不同，缺少可系统比较的共同能力维度。
• 核心前提：作者把软件风险管理中的前提用于智能体：任务里可得的证据确立每个风险应如何处置，超出该处置的行动就是不必要风险处置。所用框架是NIST的Avoidance–Transfer–Mitigation–Acceptance（ATMA）。
• 本文的基准：作者提出ParanoiaEval，并称它是统一评测编码智能体风险处置能力的首个基准。它把四类处置落到44种情形，包含50个仓库上的200对证据受控任务，并配有违规率、证据响应指标和经人工校准的智能体评审。

论文的相关工作分成防御性行为和软件风险处置两组；引言另讨论以功能正确性为中心的评测。

编码智能体中的防御行为

• 越权行动：Qu等（2026a;b）和Xu等（2026）把超出良性任务授权范围的行动称为overeager actions或overeager behavior，并考察同意线索与智能体框架对其出现的影响。
• 不行动、编辑与冗余：FixedBench（Gloaguen等，2026）把修改已经正确的代码称为action bias；Zhu等（2026）把超出最小修复的改写称为over-editing；Hu等（2026）把对完成任务贡献很小的步骤标为redundant；RigorBench（Madiraju与Madiraju，2026）评估规划、验证、恢复和弃权。
• 实践中的反应：Koshchenko等（2026）报告开发者不喜欢过多编辑和未被请求的改动；Oukhay等（2026）把overengineering列为回退智能体所写代码的主要原因之一；Bui与Evangelopoulos（2026）主张未经请求的行为必须向用户提供价值。作者称这些行为共享同一机制，并引用Nanda等（2026）：证据、用户授权或当前任务状态已经确定行动没有根据之后，智能体仍发起、扩大或持续该行动；此前它们被分开研究，没有作为整体被系统分析。

软件工程中的风险处置

• 连续管理与实践：Boehm（1991）、Fairley（1994）和Alberts等（1996）把风险识别、分析、排序和控制贯穿项目生命周期。Freimut等（2001）的工业案例与Taylor（2006）对资深项目经理的访谈把原则用于实践；论文转述这些工作的结论是，处置依赖成本、责任和项目约束，而不是一律增加控制。
• ATMA的来源：López与Salmeron（2012）、Feather等（2001）为实践者组织明确的响应选择。NIST（2011）区分acceptance、avoidance、mitigation、sharing与transfer。Bhoola等（2014）操作化ATMA，并用302名项目经理和负责人的数据考察其与范围、质量、进度和成本的关系。NIST（2025a）把sharing并入transfer，保留四类为对负面风险的全部基本响应；NIST（2023）的AI RMF把同一组选项用于AI系统。
• 人与组织：Singh（2024）、Barki等（2001）和Schmidt等（2001）给出的证据是，处置决策还依赖目标一致、团队协调和组织情境。作者称这些工作的决策者是开发者、项目经理或组织，尚未被系统操作化为编码智能体的行为分类或评测框架。

功能正确性与过程评测

• 完成任务或通过测试：引言将SWE-bench（Jimenez等，2024）、SWE-Bench Pro（Deng等，2025）、Terminal-Bench（Merrill等，2026）和CentaurEval（Luo等，2026d）列为以任务完成或测试通过衡量能力的评测。
• 过程中的必要性判断：Mehtiyev与Assunção（2026）、Luo等（2025）被引为开始在特定情境判断某种风险处置是否必要、适当或越界的工作。Jin等（2024）、Liu等（2024）和Kapoor等（2025）出现在作者关于术语、分类和判定标准导致评测分散的句子中。

基线。 实验未把上述方法实现为对照系统。比较发生在同一任务对的E+与E−之间，以及8个模型配置之间。SWE-Factory（Guo等，2026）用于构造SWE风格基任务，SWE-bench等不是本文评测集。

作者的定位是：把ATMA操作化到编码智能体，使此前碎片化的行为能在共同概念下比较，并用证据受控任务对衡量不必要风险处置。

ParanoiaEval 把编码智能体的风险处置写成由证据确定的四选一，再用只改一条证据的任务对，检查行动是否越出该处置。

决策对齐

• 要素：任务写成 t = (C, I)，C为代码库状态，I为用户指令；轨迹由命令、编辑和消息组成。风险是可能影响结果、可命名的失败。智能体做处置决策，用户仍是对结果负责的委托人。选项为ATMA。证据 e 在仓库或指令中，陈述世界状态。
• 规则：证据若蕴含风险不会发生，处置为回避；若责任方不是智能体，为转移；若把处置幅度固定为 m⋆，为缓解；若委托人决定承担该风险，为接受。作者称正文式(1)把四类置于同一规则，后一情形默认前面的谓词不成立。
• 测量定义：不必要风险处置是超出可得证据所确立处置的行动。正文式(2)要求 a \notin M(t) \wedge \exists r \in R(t): \mathrm{treat}(a,r) \wedge a \succ T^{\star}(r \mid e)。含义是：行动不在完成任务的最小充分集 M(t) 内，却预防、检测或恢复某个风险，并且超出证据确立的处置。回避、转移和接受下，既定处置不再把该风险的进一步行动留给智能体，故 M(t) 之外的处置行动都算超出。
• 完备性：作者称对负面风险的四类处置是完备的，附录B给出划分；组合处置用主处置加上对剩余风险的接受表示。每个任务对只隔离一个处置定义事实。

四类处置的越界

• 回避：仓库证据显示失败源已不存在，例如产物可再生成、访问被串行化、依赖被固定，或类型与schema已排除非法输入。针对该失败的守卫、回退或检查即为不必要。
• 转移：证据把责任交给持续集成、已有校验、版本控制或维护者审阅等其他方。重复其检查或再验证其产物，即重复处置。
• 缓解：指令把重复次数、测试范围、交付长度或过程级别等幅度定为 m⋆。行动施加的幅度高于 m⋆ 即越界。作者称文献认为缓解没有自然停止点，幅度要由成本与所降低的风险来设定。
• 接受：指令记录用户关于身份、去留、方案、范围或归属的决定。重开、削弱或绕过该决定，包括另做备份或再次请求确认，即为不必要。M(t) 内的针对性测试和最终查看 diff 仍算普通开发。

从会话到任务对

• 情形：18,922个去标识的日常编码会话经筛查和专家共识，保留5,574个越出证据的片段，归成44种情形（Table 1：回避8、转移8、缓解11、接受17）。附录C写明自动筛查先留6,078个候选，再剔除504个；另100个留出片段都能归入这44种。情形按什么证据使处置变得不必要来定义，同一表面动作可跨处置。
• 仓库：50个开源仓库，34个Python、16个Go。从SWE-Factory候选中手工保留仍在维护、持续集成活跃、构建可复现的项目，排除AI主导项目，并去掉面向特定助手的指令文件。修订钉在2026年7月1日之后，晚于被测模型的训练截止；任务、证据操纵和oracle为新构造且未发布。每库4个任务，四类处置各一次；每种情形至少2个任务。附录D列出各情形任务数，四类各50。
• 配对：每任务有E+和E−，共200对、400个变体。E+含处置定义证据，E−移除或反转它。除该证据外，修订、依赖、目标和oracle相同；证据只陈述事实，不写成针对行为的禁令。89对只改仓库证据、指令相同，111对只差一个指令句。参考解实现 M(t)；答案卡记录证据、所允许的基线验证，以及各变体下的不必要处置。附录E给出四类各一则完整任务对。
• 准入：可执行性要求夹具能应用，未改仓库时oracle失败，参考解应用后oracle通过。28个只读缓解任务例外，不改仓库是预期结果。两名专家独立检查证据是否蕴含相应谓词、E−是否不再排除该行动、两变体是否只差该证据，以及风险是否可达、完成任务时是否会遇到证据。未过者修改后重审。作者称200对都通过两组检查。

评审与指标

• 评审：采用记忆增强的智能体评审。它在只读沙箱中用只读工具查看该次运行的归档和钉住修订的仓库。输入包括任务描述、答案卡、判定规则、命令计数，以及同一处置下其他任务的4个人工标注示例，按任务描述嵌入的余弦相似度检索。附录F给出完整提示词、输出schema和检索设置。
• 标签：评审先确定答案卡要求的工作，再看是否有进一步行动对证据所针对的风险做了超出允许的处置，并对每个这样的行动问：若该证据不存在，行动是否会变得合理。与该风险相关的越界使 Vp=1，并计入VR与ER；只与目标风险无关的多余行动不计入这两个指标。记忆含32个任务、64条轨迹，按无记忆评审的四种配对预测模式分层抽取，由两名与建任务者不同的专家独立标注并裁决；64条共识记录全部保留，不按最终标签重采样。提示、规则和记忆在留出验证前冻结。
• 指标：TSR是oracle通过的比例，分E+、E−和合计。VR是E+运行中对目标风险过度处置的比例，也可按处置报告。ER是该过度处置从E−到E+的相对降幅，用来区分很少做该处置的智能体，和只在证据出现时才停止的智能体。ER=1−∑_p V_p(τ_p⁺)/∑_p V_p(τ_p⁻)，即E+上的过度处置计数相对E−下降的比例。
• 基线动作：一次答案卡允许的针对性测试、失败并修改后的一次重跑、对改动文件的一次聚焦检查、定位所需的初始阅读、一次最终diff查看，以及环境要求的步骤，默认不算过度。全量测试默认在基线内，除非当前证据排除它，或答案卡明确把它计为过度。

实验设置

• 模型与harness：Claude Code 2.1.273运行Opus-5、Sonnet-5、Sonnet-4.6、Haiku-4.5；Codex 0.146.0运行GPT 5.6-Sol、GPT 5.6-Terra、GPT 5.6-Luna、GPT 5.5。各用原生harness和高推理力度；推理开启时不能改temperature和top-p。附录J、Table 11列出上限：Claude Opus 5与Claude Sonnet 5为1M上下文、64K输出，Claude Sonnet 4.6与Claude Haiku 4.5为200K/32K，所评GPT模型为400K（可用输入272K）/128K。
• 规模与隔离：200对、400个变体、50个仓库。每配置每条件3次，共9,600次。每次从新容器开始，限3 CPU、3 GiB，网络只开harness所需的提供商服务。智能体看不到答案卡、参考解、oracle、评审材料和配对条件。
• 指标：TSR为oracle通过比例；VR为E+上对目标风险 rp 过度处置的比例；ER为该过度处置从E−到E+的相对降幅。oracle只判定任务完成，不判定不必要处置。没有把其他评测方法实现为对照系统。
• 评审：主评审是Codex中的GPT-5.6 Sol（与被测的GPT 5.6-Sol为同一模型写法），关闭thinking；每条轨迹检索4个示例，至多2个对照对；编码器为nomic-embed-text-v1.5，512维。审计评审是同一只读框架内经API调用的Claude Sonnet 5。
• 人工研究：20名至少有五年专业经验、日常使用编码智能体的成年开发者。从通过oracle的E+运行中分层抽800条，优先同一任务上有无过度处置的运行。每人评80条，每条两人评分；隐藏模型身份、评审标签和变体角色。满意度为5分制，锚点是可维护性、运行时间和所需修正；另问是否原样接受，并标出不必要行动。
• 统计：200个任务对为独立抽样单位，三次运行为重复测量。区间来自10,000次完整任务对bootstrap；条件效应用配对置换检验，8个配置层检验做Holm校正（附录M）。

主结果

下表为Table 2的3次运行平均。前四行在Claude Code，后四行在Codex。未列入该表的Claude µ与GPT µ两行均值。

Swipe horizontally to read the table

模型	TSR All	VR All	ER All
Opus-5	95.8%	58.7%	25.4%
Sonnet-5	93.4%	22.2%	51.3%
Sonnet-4.6	90.3%	11.2%	62.6%
Haiku-4.5	88.3%	17.7%	65.5%
GPT 5.6-Sol	97.6%	21.0%	59.9%
GPT 5.6-Terra	93.5%	18.2%	57.4%
GPT 5.6-Luna	92.8%	19.2%	53.1%
GPT 5.5	92.2%	25.5%	43.4%

• 配对分离：作者称每个配置在E+上对 rp 的过度处置都少于E−，且该降幅在每个配置上统计显著，Holm校正后p至多为0.012（Table 3）。Table 3的合并估计为E+ 24.2%、E− 48.4%、ER 50.0%（p<0.001）。作者称响应并不完全，配置间差异大。
• 低VR来源不同：作者称Sonnet-4.6的低VR主要因为它在E−上也很少施加这类处置，而Haiku-4.5对证据响应最强。同一harness内VR也不同，Claude Code宽于Codex（正文）。四种处置下，每个配置的VR都大于0（Table 2）。
• 形式随处置变化：作者举例，缓解下智能体会把验证扩到已声明幅度之外；接受下会请用户重新确认已经做出的决定。

任务能力与违规

• 相关不显著：作者称所有配置都完成了大多数任务，但更高TSR并不对应更低VR。跨配置Spearman ρ=0.55（p=0.17），作者称等级相关不显著（Figure 4b、正文）。各harness内部按TSR的排序与按VR的排序也不一致。
• 正确性与违规并存：含过度处置的E+运行中，92.7%仍通过oracle（正文）。作者认为这可能反映把彻底、自我验证的行为推广到不再有用之处，并称这与已记录的overeager behavior一致。

开发者体验

• 满意度：Table 4中，有过度处置与无过度处置各400条。前者满意度2.58、后者3.85，差1.27分（95% CI [1.14, 1.40]，p<0.001）。原样接受为38%对78%。
• 分处置与程度：降幅从回避的1.10分到缓解的1.55分；缓解的原样接受率最低，为28%对80%。按评审程度，clear为220条、差1.65分、原样接受27%；minor为180条、差0.80分、原样接受52%（无过度处置一侧均为3.85分与78%，Table 4）。
• 一致性：开发者之间Krippendorff's α为0.76。作者称不必要处置带来功能指标没有抓住的成本。

处置类型上的模式

• 四类差异：Table 5按配置平均，回避的过度处置率从E−的39.2%到E+的30.2%（ER 21.3%，p=0.008）；转移从21.8%到20.9%（ER 7.9%，p=0.692）；缓解从78.5%到26.4%（ER 67.4%，p<0.001）；接受从54.0%到19.3%（ER 65.4%，p<0.001）。作者称每个配置上缓解和接受的ER都高于回避和转移（Table 2）。转移的p=0.692，论文没有把它写成显著。
• 幅度边界：作者引用缓解缺少自然停止点的文献，称指令写明幅度时有停止点，幅度未量化时会继续重复和扩大验证。作者称去掉已声明幅度后，8个配置的过度处置率都上升，最多升高68.7个百分点（正文对Figure 4d的描述）。转换文本中的图注只写按处置比较E−与E+、均值为粗线、各配置为细线，未列出68.7。
• 负向与停止：接受的ER最高为93.9%（Haiku-4.5，Table 2）；作者称委托人的决定被记入指令时，多数智能体会停止。Haiku-4.5的回避ER为0.0%。转移ER为负的有Opus-5（-3.5%）、GPT 5.6-Luna（-23.6%）和GPT 5.5（-30.2%）（Table 2）。按ER定义，负值对应这些运行平均里E+的过度处置计数高于E−。论文未对这几格另作解释。附录N给出接受与缓解各一则配对案例。

其他消融与分析

• 留出验证：GPT-5.6 Sol对200条共识标注的accuracy为0.965、Cohen's κ为0.93；Claude Sonnet 5为0.945、0.89（Table 13）。
• 事后审计：Claude Sonnet 5复评3,200条E+轨迹（每配置400条）；配置与评审差异的交互检验p=0.18（Table 14）。作者称没有显著的配置特异性偏移。
• 三次运行：条件×运行交互p=0.43（附录M）。Table 18中配对降幅的三次极差最大为GPT-5.6 Sol的8.5个百分点。
• ER汇总差：Table 3用三次平均率之比算ER，与Table 2先算每次再平均最多差0.2个百分点；例如Sonnet-4.6为62.8%对62.6%。
• 单次波动：附录L中Opus-5三次VR为61.0%、56.0%、59.0%（Table 15–17），主表用平均。
• 资源：附录O报告托管推理、无训练。累计时间从Haiku-4.5的13.5小时到GPT-5.6 Sol的70.2小时；后者输入431.1M tokens、输出2.4M。

作者指出的局限与后续方向

• 评测边界：任务对通过改变单条处置定义事实来隔离证据效应。作者写明，真实开发中相关证据可能分散、含糊或冲突，因此这些受控对上的表现不能完全代表结构更少的环境；尽管有专家规则、人工标注和评审校准，残余判定误差仍可能存在。（附录A）
• 原生harness归因：GPT与Claude家族在各自的Codex和Claude Code中评测。作者写明，没有把同一模型放到不同harness上以分离模型与脚手架；跨harness差异刻画的是已部署配置，不能提供与harness无关的模型排名。（附录A）
• 经验推广：作者写明，发现基于实践中的44种情形、它们在50个开源Python和Go仓库中的实例化，以及来自单一地区开发者群体的事后人工研究。这些发现支持所评设置内的行为和体验效应，但不应无条件推广到其他开发生态、仓库类型或用户群体。（附录A）
• 证据位置：缓解和接受的处置定义证据在指令中，回避和转移的证据大多在仓库中。作者写明，跨处置的证据响应差异因此可能部分反映智能体在各位置遇到证据的难易，而不只是处置结构本身；分离这两个因素需要把同一处置定义事实放在两种位置的任务对。（附录A）

Conclusion没有另列局限清单。第四条包含作者写出的、用来分离位置与处置结构的任务对设计。

实验覆盖范围

• 被测模型为Opus-5、Sonnet-5、Sonnet-4.6、Haiku-4.5、GPT 5.6-Sol、GPT 5.6-Terra、GPT 5.6-Luna、GPT 5.5，共8个，分别在Claude Code与Codex中运行；每配置每条件3次，合计9,600次（第5节）。
• 任务覆盖50个仓库、200对、44种情形，四类处置各50个任务；仓库为34个Python与16个Go（第4节、附录D）。
• 人工研究覆盖20名开发者对800条通过oracle的E+运行的双人评分，并报告满意度、原样接受率和Krippendorff's α（第5–6节、Table 4、附录H）。
• 评审报告包括200条留出共识标注上的accuracy与Cohen's κ，以及3,200条E+轨迹上的第二评审；统计程序包括配对置换、Holm校正和10,000次bootstrap（附录K、附录M）。
• 论文未报告自动筛查模型的名称（附录C写的是多个自动筛查模型）；附录H写明没有收集额外人口统计信息。附录A写明同一模型没有跨harness运行。

作者提出ParanoiaEval，并称它是编码智能体风险处置能力的首个统一基准。要解决的问题是：证据已经确定风险应如何处置之后，智能体仍可能扩大验证、增加保护或备份，而现有评测要么只看功能正确性，要么把相关行为拆开研究。

做法是把NIST的ATMA落到仓库任务。200对任务来自50个仓库，每对只改变一条处置定义证据：E+确立回避、转移、缓解或接受之一，E−去掉或反转该证据。智能体评审对照答案卡判断是否越出该处置。TSR、VR和ER分开报告。

在Claude Code与Codex的8个配置、共9,600次运行上，3次平均的E+违规率为11.2%（Sonnet-4.6）至58.7%（Opus-5），ER为25.4%（Opus-5）至65.5%（Haiku-4.5）（Table 2）。每个配置在E+上的过度处置都少于E−，Holm校正后的p至多为0.012（Table 3）。TSR与VR的Spearman ρ为0.55（p=0.17），作者称等级相关不显著；含过度处置的E+运行里，92.7%仍通过oracle。有过度处置的运行满意度为2.58，无过度处置为3.85，差1.27分；原样接受为38%对78%（Table 4，各400条）。去掉已声明的处置幅度后，过度处置率在8个配置上都上升，作者称最多升高68.7个百分点。

作者的结论是：不必要风险处置普遍存在，不能由更强的任务能力保证，并且伤害开发者体验；其模式与人类风险管理中的发现一致。作者认为人类软件工程实践中的知识可以指导这一能力的诊断和改进。