build-your-own-openclaw：用 18 個步驟拆解一個 AI agent 的內部構造
A step-by-step guide to build your own AI agent.
秒懂
- 它是什麼？
- 這是一份以 Python 撰寫的教學專案，把 OpenClaw 這類 agent 從聊天迴圈一路拆到事件驅動、多 agent 派工與長期記憶。它的價值在於順序與可執行性，不在於拿來當 production 框架。
- 適合誰用？
- 想理解 agent 內部構造、願意照著步驟從 00-chat-loop 一路做到 17-memory 的工程師，這個專案值得投入；只想找現成框架直接接上自家系統的人則不適合，因為每一階段的程式碼是教學產物，不是維運成品。動手前先確認 default_workspace/config.example.yaml 的欄位能否對上你手上的 LiteLLM provider，再確認 09-channels 與 10-websocket 這兩個步驟所需的對外連線在你的環境裡是否可行。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 70 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這個教學要解決的是「agent 內部長什麼樣」而不是「怎麼用 agent」
多數人第一次接觸 AI agent 是從框架的文件開始，看到的是 AgentExecutor、Tool、Memory 這些已經封裝好的名詞，卻很難說出一次對話在程式裡實際經過哪些函式。這個專案把順序倒過來：先給你一個只有聊天迴圈的 00-chat-loop，再逐步加上工具、技能、持久化，每一階段的 README 說明該步驟的關鍵元件與設計取捨，並附上可直接執行的程式碼。README 把它描述為「18 progressive steps」，目標是做出 OpenClaw 的精簡版本。
它的讀者輪廓相當明確：已經會寫 Python、想搞清楚 agent 的訊息流與狀態存放位置的人。如果你只是想在自己的服務裡接一個會呼叫工具的模型，這個專案不會替你省下時間，反而會讓你多讀十幾個目錄。
從聊天迴圈到事件驅動：四個階段各自在換掉什麼
README 把 18 個步驟切成四期。Phase 1（步驟 0 到 6）是單一 agent 的能力堆疊，依序是 chat loop、tools、skills、persistence、slash commands、compaction、web tools。這一段的軸線是「同一個迴圈不斷長出東西」：工具讓模型能作用於外部，SKILL.md 讓能力以檔案形式擴充，persistence 把對話存下來，compaction 處理歷史過長，web tools 讓 agent 取得外部資訊。
Phase 2（步驟 7 到 10）換掉的是執行模型本身。07-event-driven 把 agent 從 CLI 裡解放出來，08-config-hot-reload 讓設定改動不必重啟，09-channels 把入口延伸到手機，10-websocket 提供程式化互動。這四步合起來意味著一件具體的事：agent 不再是一個前景執行的程式，而是一個等待事件的服務。
Phase 3（步驟 11 到 15）處理的是「誰來決定做什麼」：multi-agent-routing 負責分派，cron-heartbeat 讓 agent 在無人觸發時也能工作，multi-layer-prompts 疊出更多上下文，post-message-back 讓 agent 主動發話，agent-dispatch 則讓 agent 之間互相派工。Phase 4 只有兩步，16-concurrency-control 與 17-memory，對應的是同時執行過多任務與長期記憶這兩個在真實使用中才會浮現的問題。
值得注意的是這個排序本身帶有主張：併發控制與記憶被放到最後，說明作者認為它們是規模化之後才需要面對的議題，而不是一開始就該引入的抽象。
啟動方式與設定檔的位置
README 給的起步指令只有一行：
cp default_workspace/config.example.yaml default_workspace/config.user.yaml
複製之後編輯 config.user.yaml 填入 API key。模型供應商走 LiteLLM，README 指向 LiteLLM providers 文件作為完整清單，並另外提供 PROVIDER_EXAMPLES.md 舉例。這代表設定檔的欄位設計與 LiteLLM 的 provider 命名綁在一起，換供應商時改的是設定而非程式。
README 對使用方式的說明就停在這裡，接下來是「just follow each steps, read and try it out」。沒有列出各步驟的執行指令，也沒有說明依賴安裝方式，實際的啟動命令必須進到各個步驟目錄的 README 才會看到。這在教學專案裡是合理的安排，但如果你期待一份從 clone 到跑起來的單一路徑，會需要自己在目錄之間跳。
compaction 與記憶是兩個不同層次的問題
05-compaction 與 17-memory 相隔十幾個步驟，處理的卻常被混為一談。compaction 出現在 Phase 1，位置緊接在 persistence 與 slash commands 之後，處理的是單一對話歷史過長時怎麼壓縮後繼續。17-memory 則被放在最後一期，與併發控制並列，處理的是跨對話、跨時間的資訊保留。
這個切法有實際後果：如果你只做到 Phase 1，agent 記得的是「這次對話裡發生過什麼」；要做到 17-memory 之後，agent 才可能記得「上次對話裡發生過什麼」。把這兩件事分開，也讓每一階段的程式碼維持在可讀的規模，不必在第三步就引入向量儲存之類的基礎設施。
教學專案的邊界：它不是框架，也沒有版本可鎖
這個 repository 沒有檢索到任何 release。也就是說沒有版本號可以寫進 requirements，沒有 changelog 可以對照升級影響。你要採用它的方式只能是鎖定某個 commit，或是在自己的 fork 裡維護。
另一個邊界來自它的目的。README 說每個步驟「is implemented in a separate session」，這句話同時說明了它的組織方式與它的限制：步驟之間是漸進的教學路徑，不是可以互相替換的模組。你不會從 11-multi-agent-routing 直接取一段程式碼接到自己的服務上，因為那一步預設了前面十步建立起來的訊息流與設定結構。
還有一個無法從現有材料確認的點：Phase 2 之後的步驟牽涉對外通道與 websocket，這些在受管控的網路環境裡不一定能通。README 沒有提供替代方案，這是採用前必須自己確認的事。
對照 LangGraph 這類框架，差別在於誰決定抽象層
拿 LangGraph 這類 agent 框架來對照最清楚。框架一開始就給你狀態圖、節點、邊這些抽象，你把自己的邏輯填進去，好處是省掉重新發明訊息傳遞與狀態管理的功夫，代價是你得先接受它的心智模型。
這個專案走的是相反的路：抽象是過程中長出來的。你先寫一個聊天迴圈，等它不夠用了才在 07-event-driven 換成事件驅動，等同時執行的任務太多才在 16-concurrency-control 處理併發。副作用是你會很清楚每個抽象為什麼存在，因為你經歷過它不存在時的狀態。
如果你已經在用框架，這個專案不會取代它，但可以當成對照組：讀到 05-compaction 時，你會知道自己框架裡的歷史壓縮是在哪一層發生的。
授權與後續維護成本
專案採用 MIT 授權，這是寬鬆授權，允許修改與再散布，通常只要求保留著作權聲明與授權條款。實際的條款文字與適用範圍仍以 repository 內的 LICENSE 檔案為準，這裡不構成法律意見。
維護成本主要落在兩處。一是上游依賴：模型供應商透過 LiteLLM 接入，供應商的 API 變動會反映在設定與呼叫層。二是專案本身沒有 release 週期，你不會收到升級通知，也就無從判斷何時該同步上游的修正。若你打算把某一步的程式碼帶進正式系統，把它視為自己維護的程式碼會比視為依賴更貼近現實。
編輯結論
想理解 agent 內部構造、願意照著步驟從 00-chat-loop 一路做到 17-memory 的工程師，這個專案值得投入；只想找現成框架直接接上自家系統的人則不適合，因為每一階段的程式碼是教學產物，不是維運成品。動手前先確認 default_workspace/config.example.yaml 的欄位能否對上你手上的 LiteLLM provider，再確認 09-channels 與 10-websocket 這兩個步驟所需的對外連線在你的環境裡是否可行。
社群筆記