arXiv 论文雷达 2026-05-05
最值得读
| 序号 | 论文 | 链接 | 推荐 | 判断 | 关键信息 | 适合谁读 |
|---|---|---|---|---|---|---|
| 1 | Autonomous LLM Agent Worms: Cross-Platform Propagation, Automated Discovery and Temporal Re-Entry Defense | arXiv HTML | 必读 | 把 agent 安全风险从提示注入推进到持久状态重入：外部内容写进 memory、工作区或计划任务后，未来自动读回上下文并触发传播、提权和外泄。 | 问题：长运行 agent 会把文件、memory、配置和消息状态反复读回 LLM，上游污染一旦进入带工具权限的上下文，就可能驱动授权但恶意的动作。 方法：SSCGV 用源码图分析找 file I/O 到 LLM context 的载体，SRPO 优化能经受摘要和改写的 payload；RTW-A 用污染写入到暴露读取再到高风险动作的链条来做阻断、sealed config、typed memory promotion 和 capability attenuation。 实验：覆盖 3 个生产 agent 框架，报告 31 个可注入持久载体，并展示 zero-click、3-hop 跨平台传播、低权限影响高权限、系统提示和工作区文件外泄。 不足：受披露限制，框架名称、版本、payload 和脚本隐藏，复现性有限；模型覆盖窄，防御假设 runtime 能完整中介读写和高风险动作，真实插件/脚本生态会更难控。 | Agent 安全 / 平台工程 / 安全运营 |
| 2 | EvoPoC: Automated Exploit Synthesis for DeFi Smart Contracts via Hierarchical Knowledge Graphs | arXiv HTML | 必读 | 把 DeFi 审计里最费人的一步自动化：不只发现可疑漏洞，还要合成可执行、可验证、可量化收益的 exploit PoC。 | 问题：DeFi exploit 通常跨合约、跨资产和跨协议状态，手工从漏洞报告走到可复现 PoC 成本很高，很多风险停留在“疑似可利用”。 方法：用分层知识图谱组织协议语义、漏洞根因、攻击步骤、资产流和利用原语，供 LLM agent 多跳规划；再用 SMT 检查路径可达性，用资产级状态模拟验证是否真的能获利。 实验：摘要报告覆盖 88 起真实攻击、72 个审计项目和 2573 个合约；PoC 成功率 96.6%，复现 85 起历史攻击，并在 bug bounty 中确认 16 个 0-day。 不足：需要核验 HKG 人工构建比例、链上状态快照依赖、SMT/EVM 覆盖范围、MEV/滑点/预言机等经济约束，以及历史攻击模板是否带来过拟合；双用风险也很高。 | DeFi 安全 / 智能合约审计 / 攻击验证 |
| 3 | FlexSQL: Flexible Exploration and Execution Make Better Text-to-SQL Agents | arXiv HTML | 必读 | 把 Text-to-SQL 从固定流水线改成可随时查 schema、看数据、跑验证查询并回退计划的交互式数据库 agent。 | 问题：企业分析库 schema 大、语义隐晦，固定 upfront schema retrieval 一旦选错表或漏掉列值编码，后面只修 SQL 很难恢复。 方法：agent 在推理任意阶段探索 schema、检查真实取值、运行 SQL/Python 验证中间假设；生成多个执行计划，用 SQL 或 Python 实现，再做代码级修复和计划级回退。 实验：在 Spider2-Snow 上，gpt-oss-120b 约 65.4%，超过多条强开源基线；公开消融显示多样化 planning、Python executor 和回退修复都有贡献。 不足：测试时查询和 token 成本较高，真实企业库的权限、隐私、查询开销和 SQL 方言差异可能限制部署；细节还要看完整成本和错误分类。 | Text-to-SQL / 数据库 Agent / 企业 BI |
| 4 | AOCI: Symbolic-Semantic Indexing for Practical Repository-Scale Code Understanding with LLMs | arXiv HTML | 值得读 | 给大型代码库先建一张稳定的符号-语义地图，再让 LLM 在这张地图上问答和改代码，方向比每次临时检索更工程化。 | 问题：repo-scale coding agent 的失败常来自上下文构造不稳：检索漏文件、摘要丢约束、临时探索看不到架构边界。 方法：每个文件、表或关键模块形成 index entry，符号标签给架构坐标和依赖位置，语义字段写功能、约束和使用方式，并支持增量维护。 实验：摘要报告 4 个项目、3 个 LLM、6 种上下文条件共 2160 次评估，准确率超过可部署 baseline；19 个工业任务里报告 0 个 final-state defects，token 使用量也明显低。 不足：索引质量决定上限，动态依赖、配置生成、运行时 schema 和跨语言边界不一定好编码；工业任务数量仍小，索引构建和维护成本需要进一步核算。 | 代码库理解 / Coding agent / 软件工程平台 |
| 5 | FunFuzz: An LLM-Powered Evolutionary Fuzzing Framework | arXiv HTML | 值得读 | 把 LLM 输入生成放进多岛进化 fuzzing，用覆盖率和失败信号减少重复探索，目标是更有效地测 GCC/Clang。 | 问题：LLM fuzzing 容易受初始 prompt 和采样方差影响，生成相似输入，覆盖率增长慢，也不容易触发新的 compiler-internal failures。 方法：多个 island 并行探索，从文档生成主题化 prompt，用 coverage 排序候选，周期性迁移高价值输入，并用编译器内部失败信号识别 crash 触发输入。 实验：在 GCC 和 Clang 上做 24 小时重复 campaign，用覆盖率和 unique failures 比较，摘要称优于已有 LLM fuzzing baseline。 不足：还需要看 baseline 调参、重复次数、统计显著性、LLM 调用预算、失败去重和消融；收益可能部分来自更高并行度或采样量。 | Fuzzing / 编译器测试 / LLM for SE |
| 6 | ARIADNE: Agentic Reward-Informed Adaptive Decision Exploration via Blackboard-Driven MCTS for Competitive Program Generation | arXiv HTML | 值得读 | 把竞赛编程生成做成带 blackboard 的 MCTS：策略、代码、测试、评价和修复共用证据，而不是让模型反复一次性写代码。 | 问题：竞赛编程需要先选算法，再处理复杂度、边界和实现细节；one-shot 或简单 self-debug 很容易在局部补丁里打转。 方法：把生成过程拆成 strategy selection、code generation、test generation、quality evaluation、code repair 五阶段，用 blackboard 保存结构化证据，并让 MCTS 在策略和修复空间里探索。 实验：摘要覆盖 APPS、CodeContests、CodeContests+ 和 LiveCodeBench，多种 LLM backend 下 Pass@1 最优，GPT-4o 下最高比 CodeSim 高 26.06 点。 不足：需要确认测试时计算预算、公平 baseline、LiveCodeBench 时间切分和消融；自动测试可能更擅长修浅层实现错误，对高难构造题和证明型题目未必稳。 | Coding agent / 程序生成 / MCTS |