作者： xiyu
不想閱讀的，可以直接寄給你的openclaw
一個人+ OpenClaw = 一個管理團隊
用開源AI Gateway 打造一人公司全端管理系統
ai時代以前的單人公司
如果你在經營一人公司或獨立業務，大概是這樣的節奏：上午對帳、下午寫方案、晚上處理合規文件，中間還要回客戶訊息、檢查伺服器狀態、更新資料報表。
你不是在做一份工作，你同時在做五份工作。
大多數人的第一個反應是找個AI 聊天機器人幫忙。 ChatGPT、Claude，確實能回答問題、寫寫文件。但花了一段時間你會發現──聊天機器人解決的是「問答」問題，不是「管理」問題。
你需要的不是一個更聰明的助手，而是一個AI 管理層：能分工、能記住上下文、能自動執行任務、能在該請示的時候請示你。
這篇文章分享我用OpenClaw （一個開源的AI Gateway）搭建一人公司全端管理系統的完整想法和踩坑經驗。不是概念驗證，是實際在跑步的系統。
為什麼是OpenClaw
OpenClaw 的優點：
開源、自託管—— 資料全在自己機器上，不經過第三方
原生多Agent —— 不同Agent 有獨立的人格檔案（ SOUL.md ）、工具權限、記憶空間
Discord 整合－ 頻道就是部門，發訊息就是下指令，天然的管理介面
持久運作－ 不是跑一次就結束的workflow，而是7×24 線上的Gateway
最關鍵的一點：頻道= 部門，訊息= 指令。這個模型自然適合管理場景。你在#accounting頻道說“本月支出匯總”，會計Agent 自動響應；在#ops頻道說“檢查伺服器狀態”，運維Agent 接手。不需要記住任何命令語法，就像給下屬發訊息一樣自然。
多Agent 架構設計
角色分工
我的系統目前規劃了這些角色：
CTO Agent —— 技術負責人，系統架構、程式碼、部署、工具開發
會計Agent —— 記帳、對帳、每月結算、報表生成
業務Agent —— 客戶溝通、訂單追蹤、報價管理
合規Agent —— 法規檢查、文件歸檔、定期掃描
監控Agent —— 系統心跳、異常警報、資源監控
階段化激活
這裡有一個很重要的設計概念：不要一開始就把所有Agent 都啟動。
業務量小的時候，讓CTO 代行會計和合規的職責就夠了。等業務量上來，再逐步拆分：
階段A（起步期）：CTO 一人多職，其他Agent 休眠
階段B（穩定期）：啟動會計+ 合規，CTO 專注技術
階段C（擴展期）：全員上線，各司其職
階段切換可以用定時任務自動偵測觸發條件（例如月交易筆數超過閾值），也可以手動切換。關鍵是架構先搭好，啟動按需來。
頻道路由
#cto -office → CTO Agent
#accounting → 會計Agent
#compliance → 合規Agent
#ops -monitor → 監控Agent
#general → 所有Agent 都能看到，按需回應
OpenClaw 的設定檔裡可以指定每個Agent 監聽哪些頻道。訊息進來後自動路由，不需要手動@。
決策權限矩陣
這是整個系統最重要的設計之一：
護欄內→ Agent 自主執行，事後記錄
護欄外→ Agent 暫停，@老闆請求決策
不確定→ 視為護欄外，寧可多問一次
舉個例子：
記一筆常規支出→ 護欄內，自動執行
刪除一筆資料庫記錄→ 護欄外，必須確認
遇到一個沒看過的稅務分類→ 不確定，上報
關鍵原則：Agent 永遠不應該在不確定的情況下自作主張。 誤操作的修復成本遠高於多問一句的溝通成本。
資料架構
單一資料來源
所有業務資料存在本地SQLite 資料庫裡。為什麼不用MySQL 或PostgreSQL？因為一人公司不需要並發，SQLite 零設定、零運維、一個檔案搞定，備份就是複製檔案。
~/.openclaw/data/main.db
├── transactions # 交易記錄
├── clients # 客戶訊息
├── documents # 文書索引
├── audit_log # 稽核日誌
└── ...
統一操作層
所有資料庫操作必須通過一個統一的操作腳本（例如db_ops.py），禁止直接寫入SQL。好處：
自動審計－ 每次操作自動記錄：誰、什麼時候、做了什麼、改了什麼
格式統一－ 不會出現一個Agent 用這種格式、另一個用那種格式的問題
權限控制－ 在操作層就能攔截越權操作
Notion 鏡像備份
SQLite 是資料來源，但不方便人類瀏覽。所以我用Notion 做視覺化鏡像：
即時同步：關鍵操作（新增交易、狀態變更）觸發即時同步
每日兜底：每天23:00 全量校驗一次，確保沒有遺漏
只讀鏡像：Notion 那邊只看不改，避免雙向同步的惡夢
多語言導出
如果你的業務涉及多語言場景，可以在導出層做語言適配：
db_ops.export_csv() # 中文版
db_ops.export_csv() # 英文版
db_ops.export_csv() # 雙語對照
列名、分類名、狀態標籤都在設定檔裡維護映射表，匯出時自動翻譯。
記憶系統
雙層記憶架構
工作記憶有容量上限（例如200 行），超了就要淘汰。長期記憶理論上無限，但檢索品質會隨著資料量成長而下降，需要定期清理。
遺忘曲線：基於引用日期的過期機制
每個記憶都帶著一個ref（引用日期），記錄它最後一次實際使用的時間。注意：自動載入不算引用，只有在回覆中實際用到才算。
- [2025-01-15][ref:2025-02-20] 供應商A 的付款週期是Net 30
- [2025-01-15][ref:2025-01-15] 某個暫時備忘（一個月沒用到，即將過期）
過期規則：
高優先記憶：ref 超過90 天淘汰
暫時備忘：ref 超過30 天淘汰
核心身分資訊：永不淘汰
置信度評分
不是所有記憶都一樣可信。我給每個記憶加了置信度分數：
來源定價（寫入時）：
用戶親口確認→ 0.95
手動錄入→ 0.85
自動從日誌擷取→ 0.50
時間衰減： ref 超過60 天沒被命中的記憶，信賴度每天×0.95
檢索增強： 每次被搜尋命中，信賴度×1.05（上限0.95）
自動清除： 置信度低於0.1 時刪除
為什麼過時的記憶比沒有記憶更危險
這是一個血淚教訓。沒有記憶，Agent 會說「我不知道」，然後你去查。但如果Agent 記著一條過時的訊息（例如三個月前的價格、已經廢止的規定），它會非常自信地給你一個錯誤答案，而你可能不會去驗證。
過時的記憶是帶毒的緩存。 所以遺忘機制不是可選的，是必須的。
自動化維
定時任務範例
cron:
- name: monthly-settlement
schedule: "0 10 1 * *" # 每月1號上午10點
action: 每月結算總結
- name: compliance-scan
schedule: "0 9 * * 1" # 每週一上午9點
action: 合規掃描
- name: system-healthcheck
schedule: "*/30 * * * *" # 每30分鐘
action: 系統心跳檢查
- name: data-sync
schedule: "0 23 * * *" # 每天23點
action: 資料同步到Notion
- name: memory-cleanup
schedule: "30 23 * * *" # 每天23:30
action: 記憶過期清理
心跳監控
每30 分鐘讓監控Agent 檢查一次系統狀態：Gateway 是否在線上、磁碟空間、資料庫完整性。異常時透過Discord 告警。
自動升級檢測
定期檢查OpenClaw 是否有新版本，有的話通知你，但不自動升級（升級屬於「護欄外」操作）。
安全設計
一人公司的AI 系統，安全設計不能省。因為出了事沒有別人幫你兜底。
敏感操作按鈕確認
所有危險操作（刪除、修改關鍵設定、執行shell 指令）必須彈出確認按鈕：
⚠️ 確認執行？
操作：刪除2024 年歸檔數據
影響：不可恢復
[✅ 確認] [❌ 取消]
不是文字確認，是Discord 的互動組件按鈕。防止Agent 自己「點確認」。
指令白名單+ 分級控制
🟢 自由執行：ls, cat, head, tail, sqlite3 (唯讀)
🟡 需要記錄：python3, node, 寫檔案操作
🔴 需要確認：rm, chmod, 網路請求, 資料庫寫入
⛔ 絕對禁止：sudo, 修改系統檔案, 存取敏感目錄
蜜罐文件檢測
在敏感目錄放幾個「蜜罐檔案」（honeypot）。如果Agent 試圖讀取這些文件，表示它可能被prompt injection 了，立即觸發警告並暫停該Agent。
PII 稽核掃描
定期掃描所有Agent 的輸出日誌，檢查是否意外洩漏了個人識別資訊（PII）。一旦發現，警告+ 自動打碼。
踩坑經驗
Mac 做伺服器的休眠問題
如果你用Mac 跑OpenClaw Gateway，一定要處理休眠問題。 Mac 預設會在空閒時休眠，Gateway 隨之中斷。解決方案：
# 禁止休眠（需要sudo）
sudo pmset -a sleep 0 displaysleep 0 disksleep 0
# 或用caffeinate 保持喚醒
caffeinate -s &
但要注意散熱和電費，長期跑建議上個低功耗的Linux 設備。
exec 權限平衡
給Agent 的exec 權限太大，它可能誤操作搞崩系統；太小，很多自動化任務跑不了。我的經驗是：
預設最小權限
按需開放，每次開放都記錄原因
用白名單而不是黑名單
Gateway 重新啟動後session 斷開
OpenClaw Gateway 重新啟動後，先前的對話session 會遺失。如果你有依賴session 上下文的長任務，要嘛做好斷點續傳設計，要嘛把關鍵上下文寫入檔案。
Notion API 的各種限制
每分鐘請求數有限制（rate limit）
單一block 的文字長度有上限（2000 字元）
不支援某些富文本格式
資料庫屬性類型變更會導致同步腳本報錯
建議：同步腳本要做好錯誤處理和重試邏輯，不要假設API 呼叫一定成功。
配置合併只能追加不能替換
OpenClaw 的設定檔合併邏輯是追加式的，不是替換式的。也就是說，如果你在本地配置和全域配置裡都定義了同一個字段，結果是合併而不是覆蓋。踩過坑之後我學會了：關鍵配置只在一個地方定義，不要分散。
一個人經營一家公司，最大的瓶頸不是能力，而是頻寬。你不可能同時精通會計、法務、技術、業務，還要保證每件事都不出錯。
一個人+ 一套設計良好的AI 系統= 一個完整的管理團隊。
但關鍵字是「設計良好」。這意味著：
權限邊界清晰－ Agent 知道什麼能做、什麼不能做、什麼要問
資料流可追溯－ 每一筆操作都有記錄，出了問題能查
安全不妥協－ 蜜罐、白名單、PII 掃描，一個都不能少
記憶會過期—— 過時的資訊比沒有資訊更危險
階段化演進—— 不貪多，按需激活，保持系統簡單
這不是一個「用AI 取代人」的故事，而是一個「用AI 讓一個人能管住一攤事」的實踐。
系統還在持續迭代中，但核心架構已經穩定跑了一段時間。如果你也在考慮用AI 來管理自己的獨立業務，希望這些經驗對你有用。
技術堆疊：OpenClaw + SQLite + Notion + Discord + Python
適用場景：一人公司、獨立開發者、自由工作者、小型工作室
