AgentSquare: Automatic LLM Agent Search in Modular Design Space

读前先抓住结论

AgentSquare 要解决的不是“把某个 prompt 写得更好”这么窄的问题，而是更接近 Agent 工程的核心问题：当一个 LLM Agent 由规划、推理、工具调用、记忆读写和环境反馈组成时，我们怎样系统地找到更好的整体架构？论文把这个问题命名为 MoLAS，也就是模块化 LLM Agent 搜索。它的判断很直接：已有 Agent 论文里有很多成功组件，但这些组件常常散落在不同代码库和不同任务里，如果没有统一接口，就很难被复用、比较和重组。

论文的关键贡献是构造一个 模块化设计空间。作者把既有 Agent 设计抽象成四类模块：Planning、Reasoning、Tool Use 和 Memory。每个模块都有标准输入输出接口，因此一个 Agent 可以表示为四类模块的组合。这个设计让“复用已有 Agent 经验”不再只是读论文后的人工灵感，而变成可以被搜索算法操作的结构对象。

在这个空间上，作者提出 AgentSquare。它有三个核心机制：模块重组、模块演化和性能预测器。模块重组负责从已有模块池中挑选更有希望的组合；模块演化负责用 LLM 生成新的模块变体；性能预测器则在重组阶段先估计候选 Agent 的表现，避免每个候选都进入昂贵的真实环境评估。

实验结果给出的信号很强。论文在 WebShop、ALFWorld、ScienceWorld、M3ToolEval、TravelPlanner 和 PDDL 六个任务上比较人工 Agent、模块搜索、提示搜索和 Agent 搜索基线。AgentSquare 在 GPT-4o 设置下分别达到 0.607、0.695、0.781、0.524、0.583 和 0.669，相比已知最佳人工设计平均提升 17.2%。这说明模块化搜索不是只在某一个任务上偶然有效，而是在网页、具身、工具和游戏场景中都有稳定收益。

问题背景：Agent 设计为什么需要模块化搜索

很多 Agent 系统的效果来自流程结构，而不是单次模型调用。一个网页购物 Agent 可能需要先理解用户需求，再搜索商品，再比较属性，最后执行购买；一个具身环境 Agent 可能需要规划行动、观察环境、更新记忆、修正计划；一个工具使用 Agent 需要在多轮交互里选择 API、读取结果并决定下一步。单个 prompt 很难完整表达这些结构。

过去的做法大多依赖人工设计。研究者会根据经验构造 CoT、Self-Refine、ToT、Voyager、HuggingGPT、DEPS 或 OPENAGI 这类 Agent。它们在特定任务上有效，但迁移成本高：一个为 Minecraft 或 ALFWorld 设计的记忆模块，未必能直接放进 WebShop；一个工具选择模块也未必和某个推理模块接口相容。于是，研究社区不断产出新 Agent，却很难把这些成功组件积累成可组合的公共资产。

已有自动化方法解决了一部分问题。OPRO 和 PromptBreeder 主要优化提示词；ADAS 进一步在代码空间中搜索完整 Agent 系统；多 Agent 配置优化则关注角色和交互模式。AgentSquare 的位置介于这些方法之间：它不像纯 prompt 优化那样只改文字，也不像无约束代码搜索那样面对巨大空间，而是把搜索限制在 有标准接口的模块空间 中。

这种限制反而是优点。模块空间让搜索有明确维度：规划模块怎么选，推理模块怎么选，工具模块是否需要，记忆模块是否引入。它让已有人工设计变成种子模块，也让新模块可以作为插件继续加入。对工程实践来说，这相当于把“我看了很多论文后手工拼 Agent”的过程，改造成“把论文中的模块标准化，再让搜索过程系统比较组合”。

方法总览：四类模块如何变成设计空间

AgentSquare 的设计空间由四类模块构成。Planning 模块接收任务描述和反馈，输出子任务序列；Reasoning 模块接收子任务和反馈，输出推理结果或行动候选；Tool Use 模块根据推理过程中出现的问题，从工具池中选择可用工具；Memory 模块负责读写观察、行动和经验，帮助 Agent 在长程任务中保留上下文。

这四类模块不是任意画出来的分类。作者从近三年 NeurIPS、ICML 和 ICLR 中的 LLM Agent 论文出发，排除多 Agent 和需要额外训练的系统，整理出 16 个常见 LLM Agent，并抽象出 1050 种可能组合。论文并不声称这个空间覆盖所有未来 Agent，而是把它作为一个可扩展平台：新论文提出的模块可以接入同一接口，成为未来搜索的候选。

统一接口的意义在于，它让不同来源的模块可以被机器而非人工重组。如果一个规划模块输出子任务列表，推理模块就必须能读懂这个列表；如果记忆模块返回相关经验，推理模块就必须知道如何利用它；如果工具模块输出工具调用，环境执行器就必须能接住结果。没有这层接口，搜索算法生成的组合很可能只是在语义上“看起来合理”，实际运行时却无法连接。

可以用下面的简化接口来理解论文的设计直觉：

1agent = Agent(2    planning=P,3    reasoning=R,4    tool_use=T,5    memory=M,6)7subtasks = P(task, feedback)8for subtask in subtasks:9    context = M.retrieve(observation)10    tool = T.select(subtask, tool_pool)11    result = R.solve(subtask, context, tool)12    M.write(result)

这段伪代码不是论文实现，而是帮助读者抓住抽象：Agent 不再是一个不可拆的整体，而是四个可以替换的模块和一套试错循环。这样，搜索可以针对不同任务发现不同组合，例如网页任务可能更依赖工具选择和记忆，具身任务可能更依赖规划与反馈修正。

MoLAS 形式化：把 Agent 架构当作组合优化

在 MoLAS 中，一个 Agent 被表示为 $A=(P,R,T,M)$。这里 $P$ 是规划模块，$R$ 是推理模块，$T$ 是工具使用模块，$M$ 是记忆模块。给定任务描述 $d$ 和四类模块集合，目标是在四个维度的笛卡尔积中寻找性能最高的组合。

这个公式看起来简单，但改变了问题的粒度。传统 Agent 设计常常问“我应该使用哪种提示策略”，MoLAS 问的是“我应该选择哪组模块，以及是否需要创造新模块”。这意味着评估对象不是一段提示词，而是可以完整运行的 Agent 架构。

这种形式化也解释了为什么 AgentSquare 需要搜索机制。四个模块维度看似有限，但每个维度都可能包含多个来自不同论文的模块，并且新模块还会不断加入。如果只靠人工枚举，组合数量很快变大；如果只做随机组合，又会浪费大量真实评估成本。AgentSquare 的演化、重组和预测器正是为这个组合优化问题服务。

AgentSquare 搜索循环：演化、重组与选择

AgentSquare 的整体搜索可以分成初始化、模块演化、真实评估、模块重组、预测评估和选择。初始化阶段先建立经验池，记录已有模块组合及其真实表现；模块演化阶段让 LLM 编写或改造新模块；真实评估阶段运行包含新模块的候选 Agent；模块重组阶段让 LLM 根据历史经验替换已有模块；性能预测器则先给重组候选打分，减少真实评估次数。

算法的关键在于交替使用探索和利用。模块演化偏探索，它允许搜索空间出现从未见过的新模块；模块重组偏利用，它把已经证明有价值的模块重新组合到当前任务中；性能预测器则让利用阶段更便宜。三者一起避免两个极端：只重组已有模块会限制上界，只演化新模块又会成本过高且方向不稳。

1Require: initial agent $A_0$, task description $d$, max episode $K$, population size $N$, module pools $P/R/T/M$, experience pool $E$2Ensure: evolved agent $A^*$3$t \leftarrow 1$4$A^e_0 \leftarrow A_0$5while $t \leq K$:6  $\{A^e_1...A^e_N\} \leftarrow module\_evolution(A^e_0, d, N, module\_pools, E)$7  $A^r_0 \leftarrow best\_by\_real\_eval(\{A^e_0...A^e_N\})$8  $\{A^r_1...A^r_N\} \leftarrow module\_recombination(A^r_0, d, N, module\_pools, E)$9  $A^e_0 \leftarrow best\_by\_predicted\_or\_evaluated\_score(\{A^r_0...A^r_N\})$10  $t \leftarrow t + 1$11return $A^e_0$ as $A^*$

输入中的经验池 $mathbb{E}$ 很重要。它不是普通日志，而是搜索的记忆：哪些模块组合在任务上表现好，哪些组合失败，某个模块在不同任务中是否稳定。模块重组器读取这些经验后，才能提出比随机替换更有方向的组合。例如，当历史显示某类记忆模块在 ALFWorld 上有效，而某类工具模块在 TravelPlanner 上更关键时，提议器可以把任务特征和历史表现一起纳入选择。

模块演化则更接近“让 LLM 写新组件”。论文借鉴 FunSearch 和 ADAS 的思路，把任务描述、已有模块代码和过去性能放进元提示，让 LLM 编写新的模块变体。新模块产生后，不是直接被信任，而是作为候选替换当前 Agent 的某个模块，并在真实任务中测试。这个设计让创新和评估绑定在一起，减少只凭语言描述判断模块好坏的风险。

性能预测器：为什么搜索不能每个候选都真跑

Agent 搜索最现实的限制是成本。很多任务不是一次输入输出，而是多步环境交互：ALFWorld 可能需要连续观察和行动，WebShop 需要浏览、比较和选择，M3ToolEval 需要多轮工具调用。如果每个候选 Agent 都完整跑验证任务，API 成本会很快失控。论文给出的例子是，在 ALFWorld 上评估一个简单 CoT Agent，基于 GPT-4o 的成本可以达到约 60 美元量级。

AgentSquare 的性能预测器 $pi_p$ 是一个上下文内代理模型。它读取候选 Agent、任务描述、模块画像和历史评估样例，输出预测性能 $v'$。这个预测不是最终实验结果，而是用于搜索阶段筛选候选：如果一个组合看起来明显不值得真实运行，就可以跳过；如果候选来自模块演化，因为它包含从未评估过的新模块，论文仍要求真实测试。

性能预测器的价值在消融和成本分析中体现出来。论文报告，在 ALFWorld 上，预测器评估成本约为完整 GPT-4o 评估成本的 0.025%。这并不意味着预测器可以替代最终评测，而是说明它适合作为搜索中的前置过滤器。换句话说，AgentSquare 把真实评估留给更值得验证的候选，从而把预算花在更可能带来提升的方向上。

这里也有边界。预测器依赖历史经验池，如果当前任务很新、模块画像不充分，或者候选结构与历史样例差异过大，预测可能失准。论文因此只在重组阶段使用预测器，而对新演化模块保留真实测试。这是一个保守设计：让预测器节省成本，但不让它独自决定开放式创新模块的价值。

实验结果怎么读

实验覆盖四类场景六个任务。WebShop 使用 task score，ALFWorld 和 M3ToolEval 使用 success rate，ScienceWorld 与 PDDL 使用 progress rate，TravelPlanner 使用 micro pass rate。因为指标含义不同，读表时不能简单横向比较任务之间的数值大小，而应比较同一任务内不同方法的相对表现。

基线也分成四组。人工 Agent 包括 CoT、CoT-SC、Self-Refine、ToT、Step Back、Thought Propagation、HuggingGPT、Voyager、Generative Agents、DEPS、OPENAGI 和 Dilu。模块搜索包括随机组合和贝叶斯组合，提示搜索使用 OPRO，完整 Agent 搜索使用 ADAS。这个设置让论文可以回答三个问题：是否超过人工经验，是否超过简单模块组合，是否超过提示或代码搜索基线。

GPT-4o 主结果中，AgentSquare 在六个任务上都取得最高分：WebShop 0.607、ALFWorld 0.695、ScienceWorld 0.781、M3Tool 0.524、TravelPlanner 0.583、PDDL 0.669。相对于最佳人工设计，论文报告平均提升 17.2%。更细地看，ALFWorld、ScienceWorld 和 M3Tool 的提升尤其明显，说明模块化搜索在需要多步骤、工具或环境反馈的任务中更有价值。

与搜索基线相比，AgentSquare 也更强。相对最佳搜索基线，它在 WebShop、ALFWorld、ScienceWorld、M3Tool、TravelPlanner 和 PDDL 上分别有 8.4%、8.1%、11.0%、12.8%、2.5% 和 1.4% 的提升。这里的结论不是“其他搜索都没用”，而是说明只做随机、贝叶斯或提示层修改不够；AgentSquare 的优势来自能同时利用已有模块组合和新模块发现。

搜索轨迹图帮助理解表格背后的动态。随机和贝叶斯模块搜索缺少明确方向，可能在组合空间中碰运气；OPRO 修改空间较小，容易进入性能瓶颈；ADAS 可以搜索完整代码空间，但空间太大，需要更多迭代才能稳定发现好结构。AgentSquare 的模块空间更小、更有经验约束，因此能较快越过人工设计和其他搜索曲线。

消融、轨迹与新模块洞察

消融实验直接检验三个机制里最核心的两个：模块演化和模块重组。GPT-4o 下，完整 AgentSquare 在六任务上分别是 0.607、0.695、0.781、0.524、0.583、0.669；去掉模块演化后，WebShop、ALFWorld、ScienceWorld、M3Tool、TravelPlanner 和 PDDL 均下降；去掉模块重组后，多个任务下降更明显，TravelPlanner 从 0.583 下降到 0.280。

这个结果说明两件事。第一，模块重组很关键，因为很多收益来自把已有成功模块放到新的任务组合里。第二，模块演化也不可替代，因为仅靠已有模块会限制上界，无法为某个任务创造新的规划、推理或工具策略。两者配合时，AgentSquare 既能复用社区积累，也能继续扩展模块池。

最佳 Agent 表进一步显示 AgentSquare 的可解释性。WebShop 的搜索结果使用 IO 规划、HTSS 推理和 Dilu 记忆；ALFWorld 使用新规划模块 TD、新推理模块 SF-ToT 和 Generative Agents 记忆；M3Tool 使用 CoT-SC 推理和 ToolBF 工具模块；TravelPlanner 使用 DEPS 规划、CoT 推理和 TH 工具模块；PDDL 使用 IR 规划、CASRC 推理和 Generative Agents 记忆。也就是说，搜索结果不是一个黑箱模型权重，而是一组可读模块选择。

论文还展示了多个新模块。比如 ALFWorld 的新模块强调任务分解、反馈修正和更适合环境交互的推理结构；WebShop 的 HTSS 倾向把 Tree-of-Thoughts、Self-Consistency 和 Self-Refine 结合；M3Tool 的 ToolBF 把工具检索和多候选投票结合。这些案例让 AgentSquare 不只是给出更高分，还能告诉研究者“哪些结构组合在某类任务上更有希望”。

这些新模块图和附录代码也提醒我们，AgentSquare 的输出需要人工复验。搜索产生的模块可能在验证集上有效，但仍要检查接口稳定性、错误处理、成本、泛化和安全边界。论文的价值不在于自动生成模块后完全不需要工程师，而在于把可比较的候选和设计洞察系统地交给工程师。

局限与复用启发

AgentSquare 依赖一个前提：任务必须能被自动评估。MoLAS 的目标函数需要 $Eval_d$，实验中的任务都有明确指标。如果某个业务 Agent 没有稳定评测集，或者评价需要复杂人工判断，搜索过程就会失去可靠反馈。工程落地时，第一步往往不是写搜索算法，而是建立小而可信的验证任务、日志和指标。

第二个边界是搜索成本。性能预测器可以降低重组阶段的成本，但模块演化产生的新模块仍要真实评估。对于每次运行都很昂贵、风险很高或耗时很长的环境，需要分层评估：先用廉价模拟或小样本筛选，再进入真实任务；否则搜索预算会快速膨胀。

第三个边界是模块接口。AgentSquare 的优势来自标准 IO，但真实系统中的模块输出往往不干净：规划结果格式可能变化，工具调用可能失败，记忆检索可能返回过长内容，推理模块可能不遵守约束。要复用这篇论文，工程上必须先把模块封装成强类型或至少强约定接口，并记录每次输入、输出、错误和成本。

对读者最有用的启发，是可以把 AgentSquare 拆成几个渐进步骤复用。先把现有 Agent 拆成规划、推理、工具和记忆模块；再建立模块池与统一接口；然后记录每组模块在验证任务上的表现；接着做简单随机或贝叶斯组合；最后再加入 LLM 提议器、模块演化和性能预测器。这样不必一开始就复刻完整论文，也能逐步获得模块化搜索的收益。

如果把这篇论文放到 Agent 架构研究脉络里，它最值得带走的不是某个单独模块，而是一种组织知识的方式：让每篇论文里的成功设计都能变成可复用模块，让每次实验结果都进入经验池，让新模块既能被 LLM 提议，也能被真实任务裁决。这样的机制比单次 prompt 优化更接近可积累的 Agent 工程。

从复现角度看，AgentSquare 最容易被低估的是“模块画像”的维护。搜索器不能只知道一个模块的名字，还需要知道它解决什么问题、输入输出是什么、过去在哪些任务上有效、失败时常见症状是什么。没有这些描述，重组器只能做表面替换；有了这些描述，LLM 才能把任务需求和模块能力对齐。论文中的经验池本质上就是一份不断更新的结构化实验档案。

另一个值得注意的点是任务粒度。MoLAS 的搜索对象是单 Agent 内部架构，不是多 Agent 社会结构，也不是底层模型训练。这个边界让论文的设计更容易落地：团队可以先把已有单 Agent pipeline 拆成模块，再逐步收集性能经验。等单 Agent 模块空间稳定后，再考虑把不同 Agent 角色、协作协议或权限边界纳入更大的搜索空间。

AgentSquare 对研究社区也有一种“标准化积累”的意味。许多 Agent 论文提出新流程后，通常只在自己的任务和代码库中验证；后来者想复用时，需要重新读代码、改接口、猜参数。模块化设计空间把这些流程拆成能被登记、调用和评估的单元。长期看，这比单篇论文的分数更重要，因为它让成功经验能够以模块形式跨任务流动。

当然，模块化也会带来抽象损失。某些 Agent 的能力来自多个组件之间非常细的耦合，例如规划提示、记忆格式和工具返回字段互相配合；强行拆成四类模块后，这些耦合可能被切断。因此复用 AgentSquare 思路时，不应把四类模块当成唯一真理，而应根据系统实际增加适配层、共享状态或更细粒度的子模块。

最后，这篇论文给工程团队的实践建议很清楚：不要一开始就追求“自动设计完整智能体”。更稳妥的路线是先把现有 Agent 运行日志保存下来，再把可替换组件标准化，然后用小规模验证集比较模块组合。只有当评估、日志、接口和成本统计都稳定后，自动搜索才会真正带来收益。否则搜索只是把原本的人工作坊变成更昂贵的试错循环。

如果从系统实现角度继续拆，AgentSquare 至少需要三类基础设施。第一类是模块注册表，负责保存模块名称、类型、描述、输入输出格式和调用方式。第二类是执行器，负责把某个模块组合装配成可运行 Agent，并在任务环境中记录每一步输入、输出、错误和成本。第三类是评估器，负责把任务结果转成统一分数，并把分数写回经验池。论文主要讨论搜索算法，但真正落地时，这三类基础设施决定了搜索是否稳定。

模块注册表尤其关键。一个规划模块可能输出自然语言步骤，也可能输出结构化子任务列表；一个工具模块可能返回工具名称，也可能返回完整调用参数；一个记忆模块可能返回相似历史片段，也可能返回压缩后的反思。为了让这些模块可组合，注册表必须记录格式约束和适配逻辑。否则，搜索器生成的组合会频繁因为格式不匹配而失败，而这些失败并不能说明模块本身无效。

执行器的难点在于可观测性。Agent 搜索不是只看最终分数，还要理解为什么一个组合成功或失败。比如某个组合在 WebShop 上失败，可能是因为规划模块没有拆出商品属性比较步骤，也可能是工具模块选择了错误搜索动作，还可能是记忆模块把过期观察注入推理。没有细粒度日志，经验池只能保存一个低分；有了日志，模块演化器才有机会提出针对性的修复。

评估器则决定搜索方向是否可靠。论文使用六个已有基准，因此每个任务都有明确指标。但在真实业务中，指标经常混合正确性、用户满意度、成本、延迟和安全约束。此时不能简单把所有目标压成一个分数，而应先明确主指标和约束指标。例如客服 Agent 可以以任务完成率为主指标，以错误承诺、敏感信息泄露和平均成本为硬约束。这样的评估设计会直接影响 AgentSquare 搜到什么样的模块。

模块演化的实际风险是生成“看起来聪明但不可维护”的模块。LLM 可能写出很长的提示词、复杂分支或隐含假设，短期在验证集上提升，长期却难以调试。一个稳妥策略是限制新模块的接口和代码风格：要求输出结构化对象，要求错误时返回明确状态，要求引用工具时经过统一路由，要求提示词中显式说明输入字段。这样演化得到的新模块更容易进入长期模块池。

模块重组的风险则是过度依赖历史经验。如果经验池中某个模块在多个任务上表现好，重组器可能倾向反复选择它，导致搜索过早收敛。论文通过与演化机制交替运行来缓解这个问题；工程实现中还可以增加多样性约束，例如限制连续选择同一模块组合，或要求每轮保留若干结构差异较大的候选。这样可以避免搜索只在少数热门模块附近打转。

性能预测器最适合做“粗筛”，不适合做“裁判”。它的输入是模块描述和历史样例，本质上仍是语言模型对结构和表现关系的估计。对于与历史经验相似的候选，它可能很有效；对于包含新代码、新工具或新环境交互模式的候选，它可能低估真正有潜力的设计。因此论文把新演化模块交给真实评估，是合理且必要的安全阀。

从论文实验看，模块重组在消融中贡献更大，尤其在某些任务上移除重组会明显下降。这可以理解为：已有 Agent 研究已经积累了不少强模块，真正缺的是把它们放到合适任务里的机制。模块演化则像补充创新来源，当已有模块无法覆盖任务特性时，它会产生新的规划、推理或工具策略。二者不是替代关系，而是一个负责重用，一个负责扩展。

对比 ADAS 也能看出论文选择模块空间的理由。完整代码空间搜索表达能力更强，但空间过大，候选可运行性和评估成本都会成为问题。模块空间牺牲一部分自由度，换来更高的可解释性、更低的组合成本和更好的经验复用。对于多数工程团队，这种受约束搜索往往比完全自由生成更实用，因为它更容易调试，也更容易把失败归因到具体模块。

这篇论文还隐含一个对 Agent 评测的提醒：只比较最终答案分数是不够的。一个 Agent 架构是否值得复用，还要看成本、轨迹稳定性、错误类型和模块可解释性。论文把成本图、搜索轨迹、新模块示例和消融都放进分析，就是为了避免把结论简化成“分数最高”。高分 Agent 如果成本过高、轨迹不稳定或模块难维护，在实际系统里未必是最佳选择。

如果要把 AgentSquare 用在企业任务上，可以先选择一个低风险、可自动打分的场景。例如内部文档问答、工具调用沙盒、表格处理、工单分类或可回放的网页任务。先把少量人工设计流程拆成模块，再采集几十到几百个验证任务，记录每个模块组合的表现。等经验池有了基础样例，再引入 LLM 重组器和性能预测器，会比从零开始让模型设计 Agent 更稳。

在安全场景中，模块化还有额外好处。可以把权限检查、工具白名单、输出审计和敏感信息处理做成固定模块，不允许搜索器随意替换。搜索只在规划、推理或非敏感工具策略上进行。这样既能获得自动优化收益，又能保持关键安全边界不被候选模块绕过。论文没有重点讨论安全，但它的模块化接口非常适合加入这种边界。

读论文时也要注意，17.2% 平均提升是基于作者选定任务、模块池、模型和搜索预算得到的。这个数字说明方法有效，但不保证换到任何业务任务都有同样幅度。真正可迁移的是方法论：把 Agent 组件标准化，把历史结果结构化，把候选设计交给任务指标裁决，并用低成本预测器减少无效评估。迁移时应重新建立本地基线，而不是直接套用论文数字。

AgentSquare 的可解释性来自“模块级输出”。相比一个端到端模型，模块组合表能告诉我们某任务最终用了什么规划、什么推理、是否需要工具、是否需要记忆。新模块图还能展示设计意图和代码结构。这种可解释性对研究很有用，因为它能反过来生成新的假设：为什么某类任务需要记忆，为什么某类工具任务更适合多候选投票，为什么某些具身任务需要反馈式规划。

不过，可解释不等于完全可证明。搜索发现某个模块组合表现好，只能说明它在当前评测设置下有经验优势，不能直接证明其中每个设计选择都是因果必要的。要进一步确认机制，需要更细的消融，例如固定其他模块只替换记忆，或固定任务只改变工具选择策略。论文的消融已经验证了演化和重组两个大机制，未来还可以对具体模块内部设计做更细粒度分析。

把这篇论文和 AFlow 放在一起看，会发现两者都在推动 Agent 自动化设计，但粒度不同。AFlow 更强调在可执行 workflow 代码空间中搜索流程程序，AgentSquare 更强调在模块化设计空间中复用和重组已有 Agent 组件。前者适合探索工作流结构，后者适合积累和复用研究社区的模块资产。二者并不冲突，甚至可以组合：先用 AgentSquare 选模块，再用 AFlow 式方法优化某个模块内部 workflow。

对学习者来说，读完这篇论文可以形成一个检查清单：我的 Agent 是否有清晰模块边界；每个模块是否有统一输入输出；是否有验证集和指标；是否记录了模块组合的历史表现；是否能从日志中判断失败来自规划、推理、工具还是记忆；是否有低成本方式预估候选组合；是否保留真实评估作为最终裁决。这个清单比单纯记住 AgentSquare 这个名字更有价值。

最终，AgentSquare 的核心不是“让 LLM 自己设计一切”，而是把 Agent 设计变成可记录、可比较、可复用的搜索流程。它把任务、模块池、历史表现和反馈放进同一个闭环，让经验不再停留在论文标题或人工灵感里，而是进入可以继续迭代的模块账本。

如果只带走一个工程动作，就是先建立自己的 Agent 实验账本：记录任务、模块组合、输入输出、分数、成本、错误和人工判断。没有账本，搜索器只能从零猜；有了账本，团队过去的失败和成功都会变成下一轮搜索的燃料。

读搜索结果时也要保持克制。某任务选中记忆模块，不代表所有任务都需要记忆；某个工具策略得分高，也不代表它普遍最优。正确读法是：在给定任务、模型、模块池和预算下，这个组合被证据支持。换任务时，应重新搜索或至少重新验证。

这也是它区别于普通基准刷分的地方：分数只是结果，模块、日志、经验和可复用接口才是长期收益。读者真正应学习的是这种积累机制，而不是把最终表格里的某个模块组合当成通用架构定律。