乐于分享
好东西不私藏

软件工程论文速递 | 26.05.08 日报: 36篇新论文速递

软件工程论文速递 | 26.05.08 日报: 36篇新论文速递

目录

代理式编程与工作流编排

  • • DADL: A Declarative Description Language for Enterprise Tool Libraries in LLM Agent Systems
  • • PARNESS: A Paper Harness for End-to-End Automated Scientific Research with Dynamic Workflows, Full-Text Indexing, and Cross-Run Knowledge Accumulation
  • • Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use
  • • Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology
  • • MAS-Algorithm: A Workflow for Solving Algorithmic Programming Problems with a Multi-Agent System
  • • BUILD-AND-FIND: An Effort-Aware Protocol for Evaluating Agent-Managed Codebases
  • • From Agent Loops to Deterministic Graphs: Execution Lineage for Reproducible AI-Native Work
  • • To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study

代码表示、检索与生成评测

  • • Identifier-Free Code Embedding Models for Scalable Search
  • • Bridging Generation and Training: A Systematic Review of Quality Issues in LLMs for Code
  • • Schedule-and-Calibrate: Utility-Guided Multi-Task Reinforcement Learning for Code LLMs

测试、修复与程序分析

  • • Beyond BLEU: A Semantic Evaluation Method for Code Translation
  • • Exploring the Effectiveness of Abstract Syntax Tree Patterns for Algorithm Recognition
  • • Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution
  • • Teaching LLMs Program Semantics via Symbolic Execution Traces
  • • SiblingRepair: Sibling-Based Multi-Hunk Repair with Large Language Models

开发流程、需求与治理

  • • Automated Population-Level Audit Assurance via AI-Based Document Intelligence
  • • An Empirical Study of Proactive Coding Assistants in Real-World Software Development
  • • Operationalizing Ethics for AI Agents: How Developers Encode Values into Repository Context Files
  • • From Chat to Interview: Agentic Requirements Elicitation with an Experience Ontology
  • • Evaluating Non-English Developer Support in Machine Learning for Software Engineering

安全、可靠性与供应链

  • • Evolution of Log-Based Detection Rules in Public Repositories
  • • Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration
  • • On Fixing Insecure AI-Generated Code through Model Fine-Tuning and Prompting Strategies
  • • Heimdallr: Characterizing and Detecting LLM-Induced Security Risks in GitHub CI Workflows
  • • Beyond Accuracy: Policy Invariance as a Reliability Test for LLM Safety Judges
  • • Modeling Dependency-Propagated Ecosystem Impact of Changes in Maintenance Activities: Evaluating Support Strategies in the PyPI Network
  • • Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions
  • • Constraint Decay: The Fragility of LLM Agents in Backend Code Generation

程序语言、语义与形式化方法

  • • Governed Metaprogramming for Intelligent Systems: Reclassifying Eval as a Governed Effec
  • • A Practical Specification Language for Automatic Quantum Program Verification (Technical Report)
  • • Resource-Constrained Robotic Planning in the face of Mixed Uncertainty
  • • Infinite-state Games with Energy Objectives Beyond Counters
  • • Edit Distance of Finite-Valued Transducers
  • • Temporal Causal Models as a Model of Computation
  • • MinMax Recurrent Neural Cascades

研究方向:代理式编程与工作流编排

DADL: A Declarative Description Language for Enterprise Tool Libraries in LLM Agent Systems

  • • 作者:Axel Dunkel
  • • arXiv URL:https://arxiv.org/abs/2605.05247

Abstract

模型上下文协议(MCP)是大语言模型代理与外部工具之间的标准接口,但在组织规模下会暴露两个结构性问题。第一,每个 API 集成都要作为一个独立的服务器进程交付,并带着各自的部署、依赖树和凭据处理;近期实证研究表明,这类服务器中绝大多数只是 REST API 的薄包装。第二,按工具逐个注册的模式会让上下文窗口消耗随目录规模线性增长,迫使真实部署只能暴露组织实际使用 API 的一小部分。为解决这些问题,我们提出 DADL(Dunkel API Description Language),一种用单个声明式 YAML 文件描述 REST API 端点、认证、分页、响应整形和访问分类的格式。DADL 文件由运行时执行层解释;它不为每个 API 部署单独的服务器进程,也不生成集成代码,尽管运行时本身仍是一个服务器。由于所有工具共享同一运行时,凭据与授权可以集中管理,而目录则通过一个固定大小的 Code Mode 接口交给 LLM,与目录规模无关。这样得到的是一个企业工具库:一个可版本化、可审计的 API 集合,任何团队都可以在同一认证与授权边界内扩展、共享并使用。DADL v0.1 规范已按 CC BY-SA 4.0 发布,公共注册表包含 20 个服务上的 1,833 个工具定义。在该目录上,Code Mode 将工具公告的上下文成本从约 14.2 万个 token 降到约 1,000 个 token,约减少 142 倍;而搜索和执行调用的单次成本则另外计算,并取决于任务。


PARNESS: A Paper Harness for End-to-End Automated Scientific Research with Dynamic Workflows, Full-Text Indexing, and Cross-Run Knowledge Accumulation

  • • 作者:Yuchen Wang, Zhongzhi Luan
  • • arXiv URL:https://arxiv.org/abs/2605.05258

Abstract

近期的自主研究系统,如 AI-Scientist、PaperOrchestra、AutoSOTA、DeepResearch、InternAgent、ResearchAgent 等,已经展示出 LLM 代理可以完成提出想法、做实验和写论文,但每个系统都在框架层固定了一种特定的控制流形状,例如线性流水线、状态机、单代理循环或固定技能包。我们认为,这种僵化来源于五个方面:(1)工作流是动态且学科特定的,实验室工作、综述、仿真和理论推导的循环方式各不相同;(2)创意生成受限于 LLM 上下文,而跨领域创意又需要单个上下文无法容纳的知识;(3)仅有摘要视图会遗漏论文正文,但全文访问又并不均衡,因此必须依赖累积语料库来承担工作;(4)论文的开源仓库往往才是其实验方案的完整规格,但论文到代码的链接常被忽视;(5)没有工具能够把跨轮次知识以可检索的方式持久化到有限的 LLM 上下文中。为此,我们提出开源框架 PARNESS,包含四个设计动作:(i)一个轻量 DAG 内核和四字段 Agent 合约,将调度与领域语义解耦,使任何学科的循环都可以用可编辑的 YAML 表达;(ii)一个全文 PDF 解析与文献库子系统,将论文正文、图和表索引为类型化对象,并在必要时优雅退化为仅摘要;(iii)一个覆盖论文、想法、实验和代码仓库的知识图谱索引,配合相似、矛盾、跨领域、反直觉等场景类型检索,把聚焦后的片段送入每次 LLM 调用;(iv)一个小型扩展面,允许任何现代编码代理(Claude Code、Cursor、Copilot、OpenCode)增加或替换任意模块。据我们所知,PARNESS 是首个把声明式流水线、全文 PDF 与代码仓库索引、以及跨轮次知识结合在一起的开源系统。


Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

  • • 作者:Francisco Javier Arceo, Varsha Prasad Narsing
  • • arXiv URL:https://arxiv.org/abs/2605.05287

Abstract

RAG 和代理式 AI 系统正在企业部署中迅速普及,但真实企业环境带来的挑战在学术处理和面向消费者的 API 中往往不存在:多租户异构数据、严格访问控制、监管合规,以及要求共享基础设施的成本压力。现有 RAG 架构的一个根本问题是:检索系统按相关性排序文档,无论是语义相似、关键词匹配还是混合方法,而不是按授权排序,因此来自某个租户的查询可能仅因分数最高就把另一租户的机密数据暴露出来。我们形式化了这一差距,并分析了当代理系统把相关性与授权混为一谈时还会出现的其他缺陷,包括经由工具导致的信息泄露、跨轮次的上下文累积,以及对客户端编排的旁路。为解决这些问题,我们提出一种分层隔离架构,将感知策略的摄取、检索时门控和共享推理结合起来,并通过服务器端代理编排实施。该方法把工具执行授权、状态隔离和策略强制等安全关键操作集中到服务器端,为多租户隔离创建自然的强制点,同时允许客户端框架继续控制代理组合和对延迟敏感的操作。我们通过 OGX 的开源实现验证了该架构;OGX 是一个厂商中立的框架,实现了与 OpenAI 兼容的开源 Responses API,并支持服务器端多轮编排。我们的实验表明,ABAC 门控可以消除跨租户泄露,而额外开销可以忽略不计。


Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology

  • • 作者:Andrew Zigler
  • • arXiv URL:https://arxiv.org/abs/2605.05400

Abstract

AI 编码代理被迅速采用后,形成了一种占主导地位的工作流模式,常被称为“vibe coding”,它更强调实现速度而不是有意的准备。我们认为,这种做法会制造一个系统性的对齐问题:缺少足够上下文的代理会产出需要大量调试和重构的代码,耗费大量开发时间。借用烹饪中的 mise en place(把一切就位,简称 MEP)概念,我们提出一种面向 agentic coding 的三阶段准备方法:(1)上下文奠基,将领域专长和隐性知识外化为结构化文档;(2)协作式规格化,通过人机对话产出详细设计工件;(3)任务分解,将规格转化为结构化、带依赖关系的任务记录。我们报告了 MEP 在一次编程马拉松中的应用:大约两小时的准备使多个 AI 代理能够并行快速实现一个全栈教育平台。我们提出 context fluency 这一新兴开发者技能,即创建代理可以有效处理的丰富、结构化上下文的能力,并将其与逆向设计和隐性知识外化等既有框架联系起来。最后,我们给出了一个研究议程,用于实证验证 AI 辅助软件开发中的准备阶段方法。


MAS-Algorithm: A Workflow for Solving Algorithmic Programming Problems with a Multi-Agent System

  • • 作者:Yuliang Xu, Xiang Xu, Yao Wan, Hu Wei, Tong Jia
  • • arXiv URL:https://arxiv.org/abs/2605.05949

Abstract

算法题求解是评估 AI 编码系统中结构化推理能力的严苛试金石,因为它直接反映了模型在复杂场景中执行结构化推理的能力。现有方法主要依赖模型中心策略,如架构改造和数据扩展,这些方法成本高且可解释性有限。借助外部工具或提示技巧(例如 chain-of-thought)的替代方案又往往零散,缺乏统一框架。本文提出 MAS-Algorithm,一种受到竞赛程序员和算法工程师实践启发的系统化多智能体工作流,用于算法题求解。我们的框架把端到端求解过程拆解为模块化阶段,使其能够在代理之间实现结构化推理、工具集成和灵活协调。该设计强调严谨性和可扩展性,使其可以推广到多种题型。我们在自建基准上的实验表明,该框架在多个 Qwen 系列模型上都带来了稳定改进,平均接收率提升 6.48%。相比之下,在同一数据上进行参数高效微调仅带来 0.89% 的边际提升。我们还在 LiveCodeBench-Pro 上观察到 4.72% 的提升,并在额外的准确率与效率指标上持续改进。除了性能提升,我们还对工作流中的推理过程做了综合分析,包括错误模式和跨场景行为;进一步的替换与消融实验表明,单个代理的贡献最高可达 27.7%。这些结果表明,MAS-Algorithm 在推进 AI 驱动的算法推理方面具有很强潜力。


BUILD-AND-FIND: An Effort-Aware Protocol for Evaluating Agent-Managed Codebases

  • • 作者:Jhen-Ke Lin
  • • arXiv URL:https://arxiv.org/abs/2605.06136

Abstract

大多数编码代理基准只关注生成代码是否行为正确,这仍然重要,但仓库级工程越来越多地由代理管理:一个代理编写仓库,之后的代理再把它当作工作上下文进行检查、审计或扩展。在这种情境下,生成出来的仓库不仅是任务答案,也是供后续工作使用的沟通工件。即便强大的代理几乎满足了可见的行为目标,不同仓库在暴露其预期行为以及这些行为背后的设计选择方面也会有很大差异。我们提出 BUILD-AND-FIND,这是一个评估协议,用于衡量下游代理能否从生成的仓库中恢复这些预期选择,以及恢复需要多少检查工作。对于每个任务,builder 看到隐藏的仓库规格并构建代码库;finder 只能看到代码库和一个与规格追踪相关的多选题库。该协议把行为正确性与工件侧恢复分开,并报告恢复准确率、可重复性、实现覆盖率和检查工作量。准确率和稳定性作为门槛:只有在恢复可靠成功时,工作量才有解释意义。在能够恢复同一意图的工件中,同一个 finder 所需工作量越低,说明该工件越容易定位这一意图。仅问题控制和仅规格控制分别量化了通用先验和规格访问的影响,而审计则将遗漏的主张与 finder 失败区分开来,并检查正确答案是否引用了工件证据。在我们发布的高先验任务包中,恢复准确率接近饱和,因此检查工作量和 finder 特定效应成为主要的局部比较指标。


From Agent Loops to Deterministic Graphs: Execution Lineage for Reproducible AI-Native Work

  • • 作者:Josh Rosen, Seth Rosen
  • • arXiv URL:https://arxiv.org/abs/2605.06365

Abstract

大语言模型系统越来越多地以代理式工作流的形式部署,这类工作流把推理、工具使用、记忆和迭代细化交织在一起。这些系统能够有效产出答案,但它们往往依赖隐式的对话状态,使得保留稳定的工作产物、隔离无关更新,以及把变更传播到中间工件都变得困难。我们提出 execution lineage,一种执行模型:AI 原生工作被表示为带有显式依赖、稳定中间边界和基于身份的重放的有向无环图(DAG)。我们的目标不是把模型变成更好的单次写作者,而是让不断演化的 AI 生成工作在变化下仍可维护。我们在两个受控的政策备忘录更新任务上,将 execution-lineage 重放与以循环为中心的更新基线进行了比较。在无关分支更新中,DAG 重放在所有运行中都精确保留了最终备忘录,没有任何内容漂移或无关分支污染,而循环基线则会重新生成备忘录,并经常把无关上下文带入其中。在中间工件编辑中,所有系统都把新约束反映到了最终备忘录中,但只有 DAG 重放实现了完美的上游保留、下游传播、未受影响工件保留以及跨工件一致性。结果表明,最终答案质量与维护中的状态质量是两个不同的概念。当任务是有界的综合/更新问题且当前所有来源都能放入上下文时,强循环基线在产出打磨过的最终输出方面仍然具有竞争力,但眼前任务的成功可能掩盖部分状态不一致,而这种不一致会在后续修订中累积。Execution lineage 为“什么应该改变、什么应该保持稳定以及工作如何随修订演化”提供了更强的保证。


To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study

  • • 作者:Shota Sawada, Tatsuya Shirai, Yutaro Kashiwa, Ken'ichi Yamaguchi, Hiroshi Iwata, Hajimu Iida
  • • arXiv URL:https://arxiv.org/abs/2605.06464

Abstract

基于 LLM 的自主编码代理已经重塑了软件开发。虽然这类代理在代码生成方面表现出色,但 AI 生成代码的长期可维护性仍有待解答。本研究从实证角度考察了 AI 生成文件与人工编写代码在维护频率、人工参与程度以及修改类型上的差异。我们利用 AIDev 数据集中的 AI 生成 Pull Request 和 GitHub 数据,分析了 100 个热门仓库中的 1,000 多个文件以及约 3,200 次改动。研究结果表明:(i) AI 生成文件接受维护的频率低于人工编写代码,且更新通常只影响文件规模的一小部分;(ii) 对 AI 代码最常见的修改是功能扩展,而人工更新更多聚焦于修复 bug;(iii) 绝大多数这类维护工作由人类开发者完成。


研究方向:代码表示、检索与生成评测

Identifier-Free Code Embedding Models for Scalable Search

  • • 作者:Eric Wolos, Michael Doyle
  • • arXiv URL:https://arxiv.org/abs/2605.05251

Abstract

功能关联(function association)是二进制逆向工程中的一个有用过程。现有搜索工具可以在大规模上执行这种关联,但并未充分利用 AI 赋能搜索所能提供的能力。已有工作探索了面向某些逆向工程代码表示的嵌入模型,但并未覆盖源代码与去符号后的反编译代码之间、且带有标准预处理要求的双向关联。为弥补这一空白,我们形式化了这一函数关联问题,并评估嵌入模型在这两种表示之间双向关联的能力。为提升模型在该任务上的表现,我们使用对比学习对 Qwen3-Embedding 模型进行了微调。结果表明,我们的新模型在所有函数关联基线任务上都以显著优势超过其他模型,并且还能泛化到一个未显式训练过的常量算法关联任务。


Bridging Generation and Training: A Systematic Review of Quality Issues in LLMs for Code

  • • 作者:Kaifeng He, Xiaojun Zhang, Peiliang Cai, Mingwei Liu, Yanlin Wang, Chong Wang, Kaifeng Huang, Bihuan Chen, Xin Peng, Zibin Zheng
  • • arXiv URL:https://arxiv.org/abs/2605.05267

Abstract

大语言模型(LLM)在代码生成任务中经常产生有缺陷的输出,缺陷范围从逻辑 bug 到安全漏洞不等。尽管这些生成失败通常被视为模型层面的局限,但越来越多的实证证据表明,其根源往往在于训练语料中的缺陷。然而,训练数据质量问题如何传播为代码生成质量问题,具体机制仍缺乏系统梳理。本文通过对 114 篇原始研究进行系统综述,考察训练数据质量问题如何传导到代码生成。我们建立了一个统一分类法,将生成代码的质量问题归纳为九个维度,并把训练数据质量问题分为代码属性和非代码属性两类。基于这一分类法,我们形式化了一个因果框架,描述 18 种典型的传播映射机制。此外,我们还综合了数据、模型和生成生命周期中的最新检测与缓解技术。所综述文献显示出一个清晰的方法论转向:质量保证正从反应式、启发式的生成后过滤,转向主动式、以数据为中心的治理和闭环修复。最后,我们指出了开放问题,并提出了通过集成数据整理与持续评估来开发更可靠代码 LLM 的研究方向。


Schedule-and-Calibrate: Utility-Guided Multi-Task Reinforcement Learning for Code LLMs

  • • 作者:Yujia Chen, Yang Ye, Xiao Chu, Yuchi Ma, Cuiyun Gao
  • • arXiv URL:https://arxiv.org/abs/2605.06111

Abstract

强化学习(RL)结合可验证奖励已被证明能有效用于代码 LLM 的后训练,但为每个任务单独部署专用模型会带来随任务数量增长的成本,因此推动了统一的多任务 RL(MTRL)方法。然而,现有 MTRL 方法把所有编码任务一视同仁,在共享优化策略下使用固定的数据课程,最终限制了多任务训练的效果。为解决这些局限,我们提出 ASTOR,一个通过效用驱动协同进行的多任务代码强化学习框架。ASTOR 围绕任务效用这一信号展开,该信号刻画每个任务的学习潜力和跨任务协同,包含两个耦合模块:1)分层效用路由的数据调度模块,按层次分配训练预算并优先选择信息量大的提示,将训练引向最有价值的数据;2)自适应效用校准的策略优化模块,动态缩放每个任务的 KL 正则强度,使更新约束与该任务当前的训练状态相匹配。我们在两种广泛使用的 LLM 上、针对四项代表性编码任务进行了实验,结果表明 ASTOR 能稳定提升单一模型在所有任务上的表现,优于最佳任务专用专家 9.0%–9.5%,并超过最强的 MTRL 基线 7.5%–12.8%。


研究方向:测试、修复与程序分析

Beyond BLEU: A Semantic Evaluation Method for Code Translation

  • • 作者:Julius Näumann, Sven Keidel, Amir Molzam Sharifloo, Mira Mezini
  • • arXiv URL:https://arxiv.org/abs/2605.05282

Abstract

代码翻译是 LLM 的核心能力之一。然而,评估翻译是否正确仍然很困难,因为像 BLEU 这样的常用指标只衡量句法相似性,而忽略程序语义。我们提出一种新的代码翻译评测方法,强调语义等价而非表层字符串相似度。我们的方法把成熟的编译器测试方法论应用到一个新领域,用于评估一个针对 binary lifting 任务微调的 LLM(即把二进制反编译为更高层表示)。我们引入语义正确性得分,定义为产生正确执行结果的翻译比例,并用它来评估基于 LLM 和启发式的反编译器。结果表明,基于 LLM 的方法显著优于启发式方法,而 BLEU 分数与语义正确性的相关性几乎可以忽略不计(r = -0.127 到 0.354),说明句法指标无法预测功能正确性。


Exploring the Effectiveness of Abstract Syntax Tree Patterns for Algorithm Recognition

  • • 作者:Denis Neumüller, Florian Sihler, Raphael Straub, Matthias Tichy
  • • arXiv URL:https://arxiv.org/abs/2605.06098

Abstract

自动识别算法实现可以通过为代码库中包含的关注点提供知识,从而支持许多软件维护和重工程活动。此外,识别出 Bubble Sort 之类的低效算法并建议更优的库替代实现,也有助于评估和改进系统质量。相关工作中的方法存在可用性和可扩展性问题,而且准确率尚未得到评估。本文研究基于程序抽象语法树(AST)的模式在自动算法识别中的效果。为此,我们实现了一个原型,包括:一种专门用于捕捉算法关键特征的领域特定语言,用它在 AST 上表达搜索模式;一种用于查找这些特征的匹配算法;以及一个初始的“即用型”模式目录。为了生成搜索模式,我们用算法名称和关键特征进行网络搜索,并使用我们的 DSL 描述找到的参考实现。我们在 BigCloneEval 基准的一个子集上评估该原型,其中包含 Fibonacci、Bubble Sort 和 Binary Search 等算法。我们的平均 F1 分数达到 0.74,优于 Codellama 的 0.35。作为对比,我们还使用多个代码克隆检测工具作为基线,召回率达到 0.62,而表现最好的工具仅为 0.20。


Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution

  • • 作者:Ye Shang, Quanjun Zhang, Haichuan Hu, Chunrong Fang, Liang Xiao, Zhenyu Chen
  • • arXiv URL:https://arxiv.org/abs/2605.06125

Abstract

随着生产代码演化,测试套件也必须随之演化,才能保持有效。现有的测试演化基准停留在方法级粒度,并使用预配对输入,绕过了从完整项目中定位受影响测试的任务,也完全排除了新增测试的需要。我们提出 TEBench,这是第一个项目级测试演化基准。给定一个项目仓库和一条会改变代码的提交,TEBench 要求系统自动识别需要修改的测试、判断何处需要新增测试,并生成相应的测试补丁。我们通过在 Defects4J 项目上构建一个四阶段流水线,整理出来自 10 个项目的 314 个任务实例,并提供开发者编写的真值。每个实例都被标注为三类演化类型之一或多种:Test-Breaking(测试失败)、Test-Stale(测试虽然通过,但已不再能有效验证更新后的行为)和 Test-Missing(新增功能需要新测试)。我们评估了 7 种配置,覆盖 3 个工业代理框架(Claude Code、Codex CLI、OpenCode)和 6 个基础模型,以及一个启发式基线。所有 7 种配置在识别任务上的 F1 都收敛到 45.7%–49.4%,显示出跨框架与跨基础模型的共同性能上限。Test-Stale 是最难处理的类型,平均 F1 约为 36%,因为这些配置依赖执行失败信号,缺乏前瞻性的语义推理。在更新任务上,这些配置生成了高度可执行的测试修改,但其表面形式与真值相差很大。轨迹分析揭示了一种反应式的“执行-失败-修复”循环:它对 breaking tests 有效,但在结构上无法处理 stale 或 missing tests。TEBench 可在 GitHub 上获取,并提供 leaderboard。


Teaching LLMs Program Semantics via Symbolic Execution Traces

  • • 作者:Jonas Bayer, Stefan Zetzsche, Olivier Bouissou, Remi Delmas, Michael Tautschnig, Soonho Kong
  • • arXiv URL:https://arxiv.org/abs/2605.06184

Abstract

我们提出了一个评测框架,包含基于 SV-COMP 2025 的 500 个 C 验证任务,覆盖五类属性(内存安全、溢出、终止性、可达性、数据竞争),并对 6 个家族中的 14 个模型进行评估。我们发现,整体准确率很高会掩盖一个关键弱点:虽然大多数模型能够可靠地确认属性成立,但对违规的检测却差异很大,并且会随着程序长度增长而显著退化。为弥补这一差距,我们在形式化验证工件上进行训练:用 Soteria 符号执行引擎在通用开源 C 代码上运行,并使用得到的执行轨迹对 Qwen3-8B 进行继续预训练。仅约 3,000 条 bug 轨迹,再加上推理阶段的 chain-of-thought,就能将违规检测提升超过 17 个百分点,使其成为被评估模型中最均衡的准确率配置之一。在违规检测任务上,经过训练的 8B 模型甚至优于参数规模大 4 倍、但不使用思维链的 Qwen3-32B,并且在整体准确率上也接近后者。轨迹训练与 chain-of-thought 之间呈现超加性:单独使用任一方法都不会带来显著收益,但二者结合后效果明显。改进可迁移到全部五类属性,包括训练轨迹并未直接针对的属性。我们的 28 组配置证实,这些收益来自轨迹语义,而非代码量;同时,轨迹筛选与格式也很重要。


SiblingRepair: Sibling-Based Multi-Hunk Repair with Large Language Models

  • • 作者:Xinyu Liu, Jiayu Ren, Yusen Wang, Qi Xin, Xiaoyuan Xie, Jifeng Xuan
  • • arXiv URL:https://arxiv.org/abs/2605.06209

Abstract

开发者常常会在实现相关功能的多个代码位置犯下相似错误。这些位置被称为 siblings,它们共享相似问题,也需要相似的修复。准确识别 siblings 并保持修复一致性,是自动程序修复的关键。Hercules 是一项面向 sibling 修复的 SOTA 技术,但它受限于对 sibling 位置和提交历史可用性的强假设、基于 AST 的刚性 sibling 匹配,以及不够灵活的模板式补丁生成。为解决这些限制,我们提出 SiblingRepair,一种面向 sibling 修复的新型基于 LLM 的多处修复(multi-hunk)APR 技术。以谱系故障定位识别出的可疑位置为起点,SiblingRepair 通过基于 token 和 embedding 的代码匹配寻找语义相关的 sibling 候选项,而不再把发现过程限制在失败测试覆盖或提交历史上。随后,它使用 LLM 识别与失败相关的 siblings,并通过两种互补策略生成一致的补丁:同时修复(simultaneous repair),即联合修复多个 sibling;以及迭代修复(iterative repair),即逐步分析候选项以构造补丁。SiblingRepair 还会保留此前可疑位置生成的有希望补丁,并将其组合成泛化的多处补丁。我们在 Defects4J 和 GHRB 基准上评估了 SiblingRepair,结果表明它显著优于包括 Hercules 在内的 SOTA 多处修复技术。评估还展示了其修复效率、sibling 检测与修复组件的有效性,以及 LLM 数据泄漏对结果影响有限。总体而言,SiblingRepair 推进了 sibling 以及一般多处自动修复研究。


研究方向:开发流程、需求与治理

Automated Population-Level Audit Assurance via AI-Based Document Intelligence

  • • 作者:Santosh Vasudevan, Velu Natarajan
  • • arXiv URL:https://arxiv.org/abs/2605.05252

Abstract

审计交易测试用于验证客户面向报表的准确性和完整性,并将其与内部记录系统进行对照。传统的人工、基于抽样的非结构化 PDF 报表审查劳动密集,且无法扩展到数百万笔交易。本文提出一个使用 AI 文档智能进行大规模审计交易测试的自动化框架。该方案利用 Snowflake Document AI,从非结构化 PDF 报表中提取结构化数据,仅需少量标注语料(约 20 份文档)。提取的数据再与权威的 source-of-truth 数据集进行对账,以大规模识别差异。结果通过交互式仪表盘和自动化报告呈现。该框架支持面向全量的测试,而不是基于抽样的方法,从而提升审计覆盖率并支持持续保证目标。文档智能和数据分析驱动的审计框架的最新进展,使得可扩展、近实时的风险识别和持续保证成为可能。


An Empirical Study of Proactive Coding Assistants in Real-World Software Development

  • • 作者:Lehui Li, Ruixuan Jia, Guo-Ye Yang, Jia Li
  • • arXiv URL:https://arxiv.org/abs/2605.05700

Abstract

尽管基于大语言模型(LLM)的编码助手已经取得显著进展,但大多数系统仍然是反应式的,需要开发者显式说明需求。主动式编码助手旨在从集成开发环境(IDE)交互和仓库上下文中推断开发者的潜在意图,从而降低交互开销并提供更无缝的辅助。然而,这一方向的研究受限于大规模真实开发者行为数据的稀缺,因此现有研究往往依赖 LLM 模拟的 IDE 轨迹,而这些轨迹与真实开发行为的一致性尚不清楚。本文通过一项大规模实证研究来考察这一“模拟到现实”的差距。我们通过一个定制的 Visual Studio Code 扩展,连续三天收集了 1,246 名有经验的工业开发者的真实 IDE 交互轨迹,并构建了配对的 LLM 模拟轨迹进行对照。分析表明,模拟轨迹在行为多样性、时间结构和探索模式上都与真实轨迹存在显著差异。基于这些数据,我们提出 ProCodeBench,一个面向主动意图预测的真实世界基准。对代表性 LLM、检索增强方法和 agentic 基线的实验表明,在真实 IDE 轨迹上,当前方法仍远未可靠,这说明基于模拟的数据评估可能会高估真实世界表现。最后,我们的训练研究表明,模拟数据不能替代真实数据,但在真实世界微调之前使用时可以作为补充。这些发现强调了真实开发者行为数据对于评估和训练主动式编码助手的重要性。


Operationalizing Ethics for AI Agents: How Developers Encode Values into Repository Context Files

  • • 作者:Christoph Treude, Sebastian Baltes, Marc Cheong
  • • arXiv URL:https://arxiv.org/abs/2605.05584

Abstract

随着 AI 编码代理嵌入软件开发工作流,开发者开始通过在仓库级上下文文件中编码行为规则来将伦理原则操作化,例如 AGENTS.md 文件。与其抽象地考察 AI 代理的伦理,不如研究伦理与价值观如何已经被翻译为可执行指令,从而塑造代理行为。通过一项初步调查,我们发现开发者已经在嵌入与公平、可访问性、可持续性、语气和隐私相关的指导。这些工件充当了由开发者编写的治理层,将抽象原则转化为开发工作流中具体语境下的自然语言指令。我们提出一个研究议程,用于研究这种新兴实践,包括编码后的价值在不同社区之间如何变化、多方贡献者在协商这些文件时会出现怎样的治理动态,以及代理是否能够可靠遵守所规定的约束。理解伦理与价值观如何在现代软件工程实践中被操作化,对于将 AI 治理扎根于现实至关重要。


From Chat to Interview: Agentic Requirements Elicitation with an Experience Ontology

  • • 作者:Dongming Jin, Zhi Jin, Yaotian Yang, Linyu Li, Zheng Fang, Yuanpeng He, Wenchun Jing, Xiaohong Chen
  • • arXiv URL:https://arxiv.org/abs/2605.05828

Abstract

需求获取访谈在需求工程中至关重要且耗时,而且高度依赖需求分析师的经验。尽管大型语言模型(LLM)的最新进展为自动化这一过程带来了新机会,但现有方法仅依赖 LLM 进行自由形式对话,却没有考虑访谈与开发经验。这导致隐式需求被遗漏、重复提问增多。实际上,经验丰富的分析师在进行需求获取时,会隐式遵循一个结构化的认知框架。受此启发,本文提出一种名为 OntoAgent 的访谈代理,它借助经验本体来引导需求获取。OntoAgent 会自动分析领域特定的需求描述,构建一个经验本体,将需求关注点组织进该本体中,以支持系统化且可解释的访谈。在访谈过程中,OntoAgent 首先执行四个由本体引导的操作(ParseUser、ScoreOnto、ReRankOnto、GatePrune),以识别相关需求关注点。随后,将选中的关注点与当前对话上下文结合,生成获取问题。为验证 OntoAgent,我们在广泛使用的网站应用领域进行了全面的定量实验。结果表明,OntoAgent 在获取效果和提问效率上均显著优于现有基线,IRE 提升了 33%,TKQR 提升了 21%。消融实验进一步验证了各关键设计组件的贡献。此外,定性用户研究展示了其在真实场景中的实际优势。我们认为 OntoAgent 也可以扩展到其他领域的需求访谈任务。


Evaluating Non-English Developer Support in Machine Learning for Software Engineering

  • • 作者:Jonathan Katzy, Yongcheng Huang, Gopal-Raj Panchu, Maksym Ziemlewski, Paris Loizides, Sander Vermeulen, Arie van Deursen, Maliheh Izadi
  • • arXiv URL:https://arxiv.org/abs/2605.05902

Abstract

大语言模型正越来越多地被用于软件工程,但代码生成以及其评估仍然主要以英语为中心。这使我们难以理解当前工具对多语言开发的支持程度,而在这类开发中,代码会包含非英语自然语言。本文研究非英语代码注释生成,以及现有评估方法的可靠性。我们评估了五个代码 LLM(CodeGemma、CodeLlama、CodeQwen1.5、GraniteCode 和 StarCoder2)在五种自然语言上的表现:荷兰语、英语、希腊语、波兰语和中文。我们还对 12,500 条生成注释进行了开放式编码研究,据此构建了一个公开发布的人类标注数据集和一个包含 26 种错误类型的分类体系。随后,我们使用这些人工标注来评估神经指标和 LLM-as-a-judge 流水线的表现。结果表明,离开英语后,生成性能显著下降,语言错误最高增加 15.1 倍,同时经常出现不连贯生成和语义错误增加。更关键的是,我们发现非英语注释中的错误检测表现不足。无论是传统的重叠度指标、现成的神经指标、使用更新的多语言、语言特定和代码特定模型扩展后的神经指标,还是 LLM-as-a-judge 流水线,都没有任何自动化方法能提供可靠且一致的评估。神经指标无法区分正确注释、错误输出甚至随机噪声,并倾向于高估非英语场景下的质量。LLM-as-a-judge 方法与人工标注的一致性最高,但仍无法可靠捕捉重要的语言相关错误和语义错误。总体而言,我们的结果表明,评估与生成是多语言工具的关键瓶颈,而人工判断仍然不可或缺。


研究方向:安全、可靠性与供应链

Evolution of Log-Based Detection Rules in Public Repositories

  • • 作者:Minjun Long, David Evans
  • • arXiv URL:https://arxiv.org/abs/2605.05383

Abstract

日志型检测规则仍然是现代安全运营的核心,它们编码了分析师不断迭代的领域知识,以在检测覆盖率与告警数量之间取得平衡。然而,尽管已有工作考察过网络入侵检测签名的演化,日志型检测规则的长期行为却几乎没有得到实证研究。我们给出了首个跨两个广泛使用仓库的检测规则演化纵向分析:社区驱动的 Sigma 项目和经整理的 Splunk Security Content(SSC)。为了比较规则版本时关注检测逻辑而不是表层语法,我们提出 predicate graph 中间表示,用来规范化规则的逻辑结构,并结合树对齐过程分析不同修订之间的变化。我们将该方法应用于 Sigma 和 SSC 的 6,859 条规则历史,发现大约 56% 的规则至少经历过一次检测逻辑修订。在规则生命周期内,演化主要是非单调的,超过一半的规则会随着时间同时增加和删除子句。我们还观察到反复回退,说明这些变化经常被重新审视,而不是简单累积。结合结构分析、基于 LLM 的推断和对操作意图的人类验证后,我们发现大约四分之一到三分之一的规则会在扩展覆盖与减少误报之间交替,而不是收敛到稳定形式。总体来看,这些结果表明,公开仓库中的检测规则演化反映的是持续的运行权衡,而不是单向趋稳。我们的研究也引出了新的问题:规则为何会这样变化,并为更好的规则制定与部署流程提供了研究支持。


Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration

  • • 作者:Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar
  • • arXiv URL:https://arxiv.org/abs/2605.05564

Abstract

持续集成(CI)系统通常并行运行许多构建。在这种环境下,一次合法的构建失败未必是由触发它的代码提交引起的。这类无关构建失败会浪费开发者精力,因为开发者必须判断失败是否与当前变更相关。我们研究了来自 7 个开源 Apache 项目的 77,354 次 CI 构建失败,以理解并预测无关构建失败。我们发现,开发者在判定一次失败与其提交是否相关时,中位数需要 4 小时。我们还对从 10,316 个潜在无关失败中抽样得到的 371 个已确认无关构建失败进行了文档分析。分析显示,无关测试失败占开发者将构建失败判定为无关的案例中的 20%。为了预测无关构建失败,我们从与触发提交相关的 issue 报告、issue 评论和 commit 中提取了 33 个特征。我们为 7 个 Apache 项目构建了半监督的 Positive and Unlabeled(PU)学习模型。模型的 precision 介于 0.70 到 0.88 之间,recall 介于 0.30 到 1.00 之间,F1 在 0.44 到 0.91 之间,AUC 在 0.63 到 0.97 之间。特征重要性分析表明,CI 延迟、重复错误消息以及先前评论数量是判断无关构建失败的有用指标。结果表明,PU 学习可以帮助开发者识别那些不太可能由当前提交引起的构建失败。


On Fixing Insecure AI-Generated Code through Model Fine-Tuning and Prompting Strategies

  • • 作者:Ali Soltanian Fard Jahromi, Amjed Tahir, Peng Liang, Foutse Khomh
  • • arXiv URL:https://arxiv.org/abs/2605.05867

Abstract

AI 生成代码的安全性仍然是其广泛采用的一大障碍。尽管代码生成模型在功能性基准上表现良好,但其输出经常包含 bug 和安全弱点,从而削弱了可信度。已有工作探索了多种缓解 AI 生成代码安全问题的方法,例如使用静态分析引导生成和提示工程;然而,这些方法在不同模型和设置下的效果差异很大。本文系统研究了用于强化模型生成代码、使其抵御一系列 CWE(Common Weakness Enumeration)漏洞的策略。我们评估了这些策略在不同模型和编程语言上的安全提升程度,采用微调和提示两类方法对模型输出进行修正。除了弱点的普遍性之外,我们还分析了所识别 CWE 的严重性、共现关系,以及修复的意外后果,也就是修复某些弱点是否会在同一代码的其他位置引入新的弱点。结果表明,安全改进高度依赖于具体策略和具体模型。尽管某些方法可以减少特定类别的弱点,但它们常常会把新的弱点作为修复的副作用引入进来。此外,没有任何一种策略能在所有模型和场景中持续消除弱点,这说明并不存在一种普适有效、能让 AI 生成代码“刀枪不入”的方案。


Heimdallr: Characterizing and Detecting LLM-Induced Security Risks in GitHub CI Workflows

  • • 作者:Bonan Ruan, Yeqi Fu, Chuqi Zhang, Jiahao Liu, Jun Zeng, Zhenkai Liang
  • • arXiv URL:https://arxiv.org/abs/2605.05969

Abstract

GitHub 持续集成(CI)工作流越来越多地集成大语言模型(LLM),用于自动化审查、分流、内容生成和仓库维护。这带来了一个新的攻击面:外部可控的工作流输入可能塑造 LLM 的提示与输出,而这些输出又可能影响安全决策、仓库状态或特权执行。尽管 LLM 安全与 CI 安全都已被广泛研究,但两者的交叉领域仍然少有探讨。本文给出了首个关于 GitHub CI 工作流中 LLM 引入的安全风险的研究。我们从完整执行链路上刻画这一问题,并提出高层风险类别和具体威胁向量的分类体系。为在实践中检测此类风险,我们设计了 Heimdallr,这是一个混合分析框架:它把工作流规范化为 LLM-Workflow Property Graph(L-WPG),并结合触发可行性分析、LLM 辅助的数据流总结和确定性传播来合成具体的威胁向量结果。我们在 300 个人工标注的唯一工作流上对其进行评估,Heimdallr 在 LLM 节点识别(F1≈0.994)、触发可行性分类(99.8%)和威胁向量检测(micro-average F1≈0.917)上都取得了很高准确率。作为持续检测与披露工作的一部分,我们目前已负责任地披露了 802 个有漏洞的工作流实例,分布在 759 个仓库中,并收到了 71 份确认。


Beyond Accuracy: Policy Invariance as a Reliability Test for LLM Safety Judges

  • • 作者:Shihao Weng, Yang Feng, Xiaofei Xie
  • • arXiv URL:https://arxiv.org/abs/2605.06161

Abstract

LLM-as-a-Judge 流水线已成为代理安全的事实标准评估器,但现有基准把其判定当作真值代理,却没有检查这些判定是依赖于代理行为,还是仅仅依赖于评估策略的措辞。我们认为,任何可信的安全判官都应满足一个基本性质:策略不变性(policy invariance)。我们将其操作化为三条可测试原则:在经认证等价改写下的 rubric-semantics invariance、在有意从严格到宽松的 rubric-threshold 变化下的 rubric-threshold invariance,以及能够感知歧义的校准,使得判定不稳定主要集中在真正有歧义的案例上。我们把这些原则实现为一个压力测试协议,在来自 ASSEBench 和 R-Judge 的轨迹上对四类代理判官进行测试,暴露出一个此前未被测量的失败模式:今天的判官对有意义的规范变化和无意义的结构改写会产生几乎同等强度的反应,而且分不清二者。内容保持不变的策略重写会使高于基线抖动的判定翻转最高达到 9.1%,而所有观察到的翻转中有 18%–43% 出现在这些重写下的无歧义案例中,这说明现有安全分数把代理做了什么与评估器如何被提示混在了一起。除了诊断,我们还贡献了 Policy Invariance Score 和 Judge Card 报告协议,它们揭示出判官可靠性存在数量级上的差异,而这种差异在只看准确率的排行榜中是看不见的。我们发布了协议与代码,以便未来的代理安全基准能够审计自己的评估器,而不是默认信任它们。


Modeling Dependency-Propagated Ecosystem Impact of Changes in Maintenance Activities: Evaluating Support Strategies in the PyPI Network

  • • 作者:Alexandros Tsakpinis, Emil Schwenger, Alexander Pretschner
  • • arXiv URL:https://arxiv.org/abs/2605.06164

Abstract

开源软件生态系统存在密集的依赖网络,维护活动在结构上居中的包一旦出现退化,其影响会广泛传播。尽管人们越来越关注开源可持续性,但现有支持机制缺乏一种显式的、依赖感知的生态级影响概念来指导支持决策。本文提出一种依赖感知的生态影响模型,用来捕捉维护活动的变化如何在 Python Package Index(PyPI)生态中传播并影响整体状态。基于这一模型,我们利用依赖传播意义上的生态影响来优先选择需要支持的包。方法上,我们应用这一框架到一个包含 718,750 个 PyPI 包和超过 200 万条依赖的快照中,并将我们的影响驱动支持策略与现有支持机制(Tidelift、Ecosyste.ms 和 GitHub Sponsors)以及作为结构重要性基线的 PageRank 进行比较。结果表明,如果按照依赖传播影响来排序,所建模的生态影响中大约 80% 可以归因于仅 0.1% 的 PyPI 包。相比之下,外部定义的支持集合与生态影响的对齐程度差异很大。我们进一步分析了维护者可达性和元数据可访问性,发现生态影响、社会足迹和操作可行性是不同但互补的生态支持维度。结论是,依赖感知的生态影响建模为在大规模软件生态中优先开展支持提供了透明且系统化的基础。我们的发现表明,由生态管理者、资助机构和运营支持项目的组织推动的有效支持策略,应当以影响为导向的决策来补充现有分配逻辑。


Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions

  • • 作者:Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao
  • • arXiv URL:https://arxiv.org/abs/2605.06279

Abstract

大语言模型(LLM)如今已广泛参与软件开发工作流,它们生成的代码中经常包含带有特定版本号的第三方库(TPL)导入。这些版本选择可能带来安全和兼容性风险,但此前尚未被系统研究。我们给出首个关于 LLM 生成 Python 代码中版本级风险的大规模测量研究,使用 PinTrace 这一包含 1,000 个 Stack Overflow 编程任务的整理基准,对 10 个 LLM 进行了评估。当直接被要求指定版本号时,LLM 指定版本号的比例为 26.83%–95.18%;而在直接创建清单文件时,这一比例下降到 6.45%–59.19%。在这些被指定的版本中,36.70%–55.70% 的任务至少包含一个已知 CVE,其中 62.75%–74.51% 的严重性为 Critical 或 High。在 72.27%–91.37% 的案例中,相关 CVE 在模型知识截止时间之前就已公开。统计结果表明,所有模型都会收敛到同一小组高风险发行版本,说明这是一种系统性偏差,而不是单个模型的偶发错误。静态兼容率范围为 19.70%–63.20%,安装失败是主要原因。动态测试用例进一步验证了这一模式,pass rate 为 6.49%–48.62%。进一步实验确认,这些失败来自版本选择而不是代码质量,而且外部锚定的版本约束可以显著降低漏洞暴露和兼容性失败。我们的发现表明,LLM 版本选择是一个一等的、此前被忽视的风险面。我们已把这些发现披露给被评估模型的社区,其中一些已经确认了这一问题。所有代码与数据集都已开源。


Constraint Decay: The Fragility of LLM Agents in Backend Code Generation

  • • 作者:Francesco Dente, Dario Satriani, Paolo Papotti
  • • arXiv URL:https://arxiv.org/abs/2605.06445

Abstract

大型语言模型代理在宽松规格下的自主代码生成中表现强劲。然而,生产级软件要求严格遵守结构约束,例如架构模式、数据库和对象关系映射(ORM)。现有基准往往忽略这类非功能性需求,奖励的是功能上正确但结构上随意的解法。我们对代理在多文件后端生成任务中处理结构约束的能力进行了系统研究。通过在 80 个从零开始的生成任务和 20 个功能实现任务上固定统一的 API 合同,并覆盖 8 种 Web 框架,我们结合端到端行为测试与静态验证器,分离出结构复杂度带来的影响。结果揭示了一种“约束衰减”现象:随着结构要求不断增加,代理性能显著下降。表现较强的配置从基线到完全指定任务时,断言通过率平均下降 30 个百分点,而一些较弱配置则接近于零。框架敏感性分析显示出显著差异:代理在更简洁、约束显式的框架(如 Flask)中表现更好,但在更依赖惯例的环境(如 FastAPI、Django)中平均表现更差。最后,错误分析将数据层缺陷,例如错误的查询构造和 ORM 运行时违规,识别为主要根因。该工作强调,同时满足功能与结构要求仍是编码代理的一项关键开放挑战。


研究方向:程序语言、语义与形式化方法

Governed Metaprogramming for Intelligent Systems: Reclassifying Eval as a Governed Effec

  • • 作者:Alan L. McCann
  • • arXiv URL:https://arxiv.org/abs/2605.05248

Abstract

AI 系统越来越多地在运行时合成可执行结构:LLM 生成程序,代理构造工作流,自我改进系统修改自身行为。在经典的同构语言和分阶段语言中,从代码表示到执行的转换是无约束的,eval 只是一个语言原语,而不是受治理的操作。我们认为,在治理化的智能系统中,这种转换是一种权限放大:它把符号结构转化为可执行权限,因此必须像其他效应一样受到调控。我们提出 governed metaprogramming,这是一种语言设计:程序表示(machine forms)是第一类值,形式操作属于纯计算,而 materialization(从形式到可执行机器的转换)则是一个受治理的效应,要接受结构检查。治理系统会先分析所提议程序的能力需求、策略合规性和资源估计,然后才允许执行。我们形式化了两个判断:纯形式求值(不发出任何指令)和受治理的 materialization(恰好发出一条受治理指令)。我们证明了三个性质:形式操作的纯性、no-bypass 定理,以及边界保留。我们在 MashinTalk 中实现了这一设计;MashinTalk 是一个面向 AI 工作流的 DSL,编译为 BEAM 字节码,并与 454 个现有的机器检查 Rocq 定理集成。本文的核心贡献,是把 eval 从语言原语重新分类为一个受治理的效应。


A Practical Specification Language for Automatic Quantum Program Verification (Technical Report)

  • • 作者:Wei-Lun Tsai, Yu-Fang Chen, Ondřej Lengál
  • • arXiv URL:https://arxiv.org/abs/2605.05786

Abstract

Hoare 风格验证为推理量子程序正确性提供了原则性的基础,但现有方法无法实现完全自动化验证。尽管当规范直接以自动机给出时,基于自动机的验证具有良好的扩展性,但以往框架在把高层集合式断言转换为自动机时会产生指数级膨胀,这严重限制了其实用性。我们提出一种扩展的集合式规范语言,以及一种规范到自动机的转换算法,其复杂度在量子比特数量上是线性的,这得益于受控的自动机构造和量子比特重排。由此得到的紧凑自动机使得固定量子比特的量子程序可以在此前不可行的规模上实现完全自动的 Hoare 风格验证,同时在不牺牲效率的情况下显著提升表达能力。


Resource-Constrained Robotic Planning in the face of Mixed Uncertainty

  • • 作者:Yihao Yin, Pian Yu, Andrea Turrini, Zhiming Chi, Yong Li, Lijun Zhang
  • • arXiv URL:https://arxiv.org/abs/2605.05797

Abstract

机器人运行在显著的不确定性之下,从可量化的噪声到不可量化的未知都需要考虑,同时还必须满足严格的运行约束,例如资源有限。本文研究在保证系统永不耗尽资源的前提下,为满足给定任务而合成鲁棒策略的问题。为解决这一问题,我们首先将机器人系统建模为一个 Consumption Markov Decision Process with Set-valued Transitions(CMDPST),这是一个统一框架,可同时建模非确定性动作、可量化与不可量化的不确定性以及资源消耗。然后,我们把 CMDPST 与任务规范结合起来,任务规范用有限轨迹上的线性时序逻辑(LTLf)公式表示。最后,我们解决资源约束下的最优鲁棒策略合成问题,目标是在不耗尽资源的前提下,使满足 LTLf 目标的概率最大化。我们的解法包括两种技术:一种直接的展开法,另一种更高效的优化方法,后者利用状态空间剪枝来提升性能。仓库运输网络上的实验表明了所提方案的有效性。


Infinite-state Games with Energy Objectives Beyond Counters

  • • 作者:Irmak Sağlam, Georg Zetzsche
  • • arXiv URL:https://arxiv.org/abs/2605.05935

Abstract

在无限状态竞技场上的博弈理论中,递归型模型(如 pushdown system 及其扩展)与基于计数器的模型(如带状态的向量加法系统 VASS)之间形成了鲜明对比。对于 pushdown system 及其扩展,存在丰富而成熟的可判定博弈;而在 VASS 场景中,即使是极其简单的博弈也不可判定。这里的 VASS 是一种带计数器的自动机,计数器可以加一或减一,但不能测试是否为零;关键是这些计数器只能取非负值。然而,当采用能量语义时,某些 VASS 博弈会变得可判定:在能量博弈中,系统可以包含负计数器配置,但计数器保持非负的要求转而成为存在玩家的胜利条件。我们在一类更广泛的无限状态系统上研究能量语义的类比,也就是把指令的合法性放在胜利条件中而不是竞技场里,我们将其称为 viability games。具体来说,我们在 graph monoids 上的 valence systems 框架中研究 viability games,其中(允许自环的)无向图指定了多种无限状态系统,例如 pushdown、VASS 计数器、整数计数器以及它们的组合。我们的主要结果是:我们给出了 graph monoids 上 valence systems 的 viability games 的可判定性与复杂性版图的完整描述。结果令人鼓舞。比如,在 pushdown 与计数器的某些组合中,viability games 是可判定的,尽管那里的 non-termination 博弈是不可判定的。甚至在某些系统中,viability games 仍然可判定,而这类系统的(单玩家)控制态可达性却不可判定。


Edit Distance of Finite-Valued Transducers

  • • 作者:Prince Mathew, Saina Sunny
  • • arXiv URL:https://arxiv.org/abs/2605.06269

Abstract

transducer 将自动机推广为:对每个输入词产生一个或多个输出词,从而定义了词之间的关系。若对每个输入词,transducer 最多产生 k 个输出词(其中 k 为某个常数),则称其为 finite-valued;若 k=1,则称其为 functional。两个 transducer 之间的 edit distance 是:对于每个输入词,把一个 transducer 的每个输出转化为另一个 transducer 的某个输出所需的最少编辑次数。对于 functional transducer,这一概念已被研究,并且可计算;但对一般 transducer 而言,它是不可计算的。本文证明了 finite-valued transducer 的 edit distance 是可计算的,而这一类别的表达能力严格强于 functional transducer。


Temporal Causal Models as a Model of Computation

  • • 作者:Maksim Gladyshev, Natasha Alechina, Brian Logan
  • • arXiv URL:https://arxiv.org/abs/2605.06292

Abstract

因果模型,也称结构方程模型(SEM),是一种众所周知的形式,用于表示和推理事件之间的因果依赖。在本文中,我们表明,支持时间推理的 Temporal SEMs(TSEMs)可以被解释为一种计算模型。我们证明了 TSEMs 可以编码线性有界自动机,因此能够表示上下文有关语言中的因果场景。我们还证明了具有可数多个变量的 TSEMs 是图灵完备的。这些结果在因果推理与经典计算模型之间建立了形式联系,使得可以把反事实推理技术从因果推断领域整合进计算理论。


MinMax Recurrent Neural Cascades

  • • 作者:Alessandro Ronca
  • • arXiv URL:https://arxiv.org/abs/2605.06384

Abstract

我们表明,MinMax 代数提供了一种递归形式,它不仅表达能力强,而且实现效率高,最重要的是不会受到梯度消失或梯度爆炸的影响。我们把由多个使用这种递归方式的神经元层级串联而成的模型称为 MinMax Recurrent Neural Cascades(RNCs)。我们证明了 MinMax RNC 具有多项良好的理论性质。首先,它们的形式表达能力包含所有正规语言,这可以看作有限记忆系统的最大表达能力。其次,在给定足够处理器的情况下,它们可以在输入长度的对数时间内并行求值,也可以顺序求值。第三,它们的状态与激活值在任意输入长度下都保持有界。第四,在几乎所有点上,其损失梯度都存在且有界。第五,它们不会出现状态梯度消失:某个状态相对于更早状态的梯度,其值可以始终为 1,而与两者之间相隔多远无关。最后,我们通过实验证据发现,MinMax RNC 的良好理论性质也体现在实际能力上:它们能够完美解决若干合成任务,性能优于我们比较的最先进循环神经网络;此外,我们还训练了一个 1.27 亿参数的 MinMax RNC 进行下一个 token 预测,结果显示该模型在其规模下具有竞争力的表现,说明 MinMax RNC 在真实任务上的潜力。

基本 文件 流程 错误 SQL 调试
  1. 请求信息 : 2026-05-11 18:30:40 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/606769.html
  2. 运行时间 : 0.159307s [ 吞吐率:6.28req/s ] 内存消耗:5,008.49kb 文件加载:145
  3. 缓存信息 : 0 reads,0 writes
  4. 会话信息 : SESSION_ID=1de7f27782adf3f1f6f45dcb4106ddb4
  1. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/public/index.php ( 0.79 KB )
  2. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/autoload.php ( 0.17 KB )
  3. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_real.php ( 2.49 KB )
  4. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/platform_check.php ( 0.90 KB )
  5. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/ClassLoader.php ( 14.03 KB )
  6. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_static.php ( 6.05 KB )
  7. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper.php ( 8.34 KB )
  8. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/helper.php ( 2.19 KB )
  9. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/ralouphie/getallheaders/src/getallheaders.php ( 1.60 KB )
  10. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/helper.php ( 1.47 KB )
  11. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/stubs/load_stubs.php ( 0.16 KB )
  12. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Exception.php ( 1.69 KB )
  13. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Facade.php ( 2.71 KB )
  14. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/deprecation-contracts/function.php ( 0.99 KB )
  15. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap.php ( 8.26 KB )
  16. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap80.php ( 9.78 KB )
  17. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/Resources/functions/dump.php ( 1.49 KB )
  18. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-dumper/src/helper.php ( 0.18 KB )
  19. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/VarDumper.php ( 4.30 KB )
  20. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions_include.php ( 0.16 KB )
  21. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions.php ( 5.54 KB )
  22. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/App.php ( 15.30 KB )
  23. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Container.php ( 15.76 KB )
  24. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/container/src/ContainerInterface.php ( 1.02 KB )
  25. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/provider.php ( 0.19 KB )
  26. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Http.php ( 6.04 KB )
  27. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Str.php ( 7.29 KB )
  28. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Env.php ( 4.68 KB )
  29. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/common.php ( 0.03 KB )
  30. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/helper.php ( 18.78 KB )
  31. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Config.php ( 5.54 KB )
  32. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/alipay.php ( 3.59 KB )
  33. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Env.php ( 1.67 KB )
  34. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/app.php ( 0.95 KB )
  35. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cache.php ( 0.78 KB )
  36. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/console.php ( 0.23 KB )
  37. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cookie.php ( 0.56 KB )
  38. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/database.php ( 2.48 KB )
  39. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/filesystem.php ( 0.61 KB )
  40. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/lang.php ( 0.91 KB )
  41. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/log.php ( 1.35 KB )
  42. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/middleware.php ( 0.19 KB )
  43. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/route.php ( 1.89 KB )
  44. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/session.php ( 0.57 KB )
  45. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/trace.php ( 0.34 KB )
  46. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/view.php ( 0.82 KB )
  47. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/event.php ( 0.25 KB )
  48. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Event.php ( 7.67 KB )
  49. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/service.php ( 0.13 KB )
  50. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/AppService.php ( 0.26 KB )
  51. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Service.php ( 1.64 KB )
  52. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Lang.php ( 7.35 KB )
  53. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/lang/zh-cn.php ( 13.70 KB )
  54. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/Error.php ( 3.31 KB )
  55. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/RegisterService.php ( 1.33 KB )
  56. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/services.php ( 0.14 KB )
  57. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/PaginatorService.php ( 1.52 KB )
  58. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ValidateService.php ( 0.99 KB )
  59. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ModelService.php ( 2.04 KB )
  60. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Service.php ( 0.77 KB )
  61. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Middleware.php ( 6.72 KB )
  62. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/BootService.php ( 0.77 KB )
  63. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Paginator.php ( 11.86 KB )
  64. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/Validate.php ( 63.20 KB )
  65. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Model.php ( 23.55 KB )
  66. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Attribute.php ( 21.05 KB )
  67. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/AutoWriteData.php ( 4.21 KB )
  68. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Conversion.php ( 6.44 KB )
  69. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/DbConnect.php ( 5.16 KB )
  70. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/ModelEvent.php ( 2.33 KB )
  71. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/RelationShip.php ( 28.29 KB )
  72. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Arrayable.php ( 0.09 KB )
  73. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Jsonable.php ( 0.13 KB )
  74. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/contract/Modelable.php ( 0.09 KB )
  75. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Db.php ( 2.88 KB )
  76. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/DbManager.php ( 8.52 KB )
  77. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Log.php ( 6.28 KB )
  78. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Manager.php ( 3.92 KB )
  79. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerTrait.php ( 2.69 KB )
  80. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerInterface.php ( 2.71 KB )
  81. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cache.php ( 4.92 KB )
  82. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/simple-cache/src/CacheInterface.php ( 4.71 KB )
  83. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Arr.php ( 16.63 KB )
  84. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/driver/File.php ( 7.84 KB )
  85. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/Driver.php ( 9.03 KB )
  86. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/CacheHandlerInterface.php ( 1.99 KB )
  87. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/Request.php ( 0.09 KB )
  88. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Request.php ( 55.78 KB )
  89. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/middleware.php ( 0.25 KB )
  90. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Pipeline.php ( 2.61 KB )
  91. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/TraceDebug.php ( 3.40 KB )
  92. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/middleware/SessionInit.php ( 1.94 KB )
  93. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Session.php ( 1.80 KB )
  94. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/driver/File.php ( 6.27 KB )
  95. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/SessionHandlerInterface.php ( 0.87 KB )
  96. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/Store.php ( 7.12 KB )
  97. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Route.php ( 23.73 KB )
  98. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleName.php ( 5.75 KB )
  99. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Domain.php ( 2.53 KB )
  100. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleGroup.php ( 22.43 KB )
  101. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Rule.php ( 26.95 KB )
  102. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleItem.php ( 9.78 KB )
  103. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/route/app.php ( 3.94 KB )
  104. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Route.php ( 4.70 KB )
  105. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/dispatch/Controller.php ( 4.74 KB )
  106. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Dispatch.php ( 10.44 KB )
  107. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Index.php ( 9.87 KB )
  108. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/BaseController.php ( 2.05 KB )
  109. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/facade/Db.php ( 0.93 KB )
  110. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/connector/Mysql.php ( 5.44 KB )
  111. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/PDOConnection.php ( 52.47 KB )
  112. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Connection.php ( 8.39 KB )
  113. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/ConnectionInterface.php ( 4.57 KB )
  114. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/builder/Mysql.php ( 16.58 KB )
  115. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Builder.php ( 24.06 KB )
  116. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseBuilder.php ( 27.50 KB )
  117. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Query.php ( 15.71 KB )
  118. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseQuery.php ( 45.13 KB )
  119. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TimeFieldQuery.php ( 7.43 KB )
  120. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/AggregateQuery.php ( 3.26 KB )
  121. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ModelRelationQuery.php ( 20.07 KB )
  122. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ParamsBind.php ( 3.66 KB )
  123. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ResultOperation.php ( 7.01 KB )
  124. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/WhereQuery.php ( 19.37 KB )
  125. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/JoinAndViewQuery.php ( 7.11 KB )
  126. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TableFieldInfo.php ( 2.63 KB )
  127. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/Transaction.php ( 2.77 KB )
  128. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/driver/File.php ( 5.96 KB )
  129. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/LogHandlerInterface.php ( 0.86 KB )
  130. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/Channel.php ( 3.89 KB )
  131. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/event/LogRecord.php ( 1.02 KB )
  132. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/Collection.php ( 16.47 KB )
  133. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/View.php ( 1.70 KB )
  134. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/View.php ( 4.39 KB )
  135. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Es.php ( 3.30 KB )
  136. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Response.php ( 8.81 KB )
  137. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/response/View.php ( 3.29 KB )
  138. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cookie.php ( 6.06 KB )
  139. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-view/src/Think.php ( 8.38 KB )
  140. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/TemplateHandlerInterface.php ( 1.60 KB )
  141. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/Template.php ( 46.61 KB )
  142. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/driver/File.php ( 2.41 KB )
  143. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/contract/DriverInterface.php ( 0.86 KB )
  144. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/runtime/temp/c935550e3e8a3a4c27dd94e439343fdf.php ( 31.50 KB )
  145. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Html.php ( 4.42 KB )
  1. CONNECT:[ UseTime:0.000493s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
  2. SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000589s ]
  3. SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000543s ]
  4. SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.008819s ]
  5. SHOW FULL COLUMNS FROM `set` [ RunTime:0.000712s ]
  6. SELECT * FROM `set` [ RunTime:0.000212s ]
  7. SHOW FULL COLUMNS FROM `article` [ RunTime:0.000656s ]
  8. SELECT * FROM `article` WHERE `id` = 606769 LIMIT 1 [ RunTime:0.001428s ]
  9. UPDATE `article` SET `lasttime` = 1778495441 WHERE `id` = 606769 [ RunTime:0.017491s ]
  10. SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.005536s ]
  11. SELECT * FROM `article` WHERE `id` < 606769 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000487s ]
  12. SELECT * FROM `article` WHERE `id` > 606769 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.001874s ]
  13. SELECT * FROM `article` WHERE `id` < 606769 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.006009s ]
  14. SELECT * FROM `article` WHERE `id` < 606769 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.001085s ]
  15. SELECT * FROM `article` WHERE `id` < 606769 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.001382s ]
0.161033s