之前关于飞书多 Agent 的教程发布后，不少朋友已经跑通了“一号多用”的入门模式。但后台有位硬核老哥提出了一个很尖锐的观点：既然 Sub-agent 已经能实现后台静默协作，追求那种‘全员出镜’的重型方案，是不是显得有点多余？把流程拆解成步骤交给一个 Bot 不就行了吗？
这个观点确实代表了目前圈内一种主流认知：追求极致的极简和效率。
然而，我最近在 Discord 上调试了一套全新的“灵系军团”阵列，带给我的体验是颠覆性的。看着5个独立的 Agent 在一个频道里实时穿插、透明协作，那种掌控感和过程可见性，是任何后台模式都无法替代的。
在正式分享配置之前，有必要先理清两种完全不同的“大模型统帅学”。
两种协作模式：分身术 vs 独立团
1. 飞书篇的“分身术”：单渠道单账户
这是我之前分享的入门打法：一个机器人分身服务所有 Agent。
- 逻辑：通过
binding 规则按群 ID 进行路由，让同一个机器人在不同的群里扮演不同的角色。
- 特点：用户只需要面对一个 Bot，配置极简，非常适合个人日常轻量办公。
2. Discord 篇的“独立团”：单渠道多账户
这是我最近尝试的硬核打法：一个专家角色对应一个独立的 Bot 账户。
- 逻辑：在同一个 Discord 频道里，灵统（指挥）、灵策（军师）、灵工（工程师）等5个专家全员在线，身份边界极度清晰。
- 价值：这种模式实现了 “同频群聊协作” 。当你亲眼看到军师出方案、工程师秒接指令、创作官同步写文案时，那种全透明的协作张力与过程可见性，是后台静默模式永远无法提供的。
技术没有绝对的优劣，只有场景的适配。如果你已经玩腻了“单 Bot 分身”，想体验指挥一支 AI 军队、看着它们在频道里实时协作的快感，那么今天这篇 “单渠道多账户” 的实操指南，就是为你准备的。
核心架构：同频群聊模式
不同于传统的后台调用，我们的“灵系军团”采用的是 全公开的广播机制。
看到这个架构你可能会问：为什么需要5个 Bot 还要一个“灵统”来指挥？平等协作不是更民主吗？
答案恰恰相反——在群聊环境中，绝对的平等协作往往是灾难。每个 Bot 都在判断“这句话是在叫我吗？”，结果要么全部抢着回复，要么集体沉默装死。
“灵统”就是那个“拍板的人”。任务进来先由它接收和判断，它来决定派给谁，其他专家 Bot 只需要专注把自己的活干漂亮。这套架构的核心在于：
- 每一个角色都是独立实例：灵统、灵策、灵工等在后台都是独立的 Agent 进程。
- 环境全感知：通过
sessions.visibility: "all" 配置，打破会话隔离，实现上下文穿透。
- 精准唤醒：利用 Discord 的原生提及功能（
<@BotID>），精准点名对应的专家。
当然，你可能会质疑：OpenClaw 本身支持 Sub-agent，为什么还要搞这么“重”的多账户方案？
这个问题很好，答案也很明确：Sub-agent 和多账户军团，解决的根本不是同一个问题。
Sub-agent 是后台静默执行，用户看不见过程，只拿结果。它效率高、节省 Token，适合追求极简的场景。
但这篇文章的核心是 “协作可见性” 。当你需要向团队演示、向客户汇报，或者单纯自己想看清楚每一步决策是如何发生时，这种全透明的同频协作就展现出无可替代的价值。就像开会，你可以让秘书背后协调，但有些时候，你需要把相关人拉到一起，当面把事情说清楚。
实操配置：组建你的灵系军团
下面，我们一步步搭建这支透明协作的 AI 队伍。
Step 1. 账号绑定与路由配置 (bindings)
要组建独立团，第一步是去 Discord 开发者门户，为每个角色申请独立的 Bot 账户。
1、建立总部：创建应用
访问 https://discord.com/developers/applications，点击 New Application。应用名称建议使用统一前缀，例如 灵统、灵策。
2、核心：开启 Bot 的“感知能力”
在左侧 Bot 页面，找到 Privileged Gateway Intents 区域，务必勾选以下两项，否则你的 Bot 将无法正常工作：
- ☑
SERVER MEMBERS INTENT
- ☑
MESSAGE CONTENT INTENT (关键！ 不开启此项，Bot 无法读取消息内容)
3、领取令牌：Reset Token
点击 Reset Token 生成并保存那串密钥。这是 Bot 的唯一身份证，只会显示一次，务必妥善保存。
4、邀请入群：OAuth2 URL 生成
在 OAuth2 -> URL Generator 中勾选 bot 和 applications.commands 作用域。
在下方的 Bot Permissions 中，根据你的需求勾选必要权限，例如“查看频道”、“发送消息”、“嵌入链接”等。
复制底部生成的链接，在浏览器中打开，选择你的 Discord 服务器，完成授权。
为“灵策”、“灵工”、“灵文”、“灵核”重复以上1-4步骤，创建总共5个独立的 Discord Bot 应用。
Step 2. 招募你的“灵系”员工 (Agent & Workspace)
拿到所有 Bot 的 Token 后，回到本地终端，使用 openclaw 命令行工具为每个角色创建独立的 Agent 和工作区。建议为5个角色创建独立的 Workspace 目录，实现真正的物理隔离。
依次执行以下命令：
# 1. 招募总指挥 (ds-lingzong)
openclaw agents add ds-lingzong --model zai/glm-4.7 --workspace ~/.openclaw/workspace-ds-lingzong
openclaw agents set-identity --agent ds-lingzong --name "总指挥"
# 2. 招募军师 (ds-lingce)
openclaw agents add ds-lingce --model zai/glm-4.7 --workspace ~/.openclaw/workspace-ds-lingce
openclaw agents set-identity --agent ds-lingce --name "军师"
# 3. 招募工程师 (ds-linggong)
openclaw agents add ds-linggong --model zai/glm-4.7 --workspace ~/.openclaw/workspace-ds-linggong
openclaw agents set-identity --agent ds-linggong --name "工程师"
# 4. 招募创作官 (ds-lingwen) 和 审核官 (ds-linghe) 命令格式同上
# openclaw agents add ds-lingwen ...
# openclaw agents add ds-linghe ...
执行完成后，你的 ~/.openclaw/ 目录下会生成5个以 workspace- 开头的文件夹。这种物理隔离是防止 AI “神经错乱”的关键。
验证环节：打开 ~/.openclaw/openclaw.json 文件，检查 agents.list 部分是否已经整齐地列出了5个独立的 Agent 配置块。
Step 3. 部署通信枢纽 (Config 路由)
这一步的目的是建立 Discord Bot 账号与本地 Agent 的映射关系。编辑 ~/.openclaw/openclaw.json 文件，在 bindings 数组中添加如下配置（请将 accountId 和 agentId 替换为你自己的值）：
"bindings": [
{
"agentId": "ds-lingzong", // 对应 Step 2 创建的本地 Agent ID
"match": {
"channel": "discord",
"accountId": "lingzong" // 对应 Step 1 中你在配置文件里给这个Token起的名字
}
},
{
"agentId": "ds-lingce",
"match": {
"channel": "discord",
"accountId": "lingce"
}
},
{
"agentId": "ds-linggong",
"match": {
"channel": "discord",
"accountId": "linggong"
}
},
// ... 为 ds-lingwen, ds-linghe 添加类似的绑定配置
]
避坑提醒：
accountId 必须和 channels.discord.accounts 对象下的键名完全一致。- 如果发现某个 Bot 在 Discord 说话但本地 Agent 没反应，优先检查这里的映射关系是否写错。
这是实现同频协作最关键也最容易出错的步骤。需要配置三个核心部分。
1、完善账号与安全隔离配置
我们需要在 openclaw.json 的 channels.discord.accounts 下为每个账号进行详细配置，实现细粒度的安全控制。
{
"channels": {
"discord": {
"enabled": true,
"allowBots": true, // 【重点】必须为 true，否则子 Bot 会无视指挥官（另一个Bot）的指令
"actions": {
"reactions": false, // 建议关闭，防止互刷表情导致意外触发
"messages": true,
"threads": false
},
"accounts": {
"lingce": { // 对应你在 accounts 里定义的账号别名
"token": "你的 Bot Token",
"groupPolicy": "open",
"guilds": {
"你的服务器ID": { // 你的 Discord 服务器 (Guild) ID
"requireMention": true, // 【安全】必须被@提及才响应，防止死循环
"users": [ // 【严谨】白名单：只听你和其他4个Bot的指令
"你的用户ID",
"灵统的Bot用户ID",
"灵工的Bot用户ID",
"灵文的Bot用户ID",
"灵核的Bot用户ID",
"灵策的Bot用户ID" // 自己也要加，用于识别自身消息
],
"channels": { // 【精准】指定授权频道，防止在闲聊区刷屏
"你的频道ID": {"allow": true}
}
}
}
}
// ... 为 lingzong, linggong 等其他账号按此结构依次配置
}
}
}
}
配置逻辑解析：
allowBots: true：在多 Bot 协作中，指令常由“灵统”发出，此开关必须打开，子 Bot 才会响应另一个 Bot 的消息。users 白名单：必须将指挥官（灵统）和其他协作 Bot 的 User ID 加入列表，否则它们会相互视作“陌生人”而拒绝协作。channels 配置：一旦定义了此字段，就进入了“白名单模式”，未列出的频道将被屏蔽。
2、赋予跨Agent通信能力
为了让“灵统”能向其他专家 Bot 分派任务，需要开启 agentToAgent 工具权限。
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["ds-lingzong", "ds-lingce", "ds-linggong", "ds-lingwen", "ds-linghe"]
}
}
3、打破信息孤岛，实现上下文共享
这是实现“全员全知全能”的底层逻辑。必须开启会话可见性，让所有 Agent 共享频道内的全量对话上下文。
"tools": {
"sessions": {
"visibility": "all" // 【灵魂开关】让所有 Agent 共享频道内的全量上下文
}
}
为什么必须开启？ 如果不开启 all，当你@“灵工”时，它只知道被@了，却看不见前面“灵策”出的方案和“灵统”提的要求。开启后，每个 Bot 都能感知频道里发生的一切，就像坐在同一张桌子前开会。
Step 5. 配置识别信号 (Mention Patterns)
最后一步，为每个 Agent 配置精准的唤醒词，让它们在群聊中准确识别属于自己的指令。
在 openclaw.json 的 agents.list 下，找到每个 Agent 的配置块，添加 groupChat 和 mentionPatterns。
{
"agents": {
"list": [
{
"id": "ds-lingzong", // 你 Step 2 创建的 Agent ID
"name": "ds-lingzong",
"identity": { "name": "总指挥" },
"groupChat": {
"mentionPatterns": [
"<@!?1474005066569617551>", // 【核心】Discord 原生 ID 匹配（最稳健）
"灵统", // 【增强】昵称或简称唤醒词
"1474005066569617551" // 【兜底】纯数字 ID 匹配
]
}
}
// ... 为 ds-lingce, ds-linggong 等其他 Agent 按此格式依次修改
]
}
}
终极实战：两种协作场景测试
配置完成后，这支“灵系军团”到底表现如何？我测试了两种不同的指令模式。
场景一：模糊指派，考验“灵统”的决策力
如果你任务目标明确但不想操心细节，可以直接对“大脑”发号施令。
我的指令：
@灵统 启动‘灵系极简协作’！我想发个朋友圈，主题是‘深夜还在折腾 OpenClaw 终于跑通了’。
军团表现：
“灵统”瞬间完成拆解，判断核心是“内容创作”，于是直接点名委派“灵文”接手，并给出了“真实感+小成就感”的风格建议。“灵文”秒出列，一口气提供了三个版本文案和配图建议。
这种无需多言、一击即中的默契，正是中枢指挥系统的价值。
场景二：精准委派，考验军团的执行精度
如果你对产出有明确要求，可以直接在指令中排兵布阵。
我的指令：
@灵统 启动‘灵系极简协作’！我想发个朋友圈，主题是‘深夜还在折腾 OpenClaw 终于跑通了’，请：1. 灵策：帮我定一个文案风格。2. 灵文：根据军师定的调性，写出两段文案。
军团表现：
-
灵统调度：迅速解析指令，明确分工给灵策和灵文。
-
灵策定调：“灵策”出列，经过场景分析，推荐了“凡尔赛风格”并阐述了理由。
-
灵文创作：“灵文”展现了全感知能力，它既听到了我的原始指令，也捕捉到了“灵策”刚刚定下的“凡尔赛”调性，丝滑地输出了两版符合要求的文案。
整个流程在同一个频道中透明展开，你可以随时插话修正，每个 Bot 都能实时感知最新上下文。这种 “所见即所得”的协作体验，正是多账户独立团模式的核心魅力。
结语：从技术执行到组织设计
搞定这套“灵系军团”，你掌握的将不再是一堆冷冰冰的代码和配置，而是一支拥有明确分工、可实时观测的 AI 团队。虽然这套模式在 Token 消耗和配置复杂度上高于后台静默方案，但它所带来的 “同频协作感” 和 “组织设计力”，对于需要过程透明、实时干预或团队演示的场景而言，价值巨大。
很多人认为多 Agent 是个技术问题，但深入实践后你会发现，它更接近一个组织管理问题——你实际上在设计一个会思考、能协作的微型组织架构。在 AI自动化工作流 的探索道路上，这种对协作过程的可视化和精细化控制，或许能为我们打开新的思路。
AI 时代，一个人或许真的可以成为一支军队的指挥官。你的“灵系独立团”组建完成后，准备派它们去攻克的第一个任务高地是什么呢？欢迎在技术社区分享你的实践和想法，例如在 云栈社区 与更多开发者交流碰撞。
发表于 20 小时前
|
查看: 1|
回复: 0
