1 版本升级

因为openclaw的版本更新很快，有些功能的启用应该要升级，那么升级会发生什么？

首先在dashboard上openclaw自己会有一个升级提醒，我某台机器上的openclaw是2026.3.1,提示我可以升到2026.3.2，有个update now按钮，我大着胆子点了一下。

• good news: 升级还挺顺利，不到10分钟就好了
• bad news: 只剩下一个main session，剩下的全都没了，我的飞书不能通信了

解决办法：用code buddy检查修复，它告诉我新版本的飞书插件有缺失，还有的地方有冲突。然后还有一些配置有点问题，但问题应该也不大。

总结一下：openclaw整体的设计上还是非常不稳定的，但话又说回来，人们愿意接受如此不稳定的东西，背后有什么是值得我们期待的呢？我相信一定有一些高层抽象的东西是值得我们去研究的。

2 ACPX

还有一个提示是关于ACPX的(说有一个设置没弄好)，因为我要用Agent Spawn功能，所以多看了一下：

当 Agent 通过 sessions_spawn 工具创建子 Agent 时，需要有一个运行时来管理这些子 Agent 的生命周期。ACPX 就是这个运行时后端。

工作流程

• 1 Zoe 想要 spawn 子 Agent → 调用 sessions_spawn 工具
• 2 OpenClaw 检查配置 → 找到 acp.backend: “acpx”
• 3 ACPX 接管 → 启动并管理新的子 Agent 实例
• 4 子 Agent 执行任务 → 任务完成后，ACPX 清理资源

如果把一个agent runtime看成一个容器，那么ACPX看起来就像是docker。

配置说明

你当前的配置：

ACP 配置：

{
  "acp": {
    "enabled": true,
    "defaultAgent": "minimax_coder"
  }
}
ACPX 插件配置：

{
  "plugins": {
    "entries": {
      "acpx": {
        "enabled": true
      }
    }
  }
}

是否需要额外配置？
不需要！ 你的配置已经完整了，可以直接使用 Agent spawn。

✅ acp.enabled: true - ACP 功能已启用
✅ acp.defaultAgent: “minimax_coder” - 默认子 Agent 已设置
✅ acpx.enabled: true - ACPX 后端已启用

所以acp有两个必要的基本配置：打开acp功能，并设置一个默认的子agent。

使用示例

现在 Zoe 可以直接这样调用：

{
  "task": "帮我写一个 Python 脚本来处理 CSV 文件",
  "runtime": "acp",
  "agentId": "minimax_coder",
  "mode": "session"
}

或者不指定 agentId，会自动使用默认的 minimax_coder：

{
  "task": "帮我分析一下日志文件",
  "runtime": "acp",
  "mode": "run"
}

总结：ACPX 是你使用 Agent spawn 功能的必要组件，你已经配置好了，可以直接使用。

3 ACP

上面提到了ACPX，这个本身是ACP的一个延伸。什么是ACP？

专门为了让AI代理（Agent）和客户端应用（Client，比如代码编辑器）能够顺畅地沟通和协作。它的目标是为AI助手进入我们的日常工作流，搭起一座标准化的桥梁。

🎯 ACP的核心思想：让AI代理成为你的“副驾驶”
在ACP的框架下，系统被清晰地划分为两个角色：

• 客户端 (Client): 这是你直接交互的软件，比如 Zed、VS Code、JetBrains 系列 IDE，甚至是一个命令行终端。它负责管理你的工作环境、展示信息。

• 代理 (Agent): 这是后台的AI大脑，例如 OpenClaw、Claude Code、Gemini CLI 等。它负责思考、规划并执行任务，比如写代码、查资料。

理解ACP的概念，关键要从“点”转为“边”。ACP描述的是Agent到Client的通信协议，这里Agent指的是openclaw的智能体，而Client则是外部的工具，例如ClaudeCode之类的。

协议交互图如下：

插个点，会话这种形式会比预想的要更有普适性，如果进行抽象的话，一次api请求也是session，周末有想到一些模糊的点，以后再展开。
可以看到，上面的交互确保了一个动态的、可断点续传的交互的一种协作可以进行。

两种ACP的应用模式：

4 subagent 与 ACP

在讨论蜂群(Swarm)的时候，我们知道一个任务中会需要多个agent参与，那么与ACP是什么关系呢？

subagent 和 ACP 是两种运行模式。

主要区别：

1. 运行后端不同

• subagent：OpenClaw 原生子代理运行时。
• ACP：走 ACP 后端插件（例如 acpx），用于外部 harness（Codex/Claude/Gemini 等）。

2. sessions_spawn 默认行为不同

• 默认是 runtime: "subagent"。
• 要用 ACP，必须显式 runtime: "acp"。

3. 适用场景不同

• subagent：OpenClaw 内部任务拆分、并行跑子任务。
• ACP：把任务交给外部编码代理运行时执行（你说的 Agent Spawn 外部代理能力）。

4. 会话与控制命令不同

• subagent：/subagents ... 命令族。
• ACP：/acp ... 命令族（如 /acp spawn, /acp status, /acp doctor）。

5. 会话标识不同

• subagent：agent:<id>:subagent:<uuid>
• ACP：agent:<id>:acp:<uuid>

一句话：

• 想要“OpenClaw 自己的子任务执行”用 subagent；
• 想要“调用外部 Agent runtime（如 acpx）”用 ACP。

持久化差异

相对来说，subagent 的持久化时间更短，一般来说session可能在一段时间后自动删除；而acp会持续到明确的结束指令发出才会消失。

Pi Agent

我还注意到在原理图里有提到一个Pi agent(注意，描述是"编程智能体")。

Pi agent 实际上就是一个“轻量级 AEE（Agent Execution Engine）”

这个Pi Agent+Worker分层的实现方式挺好，后续我的第一个版本也可以照这个来改。