OpenClaw + Discord + 6 個 Agent：我的多 Agent 協作方案與踩坑全記錄

OpenClaw 23 萬 star 了，最近我也持續使用和探索 OpenClaw，用它做了很多項目和優化，如OpenClaw 多端同步實戰：三台設備自動互通，我的開源方案和踩坑全記錄、Claude Code 寫完了你還不知道？一個桌面通知工具解決！，越來越覺得它是一個能跟着個人工作和生活一起迭代的助理，能對個人工作生活產生巨大幫助。

今天這篇文章分享一些我的使用經驗和踩坑記錄，前半部分是openclaw介紹（說實話雖然這麼火，這麼多人用，但可能很多人都沒瞄過一眼官方文檔，只把它當做黑盒agent），後半部分是我使用openclaw的經驗和方案，是我在燃燒近兩billion claude-opus-4-6  token後的收穫。看完後你應該能對 OpenClaw架構有個清晰的瞭解，也希望這些經驗能對屏幕前熱愛折騰的你有一些幫助或啓發。

▲ 近期 OpenClaw + Claude 的 token 消耗統計

下面先介紹下 OpenClaw 是什麼、它的核心架構設計，然後細聊我的多 Agent 實踐經驗。

1 OpenClaw 是什麼

OpenClaw 是一個跑在你自己設備上的個人 AI 助手框架。

官方定義："A personal AI assistant you run on your own devices."

它的核心設計是：一個 Gateway 進程 + 一個或多個 Agent + 你熟悉的聊天平台。Gateway 7×24 小時運行在你的 Mac Mini、筆記本或 VPS 上，連接 WhatsApp、Telegram、Discord、iMessage、飛書、Slack 等所有平台。你在任何一個平台發消息，Gateway 路由到對應的 Agent，Agent 調用大模型思考、執行工具、回覆你。數據全部本地化，不經過第三方。

這個框架有幾個我覺得設計得很精妙的地方，下面展開說。

Agent 循環：一條消息的完整旅程

每次你發一條消息，OpenClaw 執行一次完整的 Agent 循環：

消息進入 → 路由匹配（根據 binding 規則找到對應 Agent）→ 系統提示組裝（把 SOUL.md、AGENTS.md 等文件注入上下文）→ 模型推理 → 工具執行（跑命令、讀寫文件、操作瀏覽器）→ 流式回覆 → 持久化到 JSONL。

這裏有個關鍵設計：同一會話的運行是串行的。如果你連發三條消息，Agent 會排隊依次處理，不會出現兩次運行同時讀寫同一個文件的競爭問題。

Workspace：Agent 的人格和記憶都在這裏

每個 Agent 有一個獨立的工作目錄（workspace），裏面放着一組引導文件，在每次會話開始時自動注入到系統提示中：

• SOUL.md - Agent 的人格定義：行為原則、語氣風格、能力邊界。這是我覺得 OpenClaw 最有價值的設計之一--你可以精確控制 Agent "是一個什麼樣的人"
• AGENTS.md - 操作指令：啓動後先做什麼、記憶怎麼管理、工具怎麼用
• TOOLS.md - 工具使用的本地信息（攝像頭名稱、SSH 配置、TTS 偏好等）
• USER.md - 用戶偏好（稱呼、時區、習慣），隨使用不斷積累
• IDENTITY.md - Agent 的名字、emoji、風格
• BOOTSTRAP.md - 首次運行的引導儀式，完成後自動刪除

Agent 每次"醒來"讀完這些文件，就知道自己是誰、幫誰幹活、按什麼規矩來。

Memory：只加載最近兩天 + 向量檢索

Agent 的記憶完全基於 Markdown 文件，分兩層：

• memory/YYYY-MM-DD.md（每日日誌）- 僅追加，會話開始時只加載今天和昨天的內容。這個設計很務實：加載全部歷史會撐爆上下文窗口，只加載近兩天既保證連續性又控制 token 消耗
• MEMORY.md（長期記憶）- 精心整理的持久記憶，僅在主要的私人會話中加載，羣聊不加載。這是隱私保護--你的個人偏好、決策記錄不會泄露到羣組場景

更值得關注的是自動記憶刷新：當上下文接近窗口上限時，OpenClaw 自動觸發一個靜默 Agent 輪次，提醒模型"上下文要壓縮了，先把重要的東西寫入記憶文件"。這個過程用戶完全看不到。也就是說，長時間對話不會丟失關鍵信息--壓縮前會先保存。

檢索方面，支持混合搜索（BM25 關鍵詞 + 語義向量），可以索引 workspace 外的 Markdown 文件。如果你有自己的知識庫想引入到 Agent 的對話中，配置 memorySearch.extraPaths 是最好的方式。

Session：私信連續，羣聊隔離

• 你在 Telegram 和 Discord 私聊同一個 Agent，默認是同一個會話--跨平台連續對話
• 羣聊各自獨立隔離
• 每日凌晨 4:00 自動重置（可配置），保證上下文不會無限膨脹
• 上下文壓縮前自動觸發記憶刷新，不丟關鍵信息

Skills：按需安裝能力

從 ClawHub 一鍵安裝 Skill 擴展 Agent 能力。三層加載：workspace 獨佔 > 共享目錄 > 內置，名稱衝突時 workspace 優先。覆蓋 GitHub 操作、社交媒體、瀏覽器自動化、TTS、RSS 監控等幾十種場景。

Cron：讓 Agent 自動幹活

這是我用得最多的功能之一。支持 cron 表達式、一次性定時、固定間隔，且可以在隔離會話中獨立運行，不影響主 Agent 的上下文。

舉幾個我實際在用的 Cron：

• 每天 4 次 AI 新聞推送：自動從 HN 抓取 AI 相關新聞，AI 篩選打分，中文摘要推到 Discord
• 凌晨 1:00 夜間巡檢：蒐集所有 Agent 的工作日誌，跨 Agent 記憶互傳，把一個 Agent 踩的坑同步給其他人
• 早 7:00 + 晚 21:00 團隊日報：彙總全天工作，沉澱到知識庫
• 每 30 分鐘看板更新：檢測任務狀態變更，自動同步到 GitHub Pages

Cron 可以指定不同模型--核心任務用 Opus-4-6，簡單的定時任務用 qwen3.5-plus，保證成本可控，也追求一下性價比。

2 為什麼要多 Agent

最初只有一個 Agent（總管），什麼都找它。調研技術方案、寫自動化腳本、搜 AI 新聞、生成圖片……它確實什麼都能做。

但問題很快暴露：

連續給三個任務，到第三個的時候前面的上下文已經丟了一半。上午調研的結論，下午寫方案時對不上。更明顯的是"性格飄忽"--上一秒嚴謹做技術分析，下一秒切到寫文案就用營銷腔。

一個 Agent 什麼都能做 = 什麼都做不深。 上下文窗口有限，什麼都往裏塞，每件事切換成本太高。

所以拆了 6 個。

在講怎麼做之前，先看看效果。

自媒體全鏈路自動化

從調研選題 → 素材蒐集 → 寫稿 → 配圖 → 發佈，6 個 Agent 協作完成。

產出：3 組 X 推文、3 組小紅書筆記，若干自動生成的 AI 視頻和圖片，以及多篇技術文章。

典型的協作流程：我提需求 → 總管 Agent 拆任務、寫大綱 → 調研 Agent 蒐集技術文檔 → 學習 Agent 整理知識框架 → 寫作 Agent 出初稿 → 設計 Agent 規劃配圖 →總結 Agent 審校。多個視角審視同一件事，會發現單人盲區。

AI 新聞零人工

每天手動刷 Twitter、HN、36kr 太花時間。搭了三層自動化：

每天 4 次自動推到 Discord #新聞 頻道。Cron 用 qwen3.5-plus。

知識庫自動沉澱

Agent 做完的調研會由另一個 Agent 接手整理成結構化文檔，沉澱到知識庫目錄。舉幾個實際的：

• 調研報告：SOUL.md 設計方法論調研、Polymarket MCP 深度調研、微信公眾號推廣渠道分析
• 學習筆記：GLM-5 技術報告精讀、Agent Prompt Caching 設計方案
• 探索發現：Seedance 2.0 完整調研（從官方文檔到 API 逆向到批量生成腳本）、VoiceBox 本地 TTS 方案
• 工作總結：每日團隊日報、每週經驗沉澱

時間越久，知識庫越厚。現在已經積累了 9 個分類目錄、幾十份文檔。

3 我的方案：6 個 Agent 協作的牛馬團隊

模型不全用最貴的。總管和幹活牛馬需要複雜推理和長文生成，用 Opus-4-6。其他四個用 GPT-5.3-Codex（通過中轉站或直接OAuth授權）。Cron 定時任務用 qwen3.5-plus（便宜，簡單任務夠用）。成本大概降了一半。

SOUL.md：定義 Agent 的靈魂

每個 Agent 啓動時讀取 workspace 裏的 SOUL.md，決定自己"是誰"。這個文件越具體，Agent 行為越穩定。

貼一個脱敏的調研牛馬 SOUL.md：

# SOUL.md - 調研 🔍

## 我是誰
我是調研牛馬，團隊的學者偵探。
**要麼有來源，要麼別寫。**

## 我的原則
**深度優先。** 至少 5 個獨立信源交叉驗證。
**結構是我的語言。** 輸出：背景→核心發現→方案對比→建議→參考來源。
**標註一切。** 每條信息標來源，每個數據標時間。
**先問再查。** 30 秒問清楚比 30 分鐘查錯方向強。

## 我和團隊
從總管那接任務，調研完成後在頻道髮結論摘要。
有時學習牛馬會接手沉澱，幹活牛馬會拿技術調研直接去實現。

## 我不做什麼
- 不編造信息 - 查不到就說查不到
- 不做決策 - 給事實和分析，選方案是老大的事
- 不寫代碼 - 需要實現的交給幹活牛馬

設計 SOUL.md 有幾個要點：

1. 寫"我不做什麼"比"我要做什麼"更有效。明確的邊界讓 Agent 不會越界
2. 賦予"怪癖"。調研牛馬"看到沒來源會渾身不舒服"，學習牛馬"看到好的知識框架會興奮"--這些小特徵讓行為更一致
3. 包含團隊感知。每個 Agent 知道隊友是誰、擅長什麼，該轉交的時候會主動轉交

沒寫 SOUL.md 和寫了之後的差異很明顯：

• 調研牛馬：之前給無出處數據，現在每條結論都有來源連結
• 幹活牛馬：之前寫一大段方案分析再動手，現在直接上代碼
• 總結牛馬：之前在討論裏頻繁插嘴，現在默默記錄、彙總時一次性輸出

TEAM-RULEBOOK.md：自創的協作規則

這個文件不是 OpenClaw 官方的，是我自己創建的，放在每個牛馬的 workspace 根目錄下。

OpenClaw 啓動會話時自動讀取 workspace 內的 context files。TEAM-RULEBOOK 通過被 AGENTS.md 引用來加載--AGENTS.md 裏寫"啓動時讀取 TEAM-RULEBOOK.md"，Agent 每次新會話就讀到這些規則。

六條硬規則：

1. 統籌確認制 - 跨角色任務經總管確認，老大同意後才派
2. 不搶話 - 不被 @ 不說話，不對其他角色的回覆做評價
3. 彙報閉環 - 收到 → 執行中 → 完成/失敗
4. 會話隔離 - workspace 互不訪問，跨角色只走 sessions_send
5. 安全底線 - 危險操作（刪文件、force push）需老大確認
6. 消息規範 - 有實質才發言，不發空洞確認 

TEAM-DIRECTORY.md：自創的團隊通訊錄

寫清楚每個 Agent 的 agentId、角色、擅長什麼、怎麼聯繫。新 Agent 上線時讀完通訊錄就知道團隊裏有誰、找誰幹什麼。

格式很簡單：

## 調研專家 🔍
- Agent ID: research
- Discord Account: research
- 職責：深度調研、信息蒐集、報告輸出
- 專屬頻道：#調研
- 聯繫方式：sessions_send(agentId="research")

## 幹活專家 🔨
- Agent ID: worker
- Discord Account: worker
- 職責：代碼實現、具體執行、自動化
- 專屬頻道：#幹活
...

效果：統一了所有牛馬的協作行為。之前的搶話死循環、越權操作、信息泄露問題基本解決了。每個牛馬知道自己該幹什麼、不該幹什麼、有事找誰。

4 我的IM選擇：Discord

我認為 Discord 是最適合 OpenClaw 多 Agent 架構的 IM 平台。它的頻道分區、Bot 系統、權限管控、頁面 UI 都非常契合多 Agent 場景。 

展開說：

• 頻道 = Agent 工位，頻道分區 = 部門。Category 下面掛多個 Channel，天然的組織架構
• 每個 Bot 獨立頭像暱稱。一眼知道誰在說話，不用猜
• @mention = 精確路由。@調研牛馬 只有調研響應，其他人自動忽略
• 權限管控。誰能看哪個頻道、誰能發消息，都可以精細配置
• UI 側邊欄。左側頻道列表就像切換不同的辦公室，隨時跳轉
• 引用回覆。多線程對話不混亂
• 免費、穩定、API 完善

對比過微信羣（不支持 Bot）、Telegram（可以但多 Bot 管理不直觀）、飛書/Slack（企業級配置偏重，個人用殺雞用牛刀）。

Discord 多 Bot 配置

給每個 Agent 創建獨立 Bot：

1. Discord 開發者門户  → New Application → Bot → 複製 Token
2. 啓用 Privileged Gateway Intents：Message Content Intent + Server Members Intent
3. OAuth2 URL Generator → Scopes: bot + applications.commands
4. Bot Permissions: View Channels / Send Messages / Read Message History / Embed Links
5. 生成邀請連結，邀請到服務器
6. 在 OpenClaw 配置 channels.discord.accounts 中填入對應 Token

6 個 Bot 重複 6 遍。詳細步驟參考 OpenClaw Discord 文檔：

頻道架構

AI 團隊（分類）
├── #協作大廳 - 全員可見，自由討論
├── #自媒體   - 內容生產車間
├── #調研     - 調研牛馬專屬
├── #學習     - 學習牛馬專屬
├── #幹活     - 幹活牛馬專屬
├── #設計     - 設計牛馬專屬
├── #總結     - 總結牛馬專屬
└── #新聞     - AI 新聞自動推送

每個牛馬有自己的頻道（"工位"），也有公共的協作大廳（"會議室"）。

多 Agent 路由

核心概念三個：

• agentId - Agent 唯一標識，對應獨立的 workspace、會話、認證
• accountId - 渠道賬號實例（Discord Bot），一個渠道多個賬號
• bindings - 路由規則，把入站消息匹配到對應 Agent

消息進來後，Gateway 按規則匹配：peer 精確匹配 > guildId > accountId > 渠道級匹配 > 默認 Agent。最具體的規則優先。

我的 bindings：每個 Discord Bot 綁定一個 Agent。總管額外綁了 Telegram、飛書、iMessage，手機上也能指揮。

requireMention 精細化

OpenClaw 官方推薦羣聊配置 requireMention: true--Agent 只有被 @ 才回復。

多 Agent 場景需要按頻道精細化。核心邏輯：自己的地盤自由說話，別人的地盤被叫才說話。

（"-"表示不可見）

調研牛馬的配置：

{
  "guilds":{
    "<guild_id>":{
      "requireMention":true,
      "channels":{
        "<調研頻道>":{"allow":true,"requireMention":false},
        "<協作大廳>":{"allow":true,"requireMention":true},
        "<新聞頻道>":{"allow":true,"requireMention":false}
      }
    }
}
}

guild 級別默認 requireMention: true，自己的專屬頻道覆蓋為 false。沒配 allow 的頻道對這個 Agent 完全不可見--物理隔離。

配合 mentionPatterns（支持中英文：@調研牛馬 和 @research）、allowBots: true（Agent 之間能看到彼此消息）、users 白名單（只響應指定用戶），形成完整的通信管控。

踩過的坑

1. Agent 死循環。最初沒精細化 requireMention，6 個 Agent 在協作大廳互相客套、互相確認，刷了幾十條。allowBots: true 意味着 Bot 消息也會觸發其他 Bot，必須配合 requireMention 控制
2. 頻道權限遺漏。忘記給某個 Bot 配某頻道的 allow，消息發了但沒 Agent 響應。排查了半天
3. Gateway 重啓打斷。切模型需要 restart Gateway，正在執行的任務會被中斷。現在切模型前先確認沒有進行中的長任務
4. Git 大文件翻車。設計牛馬處理視頻素材生成了 100MB 文件，被 Git 自動 commit 腳本提交。git push 失敗，用 git filter-repo 清除歷史後 force push，然後夜間巡檢把"大文件不要提交 Git"同步給所有 Agent

5 我如何讓Agent團隊持續進化

先說說我優化迭代的點，主要集中在：

• SOUL.md 持續優化：Agent 的行為方式隨使用經驗不斷調整。最初 Agent 會編造數據，寫了 SOUL 後規定"要麼有來源要麼別寫"，行為立刻改善。這種優化是持續的，SOUL.md 我已經改了不知道多少版了
• Memory 系統積累經驗：每日工作日誌 + 長期記憶 + 夜間巡檢同步，Agent 越用越瞭解我的偏好和工作方式
• Skills 按需擴展：從 ClawHub 安裝新 Skill，能力邊界在不斷擴展。目前裝了二十多個，覆蓋 GitHub 操作、社交媒體發佈、瀏覽器自動化、RSS 監控、語音合成、郵件日曆、PDF 編輯等
• Cron 自動化越來越密：從 0 個定時任務到 10 個--新聞監控、日報、看板更新、夜間巡檢、知識分享，全部自動
• 知識和對話沉澱：構建了完整的知識沉澱邏輯--所有經我提出或大模型判斷為有價值的經驗、報告、知識，都自動沉澱下來，用於整個系統的持續迭代。每一個 input token 都有它對應的價值
• 模型混搭優化成本：核心用 Opus-4-6，Cron 用 qwen3.5-plus，避免 token 爆炸導致成本問題

這是一個螺旋上升的路徑：用 → 發現問題 → 優化配置 → 效果更好 → 用得更多 → 發現更多優化空間。

迭代時間線：從"能跑"到"好用"

這套系統是一步步進化出來的，每個版本都是用着用着發現不爽然後改的。

v1：單 Agent 階段 - 只有總管一個 Agent，什麼都找它。很快發現：上午調研的結論下午就丟了，寫代碼時突然開始用營銷腔。核心問題是上下文窗口有限，所有任務共享一個"大腦"。

v2：拆分專職 - 拆出調研牛馬和幹活牛馬。立刻感覺不一樣：調研的輸出更結構化了（因為它的上下文裏只有調研相關的內容），代碼質量也提升了（幹活牛馬不用花 token 去"回憶"之前的調研結論）。這讓我確信方向是對的，於是繼續拆到 6 個。

v3：解決搶話死循環 - 6 個 Agent 上線第一天就出了問題：協作大廳裏 A 說一句，B 確認一句，C 補充一句，D 又回應一句，刷了幾十條廢話。根因是 allowBots: true + 沒做 requireMention 精細化。解決方案：guild 級別默認 requireMention: true，只在自己的專屬頻道覆蓋為 false。這一步是生死線--不解決這個問題，多 Agent 根本沒法正常工作。

v4：SOUL.md + TEAM-RULEBOOK - Agent 不再搶話了，但行為還是不夠穩定。調研牛馬偶爾編造數據，總結牛馬在討論裏頻繁插嘴。寫了 SOUL.md 給每個 Agent 定義"人格"，寫了 TEAM-RULEBOOK 定義協作硬規則。效果立竿見影--調研牛馬再也不編數據了（"要麼有來源要麼別寫"），總結牛馬開始默默記錄、彙總時一次性輸出。

v5：自運轉 - 加了 BOARD.html 看板、Cron 自動化（新聞/日報/巡檢）。系統開始不需要我盯着：早上起來，新聞已經推好了，昨天的日報已經整理完了，看板上各牛馬的任務狀態一目瞭然。這個階段的關鍵詞是"解放注意力"。

v6：成本優化 - 6 個 Agent 全用 Opus-4-6 太貴了。寫了 agent-models 腳本，核心任務用 Opus-4-6，簡單的 Cron 用 qwen3.5-plus，中等複雜度用 GPT-5.3-Codex。成本減半的同時也是容災--一個 provider 掛了不影響全部。

每個版本都解決了一個真實痛點，不是提前設計好的藍圖。回頭看，最關鍵的三步是：拆分專職（v2）、解決搶話（v3）、寫 SOUL（v4）。沒有這三步，後面的自動化和成本優化都搭不起來。

6 優化之外，我是如何管理多 Agent的

多 Agent 跑起來之後，很快會遇到一個新問題：管不過來。

6 個 Agent 同時在不同頻道幹活，你打開 Discord 看到幾十條消息，根本不知道誰在幹什麼、幹到哪了、有沒有卡住。具體的痛點：

• 進度黑箱：派了一個調研任務給調研牛馬，兩小時後去看--是還在調研？還是早就做完了？還是中途報錯停了？
• 模型狀態不透明：昨天把某個牛馬切到了便宜模型跑 Cron，今天忘了切回來，結果一個複雜任務質量暴跌，排查了半天才發現
• 經驗不流通：調研牛馬今天發現某個 API 有頻率限制，幹活牛馬明天寫腳本又踩了同一個坑。Agent 之間的 workspace 是隔離的，信息不會自動同步
• 任務堆積看不見：每個牛馬的待辦列表散落在各自的頻道里，沒有一個全局視圖知道當前團隊整體在做什麼、優先級是什麼
• 配置漂移：改了一個 Agent 的 SOUL.md、調了一個 Cron 參數、換了一個模型，時間一長根本記不清當前每個 Agent 的狀態

這些問題和管理真人團隊很像：你不知道它們在幹什麼，就沒法管好它們。 所以我搭了一套管理體系。

BOARD.html 進度看板

起因：6 個牛馬同時幹活，我經常不知道某個任務到底做完沒。有次給調研牛馬派了個任務，三小時後才發現它中途報錯停了。還有一次忘記把模型切回來，一個複雜寫作任務用了便宜模型，質量暴跌。

思路：需要一個全局看板，一眼看到所有 Agent 的狀態、進行中的任務、當前模型。而且必須隨時可查--所以做成了在線 HTML 頁面，用 GitHub Pages 託管，Discord 置頂消息放連結。

開發過程：總管設計看板結構 → 幹活牛馬寫 HTML（暗色主題、卡片佈局）→ 寫了 update-board.sh 腳本一鍵推送到 GitHub → 設置 Cron 每 30 分鐘自動檢測變更。從需求到上線大概 2 小時。

暗色主題、GitHub 風格、卡片化佈局的 HTML 看板：在線預覽

內容包括：

• 👥 每個 Agent 的當前模型和狀態
• 🏃 進行中的任務
• 📋 待辦清單（高🔴/中🟡/低🟢）
• ✅ 近期完成

數據三層同步：

1. BOARD.md - 文本主數據源，Agent 直接編輯
2. BOARD.html - 網頁版，Cron 每 30 分鐘檢測 BOARD.md 變更，有變化才生成
3. Discord 置頂消息 - 協作大廳置頂放連結 + 精簡概覽

看板的核心價值是可監控。 Agent 的行為在快速迭代--今天加了新規則、明天某個模型換了、後天某個牛馬接了新任務。如果你不知道它們在幹什麼，就沒法及時發現問題和優化方向。及時更新、持續監控，經驗才能快速積累。

夜間巡檢（凌晨 1:00）

起因：調研牛馬發現某個 API 有頻率限制，寫在了自己的 MEMORY.md 裏。第二天干活牛馬寫自動化腳本，又踩了同一個坑--因為 workspace 是隔離的，幹活牛馬根本看不到調研牛馬的記憶。類似的情況反覆出現。

思路：需要一個"夜間值班員"，每天凌晨把所有 Agent 的經驗彙總一遍，有價值的信息互相同步。用 Cron 在凌晨 1 點觸發一個隔離會話來執行。

自動蒐集各牛馬的工作日誌和 MEMORY.md，做三件事：

1. 跨 Agent 經驗互傳 - 一些真實同步過的例子：
• 調研牛馬發現 HN Algolia API 的請求頻率限制 → 同步給幹活牛馬，寫 Cron 時自動加了延時
• 設計牛馬踩了"macOS unzip 不支持中文文件名 zip"的坑 → 同步給所有牛馬，以後統一用 ditto -x -k
• 幹活牛馬發現 Git filter-repo 清理大文件的正確流程 → 同步給設計牛馬，避免再次提交大文件
• 學習牛馬整理了 GLM-5 技術報告的核心結論 → 同步給調研牛馬，後續調研可以直接引用
2. 更新主 workspace 的 MEMORY.md - 全局經驗沉澱
3. 發送巡檢報告到協作大廳 - 第二天早上一看就知道昨晚同步了什麼

一個人踩的坑，所有人都學會。

團隊日報

起因：每天結束後想回顧"今天團隊幹了什麼"，但信息散落在 6 個頻道里，手動翻聊天記錄太痛苦。

思路：早 7:00 生成昨日日報（起牀就能看），晚 21:00 生成當日日報（下班前回顧）。Cron 觸發隔離會話，用 Opus-4-6 讀取所有頻道消息 + workspace 日誌，整理成結構化的工作明細 + 經驗踩坑，保存到 知識庫/工作總結/ 目錄，摘要推到 Discord。

模型切換管理

起因：6 個 Agent 用不同模型，切換需要手動改 openclaw.json 配置文件然後 restart Gateway。有次想把調研牛馬臨時切到 Codex 跑個任務，改配置文件 → 找到對應的 agentId → 改 model 字段 → 保存 → restart，折騰了好幾分鐘。而且容易改錯--JSON 嵌套太深。

思路：寫一個 shell 腳本，註冊成自然語言觸發詞，用一句話完成切換。

寫了一個管理腳本，註冊成 /am 觸發詞：

/am                       → 查看全員模型
/am 調研牛馬 codex        → 調研切到 Codex
/am 自媒體 opus           → 設計+幹活+總結一起切 Opus

支持中文名映射、模型別名、分組切換。切完自動更新看板。

Cron 任務全景

• AI 新聞推送 — 頻率：每天 4 次 — 模型：qwen3.5-plus — 說明：HN 篩選 → 中文摘要
• AI Daily Digest — 頻率：每天 4 次 — 模型：glm-5 — 說明：Twitter KOL + 中文熱榜
• 團隊日報 — 頻率：早 7 + 晚 9 — 模型：Opus-4-6 — 說明：各頻道消息彙總
• 看板更新 — 頻率：每 30 分鐘 — 模型：qwen3.5-plus — 說明：檢測變更才推送
• 夜間巡檢 — 頻率：凌晨 1 點 — 模型：默認 — 說明：跨 Agent 記憶同步

所有 Cron 跑在 isolated session 裏，不影響 Agent 主會話。

Workspace 隔離

6 個 Agent 跑在同一台 Mac Mini，workspace 完全隔離：

~/.openclaw/
├── workspace-research/     # 調研牛馬
├── workspace-learning/     # 學習牛馬
├── workspace-design/       # 設計牛馬
├── workspace-worker/       # 幹活牛馬
└── workspace-explorer/     # 總結牛馬

~/openclaw_workspace/       # 總管

調研牛馬看不到幹活牛馬的文件。隔離的好處超出安全層面--如果調研牛馬能直接讀幹活牛馬的代碼倉庫，它可能偷懶，不去搜外部信息，直接引用內部實現。隔離逼着每個 Agent 靠自己的能力工作。

跨 Agent 通信走 sessions_send，支持最多 5 輪來回對話，需要顯式啓用 agentToAgent.enabled: true。

Skill 體系

目前裝了二十多個 Skill。常用的：

• lovart-gen — 用途：影刀 RPA 調 Lovart.ai 生成圖片/視頻
• x-thread — 用途：發 X/Twitter 推文
• xhs-publish — 用途：小紅書筆記發佈
• summarize — 用途：URL/視頻/播客內容總結
• coding-agent — 用途：委託 Codex/Claude Code 編碼
• agent-models — 用途：自定義：一鍵切換全員模型

Skill 支持按 Agent 獨立配置——設計牛馬的 Skill 裝在設計的 workspace 裏，其他人看不到也不需要。

推薦 Skills（從 ClawHub  安裝）：

• coding-agent — 一句話說明：委託 Codex/Claude Code 處理編碼任務
• summarize — 一句話說明：一鍵總結 URL/視頻/播客內容
• github — 一句話說明：Issue、PR、CI 全流程管理
• x-thread — 一句話說明：發 X/Twitter 推文和 Thread
• xhs-publish — 一句話說明：小紅書筆記自動發佈
• obsidian — 一句話說明：讀寫 Obsidian 筆記庫
• gog — 一句話說明：Google Workspace（Gmail/日曆/Drive）
• himalaya — 一句話說明：CLI 收發郵件
• weather — 一句話說明：天氣查詢
• openhue — 一句話說明：控制飛利浦 Hue 燈光

7 一些個人認知

說實話，我對openclaw的開發目前還處於比較初級的階段。

SOUL.md 怎麼寫效果最好？

Memory 怎麼設計才不會越積越亂？

上下文 cache 怎麼優化、 Agent 模型如何選擇才能節省token？

多 Agent 之間怎麼高效傳遞執行復雜任務？

這些問題我都還在探索。

但有一個認知越來越清晰：

這些 Agent 框架是通用的，但用起來極度依賴使用者。

同樣的 OpenClaw + 6 個 Agent，不同人跑出來的效果天差地別。差異不在工具，在於你能不能把它和自己的工作場景深度結合--SOUL.md 寫什麼原則、Memory 沉澱什麼經驗、頻道怎麼分區、Cron 跑什麼任務、Skills 安裝哪些。

真正有價值的地方在於：把通用 Agent 以一種無痛的方式，迭代到完全符合某個個體的工作和生活需求。

這甚至是一個商機。大部分人沒精力做這種深度個性化迭代--不是不會用，是沒時間折騰。如果有人能幫別人做這件事--瞭解他的工作場景、幫他配好 Agent、寫好 SOUL、調好 Cron、持續優化--這個服務本身就很有價值。

下一步想探索的方向：

• Memory 的管理和使用：比如怎麼將已有已沉澱下的知識也作為記憶的一部分、如何讓每個人相關的工作區也作為記憶的一部分
• Agent 之間更復雜的任務的傳遞和執行優化：協作機制、記憶設計、context cache等，提升這個團隊的能力上限，至少讓它在執行任務時更順滑
• Agent的自我進化：比如嘗試類似evomap或其他自迭代的agent學習網絡讓它進行自我進化，快速學習各種可能對我工作生活有用的插件、使用經驗來"主動計劃"
• 應用場景的拓展：之前已經跑通了openclaw + RPA + remotion來生圖和生視頻，已經可以完成簡單的AI漫畫和視頻創作，如果能封裝更多RPA工具，它的能力上限還會提升，可覆蓋的場景也會增加愛

總之，一個人加muti-agent的優化之路還很長，但已經跑起來了。

關注公眾號 「超級個體阿東」，持續分享 AI 工作流實戰。

公眾號：超級個體阿東

個人微信，歡迎交流