Inefficiencies of Meta Agents for Agent Design

论文阅读：Inefficiencies of Meta Agents for Agent Design

论文标题：Inefficiencies of Meta Agents for Agent Design

作者：Batu El、Mert Yuksekgonul、James Zou

作者机构：Stanford University（斯坦福大学）

发表位置：Findings of EMNLP 2025

arXiv 编号：2510.06711

原文链接：https://arxiv.org/abs/2510.06711

提交时间：2025 年 10 月 8 日

主题：自动化 Agent 设计、Meta-Agent、进化搜索、行为多样性、经济成本分析

核心问题：当 Meta-Agent 能够自动生成并迭代优化 Agent 时，它是否真的能够从历史设计中学习？生成的多个 Agent 是否具有互补性？自动化设计带来的性能提升是否足以抵消额外的设计与推理成本？

1. 论文要解决什么问题？

1.1 背景：让 LLM 自动设计 Agent

传统的 Agent 系统通常由研究人员手动设计。例如，面对复杂的推理任务，研究人员可能会选择以下方案：

  • 使用 Chain-of-Thought（CoT）引导模型逐步推理。
  • 使用 Majority Voting，通过多次采样和投票提高答案质量。
  • 使用 Reflection，让模型根据反馈反复修改答案。
  • 使用 Multi-Agent Debate，让多个模型实例相互讨论。
  • 设计不同的工作流，将任务分配给不同的模型或处理模块。

这些方案依赖人工经验。研究人员需要决定使用什么组件、采用什么工作流，以及如何组合这些设计。

随着 LLM 能力的提升，研究者开始尝试让 LLM 自动完成这项工作：由一个更高层次的 Meta-Agent 负责设计 Agent，并根据执行结果不断修改设计。

这一过程可以概括为：

  1. Meta-Agent 生成一个 Agent。
  2. 执行该 Agent，并在训练数据上评估其表现。
  3. 将执行结果反馈给 Meta-Agent。
  4. Meta-Agent 根据已有信息生成下一个 Agent。
  5. 重复上述过程，最终选出表现最好的 Agent。

这种方法通常采用 Sample–Evaluate–Iterate 范式，即采样、评估和迭代。

image

【Figure 1（Meta-Agent 自动设计 Agent 的整体框架，以及学习、多样性和经济成本三个分析维度）】

1.2 作者关注的三个问题

本文并不是提出一套全新的 Agent 架构，而是分析现有一类自动化 Agent 设计方法的不足。

作者重点研究三个问题。

问题一：Meta-Agent 是否真的能够从历史设计中学习？

已有方法通常会将之前生成的 Agent 及其评估结果加入上下文，希望 Meta-Agent 能够参考历史经验，逐步生成更好的设计。

但是，历史信息越多，就一定越好吗？

如果之前生成的 Agent 质量参差不齐，那么将所有历史设计都放入上下文，是否反而会干扰后续生成？

问题二：自动生成的多个 Agent 是否具有行为多样性？

Meta-Agent 在搜索过程中可能生成几十个不同的 Agent。

如果这些 Agent 的表现非常相似，例如总是解决相同的问题、在相同的问题上失败，那么即使生成了很多 Agent，它们也未必能够互补。

如果不同 Agent 擅长解决不同类型的问题，那么系统理论上可以根据输入动态选择合适的 Agent，或者组合多个 Agent 的结果。

因此，作者不仅关注单个 Agent 的性能，还关注整个 Agent 集合的行为多样性。

问题三：自动化设计是否具有经济价值？

自动设计 Agent 需要消耗额外的模型调用和评估成本。

即使自动设计得到的 Agent 比人工设计的 Agent 更准确，也不意味着这种方法一定划算。

例如，假设自动设计需要花费大量计算资源，最终只带来少量准确率提升，那么对于只执行几百个任务的应用来说，这笔成本可能完全不值得。

作者希望回答：需要部署多少个任务，自动设计得到的 Agent 才能在经济成本上超过现有方案？

2. 相关工作

本文的主要参考工作是 ADAS。

ADAS：Automated Design of Agentic Systems 尝试将 Agent 设计问题转化为代码空间中的搜索问题，让 Meta-Agent 自动生成 Agent 程序，并根据评估结果持续迭代。

除此之外，论文还讨论了几类相关研究：

工作 主要方向
ADAS 在代码空间中自动搜索 Agent 设计
AutoFlow 自动生成 LLM Agent 工作流
MAS-GPT 训练 LLM 自动构建多 Agent 系统
ScoreFlow 使用偏好优化学习 Agent 工作流
AgentSquare 在模块化设计空间中搜索 Agent
Archon 搜索和组合推理时使用的不同模块

这些研究关注如何自动生成或优化 Agent 系统。

本文则把重点放在对自动化设计过程的分析上：历史设计如何影响后续搜索、生成的 Agent 是否具有互补性，以及整个过程是否值得付出额外成本。

3. 方法：Meta-Agent 如何迭代设计 Agent？

3.1 基本框架

首先，需要明确论文中 Agent 的定义。

作者将一个 Agent 视为一个计算机程序：它接收问题作为输入，并通过调用语言模型来计算答案。

因此，本文所搜索的对象不是单纯的自然语言 Prompt，而是由代码表示的 Agent 设计。

这些代码可以实现不同的推理策略、模型调用方式和协作机制。

Meta-Agent 负责生成、修改和调试这些程序，而实际执行任务的是被生成的 Agent。

整个系统维护一个历史档案，记为 \(A\)。其中保存了已经发现的 Agent 及其在训练集上的评估结果。

对于第 \(i\) 个 Agent，作者将其评估结果表示为：

\[s_i = \operatorname{eval}(f_i,D_{\text{train}}) \in \mathbb{R}^{N_{\text{train}}} \]

其中：

  • \(f_i\) 表示第 \(i\) 个 Agent。
  • \(D_{\text{train}}\) 表示训练数据集。
  • \(N_{\text{train}}\) 表示训练样本数量。
  • \(s_i\) 是该 Agent 在每个训练样本上的评估结果组成的向量。

这里保存的不仅是 Agent 的总体分数，还包括它在不同训练样本上的具体表现。

例如，两个 Agent 的总体准确率可能都是 70%，但它们可能擅长解决不同的问题。这种差异在后续的多样性分析中非常重要。

3.2 一轮迭代具体做什么？

每一轮迭代都包含以下步骤：

  1. 选择上下文。 从历史档案中选择一部分 Agent 及其评估结果，作为 Meta-Agent 当前可以参考的信息。
  2. 生成 Agent。 Meta-Agent 根据所提供的上下文，使用语言模型生成新的 Agent 代码。
  3. 修改与调试。 对生成结果进行必要的格式修正和调试，并利用执行反馈处理代码问题。
  4. 评估 Agent。 在训练数据上运行新 Agent，获得其逐样本评估结果。
  5. 更新档案。 将新 Agent 及其评估结果加入历史档案，供后续迭代使用。

需要注意的是，作者并没有在这里提出新的模型训练算法。核心流程仍然是利用 LLM 生成程序，通过执行和评估提供反馈，再继续搜索。

真正影响搜索行为的是第一步：每一轮究竟应该让 Meta-Agent 看到哪些历史信息？

作者围绕这个问题设计了三种上下文选择策略。

3.3 三种上下文选择策略

作者将上下文选择函数记为 \(\phi\)。它决定从历史档案 \(A\) 中挑选哪些内容，供下一轮 Agent 生成使用。

3.3.1 Cumulative：累计式策略

累计式策略会将所有已经发现的 Agent 及其评估信息纳入上下文。

随着迭代次数增加，Meta-Agent 可以参考的历史设计也越来越多。

其设计逻辑是：历史信息能够帮助 Meta-Agent 总结过去的经验，从而逐步生成更好的 Agent。

但是，这种策略存在两个潜在问题：

  • 历史 Agent 的数量不断增加，上下文越来越长，生成成本也会随之增加。
  • 历史设计的质量可能参差不齐。将大量低质量设计也放入上下文，并不一定有利于后续搜索。

作者希望通过实验检验：累计历史设计是否真的能够提高 Meta-Agent 的学习效率。

3.3.2 Parallel：并行式策略

Parallel 策略采用了另一种思路。

它始终只向 Meta-Agent 提供初始 Agent 库中的 7 个 Agent 及其评估结果，不把后续生成的 Agent 加入下一轮的生成上下文。

因此，每一轮生成新 Agent 时，Meta-Agent 都以同一组初始设计作为参考，而不是不断吸收之前生成的结果。

这种策略的关键特点是：

  • 上下文规模保持固定。
  • 新生成的 Agent 不会直接成为后续迭代的参考对象。
  • 每个候选设计相对于初始库进行探索，而不是沿着之前生成的设计持续演化。

这里的 Parallel 并不意味着测试阶段会让多个 Agent 并行协作，也不意味着一定使用并发计算。它描述的是一种上下文选择方式。

这种策略实际上放弃了对历史生成结果的直接利用，以换取更稳定的搜索过程和更多样的候选设计。

3.3.3 Evolutionary：进化式策略

Evolutionary 策略试图结合前两种策略的优点。

它不会像 Cumulative 一样使用全部历史设计，而是从历史档案中选出表现最好的 7 个 Agent，作为下一轮生成的参考对象。

这些 Agent 相当于进化过程中的父代。

具体而言：

  1. 收集初始 Agent 和后续迭代生成的 Agent。
  2. 根据训练集评估结果对它们进行排序。
  3. 选择表现最好的 7 个 Agent。
  4. 将这些 Agent 及其评估信息提供给 Meta-Agent。
  5. 生成新的 Agent，并继续评估和更新档案。

与累计式策略相比，它过滤掉了大量低分设计；与并行式策略相比，它允许高质量的历史设计影响后续生成。

作者希望通过这种方式，让 Meta-Agent 更有效地利用已有搜索结果。

3.4 三种策略的核心区别

对比维度 Cumulative Parallel Evolutionary
使用初始 Agent 库 是 是 是，作为候选档案的一部分
使用之前生成的 Agent 全部使用 不使用 只使用表现最好的 7 个
上下文规模 随迭代增加 固定 固定为 7 个 Agent 的参考集合
是否利用历史生成结果 是 否 是，选择性利用
搜索倾向 累积历史信息 独立探索新设计 利用高分设计继续探索
主要潜在问题 上下文膨胀、低质量历史干扰 难以直接吸收后续搜索经验 可能不断生成相似的高分设计

这三种策略构成了本文后续实验的基础。

4. 实验设置

4.1 数据集

作者选择了四个不同类型的基准数据集。

数据集 任务类型 训练集规模 测试集规模 评价指标
DROP 阅读理解与离散推理 128 200 F1
MGSM 多语言数学推理 128 200 Accuracy
MMLU 多任务知识与问题求解 128 200 Accuracy
GPQA 研究生水平科学问题 32 个样本，重复评估 5 次 160 Accuracy

对于 GPQA，作者将 32 个训练样本各评估 5 次，以降低评估波动；因此训练阶段共进行 160 次样本级评估。

作者使用训练集评估候选 Agent，并在测试集上检验最终选出的 Agent，以区分搜索阶段的表现和留出数据上的表现。

4.2 使用的模型

实验采用两个不同的模型承担不同职责：

  • GPT-4o：Meta-Agent。 负责生成、修改和调试 Agent 代码。
  • GPT-3.5：Agent 执行模型。 负责执行被设计出来的 Agent 中的语言模型调用。

因此，Meta-Agent 与被设计的 Agent 并不是同一个角色。

前者负责搜索和设计，后者负责具体任务执行。

作者在每次实验中执行 30 轮 Agent 设计，并将结果在 3 次独立运行上取平均。

4.3 初始 Agent 库

初始 Agent 库由 7 种已有方法组成。

方法 基本思路
Chain-of-Thought 引导模型先输出推理过程
Majority Voting 多次生成答案，再通过投票选择结果
Refinement from Feedback 根据反馈反复改进答案
LLM-Debate 让多个语言模型实例相互讨论
Quality-Diversity 生成并集成多样化的回答
Routing 根据任务选择合适的模型或专家角色
Stepping-back 先考虑相关的高层原理，再解决具体问题

这 7 种方法为 Meta-Agent 提供了初始搜索空间。

后续生成的 Agent 可以在这些设计基础上进行修改，也可以探索不同的程序结构。

5. 实验结果

5.1 Meta-Agent 是否能够从历史设计中学习？

作者首先比较三种上下文策略在训练集上的最佳 Agent 表现。

下表仅展示每种策略在各数据集上的最佳 Agent 分数。括号内为原论文报告的波动量，结果为 3 次运行的平均表现。

数据集 Cumulative Parallel Evolutionary
DROP 71.4 (2.0) 72.5 (4.2) 74.4 (3.2)
MGSM 41.4 (6.2) 56.2 (10.5) 56.5 (4.7)
MMLU 74.7 (2.0) 76.3 (1.6) 76.6 (2.7)
GPQA 32.3 (2.6) 35.2 (2.8) 33.8 (2.2)
平均 55.0 60.0 60.3

结果表明，累计式策略并没有取得最好的训练表现。

相反，Parallel 在四个数据集上的平均最佳分数明显高于 Cumulative。Evolutionary 的平均最佳分数略高于 Parallel。

尤其是在 MGSM 上，Cumulative 的最佳分数为 41.4，而 Parallel 和 Evolutionary 分别达到 56.2 和 56.5。

这说明，简单地向上下文中添加越来越多的历史 Agent，并不能保证 Meta-Agent 更有效地利用这些信息。

相比之下，筛选高质量历史设计的进化式策略，可以改善搜索结果。

不过，训练集上的最佳分数并不能完全代表泛化表现。还需要观察这些 Agent 在独立测试集上的结果。

5.2 测试集表现：进化式策略并非始终最优

作者根据训练集表现选出每种策略的最佳 Agent，再在测试集上评估。

下表中的 Initial 表示从初始 Agent 库中选出的最佳 Agent，其他三列分别对应三种自动化设计策略。

数据集 Initial Cumulative Parallel Evolutionary
DROP 64.8 (1.3) 71.9 (3.2) 72.6 (7.8) 73.2 (5.1)
MGSM 38.4 (2.8) 41.2 (4.8) 51.8 (7.6) 53.5 (2.0)
MMLU 62.8 (2.3) 66.2 (4.2) 67.8 (0.8) 65.8 (3.3)
GPQA 30.0 (2.4) 29.7 (2.7) 31.3 (0.0) 28.5 (3.1)
平均 49.0 52.2 55.9 55.2

从测试结果可以看到几个现象。

第一，自动化设计能够带来性能提升，但提升幅度因任务而异。

例如，在 MGSM 上，Parallel 和 Evolutionary 的测试准确率分别达到 51.8 和 53.5，明显高于初始 Agent 库的 38.4。

但在 GPQA 上，Evolutionary 的测试分数只有 28.5，低于初始 Agent 库的 30.0。

因此，自动化设计并不是对所有任务都有效。

第二，Evolutionary 的训练表现略好，但测试集上的平均表现不如 Parallel。

Evolutionary 的最佳训练分数平均为 60.3，高于 Parallel 的 60.0。

然而，在测试集上，Parallel 的平均分数为 55.9，Evolutionary 为 55.2。

这表明，搜索阶段的最佳分数与测试阶段的整体表现并不完全一致。不能只根据训练集上的最高分，就判断某种搜索策略更优。

第三，Parallel 在不同任务之间表现出较好的稳定性。

Parallel 在四个数据集中的三个数据集上取得了最高的测试分数或并列最高分数中的最佳表现，并且整体平均分数最高。

综合来看，选择性利用历史信息有助于搜索，但并不是利用历史信息越多，最终效果就越好。

6. Agent 的行为多样性与互补性

6.1 为什么需要研究 Agent 多样性？

假设 Meta-Agent 生成了 30 个 Agent。

如果这 30 个 Agent 都采用相似的推理方式，那么它们可能会解决相同的问题，也会在相同的问题上失败。

即使其中某个 Agent 表现很好，其他 Agent 也未必能够为它提供额外价值。

相反，如果不同 Agent 的能力具有互补性，那么系统就可以考虑根据输入动态选择 Agent，或者在必要时组合多个 Agent 的输出。

因此，Agent 的数量并不能直接代表系统的有效搜索范围。

作者希望回答两个问题：

  1. 不同 Agent 在训练样本上的表现究竟有多相似？
  2. 整个 Agent 集合能够覆盖多少不同的问题？

6.2 如何衡量 Agent 的行为多样性？

作者并不是通过比较 Agent 代码的文本差异来衡量多样性，而是通过它们在训练样本上的表现进行比较。

具体来说，每个 Agent 都有一个评估向量，记录其在不同训练样本上的得分。

例如：

  • Agent A 擅长数学推理，但在科学问题上经常失败。
  • Agent B 擅长科学问题，但在某些数学问题上表现不佳。

即使两个 Agent 的总体准确率相同，它们的逐样本表现也可能明显不同。

作者将所有 Agent 的评估向量组合成一个矩阵，再计算不同 Agent 之间的余弦相似度。

这种方法衡量的是行为相似性，而不是代码相似性。

如果两个 Agent 经常在相同的问题上答对，并且在相同的问题上答错，那么它们的行为相似度就会较高。

反之，如果它们擅长解决不同的问题，行为相似度就会较低。

需要注意，这种相似性度量并不直接证明两个 Agent 可以在组合后提升性能，但能够反映它们是否具有潜在的互补空间。

6.3 实验发现：进化搜索提高性能的同时，可能降低多样性

作者发现，Evolutionary 生成的 Agent 通常具有较高的行为相似度。

这与其搜索机制有关：每轮都选择表现最好的 7 个 Agent 作为参考对象，新生成的 Agent 更容易受到高分设计的影响。

这种机制有利于集中搜索高质量设计，但也可能使搜索逐渐集中于相似的解决方案。

Parallel 则不直接利用之前生成的 Agent，因此更容易探索不同的设计方向。

Cumulative 的行为相似度整体上更低，表现出较高的行为多样性，但其搜索性能并不理想。

这说明，性能优化和行为多样性之间可能存在权衡。

6.4 覆盖率分析

作者还引入了覆盖率指标。

覆盖率表示：在整个生成的 Agent 集合中，至少有一个 Agent 能够正确回答的问题所占的比例。

它与单个 Agent 的准确率不同。

例如，一个 Agent 只能回答 70% 的问题，而多个具有互补性的 Agent 组合起来，可能至少有一个能够回答的题目超过 90%。

论文报告的覆盖率如下：

数据集 Cumulative Parallel Evolutionary
DROP 96.6% 96.0% 93.6%
MGSM 89.1% 95.3% 93.0%
MMLU 99.2% 97.7% 99.2%
GPQA 91.9% 94.4% 91.9%
平均 94.2% 95.9% 94.4%

这些结果是对每种策略生成的 90 个 Agent 进行统计得到的，即每种策略在 3 次运行中各生成 30 个 Agent。

Parallel 的平均覆盖率最高，达到 95.9%。

这与前面的相似度分析相呼应：Parallel 能够在保持较好单体性能的同时，探索更多样的解决方案。

不过，覆盖率并不意味着论文已经实现了一个能够自动选择最佳 Agent 的系统。这里统计的是整个候选集合的潜在覆盖能力，而不是单个 Agent 在测试时能够直接获得的准确率。

作者指出，当前这类 Meta-Agent 通常在测试阶段只部署一个选定的 Agent，因此多个候选 Agent 之间的潜在互补性还没有被充分利用。

7. 自动化 Agent 设计是否划算？

7.1 设计成本与推理成本

即使自动设计能够提高准确率，也需要考虑额外成本。

论文将自动设计得到的 Agent 的总成本分成两部分：

  • \(C_0\)：固定设计成本，包括生成 Agent、修改与调试，以及评估候选 Agent 所产生的成本。
  • \(C_j\)：每个测试样本的推理成本。
  • \(n\)：部署时处理的测试样本数量。

因此，总成本可以写为：

\[C_{\text{total}}(n)=C_0+n\cdot C_j \]

这个公式体现了一个重要特点：自动化设计需要先支付固定成本，之后每处理一个新问题，又会产生额外的推理成本。

对于人工设计的初始 Agent 库，论文在这一成本模型中不计入自动搜索所产生的固定设计成本。

因此，自动设计方案必须通过更好的任务表现、更低的推理成本，或者两者的结合，才能逐渐抵消前期的搜索开销。

7.2 三种策略的成本差异

作者发现，不同上下文策略产生的 Agent，在推理成本上存在明显差异。

总体上，平均推理成本的排序为：

Cumulative > Evolutionary > Parallel > Initial。

也就是说：

  1. Cumulative 生成的 Agent 平均推理成本最高。
  2. Evolutionary 次之。
  3. Parallel 在三种自动化设计策略中成本最低。
  4. 初始 Agent 库中的方法整体成本最低。

其中，Cumulative 的问题不仅在于推理成本较高，还在于生成成本会随着历史上下文增长而不断增加。

当历史档案越来越大时，Meta-Agent 需要处理越来越多的历史设计，下一轮生成所需的成本也会随之增加。

Parallel 和 Evolutionary 则始终只使用 7 个 Agent 作为上下文，因此其上下文规模保持固定。

7.3 什么时候能够收回设计成本？

作者进一步比较了不同部署规模下，每个正确答案所对应的成本。

结果显示，在 DROP 和 MMLU 上，采用 Parallel 策略时，自动设计得到的最佳 Agent 大约需要部署在 15,000 个测试样本上，才能达到比初始 Agent 库更低的单位正确答案成本。

对于其他数据集和上下文策略，作者没有发现设计成本能够被性能收益抵消的盈亏平衡点。

这意味着，自动化 Agent 设计的经济价值与任务类型和部署规模密切相关。

对于需要大量重复执行的任务，即使前期设计成本较高，后续仍有机会通过规模化部署收回成本。

但如果任务数量有限，或者性能提升不足，那么自动化搜索未必比直接使用现有 Agent 更划算。

这里的 15,000 个样本是论文特定实验配置下的结果，并不是适用于所有 Agent 系统的通用阈值。

8. 局限性

作者在论文中明确讨论了以下局限性。

8.1 研究范围有限

本文重点研究采用 Sample–Evaluate–Iterate 范式的 Meta-Agent。

因此，论文发现的问题不一定适用于所有自动化 Agent 设计方法，尤其不能直接推广到采用其他搜索、训练或架构生成机制的系统。

8.2 评估指标有限

论文主要使用 Accuracy 和 F1 评估任务表现。

对于更强调输出一致性、稳定性或其他业务效用的任务，本文的实验结论未必能够直接适用。

8.3 经济分析依赖任务设置

论文的经济分析主要适用于能够可靠验证答案正确性的场景。

如果任务没有明确的正确答案，或者评估成本、人工审核成本占据主要部分，那么成本模型可能需要重新设计。

8.4 行为相似性指标存在偏差

作者使用余弦相似度比较 Agent 的逐样本评估向量。

这种方法存在一定偏差：高性能 Agent 更容易因为共同答对的问题而显得相似，而持续失败的 Agent 可能被判断为相互正交。

为了检验结论的稳健性，作者还使用了基于 Hamming 距离的相似性指标，并观察到相近的整体趋势。

8.5 搜索过程具有随机性

Meta-Agent 的生成结果、被设计 Agent 的执行过程，以及不同迭代轨迹上的评估结果都具有随机性。

前一轮的微小差异还可能改变后续搜索方向。

作者的实验结果取自 3 次运行的平均值，并指出，更可靠的结论通常需要更多次独立运行。

8.6 自动生成程序的安全风险

自动化设计系统会生成并执行复杂程序。如果缺乏必要的检查，这些程序可能带来安全风险。

因此，在部署之前，仍需要考虑对自动生成系统的审计与控制。

9. 总结

本文围绕 Meta-Agent 自动设计 Agent 的过程，研究了历史信息利用、行为多样性和经济成本三个方面。

首先，作者发现，将全部历史 Agent 不加筛选地加入上下文，并不能保证更好的搜索结果。相比之下，Evolutionary 通过选择表现最好的历史 Agent，能够改善训练阶段的搜索表现；Parallel 则在测试集平均表现上取得了最好的结果。

其次，作者发现，Agent 的性能与行为多样性之间存在一定权衡。Evolutionary 更倾向于生成行为相似的 Agent，而 Parallel 在保持较好性能的同时获得了最高的平均覆盖率。

最后，作者从经济成本角度指出，自动化设计需要额外的固定成本，并且生成的 Agent 不一定具有更低的推理成本。在实验设置中，只有 DROP 和 MMLU 上采用 Parallel 策略的方案，在大约 15,000 个测试样本的部署规模下实现了成本盈亏平衡。

总体而言，这篇论文的核心工作是对一类自动化 Agent 设计范式进行系统分析。它说明，评估这类系统时，不能只关注搜索得到的最高准确率，还需要考虑历史信息是否真正发挥作用、候选 Agent 是否具有互补性，以及性能提升能否抵消整个设计和部署过程的成本。

参考

  1. El, Batu, Mert Yuksekgonul, and James Zou. Inefficiencies of Meta Agents for Agent Design. arXiv:2510.06711, 2025. 论文原文
  2. Hu, Shengran, Cong Lu, and Jeff Clune. Automated Design of Agentic Systems. arXiv:2408.08435, 2024. 论文原文
  3. Li, Zelong, et al. AutoFlow: Automated Workflow Generation for Large Language Model Agents. arXiv:2407.12821, 2024. 论文原文
  4. Shang, Yu, et al. AgentSquare: Automatic LLM Agent Search in Modular Design Space. arXiv:2410.06153, 2024. 论文原文
  5. Saad-Falcon, Jon, et al. Archon: An Architecture Search Framework for Inference-Time Techniques. arXiv:2409.15254, 2024. 论文原文
posted @ 2026-10-29 17:02  YourF4u1t  阅读(13)  评论(0)    收藏  举报