ArchPilot：基于多智能体与代理评估的高效神经网络架构搜索框架

1. 项目概述：当大模型遇上架构搜索，如何用“代理”思维省下百万算力？

如果你在机器学习领域摸爬滚打过几年，尤其是深度参与过模型调优或自动化机器学习（AutoML）项目，那你一定对“神经网络架构搜索”（Neural Architecture Search, NAS）又爱又恨。爱的是，它承诺将我们从无穷无尽的手动调参和架构设计中解放出来；恨的是，它那令人咋舌的计算成本——动辄需要成千上万的GPU小时去训练和评估海量候选模型，这成本别说个人研究者，就连很多中型团队都望而却步。传统的NAS，就像是一个挥金如土的“富二代”探险家，每看到一个可能的藏宝点（候选架构），不管三七二十一，先挖到底（完整训练）看看有没有宝，效率极低。

近年来，大语言模型（LLM）驱动的智能体（Agent）在代码生成和问题求解上展现出了惊人潜力，自然也被寄予厚望，希望能成为那个“聪明”的AutoML工程师。于是，像AIDE、ML-Master这样的系统出现了，它们让LLM来扮演架构师，自动生成、调试、迭代模型代码。这听起来很美，但一个根本的瓶颈依然存在：这些系统评估一个候选方案的好坏，依然严重依赖完整的模型训练。这就好比让一个AI建筑师画了张草图，要判断这房子好不好，不是去分析结构、估算材料，而是非得把房子真盖起来住一阵才知道。迭代速度慢、计算开销大、搜索空间受限的问题，本质上并没有解决。

今天要深入拆解的ArchPilot，正是瞄准了这个核心痛点。它不是一个简单的工具迭代，而是一套基于“代理评估”与“多智能体协作”的系统性工程框架。其核心思想非常“工程师”：引入一个快速、廉价的“质检员”（代理评估），先对候选架构进行快速初筛，只让最有潜力的方案进入昂贵的“终审”（全训练）。更妙的是，这个质检标准（代理函数）不是固定的，而是会根据真实反馈（全训练结果）动态学习和调整的。ArchPilot通过三个分工明确的智能体——生成（GA）、评估（EA）、协调（OA）——将架构生成、快速评估和资源调度解耦，形成了一套高效的搜索闭环。实验表明，在相同的严格计算预算下，它在MLE-Bench基准上不仅提交成功率更高，最终模型的排名也显著优于之前的SOTA方法。接下来，我们就从设计思路到实操细节，彻底搞懂这套框架是如何工作的，以及我们能从中借鉴什么。

2. 核心设计思路：为什么是“多智能体”与“代理评估”？

在深入代码和流程之前，我们必须先理解ArchPilot设计哲学背后的“为什么”。这决定了它为何有效，以及它的优势边界在哪里。

2.1 传统NAS与LLM-Agent的瓶颈分析

传统的NAS方法，无论是基于强化学习、进化算法还是可微分搜索，其计算开销的根源在于性能评估的代价。评估一个神经网络架构的性能，黄金标准就是在目标数据集上进行完整训练和验证。这个过程极其耗时，严重限制了搜索空间的大小和探索的深度。

LLM-Agent的引入，将架构的“设计”过程自动化、智能化了，但评估方式并未发生本质改变。系统依然需要执行生成的训练脚本来获得反馈。这带来了几个连锁问题：

1. 迭代周期长：一次完整的训练-评估循环可能耗时数小时，严重拖慢了智能体的“思考-行动”反馈速度。
2. 探索成本高：由于每次评估都贵，智能体不敢进行大胆或广泛的探索，倾向于在局部微调，容易陷入次优解。
3. 预算约束下的无效浪费：有限的GPU预算可能大量消耗在评估一些明显不佳的候选架构上，导致没有足够资源去深入挖掘真正有潜力的方向。

ArchPilot的洞察在于：我们不一定需要在每次迭代中都获得绝对精确的性能评估，一个相对准确的、快速的性能“预测”或“代理”，就足以指导搜索方向。这类似于我们在研究初期，会用一些小规模实验（如训练1个epoch、在小数据集上跑）来快速验证想法可行性，而不是一开始就上大规模全量训练。

2.2 三智能体分工：解耦复杂任务，各司其职

将复杂的NAS任务扔给一个“全能”的智能体，容易导致其注意力分散，策略混乱。ArchPilot采用了经典的“分而治之”思想，设计了三个专职智能体：

• 生成智能体（Generation Agent, GA）：职责是“写代码”。它根据任务描述、历史记忆和协调智能体的指令，负责生成可运行的训练脚本（Draft）、对现有脚本进行原子级改进（Improve）、以及调试修复出错的脚本（Debug）。它的目标是保证代码的功能正确性和多样性。
• 评估智能体（Evaluation Agent, EA）：职责是“打分数”。它是系统的“成本控制中心”。它不直接进行昂贵全训练，而是设计并执行一系列代理函数（Proxy）——这些是超轻量级的评估手段（如单周期验证、带噪声验证）。EA将这些代理分数聚合成一个单一的“代理分数”，用于快速排名。同时，它管理着代理函数的权重，并随着全训练结果的积累，动态优化这些权重，让代理评估越来越准。
• 协调智能体（Orchestration Agent, OA）：职责是“做决策”和“管资源”。它是系统的大脑和调度中心。它维护着一个基于蒙特卡洛树搜索（MCTS）的搜索树，树上每个节点代表一个候选架构及其评估状态。OA负责决定接下来探索哪个节点（利用-探索权衡），决定何时该对一个节点进行“终审”（启动全训练），管理计算预算，并在代理评估标准更新时，果断地重启搜索树，防止在过时的方向上浪费资源。

这种分工带来了清晰的责任边界和模块化优势。GA可以专注于代码生成质量的提升，EA可以研究更有效的代理函数，OA可以优化搜索策略，三者可以独立演进。

2.3 代理评估的核心：从快速猜测到动态校准

代理评估是ArchPilot高效的关键。其核心流程是一个从“快速猜测”到“动态校准”的闭环：

1. 多代理信号采集：对于一个候选架构，EA会并行运行多个预定义的代理函数。例如：

   • 单周期验证（One-epoch Validation）：用10%的训练数据训练一个周期，看验证损失。快速检验模型的学习能力和泛化起点。
   • 带噪声验证（Noisy Validation）：在验证时给输入特征添加高斯噪声，评估模型的鲁棒性。
   • 特征丢弃验证（Feature-dropout Validation）：随机屏蔽一部分输入特征，检验模型是否过度依赖某些特定特征。 每个代理函数输出一个标量分数。这些分数方向可能不同（有的分数越高越好，如准确率；有的越低越好，如损失）。

2. 方向对齐与加权聚合：EA首先将所有代理分数统一到“越大越好”的尺度（例如，将损失乘以-1）。然后，将这些对齐后的分数进行加权求和，得到一个总的代理分数s(c)。公式如下：s(c) = Σ(λ_i * d_i * x_i(c)) / Σλ_i，其中Σλ_i = 1, λ_i ≥ 0。 这里，x_i是第i个代理的原始分数，d_i是其方向系数（+1或-1），λ_i是该代理的权重。初始权重通常是均匀分布或偏向最稳定的代理。

3. 权重动态优化（关键创新）：当系统积累了一定数量（例如5个）的“真实数据对”(y, x)后（其中y是全训练得到���真实性能，x是对应架构的代理分数向量），EA就会启动权重优化。它通过求解一个岭回归（Ridge Regression）问题，来学习如何组合代理分数才能最好地预测真实性能y。 具体是求解：arg min_λ ||Zλ - Y||^2_2 + α||λ||^2_2，其中Z是代理分数矩阵，Y是真实分数向量，α是正则化系数防止过拟合。求解得到的权重λ_hat可能为负或不和为1，因此需要将其投影回概率单纯形（即所有权重非负且和为1），得到最终的λ*。

4. 硬零策略与代理管理：为了保证稳定性，EA采用“硬零策略”：如果一个代理函数在评估某个架构时失败（返回一个巨大的哨兵值），则该代理的权重会在后续聚合中被强制设为0。同时，系统可以动态引入新的代理函数（例如由LLM提议），它们初始权重为0，直到有足够数据对其进行校准。如果代理函数总数超过预算，则淘汰权重最小的那个。

实操心得：代理函数的设计是门艺术。论文中提到的三种代理（单周期、噪声、特征丢弃）是很好的起点，但它们与最终性能的相关性因任务而异。在实际项目中，你需要针对你的任务类型（图像分类、序列预测等）设计或选择更具指示性的代理。例如，对于视觉任务，在极早期训练阶段（如几个batch后）的梯度范数、激活值分布等，有时也能成为有效的代理信号。关键在于，代理函数必须极度廉价（比全训练快几个数量级）且与最终性能存在潜在相关性。

3. 系统工作流与核心环节实现

理解了设计思路，我们来看ArchPilot是如何将这些组件串联起来，形成一个自动化搜索闭环的。下图清晰地展示了三个智能体之间的协作与数据流： （注：此处描述图1内容，实际行文中不嵌入Mermaid）协调智能体（OA）位于顶端，它根据MCTS策略从搜索树中选择一个候选节点。该节点及其上下文（任务描述、历史记忆等）被传递给生成智能体（GA）。GA则根据指令，执行“生成”、“改进”或“调试”操作，产出一个新的可执行训练脚本。这个脚本被交给评估智能体（EA）。EA决定进行快速的代理训练（产出代理分数向量）还是昂贵的全训练（产出真实性能分数）。评估结果反馈给OA，OA据此计算奖励，更新搜索树节点（Q值、访问次数N），并可能触发权重重拟合和树重启。整个循环在计算预算的约束下持续进行。

3.1 协调智能体（OA）：基于MCTS的智能调度器

OA是整个系统的大脑，其核心是管理一棵不断生长的搜索树，并做出序列决策。

1. 搜索树节点结构：每个节点v存储了以下信息：

   • c_v: 可运行的训练脚本代码。
   • x(c_v): 代理分数向量。
   • s(c_v): 聚合后的代理分数。
   • y(c_v): 真实性能分数（如果已进行全训练）。
   • Q_v: 累计奖励值。
   • N_v: 节点访问次数。
   • 执行结果（日志、错误等）。

2. MCTS四阶段循环：

   • 选择（Selection）：从根节点开始，递归地选择子节点，直到到达一个叶节点或未完全展开的节点。选择标准是UCT公式：UCT(v) = Q_v / N_v + C * sqrt(ln(N_parent) / N_v)其中，Q_v/N_v代表该节点的平均收益（利用），后半部分鼓励探索访问次数少的节点。常数C控制探索与利用的权衡。
   • 扩展（Expansion）：当选中一个节点后，OA会调用GA，并为其提供丰富的上下文信息，要求GA在该节点基础上进行“生成”、“改进”或“调试”操作，从而创建新的子节点。
   • 验证（Simulation/Evaluation）：新生成的子节点会被交给EA进行评估。EA执行代理训练，返回代理分数s(c_v)。如果满足特定条件（如节点代理分数很高，或预算充足），OA会决定对该节点进行“全训练”验证，获得真实分数y(c_v)。
   • 回溯（Backpropagation）：将本次评估得到的奖励R(v)沿着从该节点到根节点的路径反向传播，更新路径上所有祖先节点的Q值和N值。奖励R(v)的设计是稀疏的：无效节点得-1；有效节点则根据其是否调试成功、性能是否提升（对比代理分数或真实分数）来获得加分。

3. 树重启机制：这是ArchPilot的一个关键设计。当EA通过积累的真实数据优化了代理权重λ后，所有历史节点的代理分数s(c)都需要用新的权重重新计算。这可能导致节点的价值排序发生剧变。如果继续在旧的搜索树上探索，可能会在已经“贬值”的区域浪费资源。因此，OA会果断重启搜索树：它根据新的代理分数，重新评估所有节点，保留表现最好的Top-K个节点作为新的“根”集合，然后清空旧的搜索统计信息（Q,N），从这些优质起点重新开始探索。这个机制确保了搜索方向能及时跟随评估标准的变化。

4. 预算与成本控制：OA持有一个全局计算预算（如GPU小时数）。每次代理评估和全训练都会消耗预算。OA会严格追踪预算，并在预算耗尽时终止搜索。此外，它还实施了一些安全策略：例如，当剩余时间或预算非常紧张时，会关闭代理模式，直接使用全训练进行评估，以确保最后阶段资源的有效利用。

3.2 生成智能体（GA）：可靠且专注的代码工匠

GA的目标不是天马行空地创造，而是在给定上下文中，生成可运行、可测试、有改进的代码。它有三种工作模式，每种都要求输出精确、原子化的变更。

• 生成模式：给定任务描述、数据签名、可用资源包和短期记忆摘要，GA需要输出一个3-5句的自然语言计划，以及一个完整的、自包含的PyTorch训练脚本（包括数据加载、预处理、模型定义、训练循环和验证）。关键要求是：必须与记忆中已有的设计有区别，以促进探索的多样性。
• 改进模式：针对一个已经能正常运行（无bug）的父节点脚本，GA被要求提出且仅提出一个原子级的修改。例如：“增加Dropout层”、“将优化器从SGD改为AdamW”、“将网络某层的宽度从64增加到128”。OA会提供父节点代码、执行结果和兄弟节点的改进摘要。GA需要输出修改理由和只包含该处修改的脚本。这确保了每次改进的效果是可孤立评估的，便于OA分析不同修改的贡献。
• 调试模式：当节点脚本运行失败时，GA需要根据错误的代码、执行日志和OA提供的根因摘要（如张量形状不匹配、数据类型错误、设备错误、缺少提交文件等），生成一个最小的修复方案，同时尽量保留已验证的组件。

注意事项：GA提示工程是关键。提供给GA的上下文（Context）质量直接决定了其输出质量。除了基础的任务描述，OA提供的“短期记忆摘要”至关重要。它需要精炼地总结：1）已尝试过哪些架构或技巧（避免重复）；2）哪些修改带来了性能提升；3）常见的失败模式是什么。这能有效引导GA进行更有针对性的探索，避免在死胡同里打转。在实际部署中，这部分摘要的生成逻辑需要精心设计。

3.3 评估智能体��EA）：从成本控制到学习优化

EA是ArchPilot高效能的基石，它的工作远不止“跑个脚本打个分”那么简单。

1. 脚本插桩与执行：EA接收GA生成的脚本。对于代理评估，它会编写一个插桩版本。这个版本会：

   • 保留原始的��据和模型代码。
   • 将训练数据量减少到10%（或一个固定的小子集）。
   • 仅训练1个epoch。
   • 在执行过程中，调用所有已注册的代理函数。
   • 最终将所有代理分数以单行JSON格式打印到标准输出。 EA会捕获这个输出，解析出代理向量x(c)。如果JSON解析失败或任何代理函数返回失败哨兵值，该节点在本轮搜索中会被标记为无效。一个重要的细节是：如果异常发生在代理函数内部（而非原始训练脚本），该节点不会被标记为“buggy”，这避免了对GA生成代码的误判，将调试精力集中在真正的代码错误上。

2. 权重拟合的工程实现：当积累了足够多的(y, x)数据对后，EA需要求解那个岭回归问题。这里有几个工程上的考量：

   • 数据标准化：在拟合前，通常需要对代理分数x和真实分数y进行标准化（如Z-score），以避免量纲不同带来的问题。
   • 正则化系数α的选择：α的选择很重要。太小可能导致过拟合（尤其当数据点少时），太大会使权重趋于均匀。可以采用交叉验证或基于经验设置一个较小的固定值（如1e-3）。
   • 投影到单纯形：求解岭回归得到的是无约束的λ_hat。将其投影到概率单纯形（所有元素非负且和为1）是一个标准的优化问题，可以使用现有算法高效求解（例如，基于排序的算法）。
   • 触发重启的阈值ε：权重更新后，需要计算新权重λ*与旧权重λ的L1范数差。只有当这个差超过一个阈值ε（例如0.1）时，才触发树重启。这避免了因权重微小波动而导致的不必要的搜索重置。

3. 全训练触发策略：OA需要决定何时对一个节点进行全训练。一个简单的策略是：当节点的代理分数s(c)超过某个动态阈值（例如，当前搜索树中代理分数的前20%），或者当该节点被访问次数达到一定数量且表现稳定时，则启动全训练。全训练的结果y(c)不仅用于评估该节点的最终质量，更重要的是，它为代理权重的优化提供了宝贵的真实数据点。

4. 实战部署考量与常见问题排查

将ArchPilot这样的研究框架应用到实际项目中，会面临一系列工程化和领域适配的挑战。以下是我基于经验总结的关键点和避坑指南。

4.1 环境搭建与组件集成

ArchPilot不是一个开箱即用的产品，而是一个需要集成的框架。你需要搭建以下核心组件：

1. LLM后端：论文中使用的是GPT-4.1。你需要一个可靠的LLM API服务（如OpenAI API、Azure OpenAI Service或开源大模型+API服务器）。成本是首要考虑因素，因为GA、EA甚至OA的部分逻辑（如摘要生成）都可能需要调用LLM。
2. 计算集群与任务队列：EA需要调度和执行大量的代理训练和全训练任务。你需要一个任务队列系统（如Celery + Redis，或直接使用Kubernetes Jobs）来管理这些任务，并能够指定GPU资源。任务需要被隔离在沙箱环境中运行，以确保安全性和可复现性。
3. 状态存储与记忆管理：OA维护的搜索树、节点的代码、分数、日志等所有状态，必须持久化存储（例如使用数据库如PostgreSQL或键值存储如Redis）。这不仅是故障恢复所必需，也为事后分析和调试提供了可能。
4. 代理函数实现：你需要实现论文中提到的或其他自定义的代理函数。每个代理函数应该是一个独立的、可插拔的模块，接收模型、数据加载器等上下文，返回一个标量分数。确保它们的执行速度极快（秒级）。

避坑技巧：从简化版开始。不要试图一开始就实现完整的三智能体+MCTS+动态权重优化。一个有效的切入点是：先实现一个两阶段流水线。第一阶段：让GA生成一批（如50个）不同的初始架构草案，用一组固定的、简单的代理函数（如单周期验证）快速评分并排序。第二阶段：只对排名前10%的架构进行全训练。这个简化版已经能带来显著的效率提升。在此基础上，再逐步引入MCTS进行迭代改进、增加代理函数种类、最后实现动态权重优化。

4.2 代理函数的选择与设计

代理函数的质量直接决定搜索效率。以下是一些选择与设计原则：

• 相关性优先：代理函数与最终性能的相关性（如Spearman秩相关系数）比其绝对预测精度更重要。一个与最终排名高度相关的代理，即使预测的绝对值不准，也能完美指导搜索方向。
• 多样性互补：选择不同类型的代理函数，从不同角度评估架构。例如：
  • 基于训练：单周期损失、早期梯度统计量。
  • 基于初始化：网络初始化后的信号传播性质（如NASWOT分数）。
  • 基于扰动：输入噪声鲁棒性、特征丢弃鲁棒性。
  • 基于架构：参数量、FLOPs、层数（有时简单就是有效，特别是对延迟敏感的场景）。
• 任务特异性：对于图像分类任务，在ImageNet上预训练模型提取的特征相似度可能是一个强代理。对于自然语言处理任务，模型在某个小规模下游任务上的微调速度或困惑度下降速度可能有效。没有放之四海而皆准的代理，需要针对你的领域进行验证。

4.3 典型问题与排查思路

在实际运行中，你可能会遇到以下问题：

4.4 预算分配策略

计算预算是固定的，如何在代理评估和全训练之间分配，是一个需要权衡的策略。

• 早期阶段：预算应大量倾斜给代理评估，进行广泛的探索。可以设置较高的代理评估次数上限，MCTS的C值也可以设大一些。
• 中期阶段：随着高质量节点的出现和代理权重逐渐校准，可以逐步提高全训练的比例，对头部候选进行深入验证和微调。
• 后期阶段：当预算所剩无几时，应停止代理评估，将所有剩余资源用于对当前最优的几个候选进行最后的多轮训练和集成，以稳定最终性能。

OA可以根据剩余预算的百分比，动态调整触发全训练的代理分数阈值和MCTS的探索参数。

最后，我想分享一点个人体会。ArchPilot这类框架的价值，不仅仅在于它比之前的方法效果好了几个百分点，更在于它提供了一种系统性的工程思维范式：将复杂的智能问题分解为可管理的子任务，用快速近似评估驱动决策，并建立从近似到真实的持续学习闭环。这种“代理思维”和“多智能体协作”的模式，完全可以迁移到其他昂贵的自动化搜索问题上，比如超参数优化、数据增强策略搜索，甚至是芯片设计、化合物筛选等领域。它的核心启示是：在资源受限的现实世界中，“足够好且快速”的评估，往往比“绝对精确但缓慢”的评估，能带你走得更远。当你下次面临一个需要大量实验验证的探索性问题时，不妨先问问自己：我能设计一个什么样的“代理”，来帮我先筛掉那些明显不行的选项？