Clawith：把 AI agent 當成有記憶、有排班、有組織架構的數位員工
Your First AI Agents Company
秒懂
- 它是什麼？
- Clawith 是 Apache-2.0 授權的開源多 agent 協作平台，用 Python 寫成，每個 agent 有自己的 soul.md、memory.md 與私有檔案系統。它要解決的不是「怎麼叫模型回答」，而是「怎麼讓一群 agent 在同一個組織裡持續工作」。
- 適合誰用？
- Clawith 適合已經有明確組織分工、需要多個 agent 長期在線並互相傳訊的團隊，例如要讓 agent 各自盯一個服務、用 webhook 接 CI/CD 事件、再透過 Plaza 交換脈絡。只想做單輪問答或輕量 RAG 的人不需要它，因為你仍然得付 PostgreSQL、Node.js 20+ 與 Python 3.12+ 的維運成本。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 20 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Clawith 要解的問題：agent 沒有身分，也沒有班表
多數 agent 框架處理的是一次任務：給定輸入，呼叫工具，回傳結果，然後狀態歸零。Clawith 的 README 把差異寫得很直白，它給每個 agent persistent identity、long-term memory 和 its own workspace，再讓它們像一個 crew 一樣協作。這代表它的設計目標不是單次推論品質，而是跨對話的一致性。
具體落地的形式是每個 agent 有一份 soul.md 當人格設定，一份 memory.md 當長期記憶，加上一個私有檔案系統與沙箱化的程式執行環境。README 強調這些內容 persist across every conversation。對使用者的意義是：你調校一個 agent 的行為時，調的是檔案，不是 prompt 模板。
它的對象寫得也很清楚，README 用 digital employees of your organization 來描述 agent，說每個 agent 都理解完整組織圖，能傳訊、能轉派任務。所以 Clawith 假設你有一個組織，而不是一個聊天視窗。
Aware：agent 自己決定什麼時候醒來
Clawith 最具體的機制叫 Aware，README 稱它為 agent 的自主意識系統，運作方式是 agent 主動感知、決策、行動，而不是被動等指令。這裡有兩個關鍵設計。
第一個是 Focus Items。agent 維護一份結構化工作記憶，記錄自己正在追蹤什麼，狀態用 `[ ]` 表示 pending、`[/]` 表示 in progress、`[x]` 表示 completed。第二個是 Focus-Trigger Binding，規則很硬：任何與任務相關的 trigger 都必須有對應的 Focus item。agent 先建立 focus，再用 `focus_ref` 設定引用它的 trigger；focus 完成時，agent 取消自己的 trigger。
這條規則解決的是排程孤兒問題。如果 trigger 可以脫離任務存在，系統跑久了就會累積一堆沒人記得為什麼存在的定時工作。把 trigger 綁在 focus 上，等於讓每個排程都有可追溯的來源與結束條件。代價是 agent 必須先想清楚要追蹤什麼，才能排程，這對只想「先跑起來看看」的人是額外的前置負擔。
README 把這個模式總結為 the human assigns the goal; the agent manages the schedule。這句話也是它最大的風險所在，因為排程權在 agent 手上。
六種 trigger 類型與 Reflections 檢視窗
Aware 提供六種觸發方式，各自對應不同的外部事件來源。`cron` 是週期性排程，`once` 在指定時間觸發一次，`interval` 每 N 分鐘執行，`poll` 監控 HTTP 端點，`on_message` 在特定 agent 或人類回覆時喚醒，`webhook` 接收外部 HTTP POST 事件，README 舉的例子是 GitHub、Grafana、CI/CD。
這組清單透露了 Clawith 的實際使用場景：它不是拿來做對話的，是拿來接監控與交付流程的。`poll` 與 `webhook` 的並存也說明設計者知道不是每個系統都能發 webhook，有些只能被動輪詢。
Reflections 則是一個專門的檢視畫面，顯示 agent 在 trigger 觸發的 session 中自主推理的過程，工具呼叫細節可以展開。對維運者來說這是必要的，因為當 agent 自己建立與取消排程時，你需要一個地方回答「它為什麼在那個時間點做了那件事」。README 沒有說明 Reflections 的保存期限或匯出方式，這是要自行確認的部分。
從 setup.sh 到 restart.sh：部署的實際形狀
Clawith 的安裝是一條指令。README 給的流程是 `git clone https://github.com/dataelement/Clawith.git`，進入目錄後執行 `bash setup.sh` 安裝正式環境的執行期依賴，約一分鐘；或 `bash setup.sh --dev` 額外安裝 pytest 與測試工具，約三分鐘。
這支腳本做五件事：從 `.env.example` 建立 `.env`；設定 PostgreSQL，若已有實例就沿用，否則自動下載並啟動本地一份；安裝後端依賴，用 Python venv 加 pip；安裝前端依賴，用 npm；建立資料表並寫入初始資料，包括預設公司、模板、技能。啟動則用 `bash restart.sh`。
要接自己的資料庫，必須在跑 `setup.sh` 之前先建好 `.env` 並設定 `DATABASE_URL`，README 給的格式是 `postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable`。注意驅動是 asyncpg，不是 psycopg。
前置條件是 Python 3.12+、Node.js 20+、PostgreSQL 15+，測試時可用 SQLite。README 也明確說明 Clawith 不在本地跑任何模型，所有 LLM 推論都由外部 API 供應商處理，本地部署就是一個標準的 web 應用加 Docker 編排。硬體建議從 1 核 2 GB 的個人試用一路列到 4 核以上、8 GB 以上的正式環境。
組織級控制與它的代價
Clawith 把企業功能放在相當前面的位置：多租戶 RBAC 做組織隔離與角色存取；每個 agent 可以有自己的 Slack、Discord 或 Feishu/Lark bot 身分；用量配額包含每使用者訊息上限、LLM 呼叫上限、agent TTL；approval workflows 讓危險操作先送人工審核再執行；audit logs 與 knowledge base 提供追溯與共用企業脈絡，README 說知識庫內容會自動注入。
agent TTL 這個設計值得單獨看。它意味著 agent 不是永久資源，會到期。這對成本控制有用，但也代表長期存在的 agent 需要續期機制，而 README 沒有說明 TTL 到期後記憶與 focus 狀態如何處理。
自我演化能力是另一個要留意的點。README 說 agent 可以在執行期發現並安裝新工具，來源是 Smithery 與 ModelScope 的 MCP，也能為自己或同事建立新技能。這與 approval workflows 放在一起看才合理：執行期安裝工具本質上就是執行期擴張攻擊面，審核流程是配套，不是選配。如果你的部署沒有把 approval 打開，這條能力就是風險而不是功能。
什麼情況下不該用 Clawith
第一個不適合的場景是單一 agent 的問答或文件檢索。Clawith 的價值來自多 agent 之間的傳訊、轉派與 Plaza 上的知識交換，只有一個 agent 時，你付出 PostgreSQL、Node.js 20+、Python 3.12+ 的完整維運成本，換到的是一個比較重的聊天介面。
第二個是無法提供穩定 LLM 端點連線的環境。README 明說所有推論都由外部供應商處理，本地不跑模型。離線或內網隔離環境不是它設計要處理的情況。
第三個是排程必須完全由人控制的情境。Aware 的核心是 agent 自行建立、調整、移除 trigger，README 的措辭是 the agent manages the schedule。如果你的組織要求任何自動執行的變更都得先經過人簽核，這個自主性就是障礙，你得靠 approval workflows 去擋，而那會讓自動化的效益打折。
第四個是資源低於 README 最低建議的環境。2 核 4 GB 是它列出的起步線，低於這條線還想跑多個 agent 容器，README 的建議是退回 SQLite 並跳過 agent 容器，那等於放棄它最主要的特色。
替代方案的差異在哪裡
如果你要的是多 agent 協作，最直接的對照是 LangGraph 這類以圖為基礎的框架。差異在狀態歸屬：LangGraph 把狀態放在你定義的 graph state 裡，由開發者決定每個節點讀寫什麼，流程是程式碼；Clawith 把狀態放在 agent 自己的 memory.md 與 focus 清單裡，流程由 agent 在執行期決定。前者可預測、可測試，後者需要靠 Reflections 事後檢視。
如果需求偏向知識問答而非任務執行，Dify 這類平台的重心在知識庫與工作流編排，agent 的自主排程不是核心。Clawith 的 knowledge base 是注入脈絡的來源之一，不是產品主軸。
如果只是要接 webhook 做自動化，n8n 這類工具更輕，但它沒有 agent 身分與長期記憶的概念，事件處理完就結束。Clawith 的 `webhook` trigger 是喚醒一個有記憶的 agent，讓它把這次事件與之前的 focus 串起來。這個差別決定了你要付多少維運成本。
維護節奏與 Apache-2.0 的含意
從版本紀錄看，Clawith 的發布相當密集：v1.11.4 在 2026-08-24 發布，同一天又出了 v1.11.4-fix.1，標題是 Runtime onboarding and verification hotfix。前一個版本 v1.11.3 是 2026-07-28，主線到修補之間隔不到一個月，而修補當天就到。
這對維運的含意是：升級窗口要留得比月更短。onboarding 與 verification 相關的 hotfix 通常代表首次啟動流程有問題，而這正是你導入時最先踩到的路徑。若你的環境不允許短期內重複升級，得先確認自己能不能接受這個節奏。
授權是 Apache-2.0，允許商用、修改與再散布，附帶專利授權條款，需保留著作權聲明與變更說明。這對企業內部部署相對友善。但要注意兩件事：README 提到的 Smithery 與 ModelScope 上的 MCP 工具是第三方元件，各自的授權與資料處理條款與 Clawith 無關；LLM API 供應商的條款也一樣。這不是法律意見，實際條款請自行或請法務確認。
還有一點要實測而非假設：README 的 Live Demo 在 try.clawith.ai，並自我標註為 open-source feature preview，shared demo environment, not guaranteed stable。要評估穩定性，這個環境不能當依據。
編輯結論
Clawith 適合已經有明確組織分工、需要多個 agent 長期在線並互相傳訊的團隊，例如要讓 agent 各自盯一個服務、用 webhook 接 CI/CD 事件、再透過 Plaza 交換脈絡。只想做單輪問答或輕量 RAG 的人不需要它，因為你仍然得付 PostgreSQL、Node.js 20+ 與 Python 3.12+ 的維運成本。導入前先確認三件事：你的 LLM 供應商端點是否可從部署環境連出；你能否接受 agent 自行建立與取消 trigger；以及 v1.11.4-fix.1 這類 hotfix 的節奏是否符合你的升級窗口。授權是 Apache-2.0，商用與修改都可以，但仍需自行確認第三方 MCP 工具與模型 API 的條款。
社群筆記