把一个研究领域的论文、引用、开源实现和 benchmark 连接起来，能否让 AI 持续提出算法、设计实验并运行验证，最终形成类似 AlphaEvolve 的自主研究循环？
以 Fuzzing（模糊测试）为例，很多步骤已经具有可操作的接口：追踪新论文，提取研究问题、核心机制和实验结论；沿引用关系寻找相关方法；让 Coding Agent 修改 fuzzer；在固定目标程序上运行 benchmark，再根据结果生成下一轮候选。新论文和实验结果不断进入系统，理论上可以减少每次重新理解领域的成本。
困难不在于能否把这些步骤串起来，而在于论文中的结论是否能变成可执行的实验，以及系统能否负担足够多的独立验证。这决定了算法搜索能够覆盖多大的空间，也决定了结果是否值得相信。
相比自动生成更多论文，一个更值得检验的方向是：让研究 Agent 维护带有来源、运行条件和失败记录的实验记忆，并根据已有证据决定下一笔计算预算应该花在哪里。
文献可以读到，方法未必能够运行
论文摘要和引用网络能够帮助系统回答“前人研究了什么”，却不能直接回答“哪些结果可以重新验证”。
一篇 Fuzzing 论文即使提供了算法伪代码，也可能没有公开源代码、初始种子、目标程序版本或关键配置。模型可以重写伪代码，但调度队列的更新时机、覆盖反馈的编码方式、超时处理、编译插桩和运行环境都可能影响最终结果。重写后的程序无法达到论文报告的性能时，不能直接归因于论文结论有误；达到同样的指标，也不意味着两个实现具有相同机制。
这里至少有两个需要分别记录的维度：实现从哪里来，以及结果由谁在什么条件下得到。实现可能是作者公开的代码、第三方或 Agent 的重写版本，也可能根本不可获取；结果可能仅来自论文报告，也可能来自使用明确实验协议的独立测量。
这两个维度不能合并成单一的“复现等级”。拿到作者代码，不代表能跑出论文中的结果；独立实现得到接近的指标，也不代表算法行为等价。即使都成功运行，如果目标版本、初始种子或时间预算不同，结果仍可能不可比。代码和数据不可得的论文仍能贡献机制假设，但不能自动成为可直接比较的实验 baseline。
例如，一篇论文声称新的 seed scheduling 策略优于现有算法，却没有发布代码。Agent 可以把论文描述的策略移植到 AFL++ 分支，研究该机制是否有效；但对比应明确标注为“对论文方法的一种重实现”，而不是宣称复现了原论文中的全部结果。
这意味着知识库不只需要连接 Paper、Citation 和 Method，还要连接具体的实现版本、实验环境、数据来源与复验状态。引用关系表示学术关联，不自动表示一个结果得到了后续工作验证。系统也不必以复现整个领域为前提：应先选择那些可执行、可比较的研究路线，把其余论文保留为未验证的机制线索。
现有基础设施能够减少这部分工作。例如 FuzzBench 提供真实项目上的 fuzzer 对比和统计报告，允许研究者接入新的 fuzzer；但它不能补齐每篇历史论文缺失的代码，也不能替研究者证明不同实验之间的配置可比。
计算成本来自验证次数，而不只是模型调用
参考 FuzzBench 的示例报告配置，10 个 fuzzer、24 个目标、每组 20 次 trial、每次持续 24 小时，总计需要：
10 × 24 × 20 × 24 = 115,200 trial-hours
这是 115,200 个单次试验运行小时。只有在额外假设每个 trial 平均独占一个 CPU 核心时，才可近似折算成 115,200 CPU-core-hours；如果每次运行使用多个核心，核心小时数会相应增加。编译、覆盖率测量、失败重试、存储和模型调用还要单独计入。这一量级说明，完整评测不能成为每个生成候选的默认操作。
更重要的是，Agent 的大部分候选可能没有实验价值：有些不能编译，有些破坏了 fuzzer 的基本行为，有些仅仅提高了执行吞吐量，还有些只在个别目标上表现更好。若每轮生成一百种修改，再对每一种执行完整评测，搜索过程会很快被评测成本支配。
一种实现方向是把验证分成多个预算等级。候选先通过编译、单元测试和不变量检查；随后在少量目标上运行短时试验；只有保留下来的候选才进行更长时间、更多目标和多次独立重复的 benchmark。每一步都保留失败原因，并限制单个候选能消耗的资源。
这类似 multi-fidelity optimization，但不能直接把短时 coverage 当成长时表现的可靠预测。某种策略可能前期探索较慢，却在更长预算下表现更好。调度器既要利用目前看起来较好的候选，也要为尚未表现出优势、但具有不同机制的候选保留探索机会。
系统真正需要管理的是获得可靠结论的总成本：候选生成、失败构建、实验运行、结果分析以及必要的人类检查。降低单次模型调用价格未必能显著降低这个总成本；反过来，减少无效的完整评测，可能比更便宜地生成想法更重要。
AlphaEvolve 能借鉴什么，不能直接迁移什么
AlphaEvolve 的一个关键条件，是候选程序可以交给自动评价器执行和打分，并将反馈用于下一轮搜索。评价器提供的是对特定任务的可测量结果，不是对科学新颖性或机制正确性的全面判断。
Fuzzing 恰好暴露了这种区别。Coverage 提升不等于发现更多真实漏洞；更高的执行次数可能来自减少昂贵但有价值的探索；多个 crash 也可能指向同一个缺陷。FuzzBench 的核心评测以覆盖率为主，它本身不把 crash 数当作主要性能指标。FuzzBench 的实验数据说明也区分了覆盖率测量与保存的 crash 数据。
如果 Agent 的奖励始终来自固定的公开 benchmark，它可以逐步学到目标程序集的特殊性。更隐蔽的问题是，修改 fuzzer 的 Agent 也可能无意中改变插桩、初始 corpus、超时判断或计数方式，让指标改善但比较失去意义。
因此，搜索时使用的代理指标和宣称研究进展所依据的证据必须分开。搜索阶段允许快速、带噪声的比较；最终验证则需要冻结目标、测量工具和资源限制，使用独立重复、效应量、消融分析，以及候选筛选期间未接触的目标程序。后者仍然不能保证泛化到所有软件，只能给出更明确的适用范围。
这并非 Fuzzing 独有的困难。Evaluating Fuzz Testing 早已指出，baseline、benchmark 选择、随机性和统计分析都可能影响研究结论。更强的代码生成模型无法替代这些实验设计工作。
让失败实验也成为可查询的知识
传统文献追踪系统通常围绕论文与引用展开。自主科研系统还需要记录：一个假设被实现成哪个 commit，修改了哪些行为，使用何种目标与运行预算，测到了哪些差异，以及这些差异能否支持原始解释。
例如，Agent 从两篇论文中分别提取 mutation operator 和 seed selection 的机制，并提出组合方案。第一次运行后，coverage 没有提高，但执行速度下降了 30%。如果系统只把结果保存为“组合方案失败”，后续搜索就可能错误地排除整个想法。真正值得记录的是：在哪些目标和时间预算下观察到了什么；是否测量了吞吐量；性能下降究竟是已验证原因，还是模型提出的解释假设。
一条实验记录至少应绑定假设、代码差异、基础版本、环境配置、随机种子、预算、原始指标和分析结论。作者的主张、机器测量以及模型推断也要有不同的证据标记。尤其是负结果，应保存其适用范围：在有限目标上没有观察到收益，并不等于证明该机制在其他目标上无效。
这与“将所有论文摘要放入向量数据库”有本质区别。论文摘要可以帮助生成下一个想法；实验记录则可以让系统判断一个想法是否已被尝试、已有证据的可信程度，以及再做一次实验能否提供新信息。
不过，实验记忆本身有冷启动成本。早期记录少，检索价值有限；自动整理历史结果也可能引入错误。错误的失败归因一旦被反复引用，甚至会比没有记忆更有害。系统因此需要允许旧结论被新实验修正，而不是把每次 Agent 的分析永久固化为事实。
如何验证“有记忆的科研搜索”是否更有效
不必先建造覆盖所有领域的论文知识图。可以选择一个开源 fuzzer 的固定版本，例如 AFL++，把允许修改的范围限制在 seed scheduling，并选择一组可重复运行的目标程序。目标不是立刻发现 SOTA，而是判断结构化实验记忆是否真的改善了搜索过程。
这里不能只比较“没有历史记录的 Agent”和“拥有实验记忆的 Agent”。如果后者知道更多历史结果，收益可能来自额外信息，而不是记忆组织方式。因此，至少需要三个对照：
- 无历史记录：Agent 阅读相同的基础论文与实现文档，自行提出和验证候选；
- 原始记录检索：Agent 可以查询同一批历史实验日志、代码差异和结果，但不提供结构化的实验结论；
- 结构化实验记忆：Agent 访问相同历史材料整理出的假设、环境、结果及证据关系。
第二组和第三组用于区分“拥有更多信息”与“信息被怎样组织”；第一组用于评估历史实验信息整体是否有用。所有组应使用同一模型、相同的可修改代码范围和实验环境，并对检索 token、模型调用、失败编译、运行时间和人工介入设定一致的核算方式。整理实验记忆的成本不能被忽略，可以单独报告初始建设成本及其在多轮搜索中的摊销。
每组需要多次独立搜索，而不是只比较各自挑出的一个最佳结果。搜索期间只使用探索目标，最终候选再交给此前没有参与筛选的目标和评测流程。应在搜索开始前约定什么算作“通过验证的候选”，例如在留出目标上达到预设的效应门槛、没有明显回归，并有足够的重复实验支持。然后比较单位总预算获得的此类候选数量、重复失败次数，以及结果在不同目标上的稳定性。对大量候选反复筛选后，不能把赢家在探索集上的分数当作未经选择偏差影响的效果估计。
还可以先做一个更便宜的前置实验：抽样梳理某个 Fuzzing 子方向的论文，测量其中有多少提供可构建实现、足够完整的实验配置和可比较的目标程序，并记录人工或 Agent 为补齐缺失信息付出的工作量。如果可执行证据覆盖率很低，那么文献自动化程度再高，也无法直接支撑大规模实验搜索。
这个验证计划实际上测试两个独立假设：领域知识能否以可接受的成本转成实验资产；在资产可用的前提下，结构化实验记忆能否让下一次实验的选择更有效。第一个假设不成立时，第二个即使在小规模平台上成立，也不足以支持扩展到整个研究领域。
从可执行研究到科研贡献
即便一个系统在独立 benchmark 上稳定超越已有实现，也不能自动推出它提出了新的科学知识。性能提升可能来自工程细节、参数搜索或目标分布的偶然性。它需要进一步回答：什么机制导致了提升，这种解释能否被消融实验反驳，以及相比已有文献真正新增了什么。
同样，Agent 可以维护自己的实验分支，却不应因为 benchmark 改善就自动向上游项目提交修改。开源维护者仍需判断可维护性、兼容性、额外运行成本和项目目标；自动化实验的日志只能提供部分决策证据。
因此，“论文工厂”容易把终点误设为论文数量或 leaderboard 排名。更准确的研究目标是让系统持续把文献线索转化成可执行假设、把有限计算资源投入能够减少不确定性的实验，并记录这些实验没有证明的事情。
剩下的开放问题不是 Agent 能否产生更多候选，而是：当历史实现不完整、评价指标不完美、计算预算有限时，一个能够管理证据与实验成本的搜索系统，是否能在独立验证中获得比无状态搜索更高的研究产出效率。这个问题有明确的工程起点，也有可能得到否定答案。