AgentArk：面向多模态智能体的「大模型Steam」
最近，一款面向多模态智能体的开放式环境框架AgentArk迎来了亮眼的测试结果：在公开的14个任务、6个模型的评测中，GPT-6 Astra取得了80.46的综合得分，大幅领先此前的所有模型，让整个基准平台的测试数据刷新了记录。
AgentArk的核心设计思路，是通过编码智能体持续生成并扩展任务环境，同时让同一套环境既能用于智能体的强化学习训练，也能用于性能评测。目前该项目已经开发了200余个任务环境，覆盖2D、3D、物理交互、多视角、时间估计、GUI、图表、3D建模以及类ARC-AGI-3等多个方向，团队的2026年目标是将任务数量扩展到1000个以上。在强化学习侧，AgentArk已经支持ms-swift与verl两款工具，可以直接在这些多模态交互环境上开展GRPO等智能体强化学习训练。
项目开发者用一句直观的话概括了自己的愿景：希望AgentArk能成为“大模型的Steam”。这里的核心并非维护一套固定的任务题库，而是让环境库实现持续增长：新的任务可以不断被开发、验证并加入任务商店，智能体既可以进入这些环境完成评测，也可以直接在其中进行强化学习训练。
此次GPT-6 Astra的亮眼表现，也解答了项目开源初期团队一直存在的疑问：当多个模型在大量任务上表现不佳时，到底是模型能力不足，还是任务环境本身的设计存在问题？尤其是AgentArk的任务全部由编码智能体自动化开发，这个问题更需要被重视。
而在同一套环境与交互协议下，更强的模型能够显著推高整体得分，这至少证明了一个重要结论：过去大量的任务失败并非因为任务本身不可解，随着模型能力的提升，原本存在的能力提升空间确实可以被解锁。这也让团队更有信心将AgentArk往“更难、更陌生、更依赖上下文学习”的方向持续扩展。
GPT-6 Astra在ARC-AGI-3上的表现也提供了有趣的参照。虽然ARC-AGI-3和AgentArk并非同一套基准，但两者关注的能力存在明显交集：让智能体进入陌生环境，通过观察、行动和反馈，在上下文语境中逐步理解环境规律，也就是“环境内的上下文学习”。
ARC-AGI-3更聚焦于陌生的抽象交互环境，而AgentArk则更侧重广义的多模态智能体。除了数十个类ARC-AGI-3的任务，AgentArk还包含普通2D/3D、物理交互、空间推理、多视角、时间估计、GUI、图表、3D建模等多种任务类型。从这个角度来看，AgentArk想要解决的问题非常直接：如果我们希望智能体真正进入陌生环境中观察、试错、学习和改进，那么足够丰富的多模态交互环境从哪里来？
如果将范围放宽到所有智能体环境，“环境稀缺”的说法并不完全准确。例如编码智能体已经拥有大量成熟的沙盒、代码仓库、编译器、解释器和单元测试工具，这些结构化基础设施天然适合构成大规模、可验证的训练与评测环境。但团队真正想强调的是：足够多样、可交互、可验证，并且能同时用于评测和强化学习的多模态环境，仍然非常稀缺。
多模态环境的难点在于，智能体接收的是视觉画面，执行的动作需要真实改变环境状态，而环境还必须自动给出奖励信号，并支持重置、随机化、重放以及并行运行。目前已有一些相关工作，部分子方向已经具备较好的扩展基础，例如GUI任务的交互范式相对固定，Web/WebDev天然拥有DOM、HTML、CSS、JavaScript这样的结构化状态，既容易构造视觉观察，也容易自动验证结果。另外还有一些工作更侧重环境接口、部署和共享，例如OpenEnv以及Prime Intellect的环境中心，它们对智能体生态很重要，但更关注如何让已有环境更容易被标准化、运行和分发。
这里需要区分两个关键问题：一是如何让环境更容易被接入和共享，二是大量新的多模态环境本身从何而来。AgentArk更聚焦于解决第二个问题。
AgentArk的基本路线非常直接：利用已经足够强大的编码智能体，自动开发用于评测和训练下一代多模态智能体的环境。在半年前，这件事还很难实现，因为一个真正可用的智能体环境，并非只是“写一个小游戏”，还需要包含场景、任务目标、观察空间、动作API、奖励机制、随机化、重置、终止条件、异常处理、可解性检查与重放功能；而且任务本身也不是一次性完成的，如果需要修正，编码智能体也需要具备一定的多模态能力。
但今天，编码智能体的软件工程能力已经跨过了关键门槛，一个自然的问题随之而来：能否将编码智能体的能力，转化为构造训练环境的能力？AgentArk正是在尝试解决这个问题。
AgentArk的底层维护一个通用运行时，新的任务环境以独立的Task Mod形式加载。每个Mod可以自行定义任务说明、观察空间、动作空间、奖励/评分机制、终止条件以及场景逻辑。运行时本身不需要知道当前加载的是3D空间推理、物理控制、GUI、类ARC谜题还是图表操作，只需要提供统一的执行和交互能力。
因此，AgentArk Bench只是AgentArk的一种公开评测方式：基准测试是从持续增长的任务库中抽取一部分环境，通过统一配置进行公开评测。
如果编码智能体只是不断生成“看起来像任务”的场景，那么无论生成1000个还是10000个，实际意义都不大。真正的关键问题是：奖励信号从何而来？而这正是游戏引擎式环境的重要优势。
团队常用一句话概括这种结构：“判别容易，决策难”。例如一个3D任务要求智能体根据画面判断两个物体哪个离摄像头更近。对于多模态智能体来说，它接收的是RGB图像观察，需要理解深度、透视、遮挡和空间关系；但对于环境来说，它内部直接知道摄像头和两个物体的位置坐标，答案几乎可以直接计算得出。
再比如一个物理任务：智能体需要控制力度和方向，将物体投掷到目标区域。智能体只能根据画面和历史尝试估计距离、角度、速度、重力、摩擦和碰撞情况；而环境内部则拥有真实的位置、速度、碰撞、刚体状态和目标边界。对于智能体来说，这是一个复杂的感知+推理+控制问题；但对于验证器来说，只需要简单判断物体位置是否处于目标区域内即可。
这里存在一个非常适合强化学习的信息结构：智能体只能根据有限的多模态观察做出决策，而环境可以使用特权的结构化状态进行验证。因此奖励信号不需要依赖另一个昂贵的视觉语言模型去“判断模型是否大致做对”，引擎本身就拥有真实的基准结果。团队认为，这是AgentArk能够持续扩展任务数量，同时保持可训练性的核心支撑。
环境代码能够运行，并不代表它就是一个合格的智能体任务。一个程序可以完全没有代码漏洞，但仍然可能存在多种问题：目标在视觉上不可观察、奖励机制存在捷径、某些随机种子下任务无解、反馈不足导致智能体无法从失败中学习、重放无法稳定复现等等。
因此，AgentArk的环境生产并非一次性的“提示词→代码”流程，而是一个带有验证的工作流。在当前的工作流中，协调器负责整体调度，设计者负责将能力缺口转换为任务规范，构建者负责实现环境，审核者负责检查视觉可观察性、任务可解性、可重放性等关键属性。在审核者环节之后，团队还加入了黑盒智能体试玩测试：让智能体以黑盒方式真正试玩任务，从智能体侧暴露任务设计问题，例如反馈不足、任务说明存在歧义、交互逻辑不合理，或者“从开发者视角看起来可解，但实际智能体很难获得完成任务所需的信息”。试玩智能体就像普通玩家，不一定需要很强的能力，但可以有效判断任务是否合理。
这里最重要的一点是：代码的正确性不等于任务的正确性。对于AgentArk来说，任务开发实际上比“让编码智能体编写一个Unity环境”要复杂得多。一个可用于评测和强化学习的任务，至少需要确保任务可解、能够稳定重置、能够重放、奖励可验证，并且智能体确实能够通过给定的观察获取完成任务所需的全部信息。这些都属于编码智能体开发工作流的一部分。如果未来希望将任务扩展到1000、10000甚至更多，那么需要扩展的不仅是编码能力，也必须包括环境验证能力。
另一条重要的路线是世界模型。如今的视频世界模型已经可以生成越来越真实、甚至支持实时交互的虚拟世界。团队非常看好这个方向，但从智能体评测和强化学习的视角来看，需要区分两件事：世界生成和任务环境生成。
世界模型擅长生成场景、视觉变化和动态过程，智能体甚至可以在其中移动和探索。但一个可用于强化学习的环境，还需要明确目标、动作语义、奖励机制、终止条件、验证方式以及持久化状态。也就是说，除了“世界长什么样”，还要回答“这个世界里要做什么？做对了之后怎么判断？”
因此，一个能够探索的虚拟世界，并不天然等于一个可以用于训练智能体的任务环境。例如两个月前有团队基于Roblox开发的世界模型，允许玩家实时进入游玩，但大多数玩家进入后都会感到困惑：“我可以移动，但接下来要做什么？”
AgentArk的出发点刚好相反：先确定需要评测或训练的能力，再围绕这个目标构建场景、观察空间、动作空间和奖励机制。因此，编码智能体生产的环境天然是以任务为中心的。团队并不认为这两条路线互斥，更可能的未来是：世界模型/3D生成提供无限的视觉和世界多样性，而任务引擎提供明确的目标、逻辑、动作和可验证的奖励。这也是AgentArk后续希望进一步结合的方向。
AgentArk仍然遵循最基本的强化学习循环：重置→观察→动作→奖励+下一次观察，但和传统的Gym环境存在大量本质区别，这里重点讨论观察空间和动作空间。
传统的Gym环境通常会预先定义固定的观察空间和动作空间，这非常适合针对具体环境训练的策略网络。但基于基础模型的智能体，其目标并不相同：我们更关心的是，当智能体第一次进入一个陌生环境时，能否依靠当前的上下文语境现场理解环境规则？
因此，AgentArk的观察空间可以是图像、多幅图像、视频帧、文本、任务说明、之前的动作、得分、错误信息，以及前几次尝试的历史记录。一次失败的尝试也不一定意味着这段轨迹完全没有价值，对于很多需要校准、规则发现或物理推理的任务，之前的失败本身就是下一次决策的重要依据。这也是为什么AgentArk的很多任务本质上都依赖上下文学习。
对于大语言模型/视觉语言模型智能体来说，固定的动作空间往往会浪费大模型已经具备的一项重要能力：编写代码。因此，AgentArk的动作空间本质上采用“代码即动作”的设计。
对于简单任务，可以暴露结构化的函数调用，例如Move、Rotate、Launch、Click、TypeText等，智能体通过结构化工具调用的方式使用这些函数。对于更复杂的任务，也可以直接允许智能体提交完整的代码，让一次动作表达一个更长的控制程序。
当然，“代码即动作”也带来了新的问题：JSON格式可能非法、参数可能越界、代码可能编译失败，或者执行时出现异常。AgentArk会在不同阶段捕获这些错误，包括格式错误、编译错误和运行时异常。而关键的设计在于：这些错误本身也会作为下一次观察的一部分返回给智能体。智能体可以看到编译器诊断信息或运行时异常，并在下一步主动修复问题。在团队看来，这比要求大语言模型模拟传统的策略网络，更接近真正的大模型原生环境接口。
AgentArk Bench只是该项目的一种使用方式。整个系统围绕同一批任务Mods，同时支持多种用途：编码智能体生成任务Mod，加载到AgentArk运行时，之后既可以用于评测，也可以用于强化学习，最终分别输出重放/展示结果和用于训练的模型数据。
具体来说，项目的代码仓库提供运行时、Python工具链、评测、重放和强化学习接口；AgentArk Hub更像是一个不断增长的任务商店，展示任务、标签、多媒体资源、模型结果和相关工件；公开评测基准平台则提供公开的评测入口。目前强化学习侧已经支持ms-swift与verl的智能体强化学习/GRPO集成。
环境服务器负责管理任务、随机种子、运行时工作进程、预加载、沙盒和工作进程回收；训练器则通过HTTP与环境池交互，不需要直接管理图形进程。对于GRPO这类基于组的强化学习，同组的样本还可以使用相同的任务、随机种子和初始条件，让组内的奖励差异尽可能来自策略本身，而非环境的随机性。这也是AgentArk从设计之初就非常重视的一点：一个任务被开发出来后，希望评测和强化学习可以直接复用，而不需要再编写两套不同的环境。
AgentArk今年的目标是完成1000个以上的任务环境，但1000并不是终点。如果整个流程永远只是由人类提出新的任务方向，再由编码智能体实现，那么系统最终仍然强烈依赖人类任务设计者。团队更感兴趣的是下一步的自动化循环：智能体的评测与强化学习→失败轨迹分析→能力缺口识别→自动提出新任务→编码智能体实现环境→验证→加入训练课程→继续强化学习，也就是“智能体与环境的共同进化”。
如今，编码智能体在软件工程上已经足够强大，可以先利用它们来生产环境，补齐多模态智能体的能力缺口。未来，当多模态智能体进一步增强后，它们可以从自己的失败轨迹中发现新的弱点，提出下一代任务，再进入新的强化学习循环。也就是智能体找到自己的弱点→为自己出题→训练→再寻找新的弱点。这也是团队认为AgentArk最值得长期探索的方向。
相比“一个新的多模态基准测试平台”，团队更愿意这样定义AgentArk：一个通过编码智能体持续生产多模态交互环境，并统一用于评测和强化学习的开放框架。
该项目目前还处于早期阶段：开源仅两个月，已经完成了200余个任务，今年的阶段性目标是1000个任务。但任务数量本身并不是最终目标，真正重要的是，环境能否持续扩展到新的能力领域，并且在模型进步之后继续产生新的挑战。
GPT-6 Astra此次将AgentArk Bench的得分推到80.46，对团队来说并不意味着“现有基准测试已经快要完成”，反而让团队更关心下一个问题：GPT-6已经解决了这些任务，那么下一批它无法解决的环境在哪里？找到这些任务，将它们开发成环境，让智能体进入其中尝试失败，再通过强化学习让它学会完成任务，然后继续寻找下一批挑战。这就是团队目前对AgentArk最期待的方向。
团队希望有一天，大模型进入AgentArk，就像我们打开Steam一样：里面永远有它还没体验过、也还没学会的新内容。
