arXiv'26 | MAGA：Make AutoML Great Again，把 LLM Agent 拉回 NAS
arXiv’26 | MAGA：Make AutoML Great Again，把 LLM Agent 拉回 NAS
原文：Building LLM Agent Systems the Deep Learning Way: From Modular Design to Architecture Search
1. Agent 还在靠“手搓”，这事本身就很不 Deep Learning
最近 Agent 论文有一种熟悉的味道：加个 memory，再接个 retrieval，挂上 planning，最后来一段 reflection。每个模块单拿出来都有道理，拼起来也往往能跑；但问一句“为什么是这几个模块、这个顺序、这些参数”，多数时候答案还是——经验。
这和深度学习爆发前的模型设计很像。大家靠直觉手工堆网络；后来有了标准模块、端到端训练和 NAS，问题才从“这层该不该加”逐渐变成“把设计空间定义好，让算法去找”。
UIUC 的这篇新论文干脆把这个类比推到底：别把 LLM Agent 当成一堆临时拼装的 prompt，把它当成一张可以搭建、反馈、搜索的神经网络。
所以，今天的口号叫：
MAGA：Make AutoML Great Again。
不是让 Agent 再造一遍 2017 年的 NAS，而是把 AutoML 最朴素的三件事——定义搜索空间、设计评估信号、自动迭代优化——搬到 Agent system design 上。
这篇论文标题里没有 MAGA，但它做的事情确实很 MAGA：把 memory、retrieval、Tree/Graph of Thoughts 这些 Agent 积木翻译成 RNN、attention、GNN；把 prompt 当成可更新的“参数”；最后再用 Optuna 搜整个系统的配置。
先说结论：这不是一套已经足以替代成熟 Agent framework 的工程方案，实验也还有明显边界；但它把“Agent 结构设计”这个目前相当玄学的问题，重新表述成了一个标准的 AutoML 问题。这件事本身很值得聊。
2. 先把 Agent 翻译成网络：积木不是比喻，是搜索空间的坐标系
论文的第一步看上去有点像给 Agent 模块重新贴标签，但这个标签很关键。只有模块有了统一坐标系，后面的组合、比较和搜索才有依据。
| LLM Agent 里的模块 | 论文对应的深度学习模块 | 真正对应的能力 |
|---|---|---|
| 一个 vanilla LLM | 单层 MLP | 输入 query，输出 response |
| memory processor | RNN | 保存过去的交互，并影响下一步 |
| retrieval | attention | 从语料中挑出当前 query 最相关的信息 |
| ToT / GoT | GNN | 将问题拆成相连、可扩展的 thought 节点 |
| meta prompt | 可训练参数 | 约束系统每轮如何推理与输出 |
| self-reflection | loss function | 给当前结果一个可供优化的反馈 |
这里最需要避免一个误解：论文不是说 retrieval 的实现等于 Transformer attention，也不是说 ToT 真成了一层可微 GNN。 它做的是功能同构：两者都在解决哪类信息要被保留、选择或组合的问题。
- memory 像 RNN，是因为它把历史 response 和 evaluation 带进下一轮，让状态跨时间延续；
- retrieval 像 attention，是因为 query 和 corpus 先做相似度匹配，再取 top-$K$ context。单 query retrieval 对应 single-head，多个生成 query 并行检索则接近 multi-head；
- ToT / GoT 像 GNN，是因为 question 被展开成 thought 节点，节点之间有树或图的依赖关系；树只是图的特殊情况。
这套映射的价值不在“命名得多像”，而在它把 Agent architecture 变成了一组可枚举的选择：任务需要长历史，就考虑 memory / RNN；任务依赖外部知识，就打开 retrieval / attention；问题需要发散探索，再加入 Tree 或 GNN。模块本身、连接顺序、各模块预算，全部可以进入搜索空间。
图 1：论文将 vanilla LLM、memory、retrieval 与 ToT/GoT 分别映射为单层 MLP、RNN、attention network 和 GNN；这是本文用于定义 Agent 搜索空间的模块坐标系。来源：论文 Figure 1；原始资源：arXiv v1 source。
这就是 MAGA 的第一层：不是先问“该用哪个 Agent 框架”，而是先问“我的 architecture search space 到底是什么”。
3. Prompt 不是权重，但可以像权重一样被反馈信号推动
第二层是论文里最容易被宣传话术带偏的部分：作者把 meta prompt 视为训练参数，把 self-reflection 视为 loss，再将其称为 LLM 的“forward / back propagation”。
这当然不是对 base model 反向传播。没有梯度穿过 API，也没有更新 LLM 权重。它更准确的运行方式可以写成下面这个循环：
\[r_t = F_{\mathcal{A}}(q; P_t), \qquad e_t = E(q, r_t), \qquad P_{t+1} = U(P_t, r_t, e_t)\]其中，$\mathcal{A}$ 是选定的 Agent architecture，$P_t$ 是第 $t$ 轮 meta prompt，$r_t$ 是本轮 response，$e_t$ 是对它的评估，$U$ 则把 response 和 feedback 重新写入下一轮所见的 prompt 上下文。
人话：系统先做一遍题，再给自己的答案打分或写评语，然后把“刚才怎么做、哪里错了”塞回下一轮说明书里。 它和 backprop 的相似之处，是都有“前向产生输出 → 用外部信号评价 → 用评价改变下轮行为”的闭环；不同之处，是这里更新的是上下文和指令，而不是连续权重。
图 2：输入经由 MLP、RNN、attention 与 directed GNN 等模块组合生成 response；self-reflection 通过 LLM evaluation 或 metric calculation 产生反馈，并更新下一轮所见的 meta prompt。来源：论文 Figure 2；原始资源：arXiv v1 source。
论文根据反馈是否可程序化计算，分了两种 evaluator：
- 对 TSP 这类目标明确的问题，用 metric calculation 直接计算路线质量；
- 对开放式、难以写死指标的 response，调用另一个 LLM 做 evaluation。
这个区分很务实。毕竟当 evaluator 本身也在胡说时，你并没有获得一个 loss，只是多获得了一位会写长评语的同事。论文实验中，feedback propagation 在多数场景带来至少 5% 的性能提升；在 TSP 上，随着反馈轮数增加，系统效果持续改善。
不过这里也埋着一个非常现实的工程代价：每一轮优化都额外消耗生成和评估调用。论文主要报告任务指标，没有把 token 成本、端到端 latency 与 evaluator 偏差作为同等规格的对比项。把“prompt 能被迭代优化”变成生产里的“值得被迭代优化”，仍然要算账。
4. 用 Agent 搭一个 Transformer：多 query retrieval 就是 cross-attention 的影子
为了证明这不是停留在模块对照表，作者给了一个 Transformer-style case study。它对应的是一个 cross-attention Transformer：两份不同特征先交互，再经 MLP 产出结果，并保留 residual connection。
在 Agent 的版本中，流程是这样的：
- 输入原始问题 $q$，由一个 LLM 在 meta prompt 引导下生成多个 query；
- 用这些 query 对语料库分别做 retrieval，拿到多路相关 context；
- 把原始 query附回生成 query，相当于保留 residual，避免系统在 query rewriting 时把题目改丢；
- 最后让输出 LLM 同时读取原问题和检索结果，生成 response。
如果把它写成抽象计算图，大概是：
\[\tilde{Q}=G_{P_1}(q), \qquad C_r=\operatorname{Retrieve}(\tilde{Q}\oplus q, C), \qquad r=G_{P_2}(q,C_r)\]其中 $\tilde{Q}$ 是多路改写 query，$C$ 是语料库，$\oplus q$ 表示原题被保留进检索侧输入。这里没有矩阵乘法，也没有 softmax attention；但“多路 query 去选择外部信息，再把信息送进输出模块”的信息流，确实是 cross-attention 的 Agent 版。
图 3：论文把多 query retrieval 对应到 cross-attention，将输出 LLM 对应为 MLP；把原始 query 附回生成 query 的步骤对应 residual connection。来源：论文 Figure 3；原始资源：arXiv v1 source。
然后，作者又做出 RNN-Transformer、Tree-Transformer、GNN-Transformer 等变体：前者让历史 response 进入 prompt，后两者让 ToT / GoT 帮忙生成更丰富的检索 query。这个过程其实很像搭积木：不是先预设“Transformer Agent 一定最强”，而是给 architecture 加不同 inductive bias，再让任务回答哪种组合有效。
5. 真正的 MAGA 时刻：把 Agent 配置交给 NAS 搜
到这里，论文才进入最像 AutoML 的部分。
对于 Related-multi 任务，作者把 Transformer-style Agent 的一组超参数交给 Optuna 搜索：
| 超参数 | 对应的 Agent 决策 | 候选范围 |
|---|---|---|
| $m_1$ | query-generation LLM 的最大输出 token | 64 / 128 / 192 / 256 / 320 |
| $m_2$ | 最终 answer LLM 的最大输出 token | 64 / 128 / 192 / 256 / 320 |
| $m_3$ | self-reflection 的最大输出 token | 64 / 128 / 192 / 256 / 320 |
| $h$ | multi-query retrieval 的 head 数 | 1–5 |
| $n$ | 每个 head 的 retrieval 数 | 1–5 |
令一个配置为 $\pi=(m_1,m_2,m_3,h,n)$，搜索目标就是最大化验证任务的 F1：
\[\pi^*=\underset{\pi\in\Pi}{\arg\max}\;\operatorname{F1}_{\mathrm{train}}(\pi)\]实验使用 30% 的 Related-multi 数据做 search、70% 做 test，共跑 120 次 trial。最终找到的配置是 $m_1=192$、$m_2=192$、$m_3=320$、$h=2$、$n=4$，测试 F1 为 0.712；作者报告它比随机设计的 architecture 高 11%。
自动架构搜索过程：论文展示 Transformer 的自动优化过程；横轴是 trial 数，每个 trial 对应一组参数与 F1，纵轴是 F1。来源：论文自动优化图；原始资源：arXiv v1 source。
这个数字不该被解读成“Optuna 一跑，Agent 就自动进化成 AGI”。它真正说明的是一件更朴素、也更重要的事：Agent 的 token budget、检索 head 数、每 head 的文档数，并不应该永远靠人拍脑袋。 在固定任务和固定预算下，这些本来就是标准的 configuration optimization 问题。
这也是 AutoML 总被低估的地方。NAS 从来不只是“搜一个新奇网络图”；它首先是在提醒我们：当决策变量多到人的直觉难以可靠覆盖，就应该把经验固化成搜索空间，把好坏固化成 objective，再把试错交给优化算法。
6. 实验没有说“越复杂越强”，反而把选择性讲得很诚实
论文测了两类任务：不需要外部知识的 TSP 与 GSM8K，以及需要检索外部知识的 StrategyQA 和 Related-multi。前者比较 MLP、RNN-MLP、Tree-MLP、GNN-MLP；后者在这些结构前再加 attention / retrieval。
先看不带 retrieval 的结果：
| 架构 | TSP 最优路线长度 ↓ | GSM8K 准确率 ↑ |
|---|---|---|
| MLP | 79.2 | 53.3% |
| RNN-MLP | 76.6 | 60.0% |
| Tree-MLP | 73.2 | 66.7% |
| GNN-MLP | 73.9 | 64.3% |
对数学推理和组合优化，Tree / GNN 的多分支思考确实比单次 LLM response 更占便宜。尤其 Tree-MLP 把 GSM8K 从 53.3% 拉到 66.7%，不是一个可以忽略的小数点。
但加上外部知识以后，赢家换了：
| 架构 | StrategyQA F1 ↑ | Related-multi F1 ↑ |
|---|---|---|
| Att-MLP | 0.42 | 0.22 |
| RNN-Att-MLP | 0.66 | 0.24 |
| Tree-Att-MLP | 0.50 | 0.25 |
| GNN-Att-MLP | 0.54 | 0.21 |
StrategyQA 上 RNN-Att-MLP 明显最好；Related-multi 则是 Tree-Att-MLP 略胜。论文的解释也合理：前者更受益于对历史信息的连续保留，后者是“根据标题和摘要写 related work”，更需要发散地构造检索 query。
这恰好是整篇论文最有价值的结论之一：没有一个“最强 Agent architecture”，只有与任务结构相匹配的 architecture。 如果每个任务最后都赢的是最复杂的 GNN-Tree-Retrieval-Memory-All-in-One，那这套方法反而没有说服力；现在这种结果更像真实的 architecture design。
7. 这篇论文的边界，也正是下一轮 AutoML 的题目
我挺喜欢这篇工作把问题改写得很清楚，但也不觉得它已经把 Agent NAS 做完了。至少还有四个缺口：
第一，搜索空间还比较浅。 当前主要在搜输出 token、retrieval head 和 retrieve number。模块拓扑本身、工具调用策略、模型路由、memory 压缩策略、并行与串行编排，都还没有真正放进可搜索的 space。
第二，评估器未必可靠。 可精确计算的 TSP 很适合 feedback loop；但当 evaluator 也是 LLM，奖励被 hack、偏好被放大、反思越写越自信却不更正确，这些问题都会出现。论文没有系统评估这一层的稳定性。
第三，实验规模和任务分布有限。 TSP、GSM8K、StrategyQA 都是很干净的 benchmark；Related-multi 目前声明会在 review 后发布。真实 Agent 常见的 tool failure、长链依赖、动态环境和成本约束，并没有被充分覆盖。
第四，可复现性还不够。 论文页面未提供公开代码链接，按论文标题在 GitHub 检索也没有找到匹配仓库。对于一个高度依赖 meta prompt、评估 prompt 和 search budget 的工作，这些东西不是实现细节，而是结果的一部分。
所以别把它理解成“明天所有 Agent 都该交给 NAS”。更准确的理解是：它给了我们一张迁移路线图——先把 Agent 的隐性经验拆成模块和变量，再明确反馈信号与成本约束，最后才谈自动搜索。MAGA 的重点不是让旧术语重新流行，而是让自动化设计重新接管那些本不该永久依赖手工经验的决策。
总结
这篇论文最有意思的地方，不是把 LLM、RNN、attention、GNN 强行画成一张对应表，而是顺着这张表，把 Agent system design 重新变成了一个可以讨论的优化问题：
\[\text{Agent system} = \text{modules} + \text{architecture} + \text{prompt parameters} + \text{evaluation objective}\]模块怎么选、结构怎么连、prompt 怎么根据反馈演化、token 和 retrieval 预算怎么分配——这些都可以被定义、被评测、被搜索。
从这个角度看，Make AutoML Great Again 并不是怀旧。Agent 越复杂，靠“我觉得这里再接个 reflection 应该会更强”就越不够用。把设计判断显式化，把搜索过程自动化，才是让 Agent 从 demo 拼装走向系统工程的一条正路。
如果你想把这篇论文背后的 AutoML 方法论系统补起来，可以看看我们团队编写、由机械工业出版社出版的《动手学 AutoML：从 NAS 到大语言模型优化实战》。全书共 11 章，从搜索空间、评估策略和 NAS 讲到模型压缩、LLM-Agent 与 AutoML 的结合，并配有随机搜索、可微分搜索、进化压缩、LLM 剪枝等实战代码；配套资源见 AutoMLDemos。
