ARTICLE · 1279601
AI 助手怎样分工?两个开源项目把协作落到聊天与游戏开发
OSS RADAR · 开源雷达 · 2026.10.30
AI 助手怎样分工？两个开源项目把协作落到聊天与游戏开发 · 值得跟踪的开源项目
同时用 Claude、Codex 做事，任务分给谁、操作电脑前由谁批准，很快会变成实际问题。OpenMausBot 把本地 Agent 做成聊天联系人；另一个项目 Claude Code Game Studios 给游戏开发补上角色和阶段检查。两个项目处理的协作问题不同，选择也应从任务出发。
对照固定版本 README 和开放 issue，可以看到它们增加了哪些组织方式。以下命令均为文档示例，未实测，不代表已经跑通。
01
PART
OpenMausBot 先把 Agent 放进聊天窗口
SECTION
OpenMausBot 底层调用已安装并登录的 Claude、Codex 或 Grok CLI。模型能力来自这些引擎，项目新增的是聊天界面、执行环境和批准入口。每个 bot 可以有自己的模型、电脑和连接应用。
试用成本较低的是发布包，其中已内嵌 harness（管理 Agent 进程的小服务器）。源码开发需要 Node 24+、pnpm，以及至少一个已登录的 Agent CLI。固定 README 的启动示例如下，三个开发进程需分别保持运行。
git clone https://github.com/milind-soni/OpenMausBot && cd OpenMausBot
pnpm install
pnpm dev:server # harness server → 127.0.0.1:8799
pnpm dev # app → http://127.0.0.1:5199
pnpm dev:desktop # Electron shell; keep the two commands above running
文档给出的访问地址是本机 5199 端口；它是开发界面地址，不能当成实测输出。Windows 安装包尚未代码签名，Ubuntu 24.04 x64 为 Beta，采用前应核安装包来源与系统支持。
02
PART
批准卡把操作停在人能看见的位置
SECTION
界面通过 HTTP 发指令，服务器把各引擎事件汇成 SSE（持续推送事件的连接），再送回聊天窗口。权限代理把 shell 命令、文件修改等请求呈现为批准卡。用户能在对话里允许或拒绝，具体安全性仍取决于权限设置和实际执行路径。
图为项目 README 原始截图，展示批准与问答如何进入聊天；它说明交互设计，不证明操作隔离已经通过独立测试。原图。
本地优先也有范围。聊天记录、密钥和事件保存在本机目录，但接入云电脑或第三方应用仍涉及外部服务。Boat 试用后收费；Composio 连接应用需要相应账户与授权。Ubuntu Wayland 的本机控制仍禁用，Xorg 需明确开启，不能从“能聊天”推导出“能安全接管所有电脑”。
issue #3873 报告网页固定面板遇到网站禁止 iframe 嵌入时解释不足。这是一条用户报告，未在此复现，也不能据此判定整个发布版不可用。
03
PART
Game Studios 把游戏开发拆成角色与阶段
SECTION
Claude Code Game Studios 适合已经在 Claude Code 中做游戏、希望约束设计和开发步骤的人。固定 README 列出 49 个 agents、74 个 skills；仓库简介仍写 72 个 skills，二者有口径差异，这里采用 README。
它用导演、部门负责人和专门角色分工，再用 hooks（在特定操作时执行的检查）约束流程。配置集中在根目录的 project.yaml。前置依赖包括 Git、Claude Code、Python 3 和 Bash。文档示例未实测。
git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game
cd my-game
随后在含 CLAUDE.md 与 project.yaml 的根目录启动 Claude Code，执行文档中的 /start。README 提醒，从子目录启动会跳过项目 hooks、deny 规则和先询问权限模式。这个细节比角色数量更影响采用。
流程也有成本。README 自报的游戏对比中，minimal 在首行游戏代码前写 1 份文档，standard 写 30 份；两名盲评者与人工试玩把 standard 排最后。这是项目方报告，完整实验条件与独立复现不足，不能当成普遍规律，更不能承诺一键做出完整游戏。
issue #147 报告阶段脚本双写失败会留下状态不一致，指向当前固定 commit。采用前应在副本验证阶段切换失败后的恢复，再决定是否依赖它管理项目。
04
PART
哪些值得试，哪些无需整套搬入
SECTION
截至北京时间 10 月 30 日来源快照，OpenMausBot 为 7456 stars、1112 forks，当日热榜新增 1190；Game Studios 为 29152 stars、4042 forks，当日新增 538。热度不等于质量。前者发布版为 v0.1.133，后者 v1.2.0 发布于 10 月 19 日，不能都叫今天的新版本。
许可证也要分开看。OpenMausBot 开源部分为 Apache-2.0，enterprise/ 另有 source-available 许可，打包依赖保留各自条款；Game Studios 为 MIT。
相关工具可帮助缩小选择。OpenMausBot 的相关候选中，open-notebook 为 40927 stars，偏研究笔记；CopilotKit 为 38369 stars，偏应用内 Agent 界面。它们承担不同工作，不能直接替换聊天工作台。
Game Studios 的相关候选中，andrej-karpathy-skills 为 226425 stars，agent-skills 为 111746 stars，偏通用编码行为与工程技能。只想改善代码助手习惯，可以先看这类较窄的工具；需要游戏角色分工和阶段流程，再考虑 Game Studios。
需要聊天式管理多个本地 Agent，可以从 OpenMausBot 的批准路径试起；需要游戏开发流程，则先验证 Game Studios 的项目根目录与阶段切换。两者都应从副本和低权限任务开始，保留人工检查。
想继续看这类带用法和限制的开源项目拆解，欢迎自愿把公众号设为星标。
我是千哥，持续分享 AI 工程化观察与干货，这里记录从论文、开源项目到工程系统的拆解。
