一位开发者在四到五个月里，把一家小型游戏工作室的大部分运营交给了AI智能体。AI智能体是一种接收目标、将其拆分为任务并调用工具完成任务的软件。把一份大型项目规格交给这套系统，智能体们就会在代码、角色美术、音乐和质量测试等方面完成数十小时的工作。目前的成果是一款黑桃（Spades）纸牌游戏，已提交苹果App Store审核。这套架构并不是一开始就被设计成宏大的系统，而是从仓库文件里的一条规则和一个负责分派工作的协调智能体逐步发展起来的。
什么是智能体系统
这里所说的智能体系统由三部分组成：作为智能的模型、作为指令和边界的规则，以及真正完成工作的工具。把这三者组合起来运行的外层框架被称为harness。
ChatGPT、Codex和Claude Code本身已经是智能体系统，只是大多数人都在开发这些产品的公司所写的规则下使用它们。一旦开始自己编写规则，工作方式就会改变：
- 输入提示词、看到不理想的结果再重新输入提示词，这种习惯被视为去年的工作流程。
- 今年夏天以来发布的前沿模型，似乎更适合接收目标，而不是逐行的编码指令。
- 要按目标分派工作，就需要规则明确写出智能体可以做什么、绝不能做什么，以及团队如何协作。
第一条规则可以非常简单。在AGENTS.md或CLAUDE.md文件中写上一行，例如不要直接推送到生产环境，就足以起步。之后在需要时再逐条添加规则。
把一款真实的Mac应用变成由协调者主导的项目
一个例子是一款在售的Mac菜单栏应用。它会显示Claude或OpenAI订阅的使用额度还剩多少，以及按当前用量是否会提前用完。一个Git仓库里同时包含Mac应用本身、产品介绍页、销售页面和分发流程。
在Claude Code桌面应用中，与该仓库关联的聊天会话被要求担任编排者（orchestrator），也就是负责分派工作、跟踪进度的主导智能体，而不是亲自写代码。指令要求它：
- 理解每个请求，并把工作分派给子智能体或单独的线程
- 为每项任务选择合适的模型层级和推理强度（reasoning effort），即模型投入多少思考
- 在任务于后台运行时，始终保持可以与人对话的状态
- 无需询问，主动报告哪些子智能体正在运行、其状态以及项目里程碑
Claude Code接受了这一角色，并列出了模型分配方式：
| 模型 | 分配的工作 |
|---|---|
| Haiku | 查询、重命名和机械性修改 |
| Sonnet | 常规实现、运行测试、网站和导出任务 |
| Opus（高强度） | 用量节奏、预测、通知、价格档位、许可和PR审查等关键工作 |
它还承诺采用工作树隔离。当多个智能体修改同一批文件时，各自在独立的Git工作树中工作，即同一仓库的单独检出副本，这样合并时改动就不会冲突。
规则应写进AGENTS.md，而不是工具的记忆
起初，Claude Code把这些运行规则保存在了自己的本地记忆中。但一个工具内部的记忆只对该工具有用，于是智能体被要求把规则移到仓库里。它在AGENTS.md中添加了一个九行的“How we work”部分，并删除了记忆中的副本。这样，Codex等其他编程工具也能遵循同样的规则。在一个新会话中被问到自己是执行者还是编排者时，模型援引仓库规则，立即回答自己是编排者。
▲ 并行运行的三项任务
同时处理三项工作
接着，编排者收到一个包含三部分的请求：确认在售版本与仓库中的发布版本一致，运行自动化测试套件，并构思两到三个新功能。它把请求拆成三个后台任务，并实时展示一张包含智能体名称、模型、推理强度和状态的表格。
| 任务 | 模型和强度 | 结果 |
|---|---|---|
| 版本检查 | Sonnet，低 | 确认公开发布版本为2.3.0（14） |
| 运行测试 | Sonnet，中 | 43个测试套件共356项测试全部通过，含构建在内约17秒，无编译器警告，构建已完成公证和签名 |
| 功能构思 | Opus，中 | 提出3个功能方案 |
负责构思的智能体在自己的线程里读取了项目历史、速率限制和配置文件，主聊天窗口始终没有卡住。它提出的方案包括：显示过去八周用量的活动条、预测会话额度会在五小时重置前何时耗尽的提醒，以及按项目列出最耗用量会话的明细。人选择了活动条，并让编排者先由Opus撰写规格，再交给Sonnet在隔离的工作树中实现。
不妨与在多个标签页中分别打开智能体会话的做法比较一下。那样无法在一处查看整体进度，而且每次都得由人手动选择模型和推理强度。中等强度的Opus足以胜任功能构思，但架构路线图这类工作似乎更适合更高的强度。如果编排者退回到逐个执行任务而非并行执行，解决办法是调整AGENTS.md中的指令。
把这一思路扩展为游戏工作室
把同样的思路用到公司层面，就形成了一组部门，每个部门都有自己的文件夹：
- 每款游戏各有一个部门，例如黑桃和克里比奇（Cribbage）
- 市场部门和制作人部门
- 供所有游戏复用的UI、会话管理、大厅和核心游戏逻辑等共享套件
工作室还有自己的仪表盘。其中一个用环形图展示由主管、执行者、共享规则和部门组成的组织。角色工具管理肖像、配音表演档案和台词修改。音频工具整理音乐和音效，并统一采样率和比特率；一次搜索显示出205首音乐，音效库中收录了949个音效片段。发布仪表盘则跟踪App Store审核要求、截图、法律声明和营销素材。
耗时较长的评估由Lab部门负责。它在本地硬件上运行，但可以与外部测试台通信。指导原则是去中心化：长时间运行的任务应放在托管环境中，而不是依赖一台笔记本电脑整天开机。
制作人与架构师
支撑整个工作室的是两个角色。
制作人（Producer）是接收人类指令的主要窗口。它把目标拆解为计划、分配执行者，并通过四个阶段的循环跟踪产出：
- 理解与规划
- 配置人员并启动
- 观察与恢复
- 评估与整合
在工作室的看板上，制作人同时处理设计、工程和市场方面的请求，其中包括黑桃游戏的14张进行中请求卡片，并在推进过程中登记后续事项。
架构师（Architect）是内部的调节者。它检查每个部门的运行状况，如果某个部门反复失败或需要一再返工，就把纠正指引写进该部门的规则。当业务扩展时，例如开发新游戏或开始制作营销视频、发布社交媒体内容，架构师会创建边界清晰的新部门；不再需要的部门则会被撤并，以保持组织精简。
十条共享规则
每个部门都继承十条共享规则：人类意图、责任归属、主管与执行者、真正启动、质量、恢复、持久工作、托管与交付、学习，以及完整范围。这些规则让各部门以相同方式编写文件、按相同约定沟通，并达到相同的质量标准。
整个架构始于一个目标：做一款黑桃游戏。最先出现的是设计文件夹，然后是黑桃代码文件夹，再然后是独立的角色库。当克里比奇和巴棋戏（Parcheesi）开始共享素材和工具后，这些文件夹逐渐发展成如今的多部门工作室。
▲ 按部门组织的AI游戏工作室
人类始终掌控的部分
这套系统既不是完全自主的，也并不完美。人类担任创意总监，把个人品味融入游戏，并就功能和用户体验做出决定。更常见的误区或许恰恰相反：以为AI只能处理单个文件的小段代码，从而忽视了它能承担多少公司运营工作。
从一条规则和一个编排者开始
没有必要一开始就设计一个多部门工作室。复杂性应当来自真实项目中遇到的真实阻力。一个合理的起步顺序如下：
- 在现有仓库中添加AGENTS.md或CLAUDE.md文件，写入一条禁止事项。
- 让主聊天窗口担任编排者而不是亲自写代码，并让它为每项任务选择模型层级和推理强度：快速检查和测试用Haiku或低强度的Sonnet，架构和构思用高强度的Opus。
- 要求修改同一批文件的子智能体在不同的工作树中工作。
- 要求以表格形式报告状态，列出模型、强度和完成情况。
- 把运行规则保存在仓库中受版本控制的文档里，而不是某个工具的私有记忆中。
- 每当智能体卡住或重复同一个错误时，就把这条教训变成一条新规则。
随着项目增多，再把共享代码拆分为独立模块，并考虑增设负责接收指令的制作人和负责系统健康的架构师。仓库里的一条规则只是一个不起眼的起点，但这家工作室正是从这样的起点发展起来的。