OpenClaw 的 Agent Binding：用多账号把你的 AI 变成一个团队

很多人把“多智能体”理解成：给同一个 AI 换几套提示词、切几种人格。

但在生产里好用的，不是人格切换，而是组织结构：

• 谁接单（入口路由）

• 谁执行（岗位分工）

• 谁能看见进度（可观测性）

• 谁能跨岗协作（权限边界）

OpenClaw 里，三块拼起来就够了：

• agents list：岗位和工作台

• bindings：入口分流

• sessions visibility：总控能不能看见、调度、排障

1）先讲人话：三件事分别解决什么

Agent 解决“岗位分工”：每个岗位一张桌子（workspace）+ 一套工具（skills）。

Binding 解决“谁接单”：不同入口账号进不同岗位，天然隔离。

Sessions visibility 解决“管控与观测”：你能不能捞结果、跨会话转交、排障。

2）你要的效果：多账号=多部门，多 agent=多岗位

你可以把 AI 当公司来设计：

• main：总控（收敛需求、验收、拍板）

• coding：研发（只管实现）

• tester：测试与安全（只管验证）

• searcher：情报（只管找资料）

• mp-researcher：内容研究（只管选题、大纲、素材）

• mp-writer-publisher：写作发布（只管成文、排版、草稿）

核心不是一个万能 AI，而是入口分流 + 岗位分工。

3）配置骨架：岗位 + 入口

岗位示例（精简版）：

agents: {
  list: [
    { id: 'main', ... },
    { id: 'coding', skills: ['openclaw-security'] },
    { id: 'tester', skills: ['security-audit'] },
    { id: 'searcher', skills: ['scrapling'] },
    { id: 'mp-writer-publisher', skills: ['wechat-draft-api'] },
  ]
}

入口分流示例：

bindings: [
  { agentId: 'main', match: { channel: 'feishu', accountId: 'main-assistant' } },
  { agentId: 'coding', match: { channel: 'feishu', accountId: 'coding' } },
  { agentId: 'mp-writer-publisher', match: { channel: 'feishu', accountId: 'mp-writer' } },
]

4）别混了：bindings 不是派单

bindings 发生在入口，解决谁接单。

派单发生在执行层（例如 subagent），解决并行增益。

最稳的节奏是两段式交付：

• 先给 v0（立刻可用）

• 再用并行任务做增益（标题、案例、润色）

5）可观测性：sessions visibility 怎么选

四档从小到大：

• self：只看当前会话

• tree：只看当前会话 + 自己 spawn 出去的子会话

• agent：同一岗位的所有会话

• all：全局可见（总控/运维视角）

你要玩成团队，总控通常需要更高可见性；但同时要配 allowlist 做最小放行。

6）可能性：组织化以后，系统会自然变稳

• 串台少了：上下文污染下降

• 流水线成型：Research → Draft → Publish

• 矩阵化：一稿多发，多个渠道多个岗位

• 多租户：不同入口账号 + 不同 workspace，数据不串

7）常见坑

• match 太宽：路由不确定

• 一个岗位装太多技能：错误半径变大

• 把并行任务当唯一交付：用户体验变成等结果

8）行动清单（今天就能做）

• 先拆 3 个岗位：主控 / 研发 / 内容

• 每个岗位只留必要 skills

• 形成两段式交付：先 v0，再增益

9）一句总结

你不是在配 AI。

你是在搭组织结构。