如果你曾让 AI 代理直接操作真实基础设施——Azure 部署、Terraform 计划、网络 provisioning——你一定撞过那堵墙。你的代理发出一条长时间运行的 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 网络操作——比如 provisioning 一个 VNet peering，或等待一个 Terraform apply。该代理循环是串行化的，一次只处理一个操作。当它在等待 Azure API 响应时，整个代理都处于无响应状态。
没有聊天回复。无法查看其他工作。没有取消按钮。如果那次 API 调用挂起 10 分钟，你的代理就挂 10 分钟。如果它永远挂起——而 Azure 网络调用绝对有可能——你的代理就永远挂起。
有人会忍不住去把超时调长。那不是解决方案，那是带截止时间的祈祷。
ACP 如何解决这一问题
当人们说"ACP 防止 OpenClaw 卡死"时，他们的意思是：把那些风险高、慢、易出错的工作放到一个由 OpenClaw 监管的外部框架进程里执行，而不是内联在主循环里。
acpx 后端把工作派生到受监管的子进程中。运行时负责传输、排队、取消和重连。即使 Claude Code 卡在一个永远不会返回的 Azure 调用上，那段卡死的工作也活在另一个进程里。OpenClaw 的主循环保持响应。你可以：
- 取消该卡死会话
- 关闭它，让 TTL 清理器回收
- 派生一个新会话去做别的事
- 在后台工作运行时继续与代理聊天
这是把进程隔离应用到 AI 代理编排上。这并不是什么新颖的计算机科学——我们不让 Web 服务器以没有 worker 进程的单线程事件循环运行，也是同样的道理。但在大多数代理框架里，这种做法却出奇地少见。
如何设置
前置条件
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— 干净关闭
编程式派生
对于自动化工作流，使用带 runtime: "acp" 的 sessions_spawn。agentId 参数选择使用哪个框架，mode 可以是 run（一次性，执行后返回）或 session（持久，保留框架以承接后续工作）。
线程绑定也支持——Discord 线程和 Telegram 论坛主题可以绑定到具体的 ACP 会话，这样你的团队就能按任务获得相互隔离的对话上下文。
非阻塞模式
ACP 会话是更广工具箱中的一种工具。以下是我用来保持代理工作流响应性的四种模式：
选项 A：Exec 后台化。 exec 工具支持 timeout 参数（默认 1800 秒），并通过 yieldMs 自动后台化。发出一条命令，几秒后让它转入后台，然后轮询结果。简单有效，适用于已知时长的操作。
选项 B：ACP 会话。 对于涉及工具使用、文件操作和决策判断的复杂多步工作——而不只是单条 shell 命令——ACP 会话提供完整的框架隔离。框架可以思考、行动、卡住，而不会影响主循环。
选项 C：Cron 协调。 设置 OpenClaw cron 作业周期性检查基础设施状态。与其等待某次部署完成，不如每隔几分钟调度一次协调检查。代理醒来、检查状态，要么采取行动，要么继续休眠。
选项 D：Webhooks。 对于事件驱动的工作流，使用外部 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 所做的生产加固工作。