[{"content":"论文链接：https://arxiv.org/abs/2503.18666v3\n论文主旨 # ICSE 2026，主要研究Agent运行时的安全约束，设计跨领域、易插拔的模块化框架用于规范Agent行为并降低风险。\nAgent不同于大模型，它能够感知环境、并调用工具影响外界环境。这意味着Agent的错误不同于LLM，它会切实地造成现实中的严重后果，需要严格地规范和审查。\n该论文认为不同的使用场景对Agent行为的风险容忍度不同，不能只依赖一套通用的安全策略，现实中需要的是可定制的运行时安全边界。然而，现有的方法还存在较大缺陷：\n在动作执行前让另一模型来评估风险。然而交予大模型进行判断的质量不稳定，且可解释性弱，还可能受到提示词的影响。 只做风险评估，并没有真正拦截，无法在运行时生效。 因此，该论文提出了一个适用于Agent运行时生效、可自定义的规则语言：AgentSpec。不只是在动作执行前进行预测，而是在运行时进行检查，并调用对应的处理逻辑。主要将Agent的安全问题抽象成“事件-谓词-执行”的统一处理逻辑，将一条规则抽象成“trigger-check-enforce”，即当Agent在处理对应事件时，如果满足对应条件，则执行对应的干预命令。\n出发点 # 单纯的LLM更多是生成文本回答问题，无法感知现实世界并与外界环境进行交互。而Agent不一样，能够自主使用工具感知环境和影响环境，如Code Agent能够使用文件IO感知本地代码，修改或执行本地代码、联网检索资源等。故Agent在运行时的错误带来的风险和影响远大于LLM，需要规范Agent在运行时的行为。\n此外，同样的行为在不同的场景可能需要不同的约束规则。如自动转账可以在内部测试环境里自行执行，但在现实生产环境中必须有人工授权或确认。\n故该论文旨在设计一套泛用的、可无缝接入Agent的框架，拦截关键执行阶段以执行用户定义的约束。\n创新点 # 传统的减少Agent运行风险的方法有两种，但各有优劣：\n基于LLM的风险评估虽然有效，但缺乏可解释性，且没有设计安全执行机制； 基于规则的防护提供了可审查、可解释的替代方案，但目前的实现要么太死板僵硬，要么缺乏跨Agent架构的通用性。 而AgentSpec则基于Neural-Symbolic思想，将LLM的泛化能力与硬规则的确定性逻辑有机结合，构建了一个可插拔且泛Agent的运行时安全框架。\n方法流程 # 论文中选用LangChain框架作为AgentSpec嵌入载体，通过拦截LangChain的Agent迭代循环中的关键决策点(动作执行前、观察产生后，任务完成时)来插入规则执行。其整体流程图如下：\nLangChain核心循环是“接受输入-\u0026gt;生成计划-\u0026gt;执行动作-\u0026gt;获取observation-\u0026gt;进入下一步”，而AgentSpec则在其基础上增量添加了额外步骤。\n常规Agent流程 # UserInput: 用户输入，最初始任务和上下文数据来源\nAgent-Plan：根据上下文和轨迹，基于LLM生成计划动作，若已完成任务则输出。\nAgent-Execute：根据计划，调用工具执行动作，得到执行后的Observation\nAgent-Update：根据新的Observation更新Agent状态，并记录新的轨迹，继续返回Agent-Plan进行循环迭代\nAgentSpec流程 # 离线流程 # 收集系统需要遵守的外部约束来源，并拆解成一系列“行为-条件-处理”的候选规则单元\n确定每个规则单元的Trigger(before_action, state_change, agent_finish \u0026hellip;)，将外部约束绑定至一类可监控的运行时切点\n设计规则单元的Check，将自然语言描述的风险条件转变为可求值逻辑条件\n为每个规则单元确定Enforcement，并最终整理成DSL规则，创建形式化规则模板\n在线流程 # 在Agent执行的关键节点(AgentAction, AgentStep, AgentFinish)拦截，获取当前状态、动作和轨迹等信息，并以此来匹配Trigger于此对应的规则，若无对应规则则放行\n根据上下文信息，对Check求值，不成立则放行\n根据对应规则，调用对应的处理逻辑，并根据处理结果更新轨迹，改写Agent运行轨迹\n局限 # 只能在遭遇特定事件、满足特定条件时才能触发安全机制，无法做到提前预测\nAgentSpec的最终能力与predicate的质量强相关，而LLM自动生成的能力还不够稳定，无法做到开箱即用，需要人工预先定义\n","date":"2026-07-05","externalUrl":null,"permalink":"/posts/2026-07-01-agentspec-customizable-runtime-enforcement-for-safe-and-reliable-llm-agents/","section":"帖子","summary":"论文链接：https://arxiv.org/abs/2503.18666v3\n论文主旨 # ICSE 2026，主要研究Agent运行时的安全约束，设计跨领域、易插拔的模块化框架用于规范Agent行为并降低风险。\n","title":"AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents","type":"posts"},{"content":"","date":"2026-07-05","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026-07-05","externalUrl":null,"permalink":"/","section":"Hello, I am Ruk1a.","summary":"","title":"Hello, I am Ruk1a.","type":"page"},{"content":"","date":"2026-07-05","externalUrl":null,"permalink":"/tags/icse/","section":"Tags","summary":"","title":"ICSE","type":"tags"},{"content":"","date":"2026-07-05","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026-07-05","externalUrl":null,"permalink":"/categories/%E8%AE%BA%E6%96%87%E7%A0%94%E8%AF%BB/","section":"Categories","summary":"","title":"论文研读","type":"categories"},{"content":"这里用于发布技术帖子、论文研读、教程、复盘与阶段更新。\n","date":"2026-07-05","externalUrl":null,"permalink":"/posts/","section":"帖子","summary":"这里用于发布技术帖子、论文研读、教程、复盘与阶段更新。\n","title":"帖子","type":"posts"},{"content":"论文链接：https://dl.acm.org/doi/abs/10.1145/2568225.2568310\n论文主旨 # 发表于2014 ICSE，主要研究self-adaptive system。\n在传统软件工程系统中，需求分析负责研究需要解决的问题，而架构设计主要研究如何解决好问题。但在系统上线部署后，环境、负载和用户需求不是一成不变，架构和需求需要在运行时进行调整，需要设计动态变化的self-adaptive system。\n现有的两种主流方法存在明显缺陷：\n需求驱动的自适应理想地认为一个需求可以映射到一个具体的架构元素，然而现实的业务需求和架构组件之间的关系驳杂\n架构驱动的自适应认为需求不会改变，只需要在运行时调整参数或者重构即可。然而现实需求是动态变化的，需要在运行时动态调整\n故针对上述问题，该论文提出了”架构设计决策模型“，用作沟通需求层和架构层的桥梁，将其有机结合起来，在运行时进行动态适应，并通过QVT-R脚本自动进行增量模型变换。\n出发点 # 现实生产环境不是一成不变的，具体业务需求也是动态变化的，故运行时的自适应需要从两方面考虑：具体业务需求和系统架构及技术决策。已有方法要么只从具体业务需求出发，要么只从架构出发，这两种方法都存在缺陷。需求和架构之间不是一对一的简单映射，而是杂糅的多对多关系，中间还包含设计决策知识。\n如网购系统的促销活动会导致短时间内流量暴涨，请求数暴增，拖慢响应时间甚至导致后台服务宕机。这时有两种自适应思路：\n系统架构和技术层面的优化：并发优化，负载均衡等\n具体业务需求的调整和目标降级：限制接口的QPS，给高频请求的IP设置冷却时间等\n该论文认为运行时自适应应该有机结合上述两种不同层级的决策，即有机结合架构层和需求层。\n创新点 # DesignDecisionsModel # 提出了一个运行时自适应框架，包括需求层、设计决策层和架构层。通过引入设计决策层，将需求目标和架构调整方案链接起来。设计决策层的模型如下：\n需求层中的HardGoal(如订单验证)、SoftGoal(如响应速率)和Task统一抽象为Intention，通过MotivationLink关联到DesignIssue，链接具体设计问题和需求目标；DesignIssue(如日志)下有多个DesignOption(如日志级别)；同时DesignOption又通过ImpackLink影响SoftGoal(不同方案对速率、安全性等有不同影响)；Context和DependencyLink用于约束设计决策的搜索空间，InterferenceLink用于约束架构变换的执行顺序。\n系统可通过\u0026quot;Intention -\u0026gt; DesignIssue -\u0026gt; DesignOption -\u0026gt; ArchitecturalModification\u0026quot;链路，联通需求层和架构层，先选出更合适的目标规格和设计方案，再将其映射为具体的架构变换。\n新的最优目标规范选择策略 # 传统的最优目标规范是所有的软目标满意度加权和最大的哪个，该论文认为专注提高整体质量满意度容易导致个别软目标满意度极低，不利于构建高可用的、健壮的系统。故该论文使用了新的策略：优先满足尽可能多的软目标期望，即优先选择N-Score最高的目标规范，并列时选择P-Score最高的目标规范。该策略能够选出与预计期望的缺口最小的方案，即最稳定、健壮的方案。\n负偏差得分N-Score = sum(pref(g) * Δ(g, GS)) in (Δ(g, GS) \u0026lt; 0) ，即任意软目标(g)在对应GS(目标规范)的缺口值的加权和\n正偏差得分P-Score = sum(pref(g) * Δ(g, GS)) in (Δ(g, GS) \u0026gt; 0) ，即任意软目标(g)在对应GS(目标规范)的超额收益的加权和\n方法流程 # 以文中的在线购物系统为例。\n1.RunningSystem # 监控运行时质量值以及上下文值，获得原始数据信息。\n质量值Q_t = (吞吐量, 响应时间, 支付响应, 校验响应, 资源占用, \u0026hellip;) 上下文值C_t = (并发请求数, 工作负载水平, \u0026hellip;) 运行时监控数据R_t = (Q_t, C_t) 输出RuntimeData(R_t)\n2.AnalyzerEngine # 根据RuntimeData进行聚合分析，更新软目标期望向量E_t(初试值E_0人工预设)，并生成适应请求。\n输入数据为：R_t = (Q_t, C_t) 软目标期望向量E_t = {exp_t(g1), exp_t(g2), \u0026hellip;, exp_t(gn)} exp_t(gi)表示时刻t对软目标(gi)的期望满足水平，exp_t(gi) in [-1, 1] 适应请求AR_t = (E_t, C_t) 发送AdaptationRequest(AR_t)给决策模块\n3.DesignDecisionsAdaptationManager # 设计决策模块首先在当前需求规格不变的前提下，基于设计决策模型搜索最优设计方案。\n输入数据为：AR_t = (E_t, C_t) 偏差值Δ(g, DS) = sat(g, DS) - exp_t(g)，即在设计方案DS下，任意软目标(g)与期望的差值 负偏差得分N-Score = sum(pref(g) * Δ(g, GS)) in (Δ(g, GS) \u0026lt; 0) ，即任意软目标(g)在对应GS(目标规范)的缺口值的加权和 正偏差得分P-Score = sum(pref(g) * Δ(g, GS)) in (Δ(g, GS) \u0026gt; 0) ，即任意软目标(g)在对应GS(目标规范)的超额收益的加权和 最优设计方案DS* = argmax_{DS in F} (N(DS), P(DS))，即在满足约束的设计方案中，优先选择N-Score最大的，并列时选择P-Score最大的 找到DS*时，直接输出DesignSolution(DS*)给TransformationGenerator；否则进行需求适应，重新选择更合适的目标规格。\n4.RequirementsAdaptationManager # 当设计决策模块在当前需求规格下无法找到可行设计方案时，需求适应模块被触发，在目标模型中重新选择更合适的目标规格。\n输入数据为：目标模型(GM)、软目标期望向量(E_t)、软目标偏好权重(pref(g)) 候选目标规格GS = {t1, t2, \u0026hellip;, tk}，ti 表示一个叶子任务 最优目标规格GS*选择策略与最优设计方案一致 找到GS*时，将其返回给DesignDecisionsAdaptationManager，重新搜索最优设计方案；否则结束本轮适应，不执行新的调整。\n5.TransformationGenerator # 当获得新的设计方案DS*后，根据旧设计方案与新设计方案之间的差异，自动生成 QVT-R 模型变换脚本。\n输入数据为：旧设计方案DS_old，新设计方案DS_new\n根据方案差异进行计算：\nO_remove = DS_old \\ DS_new O_add = DS_new \\ DS_old O_keep = DS_old ∩ DS_new 干扰关系集合I = all_(oi, oj)，即oi的修改可能影响oj的修改的关系对 通过干扰关系集合I进行执行顺序限制，使用类似拓扑排序思维的算法对操作进行排序(C(oi, oj)：当oi不是任何干扰边的target或所有干扰oi的source都不在当前集合中时)，最终得到不会互相干扰的执行顺序\n输出有序的ModelTransformationScripts T = {t1, t2, t3 \u0026hellip; tk}\n6.ArchitectureTransformer # 架构变换模块按照顺序执行ModelTransformationScripts，对当前运行时架构模型进行增量式变换。\n输入数据为：当前架构模型(M)，模型变换脚本(T) 按脚本顺序执行t1, t2, \u0026hellip; tk, 将M转换为M* 输出AdaptedModel(M*)\n7.ExecutionEngine # 执行模块根据变换前后的架构模型差异，对真实运行系统进行重构与重配置。\n输入数据为：当前架构模型(M)，变换后架构模型(M*) 模型差异ΔM = M* - M，其可能包含add/remove component, add/remove link, turn parameter value 将脚本语句映射成具体的系统操作并执行 最终完成运行时架构变换 、\n局限 # 论文的方法依赖三个预设模型：GoalModel、DesignDecisionsModel和ArchitectureModel，只能自适应处理预期内的新需求，无法应对预期之外的新需求。因此不能自动生成真正的新架构设计，只是在预设的解空间范围内自适应地构建最适合当前需求的架构，属于闭世界的自适应方法。 DesignDecisionsModel依赖人工维护，需要预先根据设计决策方法建立对应的设计决策模型，无法自动构建。 搜索空间可能组合爆炸导致OOM。GoalModel中只要OR分解变多，可能的GoalSpecifications就会迅速增长；设计决策层同理。 ","date":"2026-07-03","externalUrl":null,"permalink":"/posts/2026-07-01-self-adaptation-through-incremental-generative-model-transformations-at-runtime/","section":"帖子","summary":"论文链接：https://dl.acm.org/doi/abs/10.1145/2568225.2568310\n论文主旨 # 发表于2014 ICSE，主要研究self-adaptive system。\n","title":"Self-Adaptation through Incremental Generative Model Transformations at Runtime ","type":"posts"},{"content":"论文链接：https://arxiv.org/abs/2509.21427\n论文主旨 # 主要研究如何增强LLM的根据bug/issue定位相关文件或代码的能力，提出了一种类似GraphRAG思想的issue localization增强方案。\n该论文认为，目前的LLM在代码仓库中定位bug/issue相关代码或函数的能力不足，经常失效。这是因为LLM主要关注具体的文件、代码、函数，缺少了宏观的整体视角。一个业务的具体逻辑经常混杂在复杂的函数内部，又分割在多个不同代码文件之间，LLM只关注具体代码容易忽视业务逻辑之间的联系。\n因此，该论文提出了RepoLens框架，先离线构建代码仓库的概念知识库，用于增强LLM定位issue的能力，在LLM需要定位时在线检索知识库，将结果注入定位的prompt中，增强LLM根据bug/issue定位相关代码的能力。\n出发点 # Issue localization: 根据bug/issue描述，自动找出最可能出问题的相关文件或函数。\n论文中提到，在真实的大项目中，问题定位很难，主要可以归结为两个现象：\nconcern tangling：业务逻辑相互混杂在同一函数中，单个业务相关的逻辑只占其中一小部分 concern scattering：一个业务对应的逻辑分散在多个函数或者文件中 即同一业务相关的逻辑常常碎片化分散在不同的函数或文件中，而同一函数又常常混杂了不同的职责和逻辑，LLM看到的是具体的代码和文件，却不容易看到这些分散的代码实则属于同一业务。 因此，该论文提出一种方法，通过离线构建概念知识库，将代码库中的相关业务逻辑重组为宏观的高层conceptual knowledge，便于LLM进行代码定位。\n创新点 # 基于类似GraphRAG的From local to global思想，提出了更加高内聚、低耦合的concern概念，作为代码仓库与具体bug/issue描述的自然语言之间的中间表示层。不同于常规的函数或代码摘要，concern主要是业务逻辑级别的，不局限与任一函数、任一文件，只关注具体语义名词在仓库中的逻辑脉络。通过构建高层语义关注点”concern“，便于检索与bug/issue中描述相关的业务概念，并溯源定位相关的代码和文件 提出了两阶段框架RepoLens，类似GraphRAG的”离线构建知识图谱和社区摘要-\u0026gt;检索图谱召回知识进行检索增强生成“。先离线构建代码仓库的conceptual knowledge库，再通过检索召回相关业务逻辑片段，嵌入定位prompt中增强LLM的bug/issue定位能力 方法流程 # 主要分为离线构建与在线检索定位两个阶段，总体流程类似GraphRAG，都存在离线构建知识库，在线检索召回提供可靠依据两阶段，最终也是将召回信息注入prompt实现检索增强。\n离线构建：\nTerm Extraction：从整个代码仓库中抽取term，即函数或变量名中的group、user、message等名词，这类名词通常是issue描述中常见的业务概念，可以作为连接具体代码实现和Issue中自然语言描述的中间层。 Term Explanation：利用LLM对每个term进行语义增强，主要包括拓展并规范term的名称、解释term的含义、总结代码中与term相关的功能语义、抽取相关的代码片段作为依据。 Knowledge Base Construction：将上述处理后的term信息组织成结构化的数据，构建一个仓库级的概念知识库。 在线检索定位：\nBug/Issue Keyword extraction：从issue的标题中提取关键词，重点提取其中的名词。 Term Retrieval：通过提取的关键词，在离线构建的知识库中检索相关的term。通过使用n-gram分解，尽可能地召回与issue相关的概念。 Concern Clustering：使用层次聚类方法先做预聚类，结合term中属性的向量相似度和函数之间的调用关系，将候选term划分为较小子集；再使用LLM分析其中的功能关联，聚合成高层的concern，并生成concern summary。 Concern Ranking：先基于语义向量相似度对concern进行粗筛，选出top-50 concerns，在使用LLM结合issue的标题和内容对concern做精排，最终召回top-10 concerns。 Prompt Building：将召回的concerns组织成结构化上下文，注入LLM/Agent的issue localization prompt中。 ","date":"2026-07-01","externalUrl":null,"permalink":"/posts/2026-07-01-extracting-conceptual-knowledge-to-locate-software-issues/","section":"帖子","summary":"论文链接：https://arxiv.org/abs/2509.21427\n论文主旨 # 主要研究如何增强LLM的根据bug/issue定位相关文件或代码的能力，提出了一种类似GraphRAG思想的issue localization增强方案。\n","title":"Extracting Conceptual Knowledge to Locate Software Issues","type":"posts"},{"content":"","date":"2026-07-01","externalUrl":null,"permalink":"/tags/se/","section":"Tags","summary":"","title":"SE","type":"tags"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"这里用于集中承载 GitHub 动态与 RSS / Stream 等外部信息源。后续可以在这里扩展更完整的动态流。\n","externalUrl":null,"permalink":"/activity/","section":"动态","summary":"这里用于集中承载 GitHub 动态与 RSS / Stream 等外部信息源。后续可以在这里扩展更完整的动态流。\n","title":"动态","type":"activity"}]