多租戶不能只開容器，先定義 cell
DEV 上看到一篇講 OpenClaw 多客戶 production hosting 的文章，我覺得蠻值得看，尤其是已經把 OpenClaw 拿來跑真工作流的人。
它最有用的不是 checklist 本身，而是把單位從 process 換成 client cell。這個觀念我最近也踩過。
我本來的想法很直覺：一個客戶一個 runtime，一組 env，一個 workspace，出事就 restart。後來發現這只是在管 process，不是在管 workflow。真正會壞的東西常常不是 runtime 掛掉，而是 browser session 過期、OAuth scope 不對、memory 混到舊任務、或某個外部動作已經送出但 local state 沒記到。
我現在會把每個 cell 拆成這幾層看：
client_cell:
runtime: openclaw process and config
state: workspace, checkpoints, artifacts
identity: email, chat, oauth, browser profile
budget: ram, cpu, concurrency
recovery: retry, rollback, handoff
owner: human approver
這篇文章提醒我一個 caveat：隔離不只是 container。container 可以隔 CPU 和 file system，但隔不了你沒有明確建模的東西。像 queues、scheduled jobs、browser cookies、外部 action receipt，這些如果還是散在 operator 腦袋裡，租戶邊界其實是假的。
我最認同的是 recovery 要按 side effect 分類。
讀資料失敗可以 retry。產生 draft 失敗可以重跑。可是 submit form、send email、改 CRM record 這種操作，不能單純看到 error 就再跑一次。我的做法是把 external action 都包一層 receipt：
external_action:
idempotency_key: task_id plus step_id
target: gmail_draft
status: created
receipt: provider_object_id
這樣 crash 之後至少能回答：剛剛到底做了沒？能不能安全重試？要不要丟給人看？
還有 health check 也不能只看 process alive。OpenClaw process 還活著，不代表 agent 能登入工具、能讀 workspace、能繼續 task、能安全處理外部副作用。真的要上 production，我會分四層看：infra、runtime、dependency、task progress。
這篇比較像一份 operator 心智模型。不是叫你一開始就上完整 fleet control plane，而是提醒你：當第二個客戶出現時，很多原本可以靠手動記住的東西，就會變成事故來源。
如果你現在的 OpenClaw setup 已經開始接真工作，我會先補三個東西：每個 workflow 的 side effect 分級、每個 cell 的 credential/browser 邊界、以及 blocked state 的 handoff 格式。這三個比再多開幾台 VM 有用多了。
作者：Jesse