Claude Code游戏工作室：49个Agent背后的真相

当49个Agent挤进一个模板

Claude Code Game Studios 是一款将 49 个 agent 与 74 个 skill 打包进同一模板的项目。很多人对「多 agent 协作」的第一反应是越多越强，但这个模板的 README 却给出了一个反直觉的结论：最重的构建排在最后。这句话值得单独拆开看，因为它指向了多 agent 系统里一个常被忽略的成本结构问题。

README 自曝的「垫底」结果

据原始信息，README 明确记录了这一排序结果，但并未给出完整的评测方法论。这既是它可贵的地方，也是需要警惕的地方：可贵在于作者没有藏起对自己不利的数据；警惕在于，缺少可复现的评测细节时，我们只能把它当作一个方向性信号，而不是精确的基准结论。

从工程直觉推断，agent 与 skill 数量增加会带来上下文占用、调度开销和结果收敛难度的同步上升。「最重的构建排最后」这一现象，与「规模换质量」的朴素预期正好相反，说明在这套系统里，配置策略的选择可能比堆叠数量更关键。

「最重的构建」在这类多 agent 模板语境下，通常指同时启用的 agent 数量最多、依赖的 skill 链最长、上下文与调度开销最大的那套配置组合。把它与其余配置放在同一维度下排序，本质是在比较不同组合的端到端表现，而非单个 agent 的能力上限。这类排序对评测方法高度敏感：任务类型、成功判定标准、是否计入 token 成本与延迟，都会改变名次。因此 README 的结论更适合读作「重配置在该作者的评测条件下没有表现出优势」，而不是「重配置一定更差」。理解这一点，才能正确使用后面关于 rigor 档位与裁剪策略的建议。

modes.rigor：先调好这档旋钮

原始信息提到 modes.rigor 是使用该模板时需要设置的配置项。虽然素材没有展开它的具体取值与语义，但从命名可以判断它与「严谨度」相关——这类配置通常决定 agent 在流程中投入多少校验、复核与自我检查。

实践上的建议是：不要一上来就全开。先用最轻的组合跑通完整流程，再逐步提高 rigor 档位，观察输出质量与耗时的变化曲线。这样做的好处是，你能建立自己的基线，而不是直接继承别人的默认值。

在多 agent 编排中，rigor 一类参数通常不是单一开关，而是影响多个环节的乘数：它可能决定 agent 是否进行额外的自我复核、是否触发交叉验证、在结果不一致时是否追加一轮协商，以及是否要求更完整的证据链。档位提高时，单次任务的往返轮数与上下文占用会同步上升，收益则取决于任务本身是否容错——对探索性、开放式的游戏设计任务，过高的校验强度可能压制发散；对需要严格一致性或可验证输出的环节，高 rigor 才有明显回报。因此合理的做法是按流程阶段分别设定 rigor，而不是全局统一拉满。

该跳过什么

原始信息同样指出「what to skip」是需要回答的问题，但没有列出具体清单。基于模板类项目的常见结构，可以给出判断原则而非具体名单：与当前任务目标无直接关联的 agent、以及流程中重复覆盖同一环节的 skill，是最优先的裁剪对象。

如果你不确定某项是否该跳过，一个简单办法是先跑一次不带它的流程，比较输出差异。差异可忽略，就说明它是冗余配置。

多 Agent 模板的取舍逻辑

Claude Code Game Studios 的价值不在于「49」这个数字本身，而在于它把多 agent 编排做成了一份可拆解的模板。74 个 skill 与 49 个 agent 提供的是一套可选件库，而不是必须全装的成品。真正决定效果的是你如何组合它们，以及 rigor 这类参数如何与任务难度匹配。

把它当成一份「配置说明书」而不是「性能保证书」，才是这类模板最合理的打开方式。