Back to Index
前沿探索 /

LLM Agents 研究前沿

ReAct、Reflexion、Voyager、CAMEL——Agent 学术研究的关键论文、Benchmark 与未来方向

22 min read Part of AI Research · Ch. 3

LLM Agents 研究前沿

flowchart LR
  A["LLM Agents 研究前沿"]
  A --> B["分类：前沿探索"]
  A --> C["关键词：AI Research"]
  A --> D["关键词：Agent"]
  A --> E["关键词：ReAct"]
  A --> F["关键词：Benchmark"]

Agent 的关键，不是让模型“多会几个工具”，而是让它在不确定环境里，为了一个目标持续观察、决策、行动、纠错，并在必要时调整计划。也正因为如此，Agent 研究不再只是 prompt engineering 的延长线，而逐渐变成一个结合推理、工具使用、记忆、环境交互与评测方法的独立研究方向。 (arXiv)

延伸阅读：

这篇文章会讲什么

如果说传统 LLM 的核心能力是“根据上下文生成下一个合理输出”，那么 Agent 研究真正要解决的问题是：模型怎样在一个会变化、会反馈、会失败的环境中，持续完成任务。

这和普通问答有本质区别。一个普通聊天模型可以在单轮里给出看起来不错的答案，但 Agent 需要面对的是另一类问题：

  • 它要不要调用工具？
  • 先做哪一步，后做哪一步？
  • 观察结果不符合预期时，是否该回退？
  • 失败之后，是继续试、改计划，还是请求帮助？
  • 当环境是网页、代码仓库、桌面系统甚至游戏世界时，它如何理解“状态”与“动作”？

过去两年里，Agent 研究之所以突然成为热点，不只是因为它听起来更像“通用智能”，更因为它把 LLM 从一个主要做语言映射的系统，推向了一个更接近“行动者”的位置。ReAct 定义了推理与行动交替的基本范式；Reflexion 把失败后的语言反思引入闭环；Voyager 展示了在开放世界里积累技能库的可能；Generative Agents 和 CAMEL 则把多 Agent、社交、角色和协作问题带进了主流讨论。与此同时，SWE-bench、WebArena、AgentBench、OSWorld 这样的 benchmark 开始让“Agent 到底强不强”这件事有了更像样的测量方式。 (arXiv)

这篇文章想做的，不是简单列论文，而是帮你建立一个更稳的研究图景：

  • Agent 研究到底在研究什么，而不只是研究“会不会调 API”
  • 为什么 ReAct 到今天仍然是最重要的起点
  • 记忆、反思、多智能体、工具学习分别解决了什么问题
  • 为什么 benchmark 在 Agent 里比在普通 LLM 里更重要
  • 2025–2026 的前沿变化，究竟是在推进“更通用”，还是只是做出更复杂的 demo

先给一个判断：Agent 研究的核心，不是“把 LLM 包成工作流”，而是“让模型在环境中形成闭环”

先看定义：只要系统需要持续观测环境、选择动作、接收反馈并调整行为，它就开始进入 Agent 问题，而不再只是普通的文本生成问题。

这是理解 Agent 研究最重要的一步。很多工程系统会把“会调用几个工具的 LLM 工作流”也叫 Agent，这没错，但从研究角度看，还不够。

更严格地说，一个 Agent 问题通常至少具备四个元素：

  1. 目标：系统不是只回答一句话，而是需要完成任务
  2. 动作空间：它可以采取动作，例如点击、搜索、调用 API、写代码、发请求
  3. 环境反馈：动作会带来新的 observation，而不是一次性结束
  4. 闭环控制：系统需要根据反馈继续决策，而不是只在起点生成完整计划

这就是为什么 ReAct 会如此重要。它不是因为写了一个好 prompt 才经典，而是因为它把“推理”和“行动”放进了可交替的循环结构里：Thought → Action → Observation。这个结构后来几乎成了所有 Agent 框架的默认心理模型，不管具体实现是 prompt-based、tool calling、planner-executor，还是更复杂的 memory / reflection 变体。 (arXiv)

从研究全景看，当前 Agent 论文大致围绕几类核心问题展开：

方向核心问题代表工作
推理与行动如何在思考与执行之间形成闭环ReAct
反思与纠错如何从失败中提炼改进信号Reflexion
技能与长期任务如何在复杂环境中积累能力Voyager
社会与多智能体多 Agent 如何分工、协作、竞争CAMEL、Generative Agents
工具学习如何泛化到新工具和新 APITool learning 系列
Benchmark如何在真实环境中测出能力与边界SWE-bench、WebArena、AgentBench、OSWorld

这个划分很重要，因为它提醒我们：Agent 研究不是一个单点能力，而是一组彼此关联的问题。很多系统看起来失败在“模型不够强”，但真实原因可能是：

  • 规划方式不对
  • 工具描述不清
  • 状态表示太弱
  • 反馈信号用不好
  • benchmark 设计无法揭示真实问题

ReAct：为什么它到现在仍然是 Agent 研究的起点

先看定义：ReAct 的贡献，不只是提出一个 prompt 模板，而是明确了 Agent 需要在“内部推理”和“外部行动”之间不断来回切换。 (arXiv)

ReAct 到底解决了什么问题

在 ReAct 之前，一个常见做法是让模型先想完整计划，再执行；或者干脆把任务直接交给模型，一次性给出答案。问题在于，这两种方式都假设模型一开始就掌握足够信息，或者能在没有环境反馈的情况下把问题想清楚。

但真实任务不是这样的。

例如：

  • 网页操作中，下一页长什么样，只有点击后才知道
  • 检索任务中，第一次搜索未必会找到正确信息
  • 代码修复中，第一次修改后需要跑测试，才能知道问题是否真的解决
  • 具身或游戏环境中，动作执行后世界状态会变化

ReAct 的价值就在于承认了这一点：很多任务不是“先想完再做”，而是“边想边做，做了再想”。

这看起来朴素，但影响极大。它把 Agent 从“静态规划问题”转成了“交互式决策问题”，也让后续大量研究得以建立在同一个基本骨架上。

为什么 ReAct 影响这么大

因为它同时满足了两个条件：

  1. 概念上简单，容易理解
  2. 形式上足够通用，能迁移到很多环境

无论你做的是网页 Agent、代码 Agent、检索 Agent，还是桌面 Agent，几乎都可以在某种程度上套进这个循环：

  • 我现在认为应该做什么
  • 我执行哪个动作
  • 我观察到了什么
  • 我是否需要修正原来的判断

从后来的发展看，很多框架虽然实现方式不同，但本质仍然继承了 ReAct 思路。差别只在于：

  • “Thought” 是显式输出还是隐藏在内部状态里
  • “Action” 是自由文本还是严格 schema
  • “Observation” 是自然语言、结构化状态，还是多模态输入
  • 中间是否引入记忆、反思、规划器、验证器等额外模块

ReAct 的局限也很典型

ReAct 很重要，但它不是终点。

它最主要的问题包括：

1. 过度依赖当前步的局部判断

模型每一步都在根据有限上下文和当前 observation 作决定，这对短任务很有效，但在长任务里容易出现“局部合理、全局迷失”。

2. 思考过程不等于高质量规划

显式 thought 并不自动等于好计划。 模型可能写出看起来很有条理的 thought，但行动选择仍然错误。

3. 错误会沿轨迹传播

一旦前几步理解错状态，后续 thought-action-observation 循环可能会围绕一个错误假设不断展开。

这也是为什么后来的研究开始引入反思、记忆、层级规划、环境建模和 verifier：不是为了推翻 ReAct，而是为了给这个闭环补上更强的纠错和长期控制能力。

Reflexion：Agent 为什么需要“从失败里提炼语言化经验”

先看定义：Reflexion 的关键洞见是，Agent 不一定要靠参数更新才能改进；它也可以把失败经验变成语言记忆，在下一轮任务中改变自己的策略。 (OpenReview)

Reflexion 的核心思想

传统强化学习会把反馈转成数值信号，再通过参数更新影响策略。 Reflexion 走的是另一条更适合 LLM 的路：把失败经验总结成自然语言反思，再把这段反思作为后续决策上下文的一部分。

这个想法看起来轻量，但非常贴合 LLM 的特性。 因为 LLM 对自然语言形式的规则、经验、提醒天然敏感。与其每次重新训练，不如直接告诉它：

  • 上次错在哪里
  • 为什么错
  • 下一次应该避免什么

这就像给 Agent 增加了一层“语言化的经验缓存”。

Reflexion 解决了什么类型的问题

它特别适合那些允许试错、而且错误模式有一定可总结性的任务，例如：

  • 编程
  • 游戏
  • 工具使用
  • 多步推理
  • 需要多轮尝试才能完成的序列决策任务

在这些任务里，单次失败并不罕见；关键不是“永不失败”，而是“失败后能否带着更好的策略继续”。Reflexion 就是在研究这个问题。

Reflexion 为什么重要

因为它把 Agent 研究里的一个深层问题摆到了台面上： LLM Agent 的学习，不一定主要发生在训练阶段，也可以发生在推理与交互阶段。

这和 reasoning models、test-time compute scaling 的趋势其实是相通的。 大家都在探索一件事：模型是不是可以在参数固定的前提下，通过更长的内部计算、更丰富的外部交互、更明确的语言反馈，获得显著更好的表现。

但 Reflexion 也有明显边界

1. 反思质量高度依赖模型自身

如果模型对失败原因的诊断不对，反思就会变成错误记忆，甚至让后续行为更差。

2. 语言反思并不总能映射到可执行改进

有些任务的失败不是策略问题，而是环境理解问题、工具能力问题或底层模型能力不足。此时“写一段教训”帮助有限。

3. 记忆一多，管理就成了问题

不是所有反思都应该永久保留。 哪些该保留、如何检索、何时失效、怎样避免互相冲突，这些都是后续记忆研究要解决的问题。

实践启示

Reflexion 最重要的启发，不是“每个 Agent 都要写反思日志”，而是提醒我们： Agent 的改进能力，很大程度上取决于它能否把失败变成结构化经验，而不是仅仅重复尝试。

Voyager：为什么它在 Agent 研究里如此特别

先看定义：Voyager 不是单纯证明“LLM 可以玩 Minecraft”，而是展示了 Agent 可以在开放环境中通过技能积累和迭代提示，形成一种近似持续学习的能力。

Voyager 的研究意义不在“游戏”，而在“开放世界”

Minecraft 只是载体，真正关键的是它提供了一个非常适合测试 Agent 的环境：

  • 状态丰富
  • 任务开放
  • 行动空间大
  • 长期目标和短期目标交织
  • 技能之间可以组合复用

这比很多封闭 benchmark 更接近“真实世界任务”的味道。 因为真实任务通常也不是一次性解题，而是要在复杂环境中不断发现新子任务、获取资源、积累技能。

Voyager 最有启发性的地方，是把“技能库”作为核心中间层。 Agent 不是每次都从零开始，而是把已有成功经验抽成可复用技能，后续遇到类似问题时再调用和组合。这比纯 prompt 式的逐步决策更接近一种可积累的能力结构。 (arXiv)

Voyager 代表了哪种研究方向

它代表的是一条非常重要的路线： Agent 不只是执行当前任务，还应该逐步建立面向未来任务的能力资产。

这个方向后来影响了很多研究和工程思路，例如：

  • 技能库 / tool memory
  • 长期任务分解
  • 子程序生成与复用
  • 环境探索式学习
  • 程序化中间表示

但 Voyager 的边界也很清楚

1. 环境仍是高度特定的

Minecraft 虽然开放，但它仍然是一个规则相对明确、接口相对清晰的数字环境。 从这里走向“真实办公环境”“真实互联网”“真实企业流程”，中间还有很大距离。

2. 技能复用依赖环境可分解性

不是所有现实任务都像 Minecraft 那样容易被拆成可复用技能单元。 很多知识工作里的技能边界更模糊，也更依赖上下文。

3. 长期学习仍然不是参数级的真正持续训练

Voyager 更多是在推理时和程序层面进行技能积累，而不是完整意义上的 continual learning。

实践启示

Voyager 对应用层最重要的启发是： 如果 Agent 要做长任务和复杂任务，单纯依赖“一次性上下文 + 当场推理”通常不够，它需要某种形式的中间能力沉淀。

CAMEL 与 Generative Agents：多 Agent 研究为什么不是“多开几个窗口”

先看定义：多智能体研究真正关心的，不是让多个 LLM 同时说话，而是研究角色、通信、分工、协商和社会性行为如何影响任务完成。 (arXiv)

CAMEL：角色扮演为什么重要

CAMEL 的一个核心做法，是通过角色设定和 inception prompting 让不同 Agent 以不同身份进行对话和协作。这个设计很巧妙，因为它把多 Agent 的关键问题显式化了：

  • 谁负责什么
  • 各自知道什么
  • 如何沟通
  • 如何避免目标冲突
  • 如何保持角色一致性

这说明多 Agent 不是“复制一个 Agent N 次”那么简单。 一旦系统里有多个行动主体，研究重点就会从单体能力转向组织问题：

  • 分工是否有效
  • 通信是否高效
  • 是否会出现无谓争论
  • 是否会相互放大错误
  • 谁负责最终整合结果

Generative Agents：为什么它引发了这么大讨论

Stanford 的 Generative Agents 让一群带有记忆、计划和反思机制的 Agent 在虚拟小镇中互动，从而展示出一种近似“社会模拟”的效果。它之所以出圈，不只是因为 demo 有趣，而是因为它让大家看到：当记忆、计划和社交机制组合在一起时，Agent 的研究对象会从“任务执行器”扩展到“行为主体”。 (arXiv)

这带来了两个非常不同的研究方向：

  1. 任务导向型多 Agent 例如协作编程、分布式检索、角色分工式问题求解。

  2. 社会导向型多 Agent 例如虚拟社区、角色互动、群体行为模拟、市场与谈判。

多 Agent 为什么既诱人又危险

诱人的地方在于，当任务复杂到单 Agent 难以同时处理规划、执行、验证、检索、整合时，把不同职责拆给不同 Agent 看起来很自然。

但危险也很现实：

  • 通信成本迅速上升
  • 上下文重复带来高成本
  • 角色不清容易互相推诿
  • 多个错误可能相互强化
  • 最终整合者可能成为新的瓶颈

因此，多 Agent 不是天然更强，而是在任务确实可以分解、子角色确实有清晰边界时，才可能带来收益。

实践启示

很多“多 Agent 系统”最后效果不好，不是因为多 Agent 这个方向错了，而是因为：

  • 任务其实不值得拆
  • 角色设计只是形式化，没有真实信息差和职责差
  • 缺乏明确的通信协议和整合机制

所以研究多 Agent 时，关键不是“能不能搭起来”，而是“为什么这个任务值得用多 Agent，而不是一个更强的单 Agent”。

Benchmark：为什么 Agent 研究比 LLM 研究更依赖 benchmark

先看定义：Agent 的能力不是一句答案就能测出来的，它必须在环境中被测量；而环境一旦变复杂，benchmark 质量就会直接决定你看到的结论是否可信。

在普通 LLM 任务里，很多 benchmark 是静态输入、静态输出。 但 Agent 不一样。它的性能往往取决于一整条轨迹：

  • 看到了什么
  • 做了什么动作
  • 何时偏离目标
  • 是否自我修正
  • 最后有没有真正完成任务

这意味着 Agent benchmark 不只是题库，而是环境 + 任务 + 评估器的组合。

SWE-bench：代码 Agent 的代表性 benchmark

SWE-bench 把真实 GitHub issue 和对应代码仓库拿来作为任务，让模型生成能通过测试的 patch。它的重要性在于，它把“编程能力”从静态题目推进到了更接近真实软件工程问题的场景里。官方站点目前已经扩展出 SWE-bench Verified、Lite、Multilingual、Multimodal 等系列，也说明 benchmark 本身在不断进化，以解决标注噪声、评测成本和任务覆盖面问题。 (swebench.com)

SWE-bench 的价值不只是测“会不会写代码”，更在于测：

  • 是否能读懂 issue
  • 是否能在真实 repo 中定位问题
  • 是否能产生可执行修改
  • 是否能通过测试闭环验证

这比普通代码补全更接近真正的 coding agent。

WebArena：网页 Agent 的关键测试床

WebArena 把任务放到更接近真实互联网的网站环境中，要求 Agent 完成诸如搜索、填写表单、购物、导航等多步任务。它的重要性在于：网页操作把语言理解、页面 grounding、状态跟踪、工具使用和长期规划全都揉在了一起。后续的 WebArena Verified 进一步修复了原始评测里的脆弱性和歧义，说明这个领域已经意识到：如果 benchmark 自己不可靠，你得到的模型排名也不可靠。 (arXiv)

AgentBench：早期通用 Agent benchmark 的代表

AgentBench 的价值在于它并不聚焦某一单独环境，而是把多个环境放在一起，试图测量“LLM as Agent”在不同任务形态下的整体表现。这条思路很重要，因为它提醒大家：单一环境下的好成绩，不一定能代表通用 Agent 能力。 (GitHub)

OSWorld：为什么“真实计算机环境”突然重要起来

OSWorld 把 benchmark 推向了更贴近真实 computer-use agent 的方向：不是在简化网页里点击，而是在真实操作系统和应用程序里完成任务。它的重要性在于把多模态感知、UI grounding、系统操作、多步任务和执行式评估放到一个统一环境里。后续关于 OSWorld 的研究甚至开始专门分析 latency，说明 Agent 的问题已经不只是“能不能做”，而是“做得是否足够快、足够实用”。 (os-world.github.io)

还有哪些新变化值得注意

2025–2026 期间，benchmark 生态继续细化：

  • BrowseComp 关注浏览与研究型 Agent 的网页搜寻能力
  • DeepResearch Bench 试图评估 deep research agents 在长链检索、引用、遗忘和 hallucination 上的表现
  • WebArena-x 则把网页 Agent 评测扩展成一组持续更新的项目，包括 VisualWebArena、TheAgentCompany 等方向 (OpenAI)

这说明 benchmark 的演进方向非常明确： 从早期“静态任务 + 模拟环境”，走向“真实环境 + 长任务 + 可复现执行 + 更细粒度失败分析”。

评测维度不能只看完成率

一个成熟的 Agent benchmark，至少还应关注：

  • 任务完成率：最后有没有做成
  • 样本效率：用了多少步、多少工具调用
  • 时间效率：是否能在可接受时间内完成
  • 鲁棒性：页面变化、噪声、意外反馈下是否还能工作
  • 轨迹质量：中间过程是不是合理、可解释
  • 成本：完成一次任务要花多少 token、多少模型调用

因为在 Agent 里，“成功但极慢”“成功但成本极高”“成功但只能在特定环境下复现”，都不能简单算作真正强。

工具学习（Tool Learning）：Agent 的泛化能力，往往取决于它会不会“读工具说明书”

先看定义：很多 Agent 问题看起来是推理问题，本质上其实是工具学习问题：模型是否理解有哪些工具、什么时候用、用哪个、参数怎么填、结果如何解释。

这是研究和工程中都极其现实的方向。 因为今天大多数 Agent 并不是在真空中行动，而是通过工具与外界连接：

  • 搜索 API
  • 浏览器操作接口
  • 数据库查询
  • 代码执行器
  • 文件系统
  • 企业内部 API
  • SaaS 平台动作

从研究角度，工具学习可以拆成四个问题：

问题本质
工具表示如何让模型理解工具做什么
工具选择在多个工具之间选对
参数构造正确填写参数和约束
结果消费正确理解返回结果，并决定下一步

为什么工具学习这么难

因为它不是简单的“记住 API 名称”。 模型需要同时处理语义和程序性约束。

例如，一个工具描述“搜索客户最近 90 天交易”，模型不仅要理解“交易”的业务含义，还要知道参数格式、时间范围、分页、错误返回、权限限制等细节。 一旦这里做不好，后面的 planning 再好也没用。

一个重要趋势：schema 越标准化，Agent 越容易学会调用

这也是为什么 function calling、OpenAPI、结构化 schema、JSON arguments 这些机制越来越重要。 因为它们在本质上是在降低工具学习的不确定性。

但要注意，标准化 schema 解决的是“接口表达清晰”问题，不自动解决“策略正确”问题。 模型可能会调用格式正确的工具，但调用顺序、时机和整体计划仍然错误。

实践启示

工具学习方向最重要的启发是： Agent 的泛化不只是换一个更强模型，还包括把工具接口设计得更可学、更可选、更可验证。

很多 Agent 项目效果不好，问题不在模型，而在工具层完全没为模型优化过。

世界模型（World Models）：Agent 真正缺的，常常不是工具，而是对环境的内部表示

先看定义：Agent 越是进入复杂环境，越不能只靠短期上下文做局部反应；它需要某种形式的“我现在在哪里、世界变成了什么样、接下来会发生什么”的内部表示。

这就是世界模型问题。

在很多当前 LLM Agent 里，环境理解是隐式的： 模型从 observation 文本、网页 DOM、UI 截图、工具返回里临时构造对当前状态的理解。

但这种方式有明显局限：

  • 记忆会被上下文窗口限制
  • 长任务中状态容易丢失
  • 模型可能混淆“过去已经做过的事”和“接下来该做的事”
  • 对未来动作后果缺乏显式预测

因此，越来越多研究开始重新关注世界模型，只不过形式不完全一样：

  1. 显式状态表示：维护任务状态、环境状态、资源状态
  2. 隐式状态压缩：通过摘要、记忆和结构化缓存保留重要上下文
  3. 预测式建模：尝试预测某个动作执行后的环境变化
  4. 具身环境建模：在机器人、游戏或仿真中学习更物理化的状态转移

为什么世界模型重要但很难

因为 Agent 环境往往既复杂又不完全可观测。 网页会变化，桌面会弹窗，外部 API 会报错，用户需求本身也可能变化。 在这种情况下，显式世界模型如果太粗糙，就帮不上忙；太细，又会变得昂贵且难维护。

所以当前现实是： 很多 Agent 系统还在大量依赖隐式世界理解，显式世界模型更多停留在研究探索阶段。

实践启示

世界模型方向给应用层的提醒是： 如果你的 Agent 经常“忘记自己做到哪一步了”“反复做同一件事”“无法利用之前观察到的关键信息”，那问题往往不是再加一个 prompt，而是需要改进状态表示。

Agent 安全研究：真正的新问题，不是“模型会不会乱说”，而是“模型会不会乱做”

先看定义：一旦 Agent 具备行动能力，安全问题就从内容安全扩展到操作安全、权限安全、连续性安全和目标对齐问题。

这和普通聊天模型有本质不同。 聊天模型说错了，可能是认知错误；Agent 做错了，可能直接造成外部后果。

典型风险包括：

风险具体含义
越权执行做了用户未授权的动作
目标漂移为了完成局部子目标偏离原始任务
不可中断执行链过长，用户难以制止
工具滥用错误或恶意地调用高权限工具
环境污染在外部系统留下错误状态
对抗脆弱性被网页、提示注入、恶意文档误导

尤其在网页、代码、桌面、企业系统场景里，Agent 很容易遇到 prompt injection、恶意页面提示、虚假系统消息、危险按钮等问题。 这说明 Agent 安全不是给输出加一个内容审核器就能解决的，而要放进整个架构里考虑：

  • 权限分层
  • 人工确认点
  • 可中断性
  • 可回滚性
  • 轨迹审计
  • 高风险动作的 verifier 或 sandbox

为什么研究里越来越强调“computer use”与真实环境

因为越接近真实环境，这些安全问题暴露得越明显。 OSWorld、WebArena 这类 benchmark 的重要性，不只是它们更难，而是它们更容易暴露出 Agent 在真实交互中的脆弱性。 (arXiv)

实践启示

如果你做的是 Agent 产品，而不是论文 demo，安全不是最后加的一层，而是从一开始就要写进动作设计与权限模型里的系统约束。

从专用 Agent 到通用 Agent：为什么“通用”仍然是长期目标，而不是短期现实

先看定义：今天大多数真正有效的 Agent，都还是专用 Agent；所谓“通用 Agent”更多是一条研究方向，而不是已经稳定成立的产品范式。

这是当前讨论里最需要克制的一点。

从 benchmark 和论文看，Agent 在特定环境中确实进步很快：

  • 代码修复有 SWE-bench
  • 网页操作有 WebArena
  • 桌面操作有 OSWorld
  • 研究型浏览有 BrowseComp、DeepResearch Bench

但这些进步，并不自动等于“一个 Agent 可以稳定跨领域完成各种现实任务”。

原因很简单：

1. 环境差异极大

网页、代码仓库、桌面系统、数据库、企业软件，它们的状态表示、动作空间和成功标准都不一样。

2. 工具泛化远未解决

模型可以在一组熟悉工具上表现不错，但换一套新工具、新 schema、新权限约束，性能可能迅速下降。

3. 任务泛化比问答泛化更难

问答里你可以靠更强知识和推理泛化； Agent 里你还要泛化到操作、错误恢复、长期规划、环境适应，这难度高一个层级。

4. 真实可用性不仅看成功率

就算 benchmark 成功率不低，也可能因为成本、延迟、稳定性、不可解释性而不适合真实落地。

因此，更现实的路径仍然是：

  • 先把专用 Agent 做得可靠
  • 再让它逐步覆盖更宽但仍有边界的一类任务
  • 最后才谈跨环境、跨工具、跨任务的更通用能力

这并不保守，而是符合过去两年的研究现实。

2025–2026 的一个新变化：Agent 研究正在从“方法论文”转向“系统能力 + 真实评测”

先看定义：早期 Agent 研究更像是在发明模式；而近一年多更明显的趋势，是大家开始认真比较真实任务、真实轨迹、真实成本和真实时间。

这点非常值得注意。

早期论文更强调：

  • 提出一种新 prompt 结构
  • 引入某种 memory / reflection / multi-agent 机制
  • 在几个代表性任务上展示提升

这类工作当然重要，它奠定了 Agent 研究的基本语言。 但到 2025–2026，领域明显开始转向更“硬”的问题：

  • benchmark 本身是否可靠
  • 任务是否足够真实
  • latency 是否可接受
  • 成本是否过高
  • 轨迹失败点在哪里
  • 浏览 / computer use / coding 是否真的能稳定复现

WebArena Verified、OSWorld-Human、DeepResearch Bench 这类工作，本质上都在做同一件事： 把 Agent 从“会不会做出惊艳 demo”拉回到“能不能在严格测量下成立”。 (OpenReview)

这说明一个很重要的领域信号： Agent 研究正在从“构想阶段”进入“系统实证阶段”。

小结

LLM Agent 研究的真正价值，不是让模型看起来更像人，而是让它开始在环境中形成目标驱动的闭环行为。

ReAct 奠定了推理—行动交替的基本范式，说明 Agent 不该只靠一次性回答，而应通过持续 observation 和 action 完成任务； Reflexion 把失败转成语言化经验，打开了“推理时学习”的方向； Voyager 证明复杂开放环境中的技能积累是有可能的； CAMEL 与 Generative Agents 则把多 Agent、角色、社会性和组织问题带进了研究主线。与此同时，SWE-bench、WebArena、AgentBench、OSWorld 让 Agent 的讨论从“感觉很强”走向“在什么环境下、以什么代价、能否真实完成任务”的可测量问题。 (arXiv)

如果把这些研究线索压缩成一个更稳定的判断，可以这样说：

  • Agent 的关键不只是会调用工具，而是能否在环境中持续闭环
  • Agent 的瓶颈不只是模型大小，还包括状态表示、工具学习、反思机制和环境设计
  • 多 Agent 不是天然更强，只有在角色和任务结构真实可分解时才有价值
  • benchmark 在 Agent 里不是配角，而是决定研究结论是否可信的基础设施
  • 从专用到通用 Agent 仍然是长期目标，短期最现实的方向，仍是把边界明确的专用 Agent 做得更稳、更快、更便宜、更安全

所以，理解 Agent 研究前沿，最重要的不是记住更多论文名字，而是建立一个判断框架：

  • 这个方法增强的是哪一层能力？
  • 它解决的是局部问题，还是长期控制问题？
  • 它是否依赖特定环境，能否迁移？
  • 它在真实 benchmark 上是否成立，而不只是 demo 好看？
  • 它离“可用系统”更近了一步，还是只是让轨迹更复杂了？

当你用这个框架看 Agent 研究时，就会更容易分辨：哪些是真正推动领域前进的工作，哪些只是“把 LLM 包得更像 Agent”。