游戏UGC多智能体AI圆桌协作系统：Token控制与本地推理实践

1. 从“Token 焦虑”说起：为什么游戏 UGC 场景需要一场 AI 圆桌

做游戏 UGC 内容的人，最近一两年大概都有一种共同的体感：AI 能帮上忙，但帮得不够“顺”。你想让 AI 帮你写一段 Minecraft 的建筑设定、生成一段 NPC 对话、再顺手把玩法机制梳理成策划案，结果往往是——你打开一个对话框，把需求丢进去，等它吐出一大段文字，然后你复制、粘贴、修改、再丢回去。整个过程里，AI 是个“单线程工具人”，而你自己反倒成了那个在多个窗口之间来回搬运信息的“人肉总线”。

更让人头疼的是 Token 消耗。多轮对话越拉越长，上下文越堆越厚，每一次追问都要把前面所有内容重新喂一遍。聊到后面，你会发现响应变慢、成本上升，甚至出现上下文被截断、前后设定打架的情况。这就是所谓的Token 焦虑：不是用不起，而是用得“不划算”，用得“不踏实”。

这次 NVIDIA DGX Spark 黑客松，我们这支来自 NVIDIA Developer 社区的队伍——“说的都队”，想解决的正是这个问题。我们没有去做一个更大的单体模型，而是换了个思路：把一个大任务拆成一张“圆桌”，让多个各有所长的智能体围坐在一起，各管一摊、互相协作，最后由一个主持人收口。这套系统我们叫它游戏 UGC 多智能体“AI 圆桌”协作系统，落地场景选的是 Minecraft UGC 内容生产。

为什么是圆桌？因为圆桌天然对应“分工 + 协商 + 收敛”这三个动作。一个 UGC 需求进来，不是一股脑塞给一个模型，而是先被拆解，再分发给不同角色的智能体，各自产出，再由协调者整合。这样做的好处很直接：每个智能体的上下文都更短、更聚焦，Token 花在刀刃上；同时因为角色隔离，设定不容易互相污染。而 NVIDIA DGX Spark 提供的本地算力，让这套多智能体协作可以在一台桌面级设备上跑起来，不用把数据来回搬运到远端，响应链路短、隐私可控、调试也方便。

这篇文章我会把这套系统从设计动机、架构拆解、Token 控制策略、到实测踩坑，完整讲一遍。适合谁看？如果你在做 AI Agent 应用、在折腾多智能体协作、或者单纯被 Token 账单和上下文长度折磨过，那这篇应该能给你一些能直接抄的思路。我不会只讲“我们做了个很酷的东西”，而是把每个设计选择背后的“为什么”讲清楚，包括我们踩过的坑。

2. 圆桌的角色分工：把“一个全能模型”拆成一支小队

2.1 为什么不做单体大 Prompt，而要做角色隔离

最开始我们也试过最朴素的做法：写一个超长的 System Prompt，把“你是策划、你是文案、你是关卡设计师、你是审核”全塞进去，让一个模型一次性输出所有内容。结果很快就崩了。问题出在三个地方。

第一，角色冲突。当同一个上下文里同时存在“创意发散”和“严格审核”两种指令时，模型会摇摆。你让它写天马行空的建筑设定，它写得挺好；但你紧接着让它“以审核视角挑毛病”，它又会把自己刚写的东西批得体无完肤，然后开始自我矛盾。这不是模型笨，而是单一上下文里目标不唯一。

第二，上下文膨胀。所有角色的历史输出都堆在同一个对话里，Token 线性增长。写到第三个环节，前面两个环节的全部内容还在被反复重读，纯属浪费。

第三，难以定位问题。输出质量差的时候，你根本不知道是哪个环节出的错——是拆解错了，还是文案跑偏了，还是整合时丢了信息。单体 Prompt 是个黑盒。

所以我们决定做角色隔离。每个智能体只关心自己那一摊事，上下文里只放它需要的输入和它自己的输出。这本质上是一种关注点分离，和软件工程里拆微服务的思路是一样的：不是因为它时髦，而是因为它让每个单元都更简单、更可测、更省资源。

2.2 圆桌上的五个固定席位

我们的圆桌设了五个核心角色，每个角色对应一个独立的智能体实例，各自有独立的 System Prompt 和独立的上下文窗口。下面这张表是我们最终定下来的分工：

这里有个关键设计：主持人不参与具体创作，只做拆解和收口。这是刻意的。如果主持人自己也写内容，它的上下文就会膨胀，而且会带着自己的“创作偏好”去整合，容易偏袒。让它保持“中立调度者”的身份，整合时才更客观。

2.3 角色之间的信息流：不是广播，而是定向投递

很多多智能体系统喜欢搞“广播”——一个智能体的输出发给所有人。我们实测下来，这是 Token 杀手。正确做法是定向投递：策划的输出只发给文案和建筑，审核只接收它需要检查的那部分。

具体来说，信息流是这样的：用户需求先进 Coordinator，Coordinator 把它拆成若干子任务，比如“设计一个沙漠主题的生存关卡”。这个子任务同时发给 Designer 和 Builder——Designer 负责玩法，Builder 负责场景。Designer 产出策划要点后，把其中的“叙事相关部分”定向发给 Writer，把“空间相关部分”定向发给 Builder。最后 Writer、Builder、Designer 的产出汇总到 Reviewer，Reviewer 只输出问题清单，不重写内容。Coordinator 拿到问题清单后，决定是打回某个席位重做，还是直接收口。

提示：定向投递的关键是“消息路由表”。我们在实现里维护了一张简单的映射表，规定“谁的输出、哪一类字段、发给谁”。这张表是整套系统 Token 控制的核心，后面第 4 节会详细讲。

这套分工跑下来，最大的感受是：每个智能体的 Prompt 都变得很短，但整体产出质量反而更高了。因为每个角色都在自己最擅长的语境里工作，不用分心去兼顾别的目标。

3. 在 DGX Spark 上把圆桌搭起来：架构与运行链路

3.1 为什么选本地算力而不是纯云端

先说选型逻辑。多智能体系统有个特点：调用次数多、单次上下文短、对延迟敏感。一场圆桌讨论，五个角色来回可能要跑十几到几十次推理。如果每次都走远端 API，网络往返的延迟会累积得很明显，而且调试的时候你没法快速迭代——改一版 Prompt，等半天才看到结果，效率极低。

NVIDIA DGX Spark 这类桌面级 AI 计算设备的价值就在这里：它把推理能力放到了本地。对我们这个场景来说，好处有三点。一是链路短，智能体之间的消息传递和推理都在本地完成，圆桌“开会”的节奏很紧凑。二是数据不出本地，UGC 项目里经常有还没发布的玩法设定，本地跑更安心。三是可反复调试，Prompt 改完立刻能验证，这对多智能体这种需要大量调参的系统太重要了。

需要说明的是，我们并不是完全排斥云端模型。实际架构里，我们保留了“本地为主、云端为辅”的弹性：常规的拆解、审核、整合走本地，遇到特别复杂的创意生成任务，可以按需路由到更强的模型。这种混合路由本身也是 Token 控制的一部分——把贵的能力用在刀刃上。

3.2 整体架构：三层结构

整套系统我们拆成三层，从下到上分别是推理层、编排层、交互层。

推理层负责真正跑模型。每个智能体在这里对应一个推理会话，共享底层的模型权重，但各自维护独立的上下文缓存。这里有个工程细节值得说：共享权重、隔离上下文是省显存的关键。如果每个智能体都加载一份模型，显存直接爆掉。我们用的是同一份模型，通过会话隔离来区分不同角色的上下文。

编排层是圆桌的“会议主持人系统”，负责消息路由、任务状态管理、重试逻辑。它不碰模型，只负责“谁该说话了”“这句话该发给谁”“这个任务卡住了要不要重试”。这一层用的是一个轻量的状态机，每个子任务有明确的状态：待分派、进行中、待审核、已完成、需重做。

交互层是给人用的界面，输入一个 UGC 需求，能看到圆桌讨论的过程和最终产出。我们刻意把中间过程可视化——你能看到每个席位说了什么，这样出问题时一眼就能定位。

3.3 一次完整圆桌的运行时序

把一次真实请求跑一遍，链路是这样的：

1. 用户在交互层输入需求，比如“设计一个以‘失落图书馆’为主题的 Minecraft 探索关卡，要有解谜元素”。
2. 编排层把需求交给 Coordinator，Coordinator 输出一份任务清单，拆成玩法、场景、叙事三个子任务。
3. 编排层按路由表，把玩法子任务发给 Designer，场景子任务发给 Builder，叙事子任务先挂起（等 Designer 的策划要点）。
4. Designer 产出策划要点，编排层从中抽取叙事字段，定向发给 Writer。
5. Writer 和 Builder 各自产出，连同 Designer 的产出一起汇总给 Reviewer。
6. Reviewer 输出问题清单，比如“解谜机制和场景布局不匹配”。
7. Coordinator 拿到问题清单，决定打回 Builder 重做场景部分，还是接受。
8. 最终 Coordinator 收口，输出整合稿给用户。

整个过程里，每个智能体只看到自己需要的信息。Writer 从头到尾不知道建筑方案长什么样，Reviewer 也不需要知道用户最初那句话是怎么说的。这种“信息最小化”是 Token 省下来的根本原因。

4. Token 到底省在哪：三个层面的控制策略

这一节是整篇文章的核心。很多人做多智能体，做着做着发现 Token 没省反而更费了，因为调用次数变多了。我们一开始也踩了这个坑，后来靠三个层面的策略把账算平了。

4.1 上下文层面：让每个窗口都“刚刚好”

第一个层面是控制单个智能体的上下文长度。核心原则是：只放当前任务必需的信息，历史产出用摘要代替原文。

举个例子。Writer 在写 NPC 对话时，它需要的不是 Designer 的完整策划文档，而是其中“这个 NPC 的性格、身份、说话风格”这几个字段。我们在编排层做了一层“字段抽取”，把上游产出里的关键字段结构化出来，只把相关字段喂给下游。这样 Writer 的上下文可能只有几百 Token，而不是几千。

另一个技巧是滚动摘要。对于需要多轮交互的智能体（比如 Coordinator 在整合阶段），我们不把每一轮的完整输出都留着，而是每完成一个子任务就生成一句摘要，替换掉原文。这样 Coordinator 的上下文始终维持在一个可控的长度。

4.2 调用层面：能合并的合并，能跳过的跳过

第二个层面是减少不必要的调用次数。多智能体最容易犯的错就是“为了协作而协作”——明明一个智能体能搞定的事，非要拆给三个，结果调用次数翻倍，Token 总量反而上升。

我们的做法是动态席位。不是每个需求都要五个角色全上。如果用户只是要一段 NPC 对话，那 Coordinator 拆解后可能只激活 Writer 和 Reviewer 两个席位，Designer 和 Builder 直接跳过。编排层会根据任务类型判断需要哪些角色，用最小席位集合完成任务。

还有一个技巧是批量推理。当多个子任务互相独立时（比如同时生成三个不同 NPC 的对话），我们会在一次调用里让 Writer 批量产出，而不是分三次调用。批量推理能显著摊薄每次调用的固定开销。

注意：批量推理不是万能的。如果子任务之间有依赖，强行批量会导致上下文互相干扰。判断标准很简单——如果两个子任务共享同一套设定，可以批量；如果各自独立，也可以批量；但如果一个任务的输出会影响另一个任务的输入，就必须串行。

4.3 缓存层面：把重复计算挡在门外

第三个层面是缓存。多智能体系统里，有些推理结果是高度可复用的。比如 Reviewer 的审核规则、Coordinator 的拆解模板，这些在多次请求之间是稳定的。我们把这些“稳定前缀”做了缓存，命中缓存时直接复用，不重新推理。

这里要提一个实测经验：缓存粒度要细。一开始我们按“整个 System Prompt”做缓存，命中率很低，因为只要 Prompt 改一个字就失效。后来改成按“段落级”缓存，把 System Prompt 拆成若干稳定段落，只有变化的段落才重新计算，命中率一下子提上来了。

另外，对于同一用户在同一会话里的连续请求，我们会复用上一轮的上下文缓存。比如用户先让系统设计关卡，紧接着说“把难度调高一点”，这时 Coordinator 不需要重新拆解，只需要在原有任务清单上做增量修改。这种增量式处理比从头再来省得多。

5. 实测踩坑：那些文档里不会写的教训

5.1 坑一：智能体“抢话”和“死循环”

多智能体协作最经典的坑就是死循环。我们的 Reviewer 一开始设计得太“较真”，它总能挑出问题，于是 Coordinator 就不断打回重做，Builder 改完 Reviewer 又挑出新问题，来回好几轮，Token 哗哗地烧。

根因是缺少终止条件。后来我们加了两道闸：一是最大重试次数，任何子任务最多打回两次，第三次强制接受并标记“待人工确认”；二是问题分级，Reviewer 的问题分成“阻断级”和“建议级”，只有阻断级才触发重做，建议级只记录不阻塞。这两道闸一加，死循环基本消失了。

另一个相关问题是“抢话”——多个智能体同时认为该自己发言，或者都不发言。这本质是编排层的状态机没设计好。我们的解法是显式状态流转：每个子任务在任何时刻只能处于一个明确状态，状态之间的转换由编排层统一裁决，智能体自己没有“决定要不要说话”的权力。

5.2 坑二：角色设定互相“串味”

有一次我们发现 Writer 写出来的 NPC 对话里，居然出现了建筑术语，比如“这个 NPC 站在石英台阶上”。问题是 Writer 根本不该知道建筑方案。排查后发现，是编排层的字段抽取写得太粗，把 Builder 的整段输出都塞给了 Writer。

这个坑的教训是：字段抽取要严格按 schema 来，不能图省事直接透传。我们后来给每个智能体的输入定义了一个明确的 schema，上游产出必须映射到这个 schema 才能传给下游，映射不上的字段一律丢弃。这看起来麻烦，但它把“串味”问题从根上堵住了。

5.3 坑三：本地推理的显存与并发平衡

在 DGX Spark 上跑多智能体，一开始我们想当然地让五个智能体并发推理，结果显存吃紧，推理排队，整体反而变慢。后来才想明白：多智能体的并发不等于同时推理。圆桌讨论本身是有先后顺序的，很多席位在同一时刻并不需要同时工作。

我们改成按依赖关系调度：没有依赖关系的智能体才并发，有依赖的严格串行。同时给推理层设了一个并发上限，超过就排队。这样显存压力下来了，整体吞吐反而更稳。这个经验很朴素但很重要——别为了并发而并发，先看清楚任务之间到底有没有依赖。

5.4 坑四：审核标准漂移

Reviewer 的审核标准如果不固定，会出现“这次严、下次松”的情况，导致产出质量不稳定。根因是 Reviewer 的 Prompt 里审核维度写得太模糊，模型每次理解都不一样。

解法是把审核维度清单化、可枚举。我们把审核拆成固定的几条：设定一致性、玩法可行性、文本风格统一、无敏感内容。每条都有明确的判断标准，Reviewer 只需要逐条打勾或标问题。标准固定了，产出就稳定了。

6. 这套圆桌还能怎么扩展

跑通基础版之后，我们试了几个扩展方向，这里分享两个觉得最有价值的。

第一个是引入“记忆席位”。现在的圆桌是“一次性”的，每次请求都从零开始。但如果用户在做一系列相关的 UGC 内容，比如同一个世界观下的多个关卡，那设定是需要延续的。我们加了一个轻量的记忆智能体，专门维护“世界观设定库”，每次圆桌开始前把相关设定注入 Coordinator。这样跨会话的一致性就有了保障，而且因为记忆是结构化的，注入的 Token 也很可控。

第二个是把审核前置。现在的流程是“先产出、后审核”，但有些问题其实在拆解阶段就能预判。我们尝试让 Coordinator 在拆解时就带上“约束条件”，比如“这个关卡不能出现红石电路”，直接写进子任务描述里。这样下游智能体一开始就不会往错误方向跑，减少了返工，也就减少了 Token 浪费。

最后分享一个我个人在实际操作中的体会：多智能体系统的调优，八成时间花在编排层，而不是模型本身。模型能力是现成的，真正决定这套系统好不好用的，是消息怎么路由、状态怎么流转、上下文怎么裁剪。如果你也在做类似的东西，建议把精力优先投在编排逻辑上，那才是这套系统的“大脑”。

至于 Token 焦虑，说到底它不是靠某个单点技巧解决的，而是靠一整套“让每个环节都只做该做的事”的设计。圆桌这个隐喻之所以好用，就是因为它天然逼着你去想：谁该说话、说什么、说给谁听。想清楚这三件事，Token 自然就省下来了。