第 1 天：我想跟一個 AI Agent 認識，先從 OpenClaw 開始

開場故事

如果你今天不是在跟一個「聊天模型」說話，而是在跟一個真的會做事、會分派工作、會記得昨天發生什麼事的 AI Agent 互動，你第一個問題通常不會是「你有多聰明」，而會是：

• 你怎麼知道自己現在要做什麼？
• 你怎麼知道這件事該找誰做？
• 你怎麼不會每次講完就忘記前面說過什麼？

我在寫這 30 天系列時，心裡想的就是這三個問題。

OpenClaw 對我來說，最有趣的地方不是它會回答，而是它很像一個真的有組織、有分工、有紀律的系統。它不是單純把模型包成一個 API 而已，而是把「接任務、分工、做事、記錄、重整」整套流程串起來。你可以把它想成一個小型國度，也可以想成一間正在運轉的公司，甚至可以想成一支有主帥、有軍團、有軍火庫的隊伍。

所以第 1 天我不想急著鑽進細節。我想先做一件比較重要的事：先把整體架構看懂。

因為如果你一開始就只盯著某一段程式碼，很容易會看成一堆零件；但如果你先知道它整體是怎麼活的，後面再看任務分派、工具調度、記憶管理、子代理協作，你就會知道每一塊為什麼要存在，也知道它們彼此在解什麼問題。

這篇就是這個起點。

今天要解的問題

• OpenClaw 在整體架構裡扮演什麼角色？
• 為什麼它不是單一聊天機器人，而是多層次的系統？
• 一個任務從進來到完成，中間經過哪些關卡？
• 為什麼要把 Agent、Skill、Cron、Memory 分開？
• 第 1 天要先建立什麼樣的腦中地圖，後面 29 天才不會迷路？

架構總覽

我先用最白話的方式講。

OpenClaw 不是「一個會聊天的東西」，而是「一個會處理工作流程的系統」。

當使用者丟進來一個需求，OpenClaw 不是直接把這句話送給模型然後等答案，而是先判斷：

1. 這個需求是什麼類型？
2. 要不要拆成多段？
3. 要交給哪個 Agent？
4. 需要用哪些 Skill？
5. 要不要查記憶？
6. 做完之後要不要寫回記錄或發送通知？

你可以把它想成一個有指揮官的作戰中心：

• main 是接令和總指揮的人
• 各個 Agent 是不同職能的兵種
• Skill 是已經打磨好的工具和戰法
• Cron 是固定時間會自動響起的軍令
• Memory 是它的工作日誌和長期記憶

這幾個東西分開之後，系統就不會全部糊在一起。今天想改任務分派，不必去碰工具實作；今天想改排程，不必重寫對話邏輯；今天想補一個新的知識流程，也不必把整個系統拆掉重來。

這就是 OpenClaw 的第一層價值：它不是只會做事，而是能把事情做成制度。

一個任務大概怎麼流動

你可以先把流程想成這樣：

使用者需求
  -> main 先接住
  -> 判斷任務種類
  -> 必要時拆分工作
  -> 指派給適合的 Agent
  -> Agent 再挑選適合的 Skill
  -> 執行任務
  -> 回報結果
  -> 寫入記憶 / 觸發後續流程

如果把它翻成日常語言，就是：

• 先有人聽懂你在講什麼
• 再決定這是不是一件可以立刻處理的事
• 如果不是，就拆開
• 如果不是一個人能做，就找別人幫忙
• 如果是固定模式的事情，就用現成工具
• 做完還要留下痕跡，方便下一次接續

這其實跟人類組織很像。

你不會期待老闆自己去印文件、跑流程、改表單、催進度、寫紀錄；你期待的是老闆知道該找誰，然後整個團隊各自把事情做好。OpenClaw 也是這種思路，只是它把這件事做成了系統。

原始碼節錄

這一篇我先不貼太多程式碼，因為第 1 天重點是看整體圖，而不是鑽細節。不過從目前的文件內容，你其實可以先抓到幾個關鍵概念：

- main：總指揮，負責接令與決策
- Agent：不同職能的兵種
- Cron：定時巡邏、定時產出、定時提醒
- Skill：可重複使用的工具與戰法
- Memory：長期知識與工作紀錄

這段看起來很像分類表，但它其實就是 OpenClaw 的核心設計。

如果你只把它看成名詞列表，很容易覺得「這不就是把功能拆一拆嗎？」但實際上，它拆的是責任邊界。每一個名詞都代表一種不同的變更頻率：

• main 和 Agent 的決策邏輯，會跟任務類型一起變
• Skill 是流程封裝，會跟實際操作方式一起變
• Cron 是時間驅動，會跟生活節奏和維運需求一起變
• Memory 是知識沉澱，會跟累積內容一起變

把這些都放在一起，系統就會越來越難維護；把它們分開，才有辦法持續長大。

白話拆解

我很喜歡用一個比喻來理解 OpenClaw：它像一間會自己開會的公司。

1. main 像總經理

總經理不一定親自做每件事，但他要知道：

• 現在進來的是什麼案子
• 這案子是不是可以直接做
• 需要誰來做
• 做完要怎麼收尾

OpenClaw 的 main 也是這樣。它不是一個只會回答的角色，而是整個系統的入口。它先把需求接住，再決定後續流程。

2. Agent 像不同部門

有些人擅長研究，有些人擅長開發，有些人擅長整理文件，有些人擅長排程，有些人擅長資訊監控。

這些能力如果都塞給同一個角色，系統會很快變得臃腫。你會發現它什麼都能做，但每件事都做得不穩。

所以 OpenClaw 把能力拆開，讓每個 Agent 專注在自己的職能上。這樣的好處是：

• 任務路徑更清楚
• 工具選擇更穩定
• 問題比較容易定位
• 後續擴充也比較不會互相打架

3. Skill 像標準作業流程

如果 Agent 是人，Skill 就像 SOP。

不是每次都重新發明輪子，而是把一件事做熟、做穩、做可重複之後，包成一套可以再次使用的流程。

例如：

• 寫文件
• 發通知
• 建排程
• 做摘要
• 安裝或發佈某種能力

這些事情如果每次都臨場處理，會很花時間，也很容易出錯。Skill 的存在，等於是把經驗封裝起來，讓下一次可以直接拿來用。

4. Cron 像固定鬧鐘

有些工作不是有人叫才做，而是每天、每週、每隔幾小時就要固定處理。

這就是 Cron 的角色。

它代表 OpenClaw 不只是被動回答，而是主動運轉。它會在時間到的時候自己跑起來，提醒、巡邏、摘要、整理、寄信，像一個不會忘記打卡的同事。

5. Memory 像長期工作筆記

如果一個 AI 系統每次都從零開始，它就永遠只能做短跑。

Memory 讓它有機會把重要的內容留下來，讓後一次能接續前一次。當然，記憶不是越多越好，而是要記對東西。這也是為什麼後面章節我會一直在看「什麼該記、什麼不該記」。

因為一個真正成熟的系統，不是記憶最大，而是記憶有用。

設計取捨

OpenClaw 這種架構，漂亮的地方很明顯，但它不是沒有代價。

• 好處 1：可以分工，責任很清楚
• 好處 2：可以重用，很多流程不用重寫
• 好處 3：可以排程，系統能自己運作
• 好處 4：可以累積，記憶不會每次歸零
• 好處 5：可以擴充，之後加新 Agent 或新 Skill 會比較順

但代價也很真實：

• 代價 1：初始化成本比較高，不是一個檔案就講完
• 代價 2：跨模組理解比較難，得先知道整個地圖
• 代價 3：流程一多，除錯會變得更像查案
• 代價 4：如果紀錄與排程沒管好，容易堆出一堆雜訊
• 代價 5：角色越多，協調成本就越高

所以 OpenClaw 的方向，不是單純追求「功能很多」，而是追求「能不能持續運作」。

這點很像真的在經營一個團隊。

團隊不是人越多越好，而是分工要對、制度要穩、資訊要流動、責任要清楚。OpenClaw 的設計其實就是把這些管理原則，翻成 AI 系統可以執行的版本。

今天的結論

• OpenClaw 不是單純的聊天機器人，而是一個能跑工作流程的 AI 系統
• main、Agent、Skill、Cron、Memory 各自扮演不同角色，彼此分工明確
• 它的核心價值不是「回答得多漂亮」，而是「能不能穩定完成任務」
• 第 1 天最重要的事情，不是記住所有細節，而是先把整體架構裝進腦袋
• 後面 29 天要拆的，其實都是這張圖上的某一塊

下一步

如果把這 30 天比成一場認識 OpenClaw 的旅行，那第 1 天只是抵達機場。

你還沒真正進到城市裡，只是先看到了它的地圖、交通、分區和節奏。接下來幾天，我會從更細的地方開始看：

• 它的腦袋長什麼樣
• 任務怎麼被接住
• 工具怎麼被叫起來
• 記憶怎麼留下來
• 子代理怎麼合作

第 1 天先到這裡。重點不是看懂每個細節，而是先知道自己接下來要往哪裡走。