我把自己的 AI 团队真正跑起来了
最近我做了一件很有意思的事。
不是再加一个模型，也不是再装一个 AI 工具，而是把一套真正能协同工作的 AI 个人团队，在自己的 OpenClaw 节点上跑通了。
这套团队里有四个角色。
Zen 是总协调者，负责决策、拆任务、整合结果。Muse 是内容情报官和写作执行者，负责信息收集、选题和内容草稿。Forge 是技术执行官，负责代码、仓库、构建和维护。Guard 是安全守护者，负责心跳监控、健康检查和异常告警。
如果只看这个分工，听起来像一套很标准的 multi-agent 架构。真正难的地方，不在于把角色名字起得像不像，而在于它们是不是能在真实环境里稳定工作。换句话说，不是能不能想象出来，而是能不能真的跑起来。
这次我最大的收获就是，AI 团队配置这件事，真正的难点从来不是 prompt，而是 prompt、模型、认证、调度、运行时环境、系统边界，全部要对上。
一开始我以为只是改几个模型配置
我手里最初有一份相对完整的团队部署文档。结构其实很好，提示词写得也成熟。每个 Agent 的职责、工作流、心跳机制、告警规则、cron 任务，几乎都已经设计好了。
如果只看文档本身，很容易产生一种错觉，这份东西稍微替换几个变量就可以直接部署。
但真正落地时，我很快发现它有一个典型问题。思路是对的，运行时不一定对。
最典型的冲突出现在模型和认证上。
文档里给 Zen 和 Guard 配的是 openai/gpt-5.4，给 Muse 配的是 minimax/MiniMax-M2.5。这套写法在某些环境里没问题，但放到我当前这台机器上就不成立。因为我的 OpenAI 实际走的是订阅账号 OAuth，不是 OPENAI_API_KEY。MiniMax 这边也不是普通 env key 链路最稳，而是 minimax-portal 的 OAuth 实际可用。
这意味着，如果我照着文档直接覆盖，最可能发生的不是部署成功，而是把原本已经能用的链路改坏。
这件事让我更确信一个判断。配置系统时，最危险的动作不是写错一行，而是把参考方案误当成现网真相。
最后跑通的模型分工，其实很务实
我最后没有执着于某个模型要不要理论最强，而是按角色任务特性来分。
Zen 作为主协调者，主模型使用 openai-codex/gpt-5.4，备用 zai/glm-5。它承担的是复杂上下文理解、多轮整合和关键判断，所以我优先考虑稳定性和综合能力。
Muse 最终不是用 MiniMax 做主模型，而是改成了 zai/glm-5 主、minimax-portal/MiniMax-M2.5 备。原因很简单，Muse 在我的系统里承担的是情报收集、内容组织、草稿生成，这类任务更看重调用稳定和响应顺滑，而不是理论上的模型排名。
Forge 保持 openai-codex/gpt-5.3-codex 主、zai/glm-5 备。它主要是技术执行官，涉及代码、仓库和构建，交给 Codex 路线更合适。
Guard 则更有意思。它的主模型是 zai/glm-5，但 heartbeat 单独指定为 minimax-portal/MiniMax-M2.5。也就是说，普通守护任务和定时巡检，用了两条不同的模型路径。这样做不是为了复杂，而是为了把日常对话和计划性健康检查分层处理。
最终跑通的结构是这样的。
Zen 使用 openai-codex/gpt-5.4，备用 zai/glm-5。
Muse 使用 zai/glm-5，备用 minimax-portal/MiniMax-M2.5。
Forge 使用 openai-codex/gpt-5.3-codex，备用 zai/glm-5。
Guard 使用 zai/glm-5，heartbeat 单独使用 minimax-portal/MiniMax-M2.5。
这套分配看起来没有那么统一，但它是真正按现网跑通结果确定下来的，而不是按想象拼出来的。
真正的大坑，不是模型，是运行时环境
这次最折磨我的部分，不是模型认证，而是子 Agent 为什么一直不回包。
表面上看，Muse、Forge、Guard 都已经配置好了，session 也能创建，Gateway 也在线，cron 也能注册。但一做实际验收，问题就来了。会话能起，消息发过去，结果总是 timeout。
一开始我还以为是模型问题，后来一路查下来，才发现根因根本不在那里。
最开始的第一层问题，是 Docker。
Muse、Forge、Guard 早期配置里都开了 sandbox，意味着它们不是直接在宿主机执行，而是试图在 Docker 沙箱里跑。理论上这很安全，也很优雅，但在个人本地节点场景里，它的副作用也很明显。
第一，路径访问会复杂很多。第二，宿主机上的工作区、日志、配置、仓库路径，在容器里不一定是直通的。第三，启动成本会明显增加。一旦 Docker daemon 状态有波动，子 Agent 就可能直接卡死。
这也是为什么一开始它们普遍表现为 session 能建立，但没有真正完成 turn。
后来我把 Muse、Forge、Guard 统一改成 sandbox.mode: off，问题一下子收敛了。这个改动不是退步，而是更符合实际。对个人本地节点来说，直接访问宿主机文件系统，反而比容器隔离更稳。
这件事让我意识到一个很重要的原则。不是所有架构里更强隔离的方案，都适合个人使用场景。有些企业级思路，放在个人工作流里只会增加摩擦。
最后卡住 Guard 的，居然不是 Guard
当我以为只剩 Guard 没修好的时候，又踩到了一个更底层的问题。
Guard 表面上像是最后一个单点故障，但继续往下查，真正异常的并不是它的提示词，也不是它的模型，而是 OpenClaw 本体安装状态不一致。
最直接的表现，是程序在运行时去加载某个 dist 模块时，引用到的 hash 文件已经不存在了。也就是说，系统里有一部分文件来自旧版本，有一部分文件来自新版本，最终 import 关系断裂，导致运行层面出现模块缺失。
这一步很关键，因为它把排障方向从继续改 Agent 配置拉回到了先修平台本身。
后来在重新安装 OpenClaw 之后，之前一直卡住的 Guard 也恢复正常了。那一刻很说明问题。有时候你以为自己在修业务层，实际是在踩平台层的坑。
最终四个 Agent 全部回包成功。
Muse 正常。
Forge 正常。
Guard 正常。
Zen 正常。
直到这一步，我才敢说这套 AI 团队是真的跑起来了。
提示词不是不重要，但不能神化
这次还有一个让我很有感触的点。
外部文档里的 prompt 确实写得不错，尤其是角色边界、工作流、告警思路、内容风格这些部分，很多都值得吸收。但真正落地时，我没有整份照抄，而是做了选择性吸收。
比如 Zen 的角色定义，我保留了第二大脑、首席参谋、执行搭档这条主线，但把创新连接方向改得更贴近当前工作现实，从 AI × 科学仪器 / 教育 / 企业管理 转成了 AI × 原生开发 / 教育 / 应用落地。
Muse 的写作要求也做了调整。新文档里把分析报告拉到了 8000 到 16000 字，方向没错，但如果无差别执行，会让日常情报写作变得过重。最后我把它改成分层策略。深度专题可以长，日常分析要克制，思考类保持轻量。
这些调整看上去像小改动，但它们决定了这套系统到底是为了显得高级而存在，还是为了长期可用而存在。
我最后确定了一条更实用的方法论
如果未来还有人要搭自己的 AI 团队，我会建议他把事情分成三层。
第一层是角色设计。每个 Agent 到底负责什么，边界是否清楚，流程是不是可执行。
第二层是运行时真相。你当前机器上的认证方式、provider、模型、路径、sandbox 策略，到底是什么，别拿模板替代事实。
第三层是验收方式。不要只看配置文件，不要只看 doctor 结果，也不要只看 session 创建成功。一定要做真实回包测试。能不能真的回复一句话，能不能真的执行一轮任务，比一切看起来正常都重要。
这次我真正学到的，不是某个命令，而是一个朴素但经常被忽视的原则。
AI 系统不是靠文档跑起来的，是靠一轮轮真实验收跑起来的。
这套系统现在意味着什么
对我来说，它已经不只是四个 bot。
它更像一个开始成形的个人 AI 组织。
Zen 负责判断和统筹。Muse 负责感知外部世界并把信息转成内容。Forge 负责把技术动作做扎实。Guard 负责在系统开始出问题之前先看到异常。
这四个角色未必完美，但它们已经不是单点工具，而是一套能协作的工作结构。
我觉得这才是 AI 真正有意思的地方。不是再多加一个聊天窗口，而是开始搭建一种可以长期协作的数字工作系统。
如果说这次折腾最终留下了什么，我想不是我配好了一套 AI 团队，而是我开始更清楚地知道，怎样把一套 AI 团队从想法，变成能稳定工作的现实。