小龍蝦的效果，不取決于“模型多強”，而取決于“定位是否清晰”。
所以多 Agent 不是花活，而是把復(fù)雜工作拆成可控模塊。

一、為什么一定要配多 Agent？

很多人一上來就想要一個“萬能小龍蝦”：
既能寫文章、又能改代碼、還能做運營復(fù)盤。

聽起來很爽，但實際很容易翻車。

因為一個 Agent 的工作效果，本質(zhì)上是被這套“靈魂三件套”約束的：

• SOUL.md：它的性格、表達(dá)風(fēng)格、做事邊界
• USER.md：它服務(wù)誰、用什么溝通方式
• AGENTS.md：它的職責(zé)和協(xié)作規(guī)則

問題在這兒：

如果定位太寬，三件套就會非常難調(diào)。
你會遇到這些典型問題：

• 一會兒像技術(shù)顧問，一會兒像營銷號，風(fēng)格漂移
• 同一個需求，今天做得好，明天做歪（不穩(wěn)定）
• 提示詞越補越多，系統(tǒng)越來越難維護

所以正確做法不是“讓一個 Agent 無所不能”，而是“讓每個 Agent 各司其職”。

二、定位做細(xì)了，能力會不會變窄？

會。

但這不是缺點，這是工程化取舍。

你把單個 Agent 定位越細(xì)，它越穩(wěn)定；
但單個 Agent 能覆蓋的任務(wù)范圍，也會越小。

這時候就需要多 Agent 協(xié)作。

比如你做公眾號這件事，至少是三段工作鏈路：

1. 選題規(guī)劃（寫什么）
2. 內(nèi)容生產(chǎn)（怎么寫）
3. 數(shù)據(jù)運營（發(fā)完怎么優(yōu)化）

這三段能力模型完全不同，強行塞進(jìn)一個 Agent，后期一定難調(diào)。

三、飛書不是“一個應(yīng)用=一個 Agent”嗎？

這是很多人卡住的點。

飛書側(cè)確實是：

• 一個應(yīng)用，通常對應(yīng)一個機器人

但 OpenClaw 的架構(gòu)里，飛書只是最外層消息通道。

所以你可以這樣理解：

• 飛書應(yīng)用：負(fù)責(zé)“收發(fā)消息”
• OpenClaw：負(fù)責(zé)“把消息路由給哪個 Agent”

核心玩法

一個飛書應(yīng)用 + 一個機器人 + 多個飛書群 + OpenClaw 綁定規(guī)則

也就是：

• 一個機器人進(jìn)多個群
• 每個群綁定不同 Agent
• 不同群發(fā)來的消息，自動路由到不同 Agent

這就是“一個飛書應(yīng)用跑多 Agent”的關(guān)鍵。

四、配置只看 3 個地方：agents / channels / bindings

1）agents：定義你有多少個小龍蝦

這部分就是 Agent 清單。

{
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "name": "主agent",
        "workspace": "/root/.openclaw/workspace"
      },
      {
        "id": "dev",
        "name": "開發(fā)助理",
        "workspace": "/root/.openclaw/workspace-dev"
      },
      {
        "id": "content",
        "name": "內(nèi)容助理",
        "workspace": "/root/.openclaw/workspace-content"
      },
      {
        "id": "ops",
        "name": "運營增長",
        "workspace": "/root/.openclaw/workspace-ops"
      }
    ]
  }
}

實操建議：

• 每個 Agent 用獨立 workspace（方便沉淀各自記憶）
• 每個 Agent 只做一類事（不要混崗）
• 保留一個 main 作為總控

2）channels：定義 OpenClaw 接了哪些消息渠道

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "xxxxxxxxxxxx",
      "appSecret": "XXXXXXXXX",
      "domain": "feishu",
      "groupPolicy": "open",
      "groupAllowFrom": [
        "群1id",
        "群2id",
        "群3id"
      ],
      "requireMention": false
    },
    "wechat-access": {
      "enabled": true,
      "wsUrl": "wss://mmgrcalltoken.3g.qq.com/agentwss"
    }
  }
}

你這個配置里，說明已經(jīng)接了飛書 + 微信兩個渠道。

兩個關(guān)鍵參數(shù)：

• requireMention: false
  • 在群里不用 @機器人 也能觸發(fā)
• groupAllowFrom
  • 只接收白名單群消息（強烈建議開）

小提醒：你草稿里寫了 fasle，發(fā)文時記得改成 false。

3）bindings：把“群”和“Agent”綁起來

這部分是整個多 Agent 路由的核心。

{
  "bindings": [
    {
      "agentId": "content",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "群1id"
        }
      }
    },
    {
      "agentId": "dev",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "群2id"
        }
      }
    },
    {
      "agentId": "ops",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "群3id"
        }
      }
    }
  ]
}

一句話解釋：

哪個群發(fā)消息進(jìn)來，就按綁定規(guī)則，交給對應(yīng) Agent 處理。其實就是群和agent的對應(yīng)關(guān)系

五、一套可直接落地的公眾號團隊分工

如果你要做“內(nèi)容閉環(huán)”，我建議先用這 3 個 Agent：

• planner：選題與發(fā)布節(jié)奏
• writer：正文寫作與改稿
• ops：標(biāo)題測試、數(shù)據(jù)復(fù)盤、二次分發(fā)

對應(yīng)飛書建 3 個群：

• 選題群 → 綁定 planner
• 寫作群 → 綁定 writer
• 運營群 → 綁定 ops

這樣做的好處是：

• 討論上下文不串臺
• 每個 Agent 的三件套更容易調(diào)
• 后續(xù)擴容（比如短視頻 Agent）也簡單

六、容易踩的 4 個坑（提前避掉）

1. Agent 定位重疊

   • 兩個 Agent 都在“寫內(nèi)容”，最后誰都不穩(wěn)定

2. 沒有群白名單

   • 機器人被拉進(jìn)新群后，容易誤觸發(fā)

3. workspace 復(fù)用

   • 多 Agent 共用一個 workspace，會互相污染記憶

4. 先堆功能，后做邊界

   • 正確順序是：先定角色邊界，再加能力

七、綜上所述

多 Agent 的本質(zhì)不是“多開幾個機器人”，而是把復(fù)雜工作拆成多個可調(diào)、可控、可復(fù)用的角色系統(tǒng)。

你要的是“穩(wěn)定交付”，不是“萬能人設(shè)”。

我現(xiàn)在調(diào) Agent 的思路很簡單：
先把單點任務(wù)做穩(wěn)定，再談跨角色協(xié)作。

以前我也試過把所有事塞進(jìn)一個 Agent，短期看省事，長期看就是災(zāi)難。
后面拆成角色后，提示詞長度下降了，輸出穩(wěn)定性反而上來了。

如果你看到這，說明你是真的在做事，不是只看熱鬧。

你要是也想把 OpenClaw 多 Agent 這套跑順，我把我自己正在用的配置和踩坑經(jīng)驗，慢慢分享給你。

wx:quven2014，直接加我就行。

備注一下【OpenClaw】，我看到會優(yōu)先通過。

本文由mdnice多平臺發(fā)布