多智能体：环境对你非平稳

1. 对手也在学，你的 MDP 在变

单 agent RL 假设 $P (s^{'} ∣ s, a)$ 固定。Multi-agent 里每个 agent $i$ 输出 $a_{i}$ ，联合 action $a = (a_{1}, \dots, a_{N})$ 决定转移——其他 agent 策略 $π_{- i}$ 也在更新，对你等价于 non-stationary dynamics。Value 函数 $V (s)$ 学的是「当前对手策略下」的期望，对手一变，旧 value 全废——这不是 hyperparam 问题，是问题定义的一部分。

Independent PPO (IPPO) 各训各的，简单，合作任务有时能 work；竞争任务 non-stationarity 更强，常崩。Simple Spread（MPE）里 IPPO 有时能学；竞争性环境 centralized critic 常更稳。Multi-agent 的「环境」包含其他 learning agent——你的最优策略随对手策略变化，不存在固定 MDP，这是和 single-agent 的本质区别。

2. 机制：CTDE 与 self-play

MAPPO / CTDE（Centralized Training, Decentralized Execution）：训练时 critic 见 global state 或 all actions，执行时各 agent 只用 local obs——部署时不需要 agent 间通信，critic 的 centralized 信息只在 train 时用。CTDE 不是 free lunch：critic 输入维数随 agent 数线性或二次增长，>5 agent 时需 attention 或 factorization。

V_{i} (s, a) 训练 π_{i} (a_{i} ∣ o_{i}) 执行

Self-play / opponent modeling：竞技游戏显式建模他人策略；联赛式 opponent pool 防 strategy cycling——今天赢的 policy 明天被新 policy 克。Self-play elo 曲线比 single opponent return 更能看 progress，避免被单一弱对手 illusion。

PettingZoo parallel API 和 Gymnasium 单 agent 不同，SB3 原生不支持，要用 SuperSuit 或 RLlib——pipeline 选型要先确认框架支持。

3. 合作 vs 竞争

Cooperative：共享 team reward，credit assignment 难（谁该被奖）。Communication channel 带宽限制写进 env spec——train 用 unlimited comm、deploy 限带宽会导致策略依赖大带宽消息，部署必崩。Multi-agent 合作任务里「谁贡献大」说不清，shared reward 下 individual gradient 弱是常态，不是调 LR 能修。

Competitive：zero-sum，non-stationarity 来自对手更新。Production 有时 frozen opponent pool 换 stable best response——竞技任务 non-stationarity 无完全解，工程上接受「对手分布固定」的近似，用 league 或 pool 管理对手版本。

Centralized critic 输入 all observations 在 agent 数 >5 时维数爆炸；attention 或局部 critic 是 scaling 方向。工程上先 2-agent toy（Simple Spread, MPE）验证算法再 scale。

4. Non-stationarity 诊断

训练中途 freeze 对手 100k step，看自身 return 是否跳涨——涨则说明被对手更新拖着走，value 学的是 moving target。Log 各 agent policy entropy，collapse 或 cycling 有迹可循。Credit assignment：team reward 谁贡献不明——shared reward 下 individual agent 的 gradient 信号极弱。

5. 失败模式

Communication 带宽无限，sim 可行 real 不可。Centralized critic 在 large agent count 时维度爆炸，未做 attention 直接上 10 agent 训练崩。Opponent modeling 过拟合当前对手，换对手泛化差。Strategy cycling：今天赢的 policy 明天被新 policy 克。

6. 验收

2 agent cooperative toy（Simple Spread）看 IPPO 是否学习；对比 centralized critic vs independent。
Freeze opponent test：return 跳涨 → non-stationarity 是主因。
Deploy 假设与 train 一致：communication 带宽、obs 范围、agent 数量。
SMAC 等复杂 env 前先在 MPE 验证 pipeline。
Self-play 用 opponent pool，非 single opponent。

7. 案例：freeze 对手后 return 跳涨

某 2-agent competitive 项目训练曲线长期震荡，freeze 对手 100k step 后自身 return 跳涨 40%——说明 value 学的是 moving target，被对手更新拖着走。改用 MAPPO centralized critic 后震荡减小，return 稳步上升。Non-stationarity 演示实验是诊断 MARL 问题的低成本方法。

8. Credit assignment 与 difference reward

Cooperative 任务共享 team reward 时，individual agent 的 policy gradient 信号极弱——全队成功/失败无法归因到单个 agent 的动作。Difference reward $D_{i} = G (s^{'}) - G (s_{- i}^{'})$ 试图隔离 agent i 的边际贡献，但 $G$ 的设计本身需要 domain knowledge。Centralized value decomposition（VDN、QMIX）是另一条路：global Q 分解为 per-agent Q 之和，训练仍 centralized。

工程上若 team reward 是唯一信号，先验证 2-agent 能否学——不能则问题可能在 reward 设计而非 algorithm。Communication 若允许，train 时 unlimited、deploy 时限带宽，策略会依赖大消息——deploy 前必须 ablate communication 看 performance 掉多少。

9. 与单 agent 迁移的关系

Multi-agent env 有时可降维为 single agent（控制其他 agent 用 fixed policy）——若 fixed-opponent 版本能学、joint training 不能，non-stationarity 是主因，应上 CTDE 或 opponent pool。若 fixed-opponent 也不能学，问题可能在 env/reward 本身，加 centralized critic 无济于事。

PettingZoo 的 parallel API 要求每个 agent 独立 step，和 Gymnasium 的 single step 不同——pipeline 封装错会导致 action 时序混乱，表现为「学不动」实为 bug。Multi-agent 实验 log 应含各 agent entropy 和 frozen-opponent test 结果，便于区分 non-stationarity 与 implementation bug。Cooperative 任务若 IPPO 不收敛，先查 reward 是否可分解、communication 假设是否与 deploy 一致，再换 MAPPO——algorithm 不是第一嫌疑人。Protocol 写进 experiment template，新人按模板跑。

Multi-agent 的非平稳性是问题定义的一部分，不是调参能消除的。CTDE 降低 value 学习的伤害，self-play 管理对手分布——先 2-agent toy 验证，再 scale；跳过 toy 直接上 SMAC，debug 成本翻倍。