SkyRL:首个现实环境、长周期LLM Agent的端到端RL流水线框架

如今众多的AI Agent智能体正在超越静态基准,进入需要长期规划、多步骤工具使用和环境反馈的现实世界任务。此前大多数现有的RL强化学习框架都针对涉及短期无状态交互的任务进行了优化,例如搜索增强推理或简单的代码执行。相比之下,现实世界中的任务(例如 SWE-B...
继续阅读 »
图片如今众多的AI Agent智能体正在超越静态基准,进入需要长期规划、多步骤工具使用和环境反馈的现实世界任务。此前大多数现有的RL强化学习框架都针对涉及短期无状态交互的任务进行了优化,例如搜索增强推理或简单的代码执行。相比之下,现实世界中的任务(例如 SWE-Bench 中所示的任务)则受益于在有状态的动态环境中进行长期规划。这给基础设施和训练算法都带来了新的挑战。wechat_559e4b3d08ece256607a09e3a5409788.jpg在这种背景下,为了有效地训练这些Agent,我们推出了SkyRL,这是我们针对Multi-Turn多轮工具使用 LLM 的 RL 训练流程,它针对 SWE-Bench 等长期真实环境任务进行了优化,建立在VeRL和OpenHands之上。使用 SkyRL,我们能够使用大约 300 个训练数据样本,在各个模型线上的SWE-Bench-Verified上取得令人满意的结果!
  • SkyRL-Agent-7B-v0:11.0% → 14.6%

  • SkyRL-Agent-8B-v0:3.6% → 9.4%

  • SkyRL-Agent-14B-v0:18.0% → 21.6%

图 1:SkyRL 构建于 VeRL 之上,继承了 VeRL 对学习算法的丰富支持。SkyRL 通过引入Agent层扩展了 VeRL,使其具备以下优势:(1) 高效的异步多Rollout;(2) 通用工具的使用;以及 (3) 通用且可扩展的环境执行。

概述

强化学习的最新进展使语言模型能够成为主动Agent。近期的开源框架,例如 Search-R1 和 ToRL(基于 VeRL 构建),在这方面取得了令人瞩目的进展,实现了多轮强化学习,并能够交叉使用单一工具(例如搜索或代码执行)。这些系统为工具增强推理奠定了重要的基础。然而,诸如 SWE-Bench、WebDev 和 Web 浏览等复杂的现实世界任务需要高级Agent能力,其中模型需要调用多个工具、编写和运行测试、响应环境反馈并执行长期规划。图 2:使用 CodeAct Agent 解决 SWE-Bench 问题的示例工作流程。

虽然这些更先进的Agent智能体标志着令人兴奋的进化,但在它们上运行在线强化学习却极具挑战性。首先,高效的训练框架需要快速的环境执行和高效的环境交互Rollout。其次,高效的训练需要强大的长周期算法(这不是本文的重点)。总而言之,这使得问题比训练先前的工具增强推理法学硕士(LLM)复杂得多。

为了填补这一空白,我们推出了SkyRL——我们的强化学习训练流水线,用于在复杂环境中执行多轮工具使用LLM的长周期任务,包括SWE-Bench,它基于VeRL和OpenHands构建

SkyRL 功能

- 支持训练执行具有复杂环境交互的多步骤计划的LLM智能体。

- 通过异步并行Rollout操作,在轨迹上重叠计算密集型阶段和环境交互密集型阶段,实现更高吞吐量的生成(比基线实现加速 4-5 倍)。

- 预填充(并扩展)强化学习算法,方便快速启动。

在 v0 版本中,我们支持 SWE-Bench 的端到端在线强化学习训练流程。接下来计划支持其他长周期任务,例如 WebArena 和 WebDev。本文章的其余部分将讨论我们在基础设施方面面临的挑战和经验教训,以及我们的初步模型结果。系统设计

在 SkyRL-v0 中,我们主要致力于解决环境扩展和低效Rollout阶段的挑战。我们集成了OpenHands项目中的CodeAct抽象作为Agent循环部分,并采用远程沙盒服务器实现可扩展的环境Rollout。

挑战 1:环境扩展 - 远程沙盒服务器

在许多实际的Agent训练任务中,例如 SWE-Bench,每次Rollout都必须在隔离且有状态的环境中运行,通常通过 Docker 容器进行配置。这些环境通常都是资源密集型,每个环境消耗1 个以上的 CPU 和约 7GB 的存储空间。即使是中等配置(例如,批次大小为 16,Rollout 8 次)也可能需要 100 多个 CPU 和接近 1TB 的磁盘空间。

将环境执行与训练共置会导致隔离受限,并且扩展并行运行环境数量的灵活性不足,这可能导致LLM 推理引擎的请求速率不足,最终导致GPU 资源利用率低下。为了解决这个问题,我们实现了一个可扩展的远程沙盒服务器将环境执行与训练分离。这种分离式设计支持独立扩展环境Worker,以保持较高的环境交互速率,从而确保在Rollout阶段实现较高的 GPU 利用率。

图 3:远程沙盒服务器的 Kubernetes Deployment。

我们将服务器部署在 Kubernetes 上,利用存储优化的实例来缓存容器镜像并实现快速启动。为了高效处理并发请求,我们利用aidocker和crun容器运行时,它提供轻量级且高性能的容器执行。我们的设置支持在 16 CPU 节点上每个副本运行大约 80-100 个容器,而不会遇到稳定性问题。虽然仍有很大的优化空间,但我们目前的实现简单、高效且公开可用。我们将服务器代码和Deployment配置开源,以支持有意自行托管强化学习训练所需的可扩展远程沙盒环境的研究人员。

挑战 2:费用昂贵的生成阶段

在基于Agent的强化学习训练中,Rollout阶段需要Agent与环境进行多轮交互。近期在多轮强化学习 (MDRL) 领域取得的进展,例如 RAGEN、Search-R1 和 ReTool,通常每个轨迹仅涉及有限数量的交互步骤。相比之下,像 SWE-bench 这样的任务通常需要 20 到 50 个轮次(甚至更多)才能让智能体使用 OpenHands 框架完成整个流程,这通常涉及识别相关文件、编写测试用例以重现问题、应用代码编辑以及通过测试验证修复。此外,每个步骤的环境执行时间在不同轨迹之间可能存在显著差异,具体取决于智能体操作的性质。例如,列出文件通常很快,而执行 Python 脚本进行单元测试则可能要耗费更多时间。

图 4 不同 rollout 实现方式的可视化。我们的异步 Rollout + 3 阶段生产者-消费者流水线有效加速了 rollout 的生成。

如图 4 上半部分所示,单轮强化学习中常见的 rollout 实现(例如 VeRL和 OpenRLHF对于Agent式推理工作负载而言效率低下。这种低效源于每个 LLM 生成步骤的同步障碍,而同步障碍是由于依赖离线批量生成造成的。因此,系统无法利用现代 LLM 服务引擎支持的连续批量优化,导致资源利用率低下和吞吐量降低。

为了解决这个问题,我们采用了两项优化措施,与原始基线实现相比,总共实现了4-5 倍的加速

1. 异步Rollout – 依赖现代 LLM 服务引擎(例如SGLang和 vLLM)的 `async_generate` 方法,每条轨迹可以独立推进,从而避开全局同步点,如上图 4 中间部分所示。

2.三阶段生产者-消费者流水线 – 此外,为了减少 GPU 空闲时间,我们可以将 (i) 运行时初始化(例如构建镜像、启动和连接容器)、(ii) 轨迹生成和 (iii) 奖励计算(例如发送补丁、运行测试)这几个阶段解耦并重叠,以最大化并行性和系统吞吐量,如上图 4 底部所示。

  • a. 我们通过三个队列实现此流水线:`init queue`、`run queue` 和 `eval queue`。每个阶段都充当下一个阶段的生产者:`init queue`从`init_queue` 中拉取数据,准备环境,然后推送至 `run_queue`;Agent Runner从 `run_queue` 中拉取已初始化的实例,执行多轮Rollout,并将完成的轨迹推送至 `eval_queue`;然后,`eval queue`从 `eval_queue` 中拉取数据来计算最终奖励。

  • b. 我们使用 `asyncio` 任务,并根据队列占用情况和剩余工作动态生成任务。每个任务都异步地将其结果推送至下一阶段,使用有Bounded的队列可以提供自然的反压机制(back-pressure),防止过载并确保跨阶段的负载平衡。这种流水线执行通过将计算和环境交互密集型阶段重叠在许多轨迹上,显著提高了系统吞吐量

早期训练探索

我们采用Openhands中的CodeAct 框架和OpenHands 脚手架来生成 rollout,并利用基于规则的奖励来执行策略更新。

Rollout 生成

我们利用 OpenHands 脚手架在软件工程任务环境中迭代地提示模型。在每个回合中,模型都会编写代码并执行函数调用作为操作。该模型提供三种类型的操作:(1) `execute_bash`:在终端中执行 bash 命令;(2) `finish`:在任务完成或助手无法继续执行任务时结束交互;(3) `str_replace_editor`:用于查看、创建和编辑文件的自定义编辑工具。

具体来说,Rollout操作通过以下流程生成:

Input: Model M, Environment E, Task description P, a set of available actions A. # OpenHands manage the history of interaction, # initialized with the task description.history = P 
while not done:    # The CodeAct framework prompt the model with the history and     # the available tool. The model generates an action in the form    # of execuatble code, e.g., view_file(file_path).    action = M(history, A)    # The action is then sent to the environment for execution    # and gets an environment observation.    # e.g. the content of a view_file action.    # The loop terminates if the action is a termination action.     done, observation = E(action)    # OpenHands then tracks the history by appending the action    # and the observation in this turn.    history.append(action)    history.append(observation)
# Returns a git patch written by the model in the history of interactionpatch = E.get_patch()return patch

奖励设计

我们使用一种简单的基于结果的奖励机制。在Agent完成交互后,我们会从环境中获取 Git 补丁。然后,我们将该补丁应用到原始代码库,并针对目标 GitHub 问题运行测试套件。如果测试通过且问题得到解决,我们将奖励 1;否则,奖励为 0。尽管简单,但这种信号有效地指导了模型,从而提高了问题解决率(参见结果部分)。我们还跟踪了两种常见的故障模式

- 陷入循环:模型连续三轮重复相同的操作。

- 未完成操作:模型未能在规定的轮次预算内输出完成操作。

我们的实验表明,这种奖励方案可以减少循环并鼓励及时完成。我们目前正在探索更丰富的多轮强化学习奖励设计

数据选择

我们从SWE-Gym中选择问题,该数据集包含 2,438 个真实的 Python 任务实例。然而,这些任务极具挑战性——即使是 GPT-4o 的成功率也只有 4.55% 到 9.13%(详情请参阅 SWE-Gym 论文中的表 10)。因此,性能较弱的模型(例如 70 亿规模的模型)通常无法完成一次成功的Rollout,导致在 GRPO 和 PPO 等算法下没有学习信号,训练崩溃。为了缓解这个问题,我们构建了三个经过筛选的数据子集,并以模型生成成功率作为选择标准:

方案与结果

在此版本中,我们开源了三个不同规模、使用不同算法训练的模型,以满足社区的需求:

  • SkyRL-Agent-7B-v0(基于 OpenHands-7B-Agent 训练,基础模型 Qwen2.5-Coder-7B-Instruct)、

  • SkyRL-Agent-8B-v0(基于 Qwen3-8B 训练,非推理模式)

  •  SkyRL-Agent-14B-v0(基于 Qwen3-14B 训练,推理模式)。

评估设置

我们使用 OpenHands 脚手架和 CodeAct Agent 评估我们的模型,并使用相同的操作集:bash_execute、finish 和 str_replace_editor。我们在 SWE-Bench Verified 基准上进行评估,最大轮次预算为 50,最大序列长度为 32k。评估说明可在以下位置找到:

[SkyRL-OpenHands](https://github.com/NovaSky-AI/SkyGym-OpenHands/tree/main/evaluation/benchmarks/swe_bench)

- SkyRL-Agent-7B-v0

SkyRL-Agent-7B-v0基于OpenHands-7B-Agent模型进行训练,该模型是 Qwen2.5-Coder-Instruct模型的监督微调版本。我们采用基于结果的强化学习,分两阶段进行训练,批次大小为 16,每个实例 8 次 rollout。训练时,学习率为 1e-6,KL 系数为 1e-3,rollout 温度为 0.5,最大轮次为 25 次,并采用 GRPO 算法。

- 使用 SkyRL-v0-80-data 进行 15 步训练(3 个 epoch,在 8xH100 GPU 上耗时 7 小时)

- 使用 SkyRL-v0-220-data 进行 15 步训练(1 个 epoch,在 8xH100 GPU 上耗时 8.5 小时)

我们按照 SWE-Gym 论文中的建议,将训练温度设为 0,并与基线一起对模型进行了测量。我们发现,在 8xH100 GPU 上训练 15.5 小时后。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了 3.6%

- SkyRL-Agent-8B-v0(非思考模式)

SkyRL-Agent-8B-v0 在 Qwen3-8B 上进行训练,未启用思考模式(通过在`apply_chat_template` 中设置 `enable_thinking=False`)。我们使用一个基于结果的强化学习阶段进行训练,批次大小为 32,每个实例的 rollout 数量为 8。训练时学习率为 1e-6,KL 系数为 1e-3,rollout 温度为 0.6。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了5.8%

- 使用 SWEGym-293-data 进行 47 步训练(4.7 个 epoch,在 8xH200 上训练 27 小时)。

- SkyRL-Agent-14B-v0(思考模式)

使用思考模式进行多轮训练很容易超出上下文长度,尤其是对于较小的模型,它们更容易陷入推理阶段。因此,对于思考模式,我们尝试使用 Qwen3-14B作为基础模型。

SkyRL-Agent-14B-v0 在 Qwen3-14B的基础上使用 PPO 进行训练。我们采用基于结果的强化学习进行单阶段训练,批次大小为 32,每个实例的 rollout 为 8。我们训练时,学习率为 1e-6,KL 系数为 1e-3,rollout 温度为 0.6,裁剪提升率 (clip higher ratio) 为 0.28,以鼓励探索。我们使用Qwen3-14B本身作为基础评价模型。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了3.1%

- 使用 SkyRL-v0-293-data 进行 25 步训练(2.7 个 epoch,在 8xH200 GPU 上耗时 20 小时)。


展望未来:构建社区平台


SkyRL 尚处于早期阶段,但其构建着眼于长远目标:


1. 多环境支持:超越 SWE-Bench——可扩展至各种长周期智能体任务。

2. 可扩展性:轻松集成新环境、智能体、工具、奖励函数和任务。

3. 高效性:高效的生成和优化的执行流水线,最大限度地减少缓慢环境带来的开销。


SkyRL 是迈向高效长远智能体强化学习训练的一步。我们诚邀社区成员试用并与我们共同构建!


文链接:https://novasky-ai.notion.site/skyrl-v0图片 收起阅读 »

EP2 从个人兴趣到财务自由:独立开发者也可以这样做开源

如果你是一个热爱编程的独立开发者,你是否想过通过自己的开源项目来实现财务独立、甚至自由呢?在本期播客节目中,我们将为你介绍一些个人的成功开源项目,探讨那些最酷的产品和商业故事,其中包括: * 两个人半年收入 200万刀的开源项目 * 一个人专注一个开源项目十年...
继续阅读 »

如果你是一个热爱编程的独立开发者,你是否想过通过自己的开源项目来实现财务独立、甚至自由呢?在本期播客节目中,我们将为你介绍一些个人的成功开源项目,探讨那些最酷的产品和商业故事,其中包括:
* 两个人半年收入 200万刀的开源项目
* 一个人专注一个开源项目十年,总共收入 1300万刀的故事
* 售卖一个小小的主题,就收入近 30万刀
* 躺着赚钱,不提供售后服务的 to b 商业
* “未来你写的每一行开源代码都可能获被动收入” —— 一个全新的开源协同和利益分配体系
* ...

你将听到
02:36 投融资从开源转向到 AI
03:30 哪里火就去做什么,就一定能赚到钱吗?
06:14 core.js 的惨状
06:31 捐赠还是主流的开源项目收入方式
08:34 开源项目的流量广告变现
09:44 基于 utility-first 的 tailwindcss
11:44 tailwindcss 的开源路径和故事
16:44 tailwindcss 作者靠写书获得大量的收入
19:44 tailwindcss 在商业上半年收入 200w 刀
21:11 另外一个 css 项目 semantic css 的故事
22:44 semantic css 和 tailwindcss 的商业对比
25:00 解决方案可能永远都存在机会
25:44 一个主题销售近 30w 刀
29:11 开发者总是喜欢酷的东西,这里面可能就蕴藏着好的生意
31:28 做 to b 生意的 Sidekiq
37:27 Sidekiq 十年收入了 1300w 刀
40:27 关于个人应不应该做 side project
43:27 开源和 web3 进行结合 tea.xyz
58:32 tea 成为共识,主流的话,会极大的促进开源社区
1:01 本期总结
【未经授权,禁止转载】

播客信息

播客名称:硬地骇客

时长:22:00:00

来源:小宇宙播客

收起阅读 »

SkyRL:首个现实环境、长周期LLM Agent的端到端RL流水线框架

如今众多的AI Agent智能体正在超越静态基准,进入需要长期规划、多步骤工具使用和环境反馈的现实世界任务。此前大多数现有的RL强化学习框架都针对涉及短期无状态交互的任务进行了优化,例如搜索增强推理或简单的代码执行。相比之下,现实世界中的任务(例如 SWE-B...
继续阅读 »
图片如今众多的AI Agent智能体正在超越静态基准,进入需要长期规划、多步骤工具使用和环境反馈的现实世界任务。此前大多数现有的RL强化学习框架都针对涉及短期无状态交互的任务进行了优化,例如搜索增强推理或简单的代码执行。相比之下,现实世界中的任务(例如 SWE-Bench 中所示的任务)则受益于在有状态的动态环境中进行长期规划。这给基础设施和训练算法都带来了新的挑战。wechat_16ffc8df6ca0b63bb5579cb51308a85a.jpg在这种背景下,为了有效地训练这些Agent,我们推出了SkyRL,这是我们针对Multi-Turn多轮工具使用 LLM 的 RL 训练流程,它针对 SWE-Bench 等长期真实环境任务进行了优化,建立在VeRL和OpenHands之上。使用 SkyRL,我们能够使用大约 300 个训练数据样本,在各个模型线上的SWE-Bench-Verified上取得令人满意的结果!
  • SkyRL-Agent-7B-v0:11.0% → 14.6%

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

    图片

  • SkyRL-Agent-8B-v0:3.6% → 9.4%

  • SkyRL-Agent-14B-v0:18.0% → 21.6%

wechat_8af5fdb5bf17dd5de7213abffb1e497e.jpg图 1:SkyRL 构建于 VeRL 之上,继承了 VeRL 对学习算法的丰富支持。SkyRL 通过引入Agent层扩展了 VeRL,使其具备以下优势:(1) 高效的异步多Rollout;(2) 通用工具的使用;以及 (3) 通用且可扩展的环境执行。

概述

强化学习的最新进展使语言模型能够成为主动Agent。近期的开源框架,例如 Search-R1 和 ToRL(基于 VeRL 构建),在这方面取得了令人瞩目的进展,实现了多轮强化学习,并能够交叉使用单一工具(例如搜索或代码执行)。这些系统为工具增强推理奠定了重要的基础。然而,诸如 SWE-Bench、WebDev 和 Web 浏览等复杂的现实世界任务需要高级Agent能力,其中模型需要调用多个工具、编写和运行测试、响应环境反馈并执行长期规划。wechat_48ce942a9fa964a031e995cd26edf75c.jpg图 2:使用 CodeAct Agent 解决 SWE-Bench 问题的示例工作流程。

虽然这些更先进的Agent智能体标志着令人兴奋的进化,但在它们上运行在线强化学习却极具挑战性。首先,高效的训练框架需要快速的环境执行和高效的环境交互Rollout。其次,高效的训练需要强大的长周期算法(这不是本文的重点)。总而言之,这使得问题比训练先前的工具增强推理法学硕士(LLM)复杂得多。

为了填补这一空白,我们推出了SkyRL——我们的强化学习训练流水线,用于在复杂环境中执行多轮工具使用LLM的长周期任务,包括SWE-Bench,它基于VeRL和OpenHands构建

SkyRL 功能

- 支持训练执行具有复杂环境交互的多步骤计划的LLM智能体。

- 通过异步并行Rollout操作,在轨迹上重叠计算密集型阶段和环境交互密集型阶段,实现更高吞吐量的生成(比基线实现加速 4-5 倍)。

- 预填充(并扩展)强化学习算法,方便快速启动。

wechat_ac3e47ff54379a9b643e84d69f254805.jpg在 v0 版本中,我们支持 SWE-Bench 的端到端在线强化学习训练流程。接下来计划支持其他长周期任务,例如 WebArena 和 WebDev。本文章的其余部分将讨论我们在基础设施方面面临的挑战和经验教训,以及我们的初步模型结果。系统设计

在 SkyRL-v0 中,我们主要致力于解决环境扩展和低效Rollout阶段的挑战。我们集成了OpenHands项目中的CodeAct抽象作为Agent循环部分,并采用远程沙盒服务器实现可扩展的环境Rollout。

挑战 1:环境扩展 - 远程沙盒服务器

在许多实际的Agent训练任务中,例如 SWE-Bench,每次Rollout都必须在隔离且有状态的环境中运行,通常通过 Docker 容器进行配置。这些环境通常都是资源密集型,每个环境消耗1 个以上的 CPU 和约 7GB 的存储空间。即使是中等配置(例如,批次大小为 16,Rollout 8 次)也可能需要 100 多个 CPU 和接近 1TB 的磁盘空间。

将环境执行与训练共置会导致隔离受限,并且扩展并行运行环境数量的灵活性不足,这可能导致LLM 推理引擎的请求速率不足,最终导致GPU 资源利用率低下。为了解决这个问题,我们实现了一个可扩展的远程沙盒服务器将环境执行与训练分离。这种分离式设计支持独立扩展环境Worker,以保持较高的环境交互速率,从而确保在Rollout阶段实现较高的 GPU 利用率。

wechat_4f42131ded7a67c46a104a660518d776.jpg图 3:远程沙盒服务器的 Kubernetes Deployment。

我们将服务器部署在 Kubernetes 上,利用存储优化的实例来缓存容器镜像并实现快速启动。为了高效处理并发请求,我们利用aidocker和crun容器运行时,它提供轻量级且高性能的容器执行。我们的设置支持在 16 CPU 节点上每个副本运行大约 80-100 个容器,而不会遇到稳定性问题。虽然仍有很大的优化空间,但我们目前的实现简单、高效且公开可用。我们将服务器代码和Deployment配置开源,以支持有意自行托管强化学习训练所需的可扩展远程沙盒环境的研究人员。

挑战 2:费用昂贵的生成阶段

在基于Agent的强化学习训练中,Rollout阶段需要Agent与环境进行多轮交互。近期在多轮强化学习 (MDRL) 领域取得的进展,例如 RAGEN、Search-R1 和 ReTool,通常每个轨迹仅涉及有限数量的交互步骤。相比之下,像 SWE-bench 这样的任务通常需要 20 到 50 个轮次(甚至更多)才能让智能体使用 OpenHands 框架完成整个流程,这通常涉及识别相关文件、编写测试用例以重现问题、应用代码编辑以及通过测试验证修复。此外,每个步骤的环境执行时间在不同轨迹之间可能存在显著差异,具体取决于智能体操作的性质。例如,列出文件通常很快,而执行 Python 脚本进行单元测试则可能要耗费更多时间。

wechat_ae2c531b2a84e45ee05b9fc827aefa4e.jpg

图 4 不同 rollout 实现方式的可视化。我们的异步 Rollout + 3 阶段生产者-消费者流水线有效加速了 rollout 的生成。

如图 4 上半部分所示,单轮强化学习中常见的 rollout 实现(例如 VeRL和 OpenRLHF对于Agent式推理工作负载而言效率低下。这种低效源于每个 LLM 生成步骤的同步障碍,而同步障碍是由于依赖离线批量生成造成的。因此,系统无法利用现代 LLM 服务引擎支持的连续批量优化,导致资源利用率低下和吞吐量降低。

为了解决这个问题,我们采用了两项优化措施,与原始基线实现相比,总共实现了4-5 倍的加速

1. 异步Rollout – 依赖现代 LLM 服务引擎(例如SGLang和 vLLM)的 `async_generate` 方法,每条轨迹可以独立推进,从而避开全局同步点,如上图 4 中间部分所示。

2.三阶段生产者-消费者流水线 – 此外,为了减少 GPU 空闲时间,我们可以将 (i) 运行时初始化(例如构建镜像、启动和连接容器)、(ii) 轨迹生成和 (iii) 奖励计算(例如发送补丁、运行测试)这几个阶段解耦并重叠,以最大化并行性和系统吞吐量,如上图 4 底部所示。

  • a. 我们通过三个队列实现此流水线:`init queue`、`run queue` 和 `eval queue`。每个阶段都充当下一个阶段的生产者:`init queue`从`init_queue` 中拉取数据,准备环境,然后推送至 `run_queue`;Agent Runner从 `run_queue` 中拉取已初始化的实例,执行多轮Rollout,并将完成的轨迹推送至 `eval_queue`;然后,`eval queue`从 `eval_queue` 中拉取数据来计算最终奖励。

  • b. 我们使用 `asyncio` 任务,并根据队列占用情况和剩余工作动态生成任务。每个任务都异步地将其结果推送至下一阶段,使用有Bounded的队列可以提供自然的反压机制(back-pressure),防止过载并确保跨阶段的负载平衡。这种流水线执行通过将计算和环境交互密集型阶段重叠在许多轨迹上,显著提高了系统吞吐量

早期训练探索

我们采用Openhands中的CodeAct 框架和OpenHands 脚手架来生成 rollout,并利用基于规则的奖励来执行策略更新。

Rollout 生成

我们利用 OpenHands 脚手架在软件工程任务环境中迭代地提示模型。在每个回合中,模型都会编写代码并执行函数调用作为操作。该模型提供三种类型的操作:(1) `execute_bash`:在终端中执行 bash 命令;(2) `finish`:在任务完成或助手无法继续执行任务时结束交互;(3) `str_replace_editor`:用于查看、创建和编辑文件的自定义编辑工具。

具体来说,Rollout操作通过以下流程生成:

Input: Model M, Environment E, Task description P, a set of available actions A. # OpenHands manage the history of interaction, # initialized with the task description.history = P 
while not done:    # The CodeAct framework prompt the model with the history and     # the available tool. The model generates an action in the form    # of execuatble code, e.g., view_file(file_path).    action = M(history, A)    # The action is then sent to the environment for execution    # and gets an environment observation.    # e.g. the content of a view_file action.    # The loop terminates if the action is a termination action.     done, observation = E(action)    # OpenHands then tracks the history by appending the action    # and the observation in this turn.    history.append(action)    history.append(observation)
# Returns a git patch written by the model in the history of interactionpatch = E.get_patch()return patch

奖励设计

我们使用一种简单的基于结果的奖励机制。在Agent完成交互后,我们会从环境中获取 Git 补丁。然后,我们将该补丁应用到原始代码库,并针对目标 GitHub 问题运行测试套件。如果测试通过且问题得到解决,我们将奖励 1;否则,奖励为 0。尽管简单,但这种信号有效地指导了模型,从而提高了问题解决率(参见结果部分)。我们还跟踪了两种常见的故障模式

- 陷入循环:模型连续三轮重复相同的操作。

- 未完成操作:模型未能在规定的轮次预算内输出完成操作。

我们的实验表明,这种奖励方案可以减少循环并鼓励及时完成。我们目前正在探索更丰富的多轮强化学习奖励设计

wechat_779de0d08fd974841541bbf57872b9b1.jpgwechat_258447a9b90cbb0213375b5608dffd29.jpg

数据选择

我们从SWE-Gym中选择问题,该数据集包含 2,438 个真实的 Python 任务实例。然而,这些任务极具挑战性——即使是 GPT-4o 的成功率也只有 4.55% 到 9.13%(详情请参阅 SWE-Gym 论文中的表 10)。因此,性能较弱的模型(例如 70 亿规模的模型)通常无法完成一次成功的Rollout,导致在 GRPO 和 PPO 等算法下没有学习信号,训练崩溃。为了缓解这个问题,我们构建了三个经过筛选的数据子集,并以模型生成成功率作为选择标准:

wechat_cd2590f1dfd9c341f50e5ae831ba0b3f.jpg

方案与结果

在此版本中,我们开源了三个不同规模、使用不同算法训练的模型,以满足社区的需求:

  • SkyRL-Agent-7B-v0(基于 OpenHands-7B-Agent 训练,基础模型 Qwen2.5-Coder-7B-Instruct)、

  • SkyRL-Agent-8B-v0(基于 Qwen3-8B 训练,非推理模式)

  •  SkyRL-Agent-14B-v0(基于 Qwen3-14B 训练,推理模式)。

评估设置

我们使用 OpenHands 脚手架和 CodeAct Agent 评估我们的模型,并使用相同的操作集:bash_execute、finish 和 str_replace_editor。我们在 SWE-Bench Verified 基准上进行评估,最大轮次预算为 50,最大序列长度为 32k。评估说明可在以下位置找到:

[SkyRL-OpenHands](https://github.com/NovaSky-AI/SkyGym-OpenHands/tree/main/evaluation/benchmarks/swe_bench)

- SkyRL-Agent-7B-v0

SkyRL-Agent-7B-v0基于OpenHands-7B-Agent模型进行训练,该模型是 Qwen2.5-Coder-Instruct模型的监督微调版本。我们采用基于结果的强化学习,分两阶段进行训练,批次大小为 16,每个实例 8 次 rollout。训练时,学习率为 1e-6,KL 系数为 1e-3,rollout 温度为 0.5,最大轮次为 25 次,并采用 GRPO 算法。

- 使用 SkyRL-v0-80-data 进行 15 步训练(3 个 epoch,在 8xH100 GPU 上耗时 7 小时)

- 使用 SkyRL-v0-220-data 进行 15 步训练(1 个 epoch,在 8xH100 GPU 上耗时 8.5 小时)

我们按照 SWE-Gym 论文中的建议,将训练温度设为 0,并与基线一起对模型进行了测量。我们发现,在 8xH100 GPU 上训练 15.5 小时后。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了 3.6%

wechat_49399842eb93cac6f8681a35d6e3a289.jpgwechat_e6af305180e1cdb9ceac257941165f77.jpg

- SkyRL-Agent-8B-v0(非思考模式)

SkyRL-Agent-8B-v0 在 Qwen3-8B 上进行训练,未启用思考模式(通过在`apply_chat_template` 中设置 `enable_thinking=False`)。我们使用一个基于结果的强化学习阶段进行训练,批次大小为 32,每个实例的 rollout 数量为 8。训练时学习率为 1e-6,KL 系数为 1e-3,rollout 温度为 0.6。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了5.8%

- 使用 SWEGym-293-data 进行 47 步训练(4.7 个 epoch,在 8xH200 上训练 27 小时)。

wechat_8f730ace861f1f63b844723d3aa6d098.jpgwechat_64b7ac3480fe808be3cdc8a2dbeec151.jpg

- SkyRL-Agent-14B-v0(思考模式)

使用思考模式进行多轮训练很容易超出上下文长度,尤其是对于较小的模型,它们更容易陷入推理阶段。因此,对于思考模式,我们尝试使用 Qwen3-14B作为基础模型。

SkyRL-Agent-14B-v0 在 Qwen3-14B的基础上使用 PPO 进行训练。我们采用基于结果的强化学习进行单阶段训练,批次大小为 32,每个实例的 rollout 为 8。我们训练时,学习率为 1e-6,KL 系数为 1e-3,rollout 温度为 0.6,裁剪提升率 (clip higher ratio) 为 0.28,以鼓励探索。我们使用Qwen3-14B本身作为基础评价模型。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了3.1%

- 使用 SkyRL-v0-293-data 进行 25 步训练(2.7 个 epoch,在 8xH200 GPU 上耗时 20 小时)。

wechat_21bba0469d1d17ae42d1ed68675816b6.jpgwechat_dfed225d56534659343e3a3c09720b2f.jpg


展望未来:构建社区平台


SkyRL 尚处于早期阶段,但其构建着眼于长远目标:


1. 多环境支持:超越 SWE-Bench——可扩展至各种长周期智能体任务。

2. 可扩展性:轻松集成新环境、智能体、工具、奖励函数和任务。

3. 高效性:高效的生成和优化的执行流水线,最大限度地减少缓慢环境带来的开销。


SkyRL 是迈向高效长远智能体强化学习训练的一步。我们诚邀社区成员试用并与我们共同构建!


文链接:https://novasky-ai.notion.site/skyrl-v0图片图片 收起阅读 »

强化学习之父携手DeepMind发布论文:欢迎来到经验时代

如何从依赖人类数据的时代迈向人工智能自主学习的时代?为了解决这个问题,刚获得图灵奖的强化学习之父Richard S. Sutton携手DeepMind发布了一篇重量级的论文。这标志着 DeepMind 的人工智能系统从人类数据训练转向类似 AlphaGo 的自...
继续阅读 »
图片如何从依赖人类数据的时代迈向人工智能自主学习的时代?为了解决这个问题,刚获得图灵奖的强化学习之父Richard S. Sutton携手DeepMind发布了一篇重量级的论文。这标志着 DeepMind 的人工智能系统从人类数据训练转向类似 AlphaGo 的自主学习和探索型智能体。这与 OpenAI 的 LLM 人工智能发展路径截然不同,以下是论文Welcome to the Era of Experience》完整的译文,Enjoy。wechat_644154d9af899ae8b58f90ff8253a61c.jpg

人类数据时代

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

近年来,人工智能通过对大量人类生成的数据进行训练,并使用专业的人类示例和偏好进行微调,取得了长足的进步。这种方法以大型语言模型LLMs 为例,这些模型已经达到了广泛的通用性。现在,一个单独的LLM可以执行从写诗和解决物理问题到诊断医疗问题和总结法律文件的任务。

然而,虽然模仿人类足以将许多人类能力复制到称职的水平,但这种孤立的方法没有而且可能无法在许多重要主题和任务中实现超级智能。在数学、编码和科学等关键领域,从人类数据中提取的知识正在迅速接近极限。大多数高质量的数据源(那些实际上可以提高强大AI智能体性能的数据源)已经被使用,或者很快就会被使用。仅由从人类数据中监督学习驱动的进步速度明显放缓,这表明需要一种新方法。此外,有价值的新见解,例如新定理、技术或科学突破,超出了当前人类理解的界限,无法通过现有的人类数据来捕获

经验时代

为了取得重大进展,需要新的数据源。这些数据的生成方式必须随着Agent变得更强大而不断改进;任何用于综合生成数据的静态过程都会很快被超越。这可以通过允许Agent不断从自己的经验中学习来实现,即Agent与其环境交互生成的数据。AI 正处于一个新时期的风口浪尖,在这个时期,经验将成为改进的主要媒介,并最终使当今系统中使用的人类数据规模相形见绌。

这种转变可能已经开始,即使对于以人为中心的 AI 的大型语言模型也是如此。一个例子是数学的能力。AlphaProof最近成为第一个在国际数学奥林匹克竞赛中获得奖牌的项目,超过了以人为本的方法(DeepMind 的 AlphaProof 无需人工数据即可进行训练能够为任何给定问题生成数学证明。它先形成自己的内部“语言”,然后翻译成人类可读的语言——整个过程完全没有幻觉)。最初接触到大约 10 万个形式证明,这些证明是多年由人类数学家研究来创建的,AlphaProof 的强化学习(RL)算法随后通过与正式证明系统的持续交互产生了 1 亿个。这种对交互式经验的关注使 AlphaProof 能够探索超越现有形式证明范围的数学可能性,从而发现新颖和具有挑战性的问题的解决方案。非正式数学也通过用自生成数据替换专家生成的数据而取得了成功;例如,DeepSeek 最近的工作“强调了强化学习的力量和美感:我们不是明确地教模型如何解决问题,而是简单地为它提供正确的激励措施,它就会自主开发先进的问题解决策略

wechat_ef530ec722050d4c5533ed90a6cdd591.jpg

AlphaProof 强化学习训练循环流程图:大约一百万个非正式数学问题通过形式化网络被翻译成正式的数学语言。然后,求解器网络搜索这些问题的证明或反证,并通过 AlphaZero 算法逐步训练自身,以解决更具挑战性的问题。

我们的论点是,一旦经验式学习的全部潜力得到利用,就会出现令人难以置信的新功能。这个经验时代的特点可能Agent和环境,除了从大量经验数据中学习外,还将在几个其他维度上突破以人为中心的 AI 系统的局限性:

• Agent将居住在经验流中,而不是简短的互动片段中。

• 他们的行动和观察将以环境为基础,而不是仅仅通过人类对话进行互动。

• 他们的回报将基于他们对环境的经验,而不是来自人类的预判。

• 他们将计划和/或推理经验,而不是仅仅用人类的语言进行推理

我们相信,今天的技术,通过适当选择的算法,已经为实现这些突破提供了足够强大的基础。此外,AI 社区对这一议程的追求将刺激这些方向的新创新,从而迅速将 AI 发展为真正的超级智能体

Streams

经验式Agent可以在一生中继续学习。在人类数据时代,基于语言的 AI 主要集中在简短的交互事件上:例如,用户提出一个问题,然后(可能在几个思考步骤或工具使用作之后)Agent做出回应。通常,很少或没有信息从一集延续到下一集,从而排除了随着时间的推移进行任何改编的可能性。此外,Agent仅针对当前剧集中的结果,例如直接回答用户的问题。相比之下,人类(和其他动物)存在于持续多年的持续行动和观察流中。信息贯穿整个流程,他们的行为会根据过去的经验进行调整,以自我纠正和改进。此外,目标可以根据延伸到流未来的行动和观察来指定。例如,人类可能会选择行动来实现长期目标,例如改善健康状况、学习语言或实现科学突破。

强大的Agent应该有自己的经验流,就像人类一样,在很长的时间尺度上不断进步。这将使Agent能够采取行动来实现未来的目标,并随着时间的推移不断适应新的行为模式。例如,连接到用户可穿戴设备的健康和保健Agent可以监测数月的睡眠模式、活动水平和饮食习惯。然后,它可以提供个性化的推荐、鼓励,并根据长期趋势和用户的具体健康目标调整其指导。同样,个性化教育Agent可以跟踪用户的学习进度学习一门新语言,识别知识差距,适应他们的学习风格,并在数月甚至数年内调整其教学方法。此外,科学Agent可以追求雄心勃勃的目标,例如发现新材料或减少二氧化碳。这样的Agent可以分析较长时间的真实世界观察,开发和运行模拟,并提出真实世界的实验或干预建议。

在每种情况下,Agent都会采取一系列步骤,以便在指定目标方面取得最大的长期成功。单个步骤可能不会带来任何直接的好处,甚至可能在短期内有害,但仍然可能为长期成功做出贡献。这与当前的 AI 系统形成鲜明对比,后者对请求提供即时响应,而没有任何能力衡量或优化其行为对环境的未来影响。

动作和观察

经验时代的Agent将在现实世界中自主行动。人类数据时代的大语言模型(LLM)主要关注人类特权级的动作和观察,即向用户输出文本,并将用户的文本输入到Agent智能体中。这与自然智能截然不同,在自然智能中,动物通过运动控制和传感器与环境互动。虽然动物,尤其是人类,可以与其他动物交流,但这种交流是通过与其他感觉运动控制相同的接口进行的,而不是通过特权通道发生的。

人们早已认识到,LLM 也可以调用数字世界中的操作,例如通过调用 API。最初,这些能力主要源于人类使用工具的示例,而非智能体的经验。然而,编码和工具使用能力越来越多地建立在执行反馈的基础上,其中智能体实际运行代码并观察发生的情况。最近,新一波原型智能体开始以更通用的方式与计算机交互,使用与人类操作计算机相同的界面。这些变化预示着从纯粹人类特权的通信向更加自主的交互的转变,在这种交互中,智能体能够在世界中独立行动。这样的智能体将能够主动探索世界,适应不断变化的环境,并发现人类可能从未想过的策略。

这些更丰富的交互将提供一种自主理解和控制数字世界的方法。Agent智能体可以使用“人性化”的操作和观察,例如用户界面,从而自然地促进与用户的沟通和协作。Agent智能体还可以采取“机器友好”的操作,例如执行代码和调用API,从而使Agent智能体能够自主地实现其目标。在体验时代,Agent智能体还将通过数字界面与现实世界进行交互。例如,科学Agent智能体可以监控环境传感器、远程操作望远镜或控制实验室中的机械臂以自主进行实验。

奖励

如果经验Agent可以从外部事件和信号中学习,而不仅仅是人类的偏好,那会怎样?以人为本的LLMs通常根据人类的预先判断来优化奖励:专家观察Agent的行为并决定它是一个好的行动,还是在多个备选方案中选择最好的Agent行动。例如,专家可能会评判健康Agent智能体的建议、教育助理的教学或科学家Agent建议的实验。事实上,这些奖励或偏好是由人类决定的,而没有其后果,而不是衡量这些行为对环境的影响,这意味着它们并不直接基于世界的现实。以这种方式依赖人类的预判通常会导致Agent的表现出现一个不可逾越的天花板:Agent无法发现更好的策略,而这些策略被人类评估者低估了。为了发现远远超出现有人类知识的新想法,有必要使用接地气的奖励(Grounded rewards):来自环境本身的信号。例如,健康助手可以将用户的健康目标转化为基于以下

为了发现远远超出现有人类知识信号(例如静息心率、睡眠时长和活动水平)的新想法,而教育助理可以使用考试结果为语言学习提供扎实的奖励。同样,以减少全球变暖为目标的科学主体可能会使用基于二氧化碳水平的经验观察的奖励,而发现更坚固材料的目标可能基于材料模拟器的测量结果的组合,例如拉伸强度或杨氏模量。

接地奖励(Grounded rewards)可能来自属于人类(Agent环境的一部分)。例如,人类用户可以报告他们是否觉得蛋糕好吃、运动后的疲劳程度或头痛的疼痛程度,从而使助理Agent能够提供更好的食谱、改进其健身建议或改进其推荐的药物。这种奖励衡量了Agent在其环境中的行为的后果,并且最终应该比预先判断拟议的蛋糕食谱、锻炼计划或治疗计划的人类专家提供更好的帮助。

如果不来自人类数据,奖励从何而来?一旦Agent通过丰富的行动和观察空间(见上文)与世界建立联系,就不会缺少接地信号来提供奖励的基础。事实上,世界上有很多数量,例如成本、错误率、饥饿、生产力、健康指标、气候指标、利润、销售额、考试结果、成功、访问、产量、股票、喜欢、收入、快乐/痛苦、经济指标、准确性、力量、距离、速度、效率或能源消耗。此外,还有无数来自特定事件发生的额外信号,或来自观察和行动的原始序列的特征。

原则上,可以创建各种不同的Agent,每个Agent都针对一个接地信号(grounded signals)进行优化作为其奖励。有一种观点认为,即使是单个这样的奖励信号,经过优化并非常有效,也可能足以诱导具有广泛能力的智力。这是因为在复杂的环境中实现一个简单的目标往往需要掌握各种各样的技能。

然而,从表面上看,追求单一的奖励信号似乎并不能满足通用 AI 的要求,因为通用 AI 可以可靠地引导到任意的用户期望行为。因此,接地的非人类奖励信号的自主优化是否与现代 AI 系统的要求相悖?我们认为情况不一定如此,通过勾勒出一种可能满足这些要求的方法;其他方法也可能是存在的。

这个想法是根据接地信号以用户引导的方式灵活地调整奖励。例如,奖励函数可以由神经网络定义,该神经网络将Agent与用户和环境的交互作为输入,并输出标量奖励。这允许奖励以取决于用户目标的方式选择或组合来自环境的信号。例如,用户可能会指定一个广泛的目标,例如“改善我的健康状况”,而 reward 函数可能会返回用户的心率、睡眠持续时间和所走步数的函数。或者,用户可能指定 'help me learn Spanish' 的目标,reward 函数可以返回用户的西班牙语考试结果。

此外,用户可以在学习过程中提供反馈,例如他们的满意度,这些反馈可用于微调奖励功能。然后,奖励函数可以随着时间的推移进行调整,以改进它选择或组合信号的方式,并识别和纠正任何错位。这也可以理解为一个双级优化过程,将优化用户反馈作为最高目标,并在低级优化来自环境的接地信号。通过这种方式,少量的人类数据可以促进大量的自主学习。

规划和推理

经验时代会改变Agent人计划和推理的方式吗?最近,在输出响应之前遵循一条思维链,使用LLMs语言进行推理或“思考”的使用取得了重大进展。从概念上讲,LLMs可以充当通用计算机:可以将LLM令牌附加到自己的上下文中,允许它在输出最终结果之前执行任意算法。

在人类数据时代,这些推理方法被明确设计为模仿人类的思维过程。例如,LLMs已经被提示发出类似人类的思维链,模仿人类思维的痕迹,或加强与人类例子相匹配的思维步骤。推理过程可以进一步微调,以产生与人类专家确定的正确答案相匹配的思维轨迹。

但是,人类语言不太可能成为通用计算机的最佳实例。更高效的思维机制肯定存在,例如使用非人类语言,例如利用符号计算、分布式计算、连续计算或可微计算。原则上,自学习系统可以通过学习如何从经验中思考来发现或改进这些方法。例如,AlphaProof 学会了以与人类数学家截然不同的方式正式证明复杂的定理。

此外,通用计算机的原理只涉及Agent的内部计算;它没有将其与外部世界的现实联系起来。受过训练模仿人类思想甚至匹配人类专家答案的Agent可能会继承深深嵌入该数据中的谬误思维方法,例如有缺陷的假设或固有的偏见。例如,如果一个Agent人接受过训练,能够使用 5000 年前的人类思想和专家答案进行推理,那么它可能会从万物有灵论的角度来推理物理问题;1000 年前,它可能用有神论的术语进行推理;300 年前,它可能是根据牛顿力学进行推理的;以及 50 年前的量子力学。超越每种思维方法都需要与现实世界互动:提出假设、进行实验、观察结果并相应地更新原则。同样,Agent必须以现实世界的数据为基础,才能推翻谬误的思维方法。这种基础提供了一个反馈循环,允许Agent将其继承的假设与现实进行对比,并发现不受当前主导人类思维模式限制的新原则。没有这个基础,一个Agent,无论多么复杂,都会成为现有人类知识的回音室。为了超越这一点,Agent人必须积极与世界互动,收集观测数据,并使用这些数据迭代地完善他们的理解,以多种方式反映推动人类科学进步的过程。

将思维直接建立在外部世界基础上的一种可能方法是构建一个世界模型 ,该模型预测Agent的行为对世界的后果,包括预测奖励。例如,健康助理可能会考虑为当地的健身房或健康播客提供推荐。Agent的世界模型可以预测此作后用户的心率或睡眠模式随后可能如何变化,以及预测将来与用户的对话。这允许主体直接根据自己的行为及其对世界的因果影响来规划。随着Agent在其整个经验流中继续与世界交互,其动力学模型会不断更新以纠正其预测中的任何错误。给定一个世界模型,Agent可以应用可扩展的规划方法来提高Agent的预测性能。

规划和推理方法并不相互排斥:Agent可以应用内部LLM计算来选择规划期间的每个作,或者模拟和评估这些作的后果。

为什么是现在?

从经验中学习并不是什么新鲜事。强化学习系统以前已经掌握了大量复杂的任务,这些任务在模拟器中表示,并具有明确的奖励信号(参见下图 1 中的“模拟时代”)。众所周知,RL 方法等于或超过人类性能。

wechat_981994ba76a1b6f0a2edc263195f60bf.jpg

图 1:占主导地位的 AI 范式的草图年表。y 轴表示该领域专注于 RL 的总工作量和计算的比例。

举个例子,通过在棋盘游戏(如西洋双陆棋、围棋、国际象棋、扑克和 Stratego)中的自我对弈;在视频游戏(如雅达利、星际争霸 II、Dota 2 和 Gran Turismo)中;在灵巧操作任务(如魔方)中;以及资源管理任务(如数据中心冷却)中。此外,强大的强化学习代理(如 AlphaZero)在神经网络规模、交互体验数量和思考时间持续时间方面表现出令人印象深刻且潜在的无限可扩展性。然而,基于这种范式的代理并没有跨越模拟(具有单一、精确定义的奖励的封闭问题)与现实(具有多个看似定义不明确的奖励的开放式问题)之间的差距。

人类数据时代提供了一个有吸引力的解决方案。大量的人类数据语料库包含用于各种任务的自然语言示例。与模拟时代更狭隘的成功相比,根据这些数据训练的Agent获得了广泛的能力。因此,经验式 RL 的方法在很大程度上被抛弃,取而代之的是更通用的Agent,导致向以人为中心的 AI 的广泛过渡。

然而,在这个转变中丢失了一些东西:Agent自我发现自身知识的能力。例如,AlphaZero 从根本上发现了国际象棋和围棋的新策略,改变了人类下这些游戏的方式。经验时代将使这种能力与人类数据时代所达到的任务通用性水平相协调。如上所述,当Agent能够在现实世界的经验流中自主行动和观察时,并且奖励可以灵活地连接到大量接地的现实世界信号中,这将成为可能。与复杂的现实世界动作空间交互的自主Agent的出现,以及可以在丰富的推理空间中解决开放式问题的强大 RL 方法表明向经验时代的过渡迫在眉睫

强化学习方法

强化学习 (RL) 有着悠久的历史,深深植根于自主学习,即Agent通过与环境的直接交互进行自我学习。早期的 RL 研究催生了一系列强大的概念和算法。例如,时间差分学习使Agent能够估计未来的奖励,从而取得了一些突破,例如在西洋双陆棋中取得了超越人类的表现。由乐观或好奇心驱动的探索技术被开发出来,旨在帮助Agent发现创造性的新行为,并避免陷入次优的Routines。像 Dyna 算法这样的方法使代理能够构建和学习其所处世界的模型,从而使它们能够规划和推理未来的行动。诸如选项\选项内/选项间学习之类的概念促进了时间抽象,使Agent能够在更长的时间尺度上进行推理,并将复杂任务分解为可管理的子目标。

然而,以人为本LLMs的兴起将重点从自主学习转移到利用人类知识。事实证明,RLHF(来自人类反馈的强化学习)等技术和使语言模型与人类推理保持一致的方法非常有效,推动了 AI 能力的快速发展。这些方法虽然强大,但经常绕过核心 RL 概念:RLHF 通过调用人类专家代替机器估计的值来回避对值函数的需求,来自人类数据的强大先验概率减少了对探索的依赖,以人类为中心的推理减少了对世界模型和时间抽象的需求

然而,可以说范式的转变已经把婴儿和洗澡水一起扔掉了。虽然以人为中心的 RL 实现了前所未有的行为广度,但它也对Agent的性能施加了新的上限:Agent无法超越现有的人类知识。此外,人类数据时代主要集中在 RL 方法上,这些方法专为短时间的无基础人工交互而设计,不适合长时间的无基础自主交互。

经验时代为重新审视和改进经典 RL 概念提供了机会。这个时代将带来新的方法来思考灵活基于观察数据的奖励函数。它将重新审视值函数和方法,以从具有尚未完成序列的长流中估计它们。它将为现实世界的探索带来有原则但实用的方法,发现与人类先验截然不同的新行为。将开发世界模型的新方法,以捕捉扎根交互的复杂性。时间抽象的新方法将允许Agent在越来越长的时间范围内根据经验进行推理。通过建立在 RL 的基础上并调整其核心原则来应对这个新时代的挑战,我们可以释放自主学习的全部潜力,并为真正的超级智能铺平道路

结果

经验时代的到来,AI Agent从他们与世界的互动中学习,预示着一个与我们以前见过的截然不同的未来。这种新范式虽然具有巨大的潜力,但也存在需要仔细考虑的重要风险和挑战,包括但不限于以下几点。

从积极的一面来看,经验式学习将解锁前所未有的能力。在日常生活中,个性化助手将利用源源不断的经验来适应个人的健康、教育或专业需求,从而在数月或数年内实现长期目标。也许最具变革性的将是科学发现的加速。AI Agent将自主设计和进行材料科学、医学或硬件设计等领域的实验。通过不断从自己的实验结果中学习,这些Agent可以迅速探索新的知识前沿,从而以前所未有的速度开发新型材料、药物和技术。

然而,这个新时代也带来了重大而新颖的挑战。虽然人工的自动化能力有望提高生产力,但这些改进也可能导致工作岗位流失。Agent甚至可能能够展示以前被认为是人类专属领域的能力,例如长期解决问题、创新和对现实世界后果的深刻理解。

此外,虽然人们普遍担心任何 AI 可能被滥用,但能够长时间自主与世界交互以实现长期目标的Agent可能会带来更高的风险。默认情况下,这为人类干预和调解Agent行为的机会较少,因此需要很高的信任和责任感。远离人类数据和人类思维模式也可能使未来的 AI 系统更难解释。

然而,在承认经验式学习会增加一定的安全风险,并且肯定需要进一步的研究以确保安全过渡到经验时代的同时,我们也应该认识到它也可能提供一些重要的安全好处。

首先,经验主体意识到它所处的环境,并且它的行为可以随着时间的推移适应该环境的变化。任何预编程系统,包括固定的 AI 系统,都可能不知道其环境背景,并且无法适应其部署的不断变化的世界。例如,关键硬件可能会发生故障,大流行可能会导致快速的社会变化,或者新的科学发现可能会引发一连串的快速技术发展。相比之下,经验Agent可以观察并学习规避出现故障的硬件,适应快速的社会变化,或接受和建立新的科学和技术。也许更重要的是,Agent可以识别其行为何时引发人类的关注、不满或痛苦,并适应性地修改其行为以避免这些负面后果。

其次,Agent的奖励功能本身可以通过经验进行调整,例如使用前面描述的双层优化(参见 奖励)。重要的是,这意味着错位的奖励函数通常可以随着时间的推移通过反复试验逐步纠正。例如,与其盲目地优化信号,例如Paperclips回形针的最大化,不如在回形针生产消耗地球所有资源之前,根据人类关注的迹象来修改奖励函数。这类似于人类为彼此设定目标的方式,如果他们观察到人们玩弄系统、忽视长期福祉或造成不希望的负面后果,然后调整这些目标;虽然也像人类的目标设定一样,但不能保证完美对齐。

最后,依赖于物理经验的进步本质上受到在现实世界中执行作并观察其后果所花费的时间的限制。例如,即使采用 AI 辅助设计,新药的开发仍然需要真实世界的试验,而这些试验不可能在一夜之间完成。这可能会自然地阻止 AI 潜在的自我提升步伐。

结论

经验时代标志着 AI 发展的关键时刻。建立在当今强大的基础之上,但超越了人类衍生数据的限制,Agent将越来越多地从他们自己与世界的互动中学习。Agent将通过丰富的观察和作自主地与环境交互。他们将在终生的经验过程中继续适应。他们的目标将指向接地信号的任意组合。此外,Agent将利用强大的非人类推理,并构建基于Agent行为对其环境的后果的计划。最终,经验数据将使人类生成数据的规模和质量黯然失色。这种范式转变,伴随着 RL 的算法进步,将在许多领域解锁超越任何人所拥有的新功能

原文链接:

https://storage.googleapis.com/deepmind-media/Era-of-Experience%20/The%20Era%20of%20Experience%20Paper.pdf

图片图片 收起阅读 »

伯克利论文:Multi-Agent多智能体系统为什么会失败?

多智能体大语言模型(Multi-Agent LLM)系统会失败?最近,伯克利大学发表了一篇重磅论文《Why Do Multi-Agent LLM Systems Fail?》,深入剖析了MAS系统的失败原因,整理出14种具体失败模式,并提出了相应改进建议。以下...
继续阅读 »
图片
多智能体大语言模型(Multi-Agent LLM)系统会失败?最近,伯克利大学发表了一篇重磅论文《Why Do Multi-Agent LLM Systems Fail?》,深入剖析了MAS系统的失败原因,整理出14种具体失败模式,并提出了相应改进建议。
以下是该论文译文,Enjoy。
简介

尽管人们对多智能体系统 (MAS) 的热情日益高涨,其中多个 LLM 智能体协作完成任务,但与单智能体框架相比,它们在流行基准上的性能提升仍然微乎其微。这一差距凸显了分析阻碍 MAS 有效性的挑战的必要性。

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

图片

在本文中,我们首次全面研究了 MAS 挑战。我们分析了五种流行的 MAS 框架,涉及 150 多个任务,涉及六位专家人工Annotator。我们确定了 14 种独特的故障模式,并提出了适用于各种 MAS 框架的综合分类法。该分类法从每项研究中三位专家Annotator之间的一致意见中迭代出现,Cohen's Kappa 得分为 0.88。这些细粒度的故障模式分为 3 类:(i) 规范和系统设计故障,(ii) 代理间错位,以及 (iii) 任务验证和终止。为了支持可扩展评估,我们将 MASFT 与 LLM-as-a-Judge 集成在一起。我们还探讨了是否可以通过提出两种干预措施轻松预防已识别的故障:改进代理角色的规范和增强编排策略。我们的研究结果表明,已识别的故障需要更复杂的解决方案,这为未来的研究指明了明确的路线图。我们开源了我们的数据集和 LLM解释器。 

wechat_2c7939c204849e5e93c47de0e67c2d92.jpg 

“成功的系统都是一样的,失败的系统都有自己的问题。”(伯克利,2025)


 


 

wechat_b8af4f99fa2fedcfca2f53058f23f8a1.jpg  


最近,基于大型语言模型 (LLM) 的代理系统在人工智能社区中引起了广泛关注。这种日益增长的兴趣源于代理系统能够处理复杂的多步骤任务,同时与不同的环境进行动态交互,这使得基于 LLM 的代理系统非常适合解决现实世界的问题,基于这一特点,多智能体系统在软件工程等各个领域得到了越来越多的探索,比如药物发现、科学模拟,以及最近的通用剂。wechat_1d74a6f40dc861d757a54d51dbb0cdab.jpg图 1:五种流行的多智能体 LLM 系统与 GPT-4o 和 Claude-3 的失败率。在本研究中,我们将基于 LLM 的代理定义为具有提示规范(初始状态)、对话跟踪(状态)和与环境(例如工具使用情况(操作))交互的能力的人工实体。然后将多代理系统MAS ) 定义为旨在通过编排进行交互的代理集合,从而实现集体智慧。MAS 的结构旨在协调努力,实现任务分解、性能并行化、上下文隔离、专门的模型集成和多样化的推理讨论。wechat_bbef8b15a6bca177be35a30556d4acf9.jpg图 2:MAS 故障模式分类。尽管 MAS 的采用率不断提高,但与单智能体框架或简单基线(例如流行基准测试中的最佳 N 采样)相比,其准确性或性能的提升仍然微乎其微。我们的实证分析表明,最先进的 (SOTA) 开源 MAS ChatDev的正确性可能低至 25%,如图 1 所示。此外,对于如何构建稳健可靠的 MAS,目前还没有明确的共识。这引出了一个我们首先需要回答的基本问题:MAS 为什么会失败?


为了了解 MAS 故障模式,我们使用GT理论 (Glaser & Strauss, 1967) 对 MAS 执行轨迹进行了首次系统评估。我们分析了五种流行的开源 MAS,雇用了六位专家Annotator来识别 150 条对话轨迹中的细粒度问题,每条轨迹平均超过 15,000 行文本。我们将故障定义为 MAS 未实现预期任务目标的情况。为了确保故障模式和定义的一致性,三位专家Annotator独立标记了 15 条轨迹,实现了Annotator间一致性,Cohen’s Kappa 分数为 0.88。通过这项综合分析,我们确定了 14 种不同的故障模式,并将它们聚类为 3 个主要故障类别。我们引入了多智能体系统故障分类法 (MASFT),这是 MAS 的第一个结构化故障分类法,如图 2 所示。我们并不声称 MASFT 涵盖了所有潜在的故障模式;相反,它是分类和理解 MAS 失败的第一步。


为了实现可扩展的自动评估,我们引入了使用 OpenAI 的 o1 的 LLM-as-a-judge 流程。为了验证此流程,我们在 10 条轨迹上将其Annotator与三位人类专家Annotator进行交叉验证,最终获得 0.77 的 Cohen's Kappa 一致性率。

直观地看,更好的规范和提示策略可能会缓解 MAS 故障。为了检验这一假设,我们使用提示工程和增强的代理拓扑编排实施了干预措施。我们对 AG2 的案例研究和 ChatDev表明,尽管这些干预措施为 ChatDev 带来了 +14% 的改进,但它们并不能解决所有故障情况。此外,改进后的性能对于实际部署来说仍然不够好。

这些发现表明,MASFT不仅仅是现有多智能体框架的产物,而是 MAS 中存在根本设计缺陷的体现。为了构建强大而可靠的 MAS,MASFT可作为指导未来研究的框架,概述 14 种故障模式中每一种的潜在解决方案。此外,我们还开源了我们的Annotator,以供 MAS 的进一步研究。

虽然人们可以简单地将这些失败归咎于当今 LLM 的局限性(例如幻觉、错位),但我们推测基础模型能力的改进不足以解决完整的 MASFT。相反,我们认为良好的 MAS 设计需要组织理解——如果组织结构存在缺陷,即使是由经验丰富的个人组成的组织也可能灾难性地失败

先前对高可靠性组织的研究表明,明确的设计原则可以防止此类故障。与这些理论一致,我们的研究结果表明,许多 MAS 故障源于代理间交互中的挑战,而不是单个代理的局限性。MASFT 能够系统地识别这些故障,并为下一代 MAS 的设计原则提供信息

本文的贡献如下:

  • 我们引入了MASFT,这是第一个基于经验的MAS 故障分类法,为理解和减轻 MAS 故障提供了一个结构化框架。

  • 我们开发了一个可扩展的 LLM-as-a-judge评估流程,用于分析新的 MAS 性能和诊断故障模式。

  • 我们针对代理规范、对话管理和验证策略开展了尽力干预研究。尽管任务完成率提高了 14%,但它们未能完全解决 MAS 故障,凸显了结构性 MAS 重新设计的必要性。

  • 我们完全开源:(1)所有 150 多个带Annotator的 MAS 对话轨迹、(2)可扩展的 LLM-as-a-judge 评估流程和 150 多个轨迹上的 LLM Annotator,以及(3)15 个选定轨迹上的详细专家Annotator。


2相关工作

2.1代理系统的挑战

代理系统的良好功能激发了对特定代理挑战的研究。例如,Agent Workflow Memory通过引入工作流内存来解决Long-Horizon网络导航问题。DSPy和 Agora解决了通信流中的问题,StateFlow专注于代理工作流中的状态控制,以提高任务解决能力。虽然这些工作对特定用例做出了有意义的贡献,但它们并没有提供对 MAS 失败原因的全面理解,也没有提出可以广泛应用于各个领域的策略。已经提出了许多基准来评估代理系统。这些评估对于识别代理系统中的挑战和局限性至关重要,但它们主要促进自上而下的视角,重点关注更高级别的目标,例如任务绩效、可信度、安全性和隐私性。

2.2代理系统设计原则

一些研究强调了构建强大的代理系统的挑战,并提出了新的策略(通常用于单代理设计)来提高可靠性。例如,Anthropic 的博客文章强调了模块化组件(如快速链接和路由)的重要性,而不是采用过于复杂的框架。同样Kapoor等人表明,复杂性可能会阻碍代理系统在现实世界中的应用。我们的工作通过系统地研究 MAS 中的故障模式、提供说明 MAS 故障原因的分类法以及为代理系统设计提出符合这些见解的解决方案来扩展这些见解。

2.3LLM 系统中的故障分类

尽管人们对 LLM Agent的兴趣日益浓厚,但对其失效模式的专门研究却出奇地有限。与Bansal 等人的研究对代理系统中人机交互中面临的挑战进行了分类,我们的贡献代表了研究 MAS 故障模式的开创性努力。这突出了未来研究的必要性,即开发强大的评估指标、识别常见的故障模式以及设计缓解策略以提高 MAS 的可靠性

3研究方法

wechat_4fada070f01fc69f18bdd4817965f32c.jpg图 3:系统研究 MAS 的方法工作流程,包括识别故障模式、开发分类法、通过Annotator间一致性研究进行迭代细化,达到 Cohen's Kappa 分数 0.88。wechat_f42ea5b199242467f3b1caa3f784006c.jpg

本节介绍了我们识别 MAS 中的主要故障模式并建立故障模式结构化分类的方法。图3概述了此工作流程。

为了系统地、无偏见地发现故障模式,我们采用了GT理论方法,这是一种定性研究方法,它直接从经验数据构建理论,而不是测试预定义的假设。GT 的归纳性质使故障模式的识别有机地出现。我们通过理论抽样、开放式编码、持续比较分析、备忘和理论化迭代收集和分析 MAS 执行轨迹。

在获得 MAS 轨迹并讨论初步发现后,我们通过收集观察到的故障模式得出初步分类法。为了完善分类法,我们进行了inter-annotator一致性研究,通过添加、删除、合并、拆分或修改定义来迭代调整故障模式和故障类别,直到达成共识。此过程反映了一种学习方法,其中分类法不断完善,直到实现稳定性,通过 Cohen 的 Kappa 分数通过Annotator间一致性来衡量。此外,为了实现自动故障识别,我们开发了一个基于 LLM 的Annotator并验证其可靠性。

3.1数据收集与分析

我们采用理论抽样以确保所识别的MAS 的多样性,以及要收集数据的任务集 (MAS 执行轨迹)。 这种方法根据 MAS 的目标、组织结构、实施方法和底层代理角色的变化来指导MAS 的选择。 对于每个MAS,选择的任务都代表系统的预期能力,而不是人为挑战的场景。 例如,如果系统报告了特定基准或数据集的性能,我们会直接从这些基准中选择任务。 分析的 MAS 涵盖多个领域和上下文,如表1和附录B所述。 在收集 MAS 轨迹后,我们应用开放式编码来分析我们收集的代理-代理代理-环境交互的痕迹。开放编码将定性数据分解为标记的段,允许Annotator创建新的代码并通过备忘录记录观察结果,从而实现Annotator之间的迭代反思和协作。具体来说,Annotator识别他们遇到的故障模式,并系统地将他们创建的新代码与现有代码进行比较,这在GT中也称为持续比较分析。这种故障模式识别和开放编码的迭代过程一直持续,直到我们达到理论饱和,即从额外数据中不再出现新见解的点。通过这个过程,Annotator标记了 5 个 MAS 中的 150 多条痕迹。接下来,我们对相关的开放代码进行分组,以揭示MASFT初始版本中的细粒度故障模式。最后,我们链接故障模式,形成错误类别的分类,如图2所示。该过程在图3中用点 1 和 2 表示。在提出初始分类法后,一个重要的问题是该分类法的可靠性如何,以及我们如何找到一种自动化方法来评估 MAS 故障。为此,我们进行了Annotator间一致性研究,其中三位Annotator旨在验证、改进和最终确定最初得出的分类法。

3.2Annotator间一致性研究和迭代改进

Annotator间研究主要针对验证给定的测试或评分标准,这样当多个不同的Annotator根据相同的评分标准Annotator同一组测试用例时,他们应该得出相同的结论。尽管我们最初根据上一节中解释的理论抽样和开放编码得出了一个分类法,但仍然需要验证该分类法的无歧义性。

对于Annotator之间的一致性,我们在初步得出分类法的基础上进行了三轮主要讨论。在第一轮中,我们从上一节中解释的理论抽样获得的 150 多条轨迹中抽取了 5 条不同的 MAS 轨迹,三位Annotator使用初始分类法中的故障模式和定义对这些轨迹进行Annotator。我们观察到,Annotator在第一轮中达成的一致性非常弱,Cohen's Kappa 得分为 0.24。接下来,这些Annotator对分类法进行改进。这涉及迭代地更改分类法,直到我们达成共识,即每种故障模式是否存在于某种故障模式中,以及是否存在于所有 5 条收集到的轨迹中。在迭代改进中,我们根据需要更改故障模式的定义,将它们分解为多个细粒度故障模式,将不同的故障模式合并为一种新的故障模式,添加新的故障模式或从分类法中删除故障模式。

这一过程可以比作一项学习研究,其中不同的代理(这次是人类Annotator)独立地从共享状态空间收集观察结果,并彼此分享他们的发现以达成共识。此外,为了不陷入将训练数据用作测试数据的谬误,当我们在第 1 轮结束时进行细化研究时,我们在第 2 轮中测试了新的Annotator间一致性和分类法在另一组轨迹中的性能。在下一阶段(第 2 轮),我们采样另一组 5 条轨迹,每条轨迹来自不同的 MAS。然后,Annotator在第一次尝试中就达成了很好的一致,彼此之间的平均 Cohen's Kappa 分数为 0.92。受此启发,我们进入第 3 轮,在那里我们采样了另一组 5 条轨迹并再次使用相同的最终分类法进行Annotator,其中获得了 0.84 的平均 Cohen's Kappa 分数。请注意,Cohen's Kappa 分数超过 0.8 被认为是强的,超过 0.9 被认为是几乎完美的对齐

受分类法可靠性的启发,我们提出了以下问题:我们能否想出一种自动化的方法来Annotator轨迹,以便开发人员或用户可以将此自动化管道与我们的分类法一起使用,以了解其模型失败的原因?因此,我们使用 LLM-as-a-judge 管道开发了一个自动化MASFT Annotator,我们将在第3.3节中对其进行描述。

wechat_fe7a1ff965c64c2e2c4a71560ce0fab0.jpg


3.3LLM Annotator

在开发了我们的分类法MASFT并完成了Annotator之间的一致性研究之后,我们的目标是想出一种自动化的方法,使用我们的分类法来发现和诊断 MAS 轨迹中的故障模式。为此,我们开发了一个 LLM-as-a-judge 管道。在这个策略中,我们为 LLM 提供了一个系统提示,其中包括我们MASFT中的故障模式、它们的详细解释以及这些故障模式的一些示例。在该策略中,我们决定使用 OpenAI 的 o1 模型,并且尝试了不提供上述示例和提供示例的情况。基于第3.2节中提到的第 3 轮Annotator间一致性研究的结果,我们测试了 LLM Annotator的成功性,如表2所示。由于我们达到了 94% 的准确率和 77% 的 Cohen's Kappa 值,我们认为 LLM Annotator(提供上下文示例)是一个可靠的Annotator。受此结果的启发,我们让 LLM Annotator标记我们收集的 150+ 条痕迹语料库中的其余痕迹,其结果如图4所示,最终的分类法与故障模式分布如图2所示。


4研究结果

wechat_fcd7c67567456d2a2fa08e8708663ebc.jpg

图4:按类别和系统分布的故障模式。

我们对一系列不同的 MAS 进行的扎根理论研究和Annotator间一致性研究促成了图2中所示的MASFT开发。MASFT 组织了 3 个总体故障类别,确定了 MAS 在执行过程中可能遇到的 14 种细粒度故障模式。MASFT 还将MAS执行分为与代理相关的 3 个阶段:执行前、执行和执行后,确定了每种细粒度故障模式可能发生的 MAS 执行阶段。

FC1. 规范和系统设计失败。由于系统架构设计缺陷、对话管理不善、任务规范不明确或违反约束以及对代理角色和职责的定义或遵守不充分而导致的失败在 MAS 中,任务失败通常源于不完整或模糊的指令。然而,即使给出了明确的规范,MAS 也可能与用户输入不一致。此类失败的一个例子是违反任务规范。当被要求设计一款以经典国际象棋走法符号(如“Ke8”、“Qd4”)作为输入的双人国际象棋游戏时,MAS 框架 ChatDev 会生成一款以 (x1, y1)、(x2, y2) 作为输入的游戏,这些符号表示棋盘上棋子的初始坐标和棋子的最终坐标,因此无法满足初始要求。此类失败的另一种模式是未遵守角色规范。例如,在 ChatDev 的需求分析阶段,CPO 代理偶尔会通过单方面定义产品愿景并做出最终决策来承担 CEO 的角色。FC2. 代理间错位。由于沟通不畅、协作不力、代理间行为冲突以及逐渐偏离初始任务而导致的失败。
wechat_7f294fab213bfb1d4fbed210797b7660.jpg图5:电话代理未能向主管传达 API 规范和登录用户名要求。在对话的另一端,主管代理也未能澄清登录详细信息。经过几次来回尝试后,主管代理将任务标记为失败。多智能体系统经常遭受对话效率低下的问题,智能体会进行无效的交流,消耗计算资源却没有取得有意义的进展。例如,在涉及创建类似 Wordle 的游戏的 ChatDev 跟踪中,程序员智能体在七个周期内与多个角色(CTO、CCO 等)进行了交互,但未能更新初始代码。由此产生的游戏可玩但缺乏稳健性,只有五个简单的单词,破坏了可重玩性并导致额外的通信轮次浪费。此类别中的另一种故障模式是智能体隐瞒有价值的信息。例如,在图 5 中,主管智能体指示电话智能体使用电子邮件 ID 作为用户名来检索联系信息。电话智能体在阅读文档并发现正确的用户名应该是电话号码后,仍然使用错误的凭据继续操作,导致错误。FC3. 任务验证与终止。由于执行过早终止而导致的故障,以及缺乏足够的机制来保证交互、决策和结果的准确性、完整性和可靠性。MAS 可能在开发时没有经过专门的验证步骤,或者可能包含无法有效执行其任务的验证代理。例如,在涉及国际象棋游戏实现的 ChatDev 场景中,验证代理仅检查代码是否编译,而不运行程序或确保符合国际象棋规则。国际象棋是一种成熟的游戏,具有广泛的规范、规则和实现,可在线轻松获取。即使是简单的检索也应该直观地防止微不足道的故障,例如接受格式错误的输入。但是,如果没有适当的验证,无效输入处理或格式错误的接口等缺陷就会持续存在,导致游戏无法玩。

4显示了所研究 MAS 中细粒度故障模式以及故障类别的分布。不同的颜色代表MASFT中的不同故障类别,不同的色调代表类别内不同的细粒度故障模式。我们强调,没有任何单一错误类别占主导地位,这表明故障发生具有多样性,并且用于对故障进行分类的分类法具有稳健性。此外,我们注意到,正如预期的那样,不同的 MAS 表现出不同的故障类别和模式分布。例如,与规范和验证问题相比,AG2 的代理间错位实例较少,而 ChatDev 遇到的验证问题比规范和代理间错位挑战少。这些差异源于不同的问题设置,这会影响系统拓扑设计、通信协议和交互管理。反过来,这些因素塑造了具有自身优势和劣势的系统。

wechat_624f8e11bdc1c5497bff300fcf433eb5.jpg

图6:MAS 故障类别相关矩阵。

6突出显示了MASFT中不同故障类别之间的相关性。观察到的相关性不是特别强,它们表明所提出的分类法是一个合理的分类框架。此外,这还表明故障不是孤立事件;相反,它们可能具有连锁效应,可以影响其他故障类别。

wechat_34b0f6ae74da9b9e1a2e6363dd21c6a4.jpg图 7:MAS 故障模式相关矩阵

4.3都是验证者的错吗?

我们已经确定了 MAS 中的一系列故障模式。然而,可以说,归根结底,每个故障都可能源于缺乏适当的验证或不正确的验证流程。如果我们假设验证代理功能完美,那么所有故障都是可检测的,因此可以避免。

在我们的研究中,我们专注于系统可以有效受益于验证过程结果的情况中的验证问题。但是,我们还会检查在最终验证步骤之前发生的其他故障模式。在许多情况下,我们可以将验证视为防止故障的最后一道防线。这使我们得出结论,虽然许多问题确实可以追溯到验证不足,但并非每个问题都可以完全归因于这一因素。其他因素,例如规格不佳、设计不足、沟通效率低下,也会导致故障。因此,全面理解和解决 MAS 故障的方法必须考虑更广泛的因素,而不仅仅是验证缺陷。

4.4MASFT故障模式违反 HRO 定义特征

尽管我们遇到了一些常见的 LLM 故障模式,例如文本重复,但我们将它们排除在MASFT之外,因为这些问题并非专门与MAS 有关,甚至可能在单LLM 调用管道中发生。另一方面,我们发现MAS 面临与复杂人类组织类似的问题的证据,因为故障模式与人类组织中观察到的常见故障模式一致。Roberts & Rousseau (1989)确定了高可靠性组织 (HRO) 共有的八个主要特征。 通过 GT 发现的MASFT没有任何先前的偏见,包括几种与Roberts & Rousseau确定的 HRO 独特特征相关的故障模式具体来说,“ FM1.2:不遵守角色规范”

代理试图超越其角色,违反了 HRO 特征“极端层级分化”。同样,FM2.2 :未能要求澄清”破坏了“尊重专业知识”。MASFT确定的故障模式直接违反了 HRO 特征,这验证了MASFT的适用性,以及需要受 HRO 启发的非平凡干预措施。例如,为了防止 MAS 中发生FM1.2:不遵守角色规范”,编排和角色分配可以强制层级分化。

5迈向更好的多智能体 LLM 系统

在本节中,我们讨论了一些使 MAS 更能抵御故障的方法。我们将这些策略分为两大类:(i)战术方法,(ii)结构策略战术方法涉及针对特定故障模式量身定制的直接修改,例如改进提示、代理网络拓扑和对话管理。在第6节中,我们在两个案例研究中试验了这些方法,并证明这些方法的有效性并不一致。这促使我们考虑第二类策略,它们是具有全系统影响的更全面的方法:强验证、增强通信协议、不确定性量化以及内存和状态管理。这些策略需要更深入的研究和细致的实施,并且仍然是有待未来探索的开放研究课题。表3了解我们提出的不同解决方案策略与故障类别之间的映射。

5.1战术方法

此类别包括与改进提示和优化代理组织和交互相关的策略。MAS 代理的提示应提供清晰的指令描述,并应明确指定每个代理的角色。提示还可以明确角色和任务,同时鼓励主动对话。如果出现不一致,代理可以重新参与或重试,如下提示词所示。完成复杂的多步骤任务后,在提示中添加一个自我验证步骤,通过重述解决方案、检查条件和测试错误来追溯推理过程。然而,它可能会遗漏缺陷、依赖模糊的条件,或者不切实际。此外,可以通过定义对话模式和设置终止条件来强化明确的角色规范。采用简单、定义明确的代理(而不是复杂、多任务的代理)的模块化方法可以提高性能并简化调试。群体动力学还使多智能体系统的其他有趣可能性成为可能:不同的智能体可以提出各种解决方案,采用多智能体策略模拟学术同行评审过程,以捕捉更深层次的不一致之处。

Prompt:您的角色是逐步批判性地评估其他代理提出的解决方案并提供最终解决方案。1. **解决方案要求**:在做出任何决定之前,请确保您已收到来自代理代码执行器和代理问题解决器的解决方案。如果缺少任何建议的解决方案,请不要得出任何结论;而是建议下一位发言者,说明:建议的下一位发言者:_建议的代理名称_ 。2. **避免假设**:注意原始问题陈述中提供的变量与代理假设的变量。**假设值对解决方案无效** ,并且可能导致不准确。切勿以假设值为基础解决问题。始终以明确给出的变量为基础解决问题,以确保正确性。如果由于缺少信息而导致问题无法解决,则返回:** SOLUTION_FOUND \\ boxed { ' None ' } ** 。3. **评估相互冲突的解决方案**:如果讨论过程中出现不同的答案,请根据您的证据选择最合适的解决方案或开展进一步的讨论以澄清。4. **最终解决方案声明**:当您对最终解决方案有信心时,请按如下方式返回:** SOLUTION_FOUND \\ boxed { _solution_value_here_ } ** 。确保只有数值放在\\ boxed { }内;任何附带的文本都应放在外面


另一套交叉验证的策略方法包括多次 LLM 调用,并进行多数表决或重采样,直到验证完成。然而,这些看似简单的解决方案往往被证明是不一致的,这与我们的案例研究的结果相呼应。这强调了需要更强大的结构化战略,如下节所述。

5.2结构性策略

除了我们上面讨论的战术方法之外,还需要更多复杂的解决方案来塑造手头的 MAS 结构。我们首先观察验证过程和验证代理在多代理系统中的关键作用。我们的Annotator表明,薄弱或不充分的验证机制是导致系统故障的重要因素。虽然单元测试生成有助于软件工程中的验证, 创建一个通用的验证机制仍然具有挑战性。即使在编码中,覆盖所有边缘情况也很复杂,即使对于专家来说也是如此。验证因领域而异:编码需要全面的测试覆盖,QA 需要经过认证的数据检查,并且推理受益于符号验证。跨领域适应验证仍然是一个持续的研究挑战。

验证的补充策略是建立标准化的通信协议。基于 LLM 的代理主要通过非结构化文本进行通信,这会导致歧义。明确定义意图和参数可增强一致性,并在交互期间和之后进行正式的一致性检查。引入了多智能体图注意力机制,利用图注意力机制来模拟智能体交互并增强协调性。同样提出了注意力沟通,使代理能够有选择地关注相关信息。同样,开发一种学习选择性通信协议,以提高合作效率。

另一个重要的研究方向是使用强化学习对 MAS 代理进行微调。代理可以使用特定于角色的算法进行训练,奖励与任务一致的操作并惩罚效率低下的行为。MAPPO优化了代理对定义角色的遵守。同样,SHPPO在应用异构决策层之前使用潜在网络来学习策略。Optima通过迭代强化学习进一步提升沟通效率与任务效果。

另一方面,将概率置信度度量纳入代理交互可以显著提高决策和通信可靠性。从 Horvitz 等人提出的框架中汲取灵感。代理可以被设计为只有当其置信度超过预定义的阈值时才采取行动。相反,当置信度较低时,代理可以暂停以收集更多信息。此外,系统可以从自适应阈值中受益,其中置信度阈值是动态调整的。

尽管记忆和状态管理通常被视为单智能体属性,但对于多智能体交互来说,它们至关重要,可以增强上下文理解并减少交流中的歧义。然而,大多数研究都集中在单智能体系统上。MemGPT引入了受操作系统启发的上下文管理,用于扩展上下文窗口,而TapeAgents使用结构化、可重播的日志(“磁带”)来迭代记录和改进代理操作,促进动态任务分解和持续改进。

wechat_f118f63a4dbc8ba35744e5ef0dd68e8e.jpg

6案例研究

在本节中,我们将介绍应用一些战术方法的两个案例研究。


6.1案例研究 1:AG2 - MathChat

在本案例研究中,我们使用 AG2 中的 MathChat 场景实现作为我们的基线,其中学生代理与能够执行 Python 代码的助理代理协作解决问题。为了进行基准测试,我们从 GSM-Plus 数据集中随机选择了 200 个练习, GSM8K 的增强版本并添加各种对抗性扰动。第一种策略是改进原始提示,使其结构清晰,并增加一个专门用于验证的新部分。详细的提示在附录E.1和E.2中提供。第二种策略是将代理配置细化为一个更专业的系统,该系统具有三个不同的角色:问题解决者,使用思路链方法解决问题,不使用工具;编码员,编写并执行 Python 代码以得出最终答案;验证者,负责审查讨论并批判性地评估解决方案,要么确认答案,要么引发进一步的辩论。在这种情况下,只有验证者才能在找到解决方案后终止对话。为了评估这些策略的有效性,我们使用两个不同的 LLM(GPT-4 和 GPT-4o)在三种配置(基线、改进的提示和新拓扑)中进行了基准测试实验。我们还进行了六次重复实验,以评估结果的一致性。表4总结了结果。

wechat_e90a86b2820df93da39e5348f44e4024.jpg表 4:案例研究准确度比较。在 AG2 下,使用 GPT-4 和 GPT-4o 报告 GSM-Plus 结果;在 ChatDev 下,报告 ProgramDev 和 HumanEval 的结果。

表4的第二列显示,使用 GPT-4,经过验证的改进提示明显优于基线。但是,新拓扑并没有产生相同的改进。Wilcoxon 检验的 p 值为 0.4,表明小幅提升并不具有统计学意义。对于 GPT-4o(表4的第三列),在将基线与改进的提示和新拓扑进行比较时,Wilcoxon 检验得出的 p 值为 0.03,表明统计上有显著的改进。这些结果表明,优化提示和定义明确的代理角色可以减少失败。但是,这些策略并不是通用的,并且它们的有效性会因底层 LLM 等因素而异。

6.2案例研究2:ChatDev

ChatDev模拟了一个多智能体软件公司,其中不同的智能体具有不同的角色规范,例如 CEO、CTO、软件工程师和审阅者,他们试图协作解决软件生成任务。为了解决我们在跟踪中经常观察到的挑战,我们实施了两种不同的干预措施。我们的第一个解决方案是改进特定于角色的提示以强制执行层次结构和角色遵守。例如,我们观察到CPO 过早结束与 CEO 的讨论而没有完全解决约束的情况。为了防止这种情况,我们确保只有高级代理才能完成对话。此外,我们增强了验证者角色规范,以专注于特定于任务的边缘情况。这些干预措施的详细信息位于F节中。第二个解决方案尝试涉及对框架拓扑的根本更改。我们将框架的拓扑从有向无环图 (DAG) 修改为循环图。现在,只有当CTO 代理确认所有评论都得到适当满足时,该过程才会终止,并具有最大迭代截止以防止无限循环。这种方法可以实现迭代细化和更全面的质量保证。我们在两个不同的基准测试中测试了我们的干预措施。第一个是自定义生成的 32 个不同任务集(我们称之为 ProgramDev),我们要求框架生成各种程序,从“为我编写一个可在终端上玩的双人象棋游戏”到“为我编写一个 BMI 计算器”。另一个基准是 OpenAI 的 HumanEval 任务。我们在表4中报告了我们的结果。请注意,尽管我们的干预措施成功地提高了框架在不同任务中的性能,但它们并没有带来实质性的改进,需要我们在第5.2节中列出的更全面的解决方案。

7结论

在本研究中,我们首次系统地研究了基于 LLM 的多智能体系统的故障模式,在GT理论的指导下,我们收集并分析了 150 多个轨迹,并通过Annotator间研究迭代地完善我们的分类法并进行验证。我们确定了 14 种细粒度故障模式,并将它们归入 3 种不同的故障类别,为未来 MAS 的研究提供了标准。我们还提出了一种 LLM Annotator作为分析 MAS 轨迹的自动化方法,并展示了其有效性和可靠性。我们还讨论了所有故障类别的两套解决方案,即战术和结构策略。在对一些战术策略进行案例研究后,我们的研究结果表明,许多这些“明显”的修复实际上存在严重的局限性,需要我们概述的结构策略来实现更一致的改进。

原文链接:https://arxiv.org/html/2503.13657v1

图片图片 收起阅读 »
Debug messages:

Template: default


Session:

Session type: db

[tlu__Anwsion] Array ( [permission] => [client_info] => [human_valid] => )


Plugins:


Loaded Class:

core_config: /data/aiquanzi/system/core/config.php

core_db: /data/aiquanzi/system/core/db.php

Zend_Db: /data/aiquanzi/system/Zend/Db.php

Zend_Db_Adapter_Abstract: /data/aiquanzi/system/Zend/Db/Adapter/Abstract.php

Zend_Db_Adapter_Mysqli: /data/aiquanzi/system/Zend/Db/Adapter/Mysqli.php

Zend_Db_Profiler: /data/aiquanzi/system/Zend/Db/Profiler.php

Zend_Db_Statement_Interface: /data/aiquanzi/system/Zend/Db/Statement/Interface.php

Zend_Db_Statement: /data/aiquanzi/system/Zend/Db/Statement.php

Zend_Db_Statement_Mysqli: /data/aiquanzi/system/Zend/Db/Statement/Mysqli.php

Zend_Registry: /data/aiquanzi/system/Zend/Registry.php

Zend_Cache: /data/aiquanzi/system/Zend/Cache.php

Zend_Cache_Backend: /data/aiquanzi/system/Zend/Cache/Backend.php

Zend_Cache_Backend_Interface: /data/aiquanzi/system/Zend/Cache/Backend/Interface.php

Zend_Cache_Backend_ExtendedInterface: /data/aiquanzi/system/Zend/Cache/Backend/ExtendedInterface.php

Zend_Db_Table_Abstract: /data/aiquanzi/system/Zend/Db/Table/Abstract.php

core_plugins: /data/aiquanzi/system/core/plugins.php

setting_class: /data/aiquanzi/models/setting.php

Zend_Db_Select: /data/aiquanzi/system/Zend/Db/Select.php

Zend_Db_Expr: /data/aiquanzi/system/Zend/Db/Expr.php

Zend_Session_Abstract: /data/aiquanzi/system/Zend/Session/Abstract.php

Zend_Session: /data/aiquanzi/system/Zend/Session.php

Zend_Session_SaveHandler_Interface: /data/aiquanzi/system/Zend/Session/SaveHandler/Interface.php

Zend_Session_SaveHandler_DbTable: /data/aiquanzi/system/Zend/Session/SaveHandler/DbTable.php

Zend_Exception: /data/aiquanzi/system/Zend/Exception.php

Zend_Session_Exception: /data/aiquanzi/system/Zend/Session/Exception.php

Zend_Db_Table_Select: /data/aiquanzi/system/Zend/Db/Table/Select.php

Zend_Db_Table_Rowset_Abstract: /data/aiquanzi/system/Zend/Db/Table/Rowset/Abstract.php

Zend_Db_Table_Rowset: /data/aiquanzi/system/Zend/Db/Table/Rowset.php

Zend_Db_Table_Row_Abstract: /data/aiquanzi/system/Zend/Db/Table/Row/Abstract.php

Zend_Db_Table_Row: /data/aiquanzi/system/Zend/Db/Table/Row.php

Zend_Session_Namespace: /data/aiquanzi/system/Zend/Session/Namespace.php

core_cache: /data/aiquanzi/system/core/cache.php

core_uri: /data/aiquanzi/system/core/uri.php

banip_class: /data/aiquanzi/models/banip.php

Zend_Validate_Interface: /data/aiquanzi/system/Zend/Validate/Interface.php

Zend_Validate: /data/aiquanzi/system/Zend/Validate.php

Zend_Loader: /data/aiquanzi/system/Zend/Loader.php

Zend_Validate_Abstract: /data/aiquanzi/system/Zend/Validate/Abstract.php

core_user: /data/aiquanzi/system/core/user.php

admin_class: /data/aiquanzi/models/admin.php

TPL: /data/aiquanzi/system/class/cls_template.inc.php

Savant3: /data/aiquanzi/system/Savant3.php

account_class: /data/aiquanzi/models/account.php

HTTP: /data/aiquanzi/system/class/cls_http.inc.php

hook_class: /data/aiquanzi/models/hook.php

plugin_class: /data/aiquanzi/models/plugin.php

PLUTPL: /data/aiquanzi/system/class/cls_plugins.inc.php

core_lang: /data/aiquanzi/system/core/lang.php

Zend_Filter_Interface: /data/aiquanzi/system/Zend/Filter/Interface.php

Zend_Filter_Digits: /data/aiquanzi/system/Zend/Filter/Digits.php

system_class: /data/aiquanzi/models/system.php

article_class: /data/aiquanzi/models/article.php

column_class: /data/aiquanzi/models/column.php

topic_class: /data/aiquanzi/models/topic.php

menu_class: /data/aiquanzi/models/menu.php

module_class: /data/aiquanzi/models/module.php

core_pagination: /data/aiquanzi/system/core/pagination.php

FORMAT: /data/aiquanzi/system/class/cls_format.inc.php

Services_BBCode: /data/aiquanzi/system/Services/BBCode.php


Database

[ Log time: 1756391531.076 ] [ Expend time: 0.0059771537780762 ] Connect Master DB

[ Log time: 1756391531.0839 ] [ Expend time: 0.0023789405822754 ] SELECT `wecenter_system_setting`.* FROM `wecenter_system_setting`

[ Log time: 1756391531.0921 ] [ Expend time: 0.0013279914855957 ] SELECT `wecenter_nav`.`url` FROM `wecenter_nav` WHERE (is_index=1 AND status='Y') LIMIT 1

[ Log time: 1756391531.0962 ] [ Expend time: 0.0015268325805664 ] SELECT `wecenter_ban_ip`.`id` FROM `wecenter_ban_ip` WHERE (ip='216.73.216.142') LIMIT 1

[ Log time: 1756391531.0983 ] [ Expend time: 0.0014660358428955 ] SELECT `wecenter_nav`.* FROM `wecenter_nav` WHERE (status='Y') ORDER BY `sort` desc

[ Log time: 1756391531.1045 ] [ Expend time: 0.002155065536499 ] SELECT `wecenter_hook_plugins`.`hook`, `wecenter_hook_plugins`.`plugins` FROM `wecenter_hook_plugins` WHERE (status = 1) ORDER BY `sort` DESC

[ Log time: 1756391531.1084 ] [ Expend time: 0.002439022064209 ] SELECT `wecenter_plugins`.* FROM `wecenter_plugins` WHERE (state = 1)

[ Log time: 1756391531.1323 ] [ Expend time: 0.0015530586242676 ] SELECT `wecenter_category`.* FROM `wecenter_category`

[ Log time: 1756391531.143 ] [ Expend time: 0.0087640285491943 ] SELECT `wecenter_article`.* FROM `wecenter_article` WHERE (category_id = 1 AND is_del = 0) ORDER BY `add_time` DESC LIMIT 10

[ Log time: 1756391531.1447 ] [ Expend time: 0.0014429092407227 ] SELECT COUNT(*) AS `n` FROM `wecenter_article` WHERE (category_id = 1 AND is_del = 0)

[ Log time: 1756391531.1485 ] [ Expend time: 0.0015981197357178 ] SELECT `wecenter_topic_relation`.* FROM `wecenter_topic_relation` WHERE (item_id IN(87,86,82,81,80) AND `type` = 'article')

[ Log time: 1756391531.1503 ] [ Expend time: 0.0015861988067627 ] SELECT `wecenter_topic`.* FROM `wecenter_topic` WHERE (topic_id IN(13,14,13,14,13,14,15,16,17,13,14))

[ Log time: 1756391531.1526 ] [ Expend time: 0.0021719932556152 ] SELECT `wecenter_users`.* FROM `wecenter_users` WHERE (is_del = 0 AND uid = 38) LIMIT 1

[ Log time: 1756391531.1549 ] [ Expend time: 0.0016458034515381 ] SELECT `wecenter_category`.* FROM `wecenter_category` WHERE (`type` = 'question') ORDER BY `id` ASC

[ Log time: 1756391531.1566 ] [ Expend time: 0.0015308856964111 ] SELECT `wecenter_category`.* FROM `wecenter_category` WHERE (`type` = 'question') ORDER BY `sort` ASC, `id` ASC

[ Log time: 1756391531.1583 ] [ Expend time: 0.001384973526001 ] SELECT question_id FROM wecenter_question WHERE category_id IN(1) ORDER BY add_time DESC LIMIT 200

[ Log time: 1756391531.1661 ] [ Expend time: 0.0076930522918701 ] SELECT `wecenter_article`.* FROM `wecenter_article` WHERE (add_time > 1753799531 AND is_del = 0) ORDER BY `votes` DESC LIMIT 10

[ Log time: 1756391531.1887 ] [ Expend time: 0.0012340545654297 ] SELECT `wecenter_users`.`avatar_file` FROM `wecenter_users` WHERE (uid=38) LIMIT 1


Cache

[ Log time: 1756391531.0901 ] Backend: File

[ Log time: 1756391531.0902 ] [ Expend time: 0.000029 ] Get Cache: crond, result type: boolean

[ Log time: 1756391531.1012 ] [ Expend time: 0.000107 ] Get Cache: user_group_99, result type: array

[ Log time: 1756391531.1431 ] [ Expend time: 0.000042 ] Get Cache: db_rows_cache_23b6df6f89e13d156eb405ad1f618f42, result type: boolean

[ Log time: 1756391531.145 ] [ Expend time: 0.000325 ] Save Cache: db_rows_cache_23b6df6f89e13d156eb405ad1f618f42, result type: integer

[ Log time: 1756391531.1531 ] [ Expend time: 0.000122 ] Get Cache: nav_menu_list, result type: array

[ Log time: 1756391531.1663 ] [ Expend time: 0.000116 ] Get Cache: db_rows_cache_807c0357c6d50ba048939821872f4edc, result type: integer

[ Log time: 1756391531.1665 ] [ Expend time: 0.000188 ] Save Cache: db_rows_cache_807c0357c6d50ba048939821872f4edc, result type: integer


Escape time: 0.48865985870361, 18 queries, PHP Memory usage: 6510.9921875 KB, Server time: 2025-08-28 22:32:11