AI自主研究新范式：基于文件总线与分层编排的长周期智能体系统设计

1. 项目概述：为什么长周期AI研究工程是个“系统工程”难题？

在AI研究领域，我们正见证一个激动人心的转变：从AI辅助研究，走向AI自主研究。早期的智能体已经能帮我们写代码、调参、甚至读论文摘要。但当任务周期拉长到数小时甚至数天——比如，给你一篇顶会论文，要求你在24小时内，从零开始复现其核心实验，并达到报告的性能指标——事情就变得复杂多了。

这不仅仅是“写个脚本跑起来”那么简单。它是一连串高度耦合、环环相扣的异构任务：理解论文意图 -> 规划实现步骤 -> 搭建复杂环境 -> 编写核心代码 -> 运行实验 -> 分析结果 -> 诊断失败 -> 迭代优化。任何一个环节的决策失误或信息丢失，都可能导致几天的工作前功尽弃。传统的、依赖智能体间“对话式上下文传递”的协作模式，在这里显得力不从心。想象一下，一个负责代码实现的智能体，需要向前一个负责论文理解的智能体反复追问：“你刚才说的那个损失函数的具体形式是什么？数据预处理步骤的第三个参数你确定了吗？” 这种模式不仅低效，更致命的是，在长周期任务中，对话历史会变得极其冗长，关键信息被淹没，状态连续性无法保证。

AiScientist 正是为了解决这一核心痛点而设计的系统。它的核心洞察非常深刻：长周期机器学习研究工程的成功，本质上是一个系统工程问题，而非单纯的局部推理问题。关键在于如何协调（Orchestration） 与维持状态连续性（State Continuity）。基于此，它提出了一个简洁而强大的设计原则：厚状态，薄控制（Thin Control over Thick State），并通过 “文件总线”（File-as-Bus） 协议与分层编排（Hierarchical Orchestration） 架构来实现。

简单来说，AiScientist建立了一个以文件为中心的共享工作空间。所有项目状态——论文分析、计划、代码、配置、实验日志、结果图表——都以文件形式持久化存储在这里。顶层有一个“指挥家”（Orchestrator），它不关心代码细节，只通过一个简洁的“工作空间地图”和阶段摘要来把握全局进度，做出“接下来该进入实验阶段了”或“需要回头修复某个模块”这样的高层决策。而具体的脏活累活，则交给下层的“专家”智能体（如论文理解专家、代码实现专家、实验专家）去完成。这些专家不靠记忆对话，而是直接去工作空间读取最新的、持久化的文件（如 paper_analysis/algorithm.md 或 exp_log.md），基于这些“厚实”的、不会丢失的工件进行工作，并将产出写回工作空间。

这套设计，使得AiScientist在需要持续数小时乃至数天的复杂研究工程任务中，比如在著名的 PaperBench（从零复现论文）和 MLE-Bench Lite（持续优化竞赛模型）基准测试上，表现出了显著优势。它不仅大幅超越了传统的智能体基线，更重要的是，其设计理念为我们构建可靠、可扩展的自主AI研究系统指明了方向。

2. 核心设计理念拆解：“厚状态”与“薄控制”的哲学

要理解AiScientist为何有效，必须深入其设计哲学。这不仅仅是技术选型，更是一种对长周期复杂任务本质的思考。

2.1 传统多智能体协作的“阿喀琉斯之踵”：脆弱的对话状态

在经典的多智能体框架（如MetaGPT、ChatDev）中，智能体之间主要通过“对话”或“消息”来传递任务上下文和状态。这在小规模、短周期的任务中工作良好。但在长周期ML研究工程中，问题凸显：

1. 信息压缩与丢失：为了将庞大的项目历史塞进LLM有限的上下文窗口，系统不得不对历史对话进行摘要或压缩。这个过程是“有损”的。一个关键的实验失败细节、一段复杂的代码修改逻辑，可能在摘要中被简化或丢失，导致后续智能体基于不完整或错误的信息决策。
2. 状态碎片化：项目状态分散在各个智能体的私有对话记忆中，没有统一的、权威的“事实来源”。当实现专家需要参考三天前论文理解专家对某个公式的解读时，它只能依赖于可能已经扭曲的对话历史，而非原始的分析文档。
3. 难以回溯与审计：当实验失败时，很难精准定位是哪个环节、基于什么信息做出了错误决策。因为完整的推理链条和依赖的输入信息，并没有被系统地、结构化地保存下来。

这就像一群工程师在做一个大项目，但唯一的沟通方式是开会时的口头交流，会后不写会议纪要，也不更新设计文档。项目初期尚可，随着时间推移和人员轮换，信息熵急剧增加，项目陷入混乱。

2.2 AiScientist的破局之道：以文件为基石的“厚状态”

AiScientist从根本上扭转了这一范式。它的核心是建立一个权限隔离的共享工作空间，并将所有关键的、演进中的项目状态，都外部化（Externalize） 为这个空间里的文件。这些文件就是系统的“厚状态”。

什么是“厚状态”？ 它指的是那些体量大、细节丰富、需要被长期保存和反复查阅的项目资产。在ML研究工程中，这通常包括：

• 分析类：paper_analysis/summary.md（论文概要）、paper_analysis/algorithm.md（算法细节推导）、paper_analysis/experiments.md（实验设置解析）。
• 规划类：agent/prioritized_task.md（带优先级和依赖关系的任务列表）。
• 实现类：submission/ 目录下的整个可运行代码库、环境配置脚本（Dockerfile, requirements.txt）、资源下载脚本。
• 实验与诊断类：agent/impl_log.md（代码实现决策日志）、agent/exp_log.md（实验运行记录、指标对比、失败诊断）。
• 原始数据：agent/experiments/ 目录下的具体实验输出文件、日志、图表。

这些文件共同构成了项目的“单一事实来源”。它们有几个关键特性：

• 持久性：不受LLM上下文长度限制，永远存在。
• 可检查性：任何智能体（包括人类监督者）在任何时候都可以直接查看文件内容，了解项目全貌。
• 可追溯性：文件的修改历史（通过Git或类似机制）清晰记录了项目的演进路径。
• 结构化：文件按角色和用途组织，便于导航和按需读取。

2.3 “薄控制”如何驾驭“厚状态”：渐进式披露与工作空间地图

如果让顶层的协调器（Orchestrator）每次都去阅读所有“厚状态”文件来做决策，那将是灾难性的——它会被海量细节淹没，无法进行有效的宏观调度。AiScientist的巧妙之处在于引入了 “薄控制” 的概念。

什么是“薄控制”？ 它指的是协调器做出决策时所依赖的上下文是“轻薄”的。它不需要记住每一行代码或每一个实验数据点。它只需要知道：

• 当前阶段：我们在论文理解、实现、还是实验阶段？
• 高层摘要：上个阶段的主要产出和结论是什么？（例如，“论文核心算法已解析，但数据预处理部分存在歧义”）
• 工作空间地图：一个轻量级的文本索引，告诉它工作空间里有哪些关键区域，每个区域是干什么的。

这个“工作空间地图”是连接“薄控制”与“厚状态”的桥梁。它可能看起来像这样：

协调器基于这张地图和阶段摘要，决定下一步行动：“哦，paper_analysis/ 已经就绪，但 submission/ 还是空的。那么下一个阶段应该是‘实现’。我需要调用‘实现专家’，并指示它基于 paper_analysis/ 和 prioritized_task.md 开始工作。”

这个过程被称为“渐进式披露（Progressive Disclosure）”：智能体从高层地图开始，按需深入读取具体的“厚状态”文件。实现专家被调用时，它会先看地图，找到 paper_analysis/algorithm.md 和 prioritized_task.md，然后深入阅读这些文件来编写代码。它不需要知道三天前论文理解专家内部讨论的所有对话，它只需要看最终产出的、已经达成共识的分析文档。

2.4 分层编排：专业化分工与“智能体即工具”

有了“文件总线”作为可靠的状态承载层，AiScientist在上层采用了分层编排架构来组织工作流。这模仿了一个高效的研究团队：

1. 第0层：协调器（Orchestrator）：相当于团队负责人或首席科学家。它负责最高层的阶段规划与决策。它不写代码，也不分析实验数据。它的工具库包括原生工具（如执行Bash命令、读写文件）和一系列“智能体即工具（Agent-as-Tool）”。
2. 第1层：专家智能体（Specialist Agents）：相当于各领域的资深工程师。每个专家负责一个核心阶段：
   • 论文理解专家：将论文转化为结构化的、可执行的分析文档。它甚至可以并行调用多个子智能体分别分析论文结构、算法、基线等，然后汇总。
   • 优先级规划专家：将论文分析转化为一个具体的、带依赖关系和优先级排序的执行计划（prioritized_task.md）。它回答“先做什么，后做什么”的问题。
   • 代码实现专家：根据计划和论文分析，编写完整的、可运行的代码库。它有两种模式：“完整模式”从零构建，“修复模式”根据 exp_log.md 中的失败报告进行针对性修补。
   • 实验专家：运行整个流水线，对比结果与论文目标，记录成功与失败，并尝试进行简单的错误诊断（如修复导入错误、配置错误）。
   • 通用助手接口：用于创建处理临时性、探索性任务的轻量级智能体。
3. 第2层：子智能体（Subagents）：由专家智能体在需要时动态创建，用于执行高度聚焦的短期任务，例如“下载某个特定数据集”、“解析某个数学公式”、“探索一种超参数组合”。任务完成后即解散，不保留长期状态。

“智能体即工具”是关键设计。对协调器来说，调用“论文理解专家”和调用“执行Bash命令”在接口上是一样的。这使得协调器的决策空间保持统一和简洁。它可以根据任务复杂度，决定是亲自处理一个简单文件操作，还是将复杂的论文解析工作委托给专家。

这种分层、专业化的设计，确保了每个智能体都能在自己最擅长的领域深度工作，同时通过“文件总线”与团队其他成员无缝协作，共同推进一个可能持续数天的复杂项目。

3. 系统架构与工作流深度解析

理解了核心理念，我们来看看AiScientist具体是如何运作的。下图展示了其核心架构与数据流，我们可以将其分解为一个动态的、证据驱动的研究工程循环。

3.1 核心组件与数据流

整个系统围绕一个权限隔离的共享文件工作空间展开。我们可以想象这个工作空间是一个项目根目录，包含几个核心区域：

• ~/paper_analysis/：论文理解区。存放所有对输入论文的结构化分析。这是项目的“蓝图”区域。
• ~/submission/：交付物区。最终要提交的可运行代码库。这是项目的“成品”区域。
• ~/agent/：智能体工作区。存放动态生成的任务列表、执行日志和实验原始数据。这是项目的“工作台”区域。

协调器（Tier-0 Orchestrator） 位于最顶层。它维护一个极简的上下文，主要包括：当前项目阶段、上一阶段的产出摘要、以及一份工作空间地图。这份地图就像一本书的目录，告诉协调器每个文件夹是干什么的，里面大概有什么。

当协调器决定推进到下一个阶段时，它不会自己动手，而是通过 “智能体即工具” 接口，调用对应的专家智能体（Tier-1 Specialist），并附上一个简明的指令（Directive），例如：“基于 paper_analysis/ 中的内容，生成实现优先级计划。”

被调用的专家智能体（如优先级规划专家）收到指令后，它会：

1. 查看工作空间地图，定位到 ~/paper_analysis/ 目录。
2. 按需读取其中的具体文件（summary.md, algorithm.md等），获取完成任务所需的“厚状态”。
3. 执行其专业逻辑（分析依赖、排序任务）。
4. 将产出（一份 prioritized_task.md 文件）写回工作空间的 ~/agent/ 目录。
5. 向协调器返回一个简洁的摘要，如“已生成包含15个任务的优先级计划，其中3个为关键路径任务”。

协调器收到摘要后，更新自己的阶段上下文，然后根据计划，决定下一步是调用代码实现专家开始编码，还是发现论文分析有歧义需要论文理解专家进行澄清。整个过程中，协调器自身从不深入代码细节，它只做高层调度。

3.2 证据驱动的研究-工程循环

AiScientist的工作流不是一个线性的瀑布模型，而是一个证据驱动的、迭代的循环。这个循环可以概括为 “实现 -> 运行 -> 诊断 -> 修补 -> 再验证”。

1. 初始化与蓝图绘制（论文理解与规划）：项目启动后，协调器会优先推动论文理解和任务规划。目标是产出一份清晰的“执行合同”（prioritized_task.md）和一个可运行的代码脚手架。这个阶段不求完美，但求可执行和可覆盖核心需求。
2. 核心实现与首次运行：代码实现专家根据蓝图，构建最初的代码库并完成环境配置。实验专家随后运行整个流程。此时，结果很可能不理想——指标达不到论文报告值，甚至运行失败。
3. 诊断与迭代优化：这是系统价值最大化的环节。实验专家将详细的失败信息、指标差距、错误日志记录到 exp_log.md 中。协调器读取这些证据，判断问题性质：
   • 简单错误（如拼写错误、路径错误）：可能直接让实验专家或通用助手修复。
   • 实现偏差（如算法理解错误、代码逻辑bug）：指派代码实现专家进入“修复模式”，让其读取 exp_log.md 和相关的 paper_analysis/ 文件，进行针对性修补。
   • 规划或理解偏差（如发现原任务依赖关系错误、论文歧义导致无法实现）：可能回调优先级规划专家或论文理解专家进行修正。
4. 持续循环：修补后的代码被再次运行、评估、诊断。exp_log.md 和 impl_log.md 像飞行记录仪一样，累积了每一次尝试的痕迹。智能体们基于这些越来越丰富的持久化证据进行决策，而不是在失忆中重复劳动。

这个循环的强大之处在于，它将长周期任务中“延迟的、混杂的反馈”转化为了系统可处理、可积累的数字化证据。 每一次失败都不是徒劳的，它产生了可供后续轮次直接查阅和推理的“厚状态”，使得系统能够像人类工程师一样，从错误中学习，逐步逼近目标。

3.3 权限隔离与“仅追加”日志：确保系统稳健性

在一个多智能体共同读写文件的环境下，如何防止混乱？AiScientist通过权限隔离和操作约束来保障。

• 角色化写权限：每个专家智能体只被授予其职责所需目录的写权限。例如，论文理解专家只能写 ~/paper_analysis/，代码实现专家主要写 ~/submission/ 和 ~/agent/impl_log.md。这避免了智能体误删或篡改不属于自己职责范围的关键文件。
• “仅追加”日志：impl_log.md（实现日志）和 exp_log.md（实验日志）被设计为仅追加（append-only） 模式。智能体不能回头删除或修改之前的日志条目，只能在末尾添加新的记录。这保证了日志的完整性和可审计性，形成了一个不可篡改的时间线，对于诊断“何时引入了某个bug”至关重要。
• 工作空间作为记录系统：系统强制规定，项目的权威状态永远以工作空间中的文件为准，而不是任何智能体的内部对话记忆。这消除了状态分歧的可能。

4. 关键实现细节与实操考量

如果你想要借鉴AiScientist的思想来构建自己的长周期AI智能体系统，以下是一些必须深入思考的实现细节和实操要点。

4.1 “文件总线”协议的具体实现

“文件总线”听起来抽象，但实现起来核心是一套关于文件命名、格式、存放位置和读写规则的约定。

1. 文件结构与命名规范：

   • paper_analysis/ 下的文件应使用清晰、一致的后缀（如 .md），并按照论文的章节或分析维度组织。例如，methodology.md, experiment_setup.md, ambiguities_and_assumptions.md。
   • submission/ 目录应是一个完整的、可独立运行的代码项目，包含标准的 README.md, requirements.txt, run.py 或 reproduce.sh 入口脚本。
   • agent/ 下的日志文件应包含时间戳和智能体ID，便于追踪。例如，日志条目格式可以是 [2023-10-27 14:30:05] [ImplementationAgent] Decision: Used AdamW optimizer as per paper, with weight_decay=0.01.

2. 文件格式选择：

   • 分析文档与日志：优先使用纯文本或Markdown格式。它们易于被LLM读取、解析和生成，也便于人类审查。避免使用复杂的二进制或专有格式。
   • 配置与数据：使用JSON、YAML或TOML等结构化且可读的配置格式。对于实验数据，可以使用CSV或JSON Lines存储关键指标。

3. 状态同步与并发控制：在纯异步环境下，需要机制防止多个智能体同时写同一个文件导致冲突。简单的策略是文件锁或操作串行化（例如，通过一个中央任务队列，确保同一时间只有一个智能体在修改某个关键区域）。更复杂的策略可以引入版本控制的思想（如内部使用Git管理 submission/ 目录），但会显著增加复杂度。

4.2 分层智能体的提示工程与工具设计

每个层级的智能体都需要精心设计的提示词（Prompt）和工具集。

1. 协调器（Orchestrator）：

   • 提示词核心：强调其“管理者”角色。提示词应包含：系统目标、可用专家智能体列表及其功能描述、工作空间地图的结构、当前阶段定义、以及决策逻辑（例如，“如果 exp_log.md 中存在‘CUDA out of memory’错误，优先考虑调用实现专家检查批量大小或模型裁剪”）。
   • 工具集：基础文件操作（读、写、列表）、执行Shell命令、以及调用其他专家智能体的接口。

2. 专家智能体（Specialists）：

   • 论文理解专家：需要强大的信息提取和结构化能力。其工具集应包括网页搜索（查找相关开源实现、澄清概念）、文档解析（处理PDF）、以及调用子智能体进行并行分析的能力。它的输出必须是高度结构化的Markdown。
   • 代码实现专家：需要完整的代码编辑、环境交互能力。工具集需包含：在指定文件/行号进行代码插入、删除、替换；执行 pip install、git clone 等环境配置命令；运行单元测试。它的提示词需要强调代码风格、依赖管理以及与现有代码库的集成。
   • 实验专家：需要监控和执行长时任务。工具集需包含：启动训练/评估脚本、监控日志输出（特别是指标和错误）、读取结果文件、对比数值。它的提示词需要教会它如何判断实验“成功”或“失败”，以及如何初步诊断常见错误（如梯度爆炸、过拟合）。

3. 子智能体（Subagents）：通常是“一次性”的，针对特定微任务创建。提示词需要极其具体，例如：“你的任务是下载数据集X到路径 ./data/，使用官方提供的脚本，并验证MD5校验和。”

4.3 工作空间地图的生成与维护

工作空间地图是“薄控制”的基石。它不应是静态的，而应随着项目演进动态更新。

• 生成方式：可以由协调器在每次需要做出决策时，动态扫描工作空间目录结构，并生成一个简短的文本描述。也可以由一个专用的“地图维护”子智能体定期更新。地图内容应包括目录路径、核心文件列表及其一句话描述。
• 信息密度：地图不能太详细（否则就变成“厚状态”），也不能太简略（否则无法导航）。一个好的原则是：只描述“区域”的用途，不描述“区域”内的具体内容。例如：“./agent/experiments/ - 存储所有实验运行的原始输出和日志文件。”

4.4 成本与效率的权衡

长周期任务意味着大量的LLM API调用和长时间的计算资源占用。必须考虑成本控制。

1. 上下文长度管理：这是“薄控制”设计的主要优势之一。协调器和专家智能体都基于简洁的摘要和按需读取的文件工作，避免了将整个项目历史塞进上下文，极大节省了Token消耗。
2. 智能体调用频率：并非每个小步骤都需要调用智能体。协调器应具备判断力，对于简单的文件操作（如重命名、移动），可以直接使用原生工具完成，避免产生不必要的智能体调用开销。
3. 实验运行的优化：实验专家在监控长时训练时，不应持续占用LLM上下文。可以采用轮询机制：启动实验后，智能体暂时“休眠”或结束会话，由外部进程监控，当实验结束或发生错误时，再重新唤醒或创建新的实验专家会话来分析结果。
4. 缓存与复用：对于频繁读取的、不变的文件（如论文原文、初始分析），可以在内存或高速存储中建立缓存，避免重复通过API上传。

5. 评估、对比与机制分析

AiScientist的价值需要通过严苛的基准测试来验证。论文主要在两个互补的基准上进行了评估：PaperBench 和 MLE-Bench Lite。

5.1 基准测试详解

1. PaperBench：专注于从零开始复现顶级学术论文。任务给定一篇论文、一个干净的Docker环境（带GPU）和时间预算（如24小时），智能体必须产出可运行的复现代码，并尽可能匹配论文报告的核心结果。评估不仅看代码能否运行，还严格评估代码质量、结果匹配度。这是一个对全流程工程能力的终极考验。
2. MLE-Bench Lite：专注于在竞赛式机器学习任务上进行持续的实验改进。给定一个任务（如Kaggle比赛），智能体需要从初始方案开始，通过多轮实验迭代优化模型性能，争夺更高的排名（铜牌、银牌、金牌）。这是一个对迭代优化和诊断能力的深度测试。

5.2 核心实验结果与解读

在PaperBench上，AiScientist（使用GLM-5作为骨干模型）取得了平均33.73分，比最强的基线（IterativeAgent）高出11.15分。更重要的是，它将与人类专家基线（41分）的差距大幅缩小。同时，其单任务平均成本（12.20美元）远低于IterativeAgent（54.90美元），实现了更高性能、更低成本。

在MLE-Bench Lite上，AiScientist取得了81.82%的“任意奖牌率”（Any Medal%），在受控对比中显著优于其他主流自主ML工程系统（如AIDE、ML-Master 2.0）。这证明其优势不仅在于论文复现，也在于持续的模型优化。

5.3 关键的机制消融实验

为了厘清“文件总线”和“分层编排”各自贡献了多少，论文进行了关键的消融实验：

1. 移除“文件总线”（File-as-Bus）：当系统退回到依赖对话上下文传递状态时，性能出现大幅下降。在PaperBench上平均分下降6.41分，在MLE-Bench Lite上“任意奖牌率”暴跌31.82个百分点。这强有力地证明了持久化状态连续性是长周期任务成功的关键瓶颈。没有它，智能体就像在流沙上建房，后期的迭代优化无从谈起。

2. 更有趣的发现：在MLE-Bench Lite上，移除“文件总线”后，“有效提交率”和“铜牌率”下降不多，但“银牌率”、“金牌率”和“高于中位数率”暴跌。这说明，“文件总线”的核心价值体现在后期的精细化调优和突破性改进上。要得到一个能运行的基线模型，可能不需要太强的状态连续性；但要持续优化到顶尖水平，必须能够积累和利用每一轮实验的详细证据。

3. 与简单智能体组织的对比：即使移除了“文件总线”，仅保留分层编排的AiScientist简化版，其表现也显著优于完全非分层、单智能体或简单循环的基线（如BasicAgent, AIDE）。这表明，仅仅增加智能体间的交互次数是不够的，必须通过专业化的角色分工（分层编排）来有效管理长周期任务的复杂性。

核心结论：长周期ML研究工程的成功，既离不开**“文件总线”提供的坚实状态基石**，也离不开**“分层编排”带来的高效任务分解与调度**。二者结合，才能支撑起持续数天的、复杂的自主研究循环。

6. 局限、挑战与未来展望

尽管AiScientist代表了重要进展，但构建完全自主的AI研究员仍面临巨大挑战。

6.1 当前系统的局限性

1. 对骨干LLM能力的强依赖：系统的上限受限于其所使用的LLM（如Gemini-3-Flash, GLM-5）的代码生成、逻辑推理和科学理解能力。如果LLM无法正确理解论文中的某个新颖算法，整个链条就会失败。
2. 复杂错误的诊断能力有限：系统可以处理明显的错误（如语法错误、配置错误），但对于深层、隐晦的bug（如算法实现中的数值不稳定、难以复现的随机性bug），其诊断和修复能力还远不及人类专家。
3. 探索与创新不足：当前系统主要目标是“复现”和“优化”，遵循一个相对明确的路径。对于需要跳出框框、进行创造性探索或提出全新研究思路的任务，系统能力有限。
4. 资源与成本：长达24小时的自动运行消耗大量GPU计算资源和API调用费用，限制了其大规模应用。

6.2 工程落地中的实践挑战

1. 工具集的完备性与可靠性：智能体的能力边界由其工具集定义。构建一个覆盖所有可能ML任务（从PyTorch/TensorFlow到JAX，从CV、NLP到强化学习）的可靠工具集，是一项浩大的工程。
2. 安全与可控性：赋予智能体执行任意Shell命令、安装依赖、访问网络的能力存在安全风险。需要在沙箱环境中运行，并严格限制其权限。
3. 人类在环（Human-in-the-loop）的接口：理想的系统不应是全黑盒。需要设计优雅的接口，让人类研究员能够中途干预（提供提示、纠正方向、审核决策）、监控进度、以及理解系统做出的每一个关键决策的理由。

6.3 未来发展方向

1. 更强大的“核心认知”模块：集成更专业的工具，如符号数学引擎（解决公式推导）、代码静态分析器（发现潜在bug）、实验数据可视化分析工具，以增强智能体的深度分析能力。
2. 元认知与学习能力：让系统能够从历史任务中学习，形成“经验库”。例如，记住在类似论文复现中成功的数据处理方式，或在遇到特定错误模式时能直接应用已知的修复策略。
3. 多模态与具身交互：未来的AI研究员可能需要直接与科学仪器交互、阅读图表、处理物理实验数据，这需要多模态理解和机器人控制能力的整合。
4. 从复现到发现：最终极的目标，是让这样的系统不仅能复现已知结果，还能自主设计实验、提出假设、发现新知，真正推动科学前沿。

AiScientist为我们描绘了一条切实可行的路径：通过**“文件总线”解决状态连续性问题**，通过**“分层编排”解决任务复杂性问题**。它将长周期AI研究工程从一个纯粹的AI问题，还原为一个需要精心设计的系统工程问题。对于每一位从事AI智能体开发或MLOps的研究员和工程师而言，理解并借鉴其“厚状态，薄控制”的设计哲学，或许是构建下一代可靠、强大自主智能系统的起点。