Discord Cross-Gateway Delegation
Run a full Discord-based delegation loop between two OpenClaw bots on different PCs/gateways.
Core rule
Treat the second bot as an external worker, not as an internal session.
Do not use same-gateway assumptions like sessions_send, local subagents, or same-process routing.
Supported operating model
A complete delegation flow should include all of these stages:
- 1. private delegation lane setup
- structured task envelope protocol
- optional DM natural-language trigger on the controller side
- worker-side intake in the delegation lane
- worker started/final replies in the lane
- relay-back of the final worker result into the original DM
If only steps 1-2 are working, the setup is incomplete.
Protocol rule
Use a protocol namespace that matches the worker lane.
Examples:
- - MACJINI lane:
[MAC_TASK], [MAC_STATUS], INLINECODE3 - KAIJINI lane:
[KAI_TASK], [KAI_STATUS], INLINECODE6
Do not mix worker identity and protocol prefix unless you are intentionally keeping a legacy compatibility layer.
What to read first
- 1. INLINECODE7
- INLINECODE8
- INLINECODE9
- If the worker is a secondary execution bot, INLINECODE10
- If anything fails, INLINECODE11
Operating guidance
- - Prefer a private server delegation lane over public channels.
- Support both quick handoff and orchestrated handoff.
- For real work, prefer orchestrated handoff: the controller bot should understand the task first, generate the worker-facing envelope itself, then delegate.
- Keep quick handoff as a shortcut for simple tests and short tasks.
- Test DM trigger, lane intake, and DM relay-back as separate checkpoints.
- Consider the setup successful only when the final worker result appears back in the original DM.
- A lane message alone is not success.
- A worker reply in the lane alone is not success.
If channel messages fail
Read references/diagnosis.md.
If the worker bot responds in DM but not in server channels, first assume a guild-channel inbound policy issue.
For groupPolicy: allowlist, explicitly add the target guild/channel under guilds, then re-test channel-based worker intake before falling back.
Discord 跨网关委派
在两台不同PC/网关上的OpenClaw机器人之间运行完整的基于Discord的委派循环。
核心规则
将第二个机器人视为外部工作者，而非内部会话。
不要使用同网关假设，例如sessions_send、本地子代理或同进程路由。
支持的操作模式
完整的委派流程应包含以下所有阶段：
- 1. 私有委派通道设置
- 结构化任务信封协议
- 控制器端可选的自然语言DM触发
- 工作者端在委派通道中的任务接收
- 工作者在通道中的开始/最终回复
- 将工作者最终结果回传至原始DM
如果仅步骤1-2正常工作，则设置不完整。
协议规则
使用与工作者通道匹配的协议命名空间。
示例：
- - MACJINI通道：[MACTASK]、[MACSTATUS]、[MACDONE]
- KAIJINI通道：[KAITASK]、[KAISTATUS]、[KAIDONE]
除非有意保留旧版兼容层，否则不要混用工作者身份和协议前缀。
优先阅读内容
- 1. references/setup-checklist.md
- references/operating-modes.md
- references/full-process.md
- 如果工作者是次级执行机器人，请阅读references/macjini-rollout.md
- 如果任何环节失败，请阅读references/diagnosis.md
操作指南
- - 优先使用私有服务器委派通道而非公共频道。
- 同时支持快速交接和编排式交接。
- 对于实际工作，优先采用编排式交接：控制器机器人应先理解任务，自行生成面向工作者的信封，然后进行委派。
- 将快速交接保留为简单测试和短任务的快捷方式。
- 将DM触发、通道接收和DM回传作为独立检查点进行测试。
- 仅当工作者最终结果出现在原始DM中时，才视为设置成功。
- 仅通道消息不算成功。
- 仅工作者在通道中的回复不算成功。
如果频道消息失败
请阅读references/diagnosis.md。
如果工作者机器人能在DM中回复但无法在服务器频道中回复，首先假设是公会频道入站策略问题。
对于groupPolicy: allowlist，需在guilds下明确添加目标公会/频道，然后在回退前重新测试基于频道的任务接收。
