昨天的 arXiv 更进一步了：不只让 Agent 做事，还要让它留下可审计证据

2026-06-18 这批真正值得看的论文，没有停留在“Agent 能不能完成任务”这一层，而是在追问一个更难也更工程化的问题：Agent 的判断怎样才能被外部证据约束、被运行时拦截、被基准协议验证、被后续审计复盘。 这和前几天的主线一脉相承，但昨天的工作更往“闭环系统”推进了一步。仓库级漏洞挖掘开始把静态分析、假设显化、动态复现实验接到一起；SWE benchmark 开始正面处理时间泄漏；GUI/computer-use agent 论文开始从“会不会点击”转向“如何把视觉技能做成可调用资产”；安全方向则在问 skill、sandbox、runtime policy 这些看似外围的东西，是否其实才是 Agent 可靠性的真实边界。

这一天尤其值得读，是因为它把“可靠 Coding Agent”拆成了几条互补但能拼回来的研究线。第一条是仓库级分析闭环：OpenAnt 和 Code-Augur 都说明，LLM 真正有价值的位置不是单独当判断器，而是嵌在可执行验证流程里。第二条是评估协议本身的可信度：SWE-Future 与 SafeClawBench 分别从时间边界和安全端点分离入手，提醒我们 benchmark 设计同样决定结论能否相信。第三条是运行时与工具边界：Runtime Compliance Verification、VISUALSKILL、PhantomSkill 这几篇看似方向不同，实际上都在处理同一件事，即 Agent 一旦进入真实工具和真实软件环境，什么应该被暴露、什么应该被限制、什么应该被记录。

下面的解读基于 arXiv 官方元数据和已下载 PDF 文本。强相关论文均已下载 PDF 并抽取方法、实验和局限；中相关论文也尽量基于正文而不是只看摘要。

今日脉络

昨天的相关论文大致可以整理成四组。

第一组是“仓库级安全 Agent 的证据闭环”。 OpenAnt 用可达性筛选、对抗验证和动态 exploit reproduction 形成漏斗；Code-Augur 则把 Agent 的隐含安全假设写成 assertion，再交给 guided fuzzer 去打脸。它们的共同点是，真正的价值不在“模型说得更像专家”，而在“模型说完以后还能不能被程序反驳”。

第二组是“benchmark 自身是否站得住”。 SWE-Future 讨论公开 issue/PR replay 带来的污染问题，用 forecast-conditioned synthesis 替代直接重放历史 PR；SafeClawBench 则指出 tool-using agent 的安全评估不能只看一个 attack success rate，而要分开看 semantic compliance、audit-visible evidence 和 sandbox-observed harm。

第三组是“运行时边界”。 Runtime Compliance Verification for AI Agents 把 GDPR 约束编成运行时谓词，在工具调用和模型输出层做实时拦截；VISUALSKILL 把 GUI/软件操作知识做成按需加载的多模态 skill；PhantomSkill 则从反方向提醒我们，skill 生态本身就是新的供应链攻击面。

第四组是“软件演化视角的边缘但重要主题”。 Vibe coding 相关论文在问：AI 生成软件之后，传统软件工程里的 variability、artifact evolution 和 change impact 还怎么表达？这些工作实证还薄，但对于 “software evolution in the agent era” 这个更长期的主线非常关键。

强相关论文深读

1. OpenAnt：仓库级漏洞发现开始像一个真正的工程闭环，而不是长上下文读代码

论文信息
标题：OpenAnt: LLM-Powered Vulnerability Discovery Through Code Decomposition, Adversarial Verification, and Dynamic Testing
作者：Nahum Korda, Gadi Evron
分类：cs.CR, cs.LG
发布日期：2026-06-17

一句话 TL;DR
OpenAnt 的真正贡献不是“让 LLM 找漏洞”，而是把仓库级漏洞发现拆成一个逐层收窄、逐层加证据的分析漏斗，让最终发现尽量带着 exploit 级别的外部支撑。

为什么这个问题重要
真实软件仓库里的漏洞挖掘，最难的通常不是“有没有可疑代码片段”，而是怎样在巨大代码面、有限上下文和大量误报之间找到平衡。传统静态分析有成熟的程序结构理解能力，但在真实项目上常被 false positive 淹没；纯动态方法如 fuzzing 又往往只覆盖有限入口和 bug class；如果直接把大模型丢进一个大型 repo，希望它凭长上下文看出关键漏洞，成本和不确定性都太高。对于 repository-level coding agents 来说，这其实是一个非常典型的问题：Agent 不需要无差别读完整个仓库，它需要一套逐层筛选并逐层验证的 workflow。

方法怎么工作
OpenAnt 的 pipeline 可以概括成三个关键阶段，再叠加一个末端的执行闭环。

第一步是结构性缩面。系统先做语言相关 AST 抽取，把代码库切成可分析函数/单元；然后从外部 entry points 出发做 reachability filtering，只保留攻击者可能真正触达的路径。论文给出的数字非常醒目：跨仓库可达性筛选能消掉 83% 到 99% 的函数；在 OpenSSL 中，15,232 个抽取函数先被压到 390 个 reachable units，约 97% 被消掉。接着再做 exposure classification，在 OpenSSL 示例里可进一步收缩到 49 个 externally exposed units。这个设计的意义很直接：它把 “repo-level task” 从“不可能靠提示词读完”的问题，变成“先让结构工具做筛，再让 LLM 看少量高价值单元”的问题。

第二步是LLM 驱动的语义分析和对抗验证。OpenAnt 并不满足于“模型说这里可能有 bug”。它要求候选漏洞进入 adversarial verification：模型要在受限攻击者能力下分析 exploitability，判断这个路径是否真的能被外部触发，而不是只在抽象语义上“似乎有问题”。这一步本质上是在把模型的 reasoning 从“代码 smell 判断”往“攻击者视角下的可利用条件”推。

第三步是动态验证。系统会自动构造 vulnerability-specific exploit environment，把临时 PoC 放进 sandboxed container 执行，执行失败或 build failure 的错误信息还会回流给模型，最多迭代修复若干次测试环境。这里的思路和 fuzzing 不同：它不是覆盖尽可能大的输入空间，而是围绕一个已经被 LLM 与结构分析筛出来的候选点，尝试生成 exploit 级证据。

关键实验与证据
论文最强的证据并不是某个 benchmark 分数，而是 pipeline 各层收缩与证据累加的组合效果。

可达性筛选在多仓库上能消掉 83% 到 99% 的函数，OpenSSL 中 15,232 个函数先缩到 390 个 reachable units。
在同一 OpenSSL 示例里，进一步的暴露分类又把 390 个单元缩到 49 个 externally exposed units。
摘要和正文都强调该流程在 OpenSSL、WordPress、Flowise 等真实开源项目上能发现 previously unknown vulnerabilities，同时显著降低 false positives。

这些数字说明 OpenAnt 的价值不在“比某个 baseline 多几个点”，而在它把仓库级语义分析的搜索空间压到了大模型能有效工作的规模。

局限和可信度
OpenAnt 最大的优点，也是它最大的评估难点：它主要在真实开源项目上验证，而不是依赖容易污染的公开 benchmark。这样做更接近真实工程，但也意味着很难估算 recall，因为真实项目没有完整 ground truth。动态验证也只是“找到 exploit 证据”的充分条件之一，不是形式化安全证明；对于需要复杂环境、并发时序或长期状态累积的漏洞，这种闭环可能仍然覆盖不足。此外，reachability/exposure 的前置分析质量会直接决定 LLM 后面的上限，如果前面把关键路径滤掉了，后面根本看不到。

与当天主题的关系
OpenAnt 几乎可以被当作“验证闭环”这一主题的最强代表。它告诉我们，可靠 coding agent 并不是把模型上下文开得更大，而是把模型嵌入一个能逐层缩面、逐层反证、最终给出执行级证据的仓库工作流里。

2. Code-Augur：比“找到漏洞”更重要的，是把安全判断背后的假设变成可被反驳的对象

论文信息
标题：Code-Augur: Agentic Vulnerability Detection via Specification Inference
作者：Zhengxiong Luo, Mehtab Zafar, Dylan Wolff, Abhik Roychoudhury
分类：cs.CR, cs.AI, cs.SE
发布日期：2026-06-17

一句话 TL;DR
Code-Augur 不只要求 Agent 报告漏洞，还要求它把“为什么认为这里安全”的隐含假设写成 in-source assertion，再用 fuzzer 去否定这些断言。

为什么这个问题重要
当前很多 agentic security 系统最薄弱的地方，不是 positive finding，而是 negative judgment。Agent 报告一个漏洞时，开发者至少知道它在盯哪里；Agent 说“这里没问题”时，往往没人知道它到底依赖了哪些假设。对于真实软件仓库里的程序理解、代码审计、patch correctness 甚至 change review，这都是同一个问题：Agent 的 tacit assumptions 不透明。 如果我们不能把这些假设拿出来检验，就很难建立对 Agent 结论的信任。

方法怎么工作
Code-Augur 的核心是 security-specification-first。

第一步，Agent 对代码进行静态语义分析，推断组件在什么条件下是“安全”的。关键不在于最后一句自然语言结论，而在于局部不变量。论文用 Little CMS 的例子展示，一个 guard 可能只比较 color model 而没有真正约束 channel count；如果 Agent 误以为 guard 已经保证了关键关系，那它的“安全判断”就是建立在错误 assumption 上。

第二步，把这些 assumption 写回源码，变成 assertion。论文反复强调，这些 assertion 不是一般功能断言，而是“支撑安全判断的局部不变量”。一旦 Agent 认为一个组件安全，它就必须把对应的 invariant 提交为程序内可执行对象。

第三步，guided fuzzer 接管。与其让 fuzzer 盲目找 crash，不如让它把 “打破 assertion” 作为浅层但语义明确的目标。论文把这种设计讲得很清楚：对灰盒 fuzzer 而言，崩溃可能太深，但 falsifiable invariant 提供了更容易逼近的目标状态。触发 assertion 之后，系统再做 triage：这可能是漏洞，也可能是 specification 写错了。不管是哪种，Agent 的理解都被迫对齐到真实程序行为上。

关键实验与证据
这篇的结果比很多概念性文章更硬。

在 AIxCC 和 OSV 两类 benchmark 上，Code-Augur 报告比 SOTA agentic systems 多发现 34% 到 370% 的 bug。
在真实开源项目里，论文列出 22 个 previously unknown vulnerabilities，其中 16 个已经被开发者确认或修复。
论文还专门比较了不同底座模型，指出使用 DeepSeek V4 Pro 的 Code-Augur 已经能超过一些依赖更昂贵或更专门化模型的系统结果。

这些数字并不自动说明 “Code-Augur 全面更强”，但至少说明 assertion + falsification 的设计不是只在 paper abstraction 里成立，而是对真实漏洞发现有贡献。

局限和可信度
它的局限也很具体。首先，assertion 的质量仍由模型推导，错误或过弱的 invariant 会把后续 fuzzer 引向无效方向。其次，fuzzer 能否触达断言点，仍然取决于 harness 设计、输入建模和构建环境。第三，像所有 real-world vuln discovery 工作一样，新增发现数量不等于整体 recall 高，特别是在 ground truth 不完整时更是如此。还有一点需要注意：这类系统在 actively developed project 上更容易拿到修复反馈，但在冷门或难构建项目上的行为边界，论文还没有完全展开。

与当天主题的关系
Code-Augur 把“证据锚定”从文本解释推进到了程序对象层。它不是让模型写更长的 reasoning trace，而是让 reasoning 的关键前提变成 assertion，再交给执行系统去反驳。这和用户关注的 agent reliability、verification、audit 非常对齐。

3. SWE-Future：SWE benchmark 终于开始正面处理“历史 PR replay 其实可能已经被模型见过”

论文信息
标题：SWE-Future: Forecast-Conditioned Data Synthesis for Future-Oriented Software Engineering Agents
作者：Qiao Zhao, JianYing Qu, Jun Zhang, Yehua Yang, Hanwen Du, Zhongkai Sun
分类：cs.SE, cs.AI
发布日期：2026-06-17

一句话 TL;DR
SWE-Future 的重点不是再造一个更大的 benchmark，而是给 SWE agent 任务构造引入时间边界：用 T0 之前的 repo evidence 预测未来 task family，再基于预测合成任务，而不是直接重放后来发生的 PR。

为什么这个问题重要
repository-level coding agent 的评估已经走到一个尴尬阶段：越真实的 benchmark，越可能被公开 issue、PR、博客、训练数据和 benchmark-driven tuning 污染。直接 replay GitHub 历史任务当然逼真，但“逼真”和“可作为未来泛化评估”并不总是一回事。对于 software change intelligence 这个方向来说，任务集本身如果带着未来信息或历史重放依赖，模型结果就很难解释。SWE-Future 正面承认了这个问题，并试图给出一个更时间一致的构造方式。

方法怎么工作
论文的方法边界画得很清楚。

第一步，在 forecast snapshot T0 之前，收集每个 repository 的 issue、PR、label、文本和演化信号，形成 pre-T0 evidence。
第二步，基于这些信息预测未来的 task families，覆盖 feature implementation/enhancement、bugfix、refactor 三类。
第三步，冻结 forecast 后，只用 T0 之后真实出现的 PR 做 retrospective validation，检查这些 forecast family 是否真的对应未来 repo work。
第四步，只有通过 strong 或 related relevance 检验的 families，才会被当作条件信号去合成 coding-agent task；这些任务来自 task-generation snapshot，而不是直接复制后来的 PR。

这背后的研究姿态很对：later PR 只用于验证预测是否靠谱，不直接进入公开任务构造。 这让 benchmark 至少在设计上摆脱了“历史补题”。

关键实验与证据
论文的数字并不夸张，反而因此更可信。

retrospective validation pool 覆盖 80 个 repository；forecasting 实际在 76 个 repo 上产出 260 个 families。
其中 strong+related 的 future-work relevance 为 151/260，即 58.1%；更严格的 strong hit rate 为 42.7%。
bugfix family 是最容易形成可用任务方向的类别，89/139 达到 strong+related；feature/enhancement 更难，45/93 达到 strong+related。
最终合成出 200 个 coding-agent tasks，覆盖 61 个 repositories。

这些结果说明 repository evolution 确实能提供未来任务信号，但远没有强到可以当 oracle。恰恰是这种“中等但真实”的结果，让它比很多高分但边界不清的 benchmark 论文更值得认真看。

局限和可信度
最大的局限在于 relevance 仍然只是“未来工作语义相关”，不是“未来真实修改任务完全等价”。也就是说，forecast 到了一个正确方向，不代表最终构造的 task 一定保留了真实 repo 的隐式约束、测试难点和环境依赖。其次，58.1% 的相关度意味着还有相当比例的 family 最终不成立，说明 forecasting 本身是 noisy 的。第三，合成任务如何避免“看起来像真实 repo task，实际上仍然是 benchmark artifact”的问题，仍需更多 executable validation 和后续 agent 评测来补。

与当天主题的关系
SWE-Future 是“评估可信度也是 Agent 可靠性的一部分”的代表。它把 attention 从模型本身拉回 benchmark construction protocol，这对 software change engineering 社区非常必要。

4. Runtime Compliance Verification for AI Agents：把 Agent 运行时行为变成可拦截、可审计的政策执行问题

论文信息
标题：Runtime Compliance Verification for AI Agents
作者：Nafiseh Kahani, Masoud Barati, Diana Addae
分类：cs.SE
发布日期：2026-06-17

一句话 TL;DR
C-Trace 不是做更多 red teaming，而是把 GDPR 类约束编成运行时谓词，拦截每一次工具调用和模型输出，让 agent compliance 从“测过了”变成“执行时真的守住了”。

为什么这个问题重要
很多 Agent 可靠性工作默认问题出在回答内容本身，但真实系统里，违规往往发生在工具调用、状态变化和历史上下文之间。例如某次营销邮件发送，在当前 turn 看起来无害，但如果之前没有 consent，它就是违规的。对于真实企业/工业场景，这和 user research 方向的“alignment”不是一回事，而是更接近 policy-as-code 和 runtime enforcement。对复杂工程平台同样如此：只靠离线 red teaming 或静态 prompt review，无法保证部署后每次执行都守住边界。

方法怎么工作
论文提出 C-Trace（Compliance Trace-based Runtime Agent Conformance Enforcement），核心是 trace-level runtime monitor。

第一步，系统把用户消息、tool calls、consent、erasure 等统一编码成 typed event model。
第二步，把 GDPR 的部分要求形式化成 predicate，包括 consent、purpose limitation、data minimization 和 right to erasure。
第三步，runtime monitor 拦截每次 tool invocation 和 model output，在事件序列上在线评估这些谓词，一旦发现 violation 就拒绝动作。
第四步，用 attack dialogues 压测系统，包括 DSPy 生成的 prompt 和真实 red-teaming corpus 中的 verbatim prompts，测试 agent 是否会在复杂对话和多步状态下违规。

这里最重要的是：它不是单条消息分类器，而是显式依赖事件历史，因此能处理“是否已有 consent”“是否已声明 purpose”“是否先前提出 erasure request”这类必须看 trace 才能判断的问题。

关键实验与证据
论文给出的结果非常明确。

在四个 case studies 上，exact extraction 时 monitor 可以把 attack success rate 和 false positive rate 都压到 0%。
在 10% per-category extractor noise 条件下，ASR 保持在不高于 12%，FPR 保持在不高于 16%。
case studies 覆盖 retail、customer support、healthcare、banking/KYC 等四种场景，并涉及 consent、purpose limitation、data minimization、erasure 四类规则。

这组结果的重要意义不在于“数值接近 0”，而在于它把合规问题从离线测评变成了运行时控制。对于我们关心的 agent quality assurance，这种思路比单纯多做一些 red team prompts 更接近真实工程。

局限和可信度
论文的限制也很清楚。它依赖一个事件抽取层，extractor 噪声直接影响最终效果；而且当前 formalized 的是 GDPR 子集，不是一般性的 policy language。0% ASR/0% FPR 只在 exact extraction 下成立，不应被误读为部署级保证。还有一个更深层的限制：如果应用侧没有把 consent capture、purpose metadata、tool semantics 结构化暴露出来，runtime monitor 其实无从判断。

与当天主题的关系
这篇把“Agent 安全边界”落到了运行时 enforcement 上。对于真实软件工程环境里的 tool-using agents，这是比 prompt hardening 更稳的一条线。

5. SafeClawBench：Agent 安全评估不能再把“答应攻击”和“真的造成伤害”混成一个指标

论文信息
标题：SafeClawBench: Separating Semantic, Audit-Evidence, and Sandbox Harm in Tool-Using LLM Agents
作者：Yuchuan Tian, Mengyu Zheng, Haocheng Mei, Ye Yuan, Chao Xu, Xinghao Chen, Hanting Chen, Yu Wang
分类：cs.CR, cs.AI
发布日期：2026-06-16

一句话 TL;DR
SafeClawBench 的关键贡献不是 600 个攻击样例，而是把 Agent 安全失败拆成三个端点：semantic acceptance、audit-visible evidence、sandbox-observed harm。

为什么这个问题重要
tool-using agent 的失败路径比纯文本模型复杂得多。一个模型可能在语义上“同意攻击”，但没有真正调到危险工具；也可能文本上没明显违规，却在工具或状态层造成了 harm。如果 benchmark 只报一个统一 ASR，就会把这些 failure mode 混在一起。对于 agent reliability 和 safety auditing 来说，这会严重误导分析：你根本不知道问题出在模型意图、证据链、还是执行层。

方法怎么工作
SafeClawBench 构建了一个 staged benchmark。

第一层是 Semantic Core：判断模型是否在语义上接受了攻击目标。
第二层是 harm-evidence audit：对 canonical CoreFail rows 做审计，检查是否有 artifact-visible harm evidence。
第三层是 Exec-Balanced executable panel：把任务放进 sandbox，看是否真的发生 state/tool harm。

benchmark 共 600 个 controlled adversarial tasks，覆盖六类攻击：direct/indirect prompt injection、tool-return injection、memory poisoning、memory extraction、ambiguity-driven unsafe inference。论文把这些端点分别命名为 CoreFail@600、HarmEvidence@600、ObservedHarm@Exec 等，不再把它们压成一个总分。

关键实验与证据
这篇最值得记住的是几组“端点不一致”的数字。

600 个受控攻击任务，五个 agent endpoints，四个 prompt policy。
无额外 prompt protection 时，不同模型的 semantic failure rate 从 9.0% 到 44.2% 不等。
在 12,000 行 matched Core–Exec join 中，347 行出现 executable harm，其中 291 行发生在语义层“通过”核心检查的样本里，也就是 CorePass∧ExecHarm。
审计层统计中，canonical CoreFail audit 覆盖 1,834 条语义失败行，其中 959 条有 evidence-supported harm，873 条只是 semantic-only failure。

这几组数字直接说明：如果你只看 semantic ASR，就会漏掉相当一部分执行层 harm；如果你只看 exec harm，又会忽略很多“模型其实已经明显被攻破，只是没触发状态变化”的样本。

局限和可信度
SafeClawBench 的局限主要在于 benchmark abstraction。尽管它已经比许多工作更细致，但仍是受控场景集合，很多真实工具的副作用不可逆、跨系统、跨时间，而 benchmark 需要把 harm 定义得足够明确才能自动判定。不同 policy 的效果也强依赖具体 harness 和 endpoint protocol，未必能直接外推到用户自己的 agent 系统。

与当天主题的关系
这篇对“Agent 质量验证与审计”极其贴题。它提醒我们，评估端点设计本身就是研究对象，不应该被藏在一个单一成功率背后。

6. VISUALSKILL：computer-use agent 的技能不该只写成文字说明，图本身就是技能的一部分

论文信息
标题：VISUALSKILL: Multimodal Skills for Computer-Use Agents
作者：Ziyan Jiang, Li An, Yujian Liu, Jiabao Ji, Qiucheng Wu, Jacob Andreas, Yang Zhang, Shiyu Chang
分类：cs.CL
发布日期：2026-06-16

一句话 TL;DR
VISUALSKILL 的核心不是“给 CUA 一个技能库”，而是证明技能 artifact 如果只保留文字、丢掉界面图像，会系统性损失对 UI 元素定位和状态验证的帮助。

为什么这个问题重要
repository-level coding agents 之外，computer-use agents 是另一类高价值真实环境：长任务、未见软件、复杂状态、操作错误代价高。GUI/软件使用场景和真实工程工具链高度相关，尤其是 IDE、浏览器、办公工具、构建仪表板、配置界面、移动/桌面应用等。过去很多 skill library 都把技能做成 text-only instructions，但软件交互本来就是视觉密集型任务。纯文本很难精确表达某个按钮的位置、菜单的展开状态、对话框在什么情况下会长什么样。

方法怎么工作
VISUALSKILL 设计成一种 hierarchical multimodal skill artifact。它不是一次把整本操作手册塞给 agent，而是先给一个中心索引，再通过 load_topic MCP tool 按需加载具体 topic 的文字和图。技能构建分两阶段：先把已有文档解析成 topic 化结构，再通过 live application UI exploration 补足真实界面截图和状态示例。这样 agent 在每一步只拿到当前子任务需要的 topic，而不是把整个 skill 库放进上下文。

这套设计有两个值得注意的点。第一，它把“技能”从 prompt 文本提升成了有文件布局、有索引、有加载协议的资产。第二，它明确把视觉 figure 视为技能本体的一部分，而不是先 verbalize 再交给模型。

关键实验与证据
论文在两个 CUA benchmark 上做了直接对照。

在 CUA-World 和 OSExpert-Eval 共 177 个任务上，Claude Code CLI agent 的平均分从 no-skill 的 0.303 提升到 VISUALSKILL 的 0.456，绝对提升 +15.3 points。
与同源内容生成的 text-only skill 比较，VISUALSKILL 从 0.373 再提升到 0.456，绝对多出 +8.3 points。
论文特别指出，收益在 unseen UI 和 long-horizon workflow 上更明显，说明多模态 skill 的价值不只是初始说明，而是帮助 agent 在执行过程中反复对照和验证当前状态。

这组结果对真实软件工程 agent 非常有启发：很多复杂平台任务失败，不是因为模型不会推理，而是它对外部界面的 state grounding 太弱。

局限和可信度
VISUALSKILL 仍然是 benchmark 环境，不等于真实生产软件的无限多样性。技能构建需要文档和 live exploration 成本，跨版本界面漂移也会削弱 skill 的稳定性。另外，它目前更像“提升操作成功率的 skill artifact 设计”，还没有和 repo-level code modification、构建反馈、端到端测试验证真正串起来。但作为 “agent workflow + evidence grounding” 的外围组件，它非常值得关注。

与当天主题的关系
这篇把“证据锚定”扩展到了 GUI 场景：图像不是装饰，而是 agent 判断 UI 状态、定位控件、确认操作后果的证据载体。对复杂工业平台和跨平台迁移场景，这条线尤其有价值。

中相关论文速读

PhantomSkill：skill 生态会不会成为 coding agent 的新供应链攻击面？

PhantomSkill: Malicious Code Injection in Agent Skill Ecosystems 很值得放在中相关的高位。它不是软件变更论文，但和 coding agent 生态直接相关。作者展示了一种攻击框架：不在 SKILL.md 这种显眼的文本描述里写恶意指令，而是把恶意行为藏到 skill 的辅助资源里，再通过 VulMask 把 overt malicious scripts 伪装成“普通但有漏洞的实现”，只在攻击者控制的 trigger 条件下激活。这个设计把可见信号从“明显恶意”转成“看起来只是安全性差的代码”，从而降低自动审查和 LLM reviewer 的告警概率。

这篇和当天主线的边缘关系在于：一旦 skill 成为 Agent 获取能力的机制，skill package 就相当于新的工具依赖和供应链。论文不是在做 repo change engineering，但它提醒我们，“给 Agent 安装能力”本身就是工程风险面。为何不必深挖到强相关？因为它主要研究攻击与检测，不直接讨论 repo 修改、验证闭环或软件演化；不过在安全边界上它非常值得保留。

From Specification to Execution：LLM 不是直接写 workflow code，而是先把 specification 变成中间层

From Specification to Execution: AI Assisted Scientific Workflow Management 的问题场景是 scientific workflow，而不是日常代码仓库维护，但方法论和真实工程很接近。论文明确反对“用户一句自然语言，模型直接生成一堆 workflow code”的套路，而是插入 specification phase，把 intent、design、implementation 分离。系统将 Pegasus WMS 接到 MCP layer 上，再配一个 debugging agent 处理多层失败。

实验对象是联邦学习医疗影像 workflow，论文声称系统能生成并执行 thousands of jobs 的大规模工作流，并降低 debugging effort。对我们的主题来说，可保留的判断是：复杂执行型系统更适合 specification-driven 中间层，而不是直接 synthesis。为何没有升到强相关？因为场景更偏 scientific workflow lifecycle，而非软件仓库变更；其验证证据也偏系统演示，尚不足以支撑更强的泛化结论。

Vibe Coding Ate My Homework：绿地编程任务的“可行”不代表真实软件工程任务的“可靠”

Vibe Coding Ate My Homework 是一篇很像“问题界定论文”的工作。它尝试评估 vibe coding 在 simple, isolated greenfield Python tasks 上的可行性，同时也反思现有 benchmark 怎样测这类能力。和当天主线的关联在于，它把话题拉回一个经常被忽略的点：很多“AI 做软件工程”实验其实只是在测 scoped toy task，而不是 repository-level change。

这篇值得保留的判断是：如果任务是隔离的小型绿地编程，模型表现可能看起来不错；但这并不能自然外推到真实仓库、执行反馈、测试反馈和多文件修改。之所以没有更深挖，是因为它目前更像 benchmark/viability discussion，和用户主线中的仓库级变更闭环贴合度有限。

Where Did the Variability Go?：AI 生成软件把变化点提前到了 generation time

Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration 是昨天最适合放在“概念上重要、证据上尚早”的论文。作者分析 10 个 vibe-coded C/C++ 项目后认为，这类软件几乎没有传统 compile-time/runtime variability，变体决策在 generation time 就被固定了。于是论文提出 Variability by Regeneration：把 variability 放在 declarative specification 中，让 LLM 作为 derivation engine，为每个 variant 生成 purpose-built binary，再由 dispatcher 路由请求。

为什么和当天主题有边缘关系？因为它直指 “software evolution in the agent era”。如果软件不再是长期维护的一棵配置化代码树，而是一组可反复再生成的 artifact，那么 change engineering 的单位、验证方式和回归分析逻辑都可能改变。为什么不进强相关？因为当前证据主要基于 10 个项目和一个 wc product family 演示，离可泛化设计原则还有距离。

可留意 / 可跳过

Toward Semantically-Seeded, Graph-Propagated Impact Analysis Across Software Artifacts: A Vision：这是和用户主线最贴的 vision paper 之一。它提出把 requirement、config、service、test 乃至 metrics/dashboard 都放进 heterogeneous artifact graph，用 semantic prior 加 structural propagation 做 change impact analysis。为什么这里只放“可留意”？因为目前只是 5 个 labelled scenarios 的 proof-of-concept，方向极好，但证据还远不够强。保留关键词：跨 artifact 变更影响分析、semantic + graph fusion、training-free and interpretable。
AI Sandboxes: A Threat Model, Taxonomy, and Measurement Framework：这篇对 agent evaluation infrastructure 很重要，尤其是 fidelity、controllability、observability、containment、reproducibility 这些维度的框架化。但它是宏观 taxonomy/framework paper，不直接落在 coding agent 改代码或仓库验证上。保留关键词：sandbox weakest-link evidence、threat model for assurance apparatus。
A Technical Taxonomy of LLM Agent Communication Protocols：如果你在关心多 Agent 系统工程化，这篇有长期价值；但对当天“软件变更工程”主线来说偏基础设施。保留判断：协议分层和 schema flexibility 以后会成为 agent ecosystem 的真实技术债。
Compute-Budgeted Exploitability Evidence Graphs for Prospective Vulnerability Triage：与 coding agent 不直接同类，但对“时间边界”非常有启发。只保留一个判断：前瞻性安全评估如果偷看未来证据，指标可以虚高数倍。

横向比较

论文	主要问题	证据类型	工程可迁移性	可信度风险
OpenAnt	仓库级漏洞发现如何缩面并验证 exploitability	reachability、对抗验证、动态复现	很高	真实项目缺少完整 ground truth，动态验证不等于完整覆盖
Code-Augur	Agent 的安全判断如何显性化并可反驳	in-source assertions、guided fuzzing	很高	specification 质量和 fuzz harness 决定上限
SWE-Future	SWE benchmark 如何减少历史 PR replay 污染	temporal boundary、forecast validation、task synthesis	很高	forecast relevance 中等，合成任务真实性仍需后续验证
Runtime Compliance Verification	Agent 运行时合规如何 enforce	trace predicates、runtime monitor、attack dialogues	高	依赖事件抽取层，当前政策语言范围有限
SafeClawBench	工具型 Agent 安全评估该看什么端点	semantic core、audit evidence、sandbox harm	很高	受控 benchmark 抽象仍与真实系统有距离
VISUALSKILL	computer-use agent 如何利用多模态技能提升可靠性	on-demand topic loading、文字+图像 skill artifact	中高	skill 构建成本高，界面漂移可能削弱稳定性

我的判断

维度	评分 / 判断
创新性	8/10。真正有新意的不是又一个 Agent，而是把验证、时间边界、端点分离、skill artifact 这些“系统约束”拉成主角。
实用价值	8.5/10。OpenAnt、Code-Augur、Runtime Compliance Verification、VISUALSKILL 都很像可以被拿来改造真实系统设计的工作。
严谨性	7.5/10。强相关论文整体比只报 benchmark 分数的工作更重视证据，但很多评估仍受真实 ground truth 缺失、样本规模有限、或 benchmark abstraction 影响。
与用户方向相关度	A-。昨天最贴主线的是 repo-level security analysis、future-oriented SWE evaluation、runtime policy enforcement，以及 GUI/computer-use skill 设计。OpenHarmony/HarmonyOS 没有直接命中，但 VISUALSKILL 和 runtime enforcement 的方法对复杂工业平台同样高度相关。

如果只记住昨天的一条主线，我会选这句：可靠 Coding Agent 的核心竞争力，不是“更像一个会写代码的模型”，而是“它的判断、动作和失败都能被外部证据、时间边界和运行时机制接住”。