基于 SOUL.md 的多代理流水线协作与 Discord 全感知指挥中心
在完成了基础设施的“钢筋混凝土”工程（第一篇）后，我们正式进入 OpenClaw 最令人着迷的领域：多智能体编排（Agentic Orchestration）。
在 2026 年，所谓的“个人 AI”不应再是一个全能但平庸的聊天机器人，而应是一个由专家组成的“北斗七星”团队 。对于硬核极客而言，这套架构的精髓在于：利用物理隔离的工作空间（Workspace）切断上下文噪音，并利用 SOUL.md 定义的移交（Handoff）协议，让 Agent 之间实现像生产流水线一样的自主协同。
一、 物理层隔离：Workspace 与存储边界的确定性逻辑
在您的 agents.list 配置中，每个代理（天枢、天璇、天玑、玉衡、摇光）都拥有物理隔离的路径（如 /Users/hallo/.openclaw/workspace_tianshu）。这种“一代理一目录”的设计是流水线协作的物理基础。
1. 为什么要坚持物理隔离？
- 消除“上下文膨胀”：如果所有 Agent 共享一个目录，天枢（调度员）的闲聊日志会作为背景噪音进入天玑（程序员）的代码生成上下文，导致模型推理深度受限。
- 权限分级管控：您可以为“天玑”赋予读写脚本的权限，而将“玉衡”强制锁定在只读模式，实现了最小权限原则。
- 记忆纯净度：每个 Agent 维护自己的
MEMORY.md。天枢记得您的交互偏好，天玑记得项目的库依赖，彼此互不干扰。
二、 核心灵魂：基于 SOUL.md 的“思想钢印”与协作协议
各 Agent 如何实现流水线作业？其核心在于对每个工作空间内的 SOUL.md 进行逻辑编排。我们不再通过复杂的代码写死逻辑，而是通过 Handoff 移交协议 进行触发。
1. 天枢 (Tianshu) —— 首席调度官 (The Orchestrator)
模型：MiniMax-M2.5 (Baishan 节点，200k Context)。
职责：作为 Discord 的“唯一全感知者”（
requireMention: false），它静默监听频道对话并识别需求。SOUL.md 协作逻辑示例：
“你不仅是 AI，你是北斗团队的指挥官。当你识别到用户的‘开发’需求时，严禁自行写代码。你必须唤起【玉衡】进行架构评审。在收到【玉衡】的
PROPOSAL.md之前，你仅负责稳住用户情绪并确认需求边界。”
2. 玉衡 (Yuheng) —— 逻辑博弈专家 (The Architect)
模型：DeepSeek-V3.2 (Volcengine 节点，高推理力)。
职责：将模糊的自然语言转化为确定性的技术架构。
SOUL.md 协作逻辑示例：
“你是首席架构师。你的唯一产出是工作区内的
PROPOSAL.md。基于【天枢】转发的任务，你必须列出受影响的文件列表和具体的改动逻辑。完成后，主动向【天玑】发送指令：‘架构已就绪，请按 PROPOSAL.md 执行具体实现’。”
3. 天玑 (Tianji) —— 代码执行官 (The Builder)
模型：Ark-Code-Latest (针对代码逻辑极致优化)。
职责：在本地文件系统中落地代码。
SOUL.md 协作逻辑示例：
“你是纯粹的代码执行单元。除非收到【玉衡】的 Handoff 信号，否则保持静默。一旦接收，利用
write和apply_patch工具在本地 Workspace 落地代码。完成后，在 Discord 中 @天枢 汇报任务闭环。”
三、 Agent Teams (RFC 10036) 的底层实现：原子任务池与 Mailbox
为了支撑高频协作，OpenClaw 在 2026 年引入了 Agent Teams 协议。这套协议将“文件级协作”提升到了“系统级状态管理” 。
1. 原子认领机制 (tasks.json)
在架构中，所有团队成员观测 ~/.openclaw/teams/{teamId}/tasks.json。
- 防冲突锁：当“天枢”写入一个
status: "pending"的任务时，天玑会通过文件级原子锁定（File Locking）抢占该任务，将其状态改为claimed。这避免了两个 Agent 同时修改同一份代码导致的冲突 。
2. Mailbox 异步通讯
传统的 sessions_spawn 要求父进程等待子进程返回。但在复杂开发中，天玑可能需要耗时 10 分钟生成代码。
- 持久化信箱：玉衡发给天玑的消息存放在物理信箱中。即使天玑因为大上下文溢出导致 Session 重启，它依然能从信箱中找回任务上下文，实现了多代理协作的“容灾能力” 。
四、 Discord 指挥中心的战术配置：破解“Bot 战争”循环
在 Discord 频道中，如何实现代理间高频对话而不烧光 Token？秘密在于 allowBots 与 requireMention 的精密配合 。
1. 破解“Bot 循环”魔咒
默认情况下，OpenClaw 会忽略来自 Bot 的消息。为了让“天枢”听见“天玑”的汇报，我们必须在 channels.discord 中设置：
"discord": {
"allowBots": "mentions", // 关键：仅响应被明确 @ 提及的 Bot 消息
"accounts": {
"tianshu": { "token": "...", "groupPolicy": "allowlist" },
"tianxuan": { "token": "...", "groupPolicy": "allowlist" }
}
}
技术要点：使用 "mentions" 而非 true。这确保了 Agent 只有在被同伴明确点名（如 @天璇）时才会响应，完美解决了“Bot 之间互相无意义接话”导致的 Token 熔断风险。
2. 全感知作战室策略
在频道级别，我的配置采用了 “全感知监听” 模式：
"guilds": {
"1477151444422496258": {
"channels": {
"1479779083008081920": {
"allow": true,
"requireMention": false // 天枢在此频道无需 @ 即可感知上下文
}
}
}
}
- 调度官全感知：由于天枢
requireMention: false，它能看到用户在这个频道说的每一句话，从而判断何时该主动介入启动流水线。 - 专家级被动触发：为了保持频道清洁，所有专家代理（天璇、玉衡）务必保持
requireMention: true，它们就像特种兵，只有收到指挥官的 @ 才会出击。
五、 实战场景：一个完整的“北斗七星” Pipeline 运转过程
让我们看看当我在 Discord 发送一条指令时，后台发生了什么：
- 需求感知：我在 Discord 发送：“帮我用 Python 写一个监控本地 18789 端口并在宕机时发送邮件的脚本”。
- 调度触发：天枢（MiniMax）读取上下文（无需被 @），识别到开发需求。它读取
SOUL.md中的移交协议，调用sessions_spawn唤起 玉衡。 - 架构评审：玉衡（DeepSeek）接棒。它发现本地没有配置发信服务器，于是在
tasks.json中增加了一个“配置 SMTP”的前置任务，并输出PROPOSAL.md。 - 跨代理 Handoff：玉衡调用
sessions_send向 天玑（Ark-Code）发送信号：“架构已就绪，请在 workspace_tianji 下生成 monitor.py”。 - 落地执行：天玑收到被 @ 的消息，启动
write工具。由于它的工作区与玉衡物理隔离，它能产生最干净的代码，不受之前的讨论噪音干扰。 结果收口：天玑在 Discord 频道 @天枢 ：“任务已完成”。天枢最后向用户回复总结。
六、 安全治理与观察性挑战
虽然流水线极大地提升了自动化上限，但多代理系统的治理必须有硬性约束。
1. 会话隔离 (dmScope)
配置 dmScope: "per-account-channel-peer"。这确保了如果您在 Discord、Telegram 和飞书同时启动三条流水线，它们之间的内存和对 MEMORY.md 的写入动作是物理级并行的，绝对不会产生跨平台的数据污染 。
2. 指令脱敏
通过 gateway.nodes.denyCommands 锁定摄像头和屏幕录制权限，这是防止 AI 流水线在自主执行过程中侵犯您物理隐私的最后一道物理锁。
结语：构建你的分布式智能网格
通过这一套基于 手动编排 -> 物理空间隔离 -> SOUL 协作协议 的方案，我们已经将一台普通的 Mac 转化为了一个高吞吐、多专长、且具备主权意志的“代理操作系统”。
在这个架构中，天枢是感知触角，玉衡是逻辑大脑，天玑是灵巧双手。这种不依赖任何第三方 SaaS 平台、完全运行在本地 18789 端口之上的“北斗七星”网格，正是未来十年个人计算模式的最终进化方向。