DuoCook：订单只完成两成六，共享笔记本还把模型拆成两派

DuoCook：受 Overcooked 启发的视觉规划与协作基准

Ziyi Jiao（Department of Computer Science, University of British Columbia）

Heng Zhang（Department of Computer Science, University of British Columbia）

Drishti Regmi（University of California, San Diego）

Xiaokang Ye（University of California, San Diego）

Lianhui Qin（University of California, San Diego）

Peter Yichen Chen（Department of Computer Science, University of British Columbia）

摘要

在烹饪任务中协调两名玩家，要求视觉语言模型跟踪不断变化的场景状态、排列食谱步骤，并在时间预算下分配共享资源。我们引入一个受 Overcooked 启发的基准，在用编码智能体构造的 Unreal Engine 环境中评测这些能力。单个视觉语言模型根据俯视视觉观察控制两名玩家，选择高层动作，而引擎执行导航。该基准包含五个类别中的 20 张地图。这些类别支持在设备争用、地形变化和交接依赖下评测集中式协调。道具图例和锅内原料计数指示提供显式的视觉线索，而基于网格的目的地支持空间定位。评测在全部 20 张地图上比较四个视觉语言模型，测量任务分数、订单完成、交付精度、动作接受率和模型 API 支出。在同样的 20 张地图上做记忆消融，考察一本共享的、由模型自己撰写的笔记本的效果，同时在两种条件下都保留六条响应的动作历史。被评测模型中最强的 gpt-6-astra 达到 26.2% 的平均订单完成率。笔记本记忆对分数的影响因模型而异：Claude 和 Qwen 的平均差为正，GPT 和 Gemini 的平均差为负。

1 引言

即使单个动作看起来合理，烹饪任务仍然可能失败。一名玩家可能切对了原料，却挡住了紧急订单所需要的砧板；或者站在沸腾的锅旁边等待，而不是到别处去干活。有效率的烹饪要求跟踪未完成的操作、分配互补的工作，并在设备和原料变得可用时修订日程。这提出一个更广的问题：视觉语言模型（VLM）能否利用视觉观察和结构化的任务信息，在订单截止时间之下协调相互依赖的工作？

Overcooked-AI 考察与人的合作（Carroll et al., 2019），MindAgent 研究多智能体任务分配（Gong et al., 2024），Collab-Overcooked 引入资源隔离和面向过程的评测（Sun et al., 2025）。视觉智能体基准评测游戏、具身环境和图形界面上的交互（Paglieri et al., 2025; Liu et al., 2025; Yang et al., 2025）。我们研究在具有不同空间与操作约束的厨房之间做集中式调度，并用一个共同的多模态接口把厨房状态、食谱、订单和玩家指派连接起来。

我们引入 DuoCook，一个在 Unreal Engine 中、受 Overcooked 启发的基准，由单个视觉语言模型从一个共享上下文控制两名玩家。它的 20 张地图跨越五个类别：基础、共享设备、动态、带共享设备的动态，以及分离的工作区（第 3.2 节），从而引入设备争用、地形变化和必需的交接。模型给两名玩家分配工作，以便在截止时间、随时间变化的小费和连击奖励之下最大化交付分数，使集中式协调成为评测目标。编码智能体通过 SimWorld Studio（Kang et al., 2026）构造厨房，随后是人工修整和演员契约核验（第 3.1 节）。

控制器接收一张俯视的厨房图像、道具图例、任务指令、实时状态信息和合法操作。模型选择动作和目的地坐标，而引擎处理导航。状态变化触发模型调用，在模型推理期间仿真暂停。因此这个接口在结构化状态辅助之下评测目的地选择和调度。

评测协议在全部五个类别的全部 20 张地图上比较四个视觉语言模型，报告总分、订单完成率、交付精度、动作接受率，以及每一回合的 API 支出。在同样的 20 张地图上做记忆消融，只去掉那本共享的、由模型自己撰写的笔记本，在保留所有其他输入的同时测量它对性能和 API 成本的影响。

本文做出两项贡献：

•

一个由 20 个智能体生成的厨房组成的基准，用于集中式的双人规划与协调，带有五个地图类别和一个共享的多模态接口。

•

一套评测协议，把五项性能、动作有效性和 API 成本指标，与对共享笔记本记忆的消融结合起来。

2 相关工作

2.1 烹饪环境与协作智能体

Overcooked-AI 研究与人的协调与合作（Carroll et al., 2019），而 ProAgent 使用语言模型来推断队友意图（Zhang et al., 2024a）。MindAgent 的 CuisineWorld 支持集中式多智能体调度（Gong et al., 2024），Collab-Overcooked 把资源隔离、不对称知识和通信结合起来，以评测相互依赖的协作（Sun et al., 2025）。DuoCook 在这些先例之上，用一个视觉上落地的控制器同时控制两名玩家，并用暴露资源和空间依赖的地图变体。它评测的是集中式调度，而不是对一个被独立控制的同伴做推断；单独的多厨师控制，或单独的必需交接，都不构成它的贡献。

ParaCook（Zhang et al., 2026）把烹饪任务表示为有向无环图，并测量并发执行效率。Robotouille（Gonzalez-Pumariega et al., 2025）考察异步的、长程的规划，而 Cookbench（Cai et al., 2025）把食谱准备与顾客意图识别结合起来。相关的规划基准包括用于图结构工作流的 WORKBENCH（Qiao et al., 2025）和 Plan-over-Graph（Zhang et al., 2025b）、用于对已知时长的任务排序的 AsyncHow（Lin et al., 2024），以及在交互环境中做调度的 TimeArena（Zhang et al., 2024b）。PACE（Huang et al., 2026）通过交错的推理与行动，使规划与执行重叠。这些方向为 DuoCook 的调度需求提供了信息，例如在汤煮着的时候去准备另一道菜。

2.2 视觉交互与游戏基准

Balrog 评测跨游戏的规划与探索（Paglieri et al., 2025），而 VisualAgentBench 覆盖具身交互、图形界面和视觉设计（Liu et al., 2025）。EmbodiedBench 覆盖语义任务、导航和操作（Yang et al., 2025）；VideoGameBench 评测原始的视觉游戏过程，包括一种暂停设定，把一部分推理延迟效应与动作选择分开（Zhang et al., 2025a）。DuoCook 聚焦烹饪工作流内部相互匹配的干预。它由引擎执行的导航、网格标签和结构化状态辅助控制器，因此分数不能与来自不同观察和控制接口的分数直接互换。

2.3 交互智能体的持久上下文

ReAct 利用交互反馈把推理与行动交错起来（Yao et al., 2023），而 Reflexion 跨试验存储言语反思（Shinn et al., 2023）。DuoCook 评测一本共享笔记本，里面是模型自己撰写的观察，并带有随时间衰减的保留。去掉这本笔记本，同时保留六条响应的动作历史以及当前的视觉与结构化输入，用来测试它对性能和推理成本的影响。

2.4 为评测而生成的环境

生成的环境可以支持智能体评测，也可以作为生成模型的输出。Procgen 使用程序生成的关卡来评测智能体泛化（Cobbe et al., 2020），而 MarioGPT 从文本生成 Mario 关卡（Sudhakaran et al., 2023）。在 DuoCook 中，编码智能体根据参考版式和构造指令建造 Unreal Engine 厨房，随后是人工修整和演员契约核验（第 3.1 节）。这一过程为评测烹饪控制器提供环境。

3 系统与任务设计

图 1 汇总基准工作流，从厨房构造到控制器执行和评测。

图 1：基准流水线。左：编码智能体的厨房构造、人工修整和演员契约核验。中：从共享的多模态输入联合控制两名玩家，以洋葱汤的准备为例。右：计时订单的评分，以及对分数、订单完成、交付精度、动作接受和 API 支出的评测。

3.1 用编码智能体生成地图

我们使用 SimWorld Studio 在 Unreal Engine 中构造厨房。它为编码智能体提供模型上下文协议（MCP）工具和用于场景配置与资产放置的 Markdown 技能。两个分开的 claude-opus-5 过程分别撰写生成提示和建造场景。撰写过程先审阅 SimWorld Studio 的架构，然后接收游戏上下文、一张参考图像，以及一份演员命名与场景结构契约。它产出一条构造提示，并带有一份完成核对清单，覆盖所需的器具和由视觉语言模型控制的 MetaHuman 角色。构造过程在能够访问游戏上下文、流水线代码、演员契约和参考图像的条件下执行这条提示。然后我们人工修整场景，并运行一个脚本来核验所需演员及其名称。人工编辑处理装饰、碰撞、可见性和相机配置。例如在一个卡车场景中，我们把石头移出卡车货台，调整俯视相机的偏航，增加一个等轴测相机，并拆掉一面卡车墙以露出厨房。

3.2 地图条件

该基准包含 20 张基于 Overcooked 版式的功能性地图，按设备共享、地形变化和物品传递分组。主评测使用全部 20 张地图；记忆消融使用同样的 20 张地图。附录 A 列出源关卡和评测子集。

所有地图都包含地板、柜台、原料箱、锅、盘子、砧板和出餐点。箱子、砧板和锅固定在柜台上，柜台阻挡移动，但支持放置食物和盘子。玩家移动、搬运并放置物体、切原料、把食物装盘，并上菜。上菜之后，在配备水槽的地图上，脏盘子出现在水槽里等待清洗；否则，干净盘子在它们的初始位置重新出现。地图类别改变这些操作所要求的协调。基础地图和共享设备地图的地形是固定的：前者允许独立完成订单，后者要求玩家共享砧板或锅等站点。动态地图引入每 1,000 步来回移动一次的柜台或地板区段，从而改变障碍或可通行地形；缺口保持不可进入，以防止坠落。四张动态地图要求设备共享，四张不要求。在分离的工作区中，玩家不能跨越区域，必须把原料或盘子从柜台对面递过去，因此任何一方都不能独自完成一道菜。

3.3 烹饪任务与控制器目标

单个视觉语言模型控制两名 MetaHuman 玩家，以便在回合时域内最大化准备并上菜所得的分数（第 4.1 节）。菜单包括沙拉和汤，食谱和订单队列按关卡配置。切菜和洗碗在执行期间占住一名玩家，而汤在无人看管时继续煮，从而允许并发工作。

#### 订单与评分。

订单每 1,000 步到达一次，在 3,000 步后过期，并且可以按任意顺序完成。每次交付获得 20 分，外加一个由连击乘数缩放的、随时间变化的小费：

其中 $w_{i}$ 是交付时的等待时间，$b(w_{i})$ 是基础小费（表 1），$m_{i}$ 遵循日程 $(1,1,2,3,4)$ ，并以上限 $4$ 封顶。交付累积连击；一张过期订单把连击重置为零。乘数只作用于小费。

表 1：未过期订单按已等待时间划分的基础小费。这些阈值对应于 3,000 步等待上限的 45%、70% 和 85%。

3.4 多模态智能体输入

控制器接收厨房图像，以及任务指令、实时状态、合法操作、执行反馈和六条响应的动作历史（图 2）。

在每次决策时，两名玩家共享一张带网格标签的俯视厨房图像、一份道具图例和文本上下文（图 2）。一条大约 4,000 词的、因地图片而异的系统提示提供厨房规则和食谱，使用仿真器的菜单，并在每次决策时重新发送。实时状态报告玩家动作、位置、手持物品和站点占用，以及订单和准备状态。游戏界面信息以文本提供，以减少对界面外观的依赖。引擎根据厨房状态和站点占用列出合法操作，而不按等待中的订单过滤；拒绝反馈解释失败，但不建议纠正计划。每名玩家的动作历史包含其最近六条响应，最新的在前，并带有动作、目标格子和执行是否被接受。这段历史在两种实验条件中都被保留。启用记忆的条件另外提供一本共享的、由模型自己撰写的笔记本（第 4.4 节）。

图 2：两种记忆条件都保留的输入组成部分。左：指令、实时状态 JSON、合法操作、六条响应的动作历史，以及执行反馈。右：一张带网格标签和锅指示器的俯视厨房图像，外加一份道具图例。启用记忆条件中额外使用的笔记本没有画出。

3.5 基于网格的导航与高层动作

每张地图有一个 $N\times M$ 网格，坐标为 rxcy，其中 $x$ 和 $y$ 表示行和列。原点按地图随机指定，然后固定；控制器阅读图像标签来定位目标（图 2）。命令把一个目的地坐标与一个动作配对，例如拾取、切菜或上菜。站点交互以站点格子为目标；引擎使用导航网格（NavMesh）处理接近过程，该网格排除柜台和缺口。不兼容的动作—目标配对以及不可到达的目的地会返回错误，供控制器修改并重试。状态变化事件触发视觉语言模型调用，包括动作或烹饪完成、订单到达或过期，以及地形变化。引擎更新观察，并在视觉语言模型推理期间暂停仿真。当一名玩家完成时，控制器为其指派下一个动作，同时保留另一名玩家正在进行的动作，该动作在推理之后继续。地形变化打断移动，促使控制器根据更新后的场景选择目的地和动作，并由引擎规划一条新路线。

4 实验

我们的评测考察单个模型如何在设备共享约束、变化的地形和必需的物品传递之下协调两名玩家。它由 20 张地图上的主基准，以及同样 20 张地图上的记忆消融组成。

4.1 评测设置

完整基准包含 20 张功能性地图。我们在跨越全部五个类别的同样 20 张地图上评测全部四个视觉语言模型，并在同样的 20 张地图上为全部四个模型比较记忆条件。附录 A 指定每个子集中的地图。消融覆盖全部五个类别。所有报告的汇总都指对应实验所包含的地图。

#### 被评测的模型。

模型名单由 gpt-6-astra、claude-opus-5、qwen3.8-27b 和 gemini-3.5-flash-lite 组成。每个模型通过单个控制器控制两名玩家，两名玩家可以并发行动。我们通过 OpenAI API 访问 gpt-6-astra，通过 Anthropic API 访问 claude-opus-5；qwen3.8-27b 和 gemini-3.5-flash-lite 通过 OpenRouter 访问。

#### 回合协议。

每个回合运行 4,000 步。这一时域适用于主基准和记忆消融。控制器调用跟随状态变化事件，仿真在推理期间暂停，如第 3.5 节所述。

对每张地图，初始状态、订单数量和订单序列是固定的，并在模型和记忆条件之间共享。每个模型在启用记忆的条件下，对 20 张主评测地图各运行一次。对消融，我们在同样的 20 张地图上复用这些结果，并让每个模型在关闭记忆的条件下对其中每张地图再运行一次。这些设置匹配起始条件和订单工作量；随后的轨迹取决于模型的动作。我们为每个回合计算指标，并在 20 张评测地图上等权平均。类别汇总只使用该类别中被评测的地图。对记忆消融，我们在 20 张地图的每一张上计算条件之间的差，然后平均这些配对差。由于每个模型、每张地图、每种条件只有一次运行，结果是描述性的，并不估计重复模型运行之间的变异。

4.2 评测指标

我们使用五项指标来测量任务性能、动作接受和推理成本。同样的指标适用于主基准和记忆消融。

#### 总分。

回合分数按照第 3.3 节的评分规则测量累积得分。每张完成的订单获得基础奖励和公式 1 中经连击调整的小费；订单可以按任意顺序完成。

#### 订单完成率。

令 $N_{\mathrm{completed}}$ 表示已完成订单数，$N_{\mathrm{orders}}$ 表示一个回合中的订单总数。订单完成率是

该指标测量控制器在回合时域内完成了多少订单工作量。

#### 交付精度。

令 $N_{\mathrm{correct}}$ 表示正确交付的次数，$N_{\mathrm{served}}$ 表示上菜的总次数。交付精度是

它测量满足订单的上菜尝试所占的比例，通过把成功交付与不成功的尝试区分开，来补充完成率。

#### 动作接受率。

令 $N_{\mathrm{accepted}}$ 表示被引擎接受的玩家命令数，$N_{\mathrm{issued}}$ 表示发出的命令总数。动作接受率是

命令按每名玩家分别计数，因此一次给两名玩家指派的响应贡献两条命令。每次重试都再计为一条发出的命令。拒绝包括不可到达的目的地和不兼容的动作—目标组合。被接受的命令即使后来被打断或没有推进订单，仍然被计数。因此该指标在所提供的接口下测量命令有效性，而分数和订单完成测量任务性能。没有发出命令的回合报告为 N/A。

#### 模型执行成本。

模型执行成本是一个回合期间花在模型 API 调用上的总金额，以美元（USD）报告。它包括所有被计费的调用，包括重试，以及图像输入和动作历史上下文的任何费用。我们在任务性能旁边报告每回合的平均 API 支出。

4.3 主基准评测

表 2：主基准性能，在 20 张地图上等权平均，每个模型每张地图一个回合。箭头给出偏好方向。交付精度排除没有交付的地图；$n$ 给出进入该均值的地图数。粗体标出每一列中所报告的最好均值。

图 3：按地图类别划分的平均订单完成。每一列等权平均该类别中的四张地图。

主评测使用上面描述的视觉观察、图例和记忆，在全部 20 张地图上比较四个模型。我们在表 2 中报告总体性能，并报告第 3.2 节所定义的每个地图类别的结果。五项指标捕捉性能的互补侧面：累积奖励、订单工作量的覆盖、交付正确性、动作接受和执行成本。

该基准远未饱和。最强的控制器完成订单工作量的 $26.2\%$ ，其余控制器完成 $8.8$ – $11.2\%$ ；大多数回合结束时什么也没有交付，其中包括 claude-opus-5 的 20 次里的 15 次，以及 qwen3.8-27b 的 20 次里的 14 次。因此控制器之间的差异，是低绝对能力水平之间的差异，而不是天花板效应。

gpt-6-astra 与其余模型明显分开，分数超过最近的替代方案的两倍，并在分数、订单完成和动作接受上领先。Claude 的交付精度最高，该精度是在它至少交付一道菜的五张地图上计算的。

两个类别构成最强的障碍。在把变化地形与共享设备结合起来的地图上，四个控制器中有三个没有交付任何菜；gpt-6-astra 是唯一的例外，它在该类别的全部四张地图上都有得分（平均分数 $29.0$ ）。在分离工作区的地图上，gpt-6-astra 再次在四张地图中的三张上得分，qwen3.8-27b 在一张上得分；claude-opus-5 和 gemini-3.5-flash-lite 在该类别它们的全部八个回合中什么也没有交付。带设备争用的地形变化，以及跨不相交工作区的必需交接，对除最强控制器以外的所有模型仍然几乎是完全的障碍。

在控制器确实有交付的地方，大多数交付的是正确的菜：claude-opus-5 的精度为 $100\%$ ，gpt-6-astra 为 $93.8\%$ ，qwen3.8-27b 为 $91.7\%$ ，gemini-3.5-flash-lite 为 $81.0\%$ 。这些精度估计排除零交付回合，并使用不同的地图子集，因此它们并不识别失败的原因。选择错误也可能阻止任何交付。动作接受和任务性能可能给模型排出不同的名次：claude-opus-5 有 $52.7\%$ 的时间发出有效命令，分数为 $8.2$ ，而 gemini-3.5-flash-lite 有 $32.1\%$ 的时间有效，分数为 $11.9$ 。这一比较促使我们同时报告两项指标，但并不建立它们的总体关联。成本跨越一个数量级以上，并且不跟随性能：最强的控制器也属于最贵的之列。

每个模型—地图结果来自单个回合，每个热图单元格平均四个这样的结果。我们报告描述性差异，而不估计逐次运行的变异。两个最难类别中的低性能，并不确立这些类别不可解。

4.4 记忆消融

图 4：共享记忆的效果，表示为 20 张消融地图上的配对差（有记忆减去无记忆）。（a）分数差：灰点是逐地图的差，标记是等权均值，并带有在重抽样地图上的 95% 百分位自助区间。（b）每种条件下每回合的 API 成本，对数尺度。区间重抽样的是地图而不是重复运行，因为每个模型—地图—条件的结果都是单个回合；它们汇总的是均值对重抽样所观察地图的敏感性，而不是单个地图效应的分布或逐次运行的变异。这些构造出来的地图并不是来自某个指定总体的随机样本，因此这些区间并不确立超出这一套件的泛化。

我们在全部 20 张地图上比较有共享记忆和没有共享记忆的控制器。启用记忆的结果复用对应的主基准回合。对每个模型和每张地图，关闭记忆的运行使用相同的初始状态和订单日程，只去掉共享记忆。

共享记忆是一本由两名玩家自己填写的笔记本。在任何一次决策中，一名玩家可以附上至多三条观察，每条是一个元组：网格格子、物体种类、状态，以及一条可选的自由文本备注。两名玩家在随后的每一次调用中读回得到的表，每个被观察的格子渲染成一行，每一行带有写下它的人的身份。条目按指数遗忘曲线衰减，半衰期为 600 步，并显示在三个置信带中（刚刚看到、相当确定、模糊）；来自同伴的传闻衰减速度是第一手观察的两倍。其中没有任何内容对照仿真器做校验：它记录的是信念，一行过时或错误的记录正是该条件所测试的一部分。

共享存储保存形式为（网格格子、物体种类、状态、可选备注、作者、写入步）的条目。条目以格子和种类为键，因此后来关于同一格子的写入会替换较早的那一条；这就是玩家纠正自己的方式，而一条状态为未知的写入则会删除该行。

信念随时间失去力量。对一条在步 $t_{i}$ 写下、在步 $t$ 被玩家 $p$ 读到的条目，保留率是

半衰期 $H=600$ 步，传闻比 $\rho=2$ 。因此玩家自己的观察在 600 步后保留一半力量，而从同伴那里读到的同一条观察在 300 步后保留一半。保留率只取决于条目的年龄和作者身份；它从不查阅仿真器状态，因此一个置信值不能编码玩家没有被告知的任何东西。

模型从不以数字形式看到保留率 $r_{i}^{(p)}(t)$ 。它被显示为三个有序带之一：高于 $0.75$ 为刚刚看到，高于 $0.45$ 为相当确定，高于 $0.20$ 为模糊；低于 $0.20$ 的条目从渲染的表中去掉。每一个留下来的行都标注它的带，以及读者是否写下了它。

存储至多保存 24 条，并且来自任何一个作者的至多 16 条。当超过上限时，最弱的信念先被逐出，按保留率排序，并用确定性的方式打破平局。逐出从不查阅仿真器：丢掉恰好在事实上错误的条目，会提供一份答案。这个上限刚好低于这些地图上可寻址物体的数量，因此即使存满，也不能相当于对关卡的完整描述。

共享记忆并不是均匀地有帮助。最清楚的收益属于 claude-opus-5，它获得 $+4.8$ 分（自助 95% 置信区间：在重抽样地图上为 $[+1.0,+9.4]$ ）；这是唯一一个所报告的自助区间不含零的模型。平均分数下降最大的是 gemini-3.5-flash-lite，平均差为 $-8.1$ 分（置信区间：$[-17.4,+1.8]$ ）。对 qwen3.8-27b（ $+1.4$ ，置信区间：$[-6.6,+9.4]$ ）和 gpt-6-astra（ $-2.7$ ，置信区间：$[-12.4,+7.0]$ ），区间跨越零。这些是描述性的地图重抽样汇总；没有任何一个区间量化跨模型运行的可重复性。

若按控制器究竟在哪些地图上有得分来计数，记忆把 claude-opus-5 从 3 张地图移到 5 张，把 gpt-6-astra 从 13 张移到 16 张，同时使 qwen3.8-27b 保持在 6 张不变，并把 gemini-3.5-flash-lite 从 11 张减到 7 张。对 Gemini 而言，有共享记忆时得到正分数的地图更少；汇总计数并不揭示逐张地图的转变。

一个假说是，笔记本与任务争夺注意力。对 gemini-3.5-flash-lite，动作接受率随记忆从 $56.4\%$ 降到 $32.1\%$ ，交付从 21 道菜降到 12 道。gpt-6-astra 的接受率也下降（ $70.3\%\rightarrow 64.6\%$ ），而它的菜品总数在两种条件下都保持为 23。这些汇总并不确立一种注意力机制；那种解释需要轨迹级证据。

记忆增加全部四个模型的平均 API 支出。Claude 和 Qwen 的平均分数差为正（ $+4.8$ 和 $+1.4$ ），尽管只有 Claude 所报告的自助区间不含零。GPT 和 Gemini 以更高的平均成本换来更低的平均分数。对 Claude 和 Qwen，所观察到的增益值不值得，取决于可接受的每一分改进的成本，以及它们在重复运行上的稳定性。

#### 条件。

两种条件只在一项上不同。两种观察都包含场景图像、道具图例、实时状态 JSON、操作列表、即时失败反馈和六条响应的动作历史；启用记忆的条件加上渲染出来的共享存储。动作历史出现在两种条件中：它由环境而不是模型写下，从不在玩家之间共享，并被保持固定，以便比较把共享的、自己撰写的记忆与单纯的新近性分开。

在启用记忆的回合中，一名玩家读到的条目有 40.1% 是由它的同伴写下的（ $26{,}750$ 条中的 $10{,}732$ 条）。这记录了同伴撰写的笔记本使用，但本身并不表明该信息不能通过其他输入获得。

这一设计测试一个共享且衰减的世界模型是否改进联合性能，并测量维护和阅读它所增加的推理成本。两种条件都使用五项基准指标，并在同样的 20 张地图上汇总。

5 局限

集中式的双人控制，把通信、私有信息，以及对独立队友的适应留在主要评测之外。俯视观察和引擎导航降低了第一人称感知或直接运动控制下会存在的要求。道具图例、锅指示器、实时状态 JSON，以及引擎计算的合法操作列表，提供了额外的信息和辅助。因此结果反映的是在这一组合接口下的规划，包括在合法操作中选择以推进等待中的订单。

地图之间的差异可以反映若干任务属性，因此跨地图条件的性能并不能分离资源共享的效应。评测也没有分离视觉图例或锅指示器的贡献，它们保持固定。记忆消融考察在保留动作历史的同时增加一本共享笔记本的效果，但记忆也可以改变词元用量和延迟。

每个模型在每张地图和每种记忆条件下只运行一次。固定的初始状态和订单序列提供了匹配的情景，但单次运行并不量化模型响应中的变异，也不确立模型排名和记忆效应在重复运行上的稳定性。

生成的地图尽管视觉上有变化，仍可能重复结构模式。在定义留出评测时，必须考虑共享的生成来源和相似的版式。新地图也不能保证食谱或任务概念没有出现在模型预训练中。超出所测试厨房分布的泛化，包括迁移到真实的协作工作，需要额外的证据。

支撑性的回合日志、逐地图指标表和分析脚本没有包含在当前文稿的产物中。单独的汇总结果不能支持基于轨迹的失败诊断，也不能支持对所报告效应的独立重算。

6 结论与未来工作

本文发展了一个受 Overcooked 启发的基准的设计，用于在智能体生成的 Unreal Engine 厨房中做视觉规划和集中式协调。它的 20 张地图跨越五个类别，覆盖独立工作、共享设备、变化地形和必需的物品传递。评测协议在全部 20 张地图上用任务性能、动作接受和 API 成本比较四个视觉语言模型，并在同样的 20 张地图上做记忆消融。实验结论适用于这一被评测的套件。这提供了一种具体的方式，来研究控制器如何把视觉观察变成协调的烹饪动作。

gpt-6-astra 取得最高的平均分数（25.6）、订单完成率（26.2%）和动作接受率（64.6%），而 Claude 在有交付的回合中具有最高的交付精度。性能仍然很低，尤其是在带共享设备的动态地图上，以及分离工作区的地图上。共享笔记本记忆增加每个模型的平均 API 成本，并对分数有混合效应：Claude 和 Qwen 在所观察的均值上改进，而 GPT 和 Gemini 下降。这些结果描述的是每个模型、每张地图、每种条件一次运行；需要重复运行来评估这些差异的稳定性。

人工智能使用声明

我们使用 claude-opus-5 来撰写场景生成提示并构造基准地图，如第 3.1 节所述。我们也使用人工智能工具来润色文稿。

参考文献

• Cai et al. (2025) M. Cai, X. Chen, Y. An, J. Zhang, X. Wang, W. Xu, W. Zhang, and T. Liu Cookbench：面向复杂烹饪情景的长程具身规划基准。arXiv preprint arXiv:2508.03232。

• Carroll et al. (2019) M. Carroll, R. Shah, M. K. Ho, T. Griffiths, S. Seshia, P. Abbeel, and A. Dragan 了解人类对人类与人工智能协调有什么用。Advances in neural information processing systems 32。

• Cobbe et al. (2020) K. Cobbe, C. Hesse, J. Hilton, and J. Schulman 用程序生成来给强化学习做基准。In International conference on machine learning, pp. 2048–2056。

• Gong et al. (2024) R. Gong, Q. Huang, X. Ma, Y. Noda, Z. Durante, Z. Zheng, D. Terzopoulos, L. Fei-Fei, J. Gao, and H. Vo Mindagent：涌现的游戏交互。In Findings of the Association for Computational Linguistics: NAACL 2024, pp. 3154–3183。

• Gonzalez-Pumariega et al. (2025) G. Gonzalez-Pumariega, L. Yean, N. Sunkara, and S. Choudhury Robotouille：面向大语言模型智能体的异步规划基准。In International Conference on Learning Representations, Vol. 2025, pp. 83757–83792。

• Huang et al. (2026) Y. Huang, X. Ying, Z. Ma, X. Yuan, Z. Gao, J. Huang, R. Mao, J. Zhang, H. Ti, M. Tian, et al. PACE：为省时的具身规划做自适应预算分配。arXiv preprint arXiv:2608.03034。

• Kang et al. (2026) H. Kang, X. Ye, Y. Liu, S. H. Mantri, L. Mao, J. Fleming, D. Regmi, and L. Qin SimWorld Studio：用不断演化的编码智能体自动生成环境，以供具身智能体学习。arXiv preprint arXiv:2605.09423。

• Lin et al. (2024) F. Lin, E. L. Malfa, V. Hofmann, E. M. Yang, A. G. Cohn, and J. B. Pierrehumbert 图增强的大语言模型在异步计划推理中的应用。In Proceedings of the 41st International Conference on Machine Learning, ICML’24。

• Liu et al. (2025) X. Liu, T. Zhang, Y. Gu, I. L. Iong, Y. Xu, X. Song, S. Zhang, H. Lai, X. Liu, H. Zhao, J. Sun, X. Yang, Y. Yang, Z. Qi, S. Yao, X. Sun, S. Cheng, Q. Zheng, H. Yu, H. Zhang, W. Hong, M. Ding, L. Pan, X. Gu, A. Zeng, Z. Du, C. H. Song, Y. Su, Y. Dong, and J. Tang VisualAgentBench：走向作为视觉基础智能体的大型多模态模型。In International Conference on Learning Representations, Vol. 2025, pp. 95650–95707。

• Paglieri et al. (2025) D. Paglieri, B. Cupiał, S. Coward, U. Piterbarg, M. Wołczyk, A. Khan, E. Pignatelli, Ł. Kuciński, L. Pinto, R. Fergus, et al. Balrog：在游戏上给智能体式大语言模型和视觉语言模型的推理做基准。In International Conference on Learning Representations, Vol. 2025, pp. 96666–96702。

• Qiao et al. (2025) S. Qiao, R. Fang, Z. Qiu, X. Wang, N. Zhang, Y. Jiang, P. Xie, F. Huang, and H. Chen 给智能体式工作流生成做基准。In International Conference on Learning Representations, Vol. 2025, pp. 69679–69703。

• Shinn et al. (2023) N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao Reflexion：带言语强化学习的语言智能体。Advances in neural information processing systems 36, pp. 8634–8652。

• Sudhakaran et al. (2023) S. Sudhakaran, M. González-Duque, M. Freiberger, C. Glanois, E. Najarro, and S. Risi MarioGPT：通过大语言模型做开放式的文本到关卡生成。Advances in Neural Information Processing Systems 36, pp. 54213–54227。

• Sun et al. (2025) H. Sun, S. Zhang, L. Niu, L. Ren, H. Xu, H. Fu, F. Zhao, C. Yuan, and X. Wang Collab-Overcooked：把大语言模型作为协作智能体来做基准与评测。In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 4922–4951。

• Yang et al. (2025) R. Yang, H. Chen, J. Zhang, M. Zhao, C. Qian, K. Wang, Q. Wang, T. V. Koripella, M. Movahedi, M. Li, et al. EmbodiedBench：对视觉驱动的具身智能体所用多模态大语言模型做全面基准。arXiv preprint arXiv:2502.09560。

• Yao et al. (2023) S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao ReAct：使语言模型中的推理与行动协同。In The Eleventh International Conference on Learning Representations, , Document

• Zhang et al. (2025a) A. L. Zhang, T. L. Griffiths, K. R. Narasimhan, and O. Press VideoGameBench：视觉语言模型能通关流行电子游戏吗？arXiv preprint arXiv:2505.18134。

• Zhang et al. (2024a) C. Zhang, K. Yang, S. Hu, Z. Wang, G. Li, Y. Sun, C. Zhang, Z. Zhang, A. Liu, S. Zhu, et al. ProAgent：用大语言模型构建主动协作智能体。In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38, pp. 17591–17599。

• Zhang et al. (2025b) S. Zhang, X. Ma, Z. Cao, Z. Zhang, and H. Zhao Plan-over-Graph：走向可并行的大语言模型智能体日程。arXiv preprint arXiv:2502.14563。

• Zhang et al. (2026) S. Zhang, X. Ma, Y. Xu, Z. Cao, P. Lu, H. Yuan, T. Shen, Z. Zhang, H. Zhao, and M. Yang ParaCook：论多智能体系统中省时的规划。In Findings of the Association for Computational Linguistics: ACL 2026, pp. 27683–27701。

• Zhang et al. (2024b) Y. Zhang, S. Yuan, C. Hu, K. Richardson, Y. Xiao, and J. Chen TimeArena：在具备时间意识的仿真中塑造高效的多任务语言智能体。In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 3894–3916。

附录 A 地图对应

表 3 列出全部 20 张功能性地图及其评测归属。主基准和记忆消融都使用全部 20 张地图。

评测标识符用下划线代替源关卡中的连字符，例如 1_3。Festive 1-6 和 Festive 1-7 对应于 festive_1_6 和 festive_1_7；Kevin 1 对应于 kevin_level_one。

表 3：源关卡对应关系与评测归属。主评测指完整的 20 张地图主评测；记忆指 20 张地图上的记忆消融。

附录 B 样例场景生成提示

Overcooked 关卡 2-1 提示 Overcooked 关卡 2-1 生成图像提示：

Overcooked 关卡 2-1——沙漠公路上的两辆平板卡车

目标：/Game/SavedScenes/overcooked_level_2_1

参考：overcooked_level_2_1.png（Overcooked 2，关卡 2-1）

目标：一个约有 149 个演员的关卡，两辆平板卡车的货台在沙漠公路上并排，沿道路错开，中间是敞开的沥青路面，恰好由两条跳板跨越。

北侧（红色）卡车负责烹饪和上菜：3 个炉灶、3 个干净碗、传送带，以及盘子回收处。

南侧（蓝色）卡车负责备料：3 个原料站、2 块砧板，以及一长排空闲柜台。

两辆卡车都使用真实的驾驶室网格（SM_vehTruck_vehicle08_No_Wheel），每辆有 6 个真实车轮网格，位置取自骨骼网格的插槽。其余一切（甲板、裙板、墙壁、栏杆、跳板）都用 Cube / Plane 图元搭建，并施加材质。

沙漠要看得出是沙漠：沥青、车道漆、护栏、仙人掌、平顶山。

任何标识都不要——一个站点就是它的演员标签，除此之外什么都没有。

关键设计决定：

（1） 甲板位于 z = 0；路面在其下方 150 个单位（z = -150），因此全部标准厨房坐高（柜台 100、灶台 100、碗 104.17，等等）保持不变。

（2） 两车之间的缺口是真正敞开的路面——不是壕沟——只由两条跳板跨越。不要加宽缺口，也不要增加第三条通道；这个瓶颈正是本关的要点。

（3） 全部三种原料都在蓝色卡车上，全部三个炉灶都在红色卡车上，因此每一道菜至少要过两次跳板。

布局：建在一个 13 行 × 9 列的网格上（BP_Grid，格子尺寸 102 cm）。红色卡车占据第 1–4 列、第 1–9 行。蓝色卡车占据第 6–9 列、第 5–13 行。第 5 列是敞开的缺口。柜台、炉灶、砧板和原料站放在特定格子上，遵循标准厨房调色板（/Game/KitchenAssets/、/Game/kitchenDatabase/Interactable/）——绝不用项目其他地方看起来相似的资产代替。

相机：俯视相机位于 (600, 561, 1500)，俯仰 -90，偏航 -90，焦距 28 mm——相对网格的真实中心有偏移，以免红色卡车伸到网格西侧之外的驾驶室被切出画面。

交付物：完成的关卡，对照一份实测核对清单核验（演员数量、坐高、标签 / 标注正确性、开局时隐藏的状态道具），外加一张与参考图像对照的俯视截图。

Overcooked 关卡 6-4 提示 Overcooked 关卡 6-4 生成图像提示：

Overcooked 关卡 6-4——"空间站：对接环"——场景提示

目标：/Game/SavedScenes/overcooked_level_6_4

参考：overcooked_level_6_4.png（Overcooked! 2 关卡 6-4）

目标：一座约有 52 个演员的厨房空间站：一个用于烹饪的中央枢纽，西、东两个侧模块通过短走廊与之对接，分别用于上菜和备料，以及南北两个不可到达的装饰性环形舱，在这一版建造中从不转动——空间站保持静止。

站点：

枢纽北侧一排有 4 个炉灶，每个都带完整的锅 / 锅铲 / 锅柜台叠放（stove_1 ..4，标签 Stove_1 ..4）。

枢纽中央一个 2×2 的岛上有 2 块砧板和刀。

3 个原料站（生菜在西，洋葱和番茄在东），每个都有一个拾取点、2 个完整原料道具和 2 个切片原料道具。

西侧模块有 1 条传送带和推动器（菜品向西送出）；东侧的"舱口"是装饰——只是普通柜台。

枢纽南侧一排有 1 个水槽；西侧模块有 1 个盘子回收处。

4 个干净碗（西侧 2 个，东侧 2 个）。

布局：建在一个 18 列 × 7 行的网格上（BP_Grid，102 cm 格子）。西侧模块（第 1–4 列）和东侧模块（第 15–18 列）经由走廊（第 5–6 列和第 13–14 列）对接中央枢纽（第 7–12 列）。两个环形舱位于网格之外的南北两侧，封闭且仅作装饰。

关键设计决定：

（1） 空间站不旋转——两个侧模块始终保持对接，与参考图的单帧一致。

（2） 全部灶台物品（参考图中的锅和平底锅）都变成相同的炉灶站点，以求一致。

（3） 只建造一条传送带和一个盘子回收处（西侧模块）；参考图东侧的第二个舱口 / 回收处表现为普通的、无功能的柜台。

（4） 原料：生菜（西侧板条箱）、洋葱（东侧板条箱），以及番茄（加到东侧柜台上，因为参考图北侧舱的板条箱不可到达）。

（5） 装饰（天空盒、驶过的飞船、舱内板条箱 / 控制台、船体管道）最后添加，只用来自现有库的资产——绝不用图元搭建，并且始终关闭碰撞。

结构：地板、墙壁和金属船体板定义三个房间和两条走廊，全部由图元搭建（这是唯一允许使用图元的地方）。五个不可见的碰撞阻挡体封住不可行走的空格子，使关卡不会把可走空间漏到预定房间之外。

光照：没有天空大气或雾（这里是太空）——光照来自一盏定向"太阳"、一盏天光，以及分布在空间站各房间中、为了看得清而放置的五盏点光源。

相机：一台俯视相机和一台等轴测相机，两者都框住包括两个环形舱在内的整个空间站，放在专门的 "Cameras" 大纲文件夹里。

交付物：完成的关卡，每个站点都在场并正确标注 / 打标签，道具稳妥地放在各自表面上，状态道具（生的 / 切过的原料、锅中汤道具、脏碗）在关卡打开时隐藏，对照一份实测核对清单核验，外加与参考图像对照的俯视和等轴测截图。

Overcooked 节日关卡 1-7 提示 Overcooked 节日关卡 1-7 生成图像提示：

Overcooked 节日关卡 1-7——"冰溪小屋"——场景提示

目标：/Game/SavedScenes/overcooked_festive_level_1_7

参考：overcooked_level_festive_1_7.png（Overcooked! 节日关卡）

目标：一座约有 90 个演员的木屋厨房，被一条东西向横过地板的冰溪分成两半。一座人字形砌块桥在房间中部跨过冰溪，第二条走道沿西墙向上。厨房的每一半都是另一半的镜像，由这座桥以及房间东端一条可走的窄带连接。

站点：

2 个炉灶，每一半一个，每个都带完整的锅 / 锅铲 / 锅柜台叠放（stove_1、stove_2）。

2 块砧板和刀，每一半一块。

2 个原料站：洋葱（北半，来自参考图的胡萝卜板条箱）和肉（南半）。

东墙上 2 条分开的传送带和推动器，每一半一条——菜品经两个滑槽向东送出。

1 个水槽（东北角）和 1 个盘子回收处（东墙，北半）——无水槽式回收，使用单个隐藏的脏碗道具。

2 个干净碗，每一半一个。

布局：一个 14 列 × 9 行的网格（BP_Grid，102 cm 格子）。南北两排柜台隔着房间相对；冰溪横切中间两行，除桥和东墙处的敞开窄带外，对移动封闭。

关键设计决定：

（1） 用两个炉灶，而不是参考图里的单个灶台，使被分开的厨房每一半都有自己的炉灶——水的每一侧一个。

（2） 两种原料：北半是洋葱，南半是肉，各自有自己的砧板。

（3） 参考图中的 "bin" 物体变成普通的、无功能的柜台；水壶、灭火器和彩球架只是装饰。

（4） 冰溪由水面加一个不可见的碰撞阻挡体建成——厨师只能经桥或东端窄带通过，绝不能穿过水面。

（5） 库里没有现成的圣诞资产（没有雪人、花环或彩球网格）——节日感来自温暖的串灯光照衬着室外的蓝雪，而不是字面的饰物。

结构：石地板（故意用冷色调，不用暖色，以便和木柜台、木墙区分开）、四面带窗带的木墙，以及积雪的外部，全部由图元搭建——这是唯一允许使用图元的地方。其余一切都是库资产。

光照：室内是温暖的串灯和壁炉式点光源，一盏昏暗、偏冷的定向"太阳"加上雾，营造蓝调时分的冬日气氛，冰溪本身沿途有一小圈冷光。

相机：一台俯视相机和一台等轴测相机，都放在专门的 "Cameras" 文件夹里，框住包括冰溪在内的整个房间。

交付物：完成的关卡，两套烹饪 / 备料 / 上菜布置都完整且标注正确，全部道具稳妥地放在各自表面上，状态道具（切片原料、煮好的汤叠加层、脏碗）在关卡打开时隐藏，厨房的两半都能从两个厨师出生点到达，对照一份实测核对清单检查，外加与参考图像对照的俯视和等轴测截图。