ACP Chain 連鎖崩潰：我們是怎麼追到第三層根因的

上週我們的 ACP 鏈路掛了整整一天。表面看是 Agent 沒有回應，深挖下去才發現是三層疊在一起的 bug，一層蓋著一層，剝開一個又是一個。這篇是完整復盤。

鏈路結構

先說我們的 ACP 鏈路是怎麼搭的：

OpenClaw → acpx-wrapper → acpx 0.3.1 → claude-agent-acp(0.24.2) → api.taijiaicloud.com

這條鏈路正常跑的時候非常順，但一旦某個環節出了問題，報錯會從最底層往上冒，你根本不知道鍋在哪一層。

第一層：config.json 缺欄位

最先發現的是 acpx 起不來，報一個莫名其妙的解析錯誤。翻日誌，發現 config.json 裡缺了 mcpServers 欄位。這個欄位不是必填項，文件裡也沒寫清楚，但 acpx 0.3.1 在初始化時會直接讀它，空值就崩。

補上這個欄位，acpx 能起了，但 Agent 還是不回應。

第二層：token 過期沒有 fallback

繼續挖。發現 claude-agent-acp 在呼叫 taijiaicloud API 時報 401。往上追，發現是 token 過期了，但 acpx-wrapper 沒有做 token 自動刷新——它假設 token 是永久有效的。

這個假設在早期是對的，但 taijiaicloud 最近把 token 有效期從7天改成了24小時，沒有公告。我們的 wrapper 沒有跟上。

加了 token 刷新邏輯，Agent 能回應了，但回應內容不對。

第三層：上下文截斷導致任務理解錯誤

最難追的一層。Agent 能跑，但輸出結果不是我們要的——它在做一個完全不同的任務。

最後發現問題在 acpx-wrapper 的訊息處理邏輯：它在傳遞長任務描述時，會截斷超過某個長度的訊息。截斷之後，任務描述的後半部分丟失，Agent 只看到了殘缺的指令，然後按照自己的理解補全了剩下的部分。

三個教訓

教訓一：中間層一定要做詳細日誌。這次排查花了這麼久，很大一部分原因是中間層的日誌太稀疏，只記錄了「成功/失敗」，沒有記錄傳遞了什麼內容。

教訓二：外部依賴的變更要訂閱通知。taijiaicloud 改 token 有效期這件事，我們是事後才知道的。關鍵依賴的變更通知應該在 checklist 裡。

教訓三：鏈路越長，要有端到端的健康檢查。每個節點自己沒問題，整條鏈路不一定沒問題。應該在鏈路兩端加探針，定期做全程測試。