寫在前面：這篇預設你已經做到這些
如果你已經：
- 裝好 OpenClaw 而且能正常聊天（Discord／Telegram／WebChat 都行）
- 寫過
SOUL.md / USER.md / IDENTITY.md - 知道
MEMORY.md、memory/分層結構，以及memorySearch大概是什麼
那就可以直接往下看了。
這篇我會講 7 個主題，都是「能直接落地」的設定點：
AGENTS.md：給 AI 一份工作手冊（最關鍵）- 記憶系統實戰：讓 AI 真正記住，而且自己維護
- 子 Agent：一個人變一支小隊（平行 + 上下文隔離）
- Cron 排程任務：精確到分鐘的自動化
- Skill 開發：教 AI 學新技能（從 0 寫一個 skill）
- 多管道接入：隨時隨地找到你的 AI
- 設定速查表：常用參數的「建議值」和坑點
先看一眼：從「上篇水準」到「本篇調教後」
SOUL.md 幾條原則一、AGENTS.md：給 AI 寫一份「工作手冊」
1）它解決什麼問題？
SOUL.md 決定「它像誰」，USER.md 決定「它在幫誰」，但很多人忽略了：AI 並不知道該怎麼工作。
例如：
- 新 session 啟動時該先讀哪個檔案？順序是什麼？
- 記憶應該寫到哪裡？用什麼格式寫？
- 哪些操作可以直接做？哪些必須先問你？
- 群組聊天裡能不能引用你的私人記憶？
這就是 AGENTS.md 的價值：它不是性格設定，而是工作手冊。
可以這樣理解：
SOUL.md= 性格（「講話實在、直接給結論」）AGENTS.md= SOP（「先讀什麼、再做什麼、怎麼記錄、什麼不能做」）
2）Session 啟動流程：AI 醒來第一件事該做什麼？
新 session 本質上是「剛醒來」，它不會自動帶著你上次對話的上下文。你要把「恢復現場」的流程寫死。
在 AGENTS.md 裡加一個段落（建議用英文寫規則比較穩定）：
Every Session
Before doing anything else:
- Read
SOUL.md— this is who you are - Read
USER.md— this is who you're helping - Read
memory/YYYY-MM-DD.md(today + yesterday) for recent context - If in MAIN SESSION (direct chat with your human): Also read
MEMORY.md
Don't ask permission. Just do it.
為什麼要讀「今天 + 昨天」的日誌？因為凌晨的時候「今天」可能還是空的，昨天才有內容。
為什麼 MEMORY.md 只在 MAIN SESSION 讀？因為 MEMORY.md 往往放的是更私人、更核心的索引資訊，不適合在群組聊天或 cron／子 agent 的 session 裡載入。
3）記憶寫入規範：教它怎麼記「可重複使用的結論」
很多人的記憶系統翻車，不是分層結構問題，而是寫入規範沒訂。
結果通常是兩種：
- 什麼都堆到
MEMORY.md（最後變成流水帳） - 或者根本不寫（下次直接忘）
建議把「寫到哪裡、寫什麼、怎麼寫」明確下來。例如：
Memory
You wake up fresh each session. These files are your continuity.
記憶分層
MEMORY.mdmemory/projects.mdmemory/infra.mdmemory/lessons.mdmemory/YYYY-MM-DD.md寫入規則
- 日誌：當天發生的事寫入
memory/YYYY-MM-DD.md，格式固定 - 專案狀態：專案有進展就同步更新
memory/projects.md - 教訓：踩坑後寫入
memory/lessons.md - MEMORY.md：只在索引變化時更新，保持精簡
鐵律
- 記結論不記過程
- 用標籤方便 memorySearch
- 想記住就寫檔案，別指望「腦子裡記著」
日誌格式可以用這種：
[PROJECT:名稱] 標題
- 結論: 一句話總結
- 檔案變更: 涉及哪些檔案
- 教訓: 踩坑點（如有）
- 標籤: #tag1 #tag2
這套格式的優勢是：你用 memorySearch 搜關鍵字時，命中會更集中、更乾淨。
4）安全邊界：哪些事能做，哪些必須問
建議把「內部 vs 外部」劃清楚，不然遲早踩坑（尤其是群組聊天、自動化任務）。
Safety
- Don't exfiltrate private data. Ever.
- Don't run destructive commands without asking.
trash>rm(recoverable beats gone forever)- When in doubt, ask.
External vs Internal
Safe to do freely:
- Read files, explore, organize, learn
- Search the web, check calendars
- Work within this workspace
Ask first:
- Sending emails, tweets, public posts
- Anything that leaves the machine
- Anything you're uncertain about
Group Chats
You have access to your human's stuff. That doesn't mean you share it.
In groups, you're a participant — not their voice, not their proxy.
二、記憶系統實戰：讓 AI 真正「記住」，而且自己維護
你可能遇過三個典型問題：
- 聊久了突然「失憶」（對話被壓縮後丟細節）
- 日誌越寫越多，但品質參差，搜尋命中越來越玄
- 記憶沒人維護，過期資訊堆成噪音
這一章就是分別解決這三件事。
1）memoryFlush：壓縮之前先把重要資訊寫進檔案
OpenClaw 會在上下文接近上限時觸發 compaction（壓縮）。壓縮本身正常，但壓縮可能丟細節。
解決辦法：開 memoryFlush，讓它在壓縮前先落盤。
在 openclaw.json 裡加（範例）：
{
"agents": {
"defaults": {
"compaction": {
"reserveTokensFloor": 20000,
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 4000
}
}
}
}
}
簡單解釋一下建議值怎麼理解：
reserveTokensFloor=20000：壓縮後至少保留一段「最近對話」softThresholdTokens=4000：剩餘空間少於 4000 token 時觸發 flush（太小寫不下，太大觸發太頻繁）
2）讓 memorySearch 更準：一篇日誌只講一個主題
向量檢索不怕你寫得少，反而更怕「寫太雜」。
經驗上，命中率最高的寫法是：
- 標題裡就寫清主題（例如 nginx 反向代理、IPv6、連接埠衝突）
- 結論放在固定位置
- 標籤補齊同義詞（#deploy #nginx #reverse-proxy）
非結構化的「流水帳」會把相似度稀釋掉，搜起來就會變玄。
3）每週自動維護：防止「記憶腐爛」
日誌寫多了以後，過期資訊會污染檢索結果。我的做法是：把維護變成固定流程，讓 AI 每週自動做一次。
你可以在 HEARTBEAT.md 裡加一個「每週維護」任務，搭配一個狀態檔案來控制頻率：
memory/heartbeat-state.json記錄上次維護日期- 心跳檢查「距離上次維護是否 >= 7 天」
- 超過就執行：提煉、壓縮、清理、更新日期
維護動作我建議三類：
- 提煉：把長期有用的東西搬到
projects.md / lessons.md - 壓縮：一次性任務從長日誌壓成一行結論
- 清理：完全過期的資訊（例如「明天開會」）
三、子 Agent：一個人變一支小隊（平行 + 隔離上下文）
1）子 Agent 到底解決什麼？
主腦單執行緒的問題是：複雜任務一來，它要嘛拖很久，要嘛中途你沒辦法插話。
子 Agent 的價值主要有兩點：
- 平行：可以同時派 2 個小弟各做一塊
- 隔離上下文：子 agent 的長任務不會把主對話擠爆
2）最容易踩的坑：子 Agent 預設「零上下文」
子 Agent 只看到主腦給它的 task 描述，所以 task 寫得爛，結果就會爛。
一個好的 task 描述至少包括：
- 目標（要產出什麼）
- 檔案路徑（讀／寫哪些）
- 限制（只讀？不能改哪些？規範是什麼？）
- 驗收標準（什麼算完成）
把 task 當成你寫給「聰明但陌生的同事」的說明書，越具體越穩。
3）並行建議：先從 2 個子 Agent 開始
同時派太多 agent 很容易觸發 API 限流（429）。經驗上：
- 一般個人額度：同時 2 個最穩
- 額度大／本地模型：可以試 3 個
- 4 個以上大概率開始 429（尤其是帶 web 搜尋／工具呼叫時）
四、Cron 排程任務：精確到分鐘的自動化
1）Heartbeat vs Cron：別混用
- Heartbeat：適合「順便檢查一下」的輕量任務（精度不高）
- Cron：適合「幾點幾分必須執行」的任務（精確到分鐘）
如果你想做「每天 9:00 發早報」「每週一 10:00 發週報」，Cron 更合適。
2）cron 運算式最常用的幾個
0 9 * * *：每天 9:000 9 * * 1：每週一 9:000 9,18 * * *：每天 9:00 和 18:00*/30 * * * *：每 30 分鐘
一定要設定時區 tz，不然預設是 UTC，時間會偏 8 小時（東八區最常見的坑）。
五、Skill 開發入門：從 0 寫一個能用的 Skill
1）Skill 是什麼？
它本質上是一份「操作手冊（Markdown）」。
OpenClaw 會把每個 skill 的 description 放進系統提示裡，當使用者發訊息時，它會比對哪些 skill 可能觸發——比對到了，就讀取對應 SKILL.md 按步驟執行。
所以 description 不是「寫得優雅」，而是「寫得涵蓋全面」。
2）SKILL.md 建議結構
- frontmatter（name/description）
- 觸發後第一步做什麼
- 步驟（最好可執行、可重現）
- 輸出格式（固定範本）
- 錯誤處理（一定要寫）
3）練手建議：先寫一個 IP 查詢 Skill
像「IP 歸屬地查詢」這種 skill 特別適合新手練手：觸發簡單、步驟明確、輸出固定、錯誤也容易處理。
寫 skill 時一個原則：先手動跑通流程，再把流程寫成 skill。這樣成功率最高。
六、多管道接入：讓 AI 隨時在線，但不亂說話
多管道接入的重點不是「接得多」，而是兩件事：
- 來源控制：
allowFrom一定要收緊（伺服器／使用者／頻道） - 格式適配：不同平台對 Markdown 支援不同（尤其表格）
如果你同時用 Discord + Telegram，建議在 AGENTS.md 裡寫「平台格式規則」：
- Discord：表格、程式碼區塊都 OK
- Telegram：表格不穩定，盡量用清單替代
- WhatsApp：基本上當純文字處理
七、設定速查表：常用參數怎麼調更穩
這一章我只保留我認為「收益明顯」的幾個點，避免你一上來就被設定淹沒。
1）blockStreaming：長回覆別等到最後一口氣
讓 AI 把長回覆分段送出來，體驗更像「即時打字」。
建議：
blockStreamingDefault: "on"minChars: 200（太小會洗頻）maxChars: 1500（太大會失去串流的意義）
2）ackReaction：先給你一個「我收到了」的回饋
尤其在 Discord／Telegram 這種即時通訊裡，很重要。不然你會以為它掛了。
3）compaction + memoryFlush：聊再久也盡量不丟關鍵資訊
你只要記住一句：壓縮前先寫檔案。這就是 memoryFlush 的意義。
4）Heartbeat activeHours：別半夜打擾你
如果你開啟了心跳巡檢，建議設定 activeHours，例如 08:00–23:00。這樣它不會在你睡覺的時候發訊息。
最後：建議的設定順序（省時間版）
如果你不想一次全做，按這個優先順序來，最穩：
AGENTS.md：啟動流程 + 記憶規範 + 安全邊界- 開啟
memoryFlush（對話再長也不容易丟關鍵點） - 設定
ackReaction（體驗立刻變好） - 開
blockStreaming（長輸出更舒服） - Heartbeat 加
activeHours（不打擾） - 再考慮 Cron、子 Agent、Skill、多管道（按需上）