如果您曾讓 AI 代理程式針對真實基礎結構執行 — Azure 部署、Terraform 規劃、網路佈建 — 您一定撞過那道牆。您的代理程式觸發一個長時間執行的 CLI 命令，整個主迴圈就陷入黑暗。沒有回應、沒有狀態更新、無法取消。只剩一片寂靜，直到那個網路呼叫決定回來，或永遠不回來。
這是生產 AI 代理程式工作流程中最大的可靠性問題，也是為什麼我一直大力推動在 OpenClaw 內採用 Agent Client Protocol (ACP)。ACP 不會神奇地把慢的作業變快。它做的是把這些作業隔離起來，讓它們無法把您的代理程式一起拖下水。
以下是它的運作方式與設定方法。
ACP 究竟是什麼
Agent Client Protocol 是一項標準，用來讓程式碼代理程式跨不同用戶端（IDE、編輯器、協調器等等）互通。其核心是透過 stdio 上的 JSON-RPC，標準化主應用程式與程式碼代理程式之間的通訊。本機代理程式以子程序的方式啟動，並透過該管道回傳訊息。
這是規格層級的描述。對我們來說重要的是：ACP 給了 OpenClaw 一種方式，把外部程式碼框架 — Claude Code、Codex、Gemini CLI — 當作受監督的子程序執行，而不是在主代理迴圈中把所有事情都內嵌處理。
OpenClaw 雙向使用 ACP：
- OpenClaw 內的 ACP 工作階段 — 透過
acpx後端外掛程式執行外部框架。OpenClaw 監督程序、管理其生命週期，並在情況失控時可予以終止。 - OpenClaw ACP 橋接器（
openclaw acp）— 一個透過 stdio 講 ACP 的 CLI 命令，讓 IDE 可將提示轉送到 OpenClaw 閘道工作階段。
本文我們關注的是第一項。
核心問題：您的代理迴圈是單一執行緒
這是我在生產環境中持續看到的失敗模式。OpenClaw 主代理回合直接叫用一個長時間執行的 Azure 網路呼叫 — 例如佈建 VNet 對等互連，或等待 Terraform apply。該代理迴圈是序列化的。一次只能一個作業。當它在等 Azure API 回應時，整個代理程式毫無反應。
沒有交談回應。無法檢查其他工作。沒有取消按鈕。如果該 API 呼叫卡住 10 分鐘，您的代理程式就卡 10 分鐘。如果它永遠卡住 — 而 Azure 網路呼叫確實可能如此 — 您的代理程式就永遠卡住。
誘惑是乾脆拉長逾時。那不是解決方案；那只是有截止期限的祈禱。
ACP 如何修正這一點
當人們說「ACP 防止 OpenClaw 卡住」時，他們的意思是：把有風險、緩慢、易失敗的工作放到 OpenClaw 監督的外部框架程序中執行，而不是內嵌處理。
acpx 後端將工作衍生到受監督的子程序。執行階段負責傳輸、排隊、取消與重新連線。即使 Claude Code 卡在等待一個永遠不會回來的 Azure 呼叫，那個卡住的工作也存在於另一個程序中。OpenClaw 的主迴圈保持靈敏。您可以：
- 取消該卡住的工作階段
- 關閉它並讓 TTL 清理程式處理
- 衍生新工作階段來做別的事
- 在背景工作執行時繼續與代理程式對話
這是把程序隔離應用到 AI 代理協調上。這不是新穎的電腦科學 — 就像我們不會把 Web 伺服器當成沒有工作程序的單一執行緒事件迴圈一樣的道理。但令人意外的是，多數代理框架都缺少這一點。
設定方式
必要條件
Claude Code 必須獨立安裝。在 Windows 上使用 PowerShell 安裝指令碼；在 Linux/macOS 上使用 curl。首次執行會提示您驗證 — 在嘗試接上 ACP 之前先把這件事搞定。
安裝 acpx 外掛程式
openclaw plugins install acpx
openclaw config set plugins.entries.acpx.enabled true
驗證一切都已正確接上：
/acp doctor
這會執行後端健康檢查。如果失敗，通常是 Claude Code 未安裝或驗證有問題。
設定 ACP
關鍵設定欄位：
openclaw config set acp.enabled true
openclaw config set acp.backend "acpx"
openclaw config set acp.defaultAgent "claude-code"
openclaw config set acp.maxConcurrentSessions 8
您也可以設定 acp.allowedAgents 來限制可用框架，以及 runtime.ttlMinutes 來自動清理超過使用壽命的工作階段。
處理權限（這會絆倒您）
ACP 工作階段以非互動方式執行 — 沒有 TTY。這表示預設權限模型（讀取須核准、寫入即失敗）會在框架嘗試寫入檔案或執行命令的瞬間拋出 AcpRuntimeError。
您需要設定 permissionMode 與 nonInteractivePermissions 以符合您的安全態勢。對基礎結構自動化，通常需要啟用寫入與執行權限。這部分要審慎處理 — ACP 工作階段執行於主機執行階段上，不在沙箱中。
日常使用方式
斜線命令
操作員工作流程相當直覺：
/acp spawn— 啟動新的 ACP 工作階段/acp status— 檢查執行中的工作階段/acp timeout <seconds>— 設定工作階段逾時/acp steer— 對執行中的工作階段發送額外指示/acp cancel— 終止卡住的工作階段/acp close— 乾淨關閉
以程式方式衍生
對自動化工作流程，使用 sessions_spawn 並指定 runtime: "acp"。agentId 參數選擇要使用的框架，mode 可以是 run（一次性，執行後返回）或 session（持久，保留框架供後續工作使用）。
執行緒繫結也支援 — Discord 執行緒與 Telegram 論壇主題可繫結到特定 ACP 工作階段，讓您的團隊為每個任務取得獨立的對話內容。
非封鎖模式
ACP 工作階段是更廣工具箱中的一項工具。以下是我用來保持代理工作流程靈敏的四種模式：
選項 A：Exec 背景化。 exec 工具支援 timeout 參數（預設 1800 秒）並透過 yieldMs 自動背景化。觸發命令、讓它幾秒後進入背景，再輪詢結果。簡單、有效，適用於已知持續時間的作業。
選項 B：ACP 工作階段。 對於可能涉及工具使用、檔案操作與決策的複雜多步驟工作 — 不只是單一 shell 命令 — ACP 工作階段提供完整的框架隔離。框架可以思考、行動，也可以卡住，而不影響主迴圈。
選項 C：Cron 對帳。 設定 OpenClaw cron 工作來定期檢查基礎結構狀態。與其等待部署完成，不如每幾分鐘排程一次對帳檢查。代理程式醒來、檢查狀態，然後就行動或回去休眠。
選項 D：Webhook。 對事件驅動工作流程，使用外部 cron 或基礎結構回呼打到 OpenClaw 的 webhook 端點（/hooks/agent）。當您的 Terraform apply 完成或 Azure 部署結束時，觸發 webhook 喚醒代理程式。無需輪詢、不會卡住。
實務上我會組合使用全部四種。ACP 工作階段處理重活、exec 背景化處理快速命令、cron 負責對帳、webhook 處理狀態變更通知。
疑難排解
權限失敗
如果您在衍生工作階段後立即看到 AcpRuntimeError，幾乎都是非互動權限預設值的問題。檢查您的 permissionMode 與 nonInteractivePermissions 設定。
殭屍工作階段
完成工作但未正確關閉的工作階段會吃掉您的並行插槽。用 /acp status 監控，並設定 runtime.ttlMinutes 自動清理過時工作階段。如果您撞到 acp.maxConcurrentSessions 上限，先檢查有沒有殭屍。
區分卡住類型
不是所有卡住都一樣，修正方式取決於您面對的是哪一種：
- 主迴圈被 shell 阻塞 — 代理程式本身卡在等待內嵌 exec 呼叫。這是 ACP 解決的問題。把工作移到工作階段。
- ACP 工作階段在完成後卡住 — 框架完成了但工作階段未乾淨關閉。使用
/acp close或讓 TTL 處理。 - 框架真的卡在網路上 — Claude Code 本身卡在等待外部 API。使用
/acp cancel終止工作階段，再調查底層網路問題。
Claude Code 安裝與驗證
這絆住人的頻率比您想像的高。Claude Code 是真實的相依性 — 若未安裝、未驗證或驗證權杖過期，ACP 工作階段會在衍生時失敗。務必先執行 /acp doctor。永遠如此。
安全性考量
ACP 工作階段執行於主機執行階段上，不在沙箱中。這是刻意的 — 它們需要存取您真實的基礎結構工具。但這意味著您必須思考安全邊界。
對 webhook，將端點保持在回環或置於 Tailnet/代理之後。使用專用權杖進行 webhook 驗證，並限制代理與工作階段路由，讓外部呼叫者無法衍生任意工作。
結論
代理程式卡住不是小麻煩 — 它是讓 AI 自動化在生產基礎結構工作上不可信賴的可靠性問題。ACP 為最可能卡住的作業提供程序隔離、生命週期控制與逾時管理。
設定並不複雜。它不是魔法。它是把良好工程實務應用到代理協調上：不要讓一個慢作業拖垮整個系統。
如果您正在為基礎結構自動化建構 AI 代理工作流程並遇到可靠性問題，讓我們談談。這正是我們在 Big Hat Group 所做的生產強化工作。