LLM 直接输出底层动作，动作空间大、非法动作多；只输出高层任务，又要靠专家规则或额外训练把它翻译成动作。 PLAP 在两者之间插入参数化技能：LLM 只负责选技能和参数，预定义的执行器负责把技能拆成可执行动作。 论文在 MicroRTS 上验证，不做额外训练，每 k=100 个游戏步才调用一次 LLM。
论文把 LLM 智能体的接地问题拆成两层：高层用语言规划，低层用环境动作执行。直接让 LLM 输出低层动作，空间大且容易出非法动作；让 LLM 输出高层任务，又要靠专家经验或额外训练把任务翻译成动作。PLAP 选中间层：参数化技能。
技能库给出 5 个技能（Table I），每个技能有名字和参数，内部对应若干原子动作。LLM 在提示里看到规则、技能表、示例、tips 和当前战场文本，输出 [Skill](params) 形式的计划；解析器丢掉非法行。执行器每步检查技能是否可用（Ii），调用预定义函数 πi 取当前状态下的第一个动作，再拼成动作向量；技能终止就删除。每 k=100 步重新规划。
在 5 个脚本基线上，16 个 PLAP 设置的平均分是 0.91，高于 RandomBiasedAI、LightRush、NaiveMCTS；Qwen-fs-tip 与 DeepSeek-fs-tip 超过 CoacAI。另一张表是 8 个 LLM 的循环赛：GPT-4o 49 分、84.3% 胜率，Gemini 1.5 Flash 25 分、65.7%。注意 84.3% 是 LLM 之间的胜率，不是对脚本基线的胜率。
先看 MicroRTS 的观测与动作编码，才能理解为什么需要中间层。
MicroRTS 是实时战略游戏：红蓝双方在对称地图上采集资源、建造单位、击败对手。一局有成千上万个游戏步，每一步都要做实时决策（§IV）。论文主要用 basesWorkers8x8 地图，双方各从一个基地和一个工人开始。
环境给智能体的观测是一个 (h, w, nf) 张量，nf=27 个特征平面，由多组 one-hot 特征拼接而成（Table III）。要让 LLM 读，还得把这 27 个平面转成结构化文本（Fig.5）。
| 特征 | 平面数 | 取值 |
|---|---|---|
| Hit Points | 5 | 0, 1, 2, 3, ≥4 |
| Resources | 5 | 0, 1, 2, 3, ≥4 |
| Owner | 3 | player 1, -, player 2 |
| Unit Types | 8 | -, resource, base, barrack, worker, light, heavy, ranged |
| Current Action | 6 | -, move, harvest, return, produce, attack |
| 合计 | 27 | — |
动作侧更紧。MicroRTS 的每个动作编码长度是 78，整个动作向量是 78 × w·h 维。Table IV 把 78 拆成 7 段 one-hot：动作类型 6、移动方向 4、采集方向 4、返回方向 4、生产方向 4、生产类型 7、相对攻击位置 49（ar=7，ar2=49），相加正好是 78。推断（由 Table IV 的各段取值范围相加得到；论文只直接给出 78 这个总长度。）
在 8×8 地图上，动作向量长度是 78×8×8 = 4992。LLM 若直接生成底层动作，每一步都要在这个 4992 维空间里给出一个合法组合；对手一行动，上一步的组合还可能立刻失效。这就是论文说的“invalid actions + curse of dimensionality”（§I）。
另一条路是把输出空间抬到高层任务，但“高层任务 → 底层动作”的翻译本身没有解决：要么靠人写规则，要么训练一个辅助模块。问题于是变成：能不能找一个比动作抽象、又比任务具体的中间层？
论文把现有做法归成两类，各自的失败点正好相反。
把 LLM 的输出空间约束成环境的低层动作空间。好处是接口直接；坏处是动作空间巨大，模型容易生成无效或非法动作，论文称之为 curse of dimensionality（§I）。
卡点：可靠性。每一步都要合法，长序列里错误会累积。推断（依据：§I 指出直接生成低层动作会遇到 invalid actions 与 curse of dimensionality；错误随序列累积是本页的延伸。）
把输出空间抬到高层任务或语言指南，再把任务翻译成底层动作。翻译环节通常依赖专家经验，或者额外训练一个模块。
卡点：高层与低层对不齐；论文原话是 “the latter faces challenges in effectively bridging high-level planning with execution”（§I）。
论文在 §II 列了几种代表做法：SayCan 需要训练一个 value function 来过滤可执行动作；Plan-Seq-Learn 依赖训练好的低层控制策略；EES 需要学习一个参数选择策略来指导执行；LLaMAR 用四个 LLM 模块协作，推理时间和调用成本都高。这些方法在机器人任务上有效，但到了对抗环境，技能参数空间会动态变化（比如新造出来的兵种），再训练一个参数生成策略很难。
Fig.1(c) 在低层动作和高层任务之间插入 parameterized skill space。每个技能是一个预定义函数，带明确参数，内部映射到一串底层动作。LLM 只在这个技能空间里规划，执行器负责把技能展开成动作。这样既不需要 LLM 直接碰 4992 维动作向量，也不需要再训练一个“任务 → 动作”的翻译器。
和 EES 的关键差别在参数由谁选：EES 学一个参数选择策略；PLAP 把技能选择和参数选择都交给 LLM（§IV-B），因此不需要额外的参数生成网络。
核心是把「做什么」和「怎么做」拆开；公式只有 active set、动作向量、终止删除三行。
论文沿用 parameterized action MDP（PAMDP）的设定，用一个五元组描述任务：(S, U, R, T, γ)。其中 U 是参数化技能集合。每个技能 ui 写成四元组：
技能库是人工设计的，论文在 MicroRTS 里放了 5 个技能。每个技能只需要 LLM 给出技能名和参数，内部包含哪些原子动作由执行器处理：
| Skill | Parameters | Atomic Actions | Description |
|---|---|---|---|
| Deploy Unit | unit type, deployment location | move, NOOP | Moves a unit of a specified type to a specified location. |
| Harvest Mineral | mineral location | move, harvest, return | Move to a specified location to harvest resources and return to base. |
| Build Building | building type, building location | move, produce | Build a building of the specified type at the specified location. |
| Produce Unit | unit type, produce direction | produce | Produce a specified type of unit from a specified direction. |
| Attack Enemy | unit type, enemy type | move, Attack | Command a specified type of unit to attack a specified enemy type of unit. |
LLM 的输出不是单个技能，而是一个技能计划。解析器 f 用正则从 START OF SKILL_PLAN / END OF SKILL_PLAN 之间提取 [SKILL_NAME](PARAMETERS)，格式错误、技能不存在、参数非法的行直接丢掉。剩下的 ct 个技能组成：
执行器每步先筛出当前状态可用的技能：
对每个活跃技能，执行器调用它的策略 πi，只取当前状态下的第一个动作，再把所有活跃技能的动作拼成动作向量：
论文特别说明：下一步不会直接使用上一步序列里的第二个动作 ai(t′,1)。原因有两个：技能可能在新的状态里不可用；对手行为不可预测，原来的第二个动作可能已经无效。所以每一步都重新调用 πi(st′+1, θi)，取新状态下的第一个动作（§IV-C）。
技能终止后从计划里删除：
这套循环把“规划”和“执行”拆成两个时间尺度：LLM 每 k 步重新看一次战场，执行器每一步都按当前状态重算动作。下一节看 k 带来的调用成本。
PLAP 的开销主要不在执行器，而在 LLM 调用次数；k 决定调用频率。
论文强调 PLAP 不需要额外学习成本，也不依赖专家经验或先验知识（§I）。实验里没有训练或微调，主要超参数只有 temperature 和 max_tokens：temperature 设为 0，max_tokens 设为 256，规划间隔 k 默认 100。地图主要是 basesWorkers8x8；论文称 prompt 的构造与具体地图无关，因此换地图可基于同一框架实现（§V-B）。
每次规划的 prompt 由六部分组成（Eq.1）：用户指令 Inst、游戏手册 Manu、技能描述 Udesc、few-shot 示例 shots、专家提示 tips、当前文本观察 Ottext。few-shot 只用 2 个手工构造的例子；tips 可以为空，也可以放“先打敌方兵营”这类专家建议。
如果一局需要 n 个游戏步，规划每 k 步发生一次，LLM 只需被调用 n/k 次（§IV）。执行器本身是预定义函数，不调用 LLM。下面把 n 和 k 做成可调的，看调用次数怎么变。
组 1：n=1000, k=100 → ceil(1000/100)=10 次；逐 step 调用 1000 次，1000/10=100 倍。
组 2：n=2000, k=50 → ceil(2000/50)=40 次；逐 step 调用 2000 次，2000/40=50 倍。
两组都能整除，所以 ceil 不改变结果；滑块取不能整除的值时，JS 用 Math.ceil 向上取整，读数会略高于 n/k。论文没有报告端到端延迟或 API 成本，这里只比较调用次数，不比较实际耗时。
这也是 PLAP 和 LLaMAR 那类多模块架构的差别：LLaMAR 要四个 LLM 模块协作，PLAP 每次规划只调用一个 LLM，靠执行器承担高频决策（§II）。代价是执行器的技能函数要人工写；论文把这一点列进了限制。
看图：LLM 只在 t=0, k, 2k... 介入；中间每一步由技能函数闭环执行。
I_i(s)=1 表示技能在当前状态可用，π_i 只取第一个动作；β_i(s)=1 表示技能终止，对应技能从 Q_t 删除。
Algorithm 1 的循环可以压成三行：
Dt，调用 LLM，解析出 Qt。Ii(st) 求活跃技能集，调用各自的 πi，取第一个动作，拼成 at。Env.step 返回新状态；按 βi 删除已终止技能；t ← t+1。把 Fig.7 与 Table II 分开看：Fig.7 是对 5 个脚本基线，Table II 是 8 个 LLM 互相循环赛。
先看对脚本基线。论文实现了 4 种提示变体（zero-shot、zero-shot + tips、few-shot、few-shot + tips），在 Qwen2-72B、DeepSeek V2.5、GPT-4o mini、GPT-4o 四个 LLM 上跑（Fig.7 横轴），共 16 个设置；每个设置与 5 个基线对战，按 +1 胜、0 平、−1 负算平均分。全部 16 个设置的平均分是 0.91，落在 WorkerRush 的 1.8 和 NaiveMCTS 的 0.2 之间。论文据此说，PLAP 在平均分上优于 RandomBiasedAI、LightRush、NaiveMCTS 三个基线（原文用 “completely superior”）；部分变体（DeepSeek-fs、GPT-4o-mini-fs、GPT-4o-mini-fs-tip、GPT-4o-zs-tip）能超过 WorkerRush；Qwen-fs-tip 和 DeepSeek-fs-tip 超过最强的脚本 AI CoacAI（§V-D1）。Fig.7 中 Qwen-fs-tip 柱为 4.6，CoacAI 基线虚线为 4.0；本页只转录与正文结论直接相关的点值，其余未逐点转录。
再看 LLM 循环赛。8 个模型都用零样本 PLAP，每个模型同时当红方和蓝方，与另外 7 个模型各打 5 局，所以每个模型共 70 场（7 个对手 × 红蓝双方 × 5 局）。Table II 按 Scores 排名：
| Model | Scores | WR | RHR | RUR | UPR | CER |
|---|---|---|---|---|---|---|
| GPT-4o | 49 | 84.3% | 2.32 | 2.34 | 1.61 | 1.63 |
| Gemini 1.5 Flash | 25 | 65.7% | 1.93 | 1.57 | 1.57 | 1.22 |
| GPT-3.5 Turbo | 13 | 52.9% | 1.13 | 1.38 | 1.32 | 0.95 |
| GPT-4o mini | -4 | 40.0% | 1.08 | 1.27 | 1.22 | 0.81 |
| Qwen2-72B-Instruct | -15 | 35.7% | 1.61 | 1.38 | 0.90 | 1.26 |
| Claude 3.5 Sonnet | -18 | 28.6% | 1.56 | 1.35 | 1.29 | 1.14 |
| Claude 3 Haiku | -25 | 20.0% | 0.98 | 1.23 | 1.20 | 0.89 |
| DeepSeek V2.5 | -25 | 18.6% | 0.98 | 1.09 | 0.83 | 0.70 |
GPT-4o 以 49 分、84.3% 胜率排第一；Gemini 1.5 Flash 以 25 分、65.7% 排第二。两者分差 24 分（49 − 25），胜率差 18.6 个百分点（84.3 − 65.7）。论文还指出不同模型有不同强项：GPT-3.5 Turbo 擅长高效花费资源和快速产兵，Qwen2-72B 在资源采集和战斗上更强（§V-E）。
提示变体的结果不是单调的。对 Qwen2-72B、DeepSeek V2.5、GPT-4o mini 三个模型，加 2 个 few-shot 例子平均提高约 3.8 分；但 §V-D2 称 GPT-4o 反而下降：few-shot 比 zero-shot 低 1.4 分，few-shot + tips 低 2.8 分。Fig.7 给出的 GPT-4o 点值是：zero-shot -0.2、few-shot -1.6、few-shot + tips 0.2。其中 few-shot 从 -0.2 降到 -1.6，低 1.4 分，与 §V-D2 相同；但 few-shot + tips 比 zero-shot 高 0.4 分（0.2 − (-0.2)），与 §V-D2 的“低 2.8 分”不一致，原文未说明以哪个为准。论文对 GPT-4o 的解释是它更强，清晰完整的指令已经够用，额外例子可能反而限制它（§V-D2）。专家 tips 则在 zero-shot 和 few-shot 下都带来稳定提升（§V-D3）。但 Fig.7 中 GPT-4o-mini 的 few-shot 为 3.0、few-shot + tips 也为 3.0，未提升（§V-D3 的 consistent improvements 未覆盖这一例外）。
论文用 5 道 MicroRTS 题和 5 道 StarCraft II 题测了 8 个 LLM 的领域知识。MicroRTS 的平均准确率是 0.15%，StarCraft II 最高到 80%。只有两个模型在 MicroRTS 上非零，其中 Claude 3.5 Sonnet 是 100%；论文认为这提示 Sonnet 的训练数据里包含题目来源。作者用这组对照支持“多数 LLM 对 Skill-RTS 没有内部知识”的判断（§V-C）。
切换下面的指标，可以看 Table II 里 8 个模型在五项指标上的相对位置。柱长按当前指标的最大值归一化，跨指标不可比。
WR 指标：最大 84.3%（GPT-4o）。DeepSeek V2.5 的 18.6% → 18.6/84.3×100 = 22.1%。
RHR 指标：最大 2.32（GPT-4o）。DeepSeek V2.5 的 0.98 → 0.98/2.32×100 = 42.2%。
柱高只表示同一指标内的相对位置；不同指标的量纲不同，不能横向比较。图中模型名是缩写，对应 Table II 的完整名称。
§VI 称 zero-shot GPT-4o ‘outperforms 80% of baseline AI bots’；Fig.7 中 GPT-4o-zs=-0.2（低于 naiveMCTS 0.2、WorkerRush 1.8、CoacAI 4，只高于 LightRush -2.6、RandomBiasedAI -3.4），GPT-4o-zs-tip=3.0 才在 5 个基线中胜过 4 个（低于 CoacAI 4）；原文未说明 80% 指哪个 zero-shot 变体。这和循环赛的 84.3% 是两套不同的分母，不能混在一起读。
论文自己列了三条限制；每一条都直接决定 PLAP 能用到哪。
论文原话：“PLAP has only been tested in the MicroRTS environment, lacking validation in more realistic adversarial scenarios.”（§VI）8×8 的网格游戏和真实世界的对抗场景差得远。推断 换到高维观察、连续动作或部分可观测环境，技能库和执行器能否直接复用，论文没有验证（依据：§VI 只列“仅在 MicroRTS 验证”这一限制，没有报告其他环境的实验）。
论文原话：“The skill functions used in PLAP are manually constructed, which limits generalization across different domains.”（§VI）推断 技能库的粒度和覆盖范围直接决定规划空间：太粗，LLM 没有足够表达力；太细，又退回到底层动作（依据：Table I 的 5 个技能覆盖部署、采集、建造、生产、攻击五类操作；§IV-B 把技能与参数都交给 LLM 选）。论文没有给出技能库设计的系统方法，只把“用 LLM 生成技能代码”列为未来方向。
论文原话：“PLAP currently focuses on explicit state(observation) changes in the environment and opponent, without modeling the opponent’s strategic intent. This limits its upper performance bound.”（§VI）执行器只对显式状态变化做反应；对手下一步想做什么、为什么这么做，不在模型里。论文把对手建模列为未来工作。
推断 文本化观察的可扩展性没有测。论文把 27 个特征平面转成结构化文本，在 8×8 地图上够用；但更高维的观察要压成多长的文本、会不会丢关键信息，论文没有实验（依据：§V-A 定义 Skill-RTS 的指标与 5 个技能，观察转换示例见 Fig.5，动作/观测细节见 Appendix VII-A；§V-B 主实验用 basesWorkers8x8）。
推断 失败归因没有专门机制。Algorithm 1 在 t % k == 0 时重新规划，但没有“分析上一轮为什么失败”的步骤；计划失败后主要靠下一轮重新看状态（依据：Algorithm 1 的循环里没有失败归因分支）。论文提到可以接入 Reflection 等推理模块（§V-D），但那是可选扩展，不是基础循环的一部分。
论文也没有报告端到端延迟或 API 成本；k 步规划降低的是调用次数，单次 LLM 延迟仍然存在。