AI 队友系统 2026:三层决策与可察觉性度量
AI 队友是游戏里最难做的一类 AI,因为玩家对队友的容忍度远低于对敌人的容忍度。本文把 AI 队友拆成分层决策、人类示范蒸馏、意图承诺黑板、能力掩盖与实时降级五层,并给出一套以可察觉性而非胜率为核心的评估方法与七步落地清单。
约 35 分钟阅读10,446 字9 次阅读博主

AI 队友是游戏里最难做的一类 AI,因为玩家对队友的容忍度远低于对敌人的容忍度。本文把 AI 队友拆成分层决策、人类示范蒸馏、意图承诺黑板、能力掩盖与实时降级五层,并给出一套以可察觉性而非胜率为核心的评估方法与七步落地清单。

一句话导语:AI 队友是游戏里最难做的一类 AI——玩家对队友的容忍度远低于对敌人的容忍度,所以工程目标不是"赢",而是"赢且不被察觉";本文把这件事拆成示范学习、分层决策、可察觉性度量、实时预算四层,并给出一套可落地的评估与降级清单。
在游戏里做敌人,容错空间很大。敌人打得笨,玩家觉得有趣;敌人打得聪明但偶尔犯错,玩家觉得有挑战性。哪怕敌人偶尔用出"完美"的微操,多数玩家也只会归结为"这个段位的高手而已",因为玩家在心理上把敌人视为一个对抗性实体——它赢我是应该的。
队友完全不同。玩家把队友视为自己身份的延伸。队友打得好,是加分;队友犯错,玩家归因的对象首先是队友本身,而不是局势。据我在 2026 年 10 月对若干公开技术分享与开发者社区讨论的粗略观察,关于"AI 队友"的抱怨里,"它为什么不救我""它是不是故意送""它走位好奇怪"这类句式远多于"它太强了"。这句话背后是一个被低估的工程事实:AI 队友的质量上限不由决策能力决定,而由"决策被玩家正确归因为队友自身表现"这件事决定。
这带来一个残酷但必须接受的推论:一个在离线评估里胜率 85%、自博弈 Elo 2600 的 AI 队友,在真实玩家体验里可能是灾难;而一个胜率只有 62%、但行为高度可解释、失误模式符合人类直觉的 AI 队友,反而能让留存提升。换句话说,AI 队友是一个感知质量(perceived quality)主导、而非绝对质量主导的 AI 问题。
这个判断可以被历史上两个反复出现的教训支持。第一,OpenAI 在 2019 年公开的 Five(hide-and-seek)展示了自博弈加种群训练能涌现出非常强的协作行为,但后续公开分析也指出,其中一部分"协作"在真实对抗环境中会被人类玩家系统性地利用与钻空子——在封闭自博弈分布内优化的行为,一旦进入有分布外对手的环境,就可能从"聪明"退化为"愚蠢且可预测"。第二,2019 年《Nature》发表的 AlphaStar 论文报告其 StarCraft II 玩家达到大师级水平,但后续关于泛化性与规则遵从度的讨论也反复提到,某些局面下的表现带有明显的策略指纹,识破成本很低。这两个案例一正一反,共同说明:可察觉性是一个独立于能力的一等工程指标。
因此本文不从"怎么把 AI 队友训得更强"开始,而从"怎么度量它被不被察觉、并且据此反向约束训练与运行时"开始。这是过去两年游戏 AI 落地里最常被跳过的一步。
把 AI 队友的问题先写清楚,后面所有工程手段才有位置。我们把队友策略建模成三层,每层有独立的时域、独立的可观测状态、以及独立的一致性要求。
第一层:战术层(tactical layer)。时域大约 0.2 到 1.5 秒,输出是移动、瞄准、释放技能、使用道具、开火压制等原子操作。这一层的状态是引擎的即时战斗状态:自身血量、弹药、技能冷却、敌方可见性、友方位置、掩体几何。约束是硬实时——通常必须在游戏主循环的一个 tick 内完成决策(30 或 60 tick/s 时分别是 33.3ms 或 16.7ms)。这一层实际上不需要大模型,需要的是一个小型行为策略网络或者规则式控制器,用固定小步长执行。
第二层:小队层(squad layer)。时域大约 3 到 30 秒,输出是"我们先压 A 点还是先绕后""谁去架枪、谁去拉视野""现在撤退还是再等一个技能 CD"。这一层的状态是压缩过的战场摘要与队友通信。它需要处理部分可观测与延迟信息,因此通常是集中训练、分散执行(CTDE)架构下的一个策略头。
第三层:意图层(intent layer)。时域 30 秒到数分钟,输出是意图与承诺:"这一局我们打防守反击"、"我在完成一个支线目标,需要 40 秒无人打扰"。这一层的时延可以放到秒级,但它对风格一致性的要求最高,因为它直接决定了玩家对队友性格的感知。
现在定义核心指标。我们用 可察觉性偏离度(detectability deviation) 来刻画"AI 行为偏离人类直觉的程度"。设 是 AI 在时刻 的动作, 是同局面下人类示范者的动作,则单步偏离为:
注意这里不能只看 argmax 相等,因为"两个人都往掩体后面躲"和"一个人往掩体后面躲、一个人往掩体外面躲"在 argmax 上可能只差一个候选,但在玩家的主观感受里是完全不同的两件事。更实用的定义是概率分布层面的相似度,例如用 KL 散度:
在真实部署里往往拿不到,因为它需要同局面的人类示范。我们在实际工程中用的是它的可观测代理:行为指纹(behavioral fingerprint)。构造方式是取玩家操作日志里的一组统计特征——例如鼠标轨迹的加加速度分布、跳跃时机与血量阈值的相关性、连续击杀后的"庆祝动作"时长、被打断时的第一反应方向——然后检查 AI 队友在这些特征上的分布与人类玩家分布的距离。
据此我们可以定义三个可落地的部署期指标:
把这三个指标连起来,我们得到一个可以写进设计文档的判断准则:AI 队友的任何能力提升,如果在降低能力的同时提高了归因友好度,净效果可能是正的。
第一层的战术决策,主流做法已经从手写行为树转向从人类示范中蒸馏。这条路线的价值在于:人类示范天然带有"人类直觉"的分布特性,而这是我们希望 AI 继承的最重要资产——不是操作精度,而是在模糊局面下的选择倾向。
一个完整的示范学习管线通常包含五个环节。
环节一:日志采集。 引擎层记录每个 tick 的状态张量、人类输入(键鼠或手柄)、以及引擎判定的结果。这一步的工程重点是可重放性:日志必须包含足够信息,使得在离线环境里能精确重建同一局面,包括随机数发生器状态、物理引擎的确定性参数、以及帧时间戳。物理引擎的非确定性是这里最大的坑——同样一串输入在两次运行里可能产生略有差异的弹道,这在训练时会引入不必要的标签噪声。应对方式通常是固定步长、固定随机种子、并记录每个随机源的调用序列。
环节二:观测对齐。 人类演示日志里的状态是"玩家眼里的世界",而训练需要的是"策略可用的特征"。两者要做一个明确的对齐层,决定哪些信息进、哪些信息不进。这里面有一个反直觉但很重要的原则:把玩家看不到的信息排除在输入之外。原因是,策略一旦依赖玩家无法观测的量(比如"敌方 AI 的当前意图"或"全局资源的精确位置"),它在输出动作时会显得"无中生有地知道很多事",这会显著降低归因友好度。当然,也有一些必须保留的引擎内部量(比如自身技能冷却的剩余时间),因为玩家通过 UI 也能感知到这些。
环节三:监督学习与误差累积问题。 直接的行为克隆(behavior cloning, BC)在理论上有个众所周知的缺陷:训练分布是专家走过的状态分布,但推理时策略一旦偏离一点点,就会进入专家从未到过的状态,然后偏离得更多,形成分布漂移的级联。标准解法是 DAgger(Dataset Aggregation):先做一轮 BC,然后用当前策略去 rollout,把遇到的新状态也加入数据集,标注专家在该状态下的动作,迭代若干轮。这在游戏里尤其划算,因为游戏环境自带重置能力,rollout 成本极低。
一个实用但常被忽略的细节是时间平滑处理。人类在 60Hz 下的人类输入是抖动的,而 BC 学出来的策略可能学到一个高方差的输出序列,直接执行会让角色看起来像癫痫发作。常用做法有三种:动作分箱(把连续鼠标位移量化成离散档位再学)、动作历史窗口(输入最近 N 帧的动作)、以及 temporal ensembling(把历史策略的输出按指数权重平均,最后一种在 Transformer 架构的 BC 里效果尤其好,因为它天然利用了上下文长度)。
环节四:强化学习微调。 BC 得到的是一个"像人但上限低"的策略,通常需要 RL 提升上限。但这里的 RL 有两个必须显式处理的约束。第一个约束是不要让 RL 抹掉人类风格。做法有几种:KL 惩罚项(对 BC 策略加一个正则)、奖励塑形时把风格一致性本身写进奖励、以及更实用的"分阶段"策略(先 BC 预训练,再冻结部分网络只训特定头)。第二个约束是奖励函数里必须包含"不要被发现"或者"不要让队友显得蠢"这类项,否则纯胜负奖励会把 AI 推回到超人类打法,而那恰恰是我们最不需要的。
环节五:本地化与端侧推理。 第一层模型最终要跑在玩家机器上。2026 年 10 月 22 日通过 GitHub API 拉取到的实时数据可以说明这条路上工具链的成熟度:PyTorch 最新 release 为 v2.14.1(发布于 2026-09-30,star 数 104,967),JAX 最新 release 为 jax-v0.12.0(发布于 2026-10-19,star 数 36,482),Google DeepMind 的 MuJoCo 最新 release 为 3.16.0(发布于 2026-10-14,star 数 15,801),dm_control 为 1.0.49(发布于 2026-10-14,star 数 4,715),Farama 基金会维护的 Gymnasium 为 v1.4.0(发布于 2026-10-05,star 数 12,701)。需要说明的是,这些是当日拉取的快照,具体版本会持续变化,工程选型应以官方仓库为准。
端侧推理的一个务实建议是:第一层不要用大模型,甚至不要用中等模型。一个 3 到 8 参数量的策略网络,配合 16 到 64 的隐藏层宽度,在多数游戏 AI 任务上已经足够,并且可以在移动端 CPU 上以单帧预算内完成推理。把预算全部花在第三层的意图生成上,回报远高于把模型堆在第一层。
小队层是 AI 队友区别于普通 bot 的地方:它需要在延迟与丢包下维持队形与意图的一致性。这一层最容易犯的错误,是把它实现成"一个更大的神经网络吃全量战场信息"。这在实验室里有效,在实战里会因为玩家单机延迟、敌方绕后、以及部分可观测而崩溃。
更稳健的做法是显式通信与承诺机制。核心是给每个队友实例一个轻量的黑板(blackboard),上面存的不是完整状态,而是有限的几个字段:当前意图 ID、意图的目标点、意图的到期时间、以及最近一次更新的时间戳。每个队友只能通过写黑板与读黑板来协调,不能直接读取队友的内部激活。
# 小队层伪代码:一个最小可用的意图与承诺仲裁
class SquadBoard:
intents: Dict[int, Intent] # key = teammate_id
def propose(self, agent_id, intent, now):
# 1. 冲突检测:同类意图已有更"紧急"的在先者
for other_id, other in self.intents.items():
if other.kind == intent.kind and other.holder != agent_id:
if other.priority > intent.priority:
return False, other # 让位,复制对方意图
# 2. 承诺锁定:写入后在 ttl 内不得自动改主意
intent.holder = agent_id
intent.issued_at = now
intent.expires_at = now + intent.ttl
self.intents[agent_id] = intent
return True, intent
def tick(self, agent_id, now):
it = self.intents.get(agent_id)
if it is None or now > it.expires_at:
return None # 承诺到期,允许重新决策
if self.cancelled(it):
return None # 被更高优先级取消
return it # 承诺有效,战术层必须遵守
这段代码的工程价值不在算法,而在它把"AI 队友出尔反尔"这个最伤玩家体验的问题变成了一个可测试的不变量:战术层拿不到有效意图时必须走 fallback,而不是自由发挥。玩家对"AI 队友突然改变主意"的容忍度,远低于对"AI 队友保守地按原计划执行"的容忍度。
延迟处理上,有两个具体建议。第一,黑板同步用冗余不追求一致性:不要用强一致协议,改成每个客户端各自维护黑板副本,字段更新带单调递增的版本号,冲突时按"版本号大者优先"合并。这样在丢包下最多出现短暂的意图分歧,而不会出现长时间卡住等待同步。第二,把延迟显式暴露给策略:与其让模型在"我不知道队友位置"的情况下乱猜,不如把"最近一次知道队友位置的时间戳"作为观测的一部分喂进去,让它自己学会在没有新信息时采取保守策略。这是一个成本极低但收益明确的改动。
动态难度调节(DDA)在单机游戏里争议很大,而在多人游戏里,针对单个玩家的难度调节几乎必然被视为作弊或降智。这是行业里少见的、几乎没有讨论空间的红线。
那么 AI 队友上有没有可用的调节空间?有的,但它的语义必须被重新定义:不是"削弱玩家",而是**"能力掩盖(competence masking)"**——在 AI 自己实力不足以提供有效支援时,主动降低自己的存在感,而不是用低质量动作去添乱。
这个区分在工程上非常可操作。低质量的 AI 队友让玩家恼火,通常不是因为它弱,而是因为它在制造额外的注意力负担——玩家必须额外观察 AI 在干什么,才能判断 AI 是在帮忙还是在添乱。如果 AI 选择"少做但做对",玩家的注意力负担会大幅下降。
我们可以给能力掩盖设计一组明确的策略:
反过来,有两类调节是明确不该做的:不要在玩家表现出弱势时降低 AI 的输出质量(会被直接察觉为作弊),也不要在玩家表现出强势时提高 AI 的输出质量(会被察觉为放水,反而摧毁成就感)。这两条限制意味着,AI 队友的调节空间本质上只能在"何时不介入"这一侧,而不是"介入得多好"那一侧。
AI 队友最现实的工程约束,是它必须和一个已经在跑的游戏共享同一份预算。2026 年 10 月 22 日通过 GitHub API 拉取的 Unity ML-Agents 仓库数据提供了一个有意思的现实注脚:star 数 19,779,最近代码推送发生在 2026-10-21,但 API 返回的最新 release tag 为 release_23_tag、发布日期 2025-09-02。也就是说,这个被广泛引用的训练框架,其发版节奏明显慢于其代码演进节奏。对工程选型的启示是:可以放心用它做训练探索,但对生产环境的依赖要做版本锁定,并明确知道"latest release"可能落后于 main 分支一年以上。
现在回到实时性。假设我们在 60 tick/s 的游戏里做 16.7ms 的总预算,一个务实的分配是:
意图层异步化是整套设计的关键。 它的正确形态是"意图流":AI 队友每隔若干秒(而不是每帧)向意图层请求一次下一个意图,请求发出后战术层继续用当前意图执行,响应到达时原子替换。这样即使意图层延迟 800ms,战术层也完全不受影响,只是玩家会看到 AI "迟钝"一点。
在此之上必须有降级链。任何在玩家机器上运行的模型都会遇到驱动不兼容、显存不足、模型文件损坏、以及第三方驱动的诡异行为。降级链的每一级都要能在不重启游戏的情况下生效:
关键的设计要求是:降级必须是连续的、可感知为平滑的,而不是阶跃的。如果玩家看到 AI 队友在毫无征兆的情况下突然变笨,他会把这归因为 bug 或作弊,而不是资源不足。
看门狗的写法也应该遵循同一个原则:不要弹窗报错,不要写日志让玩家自己去翻,而是在连续降级达到某个阈值后,主动把 AI 队友切换到一个稳定的中庸策略并保持到会话结束,同时在后台异步上报诊断信息。
AI 队友一旦上线,就会进入一个敌意环境。这里有三类完全不同的对抗,需要三套不同的防御。
第一类:AI 队友被玩家利用。 玩家会发现某些 AI 队友的行为模式,并系统性地利用它——比如发现"AI 队友永远会优先保护队友",于是安排一个玩家去送死当诱饵,让 AI 队友跟着送。这是自博弈训练里经典的 reward hacking 在真实环境的复现。防御手段是引入多样化的队友角色配置:让同一个模型支持若干套不同的偏好权重(激进、保守、保护、游走),并按玩家会话随机分配,让利用某个模式的收益被摊薄。这在技术上只是多训几个策略头或做条件化,收益却直接。
第二类:AI 队友被诱导去做坏事。 玩家可以在聊天框里对 AI 队友说脏话、要求它去做违规的事,或者诱导它做出看起来像作弊的行为。这一层的防御是内容审核与输入约束:AI 队友的对话输入必须经过实时审核(结合 2026 年 10 月 UGC 审核方向的成熟工程方案),并且 AI 队友的任何可见输出都必须经过审核才能呈现给玩家,包括语音与文字。把审核放在输出侧而不是输入侧是一个关键选择——输入审核防不住所有绕过方式,而输出审核是最后一道且必然生效的闸门。
第三类:AI 队友的信号被用来判断作弊。 有经验的外挂作者会观察 AI 队友的视角与反应速度,因为这些可以作为"真人在看屏幕"的间接信号——真人的视角转移有肌肉记忆的特征,而程序化的视角控制往往过于平滑或过于随机。对这一层的防御是:不要让 AI 队友的行为与"它在被人类观察"这件事产生任何相关性。具体来说,AI 队友的视角转动要加入拟人化的抖动(来自第一层的 BC 分布,而不是均匀噪声),并且要保证在玩家打开地图、暂停游戏、切到其他应用等场景下,AI 队友的行为分布保持一致。
这三条里,第三条最容易被工程团队忽略,因为它没有可见的线上事故,只会以"外挂作者越来越聪明"的形式缓慢表现出来。
如果只用一个指标衡量 AI 队友,团队一定会选错。胜率太容易被优化,也太容易骗人:训练环境的胜率可以通过自我对弈刷上去,但它与真实玩家的体验几乎没有关系。以下是一套在工程上更可用的指标分层。
第一层:能力下限(floor)。 AI 队友在基础场景下的完成度:跟随不丢失、复活协助到位、不堵门、不撞墙、不在敌人面前来回横跳。这些是"会不会"的问题,用自动化测试关卡就能覆盖,而且应该是硬门槛。2026 年 10 月 12 日与 10 月 19 日的两篇文章分别覆盖了游戏 QA 的 playtest agent 与动作生成工程,这里可以复用它们的资产:把 AI 队友的行为也纳入自动化 playtest 的回归集,每次模型更新都跑一遍基础场景。
第二层:可察觉性(detectability)。 核心指标,建议至少包含三个子项:行为指纹分布距离、意图一致性的时间曲线、以及盲测中测试者识别"这是 AI"的准确率。盲测是最贵但最有信息量的方法:给受试者看一段对局录像(隐去 AI 与玩家的区分),问"你觉得哪一方是 AI",准确率越高说明越容易被察觉。这个指标不适合放进日常 CI,但适合放进每个大版本的质量关卡。
第三层:玩家主观评价(subjective)。 通过问卷或对话分析采集:玩家对 AI 队友的满意度、信任度、以及"队友是否让自己分心"的自陈。这类数据噪声大,但对第一段里"AI 队友是感知质量主导"的判断最敏感。如果线上数据里"它是不是故意送"这类抱怨持续升高,即使各项客观指标都在改善,也应该回头看可察觉性。
第四层:留存与付费的长期影响。 这是最诚实的指标,但反馈周期长,容易被误读。一个实践建议是:把 AI 队友相关的功能做成可开关的实验单元,用小流量 A/B 观察 2 到 4 周的次留与 7 留差异,并把"队友满意度"作为中介变量同时观测。中介变量的存在与否,能帮你判断留存变化是 AI 队友带来的还是其他因素。
跨周期的对比要注意基线漂移:随着其他系统(渲染、网络、AI 生成资产)也在迭代,绝对留存会变,因此应当记录每次发布时的基线,而不是拿绝对值做判断。
关于分层的一个经验法则:第一层每次提交都跑,第三层每次发版都采,第四层每季度评估,第二层每个大版本做一次盲测。 把所有指标都放进日常流水线只会得到一堆没人看的数字。
如果从零开始做 AI 队友,下面是一个按依赖顺序排列的最小可行清单,标注了每一步的可验证判据——这一点比清单本身更重要,因为 AI 项目最常见的失败模式就是没有判据,导致团队陷入"越优化越说不清好没好"的状态。
有三个问题在我写这篇文章的时候还没有可靠答案,如实标注出来:
问题一:归因友好度能否被完全量化。 目前的所有度量都依赖代理指标,而代理指标与玩家真实感受之间的映射关系缺少公开验证的数据。我倾向于认为它只能做相对比较,不能做绝对阈值设定。
问题二:多玩家 AI 队友的协调。 单人 + 一个 AI 队友的场景,和五个 AI 队友与五个真人混编的场景,是两个难度完全不同的问题。后者的通信复杂度与意图冲突仲裁我目前没有看到成熟的公开工程方案。
问题三:对手戏的表达一致性。 当 AI 队友与玩家需要完成一段有明确叙事节奏的协作(比如潜行、营救)时,意图层与叙事系统的接口该长什么样,是一个我没有把握的设计问题。据我了解,目前没有公开的、可查证的统一做法。
最后一点提醒:本文提到的所有工具版本与仓库数据均为 2026 年 10 月 22 日通过 GitHub API 实时拉取的快照,工程选型请以官方仓库的最新状态为准。对于文中没有给出具体数字的判断(例如"玩家更倾向于把失误归因给队友"),它们来自公开讨论中的定性观察,尚未见到经过公开验证的定量研究,不应被当作可直接引用的结论。
Conversation
0 条