外部工具接越多，越要先畫失敗邊界
最近看到有人在講，OpenClaw 一開始要先把外部工具接起來，不然它就只是個會聊天的殼。這句話只說對一半。
工具接起來當然重要，但以前做過 backend 的人大概都知道，真正把人拖垮的從來不是 integration 本身，是 integration 後面那串沒人想先做的東西。timeout 幾秒，重試幾次，失敗後退回哪個 fallback，權限範圍切到哪裡，log 要留到哪一層。這些不先定，功能越多，debug 面積只會一起膨脹。
我踩過的坑很簡單。某次把 mail、calendar、internal CRM 一次接進 agent flow，demo 很順，到了第二週開始出事。calendar API 偶發 9 秒才回，worker timeout 設 8 秒，前面一層又自動 retry 3 次，最後 queue 卡滿，後面的任務全部跟著延遲。表面上看是「某個工具偶爾慢」，實際上是整條鏈根本沒有 backpressure。這種 pattern 很常見。單點看都能跑，串起來就炸。
所以我現在反而會先看 4 個東西。
第一，failure boundary 有沒有切清楚。某個 tool 掛掉時，是只影響那一步，還是整個 workflow 一起陪葬。
第二，權限邊界 有沒有收斂。讀 email 跟代發 email，不是同一級風險。能 read 就不要 write，能限定 folder 就不要開整個 inbox。
第三，observability 有沒有到位。至少要看得到每一步 latency、error code、重試次數。沒有 tracing，出事時你只會看到 agent 很笨，其實笨的是你自己沒埋資料。
第四，fallback 是不是真的能用。不要把 fallback 寫在簡報裡。真的去跑一次，把 primary 人工拔掉，看 30 秒內能不能切到次要路徑。切不過去，那就不叫 fallback。
我現在帶 team 做這種東西，通常會先把 timeout 壓在 5 到 8 秒，單步 retry 最多 2 次，超過就熔斷 30 秒，並且把同類工具 worker 數先鎖在 4 個以下。先保守，先看數據，再放大。因為 production 裡最貴的不是工具沒接好，是你以為它接好了。
所以結論很直接。新手如果只顧著把 OpenClaw 接到更多外部系統，通常只是把未來的 incident 排進行事曆。先把失敗邊界畫清楚，再談能力擴充。這東西 production 能跑嗎？先回答這句。
作者：鍵盤工人