Skip to main content
2026ICLR 2025

让 AI 自己设计 AI:ADAS 与 Meta Agent Search

Automated Design of Agentic Systems

Jeff Clune 团队在 ICLR 2025 提出 ADAS 研究方向,通过 Meta Agent Search 算法让 LLM 在代码空间中自动发现和设计 Agent 系统。发现的 Agent 在多个领域大幅超越手工设计基线,且具有跨领域和跨模型的强迁移性。

Shengran Hu, Cong Lu, Jeff Clune
AI解读Agent 架构设计Meta-LearningCode Search Space

论文概览

机器学习的历史反复证明一个规律:手工设计的方案最终会被学习到的方案取代。CNN 架构被 Neural Architecture Search 取代,手工损失函数被学习到的损失函数超越。Jeff Clune 团队在 ICLR 2025 发表的这篇论文,将这一逻辑推向了 Agent 系统的设计本身——能否让 AI 自动设计 Agent?

论文提出了 ADAS(Automated Design of Agentic Systems) 这一新研究方向,并给出了一个简单而有效的具体算法 Meta Agent Search。核心思路是:用一个 LLM(Meta Agent)作为"设计师",在代码空间中迭代地编写新的 Agent 程序,每次都基于一个不断增长的发现档案(Archive)来获得灵感。由于编程语言是 Turing Complete 的,这个搜索空间理论上可以表示任何可能的 Agent 系统——包括新的 prompt、工具使用方式、工作流,以及它们的任意组合。

实验结果令人印象深刻:在 ARC 逻辑推理、数学(MGSM)、阅读理解(DROP)、多任务(MMLU)和科学问答(GPQA)五个领域中,自动发现的 Agent 全面超越所有手工设计基线。更令人惊讶的是,这些 Agent 展现出强迁移性——在数学领域发现的 Agent,迁移到阅读理解领域后仍然优于专门为阅读理解设计的手工 Agent。

核心创新

1. 代码作为 Agent 的搜索空间

ADAS 的三要素定义清晰:搜索空间、搜索算法、评估函数。这篇论文的关键贡献在于选择代码空间作为搜索空间。Agent 的全部行为被定义为一个 Python forward() 函数,输入是任务信息,输出是最终答案。

这个选择带来四个优势:

  • Turing Complete:理论上可以表示任何 Agent 设计,从简单的 Chain-of-Thought 到复杂的多步 Peer Review 工作流
  • 可解释性:代码天然可读,便于调试和安全审计——这在 Agent 安全日益重要的当下尤为关键
  • 可复用人类成果:可以直接在 LangChain 等现有框架上构建,站在人类积累的基础上搜索
  • FM 天然擅长:当前 LLM 在代码生成上已经非常强大,搜索效率远高于在图结构或网络权重空间中搜索

2. Meta Agent Search 算法

算法本身出奇简洁,可以用一个循环概括:

text
初始化 Archive(包含基线 Agent) for i = 1 to N: Meta Agent 基于 Archive 设计新 Agent -> 编写 Python 代码 -> 两轮自反思确保新颖性和正确性 在验证集上评估 -> 如有错误,修正最多 5 次 将 Agent 和评估结果加入 Archive 返回最终 Archive

关键设计选择有两个。第一,Meta Agent 使用 GPT-4,而被评估的 Agent 使用 GPT-3.5(降低成本),这种"强模型设计、弱模型执行"的分工本身就是一个有趣的发现。第二,搜索策略借鉴了开放式算法(Open-endedness)的思想——不是简单地优化性能,而是鼓励探索"有趣的"新设计,避免陷入局部最优。

3. 涌现的设计模式

Meta Agent 自主发现了多种复杂设计模式,以下是三个代表性 Agent:

Structured Feedback and Ensemble Agent(ARC 最佳):生成 5 个初始候选解 → 3 个领域专家(效率专家、可读性专家、简洁性专家)分别提供反馈 → 结构化反馈去冗余后迭代精炼 3 次 → 选 Top-3 集成决策。这个设计的复杂度远超任何手工基线。

Multi-Step Peer Review Agent:4 个领域专家各自独立解题 → 互相评审(每个专家的答案被其他专家批评)→ 基于反馈精炼 → 最终决策模块集成。本质上实现了一个自动化的学术同行评审流程。

Divide and Conquer Agent:将问题分解为子问题 → 分配给专门专家 → 集成子答案。这个经典的分治策略被 Meta Agent 自主"重新发明"了。

方法论详解

框架设计

论文提供了一个不到 100 行的简单框架。核心抽象是 FM_Module 类——封装了一次 LLM 调用,包含角色描述、输出字段、温度等参数。AgentSystemforward() 方法就是 Agent 的全部逻辑:

python
class AgentSystem: def forward(self, taskInfo) -> Union[Info, str]: """ taskInfo: 任务信息 (namedtuple) return: 最终答案 """ pass

Meta Agent 在这个框架内编写 forward() 的实现。框架提供了 FM_Module(LLM 调用)和工具函数(如 ARC 中的代码测试函数),Meta Agent 通过组合这些原语来构建任意复杂的 Agent。

搜索过程的信息流

Meta Agent 每次迭代接收三部分输入:

  1. 领域描述:任务的自然语言描述和示例
  2. 框架代码:可用的 API 和工具函数
  3. 发现档案:之前所有 Agent 的名称、代码和评估分数

输出是一个 JSON 对象,包含 thought(设计思路)、name(Agent 名称)和 code(实现代码)。随后进行两轮自反思——第一轮检查新颖性和实现错误,第二轮在运行时错误发生时进行调试。

新颖性导向的探索

算法没有使用复杂的强化学习或进化策略,而是依靠 LLM 自身的推理能力来平衡探索与利用。Meta Agent 被要求"观察档案中的发现,思考可以学到什么洞见、教训或垫脚石",并"跳出框架思考"(THINK OUTSIDE THE BOX)。这种基于 LLM 的开放式搜索,比传统搜索算法更高效,因为 LLM 能利用其训练中学到的丰富 Agent 设计知识。

实验结果

多领域性能对比

AgentDROP (F1)MGSM (Acc%)MMLU (Acc%)GPQA (Acc%)
Chain-of-Thought64.228.065.429.2
COT-SC64.428.265.930.5
LLM Debate60.639.065.631.4
Step-back Abstraction60.431.165.126.9
Role Assignment65.830.164.531.1
OPRO (Prompt优化)69.130.667.632.9
Meta Agent Search79.453.469.634.6

最显著的提升在数学推理(MGSM):从最佳基线的 39.0% 跃升到 53.4%,绝对提升 14.4 个百分点。阅读理解(DROP)也提升了 10.3 个 F1 点。这证明代码空间搜索比仅优化 prompt(OPRO)有本质优势——因为 Agent 的工作流结构本身被优化了。

跨领域迁移

从 MGSM(数学)发现的 Top-3 Agent 被迁移到其他领域:

迁移目标最佳基线ADAS 迁移提升
GSM8K (数学)43.6%69.5%+25.9%
GSM-Hard (数学)18.0%31.2%+13.2%
MMLU (多任务)65.9%65.9%+0.0%
DROP (阅读理解)64.4%64.9%+0.5%

在数学领域内的迁移效果惊人(+25.9%),但更值得关注的是跨领域迁移——在数学领域发现的 Agent,在阅读理解任务上仍然优于所有手工基线。这说明 Meta Agent 发现的不是特定领域的 trick,而是具有通用性的推理策略。

跨模型迁移

在 ARC 上用 GPT-3.5 搜索到的 Agent,迁移到其他模型后仍然保持优势:

AgentGPT-3.5Claude-HaikuGPT-4Claude-Sonnet
Self-Refine (基线)6.7%6.3%23.0%39.3%
Dynamic Memory Agent12.7%9.7%37.0%48.3%

最佳 Agent 在 Claude-Sonnet 上达到 48.3%,而最强的手工基线 Self-Refine 只有 39.3%。论文还观察到一个有趣现象:GPT-3.5 上最优的 Agent 使用复杂反馈机制,但迁移到更强模型后,使用简单反馈但更多精炼的 Agent 反而更好——弱模型需要更多"脚手架"来补偿能力不足。

初始化的影响

论文比较了使用基线 Agent 作为初始 Archive 和空初始化两种策略。一个反直觉的发现:在数学领域,空初始化效果更好(67.5% vs 53.4%)。论文推测这是因为没有预定义设计模式的束缚,Meta Agent 进行了更广泛的探索。对于需要灵活多变策略的任务,"从零开始"反而可能优于"站在巨人肩膀上"。

启示与思考

ADAS 的深层含义

这篇论文让我想到 Sutton 的"The Bitter Lesson"——手工设计的特征被学习取代,手工设计的架构被 NAS 取代,现在轮到手工设计的 Agent 系统了。ADAS 提供了一个统一的视角:与其争论 CoT vs Self-Refine vs Debate 哪个更好,不如让搜索来发现最优组合。

代码空间的选择是关键。与 PromptBreeder(仅搜索 prompt 文本)或 AgentOptimizer(仅搜索工具配置)相比,代码空间覆盖了 Agent 的全部维度——prompt、工具、工作流、控制流、数据结构。而且代码的可读性使得发现可以被人类理解和复用,这是黑盒搜索(如神经网络权重)无法做到的。

安全性视角

论文在安全方面着墨不多但方向正确:容器化执行所有生成代码、手动检查有害行为、代码可审计性本身就是安全优势。不过我认为这里有一个更深层的张力:ADAS 的目标是自动发现越来越强大的 Agent,而这些 Agent 的设计可能超出人类的理解范围。即使代码可读,理解一个 50 行的复杂多步工作流的全部行为含义仍然困难。随着 ADAS 的发展,如何对自动发现的 Agent 进行安全验证将是一个关键问题。

这也与 AARM 框架的思路呼应——自动发现的 Agent 同样需要经过意图授权、执行隔离和副作用验证三层安全架构的约束。

局限性与未来方向

论文承认当前仅评估了单步 QA 任务,没有涉及多步交互的复杂环境。搜索成本也不低——ARC 的一次搜索约 500,四个领域约500,四个领域约 1200。更智能的评估函数(如利用 LLM 评估 Agent 设计而非仅看准确率)可能降低成本。

最令人兴奋的未来方向之一是种子化 ADAS——将现有的 LangChain 工具、RAG 系统等作为搜索起点,让 Meta Agent 在人类积累的基础上进一步创新。另一个方向是支持多模型 Agent——让 Meta Agent 选择不同 FM 作为模块,根据难度和数据隐私需求灵活组合。

与近期工作的关联

ADAS 与 Self-Compacting Agents 和 ZipRL 形成有趣的互补关系。后两者解决的是"Agent 运行时如何管理上下文",而 ADAS 解决的是"Agent 的架构设计本身如何自动化"。一个自然的组合是:用 ADAS 搜索 Agent 架构,同时在搜索过程中加入上下文压缩作为可选模块——让 Meta Agent 自主决定是否以及如何使用压缩策略。

参考链接