A curated collection of embodied planning methods, benchmarks, and detailed paper notes—built to support and grow the embodied planning community. 面向具身规划社区：整理方法、基准与详细论文笔记，推动社区发展。
Legend
-
：该论文/项目的开源代码仓库（实现、训练脚本、数据处理、复现说明等）。
-
：论文对应的项目主页（通常包含摘要、方法图、Demo 视频、交互展示、补充材料与下载链接）。
-
：仓库创作者整理的详细论文阅读笔记/记录（对论文进行梳理与介绍，例如：核心贡献、方法框架、实验设置与结果解读、关键公式/模块）。
-
🌿=CCF-AorICLR -
🍃=CCF-B -
🌱=CCF-C -
⭐= others / unclassified
- [2025.10|⭐ Arxiv] ParaCook: On Time-Efficient Planning for Multi-Agent Systems
- [2025.08|⭐ Arxiv] AgentWorld: an interactive simulation platform for scene construction and mobile robotic manipulation
- [2025.06|🌿 CCF-A ACL] AmbiK: dataset of ambiguous tasks in kitchen environment
- [2025.07|⭐ Arxiv] CookBench: a long-horizon embodied planning benchmark for complex cooking scenarios
- [2025.02|⭐ Arxiv] EmbodiedBench: comprehensive benchmarking multi-modal large language models for vision-driven embodied agents
- [2025.07|⭐ Arxiv] EmbRACE-3K: embodied reasoning and action in complex environments
- [2025.02|⭐ Arxiv] ET-plan-bench: embodied task-level planning benchmark towards spatial-temporal cognition with foundation models
- [2025.08|⭐ Arxiv] Large VLM-based vision-language-action models for robotic manipulation: a survey
- [2024.10|🌿 ICLR] PARTNR: a benchmark for planning and reasoning in embodied multi-agent tasks
- [2024.07|🍃 CCF-B ECCV] ReALFRED: An Embodied Instruction Following Benchmark in Photo-Realistic Environments
- [2021.03|🌿 ICLR] ALFWorld: Aligning Text and Embodied Environments for Interactive Learning
- [2020.06|🌿 CCF-A CVPR] ALFRED: A Benchmark for Interpreting Grounded Instructions for Everyday Tasks
- [2018.06|🌿 CCF-A CVPR] VirtualHome: Simulating Household Activities Via Programs
- [2021.03|🌿 CCF-A AAAI] TEACh: Task-driven Embodied Agents that Chat
- [2018.09|🌿 CCF-A CVPR] IQA: visual question answering in interactive environments
- [2026.03|⭐ Arxiv] From Word to World: Can Large Language Models be Implicit Text-based World Models?
- [2025.02|🌿 CCF-A CVPR] Magma: A Foundation Model for Multimodal AI Agents
- [2024.10|🍃 CCF-B ECCV] Octopus: embodied vision-language programmer from environmental feedback
- [2025.01|⭐ Arxiv] P3Nav: a unified framework for embodied navigation integrating perception, planning, and prediction
- [2025.07|⭐ Arxiv] World-aware planning narratives enhance large vision-language model planner
- [2024.12|⭐ Arxiv] DaDu-E: Rethinking the Role of Large Language Model in Robotic Computing Pipeline
- [2023.07|⭐ Arxiv] Embodied task planning with large language models
- [2023.05|🍃 CCF-B ICRA] Code as Policies-Language Model Programs for Embodied Control
- [2017.07|🍃 CCF-B EMNLP] Mapping instructions and visual observations to actions with reinforcement learning
- [2017.08|🌿 CCF-A ICCV] Visual semantic planning using deep successor representations
官方主页： https://code-as-policies.github.io/
-
任务：将自然语言指令转换为可执行的机器人控制代码
-
方法“代码即策略”（Code as Policies，CaP）核心是利用大型语言模型（LLM）将自然语言指令转换为可执行的机器人代码。方法可以分为高层级和低层级两个方面。
- 高层级：
- 用户交互： 用户通过自然语言指令与机器人进行交互，例如“将积木堆叠在空碗里”。
- 指令解析： LLM 将自然语言指令解析为高级代码逻辑，例如确定哪些物体需要移动，目标位置在哪里等等。
- 策略代码生成： LLM 生成调用底层 API 的 Python 代码，实现具体操作。
- 代码执行： 系统执行生成的代码，控制机器人的动作。
- 低层级：
-
感知 API： 提供对机器人感知能力的访问接口，例如物体检测、位置识别、颜色识别等。LLM 可以调用这些 API 获取环境信息，例如获取某个物体的名称、位置、颜色等。
-
控制 API： 提供对机器人控制能力的访问接口，例如移动、抓取、放置等。LLM 可以调用这些 API 控制机器人的具体动作，例如将某个物体移动到指定位置。 代码即策略方法的关键在于将高级指令解析与底层 API 调用结合起来，实现端到端的机器人控制
-
- 高层级：
先生成完整的可执行代码，再让机器人一次性执行该代码
- 使用第三方库：LLM 可以利用第三方库（例如 NumPy）进行空间推理和计算，例如计算点之间的距离，判断物体之间的位置关系等。
- 调用自定义函数：可以通过提示工程，让 LLM 学习调用自定义的函数，例如定义一个函数来获取某个物体的颜色，然后在代码中调用这个函数。
-
控制流：LLM 可以使用控制结构（例如 if-else 语句和循环语句）来实现复杂的控制逻辑，例如当满足某个条件时才执行某个动作。
-
函数嵌套：LLM 可以嵌套调用多个函数，实现多步骤的复杂任务。
-
分层代码生成： 可以提示 LLM 递归地定义新的函数，从而生成更复杂和结构化的代码。例如，可以先定义一个函数来识别某个物体，然后定义另一个函数来将该物体移动到指定位置。
通过分层代码生成，可以将复杂的任务分解成多个简单的子任务，提高代码的可读性和可维护性。 总而言之，CaP 方法为机器人控制提供了一种新的思路，通过利用 LLM 的强大能力，可以更灵活地控制机器人完成各种任务。
这篇文章提到了用于测试的两个代码生成数据集：
-
评价指标：通过率，即生成的代码通过人工编写的单元测试的百分比。
-
RoboCodeGen: 这是一个由文章作者团队创建的全新数据集，专门用于测试与机器人相关的代码生成能力。
- 它包含 37 个函数生成问题，涵盖空间推理、几何推理和控制等方面，例如寻找最接近一组点的点、检查一个边界框是否包含在另一个边界框中、PD 控制等。
- 数据集鼓励使用第三方库（例如 NumPy）。
- 提供的函数头没有文档字符串或显式类型提示，因此 LLM 需要推断和使用通用约定。
- 允许使用尚未定义的函数，可以使用分层代码生成创建。
-
HumanEval : 这是一个标准的代码生成基准测试，包含通用的代码生成问题。文章使用它来评估分层代码生成方法在通用代码生成问题上的效果。
除了这两个数据集，文章还进行了其他实验，例如使用 CaP 方法在模拟环境和真实机器人上完成各种任务，并在附录中提供了更多示例和结果。
参考链接：
不同工作可能对AI2Thor的版本有需求
ALFRED官方GitHub（重要）：https://github.com/askforalfred/alfred?tab=readme-ov-file
ALFRED官方Github中数据下载部分（重要）：https://github.com/askforalfred/alfred/tree/master/data 数据要下载全部数据
AI2Thor技术文档（重要）：https://ai2thor.allenai.org/ithor/documentation
AI2Thor安装文档：https://allenai.github.io/ai2thor-v2.1.0-documentation/installation#
AI2Thor官网：https://ai2thor.allenai.org/
7类任务，2685个任务，每个任务三个专家演示
8055个专家演示，每个演示平均50个动作（训练模型时，以RGB图片的形式使用）
一个演示对应多个英文指令，共有25743个英文指令。每个指令对应多个步骤，一个步骤对应一个图-动作对，共含有428322个图-动作对。
基于AI2Thor2.0，58种物体，26种容器，含有120个室内场景，包含厨房、卫生间、卧室、客厅场景
AI2Thor2.0中支持的13个原子动作：
5 navigation actions: MoveAhead, RotateRight, RotateLeft, LookUp, and LookDown together with
7 interaction actions: Pickup, Put, Open, Close, ToggleOn, ToggleOff
这是github中文件结构
data/train/task_type-object-movableReceptacle-receptacle-sceneNum/trial_ID/ (根目录 trajectory root)
data/train/task_type-object-movableReceptacle-receptacle-sceneNum/trial_ID/traj_data.json (专家演示数据 trajectory metadata)
data/train/task_type-object-movableReceptacle-receptacle-sceneNum/trial_ID/feat_conv.pt (由ResNet18编码的图像特征向量 Resnet18 features)
data/train/task_type-object-movableReceptacle-receptacle-sceneNum/trial_ID/problem_x.pddl (pddl文件 pddl state)
data/train/task_type-object-movableReceptacle-receptacle-sceneNum/trial_ID/video.mp4 (视频演示 video sequence)
data/train/task_type-object-movableReceptacle-receptacle-sceneNum/trial_ID/raw_images/ (专家演示数据过程中的对应的视觉图片信息 images from trajectory)接下来将介绍json文件和pddl文件中的内容。
其中json中的数据格式为：
- 图片对应高阶指令index
- 图片对应低阶指令index
- 图片文件名
['images'] = [
{
"low_idx": 0, (low-level action index，低阶动作指令标号）
"high_idx": 0, (high-level action index，高阶动作指令标号）
"image_name": "000000000.jpg"
}， (image filename，图片文件名称)
{
"high_idx": 0,
"image_name": "000000001.png",
"low_idx": 0
},
...
]- 任务id
- 任务种类
- pddl参数
"task_id": "trial_T20190908_144933_600228", # 唯一任务id
"task_type": "look_at_obj_in_light", # 七个任务种类之一
"pddl_params": {
"mrecep_target": "", # 容器
"object_sliced": false, # 是否切片
"object_target": "AlarmClock", # 目标操作物体
"parent_target": "", # 可移动容器
"toggle_target": "DeskLamp" # 切换对象
}"mrecep_target"：
- 表示目标的 可操作容器（Manipulatable Receptacle），例如一个机器人需要将某些物体放入容器（如碗、篮子）时会指定这个字段。
- 值为 "" 说明该任务中没有特定的容器目标。
- 示例任务：如果值是 "Drawer"，可能指需要将某个物体放入抽屉中。
"object_sliced"：
- 布尔值，表示目标物体是否需要被切片（Sliced）。
- 值为 false 表示当前任务不涉及切割物体。
- 示例任务：如果是食物处理任务（如切割苹果或土豆），该值可能为 true。
"object_target"：
- 表示目标物体（Target Object），当前任务涉及的具体物体。
- 值为 "AlarmClock"，说明任务的目标物体是闹钟。
- 示例任务：机器人可能需要找到闹钟并移动到某个地方。
"parent_target"：
- 表示目标物体的 父容器或父对象，即目标物体可能隶属于或附着的对象。
- 值为 "" 表示当前任务中目标物体不依赖任何父对象。
- 示例任务：如果该值是 "Desk"，可能意味着目标是从桌子上拿取某个物体。
"toggle_target"：
- 表示任务中需要操作（如打开/关闭、切换）的目标对象。
- 值为 "DeskLamp"，说明任务涉及操作台灯，例如打开或关闭台灯。
- 示例任务：机器人可能需要找到台灯，并执行“打开”或“关闭”的操作。
1. 场景编号
2. 随即种子
3. 机器人位置、转向
4. 每个物体位置、转向
5. 某些物体状态信息
"scene": {
"dirty_and_empty": false, # 表示场景是否为空或脏乱。false 表示场景正常且包含各种物体和布局。
"floor_plan": "FloorPlan303", # 场景的标识符，"FloorPlan303" 表示这是 AI2-THOR 提供的第 303 号预定义场景。
"init_action": {
"action": "TeleportFull", # 指示初始化机器人的位置和朝向。在 AI2-THOR 中，TeleportFull 是一种直接设置机器人位置的命令，用于重置机器人状态。
"horizon": 30, # 表示机器人摄像头的垂直视角，单位为度（°）。30° 说明摄像头略微向下倾斜，方便观察低处的物体。
# 在 AI2-THOR 模拟环境中，"传送"（Teleport）是指将机器人直接移动到场景中的某个指定位置，而不是通过逐步移动（如 MoveAhead 或 RotateRight）达到该位置。
"rotateOnTeleport": true, # 表示在传送时，是否让机器人旋转到指定的朝向。true：传送后，机器人会调整到 rotation 指定的方向。false：传送后，机器人保持传送前的朝向。
"rotation": 0, # 指定机器人在传送后的朝向，单位是度（°）。0：面向正北（场景的默认方向）。90：面向正东。-90 或 270：面向正西。
"x": 1.5, # 机器人在 3D 场景中的坐标位置：x 机器人在水平方向（左右）的位置。
"y": 0.901000142, # y 机器人摄像头的高度。
"z": -0.25 # z 机器人在纵深方向（前后）的位置。
},
"object_poses": [ # 列表形式描述了场景中每个物体的初始位置和旋转信息。
{
"objectName": "Mug_79472253",
"position": {
"x": 1.19420123,
"y": 0.0528196432,
"z": -2.28225541
},
"rotation": {
"x": 0.0,
"y": 0.0,
"z": 0.0
}
},
...
},
{
"objectName": "Mug_79472253",
"position": {
"x": -1.51596332,
"y": 0.5971,
"z": -0.2509424
},
"rotation": {
"x": 0.0,
"y": 0.0,
"z": 0.0
}
}
],
"object_toggles": [ # 描述场景中某些物体的状态信息，例如开/关、是否被操作等。
{
"isOn": false, # 表示台灯（DeskLamp）当前是关闭状态。
"objectType": "DeskLamp"
}
],
"random_seed": 3597013723, # 用于初始化场景中的随机元素。确保在不同的实验中可以复现相同的物体布局和初始状态。
"scene_num": 303 # 当前场景的编号，与 floor_plan 对应。
},
这块定义了一个任务的完整执行计划，分为两部分：
- 子任务高层次动作（high_pddl）：
- 描述了子任务的语义目标，每个目标表示一个逻辑上的子任务。
- 每个高层次计划都包含一个动作类型（如 GotoLocation、PickupObject）及其目标物体或位置。
- 低层次动作（low_actions）：
- 每个高层次子目标通过一系列低层次的具体操作来实现，例如移动、旋转、拾取物体等。
- 低层次动作提供了机器人在执行子目标时的具体动作序列。
['plan'] = {
###################################################################### 以下是高阶动作 #############################################3
"high_pddl": [
{
"discrete_action": { # 子目标高层次动作的类型（action）和参数（args）。
"action": "GotoLocation",
"args": [
"desk"
]
},
"high_idx": 0, # 子目标索引，用于关联高层次目标和低层次动作
"planner_action": { # 包含 PDDL 计划中生成的动作和额外参数信息
"action": "GotoLocation",
"location": "loc|-5|1|3|60" # x,y,z轴位置 + 转向角度
}
},
{
"discrete_action": {
"action": "PickupObject",
"args": [
"alarmclock"
]
},
"high_idx": 1,
"planner_action": {
"action": "PickupObject",
"coordinateObjectId": [
"AlarmClock", # 描述目标物体的空间位置和尺寸信息
[
-7.12072564, # 物体在X轴上的范围
-7.12072564,
0.12785292, # 物体在Y轴上的范围
0.12785292,
2.397561072, # 物体在Z轴上的范围
2.397561072
]
],
"coordinateReceptacleObjectId": [
"Desk",
[
-6.84, # 容器在X轴上的范围
-6.84,
-1.496, # 容器在Y轴上的范围
-1.496,
0.0, # 容器在Z轴上的范围
0.0
]
],
"forceVisible": true, # 设置为 true，表示目标物体（闹钟）在执行 PickupObject 动作前必须在机器人视野内。
"objectId": "AlarmClock|-01.78|+00.60|+00.03" # 物体相比于容器的相对位置
}
},
{
"discrete_action": {
"action": "GotoLocation",
"args": [
"desklamp"
]
},
"high_idx": 2,
"planner_action": {
"action": "GotoLocation",
"location": "loc|-5|-4|3|60"
}
},
{
"discrete_action": {
"action": "ToggleObject",
"args": [
"desklamp" # 操作物体：台灯
]
},
"high_idx": 3,
"planner_action": {
"action": "ToggleObject",
"coordinateObjectId": [
"DeskLamp",
[
-7.3960004,
-7.3960004,
-3.1439984,
-3.1439984,
2.367104,
2.367104
]
],
"coordinateReceptacleObjectId": [
"DeskLamp",
[
-7.3960004,
-7.3960004,
-3.1439984,
-3.1439984,
2.367104,
2.367104
]
],
"forceVisible": true,
"objectId": "DeskLamp|-01.85|+00.59|-00.79"
}
},
{
"discrete_action": {
"action": "NoOp", # 结束动作
"args": []
},
"high_idx": 4,
"planner_action": {
"action": "End",
"value": 1
}
}
],
############################################################### 以下是低阶动作 ########################################################
"low_actions": [
{
"api_action": { # 描述机器人在 AI2-THOR 模拟器中执行的具体动作。包括动作类型（action）及其参数（如移动距离、是否强制执行）。
"action": "LookDown",
"forceAction": true
},
"discrete_action": { # 离散化的动作表示，用于简化动作描述。包含动作名称（如 MoveAhead_25）和参数。
"action": "LookDown_15", # 视角向下移动15度
"args": {}
},
"high_idx": 0 # 表示该低层次动作属于哪个高层次目标。
},
{
"api_action": {
"action": "MoveAhead",
"forceAction": true,
"moveMagnitude": 0.25 # 向前移动0.25米
},
"discrete_action": {
"action": "MoveAhead_25",
"args": {}
},
"high_idx": 0
},
...
{
"api_action": {
"action": "LookDown",
"forceAction": true
},
"discrete_action": {
"action": "LookDown_15",
"args": {}
},
"high_idx": 0
},
{
"api_action": {
"action": "PickupObject",
"objectId": "AlarmClock|-01.78|+00.60|+00.03" # 目标物体唯一标识符，用于明确机器人需要拾取的对象
},
"discrete_action": {
"action": "PickupObject",
"args": {
"bbox": [79,118,109,176], # 描述目标物体在图像中的边界框，格式为 [xmin,ymin,xmax,ymax]
"mask": [
[35185,5], # 描述目标物体在图像中的区域，使用了一种压缩形式。每个元素是 [像素索引,像素数]，表示从某个像素开始的连续像素数。
[35196,7], # 像素索引的计算公式： 像素索引 = y × W + x ，其中 x：像素的水平坐标（列）。y：像素的垂直坐标（行）。
[35484,21], # 像素数：从像素索引开始的连续 几 个像素属于目标物体的掩码区域
[35784,22],
[36083,23],
[36382,24],
[36682,25],
[36982,25],
[37281,27],
[37581,27],
[37881,27],
...
[52284,22],
[52585,6],
[52598,6]
],
"point": [94,146] # 分别表示目标物体在图像中的列坐标、行坐标
}
},
"high_idx": 1
},
{
"api_action": {
"action": "LookUp",
"forceAction": true
},
"discrete_action": {
"action": "LookUp_15",
"args": {}
},
"high_idx": 2
},
...
{
"api_action": {
"action": "LookDown",
"forceAction": true
},
"discrete_action": {
"action": "LookDown_15",
"args": {}
},
"high_idx": 2
},
{
"api_action": {
"action": "ToggleObjectOn",
"objectId": "DeskLamp|-01.85|+00.59|-00.79"
},
"discrete_action": {
"action": "ToggleObjectOn",
"args": {
"bbox": [
180,
68,
245,
155
],
"mask": [
[20305,14],
[20601,23],
[20899,28],
[21197,32],
[21495,36],
[21793,40],
...
[46382,37]
],
"point": [212,110]
}
},
"high_idx": 3
}
]
}字符串的格式loc|x|y|z|θ，每个部分含义如下：
- x：位置的 X 坐标，表示位置在场景中的水平方向（左右）的距离。
- y：位置的 Y 坐标，通常表示高度（上下方向），即与地面的距离。对于大多数导航任务，机器人一般保持在固定高度，因此这个值通常是恒定的。
- z：位置的 Z 坐标，表示位置在场景中的纵深方向（前后）的距离。
- θ：位置的 朝向角度，表示机器人相对于场景的旋转角度，单位是度（°）。例如：
- 0 表示机器人面向正前方。
- 90 表示机器人面向右方。
- -90 表示机器人面向左方。
- 在 AI2-THOR 中，物体的精确位置通常指的是底部中心点（Base Center Point）（更常用）：
- 坐标表示物体底部的中心点，即物体与支撑面（如桌子）接触的中心位置。 这是因为在拾取或交互时，机器人通常从物体的底部中心抓取。
1. 任务id
2. 高层次任务描述：task_desc
3. 高层次计划动作：high_descs
4. 质量检测投票：vote
"turk_annotations": {
"anns": [
{
"assignment_id": "A14IPKOBOPID9H_36W0OB37HZ55HDQWMFFHW4JUCE3ZH8", # 由 AMT 生成的唯一标识符，用于区分不同标注者的任务结果。
"high_descs": [ # 逐步操作的文字描述列表，提供了完成任务的具体步骤。每个步骤的顺序与高层次计划索引（high_idx）一致。
"Turn left and head to the desk, then turn right then left",
"Pick up the round container from the desk",
"Turn around, then turn right and go to the bed, then turn right",
"Turn on the lamp that is on the desk"
],
"task_desc": "Examine the round container by the light of the lamp on the desk", #任务的高层次描述，说明需要完成的总体目标。
"votes": [1,1,1] # 每个标注的质量评分，由其他 AMT 工作者投票得出。1 表示该描述通过了质量检查。0 表示该描述未通过质量检查。
},
...
{
"assignment_id": "A1MKCTVKE7J0ZP_3GU1KF0O4LS1CWL4ZE7JJVEI72SBPK",
"high_descs": [
"Turn left, and go forward to the desk.",
"Pick up the alarm clock on the edge of the desk.",
"Turn around, step forward, turn right and go towards the bed, then turn right to face the desk.",
"Turn on the lamp, on the edge of the desk."
],
"task_desc": "Look at an alarm clock in the light.",
"votes": [1,0,1]
}
]
}仅有traj_data.json文件 测试时仅需要环境信息和高阶动作指令输入，低阶动作指令用来验证模型的动作预测是否正确
{
"scene": {
"dirty_and_empty": false,
"floor_plan": "FloorPlan2",
"init_action": {
"action": "TeleportFull",
"horizon": 30,
"rotateOnTeleport": true,
"rotation": 180,
"x": -2.75,
"y": 0.9009992,
"z": 3.0
},
"object_poses": [
{
"objectName": "Potato_5e728867",
"position": {
"x": -1.874256,
"y": 0.9352317,
"z": -1.61003125
},
"rotation": {
"x": 0.0,
"y": 0.0,
"z": 0.0
}
},
...
{
"objectName": "Bowl_253fa632",
"position": {
"x": -1.64519465,
"y": 1.46765482,
"z": 0.0131571237
},
"rotation": {
"x": 0.0,
"y": 90.0,
"z": 0.0
}
}
],
"object_toggles": [],
"random_seed": 1194579178,
"scene_num": 2
},
"task_id": "trial_T20190906_162633_239128",
"turk_annotations": {
"anns": [
{
"high_descs": [
"move to the island in front of the sink",
"pick up a scoop from the island",
"move to the end of the counter to the left of the stove",
"put the scoop in the top drawer",
"move to the island in front of the sink behind you",
"pick up a scoop from the island",
"move to the end of the counter to the left of the stove",
"put the scoop in the top drawer"
],
"task_desc": "Put two scoops in the top drawer to the left of the stove."
},
...
{
"high_descs": [
"Turn the left, walk straight, turn right, walk to the sink, then turn around to the island counter.",
"Pick up the gold spoon spoon with blue handle.",
"Walk right, then turn left and walks to the counter to the left of the stove top.",
"Put the spoon in the drawer below the counter.",
"Turn around and face the island counter.",
"Pick up the gold spoon spoon with blue handle.",
"Turn around and face the counter to the left of the stove top.",
"Put the spoon in the drawer below the counter."
],
"task_desc": "Put all the gold spoons with blue handles in the bottom drawer to the left of the stove top."
}
]
}
}| 阶段 | 训练阶段 | 测试阶段 |
|---|---|---|
| 输入 | 专家视觉序列 + 专家动作序列 + 语言指令 | 实时生成的视觉观察 + 语言指令 |
| 输出 | 模型预测的动作（监督学习：与专家动作对比） | 模型生成的动作（用于执行任务） |
| 数据流 | 依赖专家演示，逐步学习任务执行能力。 | 模型独立推理，通过动作与环境交互完成任务。 |
| 评估目标 | 最小化动作序列与专家动作的差距 | 验证任务完成率（TSR）和路径效率（PWS）。 |
| 反馈机制 | 有教师强制，可以逐步纠正错误。 | 无教师强制，错误可能导致不可逆的任务失败。 |
| 是否需要AI2Thor | 可能不需要直接运行 AI2-THOR，因为所有数据（包括视觉图像和动作信息）都已经离线生成并存储。 | 测试阶段确实依赖 AI2-THOR 仿真环境，图像数据和物体信息必须通过运行 AI2-THOR 仿真环境来实时生成。 |
- 多样性：一个任务目标可能有多种方式实现。例如，任务 "Put two scoops in the top drawer to the left of the stove." 不同的人类标注员可能有不同的理解和操作路径，因此会提供多个 high_descs。
- 冗余性：模型在测试阶段可能会依赖某一种标注路径。如果某一条路径不成功，其他路径可能仍然可以验证模型的能力。 这些 task_desc 和 high_descs 不是互相独立的，而是描述同一个目标任务。
文中提出了一个基于CNN-LSTM 的序列到序列（SEQ2SEQ）架构来模拟交互式代理。 输入:
- 视觉观察结果: 代理在每个时间步的视觉输入，例如 RGB 图像。
- 语言指令: 高级目标自然语言指令。
输出：
- 动作: 代理在环境中执行的动作，包括导航动作（例如，向前移动、向右旋转）和交互动作（例如，拿起、放下、打开）等13个预定义动作。
- 交互掩码: 对于交互动作，代理需要生成一个像素级的二进制掩码，以指示目标对象在视觉帧中的位置。
模型结构
- 视觉编码: 使用冻结的 ResNet-18 CNN 对每个视觉观察结果进行编码，使用最后卷积层的输出以保留将特定对象接地到视觉帧所需的空间信息。
- 语言编码: 将自然语言目标和分步指令连接成一个输入序列，并将其输入双向 LSTM 编码器。
- 语言注意力: 在每个时间步，代理的动作基于对指令中标记的注意力机制加权，对语言特征执行软注意。
- 动作解码: 在每个时间步，LSTM 解码器接收新的观察图像，并输出一个新的隐藏状态，用于获得注意力加权的语言特征。
- 动作和掩码预测: 代理通过选择一个动作并生成一个像素级二进制掩码来与环境交互，该掩码指示帧中的特定对象。代理从 13 个动作中进行选择，包括 5 个导航动作和 7 个交互动作。交互动作需要一个像素级掩码来表示感兴趣的对象。
评估方法 为了评估模型的性能，文中提出了两种评估指标：任务成功率和目标条件成功率。
- 任务成功率: 如果在动作序列结束时，对象位置和状态变化与任务目标条件正确对应，则定义为 1，否则为 0。
- 目标条件成功率: 模型的目标条件成功率是在一个片段结束时完成的目标条件与完成任务所需的目标条件的比率。
AI2Thor就是其中simulator，AI2Thor中的操作是连续的，但为了模型方便输出动作，划分为13个离散的预定义动作。具体内容详见AI2Thor技术文档（重要）：https://ai2thor.allenai.org/ithor/documentation 。
任务成功率 SR：如果对象位置和状态变化与动作序列结束时的任务目标条件正确对应，则任务成功定义为1，否则定义为0。
条件任务成功率 GCS：完成的目标条件与完成任务所需的目标条件的比率
路径加权：度量s的路径加权分数ps为
$$
p_s=s*\frac{L^}{max(L^,\hat{L})}
$$