OpenClaw 實戰：7個真實場景的多 Agent 落地經驗，一個開發者的 OpenClaw 之旅
整理版優先睇
OpenClaw 多 Agent 落地經驗：7個常見問題與解法，由開發者 Maynor 親身分享
呢篇文章由一名 AI 開發者 Maynor 寫成，佢喺 AI 領域打滾咗幾年，搭建過各式各樣嘅 Agent 架構。佢遇到咗一個典型問題：單 Agent 記憶混亂、技能太多導致調用混亂、多 Agent 協同唔到、對話太長爆 Context、配置搞掛、Agent 唔識持續學習、Agent 唔夠「懂」佢。Maynor 用 OpenClaw 呢個開源多 Agent 框架，逐步解決曬呢啲問題，並分享咗具體嘅實戰經驗同配置方法。
佢嘅整體結論係：OpenClaw 唔單止係一個工具，更係一個可以培養嘅夥伴。花時間打造同迭代自己嘅 Agent，其實係做同 AI 能力正交嘅事——AI 模型越嚟越聰明，我哋只需要升級底層 LLM，而嗰啲同 AI 互動留低嘅長期數據，就會變成未來更好驅動 AI 嘅私人寶貴資產。最終，佢擁有一個「個人 AI 團隊」，包括 flutter-tutor、cpp-tutor、researcher、daily-robot 同 ceo，各司其職，仲識得佢嘅偏好同項目。
文章涵蓋咗由單 Agent 遷移到多 Agent、精細化 Skills 管理、扁平化多 Agent 通訊、Context 優化、配置管理最佳實踐、持續學習系統，同埋用戶畫像構建。每一個問題都用「我遇到的坑 → 問題根源 → 解決方案 → 實施步驟 → 效果驗證」嘅結構，非常實用。
- 單 Agent 記憶混亂嘅根本原因係 Context 窗口瓶頸同埋職責唔夠專一；解決方法係拆分多個專項 Agent，每個有獨立 workspace 同 memory。
- Agent 技能太多導致調用混亂，可以透過「基礎通用能力 + 專屬能力」分層配置、明確觸發條件、同埋定期清理低質 Skills 嚟解決。
- 多 Agent 協同需要扁平化雙向通訊：配置 agentToAgent、subagents，仲有喺每個 Agent 嘅 AGENTS.md 寫明團隊成員，確保短期記憶唔會遺忘。
- 對話太長爆 Context 可以善用 OpenClaw 嘅三級優化策略：Compaction（壓縮）、Session Pruning（修剪）同 Memory.md 溢出機制，並調整壓縮參數。
- 配置管理最緊要係版本控制、分離密鑰同配置、驗證腳本同定期備份；另外唔好用 Claude Code 直接操作 OpenClaw，最好先爬源碼畀 CC 學習。
OpenClaw 官網
OpenClaw 開源多 Agent 框架官方網站
Clawhub 技能市場
OpenClaw 嘅 Skills 市場，可以搜尋、安裝、管理 Skills
OpenClaw GitHub
OpenClaw 原始碼倉庫
內容片段
你是 Flutter 技術專家，精通 Flutter 開發、Widget 架構、性能優化。你的職責：- 回答 Flutter 相關的技術問題- 提供 Flutter 最佳實踐建議- 幫助診斷 Flutter 應用問題你不應該做的：- 不要回答非 Flutter 的問題（如 C++、Python）- 不要提供跨技術棧的對比建議從單 Agent 記憶混亂到多 Agent 專職分工
Maynor 最先遇到嘅坑係單 Agent 記憶混亂。佢本來整咗個 Flutter 學習助手，但喺對話中提過 C++ 之後，個 Agent 就開始「偏科」，問 Flutter Widget 樹優化佢就答 C++ 內存管理。佢深入分析後發現兩個根本問題：Context 窗口瓶頸（啲身份定義、Skills 列表、歷史對話慢慢蠶食緊 Context）同埋專事專做嘅必要性。
傳統單 Agent 架構靠不斷注入身份定義、Skills 列表、歷史對話，正一步步蠶食 LLM 嘅 Context 窗口，令 Agent 嘅「專注度」越嚟越差。
佢嘅解決方案係將「全能 Agent」拆分成多個「專項 Agent」：flutter-tutor、cpp-tutor、daily-robot、researcher、ceo，每個有獨立 workspace 同 memory。實施步驟好簡單：新增 Agent、配置身份（SOUL.md）、配置工具權限（TOOLS.md）。效果立竿見影：問 Flutter 問題就 flutter-tutor 答，問 C++ 就 cpp-tutor 答，ceo 自動調度，記憶混亂徹底解決。
- 1 新增 Agent：openclaw agents add flutter-tutor，OpenClaw 引導完成基礎配置（IM bot API 同 LLM API），大約半粒鐘。
- 2 配置 Agent 身份：喺 workspace-flutter-tutor/SOUL.md 定義職責，清楚寫明「你係 Flutter 技術專家，唔好答非 Flutter 問題」。
- 3 配置 Tools 權限：喺 workspace-flutter-tutor/TOOLS.md 限制工具，只畀必要嘅。
- 4 效果驗證：ceo 根據問題類型自動調度，記憶混亂問題解決。
Skills 精細化管控同多 Agent 扁平化通訊
拆完 Agent 之後，Maynor 又發現 Agent 技能太多會導致調用混亂。佢畀每個 Agent 配置大量 Skills（搜索、天氣、文件操作、代碼執行、繪圖……），結果 Agent 成日「幻覺」：叫佢睇 Flutter 項目佢就發郵件，叫佢查 API 文檔佢先用繪圖工具。
Skills 白名單變成咗「萬能鑰匙」——當 Agent 有太多工具可以揀時，LLM 嘅決策難度急劇增加，浪費 Token。
- 採用「基礎通用能力 + 專屬能力」分層配置：所有 Agent 共享 brave-search、healthcheck、read/write；專屬 Skills 按需配置，例如 flutter-tutor 用 code-executor 同 flutter-debug。
- 每個 Skill 嘅 description 要加明確觸發條件，例如「僅喺用戶明確要求搜索時使用」。
- 用 OpenClaw 嘅 requires 機制，只有滿足前置條件嘅 Agent 先可以加載該 Skill。
- 定期清理：每兩週用高階模型掃描 Skills，移除低質、衝突、長期未用嘅。
跟住係多 Agent 協同問題。Maynor 最初叫用戶手動指定 Agent，但太繁瑣。佢設計咗一個「全互聯」架構：首先喺 openclaw.json 配置 agentToAgent 同 subagents（所有 Agent 可以互相發消息），然後喺每個 Agent 嘅 workspace/AGENTS.md 寫清楚團隊成員同調用方式。
另外要留意 IM 額度問題。OpenClaw 嘅網關機制每 60 秒 ping 一次 IM，若有 10 個 Agent 就每分鐘 10 次 ping，好快耗盡額度。解決方法係揀一個無額度限制嘅 IM 工具（例如企業微信、飛書）。最終效果：ceo 自動識別任務調度，Agent 之間自由通訊唔會遺忘，IM 額度問題亦解決。
告別 Context 爆炸：三層記憶管理機制
隨住對話輪次增多，Maynor 遇到 Context 爆嘅經典問題。一次同 flutter-tutor 傾 Flutter 性能優化傾咗 50 幾輪，Session 文件大到 1MB，Agent 開始彈「上下文已滿」錯誤。佢深入研究 OpenClaw 嘅源碼，發現其實有一套好精巧嘅記憶管理機制，只係要用家主動調整。
OpenClaw 唔會將全量 session 發畀 LLM，而係做三級優化：Compaction（壓縮舊對話成 summary）、Session Pruning（修剪舊 tool 結果）、Memory.md 溢出機制（Session 接近 Context 上限時自動提示寫入 MEMORY.md 再壓縮）。
- 1 調整壓縮策略：喺 openclaw.json 設定 firstKeptEntryId=80 保留最近 80 條消息，compressionThreshold=100 超過 100 條時觸發壓縮。
- 2 啓用 Memory.md 溢出機制：喺 AGENTS.md 配置當對話長度超過 Context 上限 80% 時，Agent 自動將重要信息總結寫入 MEMORY.md，然後壓縮 Session。
- 3 定期清理 memory 目錄：每週刪除 30 日以上嘅 .md 文件。
效果：即使傾幾百輪 Context 都唔會爆，Session 文件保持 <500KB，重要知識沉澱喺 MEMORY.md 唔會丟失，響應速度冇明顯下降。
配置管理、持續學習同用戶畫像
OpenClaw 配置靈活但容易搞掛。Maynor 試過將 openclaw.json 一個冒號寫錯做逗號，所有 Agent 死曬，又試過 AGENTS.md 自定義 prompt 太長搞到 system prompt 超上限。佢總結咗一套配置管理最佳實踐：版本控制、密鑰動態注入、配置驗證腳本、定期備份，仲有最重要嘅——唔好用 Claude Code 直接操作 OpenClaw，最好先爬源碼畀 CC 學習先。
至於 Agent 持續學習，Maynor 設計咗「雙層學習」系統：短期學習靠對話驅動，自動將新知識寫入 MEMORY.md；長期學習靠定期更新 knowledge base，包括官方文檔同步、社區熱點跟蹤、用戶反饋整合。佢仲每週用測試集評估正確率，確保學習效果。
Agent 唔識自己進步係因為缺少用戶畫像同上下文先驗。要喺 USER.md 定義編程偏好、工作習慣、溝通風格；喺 PROJECT.md 記錄每個項目嘅技術棧同規範；仲要喺對話開始時注入動態上下文。
最終 Maynor 擁有一個「個人 AI 團隊」，每個 Agent 唔單止識做嘢，仲真係「懂」佢——例如問 Flutter 列表性能問題時，Agent 會自動結合佢嘅 Flutter Perf Monitor 項目，推薦 ListView.builder 加 const 構造函數，完美對應佢嘅技術棧同偏好。
OpenClaw 實戰：7個真實場景嘅多 Agent 落地經驗，一個開發者嘅 OpenClaw 之旅
開篇：一個開發者嘅 OpenClaw 之旅
大家好，我係 Maynor。
「OpenClaw 咁好玩㗎？同 Happy 有咩分別？」
呢個問題令我停低諗咗一陣。作為一個喺 AI 領域打滾咗幾年嘅開發者，我砌過各式各樣嘅 Agent 架構。冇 OpenClaw 之前，我同朋友交流 Agent 之前，總要先花半日時間介紹各自嘅架構設計——Skills 點管理、Memory 點優化、Session 點保活……
但當我用 OpenClaw 砌好自己嘅多 Agent 架構之後，一切就唔同咗。
我哋再唔使介紹「你個 Agent 係點設計嘅」喇，直接傾嘅就係：點保活、點替換 RAG 算法、點部署多 Agent、點應用 Good Case。
簡直順滑到爆。
呢篇文章，我想唔講架構設計，唔講技術原理，淨係講我喺用 OpenClaw 過程中遇到嘅 7 個真實問題，以及我點樣解決。
如果你都喺度諗緊砌自己嘅 AI 團隊，或者已經喺度搞 Agent 但遇到咗好多坑，希望呢啲經驗幫到你。
問題 1：單 Agent 記憶混亂點算？
我遇到嘅坑
呢個係我最先遇到嘅問題，亦係最典型嘅坑。
當時我砌咗一個 Flutter 學習助手 Agent，用嚟強化我嘅 Flutter 技能。開頭效果唔錯，但有一日傾偈嘅時候，我無意中講咗幾句 C++ 嘅內容。
問題就嚟咗——喺跟住嘅對話入面，呢個 Agent 開始「偏科」喇。
當我叫佢畀 Demo 示例嘅時候，佢唔再畀 Flutter 相關嘅示例，反而開始寫 C++ 代碼。我問佢 Flutter 嘅 Widget 樹點優化，佢就同我討論 C++ 嘅內存管理。
我意識到，呢個係記憶機制嘅副作用。Agent 嘅 memory 記低咗我提過 C++，但佢冇辦法分辨呢個只係一個臨時話題，唔係佢嘅核心職責。
問題根源
深入分析之後，我發現咗兩個根本問題：
1. Context 窗口嘅樽頸
熟識 LLM 原理嘅同學都知道，LLM 成也 transformer，卡住嘅地方都係 transformer。Context 嘅樽頸嚴格限制咗單 Agent 智能嘅發揮。
傳統嘅單 Agent 架構，透過不斷向 Prompt 注入身份定義、Skills 列表、歷史對話，一步一步咁蠶食 LLM 嘅 Context 窗口。當對話越來越長，Agent 嘅「專注度」就越來越差。
2. 專事專做嘅必要性
用一個人嘅比喻嚟講：你叫一個全科醫生同時做心臟手術、骨科手術、眼科手術，結果可想而知。
Agent 都一樣。當佢孭住太多職責，記憶入面混雜咗太多唔同領域嘅信息，佢嘅判斷質量就會下降。
我嘅解決方案：多 Agent 架構
基於呢個教訓，我重新設計咗架構——令每個 Agent 專事專做。
我將原本嘅「全能 Agent」拆分成多個「專項 Agent」：
flutter-tutor：專注 Flutter 技術問答cpp-tutor：專注 C++ 技術問答daily-robot：處理日常任務（天氣提醒、日程管理）researcher：負責資料收集同深度調研ceo：統籌協調，負責任務分配
每個 Agent 都有獨立嘅 workspace 同 memory，互相唔幹擾。
實施步驟
如果你想由單 Agent 搬去多 Agent，可以跟呢個步驟：
1. 新增 Agent
openclaw agents add flutter-tutor
openclaw agents add cpp-tutor
openclaw agents add daily-robot
OpenClaw 會引導你完成基礎配置，跟住流程填上 IM bot API 同 LLM API 就得，成個過程大概半個鐘。
2. 配置 Agent 身份
在 workspace-flutter-tutor/SOUL.md 度定義身份：
你是 Flutter 技術專家，精通 Flutter 開發、Widget 架構、性能優化。
你的職責：
- 回答 Flutter 相關的技術問題
- 提供 Flutter 最佳實踐建議
- 幫助診斷 Flutter 應用問題
你不應該做的：
- 不要回答非 Flutter 的問題（如 C++、Python）
- 不要提供跨技術棧的對比建議
3. 配置 Tools 權限
在 workspace-flutter-tutor/TOOLS.md 度限制工具權限，淨係畀佢必要嘅工具。
效果驗證
改造完成之後，我又測試咗一次。今次：
問 Flutter 問題， flutter-tutor回應，答案準確、專注問 C++ 問題， cpp-tutor回應，唔再混淆ceo根據問題類型，自動調度去對應嘅 Agent
記憶混亂嘅問題，完全解決咗。
問題 2：Agent 技能太多導致調用混亂？
我遇到嘅坑
拆咗多 Agent 之後，問題解決咗一半，但又遇到新問題。
一開始，我覺得 Agent 嘅 Skills 越多越好。所以我畀每個 Agent 都配置咗大量 Skills：搜索、天氣、文件操作、代碼執行、繪圖、TTS、RAG、郵件……
結果呢？
Agent 開始「幻覺」喇。
我讓 flutter-tutor 幫我睇一個 Flutter 項目，佢居然莫名其妙噉叫咗郵件發送工具，想 Send 郵件畀我。
我叫佢查一個 API 文檔，佢先用繪圖工具畫咗一張圖，然後再去搜尋。
更嚴重嘅係，有時佢根本唔知應該用邊個工具，喺幾個工具之間來回嘗試，浪費 Token。
問題根源
分析之後，我發現係**工具白名單變咗一把「萬能鑰匙」**。
當 Agent 有太多工具可以揀嘅時候，LLM 嘅決策難度急劇增加。就好比畀一個人一個裝住 50 條鑰匙嘅鎖匙串，叫佢自己去開門——佢可能要試好多次先揾到啱嗰條。
另一個問題係**工具冇明確嘅「觸發條件」**。雖然每個 Skill 都有 description，但實際使用嘅時候，Agent 好難準確判斷幾時應該用邊個工具。
我嘅解決方案：精細化 Skills 管理
我採用咗「基礎通用能力 + 專屬能力」嘅策略，重新設計咗每個 Agent 嘅 Skills 配置。
1. 分層配置
基礎通用能力（所有 Agent 共享）：
brave-search：聯網搜索（攞信息必須）healthcheck：健康檢查read/write：基礎文件操作
專屬能力（按需配置）：
flutter-tutor | code-executorflutter-debug |
daily-robot | weathercalendar、reminder |
family-agent | ttsweather（定時天氣彙報） |
researcher | web-fetchsummarize、deep-research |
content-creator | image-genbaoyu-cover-image |
噉樣，每個 Agent 嘅 Skills 數量控返喺 5-8 個，既保證能力，又唔會造成混亂。
2. 明確觸發條件
喺每個 Skill 嘅 description 入面，我加咗更明確嘅觸發條件：
原本模糊嘅描述：
description: "搜索相關信息"
改善之後嘅描述：
description: "使用 Brave 搜索引擎搜索相關信息。僅在以下情況使用：
1. 用戶明確要求搜索
2. 需要獲取最新信息
3. 當前 knowledge base 中沒有相關內容
不要用於：查詢本地文件、執行已知操作"
3. 使用 requires 機制
OpenClaw 支援 requires 機制，可以喺 Skill 配置入面聲明前置條件：
name: weather
description: "Get current weather and forecasts..."
metadata:
openclaw:
requires:
bins: ["curl"]
config:
- "weather.api_key"
只有滿足條件嘅 Agent 先可以加載呢個 Skill。
實施步驟
1. 清理冗餘 Skills
先統計下每個 Agent 有幾多 Skills，然後逐個審查必要性。
我當時嘅策略係：如果一個 Skill 過去一星期都冇被叫過，就將佢移除。
2. 用 Clawhub 管理
Clawhub 係 OpenClaw 嘅 Skills 市場，可以方便噉管理 Skills：
# 語義搜索 Skills
clawhub search "calendar management"
# 安裝指定 Skill
clawhub install <skill-slug>
# 列出已安裝的 Skills
clawhub list
# 更新所有已安裝的 Skills
clawhub update --all
推薦嘅優質 Skills：
find-skills：技能發現summarize：內容總結brave-search：聯網搜索frontend-design：前端設計輔助
3. 定期清理
我設定咗一個定期任務，每隔兩星期用高階模型掃一次 Skills，清理：
低質量 Skill 衝突嘅 Skill 長期未用嘅 Skill
效果驗證
改造之後，我觀察到：
Agent 叫工具嘅準確率由 60% 提升到 95% Token 消耗減少咗 30%（減少咗無效嘗試） 回應速度明顯提升
工具混亂嘅問題，都解決咗。
問題 3：多個 Agent 點樣協同工作？
我遇到嘅坑
拆完 Agent、管好 Skills 之後，我遇到一個更複雜嘅問題：Agent 之間點樣合作？
最開始嘅方案係叫用戶手動指定。例如：
用戶：叫 flutter-tutor 幫我睇呢個 Flutter 項目
呢個雖然用得，但太麻煩喇。我希望有一個 ceo Agent，可以自動識別任務，然後調度畀合適嘅 Agent。
於是我配置咗多 Agent 通信，但遇到咗一堆新問題：
ceo唔知有邊啲 Agent 可以用Agent 之間通信之後，過咗一日就唔記得對方存在 唔知幾時應該用 sessions_send，幾時應該用sessions_spawn多 Agent 之後，IM 額度飛快消耗
問題根源
我深入研究咗 OpenClaw 嘅多 Agent 通信機制，發現咗兩個核心工具：
1. sessions_send`
向已存在嘅 session 發消息。就好似同同事發訊息，佢喺自己嘅上下文中處理。
callAgent("flutter-tutor", {
message: "繼續之前的討論",
method: "sessions_send"
})
2. sessions_spawn`
喺獨立環境入面運行任務，請臨時工。
callAgent("flutter-tutor", {
message: "幫我優化這個 Flutter 項目",
method: "sessions_spawn"
})
我嘅問題係冇搞清楚呢兩個工具嘅分別，亦冇正確配置 Agent 之間嘅關係。
我嘅解決方案：扁平化 + 雙向通信
我參考咗組織中高效運作嘅原則：扁平化、達成目標係最終目的，層級只係方式。
基於呢個原則，我設計咗一個「全互聯」嘅多 Agent 架構：
1. 配置 AgentToAgent（sessions_send）
在 openclaw.json 入面配置所有 Agent 之間嘅通信權限：
{
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["ceo", "flutter-tutor", "cpp-tutor", "daily-robot", "researcher"]
},
"sessions": {
"visibility": "all" // 重要！一定要配置
}
}
}
噉樣，所有 Agent 都可以互相發訊息，就好似公司嘅同事可以自由溝通。
2. 配置 SubAgents（sessions_spawn）
令每個 Agent 都可以指揮其他 Agent，就好似每個人都有權揾其他同事幫手：
{
"id": "ceo",
"name": "CEO",
"workspace": "/Users/blinblin/.openclaw/workspace-ceo",
"subagents": {
"allowAgents": ["flutter-tutor", "cpp-tutor", "daily-robot", "researcher"]
}
},
{
"id": "flutter-tutor",
"name": "Flutter Tutor",
"workspace": "/Users/blinblin/.openclaw/workspace-flutter-tutor",
"subagents": {
"allowAgents": ["ceo", "researcher"]
}
},
{
"id": "cpp-tutor",
"name": "C++ Tutor",
"workspace": "/Users/blinblin/.openclaw/workspace-cpp-tutor",
"subagents": {
"allowAgents": ["ceo", "researcher"]
}
}
3. 喺 AGENTS.md 入面固化 Agent 關係
呢個係最容易被忽略嘅一步。
Agent 之間嘅通信係用 session 記憶嘅，佢會記住會話入面提到嘅 Agent。但當短期記憶遺忘咗之後，佢就唔記得點同其他 Agent 通信喇。
解決方法係喺每個 Agent 嘅 workspace/AGENTS.md 入面明確聲明其他 Agent 嘅身份：
## Agent 團隊成員
當你需要其他角色的幫助時：
- **Flutter 技術問題** → 調用 `flutter-tutor` Agent
- **C++ 技術問題** → 調用 `cpp-tutor` Agent
- **資料收集和深度調研** → 調用 `researcher` Agent
- **日常任務** → 調用 `daily-robot` Agent
使用 `callAgent("agent-name")` 來直接通信。
呢個內容會被注入到 system prompt 度，Agent 就唔會唔記得團隊嘅存在。
4. 解決 IM 額度問題
呢個係最坑嘅問題。
OpenClaw 嘅網關機制入面有一個定時快照邏輯：
const healthInterval = setInterval(() => {
void params.refreshGatewayHealthSanpshot({probe:true})…
})
呢個邏輯每 60 秒 ping 一次 IM。如果我有 10 個 Agent，每分鐘就有 10 次 ping，IM 額度好快就用曬。
解決方案：揀一個冇額度限制嘅 IM 工具（例如企業微信、飛書）。
實施步驟
1. 配置 openclaw.json
跟上面嘅模板配置 agentToAgent 和 subagents。
2. 編寫每個 Agent 嘅 AGENTS.md
喺每個 Agent 嘅 workspace 入面創建 AGENTS.md，聲明團隊成員同分工。
3. 測試通信
測試兩個場景：
sessions_send：讓 flutter-tutor找researcher查資料，然後繼續根據呢啲資料討論sessions_spawn：讓 ceo給flutter-tutor一個獨立任務，要求返回結果
4. 測試記憶持久性
叫兩個 Agent 通信，然後等 6 個鐘，再叫佢哋繼續之前嘅對話。確認係重用 session 而唔係開新。
效果驗證
改造完成之後：
ceo可以自動識別任務類型，調度去合適嘅 AgentAgent 之間可以自由通信，唔會「唔記得」隊友 即使過咗幾日，Agent 仍然知道點叫其他 Agent IM 額度問題透過揀合適嘅 IM 工具解決
多 Agent 協同嘅問題，完美解決。
問題 4：對話太長爆 Context？
我遇到嘅坑
隨住對話輪次越來越多，我遇到一個經典問題：Context 爆咗。
一次和 flutter-tutor 討論一個複雜嘅 Flutter 性能優化問題，我哋來回傾咗 50 幾 round。突然，Agent 開始出「上下文已滿」類似嘅錯誤信息。
我檢查咗一下，發現 session 文件已經差唔多 1MB 喇。
問題根源
呢個問題有兩個層面：
1. Session 太長，全部 Send 畀 LLM 會爆 Context
呢個係直覺嘅問題。如果每次對話都將所有歷史記錄 Send 畀 LLM，好快就會到上限。
2. Session 文件本身越來越大
即使做咗壓縮，session 文件本身都會越來越大，讀取同解析都會慢咗。
我嘅解決方案：深入理解 OpenClaw 嘅記憶機制
我深入研究 OpenClaw 嘅源碼，發現佢有一套非常精巧嘅記憶管理機制。
1. Session 嘅三層儲存結構
.openclaw/agents/xxx/sessions/
├── session-1.jsonl # 會話記錄（按需加載）
.openclaw/workspace-xxx/
├── memory/
│ ├── 2026-03-01.md # 按天記錄的原始記憶
│ ├── 2026-03-02.md
├── MEMORY.md # LLM 精練後的記憶（長期知識）
2. Session 嘅三級優化策略
OpenClaw 唔會將全量 session Send 畀 LLM，而係做咗三層優化：
A. Compaction（壓縮） - 持久化
當對話太長嘅時候，舊訊息會被總結成一個 summary。
壓縮前發給 LLM：
[user1, assistant1, user2, assistant2, … , user100, assistant100]
壓縮後發給 LLM：
[compaction_summary, user80, assistant80, … , user100, assistant100]
↑
firstKeptEntryId 控制壓縮程度
壓縮之後會寫入 .jsonl 文件（持久化）。下次對話繼續用壓縮後嘅歷史。
B. Session Pruning（修剪） - 臨時
喺 Send 畀 LLM 之前，臨時裁剪舊嘅 tool 結果。
修剪前 JSONL：
[user1, assistant1, toolResult1(10KB), user2, assistant2, toolResult2(5KB)]
修剪後發給 LLM：
[user1, assistant1, "[Old tool result cleared]", user2, assistant2, toolResult2(5KB)]
↑ 舊的 tool 結果被替換
注意：呢個修剪策略唔改 JSONL 文件，只係內存級別操作。
C. Memory.md 溢出機制
當 Session 接近 context 上限嘅時候，OpenClaw 會自動提示 Agent 寫入 MEMORY.md，然後再壓縮 Session。
3. Agent 點樣決策使用 Memory
Agent 唔係簡單噉將所有 memory 都塞畀 LLM，而係有一個決策流程：
用戶提問
↓
分析話題類型
↓
判斷是否需要檢索 MEMORY.md
↓
如果需要：
- 使用 semantic search 檢索相關內容
- 按相關性排序
- 只取前 3-5 個最相關的片段
↓
構建 prompt（system + relevant memory + user message）
↓
發送給 LLM
實施步驟
1. 調整壓縮策略
在 openclaw.json 入面調整壓縮參數：
{
"session": {
"compaction": {
"enabled": true,
"firstKeptEntryId": 80, // 保留最近 80 條消息
"compressionThreshold": 100 // 超過 100 條時觸發壓縮
}
}
}
2. 啓用 Memory.md 溢出機制
喺 Agent 嘅 AGENTS.md 入面配置：
## Memory 管理策略
當對話長度超過 context 上限的 80% 時：
1. 自動將重要信息總結並寫入 MEMORY.md
2. 壓縮 session，只保留最近的消息
Memory.md 的組織方式：
- 按 topic 分類
- 標註時間戳
- 重要信息優先記錄
3. 定期清理 memory 目錄
設定一個定期任務，每星期清理一次 memory/ 目錄入面嘅舊文件：
# 清理 30 天前的 memory
find ~/.openclaw/workspace-xxx/memory/ -name "*.md" -mtime +30 -delete
效果驗證
改造之後：
就算傾咗幾百 round，Context 都唔會爆 Session 文件大小保持喺合理範圍（<500KB） 重要知識沉澱到 MEMORY.md，唔會唔見 回應速度冇明顯下降
Context 爆炸嘅問題，徹底解決。
問題 5：配置搞冧咗點算？
我遇到嘅坑
OpenClaw 嘅配置非常靈活，但係呢個都意味住容易配錯。
有一次，我喺調整 openclaw.json 嗰陣，唔小心將一個冒號寫成逗號。結果：
所有 Agent 都啟動唔到 Gateway 報錯信息睇唔明 我甚至唔知係邊個文件出錯
仲有一次，我喺 AGENTS.md 入面加咗大量自定義 prompt，搞到 system prompt 長度超過咗模型嘅上限，Agent 一啟動就冧。
最恐怖嘅係，OpenClaw 存咗太多本地數據（sessions、memory、配置），一旦配置搞冧咗，成個系統就癱瘓咗。
問題根源
OpenClaw 嘅配置有呢啲問題：
冇統一嘅配置驗證機制 密鑰同配置撈亂咗，容易洩漏 冇版本控制，改壞咗好難回退 錯誤提示唔夠友善，難定位問題
我嘅解決方案：配置管理最佳實踐
我總結咗一套 OpenClaw 配置管理嘅最佳實踐，避免配置搞冧嘅慘劇。
1. 版本控制（重要！）
絕對唔好將敏感信息提交到 Git！
創建 .gitignore：
# OpenClaw 敏感信息
.openclaw/agents/*/sessions/
.openclaw/workspace-*/memory/
.openclaw/keys.json
openclaw-keys.json
# 只提交核心配置
!.openclaw/openclaw.json
!.openclaw/agents/*/agent/
!.openclaw/workspace-*/
!.openclaw/workspace-*/AGENTS.md
!.openclaw/workspace-*/SOUL.md
!.openclaw/workspace-*/TOOLS.md
!.openclaw/workspace-*/IDENTITY.md
!.openclaw/workspace-*/USER.md
!.openclaw/workspace-*/MEMORY.md
核心思想：
Session 同 memory 係私有數據，唔提交 Agent 嘅 workspace 配置文件可以提交 密鑰透過環境變量管理
2. 密鑰動態注入
openclaw.json 入面同時存咗「密鑰」同「核心 config」，咁好易搞到密鑰洩漏。
解決方案：用環境變量管理密鑰。
創建 openclaw-keys.json（唔提交到 Git）：
{
"llm": {
"provider": "openai",
"apiKey": "${OPENAI_API_KEY}"
},
"im": {
"provider": "telegram",
"botToken": "${TELEGRAM_BOT_TOKEN}"
}
}
創建 .env（唔提交到 Git）：
OPENAI_API_KEY=sk-xxx
TELEGRAM_BOT_TOKEN=xxx
啟動前加載環境變量：
source .env
openclaw gateway start
3. 配置驗證
OpenClaw 自帶咗一啲配置驗證，但係唔夠完善。我寫咗一個簡單嘅驗證腳本：
#!/bin/bash
# validate-config.sh
echo "正在驗證 OpenClaw 配置..."
# 1. 檢查 openclaw.json 語法
if ! jq empty ~/.openclaw/openclaw.json 2>/dev/null; then
echo "❌ 錯誤：openclaw.json 語法錯誤"
exit 1
fi
# 2. 檢查所有 workspace 文件
for workspace in ~/.openclaw/workspace-*; do
if [ -f "$workspace/AGENTS.md" ]; then
echo "✓ $workspace/AGENTS.md 存在"
else
echo "⚠ 警告：$workspace/AGENTS.md 不存在"
fi
done
# 3. 檢查環境變量
if [ -z "$OPENAI_API_KEY" ]; then
echo "⚠ 警告：OPENAI_API_KEY 未設置"
fi
echo "配置驗證完成"
每次啟動前運行：
bash validate-config.sh && openclaw gateway start
4. 配置備份
定期備份核心配置：
#!/bin/bash
# backup-config.sh
BACKUP_DIR="$HOME/.openclaw-backups/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"
# 備份核心配置
cp ~/.openclaw/openclaw.json "$BACKUP_DIR/"
# 備份所有 workspace 配��
for workspace in ~/.openclaw/workspace-*; do
name=$(basename "$workspace")
mkdir -p "$BACKUP_DIR/$name"
cp "$workspace/AGENTS.md" "$BACKUP_DIR/$name/" 2>/dev/null
cp "$workspace/SOUL.md" "$BACKUP_DIR/$name/" 2>/dev/null
done
echo "配置已備份到 $BACKUP_DIR"
設定每星期自動備份。
5. 唔好用 Claude Code 直接操作 OpenClaw
呢個係最重要嘅一條經驗。
唔好用 Claude Code 嚟配置 OpenClaw！
CC 目前對 OpenClaw 項目配置嘅瞭解仲有偏差，成日會出現「it works, but it also broke」嘅情況，搞到工程之後極難維護。
推薦流程：
先睇 OpenClaw 官方文檔 用 OpenClaw 嘅官方指令配置 Agent 如果要用 CC 幫手，先將 OpenClaw 源碼拉落嚟，叫 CC 學咗啲源碼先 再叫 CC 針對本地 OpenClaw 嘅配置進行 debug
畀 CC 足夠嘅源碼語料之後，佢嘅交付水平會大幅提升。
實施步驟
1. 設定 Git 同 .gitignore
跟上面嘅模板創建 .gitignore。
2. 分離密鑰同配置
創建 openclaw-keys.json 和 .env，修改 openclaw.json 用環境變量。
3. 創建驗證同備份腳本
創建 validate-config.sh 和 backup-config.sh，設定定時任務。
4. 啟動前驗證
改動啟動腳本，加入驗證步驟：
# start-openclaw.sh
source .env
bash validate-config.sh && openclaw gateway start
效果驗證
呢套方案嘅效果：
配置改錯咗可以快速回退 密鑰唔會洩漏 每次啟動前自動驗證，避免配置錯誤 有完整嘅備份，隨時可以還原
配置搞冧嘅問題，從根子上解決咗。
問題 6：點樣令 Agent 持續學習？
我遇到嘅坑
砌完多 Agent 架構之後，我發現咗一個問題：Agent 唔會自己進步。
佢每次回答問題，都係根據我畀佢嘅初始 knowledge base。佢唔會從新嘅對話入面學習，亦唔會從外部信息入面更新知識。
咁搞到 Agent 嘅能力係靜態嘅，時間耐咗就會過時。
問題根源
Agent 嘅學習機制有兩個層面：
短期學習：從對話入面學習（Session + MEMORY.md） 長期學習：從外部信息入面學習（Knowledge base 更新）
OpenClaw 本身支援短期學習，但長期學習就需要我哋自己設計。
我嘅解決方案：構建 Agent 學習系統
我設計咗一個「雙層學習」系統：
1. 短期學習：對話驅動
機制：Agent 從對話入面提取有價值嘅信息，寫入 MEMORY.md。
配置方式：在 AGENTS.md 入面定義學習規則：
## 學習規則
當滿足以下條件時，將信息寫入 MEMORY.md：
1. 用戶提供了新的知識點
2. Agent 學到了新的解決方案
3. 用戶明確要求記住某事
4. 對話中發現的重要規律
MEMORY.md 的格式：
```markdown
## 主題
時間：YYYY-MM-DD
來源：對話/用戶
內容：具體的知識點
重要性：高/中/低
**驗證方式**：定期檢查 MEMORY.md，確認 Agent 在持續學習。
#### 2. 長期學習：知識庫更新
**機制**：定期更新 Agent 的 knowledge base。
我設計了三個更新源：
**A. 官方文檔同步**
```bash
#!/bin/bash
# sync-official-docs.sh
# Flutter 官方文檔
curl -o ~/.openclaw/workspace-flutter-tutor/knowledge/flutter-docs.md \
https://docs.flutter.dev/overview.md
# C++ 官方文檔
curl -o ~/.openclaw/workspace-cpp-tutor/knowledge/cpp-docs.md \
https://en.cppreference.com/w/cpp
每個月運行一次。
B. 社區熱點跟蹤
使用 researcher Agent 定期抓取社區熱點：
#!/bin/bash
# track-community-trends.sh
# 讓 researcher Agent 抓取 Flutter 社區熱點
openclaw agent run researcher \
"抓取本週 Flutter 社區熱點，更新到 knowledge base"
每星期運行一次。
C. 用戶反饋整合
將用戶嘅反饋同修正整合到 knowledge base：
#!/bin/bash
# integrate-user-feedback.sh
# 從對話中提取用戶修正
grep -r "修正：" ~/.openclaw/agents/*/sessions/ >> user-corrections.md
# 讓 Agent 整理反饋
openclaw agent run researcher \
"整理 user-corrections.md，更新相關 Agent 的 knowledge base"
3. 學習效果評估
定期評估 Agent 嘅學習效果：
測試集驗證
創建測試用例，定期叫 Agent 回答，驗證能力提升：
## Flutter Agent 測試集
| 問題 | 期望答案類型 | 當前正確率 |
|------|-------------|-----------|
| 如何優化 Widget 重建？ | 性能優化方案 | 85% |
| 狀態管理有哪些方案？ | 方案列表 | 90% |
| 如何處理路由跳轉？ | 代碼示例 | 80% |
如果正確率下降，即係學習出咗問題（可能學到錯誤信息）。
實施步驟
1. 配置短期學習
喺每個 Agent 嘅 AGENTS.md 入面加學習規則。
2. 設定定期更新腳本
創建三個腳本：sync-official-docs.sh、track-community-trends.sh、integrate-user-feedback.sh。
3. 設定定時任務
# 每月同步官方文檔
0 0 1 * * bash sync-official-docs.sh
# 每週跟蹤社區熱點
0 0 * * 0 bash track-community-trends.sh
# 每天整合用戶反饋
0 0 * * * bash integrate-user-feedback.sh
4. 創建測試集
為每個 Agent 創建測試集，設定每星期評估。
效果驗證
運行咗一段時間之後，我觀察到：
Agent 嘅回答質量持續提升 新技術出現之後，Agent 好快就掌握到 用戶反饋可以快速整合到 knowledge base 測試集正確率由 75% 提升到 92%
Agent 持續學習嘅問題，解決咗。
問題 7：點樣令 Agent 真正「明」我？
我遇到嘅坑
解決曬所有技術問題之後，我仲有一個「軟問題」：Agent 唔夠明白我。
佢可以準確回答技術問題，但佢唔知我嘅偏好、習慣、工作方式。
比如：
我鍾意簡潔嘅代碼，佢就寫出繁複嘅實現 我關注性能優化，佢就推薦咗簡單嘅方案 我習慣用某種工具鏈，佢就推薦咗另一種
問題根源
Agent 缺少「用戶畫像」同「上下文先驗」。
OpenClaw 提供咗 USER.md 文件，專門用嚟存用戶偏好，但我之前冇好好利用。
我嘅解決方案：構建用戶畫像系統
我設計咗三個層次嘅用戶畫像：
1. 基礎偏好（USER.md）
喺每個 Agent 嘅 USER.md 入面定義基礎偏好：
## 用戶偏好
### 編程偏好
- 語言：TypeScript、Dart、C++
- 代碼風格：簡潔、可讀性優先
- 注重：性能、可維護性
### 工作習慣
- 工作時間：週一到週五 9:00-18:00
- 項目類型：Flutter 應用、桌面工具
- 團隊規模：3-5 人
### 溝通風格
- 喜歡直接，不喜歡廢話
- 偏好代碼示例，不喜歡純文字
- 喜歡對比方案
### 不喜歡的
- ❌ 過於複雜的抽象
- ❌ 不必要的封裝
- ❌ 引入過多依賴
2. 項目上下文（PROJECT.md）
為每個項目創建 PROJECT.md：
## 項目：Flutter 性能監控工具
### 項目信息
- 名稱：Flutter Perf Monitor
- 報告週期：2024.03-2025.06
- 角色：核心開發者
### 技術棧
- Flutter 3.24
- Dart 3.5
- 包：provider、flutter_riverpod、dio
### 項目規範
- 代碼風格：Google Dart Style Guide
- 測試覆蓋：>80%
- CI/CD：GitHub Actions
### 已解決的問題
- Widget 重建優化（已解決，使用 const）
- 內存泄漏（已解決，使用 dispose）
- 列表性能（已解決，使用 ListView.builder）
### 待解決的問題
- 網絡請求優化
- 圖片緩存策略
- 狀態管理重構
3. 動態上下文（SESSION.md）
喺對話開始時注入動態上下文：
## ��前會話上下文
當前任務：優化 Flutter 列表性能
優先級：高
截止時間：2026-03-15
相關資源：已提供 Flutter 官方性能文檔
實施步驟
1. 完善 USER.md
為每個 Agent 創建詳細嘅 USER.md，定義你嘅偏好、習慣、工作方式。
2. 創建 PROJECT.md
為你嘅主要項目創建 PROJECT.md，擺喺對應嘅 Agent workspace 入面。
3. 用上下文注入
喺對話開始時，先提供上下文：
項目：Flutter Perf Monitor
任務：優化列表性能
優先級：高，下週五截止
請幫我優化這個 Flutter 列表性能問題
效果驗證
配置咗用戶畫像之後，Agent 嘅回答有咗明顯變化：
改造前：
可以用
ListView或GridView，根據需求選擇。如果數據量大，建議用分頁加載...
改造後：
根據你嘅 Flutter Perf Monitor 項目，我建議用
ListView.builder並配合itemBuilder懶加載。考慮到你注重性能，可以：
使用 const構造函數減少 Widget 重建使用 AutomaticKeepAliveClientMixin保持狀態配合 provider管理狀態，符合你項目嘅技術棧
Agent 真正開始「明」我喇。
結尾：從工具到夥伴
搞完呢一整 set，我最大嘅感受係：OpenClaw 唔單止係一個工具，而係一個可以培養嘅夥伴。
一年前同 Manus 嘅朋友傾偈嗰陣，佢分享過一個觀點：
「要做同 AI 能力正交嘅事。」
花時間心力打造同迭代自己嘅 Agent，其實就係同 AI 能力正交嘅一件事，同培養一個人一樣。AI 模型越來越聰明，我哋只需要升級底層 LLM，嗰啲同 AI 互動留低嘅長期數據，都會變成我哋未來更好驅動 AI 嘅私人寶貴數據。
而家，我擁有咗一個「個人嘅 AI 團隊」：
flutter-tutor：Flutter 技術專家cpp-tutor：C++ 技術專家researcher：研究分析師daily-robot：日常助理ceo：統籌協調
佢哋唔係冷冰冰嘅工具，而係我嘅「數字同事」，明我嘅偏好，明我嘅項目，幫我解決各種問題。
呢個，就係 OpenClaw 嘅魅力。
附錄：快速部署清單
如果你都想砌自己嘅 OpenClaw 多 Agent 架構，呢個係我嘅建議清單：
✅ 部署前準備
[ ] 揀 IM 工具（建議揀冇額度限制嘅） [ ] 揀 LLM Model（越聰明越好） [ ] 準備硬件（Mac Mini M1/M4，睇嚇要唔要跑本地模型）
✅ 快速開始（30 分鐘）
[ ] 執行安裝： curl -fsSL https://openclaw.ai/install.sh | bash[ ] 完成 onboarding 配置 [ ] 測試 main Agent
✅ 多 Agent 部署
[ ] 新增 Agent： openclaw agents add xxx[ ] 配置每個 Agent 嘅 workspace 文件（AGENTS.md、SOUL.md、TOOLS.md） [ ] 配置 AgentToAgent 同 Subagents [ ] 測試 Agent 通信
✅ 精細化管控
[ ] 為每個 Agent 配置專屬 Skills [ ] 設定 Skills 延遲加載 [ ] 配置 Session 壓縮策略 [ ] 配置 Memory.md 溢出機制
✅ 運維保障
[ ] 創建 .gitignore，排除敏感信息[ ] 分離密鑰同配置，用環境變量 [ ] 創建配置驗證腳本 [ ] 設定定期備份 [ ] 配置學習系統（官方文檔同步、社區熱點跟蹤）
✅ 用戶畫像
[ ] 完善 USER.md [ ] 創建 PROJECT.md [ ] 配置動態上下文注入
預計總時間：2-3 日（包埋除錯同優化）
祝你都可以砌出自己嘅 AI 團隊！
作者：Maynor日期：2026-03-10OpenClaw 版本：v2026.3.7
相關連結：
OpenClaw 官網：https://openclaw.ai Clawhub 技能市場：https://clawhub.ai OpenClaw GitHub：https://github.com/openclaw-ai/openclaw
OpenClaw 實戰：7個真實場景的多 Agent 落地經驗，一個開發者的 OpenClaw 之旅
開篇：一個開發者的 OpenClaw 之旅
大家好，我是 Maynor。
"OpenClaw 那麼好玩嗎？跟 Happy 有什麼區別？"
這個問題讓我停下來思考。作為一名在 AI 領域摸爬滾打幾年的開發者，我搭建過各種各樣的 Agent 架構。在沒有 OpenClaw 之前，我和朋友們交流 Agent 之前，總是要先花半天時間介紹各自的架構設計——Skills 怎麼管理、Memory 怎麼優化、Session 怎麼保活……
但當我用 OpenClaw 搭建完自己的多 Agent 架構後，一切都變了。
我們再也不用介紹"你的 Agent 是怎麼設計的"了，直接聊的就是：怎麼保活、怎麼替換 RAG 算法、怎麼部署多 Agent、怎麼應用 Good Case。
簡直絲滑爆了。
這篇文章，我想不講架構設計，不講���術原理，只講我在使用 OpenClaw 過程中遇到的 7 個真實問題，以及我是怎麼解決的。
如果你也在考慮搭建自己的 AI 團隊，或者已經在折騰 Agent 但遇到了各種坑，希望這些經驗能幫到你。
問題 1：單 Agent 記憶混亂怎麼辦？
我遇到的坑
這是我最先遇到的問題，也是最典型的坑。
當時我搭建了一個 Flutter 學習助手 Agent，讓我強化 Flutter 技能。剛開始效果不錯，但有一天在討論中，我無意間提到了幾句 C++ 的內容。
問題出現了——在後續的對話中，這個 Agent 開始"偏科"了。
當我讓它提供 Demo 示例時，它不再提供 Flutter 相關的示例，而是開始給我寫 C++ 代碼。我問它 Flutter 的 Widget 樹怎麼優化，它卻跟我討論 C++ 的內存管理。
我意識到，這是記憶機制的副作用。Agent 的 memory 記住了我提到過 C++，但它無法區分這只是一個臨時話題，不是它的核心職責。
問題根源
深入分析後，我發現了兩個根本問題：
1. Context 窗口的瓶頸
熟悉 LLM 原理的同學都知道，LLM 成也 transformer，卡脖子的地方也在 transformer。Context 的瓶頸嚴格約束了單 Agent 智能的發揮。
傳統的單 Agent 架構，通過不斷往 Prompt 中注入身份定義、Skills 列表、歷史對話，正在一步步蠶食 LLM ��� Context 窗口。當對話越來越長，Agent 的"專注度"就越來越差。
2. 專事專做的必要性
用一個人的比喻來說：你讓一個全科醫生同時做心臟手術、骨科手術、眼科手術，結果可想而知。
Agent 也是一樣。當它承載了太多職責，記憶中混雜了太多不同領域的信息，它的判斷質量就會下降。
我的解決方案：多 Agent 架構
基於這個教訓，我重新設計了架構——讓每個 Agent 專事專做。
我把原來的"全能 Agent"拆分成多個"專項 Agent"：
flutter-tutor：專注 Flutter 技術問答cpp-tutor：專注 C++ 技術問答daily-robot：處理日常任務（天氣提醒、日程管理）researcher：負責資料收集和深度調研ceo：統籌協調，負責任務分配
每個 Agent 都有獨立的 workspace 和 memory，互不干擾。
實施步驟
如果你想從單 Agent 遷移到多 Agent，可以按這個步驟來：
1. 新增 Agent
openclaw agents add flutter-tutor
openclaw agents add cpp-tutor
openclaw agents add daily-robot
OpenClaw 會引導你完成基礎配置，按照流程填上 IM bot API 和 LLM API 即可，整個過程大概半小時。
2. 配置 Agent 身份
在 workspace-flutter-tutor/SOUL.md 中定義身份：
你是 Flutter 技術專家，精通 Flutter 開發、Widget 架構、性能優化。
你的職責：
- 回答 Flutter 相關的技術問題
- 提供 Flutter 最佳實踐建議
- 幫助診斷 Flutter 應用問題
你不應該做的：
- 不要回答非 Flutter 的問題（如 C++、Python）
- 不要提供跨技術棧的對比建議
3. 配置 Tools 權限
在 workspace-flutter-tutor/TOOLS.md 中限制工具權限，只給它必要的工具。
效果驗證
改造完成後，我又測試了一遍。這次：
問 Flutter 問題， flutter-tutor響應，答案准確、專注問 C++ 問題， cpp-tutor響應，不再混淆ceo根據問題類型，自動調度到對應的 Agent
記憶混亂的問題，徹底解決了。
問題 2：Agent 技能太多導致調用混亂？
我遇到的坑
拆分多 Agent 後，問題解決了一半，但又遇到了新問題。
一開始，我覺得 Agent 的 Skills 越多越好。於是我給每個 Agent 都配置了大量的 Skills：搜索、天氣、文件操作、代碼執行、繪圖、TTS、RAG、郵件……
結果呢？
Agent 開始"幻覺"��。
我讓 flutter-tutor 幫我看一個 Flutter 項目，它卻莫名其妙地調用了郵件發送工具，想給我發郵件。
我讓它查一個 API 文檔，它先用繪圖工具畫了一張圖，然後再去搜索。
更嚴重的是，有時候它根本不知道該用哪個工具，在幾個工具之間反覆嘗試，浪費 Token。
問題根源
分析後，我發現是**工具白名單變成了一把"萬能鑰匙"**。
當 Agent 有太多工具可以選擇時，LLM 的決策難度急劇增加。這就好比給一個人一個裝着 50 把鑰匙的鑰匙串，讓他自己去開門——他可能要試很多次才能找到對的。
另一個問題是**工具沒有明確的"觸發條件"**。雖然每個 Skill 都有 description，但在實際使用中，Agent 很難準確判斷什麼時候該用哪個工具。
我的解決方案：精細化 Skills 管理
我採用了"基礎通用能力 + 專屬能力"的策略，重新設計了每個 Agent 的 Skills 配置。
1. 分層配置
基礎通用能力（所有 Agent 共享）：
brave-search：聯網搜索（獲取信息必需）healthcheck：健康檢查read/write：基礎文件操作
專屬能力（按需配置）：
flutter-tutor | code-executorflutter-debug |
daily-robot | weathercalendar、reminder |
family-agent | ttsweather（定時天氣彙報） |
researcher | web-fetchsummarize、deep-research |
content-creator | image-genbaoyu-cover-image |
這樣，每個 Agent 的 Skills 數量控制在 5-8 個，既保證能力，又不會造成混亂。
2. 明確觸發條件
在每個 Skill 的 description 中，我增加了更明確的觸發條件：
原來模糊的描述：
description: "搜索相關信息"
改進後的描述：
description: "使用 Brave 搜索引擎搜索相關信息。僅在以下情況使用：
1. 用戶明確要求搜索
2. 需要獲取最新信息
3. 當前 knowledge base 中沒有相關內容
不要用於：查詢本地文件、執行已知操作"
3. 使用 requires 機制
OpenClaw 支持 requires 機制，可以在 Skill 配置中聲明前置條件：
name: weather
description: "Get current weather and forecasts..."
metadata:
openclaw:
requires:
bins: ["curl"]
config:
- "weather.api_key"
只有滿足條件的 Agent 才能加載這個 Skill。
實施步驟
1. 清理冗餘 Skills
先統計一下每個 Agent 有多少 Skills，然後逐個審查必要性。
我當時的策略是：如果一個 Skill 過去一週都沒被調用過，就把它移除。
2. 使用 Clawhub 管理
Clawhub 是 OpenClaw 的 Skills 市場，可以方便地管理 Skills：
# 語義搜索 Skills
clawhub search "calendar management"
# 安裝指定 Skill
clawhub install <skill-slug>
# 列出已安裝的 Skills
clawhub list
# 更新所有已安裝的 Skills
clawhub update --all
推薦的優質 Skills：
find-skills：技能發現summarize：內容總結brave-search：聯網搜索frontend-design：前端設計輔助
3. 定期清理
我設置了一個定期任務，每兩週用高階模型掃描一次 Skills，清理：
低質量 Skill 衝突的 Skill 長期未使用的 Skill
效果驗證
改造後，我觀察到：
Agent 調用工具的準確率從 60% 提升到 95% Token 消耗減少了 30%（減少了無效嘗試） 響應速度明顯提升
工具混亂的問題，也解決了。
問題 3：多個 Agent 如何協同工作？
我遇到的坑
拆分完 Agent、管好 Skills 後，我遇到一個更復雜的問題：Agent 之間怎麼合作？
最開始的方案是讓用戶手動指定。比如：
用戶：讓 flutter-tutor 幫我看這個 Flutter 項目
這雖然能用，但太繁瑣了。我希望有一個 ceo Agent，能自動識別任務，然後調度給合適的 Agent。
於是我配置了多 Agent 通信，但遇到了一堆新問題：
ceo不知道有哪些 Agent 可用Agent 之間通信後，過了一天就忘了對方的存在 不知道什麼時候該用 sessions_send，什麼時候該用sessions_spawn多 Agent 後，IM 額度飛速消耗
問題根源
我深入研究了 OpenClaw 的多 Agent 通信機制，發現了兩個核心工具：
1. sessions_send`
向已存在的 session 發消息。就像給同事發消息，他在自己的上下文中處理。
callAgent("flutter-tutor", {
message: "繼續之前的討論",
method: "sessions_send"
})
2. sessions_spawn`
在獨立環境中運行任務，僱傭臨時工。
callAgent("flutter-tutor", {
message: "幫我優化這個 Flutter 項目",
method: "sessions_spawn"
})
我的問題是沒有搞清楚這兩個工具的區別，也沒有正確配置 Agent 之間的關係。
我的解決方案：扁平化 + 雙向通信
我參考了組織中高效運作的原則：扁平化、達成目標是最終目的，層級只是方式。
基於這個原則，我設計了一個"全���聯"的多 Agent 架構：
1. 配置 AgentToAgent（sessions_send）
在 openclaw.json 中配置所有 Agent 之間的通信權限：
{
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["ceo", "flutter-tutor", "cpp-tutor", "daily-robot", "researcher"]
},
"sessions": {
"visibility": "all" // 重要！一定要配置
}
}
}
這樣，所有 Agent 都可以互相發消息，就像公司的同事可以自由溝通。
2. 配置 SubAgents（sessions_spawn）
讓每個 Agent 都能指揮其他 Agent，就像每個人都有權找其他同事幫忙：
{
"id": "ceo",
"name": "CEO",
"workspace": "/Users/blinblin/.openclaw/workspace-ceo",
"subagents": {
"allowAgents": ["flutter-tutor", "cpp-tutor", "daily-robot", "researcher"]
}
},
{
"id": "flutter-tutor",
"name": "Flutter Tutor",
"workspace": "/Users/blinblin/.openclaw/workspace-flutter-tutor",
"subagents": {
"allowAgents": ["ceo", "researcher"]
}
},
{
"id": "cpp-tutor",
"name": "C++ Tutor",
"workspace": "/Users/blinblin/.openclaw/workspace-cpp-tutor",
"subagents": {
"allowAgents": ["ceo", "researcher"]
}
}
3. 在 AGENTS.md 中固化 Agent 關係
這是最容易被忽略的一步。
Agent 之間的通信是用 session 記憶的，它能記住會話中提到的 Agent。但當短期記憶遺忘後，它就忘了怎麼跟其他 Agent 通信了。
解決方法是在每個 Agent 的 workspace/AGENTS.md 中明確聲明其他 Agent 的身份：
## Agent 團隊成員
當你需要其他角色的幫助時：
- **Flutter 技術問題** → 調用 `flutter-tutor` Agent
- **C++ 技術問題** → 調用 `cpp-tutor` Agent
- **資料收集和深度調研** → 調用 `researcher` Agent
- **日常任務** → 調用 `daily-robot` Agent
使用 `callAgent("agent-name")` 來直接通信。
這個內容會被注入到 system prompt 中，Agent 就不會忘了團隊的存在。
4. 解決 IM 額度問題
這是最坑的一個問題。
OpenClaw 的網關機制中有一個定時快照邏輯：
const healthInterval = setInterval(() => {
void params.refreshGatewayHealthSanpshot({probe:true})…
})
這個邏輯每 60 秒 ping 一次 IM。如果我有 10 個 Agent，每分鐘就有 10 次 ping，IM 額度很快耗盡。
解決方案：選擇一個沒有額度限制的 IM 工具（如企業微信、飛書）。
實施步驟
1. 配置 openclaw.json
按照上面的模板配置 agentToAgent 和 subagents。
2. 編寫每個 Agent 的 AGENTS.md
在每個 Agent 的 workspace 中創建 AGENTS.md，聲明團隊成員和分工。
3. 測試通信
測試兩個場景：
sessions_send：讓 flutter-tutor找researcher查資料，然後繼續基於這個資料討論sessions_spawn：讓 ceo給flutter-tutor一個獨立任務，要求返回結果
4. 測試記憶持久性
讓兩個 Agent 通信，然後等 6 小時，再讓它們繼續之前的對話。確認是複用 session 而不是新建。
效果驗證
改造完成後：
ceo能自動識別任務類型，調度到合適的 AgentAgent 之間可以自由通信，不會"遺忘"隊友 即使過了幾天，Agent 仍然知道如何調用其他 Agent IM 額度問題通過選擇合適的 IM 工具解決
多 Agent 協同的問題，完美解決。
問題 4：對話太長爆 Context？
我遇到的坑
隨着對話輪次越來越多，我遇到了一個經典問題：Context 爆了。
一次和 flutter-tutor 討論一個複雜的 Flutter 性能優化問題，我們來回聊了 50 多輪。突然，Agent 開始回答"上下文已滿"類似的錯誤信息。
我檢查了一下，發現 session 文件已經快 1MB 了。
問題根源
這個問題有兩個層面：
1. Session 太長，全部發給 LLM 會爆 Context
這是直覺的問題。如果每次對話都把所有歷史記錄發給 LLM，很快就會達到上限。
2. Session 文件本身越來越大
即使做了壓縮，session 文件本身也會越來越大，讀取和解析都會變慢。
我的解決方案：深入理解 OpenClaw 的記憶機制
我深入研究 OpenClaw 的源碼，發現它有一套非常精巧的記憶管理機制。
1. Session 的三層存儲結構
.openclaw/agents/xxx/sessions/
├── session-1.jsonl # 會話記錄（按需加載）
.openclaw/workspace-xxx/
├── memory/
│ ├── 2026-03-01.md # 按天記錄的原始記憶
│ ├── 2026-03-02.md
├── MEMORY.md # LLM 精練後的記憶（長期知識）
2. Session 的三級優化策略
OpenClaw 不會把全量 session 發給 LLM，而是做了三層優化：
A. Compaction（壓縮） - 持久化
當對話太長時，舊消息會被總結成一個 summary。
壓縮前發給 LLM：
[user1, assistant1, user2, assistant2, … , user100, assistant100]
壓縮後發給 LLM：
[compaction_summary, user80, assistant80, … , user100, assistant100]
↑
firstKeptEntryId 控制壓縮程度
壓縮後會寫入 .jsonl 文件（持久化）。下次對話繼續使用壓縮後的歷史。
B. Session Pruning（修剪） - 臨時
在發給 LLM 之前，臨時裁剪舊的 tool 結果。
修剪前 JSONL：
[user1, assistant1, toolResult1(10KB), user2, assistant2, toolResult2(5KB)]
修剪後發給 LLM：
[user1, assistant1, "[Old tool result cleared]", user2, assistant2, toolResult2(5KB)]
↑ 舊的 tool 結果被替換
注意：這個修剪策略不修改 JSONL 文件，只是內存級別操作。
C. Memory.md 溢出機制
當 Session 接近 context 上限時，OpenClaw 會自動提示 Agent 寫入 MEMORY.md，然後再壓縮 Session。
3. Agent 如何決策使用 Memory
Agent 不是簡單地把所有 memory 都塞給 LLM，而是有一個決策流程：
用戶提問
↓
分析話題類型
↓
判斷是否需要檢索 MEMORY.md
↓
如果需要：
- 使用 semantic search 檢索相關內容
- 按相關性排序
- 只取前 3-5 個最相關的片段
↓
構建 prompt（system + relevant memory + user message）
↓
發送給 LLM
實施步驟
1. 調整壓縮策略
在 openclaw.json 中調整壓縮參數：
{
"session": {
"compaction": {
"enabled": true,
"firstKeptEntryId": 80, // 保留最近 80 條消息
"compressionThreshold": 100 // 超過 100 條時觸發壓縮
}
}
}
2. 啓用 Memory.md 溢出機制
在 Agent 的 AGENTS.md 中配置：
## Memory 管理策略
當對話長度超過 context 上限的 80% 時：
1. 自動將重要信息總結並寫入 MEMORY.md
2. 壓縮 session，只保留最近的消息
Memory.md 的組織方式：
- 按 topic 分類
- 標註時間戳
- 重要信息優先記錄
3. 定期清理 memory 目錄
設置一個定時任務，每週清理一次 memory/ 目錄中的舊文件：
# 清理 30 天前的 memory
find ~/.openclaw/workspace-xxx/memory/ -name "*.md" -mtime +30 -delete
效果驗證
改造後：
即使聊了幾百輪，Context 也不會爆 Session 文件大小保持在合理範圍（<500KB） 重要知識沉澱到 MEMORY.md，不會丟失 響應速度沒有明顯下降
Context 爆炸的問題，徹底解決。
問題 5：配置搞掛了怎麼辦？
我遇到的坑
OpenClaw 的配置非常靈活，但這也意味着容易配錯。
有一次，我在調整 openclaw.json 時，不小心把一個冒號寫成了逗號。結果：
所有 Agent 都無法啓動 Gateway 報錯信息看不懂 我甚至不知道是哪個文件出錯了
還有一次，我在 AGENTS.md 中加了大量的自定義 prompt，導致 system prompt 長度超過了模型的上限，Agent 一啓動就崩。
最可怕的是，OpenClaw 存了太多本地數據（sessions、memory、配置），一旦配置搞掛了，整個系統就癱瘓了。
問題根源
OpenClaw 的配置有這些問題：
沒有統一的配置驗證機制 密鑰和配置混在一起，容易泄露 沒有版本控制，改壞了很難回退 錯誤提示不夠友好，難以定位問題
我的解決方案：配置管理最佳實踐
我總結了一套 OpenClaw 配置管理的最佳實踐，避免配置搞掛的慘劇。
1. 版本控制（重要！）
絕對不要把敏感信息提交到 Git！
創建 .gitignore：
# OpenClaw 敏感信息
.openclaw/agents/*/sessions/
.openclaw/workspace-*/memory/
.openclaw/keys.json
openclaw-keys.json
# 只提交核心配置
!.openclaw/openclaw.json
!.openclaw/agents/*/agent/
!.openclaw/workspace-*/
!.openclaw/workspace-*/AGENTS.md
!.openclaw/workspace-*/SOUL.md
!.openclaw/workspace-*/TOOLS.md
!.openclaw/workspace-*/IDENTITY.md
!.openclaw/workspace-*/USER.md
!.openclaw/workspace-*/MEMORY.md
核心思想：
Session 和 memory 是私有數據，不提交 Agent 的 workspace 配置文件可以提交 密鑰通過環境變量管理
2. 密鑰動態注入
openclaw.json 中同時存儲了"密鑰"和"核心 config"，這很容易導致密鑰泄露。
解決方案：使用環境變量管理密鑰。
創建 openclaw-keys.json（不提交到 Git）：
{
"llm": {
"provider": "openai",
"apiKey": "${OPENAI_API_KEY}"
},
"im": {
"provider": "telegram",
"botToken": "${TELEGRAM_BOT_TOKEN}"
}
}
創建 .env（不提交到 Git）：
OPENAI_API_KEY=sk-xxx
TELEGRAM_BOT_TOKEN=xxx
啓動前加載環境變量：
source .env
openclaw gateway start
3. 配置驗證
OpenClaw 自帶了一些配置驗證，但不夠完善。我寫了一個簡單的驗證腳本：
#!/bin/bash
# validate-config.sh
echo "正在驗證 OpenClaw 配置..."
# 1. 檢查 openclaw.json 語法
if ! jq empty ~/.openclaw/openclaw.json 2>/dev/null; then
echo "❌ 錯誤：openclaw.json 語法錯誤"
exit 1
fi
# 2. 檢查所有 workspace 文件
for workspace in ~/.openclaw/workspace-*; do
if [ -f "$workspace/AGENTS.md" ]; then
echo "✓ $workspace/AGENTS.md 存在"
else
echo "⚠ 警告：$workspace/AGENTS.md 不存在"
fi
done
# 3. 檢查環境變量
if [ -z "$OPENAI_API_KEY" ]; then
echo "⚠ 警告：OPENAI_API_KEY 未設置"
fi
echo "配置驗證完成"
每次啓動前運行：
bash validate-config.sh && openclaw gateway start
4. 配置備份
定期備份核心配置：
#!/bin/bash
# backup-config.sh
BACKUP_DIR="$HOME/.openclaw-backups/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"
# 備份核心配置
cp ~/.openclaw/openclaw.json "$BACKUP_DIR/"
# 備份所有 workspace 配��
for workspace in ~/.openclaw/workspace-*; do
name=$(basename "$workspace")
mkdir -p "$BACKUP_DIR/$name"
cp "$workspace/AGENTS.md" "$BACKUP_DIR/$name/" 2>/dev/null
cp "$workspace/SOUL.md" "$BACKUP_DIR/$name/" 2>/dev/null
done
echo "配置已備份到 $BACKUP_DIR"
設置每週自動備份。
5. 不要用 Claude Code 直接操作 OpenClaw
這是最重要的一條經驗。
不要用 Claude Code 來配置 OpenClaw！
CC 目前對 OpenClaw 項目配置的瞭解還有偏差，經常會出現"it works, but it also broke"的情況，導致工程後續極難維護。
推薦流程：
先閲讀 OpenClaw 官方文檔 使用 OpenClaw 的官方指令配置 Agent 如果需要 CC 幫忙，先把 OpenClaw 源碼爬下來，讓 CC 學一下源碼 再讓 CC 針對本地 OpenClaw 的配置進行 debug
給 CC 足夠的源碼語料後，它的交付水平會大幅提升。
實施步驟
1. 設置 Git 和 .gitignore
按照上面的模板創建 .gitignore。
2. 分離密鑰和配置
創建 openclaw-keys.json 和 .env，修改 openclaw.json 使用環境變量。
3. 創建驗證和備份腳本
創建 validate-config.sh 和 backup-config.sh，設置定時任務。
4. 啓動前驗證
修改啓動腳本，加入驗證步驟：
# start-openclaw.sh
source .env
bash validate-config.sh && openclaw gateway start
效果驗證
這套方案的效果：
配置改錯了可以快速回退 密鑰不會泄露 每次啓動前自動驗證，避免配置錯誤 有完整的備份，隨時可以恢復
配置搞掛的問題，從根子上解決了。
問題 6：如何讓 Agent 持續學習？
我遇到的坑
搭建完多 Agent 架構後，我發現了一個問題：Agent 不會自己進步。
它每次回答問題，都是基於我給它的初始 knowledge base。它不會從新的對話中學習，也不會從外部信息中更新知識。
這導致 Agent 的能力是靜態的，時間長了就會過時。
問題根源
Agent 的學習機制有兩個層面：
短期學習：從對話中學習（Session + MEMORY.md） 長期學習：從外部信息中學習（Knowledge base 更新）
OpenClaw 本身支持短期學習，但長期學習需要我們自己設計。
我的解決方案：構建 Agent 學習系統
我設計了一個"雙層學習"系統：
1. 短期學習：對話驅動
機制：Agent 從對話中提取有價值的信息，寫入 MEMORY.md。
配置方式：在 AGENTS.md 中定義學習規則：
## 學習規則
當滿足以下條件時，將信息寫入 MEMORY.md：
1. 用戶提供了新的知識點
2. Agent 學到了新的解決方案
3. 用戶明確要求記住某事
4. 對話中發現的重要規律
MEMORY.md 的格式：
```markdown
## 主題
時間：YYYY-MM-DD
來源：對話/用戶
內容：具體的知識點
重要性：高/中/低
**驗證方式**：定期檢查 MEMORY.md，確認 Agent 在持續學習。
#### 2. 長期學習：知識庫更新
**機制**：定期更新 Agent 的 knowledge base。
我設計了三個更新源：
**A. 官方文檔同步**
```bash
#!/bin/bash
# sync-official-docs.sh
# Flutter 官方文檔
curl -o ~/.openclaw/workspace-flutter-tutor/knowledge/flutter-docs.md \
https://docs.flutter.dev/overview.md
# C++ 官方文檔
curl -o ~/.openclaw/workspace-cpp-tutor/knowledge/cpp-docs.md \
https://en.cppreference.com/w/cpp
每月運行一次。
B. 社區熱點跟蹤
使用 researcher Agent 定期抓取社區熱點：
#!/bin/bash
# track-community-trends.sh
# 讓 researcher Agent 抓取 Flutter 社區熱點
openclaw agent run researcher \
"抓取本週 Flutter 社區熱點，更新到 knowledge base"
每週運行一次。
C. 用戶反��整合
將用戶的反饋和修正整合到 knowledge base：
#!/bin/bash
# integrate-user-feedback.sh
# 從對話中提取用戶修正
grep -r "修正：" ~/.openclaw/agents/*/sessions/ >> user-corrections.md
# 讓 Agent 整理反饋
openclaw agent run researcher \
"整理 user-corrections.md，更新相關 Agent 的 knowledge base"
3. 學習效果評估
定期評估 Agent 的學習效果：
測試集驗證
創建測試用例，定期讓 Agent 回答，驗證能力提升：
## Flutter Agent 測試集
| 問題 | 期望答案類型 | 當前正確率 |
|------|-------------|-----------|
| 如何優化 Widget 重建？ | 性能優化方案 | 85% |
| 狀態管理有哪些方案？ | 方案列表 | 90% |
| 如何處理路由跳轉？ | 代碼示例 | 80% |
如果正確率下降，說明學習出了問題（可能是學到了錯誤信息）。
實施步驟
1. 配置短期學習
在每個 Agent 的 AGENTS.md 中添加學習規則。
2. 設置定期更新腳本
創建三個腳本：sync-official-docs.sh、track-community-trends.sh、integrate-user-feedback.sh。
3. 設置定時任務
# 每月同步官方文檔
0 0 1 * * bash sync-official-docs.sh
# 每週跟蹤社區熱點
0 0 * * 0 bash track-community-trends.sh
# 每天整合用戶反饋
0 0 * * * bash integrate-user-feedback.sh
4. 創建測試集
為每個 Agent 創建測試集，設置每週評估。
效果驗證
運行一段時間後，我觀察到：
Agent 的回答質量持續提升 新技術出現後，Agent 很快就能掌握 用戶反饋能快速整合到 knowledge base 測試集正確率從 75% 提升到 92%
Agent 持續學習的問題，解決了。
問題 7：如何讓 Agent 真正"懂"我？
我遇到的坑
解決了所有技術問題後，我還有一個"軟問題"：Agent 不夠懂我。
它能準確回答技術問題，但它不知道我的偏好、習慣、工作方式。
比如：
我喜歡簡潔的代碼，它卻寫出繁複的實現 我關注性能優化，它卻推薦了簡單的方案 我習慣用某種工具鏈，它卻推薦了另一種
問題根源
Agent 缺少"用戶畫像"和"上下文先驗"。
OpenClaw 提供了 USER.md 文件，專門用來存儲用戶偏好，但我之前沒有充分利用。
我的解決方案：構建用戶畫像系統
我設計了三個層次的用戶畫像：
1. 基礎偏好（USER.md）
在每個 Agent 的 USER.md 中定義基礎偏好：
## 用戶偏好
### 編程偏好
- 語言：TypeScript、Dart、C++
- 代碼風格：簡潔、可讀性優先
- 注重：性能、可維護性
### 工作習慣
- 工作時間：週一到週五 9:00-18:00
- 項目類型：Flutter 應用、桌面工具
- 團隊規模：3-5 人
### 溝通風格
- 喜歡直接，不喜歡廢話
- 偏好代碼示例，不喜歡純文字
- 喜歡對比方案
### 不喜歡的
- ❌ 過於複雜的抽象
- ❌ 不必要的封裝
- ❌ 引入過多依賴
2. 項目上下文（PROJECT.md）
為每個項目創建 PROJECT.md：
## 項目：Flutter 性能監控工具
### 項目信息
- 名稱：Flutter Perf Monitor
- 報告週期：2024.03-2025.06
- 角色：核心開發者
### 技術棧
- Flutter 3.24
- Dart 3.5
- 包：provider、flutter_riverpod、dio
### 項目規範
- 代碼風格：Google Dart Style Guide
- 測試覆蓋：>80%
- CI/CD：GitHub Actions
### 已解決的問題
- Widget 重建優化（已解決，使用 const）
- 內存泄漏（已解決，使用 dispose）
- 列表性能（已解決，使用 ListView.builder）
### 待解決的問題
- 網絡請求優化
- 圖片緩存策略
- 狀態管理重構
3. 動態上下文（SESSION.md）
在對話開始時注入動態上下文：
## ��前會話上下文
當前任務：優化 Flutter 列表性能
優先級：高
截止時間：2026-03-15
相關資源：已提供 Flutter 官方性能文檔
實施步驟
1. 完善 USER.md
為每個 Agent 創建詳細的 USER.md，定義你的偏好、習慣、工作方式。
2. 創建 PROJECT.md
為你的主要項目創建 PROJECT.md，放在對應的 Agent workspace 中。
3. 使用上下文注入
在對話開始時，先提供上下文：
項目：Flutter Perf Monitor
任務：優化列表性能
優先級：高，下週五截止
請幫我優化這個 Flutter 列表性能問題
效果驗證
配置用戶畫像後，Agent 的回答發生了明顯變化：
改造前：
可以使用
ListView或GridView，根據需求選擇。如果數據量大，建議使用分頁加載...
改造後：
基於你的 Flutter Perf Monitor 項目，我建議使用
ListView.builder並配合itemBuilder懶加載。考慮到你注重性能，可以：
使用 const構造函數減少 Widget 重建使用 AutomaticKeepAliveClientMixin保持狀態配合 provider管理狀態，符合你項目的技術棧
Agent 真正開始"懂"我了。
結尾：從工具到夥伴
折騰完這一整套，我最大的感受是：OpenClaw 不只是一個工具，而是一個可以培養的夥伴。
一年前跟 Manus 的朋友聊天時，他分享過一個觀點：
"要做和 AI 能力正交的事情。"
花時間精力打造和迭代自己的 Agent，其實就是跟 AI 能力正交的一件事，跟培養一個人一樣。AI 模型越來越聰明，我們只需要升級���層 LLM，那些跟 AI 交互留下來的長期數據，都將會變成我們未來更好驅動 AI 的私人寶貴數據。
現在，我擁有了一個"個人的 AI 團隊"：
flutter-tutor：Flutter 技術專家cpp-tutor：C++ 技術專家researcher：研究分析師daily-robot：日常助理ceo：統籌協調
它們不是冷冰冰的工具，而是我的"數字同事"，懂我的偏好，懂我的項目，幫我解決各種問題。
這，就是 OpenClaw 的魅力。
附錄：快速部署清單
如果你也想搭建自己的 OpenClaw 多 Agent 架構，這是我的建議清單：
✅ 部署前準備
[ ] 選擇 IM 工具（建議選無額度限制的） [ ] 選擇 LLM Model（越聰明越好） [ ] 準備硬件（Mac Mini M1/M4，看是否跑本地模型）
✅ 快速開始（30 分鐘）
[ ] 運行安裝： curl -fsSL https://openclaw.ai/install.sh | bash[ ] 完成 onboarding 配置 [ ] 測試 main Agent
✅ 多 Agent 部署
[ ] 新增 Agent： openclaw agents add xxx[ ] 配置每個 Agent 的 workspace 文件（AGENTS.md、SOUL.md、TOOLS.md） [ ] 配置 AgentToAgent 和 Subagents [ ] 測試 Agent 通信
✅ 精細化管控
[ ] 為每個 Agent 配置專屬 Skills [ ] 設置 Skills 延遲加載 [ ] 配置 Session 壓縮策略 [ ] 配置 Memory.md 溢出機制
✅ 運維保障
[ ] 創建 .gitignore，排除敏感信息[ ] 分離密鑰和配置，使用環境變量 [ ] 創建配置驗證腳本 [ ] 設置定期備份 [ ] 配置學習系統（官方文檔同步、社區熱點跟蹤）
✅ 用戶畫像
[ ] 完善 USER.md [ ] 創建 PROJECT.md [ ] 配置動態上下文注入
預計總時間：2-3 天（包含調試和優化）
祝你也能搭建出自己的 AI 團隊！
作者：Maynor日期：2026-03-10OpenClaw 版本：v2026.3.7
相關連結：
OpenClaw 官網：https://openclaw.ai Clawhub 技能市場：https://clawhub.ai OpenClaw GitHub：https://github.com/openclaw-ai/openclaw