刚刚 Openclaw 推出了史上最密集的一次更新，这次更新带来了很多非常实用的功能，其中最吸引我的当属 ACP Agent。

以 Telegram 为例。

Telegram 的 forum supergroup 支持 topic（话题线程）。每个 topic 就像是群里的一个独立房间，有自己的标题、自己的消息流、自己的讨论线程。

OpenClaw 支持把每个 topic 当成一个独立的工作台。

但这次更新带来了更不一样的体验。

你不再只是在 Telegram 里和 Openclaw 机器人说话，

你是在某个固定 Topic 里，和一个专门负责这件事的 Codex / Claude Code CLI 长期协作。

这个功能到底是什么？

先给一个最容易理解的定义：

Telegram topic 绑定 ACP agent，就是把 Telegram 群组里的某个 Topic，当作一个外部 ACP 会话的固定入口。
以后这个 Topic 里的消息，会持续路由到那个 ACP agent，而不是走默认主助手。

这里有四个关键词：

1）Topic 是什么？

Telegram 的 forum supergroup 里，可以把一个大群拆成多个 Topic。每个 Topic 本质上就是一个独立讨论线程。

你可以把它理解成：

• 同一个大群里的多个小工作区
• 每个 Topic 各聊各的，互不打扰
• 对 OpenClaw 来说，每个 Topic 都可以被视为独立上下文

2）ACP agent 是什么？

ACP 是 Agent Client Protocol。

它的意义，不是再造一个聊天机器人，而是让 OpenClaw 能接上外部 agent runtime。

比如：

• codex
• claude
• gemini
• opencode
• pi

这些可不是简单的将 Openclaw 换了个人设，而是直接接入外部运行时。

也就是说，OpenClaw 不只是自己回答，还能把任务交给这些外部 coding harness 去做。

3）绑定是什么意思？

绑定的意思是：

某个 Telegram Topic，不再只是普通聊天位置，而是和某个 ACP session 建立持续关系。

可以让每个 topic 绑定到：

1. 不同的 agent（比如 topic A 用 Claude，topic B 用 Codex）

2. 持久化的 ACP session（一个长期运行的 coding session，带完整上下文和工作空间）

3. 动态创建的专属线程（在聊天中直接 spawn 一个新 agent，当场绑定）

这意味着什么？

• Topic A：需求讨论，用通用 agent，轻量级对话

• Topic B：Bug 修复，绑定到一个持久化的 Codex session，带完整 repo 上下文

• Topic C：Code Review，绑定到 Claude Code，专注代码质量和架构

• Topic D：运维排障，动态 spawn 一个临时 agent，用完就走

每个 topic 有自己的上下文、自己的会话历史、自己的工作空间。它们互不干扰，各司其职。

4）为什么这很重要？

因为这意味着你终于可以把“AI 协作”从一个混乱的大聊天窗口里剥离出来。

以前是：

• 一个群里什么都聊
• 机器人什么都看
• 上下文容易串
• 代码任务、日常讨论、临时吐槽混成一锅粥

现在是：

• Topic A：专门跑 Codex 修 bug
• Topic B：专门让 Claude Code 写文档
• Topic C：主助手做人类沟通和调度

它解决了什么问题？

问题 1：外部 coding agent 缺少自然入口

Codex、Claude Code 强是真强。

但很多时候，它们的问题不是能力不够，而是不能随时随地使用。

你得切 CLI、切终端、切会话、记上下文、盯状态。

技术人能忍，团队协作就很难优雅。

现在如果一个 Telegram Topic 就能承载一个 ACP agent：

• 人类仍然在熟悉的聊天界面里工作
• 外部 agent 在背后持续跑
• Topic 成了天然的任务入口

这就舒服多了，不是每个人都想天天盯着命令行。

问题 2：一个群里，多个 AI 角色很难共存

Topic + ACP 的组合，终于让一个群里多个角色的设计变得清晰：

• 主 agent：负责解释、协调、路由
• Topic agent：负责某一类长期任务执行
• 每个 Topic 都有自己的职责边界

这才像团队协作嘛。

原理是什么？

Telegram Topic 在这里，扮演的是 thread binding 的载体。

也就是说，OpenClaw 把 Telegram Topic 看成线程。

1）Telegram Topic = ”Thread 的 Telegram 形态“

在支持 thread binding 的渠道里，OpenClaw 会把“会话绑定”挂到某个 thread 上。

而在 Telegram 里，这个 thread 对应的就是：

• forum supergroup 的 Topic
• 某些情况下的 DM topic / thread-aware routing

Telegram 的 group session 会按 group ID 隔离，forum topics 会附加 :topic:<threadId> 来保持 topic 隔离。

也就是说，在会话键层面，它不是一个普通群消息，而是类似：<chatId>:topic:<topicId>

这就是为什么 Topic 能成为绑定单位。

2）ACP session 是什么？

当你启动一个 ACP 会话时，OpenClaw 会创建一个外部 runtime session。
它的 session key 形态通常是：agent:<agentId>:acp:<uuid>

比如：

• agent:codex:acp:...
• agent:claude:acp:...

这个 session 不等于 Telegram 会话本身。

它是OpenClaw 管理下的一个外部 agent runtime 会话。

3）绑定发生了什么？

绑定之后，本质上是：

• Telegram Topic 这一侧：有一个 peer.id = "<chatId>:topic:<topicId>"
• ACP 会话这一侧：有一个 agent:<agentId>:acp:<uuid>
• OpenClaw 在中间保存这层映射关系

于是后续就变成：

• 这个 Topic 的消息 -> 路由到这个 ACP session

• ACP session 的输出 -> 回发到这个 Topic

这就是所谓的 thread-bound ACP session。

4）sessions_spawn(runtime="acp", thread=true, mode="session") 又是什么？

这是程序化启动方式。

它的意思非常直白：

• runtime: "acp"：不要走原生 sub-agent，要走 ACP 外部 runtime
• thread: true：要求绑定到一个 thread
• mode: "session"：不是一次性 run，而是持久会话

如果这个 channel 支持 thread binding，那么它就能把当前 thread（在 Telegram 里就是 Topic 语义）和这个 ACP 会话绑起来。

所以这几个概念的关系是：

• Telegram Topic：聊天面的线程载体
• thread binding：把线程和 session 绑定的机制
• ACP agent：外部 coding harness 运行目标
• sessions_spawn：创建这个会话的工具入口
• mode=session：让它不是一次性回复，而是持续协作

一句话概括：

Topic 是工位，ACP session 是工人，thread binding 是工牌，sessions_spawn 是入职流程。

三、核心概念：三种绑定方式的区别

在开始配置之前，你必须先搞清楚三个概念。这是很多人用错的地方。

1）topic.agentId：静态路由

这是最简单的方式。你在配置文件里指定：topic 3 用 agent A，topic 5 用 agent B。

{  channels: {    telegram: {      groups: {        "-1001234567890": {          topics: {   "1":{agentId:"main" },   "3":{agentId:"zu" },   "5":{agentId:"coder" }          }        }      }    }  }}

这种方式的特点：

• 静态配置：提前在配置文件里写好

• 轻量级：按 topic 分流到不同 agent

• 适合场景：日常对话、快速问答、不同角色分工

注意：agentId 不会继承 group 的默认值。你必须为每个 topic 显式指定。

2）bindings.type = "acp"：持久化绑定

这是高级玩法。你把一个 topic 直接绑定到一个持久化的 ACP session。

{  agents: {    list: [      {        id: "codex",        runtime: {          type: "acp",          acp: {            agent: "codex",            backend: "acpx",            mode: "persistent",            cwd: "/workspace/openclaw"          }        }      }    ]  },  bindings: [    {      type: "acp",      agentId: "codex",      match: {        channel: "telegram",        accountId: "default",        peer: {          kind: "group",          id: "-1001234567890:topic:42"        }      }    }  ],  channels: {    telegram: {      groups: {        "-1001234567890": {          topics: {            "42": {              requireMention: false            }          }        }      }    }  }}

这种方式的特点：

• 持久化 session：这个 ACP session 会一直运行

• 完整工作空间：带 cwd，可以直接在项目目录里工作

• 长期上下文：讨论历史、代码状态、任务进度都能连起来

• 适合场景：长期项目维护、复杂 Bug 修复、持续 Code Review

这种玩法相当于给这个 topic 配了一个专职程序员，它会一直在那个工作目录里待命，记得你们之前聊过的所有事情。

3）Thread-bound spawn：聊天内动态创建

这是最灵活的方式。你在某个 topic 里直接输入命令：

/acp spawn codex --thread here

OpenClaw 会：

1. 创建一个新的 ACP session

2. 把它绑定到当前 topic

3. 把确认消息 pin 在 topic 里

4. 后续这个 topic 的所有消息都会自动路由到这个 session

要启用这个功能，需要在配置里打开：

{  channels: {    telegram: {      threadBindings: {        spawnAcpSessions: true      }    }  }}

这种方式的特点：

• 即时创建：不需要提前写死

• 非常灵活：适合临时拉一个专属开发线程

• 适合场景：突发需求、快速原型、临时排障

四、配置实战：从简单到高级

Level 1：按 topic 指定 agentId

最小可用配置就是把不同 topic 路由到不同 agent：

{  channels: {    telegram: {      groups: {        "-1001234567890": {          topics: {   "1":{agentId:"main" },   "3":{agentId:"reviewer" },   "5":{agentId:"debugger" }          }        }      }    }  }}

这样一来：

• Topic 1 处理通用讨论

• Topic 3 处理 Code Review

• Topic 5 处理 Bug 修复

Level 2：定义 ACP Agent

如果你要接 Codex、Claude Code 这类外部 coding agent，就先在 agents.list 里定义它们：

{  agents: {    list: [      {        id: "codex",        runtime: {          type: "acp",          acp: {            agent: "codex",            backend: "acpx",            mode: "persistent",            cwd: "/workspace/my-project"          }        }      },      {        id: "claude-code",        runtime: {          type: "acp",          acp: {            agent: "claude-code",            backend: "acpx",            mode: "persistent",            cwd: "/workspace/docs"          }        }      }    ]  },  channels: {    telegram: {      groups: {        "-1001234567890": {          topics: {   "3":{agentId:"codex"},   "5":{agentId:"claude-code" }          }        }      }    }  }}

Level 3：把特定 topic 绑定到 persistent ACP

如果你希望某个 topic 本身就是一个长期运行的专属开发线程，用 bindings[]：

{  agents: {    list: [      {        id: "openclaw-dev",        runtime: {          type: "acp",          acp: {            agent: "codex",            backend: "acpx",            mode: "persistent",            cwd: "/workspace/openclaw"          }        }      }    ]  },  bindings: [    {      type: "acp",      agentId: "openclaw-dev",      match: {        channel: "telegram",        accountId: "default",        peer: {          kind: "group",          id: "-1001234567890:topic:42"        }      }    }  ],  channels: {    telegram: {      groups: {        "-1001234567890": {          topics: {            "42": {              requireMention: false            }          }        }      }    }  }}

这样配置后，topic 42 就成了一个长期开发线程。你今天在里面讨论方案，明天继续改代码，后天补测试，agent 都能记住。

真实场景

场景 1：多项目团队协作

你有一个 AI 开发群，里面开了四个 topic：

• 需求讨论

• Bug 修复

• Code Review

• 运维排障

每个 topic 绑定不同 agent。于是，同一个群，不同线程，各干各的，不会串台。

场景 2：长期维护一个 repo

你把某个 topic 固定绑定到 Codex 的 persistent ACP session。

以后这个 topic 就等于这个 repo 的驻场开发位。

你不需要每次重新解释项目结构，不需要每次重新喂上下文。

这个 agent 会一直待在那个工作目录里，持续跟进。

场景 3：Claude Code 做文档和方案设计

另一个 topic 绑定到 Claude Code。 它不一定天天改代码，但特别适合做：

• 架构讨论

• 文档整理

• 重构方案设计

• PR 分析和 review

场景 4：聊天中临时升级成专属线程

群里有人突然说：
“这个问题有点复杂，直接使用 codex 来解决吧。“

这时候你直接：

/acp spawn codex --thread here

当前 topic 立刻升级成一个专属开发线程。

不用改配置，不用切工具，不用重新建立上下文。

最后

说到底，这个功能最值钱的，不是能不能在 Telegram 里调 agent，那只是表象。

真正值钱的，是它在重塑一件事：

聊天工具，开始进化出了工作流能力。

以前群聊是沟通层，真正干活的系统在群外。

现在，随着 Topic 绑定 ACP session 这种能力出现，聊天界面本身开始变成工作入口、工作容器、工作上下文。

你不是在群里喊一个机器人帮忙。

你是在群里某个工位，持续和一个外部 agent 协作。

这个变化很小吗？

一点都不小。

这是协作界面从消息面板往任务操作系统迈出的一小步。

而所有真正重要的新能力，刚开始看起来都像个小按钮。

等你反应过来时，工作方式已经彻底变了。