先理解核心概念：Agent 就是你的员工

在 OpenClaw 的体系里，每个 Agent 本质上是一位独立的数字员工。一个可行的团队配置如下：

  • 小智（boss）：总指挥，负责统筹规划和任务分发
  • 探探（researcher）：情报专家，专门负责信息挖掘
  • 文文（writer）：内容创作者，擅长文字表达
  • 极客（coder）：技术担当，专注代码开发

每位成员都拥有独立的工作区（Workspace）、身份认证（agentDir）和对话记录（Sessions），彼此互不干扰。具体来说：

  • 工作区：存放工作规范（AGENTS.md）、人设（SOUL.md）、老板资料（USER.md）和工作笔记（memory/）
  • 身份认证：保存登录凭据，每个 Agent 必须独立配置
  • 对话记录：与不同对象的沟通历史，各自隔离

环境准备与初始化

以 Mac 系统为例，打开终端安装必要依赖，看到版本号就说明安装成功。

初始化配置时执行初始化命令，按向导操作：

  1. 选择 yes 开始配置
  2. 选择 QuickStart 快速模式
  3. 选择偏好的 AI 模型（推荐 OpenAI / Claude / Gemini）
  4. 暂时跳过其他高级选项，后续可调整

完成后你就拥有了第一个可用的 Agent。

创建 Agent 团队：两种方式

方式一：命令行向导，适合新手。向导会自动完成所有配置——建工位、发工牌、设置权限。

方式二：手动编辑配置文件，直接修改 ~/.openclaw/openclaw.json，适合有经验的用户精细控制。

这里有几个容易踩坑的点：

  • 身份认证不可共享：每个 Agent 必须有独立的 auth-profiles.json
  • 工作区不可复用：不同 Agent 使用相同的 agentDir 会引发认证冲突
  • 技能库分层管理：工作区内的 skills/ 是个人专属技能，~/.openclaw/skills/ 是全员共享技能库

接入飞书：让 Agent 真正上线

要让 Agent 在飞书里工作，需要为每个 Agent 创建独立的飞书 Bot。

创建步骤：

  1. 登录飞书开放平台（open.feishu.cn），创建企业自建应用
  2. 为四个 Agent 分别创建应用：小智 Bot、探探 Bot、文文 Bot、极客 Bot
  3. 获取每个 Bot 的 App ID、App Secret、Verification Token、Encrypt Key
  4. 开启机器人能力，配置必要权限：
    • 获取用户基本信息
    • 获取与更新群组消息
    • 获取与发送单聊、群组消息
    • 接收群聊中 @机器人消息事件
    • 读取用户发给机器人的单聊消息
    • 以应用的身份发消息
    • 获取与上传图片或文件资源
  5. 修改订阅方式为"使用长链接接收事件"，添加"接收消息"事件
  6. 在"版本管理与发布"中创建版本并发布

然后在 OpenClaw 中为每个 Agent 配置飞书认证信息，按提示输入各自的 App ID、App Secret 等。

群组设置也很关键：

  • 创建一个主工作群，只拉入小智 Bot——这是你发布任务的主界面
  • 创建一个内部协作群，拉入全部四个 Bot，你也可以加入旁观或插话

Bindings：消息路由分配

团队成员就位后，需要通过 Bindings 机制决定消息由谁处理。OpenClaw 按以下优先级匹配：

  1. 精准匹配：指定具体的用户 ID 或群组 ID
  2. 群组匹配：匹配特定群聊
  3. 账号匹配：匹配特定 Bot 账号
  4. 通道匹配：匹配整个通道的所有消息
  5. 默认兜底：以上都不匹配时交给默认 Agent

实际操作中，通过群组和账号组合来区分即可。

打通 Agent 间通信

这是整个方案里最关键的一环。默认情况下 Agent 之间无法互相对话，需要手动开启。

激活通信功能后，还要设置会话可见性。可见性有四个级别：

  • "self"：只看自己的会话，完全隔离
  • "tree"：看自己及派生的子任务（默认）
  • "agent"：看同一 Agent 的所有会话
  • "all"：看所有 Agent 的所有会话，完全开放

Agent 间通信有两种方式，各有适用场景：

  • sessions_send：向已有会话发消息，适合 Agent 已在线有活跃会话的情况
  • sessions_spawn：创建新会话执行任务，适合一次性或需要隔离的任务，支持 mode="run"（一次性）和 mode="session"（永久）

简单理解：sessions_send 是给同事发消息让他现在处理，sessions_spawn 是临时雇个外包干完走人。

建立共享知识库

通信打通后还有一个问题：小智安排给探探的任务，文文和极客并不知情；探探完成的调研报告，其他人得等小智转发才能看到。

解决方案是建立共享目录：

shared/
├── tasks.md          # 任务看板
├── board.md          # 团队公告
└── notes/
    ├── research/     # 调研报告
    ├── drafts/       # 文稿草稿
    └── code/         # 代码和技术文档

配置每个 Agent 的记忆搜索覆盖到共享目录后，探探把调研报告保存到 shared/notes/research/，文文用 memory_search 就能直接搜索到。

定义协作规范

在每个 Agent 的 AGENTS.md 中写清楚工作守则，这一步决定了团队能否真正跑起来：

  • 小智：接收任务后拆解成子任务，通过 sessions_send 分配，实时更新 shared/tasks.md，收到反馈后汇报
  • 探探：收到调研任务立即执行，报告统一存到 shared/notes/research/，完成后更新任务状态
  • 文文：写作前先查阅 shared/notes/ 中的相关资料，草稿存到 shared/notes/drafts/，需要补充资料时通过小智协调
  • 极客：代码和技术文档存到 shared/notes/code/，需要技术调研时通过小智安排探探协助

实战效果

以"撰写一篇 AI Agent 技术文章并配套演示脚本"为例，整个流程是这样的：你在主工作群对小智说一句话，小智自动拆解任务分配给探探做调研、文文写文章、极客写脚本，各专员在自己的领域独立工作，通过共享目录传递成果，tasks.md 实时反映进度，小智负责全程协调和监控。

老板只说了一句话，剩下的全由团队自主完成。

持续优化的方向

搭建完成只是开始。几个实用建议：先从简单任务跑通流程，逐步增加复杂度；根据实际表现持续调整各 Agent 的 SOUL.md 和 AGENTS.md；在 shared/board.md 中沉淀协作规范；定期让小智总结协作中的问题和改进点。多 Agent 协作的价值不在于一次配置到位，而在于在实际使用中不断打磨每个角色的边界和默契。