Minecraft中面向时间敏感互补协作的多智能体框架

# 面向Minecraft中时间敏感互补协作的多智能体框架
来源：https://arxiv.org/html/2606.15684
Juheon Yi, Jinglu Wang, Xiaoyi Zhang, Yan Lu 微软亚洲研究院 \{jyi,jinglwa,xiaoyizhang,yanlu\}@microsoft\.com

###### 摘要

我们提出 **TickingCollabBench**，一个基于Minecraft的多智能体基准测试，针对一类新颖的 *时间敏感互补协作任务*。我们的基准测试反映了现实世界协作的四个核心特征：智能体异质性、强制协作、动态环境，以及带有失败风险的严格实时约束。为此，我们开发了 **TickingCollab** 框架，该框架支持生成多样化的动态事件，并抽象化Minecraft的原始API，以便通过声明式YAML任务规范来组合这些事件。在此基础上，我们设计了一个可行性感知的自动基准测试生成流水线，其中LLM起草结构多样化的任务配置，而可行性验证器则通过近似约束过滤掉无效配置。评估结果表明，长延迟以及部分可观测性和智能体异质性下的固有协调难度，导致LLM在动态环境中频繁失败，且远不及一个拥有全局知识的理想解。

## 1 引言

现实世界中的多智能体协作通常要求具有部分可观测性的智能体协同整合异构能力，并在严格时间限制内完成任务。例如，一支携带不同工具且具备不同移动能力的具身机器人团队可能需要协调应对扩散的危害，以在救援截止时间前完成任务。类似地，在协作工作环境中，运行在不同用户设备上的个人智能体可能只能观察到本地数据，并拥有异构的计算资源，它们需要联合处理分布式信息，以及时响应来自用户的请求。然而，由于安全风险、部署成本以及对环境动态的有限控制能力，在现实世界中组成此类时间敏感协作场景并进行大规模智能体评估是困难的。因此，许多先前的工作侧重于具有共享上下文、同质智能体且无明确失败时间约束的静态任务（Zhuge等，2024；Chen等，2024；Yu等，2024a）。

为弥合这一差距，Minecraft已成为一个用于组成复杂任务和动态环境，并系统控制智能体能力（如工具、移动性和感知能力）的可扩展测试平台。然而，现有基于Minecraft的多智能体协作基准测试（White等，2025；Schipper等，2025；Long等，2024；Yu等，2024b；Dong等，2024）仍存在关键局限性：

参见子图说明
(a) 为危机做准备。
(b) 挖掘消失的方块。
(c) 突袭首领。
(d) 智能体观测与能力。

图1：**TickingCollabBench** 中的时间敏感互补协作任务。

- • 对实时动态协作的重视不足。现有任务通常具有同质化智能体并且可单独完成，使得真正的协作成为可选项而非强制性要求。此外，其静态环境和尽力而为的目标允许智能体依赖一次性的离线规划，几乎不面临因决策延迟或运行时动态事件导致的失败风险（表2中的定量分析）。
- • 对动态任务的框架支持有限。现有的Minecraft框架主要设计用于静态环境，缺乏对运行时动态事件（如扩散的洪水、物体/怪物的生成和消失）的内建支持。因此，为了引入此类动态，智能体开发者必须使用底层Minecraft API从头构建自定义服务器插件。这种高技术壁垒带来了沉重的开发负担，从而限制了多样化且复杂的协作场景的创造。

我们提出 **TickingCollab**，一个用于在Minecraft中评估LLM智能体在新颖*时间敏感互补协作任务*上的基准测试套件和框架。**TickingCollabBench**（图1）针对的是这样的场景：具有异构能力和部分可观测性的智能体必须紧密整合其互补技能。关键在于，环境持续变化，未能快速适应会直接导致任务失败。通过与前序基准测试的定量比较（表1和表2），我们提出了一个基本问题：*当面临动态环境和实时失败风险时，LLM能否在异构智能体之间编排准确且高效的协作？*

为了系统性地构建和评估时间敏感互补协作任务，我们的 **TickingCollab** 框架提供了三个关键功能：

- • **动态环境管理器**。开发者可以通过无需Minecraft API的YAML配置（示例见LABEL:list:2-metadata-example）声明式地注入复杂的运行时动态（例如，熔岩波、物体/怪物生成/消失），从而绕过自定义插件开发的沉重负担。
- • **可行性感知的自动基准测试生成**。为了系统地探索组成时间敏感互补协作任务时庞大且复杂的参数空间，我们设计了一个自动化流水线：LLM首先起草多样化的任务配置，然后可行性验证器通过近似约束过滤掉无效配置。
- • **全面评估**。该框架通过双执行模式（*同步固定时间步*与*异步实时*）将LLM的规划准确性与推理延迟分离，同时支持并行模拟和细粒度的系统成本记录。

我们使用一个基准多智能体协作方案（**TickingCollabAgent**）并结合两种源自先前工作的协调策略（集中式和分布式）来评估我们的基准测试（Long等，2024；White等，2025）。我们的评估揭示，LLM推理延迟是实时异步执行中的一个关键瓶颈，常常因违反时间约束而导致任务失败。此外，尽管集中式协调通过减少通信和推理开销优于分布式拓扑，但其性能仍不及一个理想解——即一个利用全局真值访问动态环境以及人工制定的调度规则的非LLM解决方案。这些发现突显了在部分可观测性下进行异构多智能体规划的挑战，并需要在动态环境中实现高效的LLM推理和多智能体协调策略。

## 2 TickingCollabBench 基准测试套件

表1：现有Minecraft智能体基准测试与 **TickingCollabBench** 的比较。
△：对于括号中列出的任务子集部分覆盖。

| 基准测试 | 异构智能体能力？ | 强制协作？ | 动态环境？ | 实时约束（或失败风险）？ |
| :--- | :--- | :--- | :--- | :--- |
| **单智能体** | | | | |
| MineRL (Guss等, 2019) | × | × | × | × |
| MineDojo (Fan等, 2022) | × | × | △ (战斗) | △ (战斗, 生存) |
| Odyssey (Liu等, 2024) | × | × | △ (战斗) | △ (战斗, 生存) |
| MCU (Zheng等, 2025) | × | × | △ (战斗) | △ (战斗, 生存) |
| **多智能体** | | | | |
| MineLand (Yu等, 2024b) | × | × | △ (战斗) | △ (战斗, 生存) |
| TeamCraft (Long等, 2024) | ○ (不同物品) | ○ | × | × |
| MineCollab (White等, 2025) | ○ (不同物品) | △ (烹饪, 合成) | × | × |
| PillagerBench (Schipper等, 2025) | × | × | ○ | ○ (对战对手) |
| VillagerBench (Dong等, 2024) | × | △ (密室逃脱) | △ (收获) | × |
| **TickingCollabBench** | ○ | ○ | ○ | ○ |

**TickingCollabBench** 包含三个具有代表性的 *时间敏感互补协作任务*（图1），在这些任务中，具有异构能力的智能体必须协调以实现全局目标，同时处于对动态环境的部分可观测性下。这些任务被设计为第1节中讨论的现实世界协作场景的可控类比，强调先前Minecraft多智能体基准测试中体现不足的四个关键属性（见表1的详细比较）：

- • **异构能力**。智能体在与动作相关的属性和资源（例如，感知范围、速度、生命值、工具）上有所不同，这需要复杂的互补角色，无法像先前基准测试那样仅通过简单的物品库存差异来体现。
- • **强制协作**。任务的设计使得成功需要协调互补能力，而不仅仅是扩展相同智能体的数量。
- • **动态环境**。环境在运行时持续变化，使一次性离线计划失效，需要在线适应。
- • **实时约束**。与先前无惩罚的设置不同，决策延迟直接导致任务失败，要求及时执行。

**TickingCollab** 框架为指定这些任务提供了一个声明式接口。这实现了自动化的基准测试生成流水线：LLM首先生成包含四个关键属性的多样化配置，然后根据可行性标准进行过滤，最终为 **TickingCollabBench** 生成634个有效任务（详见第3.1节）。

### 2.1 任务套件

**任务 #1：为危机做准备（图1(a)）**。智能体必须识别即将到来的危机（例如，熔岩洪水、雪崩），并协作收集地图上散落的适当材料，在危机冲击前建造合适的生存庇护所（例如，用石头而非易燃的木头）。智能体拥有不同的采矿工具（例如，斧头用于木头，镐用于金属矿石）、感知范围和移动速度。生存依赖于高效的角色分配，例如利用长感知智能体作为侦察兵，而较快的智能体则收集远处的方块。与忽略时间约束和失败风险的先前 *建造任务* 不同，该任务要求及时执行和异构智能体的高效协调。

**任务 #2：挖掘消失的方块（图1(b)）**。智能体必须挖掘多种方块类型的目标配额，这些方块随机出现并在特定类型的生命周期后消失。考虑到不同的移动速度、感知范围以及决定方块兼容性和挖掘效率的异构采矿工具（例如，木头需要斧头，金矿石至少需要铁级镐，而钻石等更高级别工具可提供更快的挖掘速度），智能体必须通过计算行进和挖掘时间与方块生命周期来最优分配目标，以避免浪费精力。虽然先前的 *收获任务* 大多具有静态方块布局和同质智能体，但我们的任务需要动态的、基于能力的分配。

**任务 #3：突袭首领（图1(c)）**。智能体必须击败一个首领怪物，该怪物会动态生成具有不同生命值和伤害的各种小兵。智能体在基础生命值和具有类型特定伤害倍数的武器上有所不同。智能体必须根据类型优势和生存能力共同优化目标分配，同时策略性地脱离战斗以从散布的宝箱中获取生命药水。虽然先前的 *战斗任务* 通常假设静态生成的怪物和同质智能体，但我们的任务引入了动态的敌人生成，并要求多样角色之间复杂的战斗协调。

### 2.2 协作难度指标

表2：多智能体基准测试统计数据对比。
↑ 和 ↓ 分别表示较高或较低的值意味着任务更具挑战性。

| 指标 | MineLand (Yu等, 2024b) | TeamCraft (Long等, 2024) | MineCollab (White等, 2025) | **TickingCollabBench** |
| :--- | :--- | :--- | :--- | :--- |
| | 战斗 | 收获 | 建造 | 破坏 | 建造 | 农业 | 冶炼 | 建造 | 烹饪 | 合成 | 准备 | 挖掘 | 突袭 |
| **H** ↑ | 0 | 0 | 0 | 0 | 0.72 | 0.43 | 0.39 | 0.68 | 0 | 0.43 | 0.44 | 0.78 | 0.72 | 0.31 |
| **N** ↑ | 0 | 0 | 0 | 0 | 0 | 0.54 | 1.13 | 0 | 0 | 1.87 | 1.76 | 1.11 | 1.42 | 1.39 |
| **D** ↑ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1.79 | 2.98 | 0.38 |
| **τ** ↓ | - | 11.51s* | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | 44.03s | 33.31s | 25.37s |

* 排除了 τ = ∞ 的样本。

我们定义了四个协作难度指标，以定量评估 **TickingCollabBench** 如何体现时间敏感的互补协作。

- • **智能体异质性 (H)** 衡量所有唯一智能体对 P 上的平均成对属性归一化距离：H = 1/|P| * Σ_{(i,j)∈P} (1/|K| * Σ_{k∈K} δ_k(a_i, a_j))。对于每个属性 k ∈ K，距离 δ_k 对连续值（例如 HP）采用最小-最大归一化处理，对集合（例如库存物品）采用Jaccard距离处理：δ_k(a_i, a_j) = { |v_{ik} - v_{jk}| / (v_k^{max} - v_k^{min}) 若k为连续值；1 - (|S_{ik} ∩ S_{jk}|) / (|S_{ik} ∪ S_{jk}|) 若k为集合 }，其中 v_k^{max} 和 v_k^{min} 表示参数空间的预定义边界。因此，H ∈ [0,1]，其中 1 表示最大差异性。
- • **协作必要性 (N)** 估计总任务工作量与最大单智能体能力之比：N = min_{a∈A} ( Σ_k Workload_k / Throughput_{a,k} ) / T_max。内部求和计算的是最强大的单智能体 a ∈ A 顺序处理所有目标 k 所需的时间。其中，Workload_k 是所需的方块数量（任务 #1， #2）或敌方总HP（任务 #3），而 Throughput_{a,k} 是智能体 a 的挖掘速度或每秒伤害（DPS）。注意，N 是一个保守的下界，因为智能体