我把游戏策划桌搬进了 AI Agent：一次用 JiuwenSwarm 做创意协作的实验

我把游戏策划桌搬进了 AI Agent：一次用 JiuwenSwarm 做创意协作的实验

做游戏策划最有趣也最危险的地方，是每个人脑子里都有一款"完美游戏"。世界观同学想写一千年王朝兴衰，数值同学盯着成长曲线，剧情同学想安排反转，关卡同学只关心玩家第一分钟会不会迷路。每个人都对，但拼在一起时，游戏可能就不对了。

所以这一次，我没有让 AI 直接"生成一份游戏策划案"。我更想测试一个问题：AI 能不能像一张真正的策划桌，让不同角色各自发声，再让冲突浮出水面？

这篇文章更像一份创作工坊记录。重点不是"AI 写了多少字"，而是它如何帮我把世界观、数值、剧情、关卡之间的矛盾摆出来------因为策划案真正难的，从来不是内容不够，而是内容之间互相打架。

一、先说工具：JiuwenSwarm 是什么，为什么选它

openJiuwen 是一个开源的 AI Agent 生态体系，JiuwenSwarm 是其中的核心应用。官方对它的定位是"懂你所想，自主演进"------它不是一个只负责回答问题的聊天窗口，而是把任务规划、工具调用、技能执行、记忆管理、浏览器操控、文件读写和 Channel 接入等能力组织在一起，让 Agent 能围绕一个目标持续推进任务。简单说，普通对话更像"问一句答一句"，JiuwenSwarm 更像一个可以拆任务、用工具、调技能、维护工作区的本地智能工作台。

请添加图片描述

理解 JiuwenSwarm 的关键，不只是理解"一个 Agent 能做什么"，还要理解"多个 Agent 怎么一起做事"。这对游戏策划尤其重要。

因为游戏策划天然不是单线程任务。一个"废土邮差探索游戏"的想法，至少会同时牵出几条线：

• 世界观：废土为什么存在？各个城镇靠什么维持秩序？
• 玩法：玩家每天做什么？探索、交易、战斗还是路线规划？
• 数值：资源怎样消耗？奖励多久给一次？失败代价有多大？
• 剧情：玩家为什么送信？谁在操纵信息？
• 关卡：地图怎么引导？第一关教什么？中期如何变化？
• 一致性：如果世界缺水，为什么商店能无限卖补给？

如果只让一个 Agent 回答，它大概率会写出一份漂亮但松散的设定------看起来丰富，实际很难进入原型。这时候就需要 Agent Swarm。

Agent Swarm：不是多开窗口，而是角色协作

Agent Swarm 可以理解为一支由 AI 组成的临时项目组。它和"多开几个聊天窗口"有本质区别：有一个 Leader 负责理解目标、拆解任务、创建成员、分派工作、跟踪进度；也有不同 teammate 负责具体专业任务。它不是简单地让同一个模型多说几段不同语气的话，而是把复杂任务拆成多个角色、多个阶段、多个交付物，再通过协调机制把结果汇总起来。

以游戏策划为例，单个 Agent 当然也能给出一份策划案，但它很容易把世界观、数值、剧情、关卡混在一起，导致重点不清，也不利于发现矛盾。Agent Swarm 的做法更接近真实团队协作：

• 创意总监先锁住方向和边界
• 世界观、玩法、数值、剧情、关卡各自独立创作
• 一致性编辑专门做跨角色的矛盾检查
• 方案整合员收集所有产出，汇总成可行的策划案

在 JiuwenSwarm 的"集群模式"下，这个过程是可以被观察到的。你会看到 team leader 创建任务、生成 DAG、spawn member、分配给不同队友执行。也就是说，"多个 Agent 在执行"并不一定表现为页面上同时刷出很多聊天气泡，而是通过任务事件、队友创建、工具调用和阶段汇总体现出来。整个协作过程可追踪、可复盘。

Coordination Engineering：让协作不靠运气

但"有多个角色"还不够。关键问题是：怎么设计这支团队才能稳定工作？

这就是 Coordination Engineering（协同工程）要解决的问题。如果说 Agent Swarm 回答的是"谁来做"，那么 Coordination Engineering 回答的是"怎么让他们稳定地一起做"。它关注的不是某个 Agent 的单点能力，而是整套协作系统的设计：

• 需要哪些角色？
• 谁先做，谁后做？
• 哪些任务可以并行？
• 哪些上下文需要隔离？
• 角色之间意见冲突时要不要调和？
• 失败时怎么降级？
• 最终交付物应该长什么样？

对游戏策划来说，Coordination Engineering 比单纯生成内容更重要。因为创意工作最需要的不是共识，而是有组织的分歧------什么时候发散，什么时候收敛；冲突出现时是硬圆设定，还是保留取舍方案让人类做最终决策。

Swarm Skill：把协作经验沉淀成可复用的团队

JiuwenSwarm 提供了 Swarm Skill 机制，可以把一次成功的协作方式沉淀成文件。一个 Swarm Skill 通常包含：

• SKILL.md：说明这支团队能做什么
• roles/：定义每个角色的职责和输出格式
• workflow.md：规定执行顺序和并行关系
• bind.md：划定边界------什么不能做、冲突怎么处理、降级策略
• dependencies.yaml：描述依赖和降级方式

如果说 Agent Swarm 解决的是"当下怎么协作"的问题，那么 Swarm Skill 解决的是"协作模式如何沉淀、复用和进化"的问题。这样一来，下次再遇到类似的策划需求，不需要重新设计整套 Prompt，而是直接复用这支团队。

二、环境准备：搭一个独立的创作实验台

为了让实验环境干净、可重复，我给这次的游戏策划项目单独搭了一套 JiuwenSwarm。官网教程：https://www.openjiuwen.com/docs-page

# 创建虚拟环境
python -m venv .venv

# 激活虚拟环境（macOS / Linux）
source .venv/bin/activate
# Windows 用户使用：.venv\Scripts\activate

# 安装 JiuwenClaw
pip install jiuwenclaw

初始化工作区：

jiuwenclaw-init

启动服务后访问：

http://localhost:5173

默认端口是 5173，可在 .env 文件中通过 FRONTEND_PORT 自定义。

启动后需要配置大语言模型（API Key、模型名称等），配置完成后点击对话测试，能正常回复就说明环境就绪了。

当然你也可以在 .env 进行配置。具体详见文档：https://www.openjiuwen.com/docs-page

开始测试一下吧：

三、设计这支策划团队

Swarm Skill Creator：一句话生成一支团队

Swarm Skill Creator（全名"团队技能自动生成专家"）是 JiuwenSwarm 社区提供的一个官方技能，专门用来创建、转换和修改 Swarm Skill。它本身不是一个多角色团队，而是一个帮你设计团队的单 Agent 工具。

简单说：你只需要告诉它"我想要一支什么样的团队"，它会自动完成从角色设计、工作流编排、边界约束到依赖配置的整套文件生成。

它支持三种工作模式：

模式	触发场景	产出
CREATE	从零开始，"帮我创建一个做 X 的团队"	完整的 Swarm Skill 目录（5 个核心文件 + 角色文件）
CONVERT	已有单 Agent 技能，想升级为多角色团队	转换后的 Swarm Skill + 升级对比报告
MODIFY	已有 Swarm Skill，需要增减角色或调整流程	更新后的相关文件

它的内部工作流大致分为 6 个阶段：

1. Triage（评估）------先判断这个任务是否真的需要 Swarm Skill，如果单 Agent 就能搞定，它会直接告诉你不需要建团队
2. Pattern Selection（模式选择）------根据任务特点选择对抗检查（A）、并行分解（B）、流水线（C）或混合模式
3. Role Design（角色设计）------为每个角色生成身份、成功标准、边界、输出格式和内联 Persona
4. Workflow + Bind（流程和约束）------编写工作流（含 Mermaid 图）和行为约束
5. Dependencies + SKILL.md（依赖和入口）------自动扫描本地可用技能和工具，匹配给各角色
6. Validate（校验）------运行自动化校验脚本，确保文件结构、角色引用、跨文件一致性全部合规

在 JiuwenSwarm 中使用时，可以从 SwarmSkills Hub 安装这个技能，然后在集群模式下直接用自然语言描述需求，它就会帮你完成团队的搭建。

给 Swarm Skill Creator 的需求

我希望它生成的不是"游戏文案机"，而是一支真正的游戏策划小组。

请创建一个 Swarm Skill：game-design-studio-team。

用途：面向游戏开发者和独立创作者，辅助世界观、核心玩法、数值、剧情、关卡设计，
并处理多角色创作中的一致性冲突。

请设计一支游戏策划协作团队，至少包含：创意总监、世界观维护者、玩法设计师、
数值平衡师、叙事设计师、关卡设计师、一致性编辑、方案整合员。

要求：

- 输出偏向可进入原型验证的轻量策划案，不要写成不可落地的宏大设定集。
- 不复刻已有游戏 IP、角色、地图或剧情。
- 世界观、玩法、数值、剧情、关卡之间出现冲突时，要显式列出冲突和取舍方案。
- 支持集群模式下多角色协同，也支持纯文本降级运行。

这里最关键的一句是**"显式列出冲突"**。很多策划问题不是没有答案，而是答案太多。让冲突浮出来，才有机会做取舍。

任务执行中，首先创建了一个 team leader，用于统领这个任务。

创建完成，我们就可以使用他了。

这张策划桌上坐了谁

game-design-studio-team 里有 8 个角色：

creative-director（创意总监） 负责先锁住游戏愿景。它会问：玩家幻想是什么？目标平台是什么？第一版原型做多大？哪些内容暂时不碰？

world-lore-keeper（世界观维护者） 管世界观规则。它不是写设定百科，而是维护"这个世界什么能发生、什么不能发生"。

mechanics-designer（玩法设计师） 管核心玩法循环。玩家输入什么，系统反馈什么，失败有什么代价，奖励为什么让人继续玩。

economy-balancer（数值平衡师） 管数值和成长。它给出的数字都只是原型假设，需要后续测试，不会假装一次就平衡了。

narrative-designer（叙事设计师） 管剧情和任务动机。它的职责不是写长篇小说，而是让剧情服务玩家行动。

level-designer（关卡设计师） 把玩法和剧情落到关卡里。玩家在哪学会机制，在哪遇到压力，在哪得到奖励。

consistency-editor（一致性编辑） 是专门挑刺的角色。世界观、剧情、数值、关卡哪里打架，它就把问题摊开。这是整个团队里最关键的角色------别的角色在创造，它在找矛盾。

pitch-synthesizer（方案整合员） 负责最后整理：轻量策划案、原型任务清单、路演摘要，或者下一轮迭代计划。

四、一次测试：废土邮差的第一版原型

团队就绪，下面用一个具体的游戏想法来测试它的实际效果。

测试输入

使用 game-design-studio-team 帮我设计一个独立游戏原型。

方向：俯视角废土邮差游戏。
玩家扮演在几个聚落之间送信的人。世界缺水，信息被少数势力控制。
我希望游戏有路线规划、资源管理、少量剧情选择，不想做复杂战斗。

请输出：
- 一句话体验目标
- 核心玩法循环
- 世界观基本规则
- 前 3 个关卡草案
- 初始资源和奖励假设
- 世界观、数值、剧情、关卡之间的潜在冲突
- 下一步原型清单

任务执行期间多个 SubAgent 协同作战。

Team leader 总指挥，向各个 SubAgent 下发任务。

任务全部执行、团队成员均处理完毕，最终产物交付。

我最关注的产出：冲突暴露

8 个角色各自给出了世界观、玩法循环、数值假设、关卡草案等内容。这些内容单独看都合理，但 consistency-editor 做完交叉检查后，指出了几个关键冲突：
冲突 1：世界缺水 vs 商店无限补给
如果水是核心资源，商店怎么能随便卖？
冲突 2：信息被控制 vs 邮差能接触大量信件
普通邮差为什么能看到敏感信息？
冲突 3：不想做战斗 vs 路上有危险
没有战斗，危险怎么体现？
冲突 4：资源管理 vs 前 3 关太安全
如果前期没有资源压力，资源管理就没有意义

这四个冲突，任何一个都能让策划案在后续开发中翻车。而如果只让一个 Agent 输出完整文档，它大概率会自圆其说------把这些矛盾藏起来，给你一份看起来很圆润的方案。

consistency-editor 给出的取舍方案

冲突	方案 A	方案 B	建议
世界缺水 vs 商店卖水	商店存量有限，补货周期 3 天	水只能从"水源点"采集，商店只卖其他物资	方案 A 更适合原型验证
邮差接触敏感信件	信件有密封度，拆开会降低信誉	只有特定任务才给敏感信件	方案 A 增加了"拆不拆"的博弈
没有战斗但有危险	用环境威胁：沙暴、迷路、脱水	遭遇 NPC 拦截，用谈判/贿赂/逃跑解决	两者可以共存
前期太安全	第 1 关就给"刚好够"的水量	第 2 关引入岔路，选错路会多消耗资源	两者结合使用

level-designer 的前 3 关草案

关卡	教什么	核心体验	预计时长
第 1 关	路线选择 + 水量消耗	"出门就要算水量"	5-8 分钟
第 2 关	岔路 + 传闻系统	"不是所有路都能走，不是所有消息都可信"	8-12 分钟
第 3 关	第一次道德选择	"送达真相还是隐瞒真相？"	10-15 分钟

这三个关卡形成了清晰的学习曲线：机制 → 信息判断 → 价值观选择。比"设计 10 个关卡"的泛泛规划实用得多。

整体流程

整个协作过程可以概括为：
创意总监锁定游戏愿景
世界观 / 玩法 / 数值 / 剧情 / 关卡并行创作
一致性编辑做冲突检查
方案整合员输出轻量策划案
下一轮迭代或进入原型开发

复盘与总结

这次测试跑完，我回头梳理了几个值得记录的点：

做得好的部分：

• 冲突暴露机制有效。consistency-editor 找到的 4 个冲突（缺水 vs 商店、信息管制 vs 邮差权限、无战斗 vs 危险、资源管理 vs 前期安全），每一个都是真实的设计矛盾。如果只用单 Agent，这些矛盾大概率会被"自圆其说"藏起来。
• 关卡草案可直接进原型。level-designer 给出的 3 关设计（机制教学 → 信息判断 → 道德选择）形成了清晰的学习曲线，不是空中楼阁式的"设计 10 个关卡"。
• 数值标注为"假设"而非"结论"。economy-balancer 输出的所有数字都带有"待原型验证"标记，避免了 AI 常见的"假装一次就平衡了"的问题。

可以改进的部分：

• 角色之间的交叉引用还不够深。比如 narrative-designer 的剧情设计和 level-designer 的关卡节奏之间，目前只靠 consistency-editor 做事后检查。如果能在创作阶段就互相传递上下文，产出会更紧密。
• creative-director 的"砍需求"力度可以更强。第一版原型应该更小，目前输出的内容偏多，独立开发者可能还需要手动再砍一轮。
• 缺少玩家测试视角。8 个角色都是"设计者视角"，没有一个角色模拟"第一次玩的玩家会怎么想"。下次可以考虑加一个 playtester 角色。

一句话总结：Agent Swarm 不是让策划案变完美，而是让策划案里的问题更早被看见。

五、生成后的 Skill 结构

生成后的团队文件放在：

.jiuwenclaw/agent/jiuwenclaw_workspace/skills/game-design-studio-team

主要文件：

文件	作用
SKILL.md	团队入口：描述团队能力、角色列表和触发条件
workflow.md	工作流：Mermaid 流程图 + 各阶段执行顺序和质量门
bind.md	行为约束：资源上限、角色隔离规则、失败处理策略
dependencies.yaml	依赖声明：各角色所需的技能和工具
roles/creative-director.md	创意总监
roles/world-lore-keeper.md	世界观维护者
roles/mechanics-designer.md	玩法设计师
roles/economy-balancer.md	数值平衡师
roles/narrative-designer.md	叙事设计师
roles/level-designer.md	关卡设计师
roles/consistency-editor.md	一致性编辑
roles/pitch-synthesizer.md	方案整合员

其中我认为最有价值的是 bind.md。它规定了几条关键边界：

1. 不复刻现有 IP------不能把某个已有游戏的系统原样搬来叫"致敬"
2. 数值只是假设------所有数字必须标注"待原型验证"，不能假装一次就平衡了
3. 不把冲突硬圆成设定------如果世界观和玩法打架，不要编一个新设定来自圆其说，而是把两个方案都列出来让人类决策
4. 输出必须可进入原型------策划案的每一条都要能对应到"下周可以开始做的东西"

第 3 条最重要。普通 AI 遇到矛盾时的本能反应是"解释"，而好的策划流程需要的是"暴露"。

六、回头看：AI 更像会议组织者，而不是灵感替身

Agent Swarm 在创意场景里的价值不是"灵感更多"，而是"灵感更有组织"。

单个 Agent 很擅长发散，但游戏开发需要的是发散之后的收束。哪个机制先做，哪个设定先砍，哪个数值只是测试值，哪个剧情必须服务关卡------这些都需要协作结构来回答。

Coordination Engineering 在这里就像会议规则：先锁体验，再分角色创作，再做冲突检查，最后只留下能进入原型的东西。

这套方法不只适用于游戏策划。任何需要多角色创意协作的场景------产品设计评审、技术方案对齐、营销内容生产------都可以用同样的思路：拆角色、定流程、设约束、查冲突。Swarm Skill 的价值正在于此：一次设计好的协作结构，可以反复用在不同的项目上。

对独立开发者来说，这意味着：你不需要真的找到 8 个策划来讨论，但你需要一个结构让创意被有组织地检验。JiuwenSwarm 提供的就是这个结构------它不替创作者做梦，但能让梦更快落到纸面、落到原型里。

---

相关资源：

• openJiuwen 官网：https://www.openjiuwen.com
• SwarmSkills Hub（Swarm Skill 社区）：https://teamskills.openjiuwen.com
• JiuwenClaw 快速开始文档：https://www.openjiuwen.com/docs-page

如果你也用 Agent Swarm 做过类似的创意实验，欢迎在评论区交流你的团队设计思路和踩过的坑。