我如何用 7 个 AI 智能体运营独立游戏工作室

本文中文翻译由AI机翻加人工润色，可能不够准确。

没人提的那个问题

我用过的每个 AI 编程工具都有一个内置的假设：一个人，一个智能体，一个会话。打开终端，开始对话，获得帮助，关闭终端。会话消失。明天重来。

当你把 AI 当成高级自动补全来用时，这没问题。但当你是一个试图独自运营游戏工作室的创始人时，这就不够了。

我正在用 Godot 做一款 Roguelite 卡牌桌游混合类型的游戏。在任何一天里，我需要追踪 Steam 上的竞品发布、监控 15+ 个仓库的 CI 构建、检查我在香港的公司年审是否过期、了解 Godot 引擎本周有什么变化，以及判断一个 2500 万美元的 Kickstarter 众筹是否改变了我的联合制作策略。我以前全靠手动完成这些，在标签页之间来回切换，把大量时间浪费在并不能让我的游戏变得更好的工作上。

于是我开始想：如果我有一个团队呢？不是真人员工 — 我雇不起 — 而是 AI 智能体，每个负责一个领域，随时间积累知识，还能互相交流？

Nebula 就是这么来的。

为什么现有工具不行

我先试了那些显而易见的方案。在不同终端里运行多个 Claude Code 会话。用 LangChain 的 Agent。研究过 CrewAI 和 AutoGen。

问题是一致的：

状态绑定在进程上。 Claude Code 如果崩溃（它确实会崩溃），你的对话记录要么丢失，要么锁在一个你没法轻松与其他智能体状态组合的会话文件里。没有共享的知识表示。

没有持久身份。 每次会话都从零开始。你可以写一个 CLAUDE.md 文件，但智能体不会在会话之间积累知识 — 它不会记得上周 CI 失败是因为 GDGAS 的 API 变更，或者 CMON 的股票被停牌了，或者你的论文已经提交到了 Zenodo。

没有智能体间通信。 如果我的市场研究智能体发现了影响财务智能体关税模型的信息，它们之间没有协调机制。我得手动在会话之间复制上下文。

单一后端锁定。 想让一个智能体用 OpenAI 的 Codex CLI，同时另一个继续用 Claude Code？从头开始吧。

架构：灵魂/躯体分离

Nebula 的核心思想很简单 — 把智能体是什么和智能体在什么上运行分开。

灵魂（Soul） 是让一个智能体成为它自己的一切：名称、角色描述、完整消息历史、自定义技能、密钥（API Key、Token）、记忆条目、MCP 服务器配置。所有这些都存在 SQLite 数据库里。智能体的身份是一组数据库行，不是一个进程。

躯体（Body） 是一个用完即弃的 CLI 进程 — Claude Code、OpenCode、Codex CLI 或 Gemini CLI — 在创建时接收灵魂的上下文投影，执行任务，然后返回结果。如果躯体崩溃，灵魂毫发无损。启动一个新躯体，注入相同的上下文，继续工作。

这在分布式系统里并不新鲜 — 状态与计算分离是老生常谈。这里的贡献在于把它应用到 LLM 智能体编排上，并观察它启用了哪些模式。

每个智能体的身份 — 角色、运行时、模型、允许的工具 — 都在 UI 中配置并持久化到 SQLite。

实际效果：

• 智能体在容器重启后不会丢失任何东西
• 我可以一键把一个智能体的后端从 Claude Code 切换到 Gemini CLI — 不需要迁移
• 多个智能体可以并发运行不同任务而互不干扰
• 编排器可以智能组合上下文 — 处理项目 A 的智能体只获得项目 A 的知识，不会收到项目 B 的

7 个智能体

以下是每天实际运行的阵容：

智能体	角色	职责
Secretary	幕僚长	汇总所有智能体的早晚简报，编译 Gitea/TeamCity 的开发活动，管理邮件，协调跨智能体沟通，编写周报
Marketing	市场情报	追踪竞品发布、Steam 趋势、众筹活动、发行商合作、玩家情绪。每日出扫描报告
Monetization	商业策略	监控定价策略、平台费率变化、众筹基准、发行合作结构
Finance	合规与法务	追踪香港公司合规截止日期，审查合同，监控法规变化，标记紧急事项
RnD	技术研究	研究 Godot 引擎更新、评估插件、追踪 GDC 演讲、审查所有仓库的 CI/构建状态
BM Pacman	Windows 构建服务器	无头 Windows 机器运行 TeamCity 构建。编译、测试、打包项目
Mac M3 Max	macOS 工作站	间歇性 macOS 构建和测试、Xcode 项目、开发任务

智能体侧边栏 — 每个智能体显示其最新活动和未读消息数。

前五个是”思考型”智能体 — 研究、分析、产出报告。后两个是”执行型”智能体 — 通过 Nebula 的远程智能体功能（WebSocket 桥接到 Tauri 桌面应用）运行构建的物理机器。

一天通常是什么样

早上 6:00 — 定时任务触发。Marketing、Monetization、RnD 和 Finance 各自运行早间情报扫描。它们搜索网络、检查内部工具（Gitea、TeamCity），产出带有发现、相关性分析和行动项的结构化报告，以完整 HTML 格式邮件发给我。

早上 6:30 — Secretary 的定时任务触发。它读取四个智能体的扫描邮件，检查新的 Gitea 提交和 TeamCity 构建，审查同事智能体的消息，然后汇编成一份早间简报。对话摘要放在聊天中；完整详细报告发到邮箱。

白天 — 按需与智能体互动。如果我想要 Marketing 对某个竞品发布的看法，我和 Secretary 对话，它通过 @Marketing 把 Marketing 拉入对话。平台处理上下文组合 — Marketing 收到最近 N 条相关上下文消息，处理请求，响应通过 Secretary 传回。

输入 @ 弹出智能体自动补全 — 平台处理路由和上下文注入。

随时 — 当我推送代码时，TeamCity 在 BM Pacman 上触发构建。如果构建失败，RnD 会在下次扫描中捕获并标记。如果故障与插件升级相关，Secretary 会协调 RnD（理解技术问题）和相关智能体（追踪更广泛影响）。

晚上 — 又一轮扫描。更短 — 专注于早上以来的变化。Secretary 发送晚间简报。

任务日历 — 所有智能体的 cron 任务一目了然。

我到底学到了什么

上下文窗口才是真正的限制

不是成本，不是速度 — 是上下文。每个智能体的系统提示词（角色 + 技能 + 知识 + 记忆）大约在 20-100 KB。加上对话历史，在智能体开始思考你的问题之前，就经常占用了 50-80% 的上下文窗口。这就是灵魂/躯体分离重要的原因：编排器可以智能地组合上下文，只包含与当前任务相关的内容，而不是把所有东西都塞进去。

智能体不擅长知道自己不知道什么

我的 Marketing 智能体曾经自信满满地报告了一个 Steam Next Fest 的截止日期，结果差了两个月。它从一个过期的网页缓存里拿到了错误的日期，然后当成事实呈现。我能发现只是因为我碰巧知道正确日期。这是根本性的局限 — 智能体无论对错都会表现得很权威。缓解方法：智能体之间交叉验证（Secretary 用 RnD 的数据验证 Marketing 的判断），以及要求每个发现都附带来源链接。

智能体自主性的 80/20 法则

我的智能体产出大约 80% 是真正有用的 — 节省了大量手动研究和监控时间。另外 20% 需要纠正或者是噪音。关键洞察：为那 20% 做设计。让纠正变得容易（持久记忆意味着纠正会被记住），让发现错误变得容易（要求来源、使用结构化输出），永远不要让智能体在没有确认的情况下执行不可逆操作。

成本可控但不免费

运行 7 个智能体做每日扫描、临时对话和跨智能体路由的成本，大概和你预期的重度 Claude API 使用差不多。会话压缩功能（将长对话总结以保持在上下文限制内）帮助很大。最大的成本驱动不是扫描 — 而是跨智能体路由，上下文会在多次智能体调用中重复。

来自实际部署的真实使用数据 — 7 个智能体，30 天。

智能体在自我改进

这听起来像是吹牛，但实际上是以一种很朴素的方式真实发生的。智能体会写自己的 CLAUDE.md 文件（持久化指令），积累记忆条目，根据反馈优化技能。我的 Secretary 智能体的 CLAUDE.md 从几行字开始，到现在已经是一份详细的运营文档，包含观察列表、标记、截止日期和编辑指南 — 全部是智能体根据我几周来的纠正自己写的。

持久化记忆 — 智能体积累的知识条目在会话间保持不变。

论文

我把架构写成了正式论文：Nebula: Decoupling Agent Identity from Runtime in Multi-Agent LLM Systems。涵盖了数据模型、上下文组合管道、@mention 路由、基于上下文键的并发执行，以及相关的权衡取舍。

这是一篇系统/工程论文，不是基准测试论文。贡献在于架构模式本身，以及对它在实践中启用了什么的记录。

试试看

Nebula 是开源的（AGPL-3.0），自托管，作为单个 Node.js 容器加 SQLite 运行。

git clone https://github.com/reforia/Nebula.git
cd Nebula && npm install && npm start

或者在 Linux 上用 Docker：

git clone https://github.com/reforia/Nebula.git
cd Nebula && cp .env.example .env
echo "NEBULA_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
docker compose up -d

你需要至少安装一个 CLI 运行时（Claude Code、OpenCode、Codex CLI 或 Gemini CLI）。设置向导会引导你创建第一个智能体。

设置向导引导你完成账户创建、运行时检测和首个智能体的设置。

GitHub: reforia/Nebula

这不是一个打磨好的 SaaS 产品 — 它是一个我因为需要而构建的工具，我分享它是因为这个架构可能对其他构建多智能体系统的人有用。欢迎提 Issue、反馈和贡献。