當你的帳號被封了，系統比你先知道 — AI Agent 帳號健康偵測實戰
事情是這樣發生的
我們用 MindThread 管理 21 個 Threads 帳號，每天自動發文 35+ 篇。
昨天，我隨手打開 Threads App 檢查其中一個帳號，看到一行字：
「請確認你是真人」
帳號被封鎖了。
但系統完全沒有報錯——API 回 200，排程照跑，只是發出去的東西沒人看得到。
這是自動化最危險的盲區：壞了但看起來沒壞。
問題規模
一個帳號還好，手動檢查就行。
但我們有 21 個帳號。不可能每天一個一個打開 App 確認。
更重要的是——如果一個帳號被封了 3 天你才發現，那 3 天的內容全部浪費，排程也全亂了。
我需要的是：系統自己知道、自己通知我。
解法：Container Creation Probe
Threads API 有個特性：
你可以嘗試「建立一個 container」而不實際發布。正常帳號會回傳一個 container_id，但被封鎖的帳號會回傳：
``
error_subcode: 2207051
error_user_title: "操作已遭封鎖"
一個 API call，就能判定帳號是否被封鎖發文。
`python
def _check_posting_blocked(token, user_id):
r = requests.post(
f'https://graph.threads.net/v1.0/{user_id}/threads',
data={
'media_type': 'TEXT',
'text': 'health_check_probe',
'access_token': token,
},
timeout=15,
)
data = r.json()
if 'id' in data:
return False, 'ok' # 正常
err = data.get('error', {})
if err.get('error_subcode') == 2207051:
return True, '操作已遭封鎖' # 被封
return False, f'other: {err.get("message")}'
`
這段 code 不會真的發文（container 建了但沒 publish），所以可以安全地用來做健康檢查。
架構：Background Worker
把這個邏輯包成一個 Background Worker，跟著主系統一起跑：
執行頻率：每 6 小時掃描一次全部帳號
掃描流程：
1. 載入所有帳號設定
2. 逐一用 Container Creation 測試
3. 記錄結果到 account_health.json（持久化）
4. 比對上次狀態，偵測「新封鎖」
5. 新封鎖 → Telegram 即時通知
關鍵設計：
- 狀態變化偵測：只在 ok → blocked 時通知，不會每 6 小時重複洗版
- 持久化：結果存 JSON 檔，系統重啟後不遺失
- Rate limiting：每個帳號之間間隔 3 秒，避免觸發 API 限流
- Graceful shutdown：支援 stop event，不會卡住主程序
Telegram 即時警報
偵測到封鎖後，系統直接推送到我的個人 Telegram：
`
⚠️ 帳號封鎖警告
以下帳號無法發文：
• rent.calc.tw — 操作已遭封鎖
• tw.salary — 操作已遭封鎖
掃描時間：2026-03-05 18:30
`
從「不知道帳號掛了」到「6 小時內自動發現 + 通知」。
API 支援手動掃描
除了定時掃描，也提供 API 讓你隨時手動檢查：
| 端點 | 用途 |
|------|------|
| GET /api/account-health/status | 查看所有帳號健康狀態 |POST /api/account-health/scan-now
| | 立即執行一次全掃描 |POST /api/account-health/start
| | 啟動定時掃描 |POST /api/account-health/stop
| | 停止定時掃描 |
scan-now 回傳格式：
`json``
{
"success": true,
"total": 21,
"ok": 19,
"blocked": ["rent.calc.tw", "tw.salary"],
"scanned_at": "2026-03-05 18:30:00"
}
這次學到的教訓
掃描完 21 個帳號，2 個被封。它們有共同特徵：
| 特徵 | rent.calc.tw | tw.salary |
|------|-------------|-----------|
| 建立時間 | 3 天前 | 3 天前 |
| 發文頻率 | 每天 3-4 次 | 每天 3-4 次 |
| 結果 | 封鎖 | 封鎖 |
結論：新帳號 + 高頻發文 = 觸發 Threads 自動偵測。
新帳號前 7 天，頻率應該砍半。先養信任度，再逐步加速。
自動化的下一層
大多數人對「自動化」的理解停留在：讓系統幫你做事。
但真正成熟的自動化是：讓系統自己照顧自己。
- 發文自動化 ✅（排程器）
- 回覆自動化 ✅（留言監控）
- 數據自動化 ✅（Insights Worker）
- 健康偵測自動化 ✅（今天加的）
當你管的帳號越來越多，人工巡檢根本不可能。系統必須能自我診斷、自我報告。
這就是 AI Agent 的真正價值——不只是幫你生成內容，而是幫你顧系統、預防問題。
技術摘要
| 項目 | 規格 |
|------|------|
| 偵測方式 | Threads API Container Creation Probe |
| 執行頻率 | 每 6 小時 |
| 通知管道 | Telegram 個人 Chat |
| 持久化 | account_health.json |
| API 端點 | 4 個（status / scan-now / start / stop）|
| 部署方式 | Background Worker Thread（隨主系統啟動）|
MindThread 不只是一個排程工具。它是一整套自動化基礎設施——從內容生成、排程發布、留言回覆，到現在的帳號健康偵測。
每一層自動化，都在把你從「手動管理」推向「系統自治」。
這是我們的方法論。持續在做、持續分享。