在通用大模型智能体蓬勃发展的 2025 年，SakanaAI 推出的 AI-Scientist-v2 开辟了一个垂直细分领域 —— 完全自主的科学研究智能体。与此前常见的金融交易智能体、RAG 平台或可观测性框架不同，AI-Scientist-v2 的核心目标是替代人类研究者完成从假设生成、实验执行到论文撰写的完整科研闭环。更为关键的是，它首次采用了代理树搜索（Agentic Tree Search）而非简单的线性 agent 架构，这一设计选择直接决定了系统在开放域科学探索中的能力边界。
从线性 Agent 到树搜索：架构范式转移
传统 Agent 系统通常采用「感知 — 思考 — 行动」的单一循环模式，在科研场景下，这种线性推理路径面临显著瓶颈。科学研究本质上是一个发散性探索过程，一个假设被证伪后，研究者需要迅速切换思路并尝试新的方向。这种「假设 — 实验 — 评估 — 调整」的迭代模式天然适合树结构表达 —— 每个节点代表一次实验尝试，枝干代表不同假设分支，叶子节点则记录实验结果与后续行动决策。
AI-Scientist-v2 实现的最佳优先树搜索（Best-First Tree Search，简称 BFTS）正是对这一需求的工程化回应。在 bfts_config.yaml 中，搜索策略由几个核心参数共同控制。num_workers 决定并行探索的路径数量，配合 steps 参数定义最大搜索深度 —— 举例而言，当 num_workers=3 且 steps=21 时，系统会在每一步同时展开 3 个节点的并发探索，总计最多探索 21 个节点。num_seeds 则控制初始根节点数量，建议在 num_workers 小于 3 时将其设为与 num_workers 相同，否则固定为 3。这个参数的设置直接影响系统在不同研究方向上的分散程度。
实验调试机制：失败路径的智能重试
科研自动化的最大挑战在于实验代码本身可能存在缺陷。与传统软件工程不同，AI 生成的实验代码往往伴随着隐藏的依赖问题、参数配置错误或逻辑漏洞。为此，AI-Scientist-v2 在树搜索框架内嵌入了专门的调试机制，通过 max_debug_depth 和 debug_prob 两个参数控制重试策略。
max_debug_depth 定义了单一节点在失败后最多尝试调试的次数，而 debug_prob 则以概率形式决定每次失败是否触发调试流程。这种概率性设计避免了系统在某些无法修复的错误上过度消耗资源 —— 当实验失败源于根本性假设错误时，继续调试同一路径的边际收益会迅速递减。根据项目文档，使用 Claude 3.5 Sonnet 执行实验阶段的成功率约为 15% 至 20%，这一数据表明调试机制虽然不能解决所有问题，但对于提升整体有效探索效率仍然至关重要。
另一个关键参数是 num_drafts，它控制第一阶段生成的初始根节点数量，本质上决定了系统在同一时间内并行探索的独立研究方向数量。较高的 num_drafts 意味着更强的探索广度，但相应的计算成本也会线性增长。
端到端工作流：从想法到论文的自动化闭环
AI-Scientist-v2 的完整流程可以划分为四个阶段：想法生成（Ideation）、实验执行（Experiments）、论文撰写（Writeup）和结果评估（Review）。每个阶段由独立的模型调用链完成，但共享同一个状态存储系统以保证上下文的连贯性。
在想法生成阶段，系统首先接收一个高层次的课题描述文件，包含标题、关键词、摘要和研究动机。这一文件可以是人工撰写的，也可以是基于已有想法的扩展。perform_ideation_temp_free.py 脚本会根据这一描述调用大模型进行头脑风暴，并通过 Semantic Scholar API 检查想法的新颖性。关键参数包括 max-num-generations（生成的独立想法数量）和 num-reflections（每个想法的迭代精炼次数）。默认配置下，系统会尝试生成 20 个候选想法，并对每个想法进行 5 轮反思优化。
实验执行阶段是整个系统的计算瓶颈。系统会根据生成的 JSON 想法文件启动 BFTS 搜索，每一步都由实验管理器代理（Experiment Manager Agent）协调。这个代理角色类似于人类实验室中的博士后，负责分配计算资源、监控实验进度并在必要时介入调整。当实验完成后，结果会自动写入指定的时间戳目录，研究者可以通过 unified_tree_viz.html 可视化文件直观查看整个搜索树的生长过程。
论文撰写阶段大约需要 20 至 30 分钟，系统会根据实验数据自动生成引言、方法、实验、结果和讨论等标准学术结构。引用生成通过 model_citation 指定的模型调用 Semantic Scholar API 完成，num_cite_rounds 参数控制引用的检索轮数。使用 GPT-4o 作为引用模型可以有效降低整体成本。
与通用 Agent 系统的本质差异
理解 AI-Scientist-v2 的独特价值，需要将其与近期活跃的通用 Agent 框架进行对比。以金融领域的 Dexter、RAG 平台的 Onyx 或可观测性框架的 AgentScope 为例，这些系统的核心逻辑是给定明确的工具集和目标函数，通过单轮或多轮对话完成特定任务。它们的任务空间是封闭的 —— 工具边界清晰、评估指标可量化、成功失败二元可判。
而 AI-Scientist-v2 面临的任务空间是高度开放的。科研探索没有标准答案，一个假设可能被证实、证伪或发现意外结论，每种结果都需要不同的后续行动。更重要的是，实验代码本身需要被创造和调试，这要求系统具备真正的代码生成能力而非仅仅是工具调用。这种「元任务」属性使得树搜索架构成为必要选择 —— 它为系统提供了在开放空间中回溯和转向的结构化能力。
从工程实现角度看，这种差异体现在两个维度上。第一是状态管理复杂度：通用 Agent 只需要维护单轮对话上下文，而 BFTS 需要管理多棵并行生长搜索树的状态，并追踪节点间的父子关系与评估分数。第二是执行环境的隔离要求：由于系统需要运行 AI 生成的代码，项目文档明确警告必须在 Docker 容器等受控沙箱环境中执行，以防止意外的网络访问或恶意包调用。
落地实践的关键监控点
将 AI-Scientist-v2 部署为科研生产力工具时，有几个监控指标值得重点关注。成功率是最直观的健康度指标，它受到基础模型能力和研究想法复杂度的双重影响。使用更强的模型（如 Claude 3.5 Sonnet）可以显著提升成功率，但相应地会增加单次运行成本 —— 项目文档给出的参考成本为每次实验 15 至 20 美元，撰写阶段额外增加约 5 美元。
实验耗时是另一个关键运营指标。完整流程通常需要数小时完成，其中树搜索阶段的时间复杂度大致为 O(num_workers × steps × 单次实验时间)。对于需要快速迭代验证的场景，可以考虑降低 steps 参数换取更快的反馈周期。
搜索树的利用率值得特别关注。理想情况下，系统应该能够持续发现新的有希望分支。如果发现大量节点在早期就被标记为失败，可能需要调整 debug_prob 或检查想法生成阶段的质量。反之，如果搜索树过于茂密但产出有限，则可能是 num_workers 设置过高导致资源分散。
最后，对于有公开论文发表需求的研究者，必须注意项目许可证中强制要求的透明披露条款 —— 任何基于 AI-Scientist-v2 生成的学术手稿必须明确标注 AI 的使用，这既是法律要求，也是科研诚信的基本体现。
资料来源：本文核心事实依据来自 SakanaAI 官方 GitHub 仓库 AI-Scientist-v2 的项目文档与配置文件说明。