跳转至

第 10 章：Agent 关键论文与实验清单

本章把 agent 相关的经典论文与代表性实验放在同一张清单里，重点抽取“核心结论”和“优化点”。它不追求穷尽，而是覆盖被频繁引用、对工程设计有直接指导意义的工作，用于和前 9 章的官方实践对照。每篇论文都有独立解读页，点击条目标题即可展开全文。

基础架构与工具调用

  • MRKL Systems [66]
  • 年份：2022 [66]
  • 递进关系：前序：无（模块化工具路线早期代表）；后续：Toolformer、Gorilla、ToolLLM [66]
  • 核心结论：模块化架构让 LLM 负责路由与解释，外部专家模块提供确定性能力，从而扩展可解决问题的范围。 [66]
  • 解读：论文的主旨是把 LLM 从“全能推理器”转为“意图路由器”，用专家模块承担确定性任务。这样系统能力随模块扩展而扩展，也便于在生产中替换或升级单个组件而不影响整体行为。 [66]
  • 优化点：将能力拆成可插拔模块；标准化“选择工具/执行工具”的接口；把确定性推理交给外部模块。 [66]
  • PAL [67]
  • 年份：2022 [67]
  • 递进关系：前序：无（程序辅助推理代表）；后续：ReAct、ReWOO [67]
  • 核心结论：先生成程序再执行能提升复杂推理的正确性，模型把计算交给执行器处理。 [67]
  • 解读：主旨是把自然语言推理转成可执行程序，让执行器负责计算与验证。这样既降低模型的算术与逻辑负担，也让推理过程更可复现、更易定位错误。 [67]
  • 优化点：用代码作为中间表示；执行器承担数值与符号计算；提示中明确“语言到程序”的映射。 [67]
  • ReAct [68]
  • 年份：2022 [68]
  • 递进关系：前序：MRKL Systems、PAL；后续：ReWOO、Reflexion [68]
  • 核心结论：思考与行动交替进行，观察结果回流上下文，显著降低幻觉并提升多步任务表现。 [68]
  • 解读：论文强调思考与行动交替，让推理始终被环境反馈校验。核心价值不是“更会想”，而是把每一步想法都落到可观察的结果上，减少臆测和漂移。 [68]
  • 优化点：显式记录思考与行动；把工具观察作为下一步输入；用少量示例建立固定格式。 [68]
  • Toolformer [69]
  • 年份：2023 [69]
  • 递进关系：前序：MRKL Systems；后续：Gorilla、ToolLLM [69]
  • 核心结论：模型可自举生成工具调用数据并内化使用方式，减少人工标注成本。 [69]
  • 解读：主旨是用自举数据让模型学会调用工具，降低对人工标注的依赖。论文强调关键在于筛选“真的有用”的调用样本，否则噪声会抵消收益。 [69]
  • 优化点：用启发式筛选有效调用；把工具输出并入训练样本；将工具调用当作一等 token。 [69]
  • WebGPT [70]
  • 年份：2021 [70]
  • 递进关系：前序：无（网页检索代理早期代表）；后续：WebShop、WebArena [70]
  • 核心结论：结合浏览与人类反馈训练可提高回答的事实性，并促使模型给出可验证引用。 [70]
  • 解读：论文主张把“浏览 + 引用”纳入训练目标，让回答必须与可验证证据绑定。这样模型不仅更可能事实正确，也更容易被外部审计与纠错。 [70]
  • 优化点：把网页浏览作为工具；奖励机制强调引用与可验证性；将引用片段纳入最终回答。 [70]
  • SayCan [71]
  • 年份：2022 [71]
  • 递进关系：前序：ALFWorld；后续：Voyager [71]
  • 核心结论：LLM 负责高层规划，机器人可行性模型负责过滤动作，使计划更可执行。 [71]
  • 解读：论文的主旨是把“语言规划”与“物理可行性”分开处理，避免语言模型直接主导动作。这样高层计划仍由 LLM 产生，但最终动作由可行性模型筛选，执行更可靠。 [71]
  • 优化点：先生成候选动作，再用可行性评分排序；在规划阶段显式约束环境条件。 [71]
  • ReWOO [73]
  • 年份：2023 [73]
  • 递进关系：前序：ReAct；后续：无（与 ReAct 同线效率优化） [73]
  • 核心结论：将规划与观察解耦，先生成计划再执行，可减少工具调用并提升效率。 [73]
  • 解读：主旨是让代理先完成“静态规划”，再进入执行阶段填充观察与结果。这样可以减少反复的计划-执行回合，尤其适合工具调用成本高或延迟大的场景。 [73]
  • 优化点：规划阶段只输出依赖图；执行阶段按步骤填充观察；减少反复“计划-执行”切换。 [73]

记忆与自我改进

  • Reflexion [72]
  • 年份：2023 [72]
  • 递进关系：前序：ReAct；后续：MemGPT [72]
  • 核心结论：自我反思与记忆能让代理从失败中改进，无需显式强化学习。 [72]
  • 解读：论文主张把失败经验转成可复用的反思文本，作为下一次行动的约束。这样改进是可累积的，而不是靠盲目重试碰运气。 [72]
  • 优化点：将反思写入长期记忆；下一次尝试将反思作为约束；用失败轨迹触发反思。 [72]
  • MemGPT [74]
  • 年份：2023 [74]
  • 递进关系：前序：Reflexion；后续：Generative Agents [74]
  • 核心结论：引入记忆层级与显式读写机制，让 LLM 在长任务中维持关键信息。 [74]
  • 解读：论文的核心在于“把记忆管理变成显式机制”，而不是依赖更长上下文。通过区分短期与长期记忆并引入读写操作，代理才可能在长任务中稳定保持关键状态。 [74]
  • 优化点：区分工作记忆与长期记忆；用分页/摘要管理上下文；显式调用读写操作。 [74]
  • Generative Agents [75]
  • 年份：2023 [75]
  • 递进关系：前序：MemGPT；后续：无（社会化代理方向代表） [75]
  • 核心结论：记忆、反思、计划三件套能生成可持续的社会化行为与长期互动。 [75]
  • 解读：论文主旨是用“记忆-反思-计划”架构模拟长期行为，让代理表现出连续一致的社会互动。它强调行为并非即时生成，而是由长期记忆检索与计划安排驱动。 [75]
  • 优化点：记忆检索考虑重要性/相关性/新近度；反思生成高层摘要；计划驱动日程安排。 [75]

规划与推理搜索

  • Tree of Thoughts [90]
  • 年份：2023 [90]
  • 递进关系：前序：ReAct；后续：Graph of Thoughts [90]
  • 核心结论：把推理拆成多路径搜索，让模型在“思维树”中探索与回溯，可显著提升复杂任务的解题率。 [90]
  • 解读：论文提出将“思考”视为可搜索的空间，而不是单一链式输出。通过多分支探索与评估，代理能在不确定任务中更稳健地找到高质量路径。 [90]
  • 优化点：设计可比较的中间状态评分；允许回溯/剪枝；用搜索预算控制成本。 [90]
  • Graph of Thoughts [91]
  • 年份：2023 [91]
  • 递进关系：前序：Tree of Thoughts；后续：无（图式推理方向代表） [91]
  • 核心结论：将推理结构从树扩展为图，支持复用与共享子结点，提升复杂任务的推理效率。 [91]
  • 解读：论文强调复杂问题往往共享子问题，图结构能减少重复推理并实现更强的组合性。对于多步骤代理任务，图式结构有助于构建可复用的中间结论库。 [91]
  • 优化点：显式建模子问题依赖；合并重复推理节点；将图搜索与评估结合。 [91]

工具生态与 API 规模化

  • HuggingGPT [77]
  • 年份：2023 [77]
  • 递进关系：前序：MRKL Systems；后续：ToolLLM [77]
  • 核心结论：LLM 作为调度器协调多模态专家模型，可完成跨模态复杂任务。 [77]
  • 解读：论文强调 LLM 的角色是调度与编排，而不是替代所有模型。通过把任务分解给擅长的专家模型，系统整体的质量与覆盖面显著提升。 [77]
  • 优化点：规划-执行-验证链路；维护模型能力清单；把中间结果作为反馈信号。 [77]
  • Gorilla [78]
  • 年份：2023 [78]
  • 递进关系：前序：Toolformer；后续：ToolLLM [78]
  • 核心结论：检索 API 文档并监督微调，可提升对大量真实 API 的正确调用率。 [78]
  • 解读：论文的主旨是把 API 文档检索融入调用流程，让模型以真实文档为依据生成调用。结果表明正确性更多取决于文档对齐与格式约束，而非模型参数规模本身。 [78]
  • 优化点：检索相关 API 文档；调用格式显式化；约束参数与返回值结构。 [78]
  • ToolLLM [83]
  • 年份：2023 [83]
  • 递进关系：前序：Toolformer、Gorilla；后续：无（大规模工具数据代表） [83]
  • 核心结论：大规模 API 调用数据让模型学习通用工具使用，并提升跨 API 泛化。 [83]
  • 解读：论文强调大规模、多样化的工具调用数据是模型获得“通用工具能力”的关键。覆盖面越广，跨 API 的泛化越强，这对工程体系意味着数据建设是核心资产。 [83]
  • 优化点：覆盖多类型 API；将工具调用作为一等输出；引入执行或模拟反馈。 [83]
  • StableToolBench [92]
  • 年份：2024 [92]
  • 递进关系：前序：Gorilla、Toolformer；后续：无（工具评测基准方向代表） [92]
  • 核心结论：稳定化的工具评测基准能更准确衡量 LLM 的工具学习能力，避免接口漂移导致的对比失真。 [92]
  • 解读：论文强调原始工具评测面临 API 变化与执行不稳定的问题，StableToolBench 通过固定 API 快照与评测流程，确保模型对比结果可复现。它更关注工具调用的正确性与执行反馈的一致性。 [92]
  • 优化点：冻结工具目录与参数协议；保留执行日志；区分调用成功率与执行成功率。 [92]

多代理协作与组织

  • AutoGen [79]
  • 年份：2023 [79]
  • 递进关系：前序：CAMEL；后续：MetaGPT、ChatDev [79]
  • 核心结论：多代理对话框架通过角色分工提升复杂任务完成度。 [79]
  • 解读：论文主张通过多代理角色对话来分担复杂任务，强调交互协议的重要性。没有明确的角色边界与终止条件，多代理只会放大无效讨论。 [79]
  • 优化点：定义清晰角色与对话协议；允许工具代理参与；设定可终止的循环条件。 [79]
  • CAMEL [80]
  • 年份：2023 [80]
  • 递进关系：前序：无（多代理对话生成代表）；后续：AutoGen、MetaGPT [80]
  • 核心结论：角色扮演式对话促成更复杂的协作过程与高质量任务数据。 [80]
  • 解读：论文的主旨是用角色扮演生成高质量对话与协作轨迹，作为训练或分析数据。角色与目标定义越清晰，生成的对话就越具结构性与可复用性。 [80]
  • 优化点：固定角色指令；明确任务目标；控制对话轮次与角色交互模式。 [80]
  • MetaGPT [81]
  • 年份：2023 [81]
  • 递进关系：前序：AutoGen、CAMEL；后续：ChatDev [81]
  • 核心结论：将软件研发流程拆成多角色协作与结构化交付，提升整体一致性。 [81]
  • 解读：论文强调把研发流程“制度化”为多个角色的协作管线，并产出明确的结构化交付物。这样可以显著减少多代理之间的理解偏差，增强一致性与可追溯性。 [81]
  • 优化点：标准化 SOP 与交付物；输出结构化文档/代码；共享记忆与评审机制。 [81]
  • ChatDev [82]
  • 年份：2023 [82]
  • 递进关系：前序：AutoGen、MetaGPT；后续：无（对话驱动开发代表） [82]
  • 核心结论：以角色化对话驱动软件开发流程，可形成需求到实现的闭环。 [82]
  • 解读：论文提出用角色对话来驱动软件开发，把需求、设计、实现组织成可对话的流程。它同时表明如果缺乏阶段化约束，对话容易发散并导致交付失真。 [82]
  • 优化点：阶段化对话流程；角色职责分离；让设计产物成为后续输入。 [82]

具身与开放式探索

  • Voyager [76]
  • 年份：2023 [76]
  • 递进关系：前序：SayCan、ALFWorld；后续：无（开放式学习代表） [76]
  • 核心结论：通过自动课程与技能库，LLM 代理能在开放环境中持续学习。 [76]
  • 解读：论文主旨是通过自动课程生成与技能库沉淀实现持续学习，而不是随机探索。技能被编码成可复用的程序，让代理在新任务中快速复用已有能力。 [76]
  • 优化点：自动生成任务目标；技能以代码形式积累复用；用反馈驱动迭代。 [76]

评测与实验环境

  • AgentBench [84]
  • 年份：2023 [84]
  • 递进关系：前序：WebShop、WebArena；后续：无（跨任务评测代表） [84]
  • 核心结论：跨任务评测基准揭示了 LLM 在交互式代理任务中的系统性差距。 [84]
  • 解读：论文的主旨是用跨任务基准揭示代理能力的系统性短板，而不是只看单任务成绩。它强调轨迹数据的重要性，因为问题往往出在中间步骤而非最终答案。 [84]
  • 优化点：统一评测协议；覆盖多类交互任务；记录中间轨迹用于诊断。 [84]
  • WebArena [85]
  • 年份：2023 [85]
  • 递进关系：前序：WebShop、WebGPT；后续：AgentBench [85]
  • 核心结论：真实网页环境能更准确评估自主代理的 UI 操作能力。 [85]
  • 解读：论文强调真实网页的动态性与噪声会显著影响代理成功率，这些因素在简化环境中常被忽略。它的主旨是把评测推向真实环境，让模型暴露生产级问题。 [85]
  • 优化点：保留网页状态与动态交互；以任务完成率为核心指标；稳定动作-观察循环。 [85]
  • WebShop [86]
  • 年份：2022 [86]
  • 递进关系：前序：WebGPT；后续：WebArena、AgentBench [86]
  • 核心结论：电商购物环境检验代理在多步网页任务中的可靠性与鲁棒性。 [86]
  • 解读：论文用电商购物流程作为测试场景，突出多步筛选与比较的长程依赖。它表明越接近真实流程，越能暴露搜索、过滤与决策中的薄弱环节。 [86]
  • 优化点：目标驱动的搜索与筛选；处理长程依赖；奖励与目标商品匹配。 [86]
  • Mind2Web [93]
  • 年份：2023 [93]
  • 递进关系：前序：WebShop；后续：WebArena、WebVoyager [93]
  • 核心结论：大规模真实网页任务数据为通用网页代理提供可迁移的操作轨迹与指令结构。 [93]
  • 解读：论文强调真实网页任务覆盖了大量 UI 变体与噪声，只有在足够多样的轨迹上训练，代理才可能具备可迁移的操作能力。该数据集也为评测提供了更真实的分布。 [93]
  • 优化点：收集跨站点任务；保留 DOM 与交互轨迹；在训练中对齐指令与操作序列。 [93]
  • WebVoyager [94]
  • 年份：2024 [94]
  • 递进关系：前序：WebArena、Mind2Web；后续：无（端到端网页代理方向代表） [94]
  • 核心结论：端到端网页代理可在真实站点上完成多步任务，但对观察建模与动作粒度极其敏感。 [94]
  • 解读：论文指出网页代理的关键不在模型参数量，而在于如何把页面状态编码成可推理的观察，并保证动作足够可执行。真实站点暴露了大量 UI 噪声与异常状态。 [94]
  • 优化点：高质量网页观察表示；动作粒度与可执行性校验；强化恢复与重试策略。 [94]
  • OSWorld [95]
  • 年份：2024 [95]
  • 递进关系：前序：无（操作系统级代理评测代表）；后续：无（跨应用任务基准方向代表） [95]
  • 核心结论：操作系统级评测揭示了跨应用任务对记忆、规划与 UI 操作的综合要求。 [95]
  • 解读：论文强调 OS 级任务不像单一网页或单一 App，代理需要在多应用之间切换并保持长程状态。该基准揭示了多应用上下文切换和权限边界的挑战。 [95]
  • 优化点：明确跨应用状态管理；记录 UI 操作轨迹；对权限/系统提示做可见化处理。 [95]
  • SWE-bench Goes Live! [96]
  • 年份：2025 [96]
  • 递进关系：前序：SWE-bench；后续：无（评测治理与线上化方向代表） [96]
  • 核心结论：基准线上化与动态维护让软件工程代理评测更贴近真实开发节奏。 [96]
  • 解读：论文强调静态评测难以覆盖真实世界的快速变化，通过上线与持续维护，可将修复能力与环境漂移纳入评价体系。对工程团队而言，这意味着评测必须具备持续回归与版本治理能力。 [96]
  • 优化点：将评测任务纳入持续更新；建立版本化回归集；把修复结果与测试门禁绑定。 [96]
  • OSWorld-Human [97]
  • 年份：2025 [97]
  • 递进关系：前序：OSWorld；后续：无（人类效率对照方向代表） [97]
  • 核心结论：引入人类效率上限后，计算机使用代理的性能差距更可量化。 [97]
  • 解读：论文把人类完成任务的效率作为参照，揭示代理不仅要“能做”，还要“做得够快”。这对多应用任务的时间预算、动作冗余控制提出了新的工程要求。 [97]
  • 优化点：优化动作路径长度；跟踪任务时间成本；针对高频操作做快捷策略。 [97]
  • Mobile-Agent-v3 [98]
  • 年份：2025 [98]
  • 递进关系：前序：无（移动端 GUI 代理方向代表）；后续：无（移动端自动化方向代表） [98]
  • 核心结论：移动端 GUI 自动化代理强调动作可靠性与跨应用一致性。 [98]
  • 解读：论文强调移动端 UI 的动态性与权限限制会放大失败成本，因此代理需要更稳健的交互策略与状态对齐机制。该方向补齐了桌面/网页代理之外的移动端场景。 [98]
  • 优化点：建立稳定的 UI 元素定位策略；对权限弹窗做专门处理；控制动作粒度避免误触。 [98]
  • MobileUse [100]
  • 年份：2025 [100]
  • 递进关系：前序：Mobile-Agent-v3；后续：无（移动端反思策略方向代表） [100]
  • 核心结论：分层反思机制能提升移动端 GUI 代理在复杂任务中的稳定性。 [100]
  • 解读：论文强调移动端任务失败往往来自步骤漂移与误触，分层反思将高层计划与低层执行分别校验，提高了纠错能力。对工程团队而言，反思机制需要与动作日志和 UI 状态对齐。 [100]
  • 优化点：引入分层反思节点；记录动作与 UI 观察；为高频错误配置回退策略。 [100]
  • MagicGUI [101]
  • 年份：2025 [101]
  • 递进关系：前序：Mobile-Agent-v3；后续：无（移动端基础模型方向代表） [101]
  • 核心结论：规模化数据流水线与强化微调可显著提升移动端 GUI 代理的泛化能力。 [101]
  • 解读：论文强调移动端代理的核心瓶颈是数据覆盖与动作对齐，MagicGUI 通过可扩展的数据管线与强化微调提升稳定性。它提醒工程团队：数据工程与训练策略同等重要。 [101]
  • 优化点：建立可扩展的数据采集管线；对动作序列做一致性校验；用强化微调对齐执行结果。 [101]
  • UI-Evol [102]
  • 年份：2025 [102]
  • 递进关系：前序：OSWorld；后续：无（计算机使用知识演化方向代表） [102]
  • 核心结论：自动化知识演化能帮助计算机使用代理持续适配新 UI 与新工具。 [102]
  • 解读：论文指出 UI 环境变化快，代理需要不断更新知识库与操作策略。UI-Evol 通过自动化知识演化机制保持代理在动态界面上的适应能力。 [102]
  • 优化点：构建可持续更新的 UI 知识库；追踪 UI 变化并触发更新；在回归集中纳入新界面样本。 [102]
  • MCP-Bench [99]
  • 年份：2025 [99]
  • 递进关系：前序：ToolLLM、StableToolBench；后续：无（MCP 工具评测方向代表） [99]
  • 核心结论：基于 MCP 的复杂工具任务评测揭示了代理在真实工具生态中的规划与调用短板。 [99]
  • 解读：论文用 MCP server 组织真实工具任务，强调工具协议、权限与执行反馈对代理表现的影响。它把“工具调用是否能闭环”转成可量化指标，更贴近工程实践。 [99]
  • 优化点：构建可复现的 MCP 工具集；记录调用链与执行反馈；对权限失败做专门统计。 [99]
  • ALFWorld [87]
  • 年份：2020 [87]
  • 递进关系：前序：无（文本化具身环境早期代表）；后续：SayCan、Voyager [87]
  • 核心结论：将具身任务转成文本交互环境，降低训练成本并保持行为约束。 [87]
  • 解读：论文的主旨是把具身任务“文本化”，用低成本环境复现复杂行为。这样既保留了任务约束，又让算法验证更可控、更易扩展。 [87]
  • 优化点：文本动作映射实体动作；多步指令执行；状态描述驱动规划。 [87]
  • SWE-bench [88]
  • 年份：2023 [88]
  • 递进关系：前序：无（真实代码修复评测代表）；后续：SWE-agent [88]
  • 核心结论：真实 GitHub issue 基准让自动修复代码的难度可量化。 [88]
  • 解读：论文的主旨是用真实 GitHub issue 评测自动修复代码的能力，难度来自真实仓库的复杂上下文。结果显示工具使用与上下文管理能力往往决定成败，而不仅是模型的代码生成能力。 [88]
  • 优化点：以测试结果验证修复；管理仓库上下文；区分不同难度的任务类型。 [88]
  • SWE-agent [89]
  • 年份：2024 [89]
  • 递进关系：前序：SWE-bench；后续：无（工程化接口方向代表） [89]
  • 核心结论：Agent-Computer Interface 证明工具接口设计对自动化软件工程至关重要。 [89]
  • 解读：论文强调“工具接口设计”是自动化软件工程成功的关键变量。通过稳定、简洁的 CLI 接口，模型的能力被有效放大，复杂度被控制在可执行范围内。 [89]
  • 优化点：精简且稳定的 CLI 工具集合；将文件与命令作为基本操作；闭环错误处理。 [89]