arXiv 每日速递 2026-05-20

今日总结

今天 arXiv 的 SE/Agent 板块密集出现了一组「把 Agent 当成研究对象本身」的论文：Reversa 用多 agent pipeline 把 COBOL legacy 系统逆向成 AI agent 能消费的"运营规范"；SkillGenBench 把"agent 是否能生成可复用 skill"独立成一个 benchmark 问题；EnvFactory 用极少的真实环境合成 agentic RL 训练数据；AI for Auto-Research 则给出了 AI 介入科研全周期的可靠/不可靠边界图。这四篇放在一起读，能看到一条清晰的趋势线：当 LLM 已经能 work，社区正在转向"度量每个 agent 组件的边际价值与失败模式"，而不再做端到端炼丹——这恰好是博客主人这两年一直主张的方向。

今日全览

论文	方向	核心贡献	与我们的相关度
Reversa	Legacy migration / Multi-agent SE	多 agent pipeline 把 legacy 代码逆向成可溯源运营规范，COBOL→Go ATM 案例	⭐⭐⭐
SkillGenBench	Agent benchmark methodology	把"skill 生成"从 skill 使用中剥离，做成独立 benchmark	⭐⭐⭐
EnvFactory	Agentic RL / env synthesis	85 个真实环境合成 2575 条 trajectory，少环境也能 outperform	⭐⭐
AI for Auto-Research	AI lifecycle roadmap	四阶段 taxonomy + 可靠/不可靠分界	⭐⭐

今日主题：Agent 时代的"组件评估学"正在成形

如果你 follow 过去两年 agent 领域，应该能感觉到一个明显的转向。2023–2024 是"我能不能把 X 任务跑通"的时代，论文标题里全是 SWE-bench pass rate、AgentBench score、tau-bench 之类的"端到端胜率"。但从今天这四篇就能看出 2026 的主旋律已经变了：

• Reversa 不汇报"我们 COBOL→Go 端到端成功率多少"，而汇报"517 个 claim 带 confidence、10 个 gap 保留给人类、9/11 个 reconstruction task 完成"——它把 agent pipeline 拆成可独立审计的 artifact。
• SkillGenBench 明确指出："prior benchmark 把 agent 当成一个整体在评估，但 skill generation 本身就值得作为独立研究对象"。这是把博客主人一直在做的"边际价值量化"思想推到了 benchmark 层。
• EnvFactory 揭示"用 5× 更少的环境却能 outperform"——隐含的潜台词是：之前社区在用 brute force 扩 environment 数量，但真正的瓶颈是数据合成质量与 implicit intent 还原，而非数量。
• AI for Auto-Research 直接画出了"AI 在哪些科研阶段可靠、哪些会幻觉"的分界图——这是博客主人"AI for SE 边际价值"哲学在科研 lifecycle 上的镜像。

放在一起看，这四篇都在做同一件事：把 agent 从一个黑盒拆开，分别度量每一层的真实贡献和失败模式。这正是博客主人这两年坚持的研究哲学——不做端到端炼丹，做边际价值实证。今天值不值得读？值得。这是趋势线性外推的一天，但每篇都有可以直接抄作业的具体方法。

---

Reversa: A Reverse Documentation Engineering Framework for Converting Legacy Software into Operational Specifications for AI Agents

推荐理由：直击博主 Android→HarmonyOS 迁移主线——同样是 legacy 跨平台迁移，同样是多 agent pipeline，同样强调 confidence / traceability / 人类保留 gap。COBOL→Go 是教科书级别的难例，方法论可以直接套用到 ArkTS 迁移工具链。

📌 论文信息：Sanderson Oliveira de Macedo, Ronaldo Martins da Costa | arXiv:2605.18684 | cs.SE / cs.AI

TL;DR

不要让 coding agent 直接读 COBOL 源码，而是先用一组专门 agent 把 legacy 系统逆向成带置信度、带 traceability 的"运营规范"，再喂给目标语言生成 agent。这把"理解"与"翻译"分离了——和博主一直主张的"static analysis 做定位、LLM 只负责修复"是同一种职责切分哲学。

问题是什么？

legacy 系统迁移本质上是个"上下文还原"问题，而不是"代码翻译"问题。一个 30 年的 COBOL ATM 系统里，80% 的业务规则散落在维护补丁的 if-else、配置文件的魔数、特殊员工口述的"这里千万别动"里——这些东西不在 spec、不在文档、甚至不在 commit message 里。直接把 COBOL 喂给 GPT-5.5 让它写 Go，模型会"看起来"把语法翻译对了，但悄悄丢掉了 30% 的隐式业务约束。

社区已经发现的痛点：(a) LLM 没有可靠的 "I don't know" 信号，会自信地编造业务逻辑；(b) 没有 traceability，出问题不知道是哪个推理步骤幻觉的；(c) 隐式假设和异常处理分支会被静默吞掉。Reversa 想解决的是：怎么让 legacy 迁移变成可审计的工程过程，而不是一锤子炼丹。

他们怎么做的？

核心 Insight：把"逆向工程"做成一个多 agent 的协作流水线，每一步产出 traceable claim + 显式 confidence + preserved gap，让人类审计员只需要看 confidence 低的部分。

具体方法流程：

1. Surface mapper agent：扫描 project 整体结构，输出模块依赖图，定位"哪些文件是入口、哪些是数据层"——这一步完全 deterministic，不让 LLM 介入推理。
2. Module analyzer agent：在 surface map 基础上，针对单模块做深度分析，提取函数签名、数据流、状态机。
3. Implicit rule extractor：这是关键步骤——专门去抠"代码里写了但 spec 里没说"的隐式规则（如错误处理分支、魔数、unconventional 状态转换）。每个 claim 必须带 (a) 源代码 anchor、(b) confidence score、(c) "我对这个 claim 有多确定"的自述。
4. Architecture synthesizer：把模块级 claim 升华成架构级 spec。
5. Spec writer + reviewer：写 unit-level spec，并用一个独立的 review agent 检查每个 claim 是否真的有源码 anchor（防止 hallucination）。
6. Gap preservation：如果某个 module agent 自己也不确定，显式保留为 gap 给人类——这一点很关键，不是兜底，而是产品设计。

跟之前方法的本质区别：传统 codebase summarization tool（如 GitHub Copilot 的 repo index）追求"覆盖率"，Reversa 追求"可追溯性 + 显式 uncertainty"。这与"GenAI for legacy modernization"（如 IBM watsonx Code Assistant）的 end-to-end 翻译路线相反——它把翻译延后到"先有可信 spec 再说"。

关键结果

指标	Reversa 在 COBOL→Go ATM 案例
提取 claim 总数	517
显式登记的 gap	10
Gherkin parity 场景	53
Reconstruction task 完成	9 / 11
是否完成 cutover validation	否

结果解读：作者非常诚实——明确说 final parity validation 和 cutover 都还没完成。这种诚实在 LLM × SE 论文里非常少见，反而比那些动辄"端到端 95% 准确率"的论文可信。值得注意的是 confidence index 的设计：与其追求 100% 自动化，不如把不确定部分主动暴露给人。这种"显式 epistemic humility"的设计是 Reversa 最值得抄的部分，比任何具体 agent prompt 都更值得借鉴。

局限性与开放问题

• 局限 1：单一案例研究（一个 ATM）不足以支撑泛化结论。COBOL 是一种特别"自描述"的语言（DIVISION 结构、命名硬约束），换到 Java、C++、Pascal 不一定能复刻。博客主人的 HarmonyOS 迁移做 Android→ArkTS，要先验证 ArkTS 的逆向是否能产出同样可靠的 claim 流。
• 局限 2：confidence 来自哪里？论文里讲了"internal confidence index"，但没有 calibration——也就是说，confidence 0.8 是否真的对应 80% 准确率？这是个根本性缺陷。博主做 LLM-as-Judge 的工作里也踩过这个坑：自报 confidence 几乎都 over-confident，需要做 isotonic / Platt calibration。
• 开放问题：traceability 在多 agent 链条上会指数级稀释——一个 claim 来自 module agent 引用 architecture agent 的输出，而 architecture agent 又综合了 5 个 surface agent。当出错时怎么定位是哪一跳的责任？这是博主 agent marginal value 工作可以切入的角度。

💡 对我们的启发

1. 直接可用的技术点：博主的 Android→HarmonyOS 迁移工具链可以完全照搬这套 multi-agent reverse engineering 架构。具体地：

   • 把现在的"Android XML → ArkUI 直接翻译"流程改成"先用 reverse agent 提取 UI 行为 spec → 再翻译"两步走
   • 把 confidence index 和 gap preservation 写进 HomeCheck 的下一版输出，明确标出"这部分修复 confidence < 0.6, 需要人 review"
   • 借鉴 Gherkin parity scenario 的思路，给每个被迁移的 Activity 产出一份"功能 parity 验证表"

2. 具体实验想法（1-2 周可验证）：拿你现在已有的 Android→HarmonyOS 迁移数据集（应该有几十个 demo 项目），跑两组对照：

   • A 组：直接 LLM 翻译（DeepSeek-Coder 14B + 标准 prompt）
   • B 组：先用 Reversa 风格的 reverse engineering agent 提取 spec，再翻译
   • 观察指标：(a) 编译通过率；(b) 行为 parity 测试通过率；(c) 隐式业务规则保留率（手动 annotate 一个 ground truth）。预期 B 组在 (c) 上显著优于 A 组，但在 (a) 上可能持平甚至略差——这是非常 publishable 的结果，因为揭示了"翻译质量"和"语义保真"的 trade-off。

3. 研究趋势判断：Reversa 代表了 LLM × Legacy Modernization 的范式转变——从"翻译质量"转向"语义保真 + 可审计性"。博主可以提前在 ArkTS 生态卡位，因为 HarmonyOS 自带"系统级文档要求严格"的产业属性，对可审计性的需求比 Android 高。这是个 OpenHarmony 工具链里被严重低估的卡位机会。

---

SkillGenBench: Benchmarking Skill Generation Pipelines for LLM Agents

推荐理由：直击博主 benchmark methodology 主线。把 agent skill 生成从 skill 使用中剥离出来做独立 benchmark——这正是博主反复主张的"边际价值量化"的 benchmark 化形态。

📌 论文信息：Yifan Zhou, Zhentao Zhang, Ziming Cheng, Shuo Zhang, Qizhen Lan | arXiv:2605.18693 | cs.AI

TL;DR

现有 agent benchmark 都在问"agent 能不能用这个 skill 完成任务"，但 SkillGenBench 退一步问："agent 能不能从一坨 repo 或 doc 里自己生成可用的 skill"。它把 skill 生成做成独立的 benchmark 问题，分 task-conditioned 和 task-agnostic 两种模式，分 repo-grounded 和 doc-grounded 两种来源。

问题是什么？

agent 领域有个长期被忽视的循环依赖：你想测 agent 的 reasoning 能力，但 agent 表现高度依赖于它能调用的 skill 库；skill 库要么是人工标注的（贵且窄），要么是 agent 自己生成的（但生成质量没有独立评估）。结果就是：好 skill 库下的渣 agent 看起来比渣 skill 库下的好 agent 更强，混淆了两者的贡献。

更糟的是，agent skill 生成本身的失败模式没人系统研究过——agent 从 repo 抽 skill 时会幻觉哪些 API、从长文档蒸馏 procedure 时会丢哪些约束、什么时候会产出 over-fitting 单任务的 skill、什么时候会过度泛化丢细节，都是黑盒。

他们怎么做的？

核心 Insight：把 skill 生成单独装进盒子，给它定义标准化的 input/output contract——generator 接收原始 corpus 输出标准化 skill artifact，artifact 在固定 harness 下执行，用 deterministic execution-based check 评估。整个 benchmark 把"skill 生成"和"skill 使用"完全解耦。

具体方法流程：

1. Generation regime 二分：
   • Task-conditioned：先告诉 generator 任务，再让它合成针对性 skill（容易，但泛化弱）
   • Task-agnostic：先让 generator 蒸馏出 reusable skill library，再揭晓下游任务（难，更现实）
2. Procedural source 二分：
   • Repository-grounded：从 code/config/script 里分散提取
   • Document-grounded：从 long-form text 里蒸馏
3. 标准化 artifact + pinned environment + execution-based eval：每个 skill 必须能在固定环境里 deterministic 跑出可验证结果，配合诊断信号定位失败模式。
4. Failure mode taxonomy：作者特别报告 repository 来源和 document 来源的 failure 模式不同——repository 容易抓 syntactic 但丢约束，document 容易抓约束但实现错。

跟之前方法的本质区别：MetaGPT、Voyager 这些工作里 skill 库本来就是流程的一部分，但没有人单独评估它——你不知道 skill 库占了多少功劳。SkillGenBench 第一次把这个变量隔离出来。

关键结果

维度	报告的差异
Task-conditioned vs task-agnostic	显著 gap，agnostic 难度高得多
Repo-grounded vs doc-grounded	failure mode 类型不同（前者丢约束，后者错实现）
不同 backbone	跨 backbone 变异性"substantial"
不同 skill gen method	也"substantial"

结果解读：论文没给具体百分比（abstract 没披露），这倒不是缺点——重点在 benchmark protocol 本身而不是 leaderboard。值得关注的是它发现 repo 和 doc 两种 source 失败模式类型完全不同，意味着 agent skill gen 不是单一能力，应当分维度训练和评估。

局限性与开放问题

• 局限 1：execution-based check 只能验证"skill 能跑过"，不能验证"skill 跑得对"。一个 skill 可能 happy path 全过，但在 edge case 静默错——而 edge case 才是工业落地的真问题。
• 局限 2：task-agnostic 模式里"reusable"如何定义？同一个 skill 在 task A 和 task B 都被调用算不算 reusable？还是要看复用时的修改幅度？这个 metric 没明确。
• 开放问题：skill 生成质量和 backbone 大小的 scaling law 是什么？是否存在某个 sweet spot 让 7B 模型也能生成质量过得去的 skill？这是博主 small/local LLM 主线可以切入的角度。

💡 对我们的启发

1. 直接可用的技术点：博主做 Cangjie / ArkTS 这种低资源语言生态时，最大的痛点之一就是"没有现成 agent skill 库"。SkillGenBench 提供的两阶段框架（先 repo-grounded 提取，再 doc-grounded 补全）可以直接落地成 ArkTS skill harvesting 工具——从 OpenHarmony 官方文档 + GitHub 上为数不多的 ArkTS 仓库里自动生成 skill 库。
2. 具体实验想法（1-2 周可验证）：
   • 选 3 个 7B 级开源 code 模型（DeepSeek-Coder 7B / Qwen-Coder 7B / StarCoder2 7B）
   • 各自跑 SkillGenBench 的 task-agnostic + repo-grounded 配置
   • 观察哪个 backbone 在 repo→skill 蒸馏上 failure mode 最少
   • 关键的实验设计点：不要直接看 final accuracy，要做 ablation——固定 skill 库，换 agent；固定 agent，换 skill 库。这才是博主一贯的"边际价值"分析范式
3. 研究趋势判断：SkillGenBench 是把 benchmark 从"agent overall capability"切向"agent component capability"的标志性工作。博主可以做的 follow-up：在 SkillGenBench 之上加一层"skill quality calibration"指标，类似博主在 process quality vs outcome correctness 里做的 Cohen κ / Gwet AC1 一致性框架。这能直接出一篇 ICSE / ISSTA 短文。

---

EnvFactory: Scaling Tool-Use Agents via Executable Environments Synthesis and Robust RL

推荐理由：和博主 agent trace 分析主线高度相关。EnvFactory 揭示了"少而精的 environment 优于多而糙"——这是博主"边际价值"思想的另一种证明，85 个环境就能击败之前用 5× 环境的方法。

📌 论文信息：Minrui Xu, Zilin Wang, Mengyi Deng, Zhiwei Li, Zhicheng Yang | arXiv:2605.18703 | cs.CL / cs.LG

TL;DR

agentic RL 卡在两个问题：(a) executable environment 少；(b) trajectory 数据 over-specified，更像 instruction list 而不像真实人类 implicit intent。EnvFactory 用 85 个环境（跨 7 个 domain）合成出 2575 条 SFT + RL trajectory，让 Qwen3 在 BFCLv3 涨 15%、MCP-Atlas 涨 8.6%——用 1/5 的环境数量打过之前 SOTA。

问题是什么？

社区做 agentic RL 时一直绕不开两个相互纠缠的瓶颈：

1. 环境瓶颈：真实 API 调用太贵（commercial cost + rate limit），LLM 模拟的环境会幻觉，pre-collected document 类的环境又只能 single-turn 没状态。
2. 数据瓶颈：合成的 trajectory 过度详细化，把"用户其实只说了一句话，agent 自己推理出 5 步"这种 implicit intent 推理过程显式写成 prompt，结果训出来的 agent 在真实人类模糊指令前完全垮掉。

之前社区的解法是 brute force——堆更多环境、堆更多 trajectory。结果是越堆越偏离真实分布，越训越像"扮演 agent 的演员"，而不是真正能推断意图的 agent。

他们怎么做的？

核心 Insight：少而精的 stateful environment + topology-aware sampling 优于多而糙的环境堆量。环境质量 > 环境数量，trajectory 自然性 > trajectory 数量。

具体方法流程：

1. 自动环境探索 + 验证：从 authentic resource（真实 API、真实 codebase）出发，让 agent 自己探索可达的 stateful tool 调用图，构建 executable env——比 LLM-sim 更可靠，比 commercial API 更便宜。
2. Topology-aware sampling：在工具调用图上做拓扑感知采样，确保 trajectory 覆盖各种 dependency pattern（不是均匀采样，而是按拓扑结构关键节点采样）。
3. Calibrated refinement：合成的初版 trajectory 经过 calibration——专门去模糊化 over-specified 的指令，让 query 看起来更像真实人类的"含糊但有 implicit intent"的请求。
4. Robust RL：在合成数据上做 SFT + RL，专门优化 robustness 而不是 peak performance。

跟之前方法的本质区别：之前工作如 AgentTuning / FireAct 默认"环境越多越好"，所以拼命扩 environment scale。EnvFactory 反其道而行——质量优于数量，特别强调 implicit intent recovery。这种"反 scaling"的发现在当前 RL 圈很罕见。

关键结果

Benchmark	涨幅
BFCLv3	+15%
MCP-Atlas	+8.6%
τ²-Bench	+6%
VitaBench	+6%
环境数对比	85（本文）vs 5× more（prior SOTA）

结果解读：BFCLv3 涨 15% 在当前 leaderboard 已经很难了，但最有信息量的是"用 1/5 环境打过 SOTA"——这意味着环境质量的边际价值远高于环境数量。作者还报告 trajectory 数也少（2575 条），即"数据稀缺也没问题，只要数据自然"。这与博主"test execution 在 agent 中只贡献 1.25pp"的边际价值发现是同源思想。

局限性与开放问题

• 局限 1：85 个环境 vs prior 5× more 的对比缺一层 ablation——是 environment quality 起作用，还是 trajectory refinement 起作用，还是两者协同？作者没做 controlled ablation。
• 局限 2："natural multi-turn" 怎么量化？现在依赖人 review，没有客观的 naturalness metric。这是 evaluation methodology 的空白。
• 开放问题：这种"少而精"是否在不同 domain 都成立？作者只在 7 个 domain 测试，且 BFCL / MCP 都偏 tool calling 任务，向 SWE-bench 这种复杂 repo 任务推广时是否还成立？

💡 对我们的启发

1. 直接可用的技术点：博主在做 agent trace 大规模事后分析时，最大的痛点是公开 trace 数据（SWE-bench / OpenHands / Aider）质量参差不齐。EnvFactory 的 trajectory refinement 思路可以反过来用：对已有 trace 做 implicit intent recovery 标注，重新构建一份"natural trace"数据集——既可以作为博主下一篇分析论文的数据基础，也可以开源做成 dataset。
2. 具体实验想法（1-2 周可验证）：
   • 选 100 条 SWE-bench-verified 的成功 trace 和 100 条失败 trace
   • 用 EnvFactory 的 calibration 思路做标注："这条 trace 里有多少步是真正的 implicit reasoning？多少步是 over-specified 的演戏？"
   • 看 success vs failure 之间这个比例是否有显著差异——猜测：失败 trace 里 over-specified 占比更高（agent 在演戏而非推理）
3. 研究趋势判断：EnvFactory 是"环境数据效率"的重要 datapoint。这给博主一个很强的论据：在 agent 边际价值研究里，可以系统量化"每多一个环境/trajectory 带来的真实增益"。如果能配合统计严谨（McNemar、TOST 等价检验），就是一篇方法论批判类高质量论文。这条线和 SkillGenBench 那条线可以合并成一个更大的研究方向——"agent component sufficiency analysis"。

---

AI for Auto-Research: Roadmap & User Guide

推荐理由：给出了"AI 在科研 lifecycle 各阶段可靠 / 不可靠"的 taxonomy，直接呼应博主"LLM 边际价值"的研究哲学——只不过它的研究对象是科研活动而非 SE。方法论可以原样迁移。

📌 论文信息：Lingdong Kong, Xian Sun, Wei Chow, Linfeng Li, Kevin Qinghong Lin | arXiv:2605.18661 | cs.AI

TL;DR

横跨 AI 介入科研全生命周期的 roadmap 报告，把科研分为 Creation / Writing / Validation / Dissemination 四个阶段，给出"哪些子任务 AI 可靠、哪些不可靠"的清晰分界。最戳人的论断：全自动化系统目前**未能****持续达到主流 venue 的接收标准——即 $15 一篇论文是真的，但被顶会接收的不是它们。

问题是什么？

"AI 写论文"已经从噱头变成产业链——15 美元一篇研究论文的服务已经上线。但论文实际上没有解决一个根本问题：在科研压力下，前沿 LLM 仍会编造结果、错过隐藏错误、不能可靠判断 novelty。社区现在迫切需要一个"哪些阶段能信、哪些阶段不能信"的可操作分界图。

他们怎么做的？

核心 Insight：科研可以拆成 4 个 epistemological phase，AI 的能力边界沿着"任务结构化程度 + retrieval-grounding 程度 + tool-mediated 程度"三条轴线分布——这三条轴线越高，AI 越可靠。

具体方法流程（其实是 taxonomy 构建）：

1. Creation phase：idea generation / literature review / coding & experiments / tables & figures——AI 在 table/figure 制作上可靠，在 idea generation 上不可靠且会"实施后退化"。
2. Writing phase：paper writing——结构化部分可靠，原创洞察不可靠。
3. Validation phase：peer review / rebuttal / revision——AI 容易模仿 review 风格但缺真正的科学判断。
4. Dissemination phase：posters / slides / videos / social——基本可靠（最结构化）。

跟之前方法的本质区别：之前的 AI4Research 综述要么乐观（"AI 即将取代研究员"），要么悲观（"AI 只能做工具"），都是定性论断。这篇给出stage-dependent 的可靠性边界，让从业者可以 selective adoption 而不是 all-or-nothing。

关键结果

阶段	AI 可靠性	主要失败模式
Table/Figure 制作	高	偶尔轴标错
Literature review	中	引用错误、囫囵吞枣
Idea generation	低	"实施后退化"——纸面 idea 实际跑不通
Coding & experiments	低	research code 远落后于 pattern-matching benchmark
Peer review	低	风格模仿强，科学判断弱
End-to-end autonomy	未达到主流 venue 接收标准	failure mode 被 obscured 而非消除

结果解读：最有信息量的是"greater automation can obscure rather than eliminate failure modes"——这是个非常深刻的洞察。自动化程度越高，越难发现错误，因为错误被埋在管线深处。这与博主在 LLM-as-Judge / agent trace 分析里观察到的现象同源。

局限性与开放问题

• 局限 1：roadmap 论文的"软证据"问题——很多结论靠定性观察，没有大样本量化。比如"idea 实施后退化"具体是退化多少？50%？80%？没有数。
• 局限 2：截止 2026 年 4 月，但 frontier model 半年就换一代，结论可能很快过期。
• 开放问题：作者提出"human-governed collaboration"是最 credible 部署范式，但具体怎么设计 governance 没说——这是个巨大的空白。

💡 对我们的启发

1. 直接可用的技术点：这篇文章的taxonomy 框架可以直接套到博主的 SE 研究上——把 SE 任务也分成 Creation / Writing / Validation / Dissemination 类似的 phase（如：repo 理解 / 代码生成 / 测试 / 部署），然后做相同的"哪些 phase AI 可靠 / 不可靠"的实证调查。这能产出一篇 SE 版的 AI lifecycle roadmap。
2. 具体实验想法（1-2 周可验证）：选 SWE-bench 上 100 个 issue，用 4 个不同 LLM agent 分别跑，记录失败发生在哪个 phase（repo 探索 / fault location / patch 生成 / test 验证）。目标不是测准确率，是测 failure mode 的 phase 分布。预期发现：fault location 是 weakest link，而非大家以为的 patch generation。这与博主之前"static analysis 做定位、LLM 只负责修复"的职责切分哲学相互印证。
3. 研究趋势判断：这篇文章代表了 2026 年 AI 综述写作的新范式——不只是 list methods，而是给 actionable boundary。博主未来写 LLM4SE survey 时可以直接借鉴这种"可靠性分界"的结构，比传统按方法分类的综述更有 impact。这是一个被严重低估的 survey writing technique。

---

方法对比

四篇论文都在做"把 agent 拆开来评估"，但切入维度不同：

维度	Reversa	SkillGenBench	EnvFactory	AI for Auto-Research
拆开的对象	reverse engineering pipeline	skill generation	environment & trajectory	research lifecycle
评估粒度	claim-level + gap registry	execution-based skill check	end-to-end + 环境数对照	stage-level capability
关键发现	confidence/gap 显式化能用	repo / doc 失败模式不同	少而精 > 多而糙	自动化越深越掩盖失败
数据规模	单 case study（ATM）	多 task 但未披露规模	85 env / 2575 traj	截止 2026-04 文献
主要局限	缺 calibration / 单案例	失败模式没量化	跨 domain 泛化未验证	软证据为主
对博主最大启发	多 agent reverse engineering 可迁移到 Android→HarmonyOS	benchmark 拆解粒度的范式参考	数据效率 vs 数据数量的边际价值证据	taxonomy 写作风格可借鉴

一句话总结：今天这四篇都在告诉社区一件事——agent 时代的论文不再是"我能跑多高"，而是"每个组件贡献了多少"。这恰恰是博主三年前就开始坚持的方向，今天看到它成为主流，应该感到欣慰。