第一個 Agent 上線那天，什麼都爛掉了

#上線前我信心滿滿

上一篇我講了為什麼決定組 AI 團隊。這篇講的是——決定之後發生了什麼事。

2026 年 3 月初的某個週末，我花了一整天設定好第一個 agent。Gemini API key 拿到了、systemd timer 設好了、prompt 寫得自認不錯。

我按下 systemctl --user enable openclaw-autopost.timer，心裡想：「明天早上醒來就有新文章了。」

然後我就去睡了。

這是我犯的第一個錯。

---

#災難一：Gemini 帳單 $127.80

醒來打開信箱，看到 Google Cloud 的帳單通知。

$127.80 美金。

我以為我用的是免費額度。結果我從 GCP Console 建的 API key，走的是有計費的 project。Gemini 免費額度只限從 AI Studio 建的 key。

我的 agent 一晚上跑了幾百次 API call（包含重試和除錯），每次都在燒錢。

#教訓

❌ 從 GCP Console 建 Gemini API key → 有帳單
✅ 從 AI Studio (aistudio.google.com) 建 → 免費 1,500 RPD

這個教訓值 $127.80。很貴，但從此之後我再也沒搞錯過。

Safety pattern： 在 gateway 層設硬上限。我們的 OpenClaw Gateway 有 1,500 RPD + 15 RPM 的限制，超過就直接 429。就算 script 寫爛了也不會再爆帳單。

---

#災難二：同一篇文章發了五次

早上起來看 Moltbook，我的 agent 帳號上有五篇幾乎一模一樣的文章。

原因很蠢：timer 設成每小時一次（我以為是一天一次），加上 prompt 裡沒有去重邏輯，所以它每次被觸發就生成一篇差不多的東西。

讀者不會覺得「哇這個帳號好勤勞」。他們會覺得「這是 spam bot」。

#教訓

自動發文系統至少要有這三道防線：

1. 冷卻時間（Cooldown）

COOLDOWN_FILE="$WORKSPACE/last-post-time"
if [ -f "$COOLDOWN_FILE" ]; then
    last=$(cat "$COOLDOWN_FILE")
    now=$(date +%s)
    elapsed=$(( now - last ))
    if [ $elapsed -lt 21600 ]; then  # 6 小時
        echo "冷卻中，跳過"
        exit 0
    fi
fi

2. 標題去重

# 取最近 10 篇標題
recent_titles=$(cat "$WORKSPACE/post-history.json" | \
    jq -r '.[-10:][].title')

# 放進 prompt 裡
DEDUP_INSTRUCTION="以下標題最近已經發過，不要重複：
$recent_titles"

3. 內容指紋

發文前算 hash，如果跟最近 10 篇的相似度太高就丟棄重來。不是完美方案，但夠用。

---

#災難三：回覆留言變成無限迴圈

我加了自動回覆功能：有人留言，agent 就回覆。

問題是——agent 回覆完之後，系統偵測到「新留言」（agent 自己的回覆），然後又觸發回覆。

結果就是一串越來越長的自言自語。

#教訓

對話深度追蹤（Conversation Threading）：

# conversation-threads.json 格式：
# { "post_id": { "depth": 2, "lastReply": "2026-03-05T10:00:00Z" } }

MAX_DEPTH=2  # 最多回覆 2 輪

current_depth=$(jq -r ".\"$post_id\".depth // 0" \
    "$DATA_DIR/conversation-threads.json")

if [ "$current_depth" -ge "$MAX_DEPTH" ]; then
    echo "已達最大對話深度，跳過"
    exit 0
fi

加上批次限制：每次掃描最多回覆 5 則。不管有多少待處理的留言，一次只做 5 個。剩下的等下一輪。

這避免了兩個問題：

1. 無限迴圈
2. 一次回太多被平台判定為 spam

---

#災難四：五個帳號同時被封鎖

MindThread 有多個 Threads 帳號在自動發文。某天早上，五個帳號同時被 Threads 封鎖發文。

原因：所有帳號的排程太接近（都是整點觸發），行為模式一模一樣，被平台的反 spam 系統抓到。

#教訓

排程要像人，不要像機器。

# 不要這樣：
OnCalendar=*-*-* 09:00:00
OnCalendar=*-*-* 12:00:00

# 要這樣：
OnCalendar=*-*-* 09:00:00
RandomizedDelaySec=300  # 隨機延遲 0-5 分鐘

另外，我們加了 Account Health Monitor：

# 每 6 小時掃描一次所有帳號
# 用 container creation API 測試帳號是否正常
# 如果被封鎖 → 即時 Telegram 通知老闆

if [ "$status" = "blocked" ]; then
    curl -s -X POST "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
        -d "chat_id=$BOSS_CHAT_ID" \
        -d "text=⚠️ $account_name 被封鎖發文！"
fi

被封鎖不可怕，可怕的是被封了你不知道，帳號就在那邊空轉。

---

#災難五：新部署時所有歷史文章都被當新文

我有一個 blog-to-social.sh script，功能是偵測新的部落格文章，自動發到 Moltbook。

邏輯是：掃描 content/blog/ 目錄，如果有文件比上次掃描時間新，就當作新文章發出去。

問題是——第一次部署時沒有「上次掃描時間」。所以它把所有 60+ 篇歷史文章都當成新文，一次全部發出去。

Moltbook 一個早上收到 60 篇來自同一個帳號的文章。

#教訓

First-Run Safety Pattern：

LAST_RUN_FILE="$DATA_DIR/blog-to-social-lastrun"

if [ ! -f "$LAST_RUN_FILE" ]; then
    echo "首次執行，建立基準線（不處理歷史文章）"
    date +%s > "$LAST_RUN_FILE"
    exit 0
fi

第一次執行時，只建立時間戳，不做任何事。從第二次開始才正常運作。

簡單到不行，但如果沒想到就會出大事。這個 pattern 我現在每個新 script 都會加。

---

#災難六：Token 過期了系統不知道

這個 bug 我們最近才修好（就在寫這篇文章的前一天）。

Threads API 的 token 有效期 60 天。我們有自動刷新機制——但它只看「理論上還剩幾天」，不會實際驗證 token 是否有效。

結果 Facebook 因為安全原因提前讓某些 token 失效，我們的系統算了一下「還有 17 天，不用刷」就跳過了。3 個帳號空轉了 4 天我才發現。

#教訓

不要只算天數，要實際驗證：

def validate_threads_token(access_token):
    """驗證 token 是否真的有效"""
    r = requests.get(
        "https://graph.threads.net/v1.0/me",
        params={"fields": "id", "access_token": access_token},
        timeout=10,
    )
    if r.status_code == 200 and "id" in r.json():
        return True, "ok"
    return False, r.json().get("error", {}).get("message", "unknown")

現在我們的 token refresh worker 會：

1. 先看天數（快到期就刷新）
2. 再看 health 資料（有 API 報錯就刷新）
3. 刷新失敗就發 Telegram 通知，讓我手動處理

雙重防線，不再有盲區。

---

#踩坑之後的自動化哲學

這些災難教會我一件事：

自動化不是「設好就不管」，是「設好然後建監控」。

每一個自動化流程，都應該有對應的：

流程	監控
自動發文	冷卻時間 + 去重 + 帳號健康檢查
自動回覆	深度限制 + 批次限制
Token 刷新	天數 + 實際驗證 + 失敗通知
內容同步	First-run safety + 基準線建立
整個系統	Health monitor + Telegram 告警

我現在的原則是：寫完一個自動化 script 之後，花同樣的時間寫它的安全機制。 如果你覺得「不會出錯吧」——那它一定會出錯。

---

#所有 Safety Patterns 彙整

Pattern	解決什麼	核心概念
Gateway 硬上限	帳單失控	在入口處攔截，不信任下游
Cooldown File	過度發文	時間鎖，強制最小間隔
標題去重	重複內容	帶歷史進 prompt
Max Depth Threading	回覆迴圈	追蹤對話深度
RandomizedDelay	被封鎖	讓行為看起來像人
First-Run Safety	歷史爆發	首次只建基準線
Atomic Lock (mkdir)	競態條件	POSIX 保證的原子操作
Health Monitor	靜默失敗	主動偵測 + 即時通知
Token 雙重驗證	盲區	理論 + 實際都要檢查

這些 pattern 全部開源在 openclaw-playbook。可以直接拿去用。

---

#下一篇

踩完坑、建完安全機制之後，我開始認真思考一個問題：怎麼讓 agent 不只是重複我教它的東西，而是真的「有腦」地產出內容？

答案是給它情報。讓它每天自動做市場研究、讀最新趨勢、分析競品——而且完全免費。

下一篇：零成本情報系統：讓 AI 每天幫你做市場研究

---

這是「一人公司的 AI 團隊」系列第 2 篇。第 1 篇：我為什麼需要 AI 團隊

所有原始碼：GitHub — openclaw-playbook