论文解读

Stefano Carlo Lambertenghi · Oliver Weissl · Johannes Betz · 1+

仿真对自动驾驶系统（ADS）测试至关重要，但仿真与现实之间的差异可能削弱测试结论。文献究竟处理了哪些差异、又有何证据支撑对应性主张，仍不清楚。对从 4,195 篇出版物中筛选出的 235 项测量或缓解 ADS 测试现实差距的原始研究进行系统性映射，刻画其目标、对象、方法、实验设置与评估证据。分类按六类 ADS 测试组件区分仿真与真实世界执行，并分别对应每种方法及其评估参照，从而把用于构建方法的真实世界信息与用于评估其主张的证据区分开。纳入研究中 76% 聚焦缓解，主要针对场景与参与者真实感及感知；94% 报告了验证或测量流程。仅 61 项研究报告了覆盖传感器/感知对应性、ADS 行为、车辆动力学或安全结果的多族指标；该覆盖不足以建立差异与测试判定之间的因果联系。综合表明，真实世界内容与物理执行须对照所评估的主张来解读。发现支持按主张评估与按组件报告，以确定哪些差异影响测试结论、以及仿真证据何时能支撑关于真实世界 ADS 行为的结论。

S M Abdulla Al Mamun · Akif Islam · Mohd. Ruhul Ameen

研究探讨在已有确定性工具证据时，增加专家语言模型上下文是否提升软件保障。实验涵盖 Java 警告控制、OWASP Benchmark、Defects4J 测试生成、SV-COMP 断言判定及误导性证据包，使用 Qwen2.5-Coder-7B-Instruct 完成 13,638 次请求。在 8 个开发警告中，上下文从 1 增至 50 使 token 用量增加 49 倍，但未改善不安全清除率。160 个 OWASP 案例中，10 上下文配置仅评估 96 例。32 个 SV-COMP 任务中，原始验证器反馈将平均正确判定从 12.7 提至 22.0，但错误判定从 1 增至 7；JBMC 加 JVM 基线返回 26 个正确判定。在 120 个证据包中，模型拒绝 70-100% 的反例，而范围检查正确分类所有包。Defects4J 中未发现目标缺陷。结果支持确定性证据准入，但暴露了判定聚合与反馈解释的局限。

Binhang Qi · Yiming Liu · Yun Lin · 3+

随着大语言模型智能体将自然语言需求编译为代码，需求到测试的生成变得至关重要。现有基准多关注白盒测试，缺乏对语义对齐的评估。本文引入 Req2Test-Bench，包含从 8 个开源项目中恢复的 5,086 个执行验证实例，涵盖 5 种编程语言和 4 种 BDD 框架。每个实例配对 Gherkin 需求与开发者编写的测试实现。评估 8 种智能体-模型-推理配置发现，执行成功率与行为充分性（以 kill-completeness 衡量）存在显著差距。最佳配置 Codex 搭配 DeepSeek-V4.1-Flash 在 82.8% 的实例上生成通过测试，但仅 33.8% 行为充分。研究发现：扩大智能体规模在行为充分性上收益递减；需求规格不足导致信息缺口；基于需求的测试框架是改进方向。

Zexin Li · Weibo Zhang · Linyi Li · 2+

ProCerDCL 是一个用于黑盒概率验证的查询高效框架。在给定可采样输入分布和二元属性预言机时，该框架评估属性违反概率 p 是否超过阈值 θ。在独立采样和无状态预言机行为下，接受断言 p≤θ，拒绝断言 p>θ+η（η 为用户指定的分离裕度），不确定结论表示证据不足。每类错误结论的概率均受指定错误预算限制。为高效支持这一三值契约，ProCerDCL 采用单一顺序测试，消除了基线所需的区间族。该测试通过修正的精确二项置信区间或任意时有效置信序列来处理重复采样检查。ProCerDCL 应用于概率局部模型语义一致性，其中属性预言机检测指定扰动分布下参考执行与编译执行间的决策级不一致。评估涵盖 TorchInductor 和 TensorRT 的 24 个任务，考察采样效率、确定性和诊断行为。在采样效率方面，使用配对单模型干净标签半径搜索：在匹配数值参数下，基线需要多 3.6-4.2 倍的唯一样本，且提供较弱的决策契约。在模型语义一致性方面，θ=10^-3 的检查在来自 21 个任务的 840 个输入-后端实例中产生 817 次接受、19 次不确定结论和 4 次拒绝。两个已记录的编译器故障案例研究进一步展示了这些局部结论的诊断能力。

Kosei Horikawa · Hao Li · Yutaro Kashiwa · 4+

Claude Code、GitHub Copilot coding agent 和 Cursor 等 AI 编码 Agent 现已直接向开源仓库提交代码。现有研究通常依赖 bot 账号或 Co-authored-by 等作者签名来识别 Agent 提交，但这些签名是可选的、可被移除的，且常附在 Pull Request 而非单个 Commit 上。本研究基于 1,226 个仓库的 7,837,946 条提交，涵盖五种编码 Agent 和 Human 提交，探讨了无签名检测的信号与局限。在屏蔽签名后，检测器将 Agent 提交排在 Human 提交之前，ROC AUC 最高达 0.859，主要信号来自消息冗长度和变更大小，而非代码本身。在未微调的情况下，gpt-6-sol 达到了与 XGBoost 和 TF-IDF 相似的 AUC。然而，在观察到的 Agent 占比下，全量测试集上最佳检测器的精确率仅为 0.332。检测在保留的 Claude Code 和 Copilot 样本上迁移效果不佳，TF-IDF 对 Claude Code 的 AUC 仅为 0.524。时间变化因 Agent 而异，Copilot 的 AUC 先降后升，而更多训练历史有助于 Claude Code 但无助于 Copilot。结果表明，无签名检测可用于优先审查提交，但不能替代记录归属，依赖签名标签的研究应将其视为 Agent 活动量的下限。

Zihan Fang · Ron Asoulin-Handelman · Helen Wu · 2+

生成式 AI 能生成复杂单元测试，但新手可能直接接受结果，缺乏独立识别测试点、评估完整性及验证正确性的机会，限制了技能发展。现有研究多关注 AI 生成测试或反馈式导师，鲜有探讨 AI 在不生成测试的前提下如何支持新手。为此，引入 TestCompass，一种提供针对性反馈以指出学生测试套件弱点的生成式 AI 导师，不生成可执行测试。在包含 18 名学生的课堂研究中，对比 TestCompass 与通用 AI 助手在两个 Java 单元测试任务中的表现，考察测试行为、套件质量及主观体验。结果显示，使用通用 AI 助手的参与者生成的测试更多，而 TestCompass 组花费更多时间自行开发和验证测试。两组测试套件质量指标大体相当，但在一个任务中，TestCompass 组以显著更少的测试方法（p=0.012）实现了相似的需求覆盖率。两组均未报告短期感知测试知识或信心的提升。这表明反馈导向的 AI 能在保留动手实践机会的同时支持有效的测试成果，为 AI 辅助测试教育提供互补方案。

Yuvraj Sehgal · Mahsa Panahandeh · Naser Ezzati-Jivan

尽管上下文窗口扩大千倍，代码智能体仍缺乏跨会话记忆，导致重复读取文件与重试失败方案。这属于记忆架构而非长度问题。Stratum 提出一种持久化、经验感知的仓库记忆系统。基于真实仓库的三项测量显示：中型项目已超出最大生产级上下文窗口，且将知识存入 KV 缓存比索引文本成本高 $10^4$ 至 $10^5$ 倍；在 752 个真实 Bug 修复提交中，中位修复仅涉及两个文件及其直接导入，占仓库不足 10%，瓶颈在于选择而非容量；即使包含传递导入和测试链接，47% 的共编辑文件对在结构上仍不连通，表明选择所需知识需从历史挖掘。Stratum 采用分层记忆架构，通过页面安全工具服务，每次响应明确返回内容、剩余内容及成本。在百万节点存储上，中位检索耗时 1.7 ms。在八个真实 Bug 的多会话实验中，继承不同模型写入记忆的代理在 24 次试验中 21 次定位到根因文件，而仅检索基线为 6 次（Fisher $p<10^{-4}$），中位 Token 成本降低 4.5 倍。合并所有八个调查笔记后，成功率保持 8/8。

Yuvraj Sehgal · Mahsa Panahandeh · Naser Ezzati-Jivan

LLM 智能体的评估常忽略工具输出在到达模型前的损耗。在基于 Linux 内核追踪的故障诊断智能体中，尽管 720 次运行中最大提示仅占用 5.75% 上下文窗口，但 3,827 个工具结果（占 34%）因固定长度切片导致 JSON 损坏。这种切片导致数据分布不均，某字段仅在 4.7% 调用中保留，而另一字段保留率达 99.3%，且证据位置取决于故障进程启动时间。受控实验表明，数据损耗首先表现为额外工作而非错误答案：工具调用增加 43%，计算量翻倍，产出率从 0.61 降至 0.31。对七个智能体框架的调查发现，其中两个存在相同的不安全切片机制。数据截断是否直接导致准确率下降仍属开放问题。

Christoph Daxerer · Johann Glock · Christian Macho · 3+

评估编码智能体在无工具、可选及鼓励使用调试器三种模式下，对原始及经行为保持变换重构程序的故障定位准确率。在144个LeetCodeDataset解决方案中植入610个单行故障，使用Sol 6.1、Luna 6和Qwen 3.8进行定位。无工具时，智能体在原始程序上定位准确率为98.2%-99.9%，变换后为96.7%-99.9%，主要误差源于循环与条件重构。鼓励使用调试器使Luna 6和Qwen 3.8在变换程序上的剩余错误分别减少63%和61%（准确率提升2.1和1.3个百分点），但Token消耗增加14.7至27.0倍；Sol 6.1保持99.9%准确率。可选模式下，Luna 6和Qwen 3.8仍提升1.5和1.3个百分点，但仅0.2%-6.2%的运行使用了交互式调试。结论：在短且规格明确的程序中，当前智能体仅凭源码即可定位几乎所有故障，调试器可消除剩余大部分错误；智能体更倾向于执行程序而非单步调试，但仍保留了大部分收益。

Xinyuan Song · Hasibul Haque · Jay Somasundaram · 3+

代码审查对识别缺陷、提升质量及支持软件演进至关重要。随着基于大语言模型（LLM）的编码代理普及，LLM 审查代理虽被广泛用于评估代码贡献，但常生成包含大量误报或证据不足问题的冗长审查，误导开发者。CIVER 提出一种基于因果干预的框架，旨在区分真实缺陷与误报。该框架集成三个模块：审查模块评估发现，干预模块生成修复导向的扰动，验证模块对审查可靠性打分。通过专家迭代进行联合优化，模块在响应针对性修复时识别真实缺陷，并在无关变更下保持稳定。在 SWE-Review-Bench 上的实验表明，CIVER 通过针对性修复正确识别了 77% 的真实缺陷。跨项目及下游修复评估进一步证明，CIVER 能跨仓库泛化并提升编码代理的任务成功率，验证了其在可靠自动化代码审查中的有效性。

Marco Paina · Mark Niklas M\"uller · Niels M\"undler-Sasahara · 1+

主动 Bug 发现是软件工程的关键问题，但编码智能体在该领域的能力研究不足，特别是跨整个仓库发现所有人类维护者会修复的 Bug 这一任务尚未被研究。为此，PROBE 基准被提出，包含 20 个多样化 GitHub 仓库在 18 个月内修复的 2,457 个 Bug，并提供了将候选发现与该部分参考集匹配的方法。评估显示，前沿模型编码智能体相对于参考集的召回率均低于 21%，精确率低于 9%。虽然更强模型将召回率从 8% 提升至 17%，但精确率未改善。令人惊讶的是，尽管精确率低，LLM 和人类评估者仍判定 85% 的发现有效。关键发现是，不同智能体发现的 Bug 分布相似，但与维护者修复的 Bug 分布存在显著差异。鉴于 Bug 发现的实用价值及前沿模型的低召回率，该基准对模型用户和开发者均具有重要价值。

Elizaveta Zinovyeva · Aiham Taleb · Nikita Kozodoi · 4+

针对安全关键汽车软件对验证的高要求及领域狭窄、数据稀缺的特点，提出一种基于 Model Context Protocol 的 C/C++ 编码助手。该助手提供生成、编辑和验证三个工具，允许开发者按需对任意代码执行验证，而非仅依赖智能体自检。底层大语言模型通过提示工程和微调进行汽车领域定制，数据集源自 AUMOVIO 生产代码，包含函数、需求文本及 UML 行为。在为期两周的生产项目试点中，开发者报告验证工具使用率最高，且用于自有代码。75% 的开发者偏好更快的提示工程配置。MISRA 和 AUTOSAR 模式检查器显示，提示工程在 C 语言违规数上表现更优，而微调在 C++ 架构模式符合度上更佳。

Yijun Zhou · Minghao Shao · Ke Zhang · 4+

游戏开发对编码智能体的挑战不同于通用软件工程，其正确性取决于引擎 API、序列化场景状态与运行时行为的交互，而非仅看源代码。现有基准主要面向 Godot 等平台，且依赖 LLM 裁判或粗粒度任务结果。UnityBench-Mini3D 包含 77 个基于七个专家定义技能类别（而非教程或类型）的项目级 Unity 任务，分为三个难度层级。每个任务包含完整 Unity 项目与自然语言需求，使用 1,178 个保留的人工编写里程碑测试进行评估，涵盖场景结构、组件配置及运行时行为。这种引擎内评估提供确定性部分得分，定位失败点，并区分部分实现与完整解决方案，无需主观裁判。在 21 个模型和 9 个编码框架中，简单任务平均通过率为 80.9%，困难任务降至 35.2%，总体仅为 57.7%。该基准提供了可复现的诊断测试平台，区分不同难度下的系统表现。

Radin Shayanfar · Keheliya Gallaba · Ahmed E. Hassan

评估编码智能体的软件团队需要反映预期变更的证据。基准分数仅总结智能体在 bug 修复等宽泛标签下的任务解决率，未提供评估工作是否类似团队工作负载的指导。本研究分析了五个公开基准中的 2,487 个任务及六种智能体配置的 14,922 次运行。引入 Spread-Novelty-Centrality (SNC) 画像，描述参考解在文件与目录中的分布、新增与删除代码的比例，以及所触及代码的依赖、历史与复杂度。结果显示，所有基准对在至少两个 SNC 轴上存在差异，即使任务标签相同。在 Claude Opus 4.6 解决的任务中，FeatBench 上的补丁大于参考解，而 FeatureBench 上更小。在六种配置中，成功解决的运行倾向于涉及分布较少的变更及 Centrality 指标较低的代码，且 Claude 与 Qwen 配置在解决相关的补丁大小上存在差异。这些观察表明，从业者应基于变更特征选择评估任务，检查任务描述中的信息，并结合同测试结果评估补丁范围。

Yuhao Tian · Tao Li · Ling Zhou · 4+

具身人工智能(embodied AI)仅以任务成功率衡量安全性并不充分，因为机器人可能在完成任务时违反安全要求。现有评估偏重性能与鲁棒性，却缺少从已记录安全风险到可执行、可验证测试的系统路径。EAST(Embodied AI Safety Testing)是一种数字孪生(digital twin)框架，将文献依据的安全证据转化为涵盖感知、指令、环境、动作和时序的故障注入测试。EAST结合专家审查的安全故障分类体系与8种可执行算子，并设置适用性和有效性约束。其三阶段工作流生成测试规范、在仿真执行中验证故障是否实现，并依据模拟器状态证据独立评估安全挑战、违规、任务结果和行为特征。框架保留执行轨迹及可重放记录，支持跨实验的问题归因与复现。在同等预算下，研究在6项RoboTwin操作任务、ACT与RDT两种策略架构上，将EAST与其他测试策略进行了比较。5轮比较活动覆盖全部74个可用任务—策略—算子组合，其中63个获得有效证据，安全挑战暴露率接近Random-Legal和Rule-Based。另有82次有效EAST执行在违反安全要求的情况下完成任务，揭示了成功导向评估所掩盖的风险。结果表明，安全测试应超越任务完成指标，并做到系统化、有效性约束与可复现。

Saurav Bellam (The University of Texas at Austin)

该研究在 SWE-bench Verified 上考察小型开放权重模型对嵌入搜索和代码图工具的使用。基于确定性跳数深度对任务分层，并在深度平衡的 160 任务集及全部 500 个任务上，对 10 个模型的定位智能体工具集进行消融，覆盖 79k 次回合。结构化工具使 Qwen3-8B 和 Gemma 4 E4B 相对仅用 grep 的准确率翻倍；参数从 1.7B 增至 4B 时增益达 17–21 个百分点，32B 时降至 4–5 个百分点。8B 以上模型约一半增益来自提交形式，而非定位目标。每增加一跳，正确定位几率均乘以 0.50–0.67；图工具的收益主要集中在第 0 跳名称查询和第 1 跳单次扩展，智能体仅在 12–14% 回合中连续扩展。线性探针显示，直接调用边可被解码，但表现低于词法基线。

Amit Verma

托管语言模型的结构化输出流水线通常在提示词中指定 Pydantic schema，验证响应，并在验证失败时重试。尽管原生结构化输出模式提供了替代方案，应用侧验证仍是实施自定义约束的重要手段。然而，单一有效率往往掩盖失败原因及可行干预。研究建立细粒度的 schema 一致性失败分类体系，并提出确定性分类器，依据模型响应与 Pydantic 验证错误判定失败类别。该框架应用于九种 OpenAI 和 Anthropic 模型/API 配置下的 3,997 次生成，使用 HotpotQA 与 FinanceBench 问题。结果表明，相近有效率可能对应不同失败模式，主要失败类别随 schema 约束和任务而变化。Markdown 围栏 JSON 最常见：在 681 次围栏失败中，去除围栏后仅 48.0% 通过验证，其余还隐藏着违规，主要是字段长度违规。探索性提示词消融显示，抑制围栏的变体似乎使失败转向长度违规，但这种转变源于暴露原有违规，说明聚合有效率会掩盖失败构成变化。研究进一步提出四项关于验证器、schema、重试和评估设计的工程实践，其中三项得到数据支持，重试反馈一项仅提出但未测试，并公开分类器、补全结果与标注。

Yuling Shi · Mingchu Zhong · Zhensu Sun · 4+

开发者使用软件项目前通常需先让其运行，这往往涉及安装语言运行时、系统包、构建工具并执行测试命令。基于 LLM 的智能体会检查仓库、编写配置脚本、执行脚本并修复错误，但仍采用串行试错流程：尝试一种方案，等待缓慢命令结束，观察失败后再决定下一步，限制了并行探索。SpecBuild 通过推测性分叉并行探索候选配置分支，保留首个提交成功的环境并丢弃其余分支。策略级分叉探索不同基础镜像和依赖策略等替代路线；命令级分叉预测命令运行失败，并在失败出现前准备修复分支。在覆盖 40 个仓库、9 种语言和 334 个任务的 Multi-Docker-Eval 上，基于三种骨干模型的 SpecBuild 相比最强基线将成功率提高 6.4 至 12.0 个百分点，平均配置时间缩短 22.4% 至 41.6%，表明并行推测性探索可同时提升速度与可靠性。

ZhiHong Liu · Shuyao Gao

将大语言模型(LLM)与静态分析结合的流水线会让模型把分析器输出作为证据，但模型能否区分真证据与假证据，以及其审查程度是否取决于证据主张，尚未得到测量。研究构建了面向 C/C++ 的过程内分析器，用于生成证明义务，并在 PrimeVul 的易受攻击与已修补函数上开展审计。六种证据条件仅在说明文字上不同，其中包括虚构“缺失检查已存在”的保证，以及虚构“新增检查缺失”的警报。研究覆盖四组互不重叠数据中的 916 对函数、来自四家厂商的 11 种模型配置，以及 16,572 次审计，所有模型均未经训练或微调。真实证据对准确率几乎没有改善（+0.02），假证据则产生非对称影响：与针对相同操作的真实说明相比，虚假保证使真实漏洞检出率最多下降 19 个百分点；虚假警报未显著降低准确率，且遭到反驳的频率高得多。预注册的内部复现实验在 7 个新模型上确认，虚假保证比虚假警报更能推动结论偏向其主张，平均非对称性为 +0.16，95% CI 为 +0.10 至 +0.24。审计提示中的指令无法可靠降低依赖程度，表现最佳的版本也未能复现。在预先设定的测试中，分别调用核验每项主张并展示被反驳的主张，使虚假保证条件下的准确率提高 12 个百分点（p=0.002），且在真实证据下无损失；第二个模型的增益较小且不显著。因此，流水线应在模型依赖工具保证前先行核验，研究也应以区分方向的指标衡量依赖倾向。

Xiaocong Yang · Rishit Chatterjee · Himanshu Udupi · 2+

编码智能体处理的代码仓库可能远超其上下文窗口。提示压缩器(prompt compressor)与检索器(retriever)可缓解此问题，但修复缺陷既需要确定必须修改的文件，也需要文件中的原始代码，因为模型必须准确复现待编辑行。检索器按代码与缺陷的相似度排序，而非判断文件是否必须修改；压缩器则删减文本以适配预算。在相同 token 预算下，将预算用于选择并原样展示相关文件的简单选择器 CQ2-CARE，比用于裁剪 token 或检索代码块解决更多问题。对 300 个近期 SWE-rebench 缺陷，每项问题均使用相同预算，并以基准测试评判补丁。使用 GPT-5.6 和 Claude Opus 5 时，CQ2-CARE 分别解决 43.7% 和 46.7% 的问题，比两种模型对应的最佳压缩器高 6.3 个百分点，比最佳检索器高 9.3 和 12.7 个百分点。它还超过两种面向缺陷修复训练的方法：SweRank 分别高 0.7 和 1.7 个百分点，SWE-Pruner 分别高 2.0 和 7.3 个百分点。分析显示，检索器常遗漏待编辑文件；压缩器虽保留这些文件，却改写文本，导致更少补丁成功应用。精确文件选择无需压缩模型，并按仓库原貌展示每一行，使模型能够原样引用待编辑代码。

Sadra Emami · Benjamin Weigell · Mohammad Reza Mousavi · 3+

大型语言模型(LLM)正被用于优化代码性能，但这通常默认执行速度提升会自然降低总能耗。研究以 EffiBench 全部 1,000 道题评测 11 个开源模型及 4 种解码配置，并逐进程采集硬件级能耗。推理能耗为 0.79–8.68 MJ，约等于 250–2800 次 GPT-4.1 查询；限制最大输出 token 的影响最大，相比默认配置最多降低 69% 能耗。44 种配置中有 42 种生成的代码单题耗能高于标准人工参考实现，增幅为 +4%–+886%；其余两种仅有微弱收益，盈亏平衡点约为 10^6–10^7 次执行。混合专家(Mixture-of-Experts)架构的推理能耗显著低于同等规模稠密模型，且不牺牲正确性，表明架构选择比解码参数更能影响可持续性。结果显示，性能优化与能源效率并不总是一致：LLM 自我改进倾向于生成运行更快但能耗更高的代码。

Salim Fares · Steffen Herbold

软件开发者正越来越多地使用可自主执行多步骤编程任务的 AI agents(智能体)，但这种做法能否迁移到机器人工程尚不清楚。机器人工程师需使用厂商专用的小众语言编程工业机器人，并依赖仿真工具的视觉反馈。研究记录了一家为工业机器人编程的中小企业使用 AI agents 的案例。智能体未提高整体生产力，仅在生成高度重复代码的任务中例外。不过，随着工程师学会使用智能体、且智能体逐步适配领域，使用效果随时间改善。AI 使用经验对智能体成功的影响大于机器人工程经验，表明 AI agents 并非即插即用方案。企业需培训工程师、为学习曲线预留时间，并确保配置符合领域及开发需求。显著的学习曲线也说明，生产力研究应采用纵向设计，否则会遗漏工程师在实际采用过程中的适应过程。

Antonio Ken Iannillo · Joshua Segun Owotogbe · Roberto Natella · 3+

LLM 智能体日益依赖通过 Model Context Protocol（MCP）暴露的外部工具，但现有 benchmark 通常假定工具能正确、及时响应，尚未测试智能体面对真实工具故障时的韧性。MCP-Injector 是一种可直接部署、感知协议的故障注入中间件，可拦截 MCP 工具调用路径，并通过可控持续性（永久、瞬时、间歇）及可设种子的调度注入故障。其故障模型依据公开 MCP 生态中观测到的事故分布（失败模式×持续性）校准，数据来自 1,774 个开源 MCP 仓库的 57,240 个 issue 与 pull request 线程。实验包含 1,350 个组合单元，交叉覆盖两种骨干模型规模（20B、120B）、三种智能体栈（自定义多轮 plan-and-execute、OpenAI Agents SDK、LangChain）和三种故障注入条件。结果显示，以永久故障为主的压力配置会显著降低质量，任务完成分从 10 分制下的 8.08 降至 3.23，下降 60%；对两个受测 gpt-oss 骨干模型而言，扩大规模并未带来容错优势。120B 模型在故障下保留的无故障得分比例并不更高（resilience-ratio model，p=0.96），其故障条件下的完成率甚至略低（91.1% 对 95.6%，相差 4.4 个百分点，95% CI [-0.2, 9.3]）。不同智能体栈吸收故障的能力存在差异，说明框架级错误处理比模型规模更为重要。

Moritz Schillinger · Maximilian Bader · Adrian Buehler · 4+

光声成像(optoacoustic imaging, OptA)与超声成像结合，是覆盖多种病理变化的有前景模态。其临床研究应用仍受限于缺乏无需编程 expertise 即可使用的分析软件；现有工具多为基于脚本的工程框架或厂商专有应用。OPTARI 是开源图形软件，支持大规模临床光声-超声(optoacoustic-ultrasound, OPUS)研究，基于 napari 图像查看器与 PATATO 数据处理工具包，支持原生厂商格式及开放 HDF5 数据格式，遵循 IPASC 标准，并以独立可执行程序分发。功能涵盖感兴趣区域标注、图像重建、色团分解、基于深度学习的组织分割，以及时间和频谱分析。自动组织分割在肌肉组织上的结果与专家标注相当，批处理将每次扫描的分析时间从数分钟缩短至不足 1 秒。OPTARI 正用于正在进行的临床 OPUS 研究，连接工程框架与医学研究，为临床 OptA 成像研究提供可复现、标准化的开源分析基础。