ACP Thread Bound Agents

这个计划是为了让OpenClaw机器人能更好地管理一种叫“ACP”的智能体。ACP就像一个很会写代码的专家朋友。我们想做到：当你在Discord的一个小聊天群（线程）里，召唤或者指定一个ACP朋友后，你们在那个小群里的所有对话，都只交给这个朋友处理，它的回答也只发回这个小群，不会跑到别的地方去。这个朋友可以一直陪着你（持久模式），也可以只聊一次就离开（单次模式）。

核心想法：分工合作 OpenClaw机器人的核心大脑（我们叫它“核心”）负责管理ACP朋友的身份、记住它被绑定在哪个小群、保证消息不会发重复、以及处理朋友什么时候来、什么时候走这些大事。而具体怎么和ACP朋友聊天、传递消息这些跑腿的活儿，交给一个叫“acpx”的插件服务去做。这样分工，核心大脑就不用重新发明轮子去学怎么和ACP朋友直接说话了。

重要的规则（绝对不能违反的约定） 为了让一切井井有条，我们定下了一些必须遵守的规则：

1. 每个绑定到小群的ACP，都必须对应一个真实存在的ACP朋友记录。
2. 每个ACP朋友都有明确的状态，比如“正在创建”、“休息中”、“工作中”、“正在取消”、“已关闭”、“出错了”。
3. 每次让ACP朋友干活（我们叫“运行”），也都有明确的状态，比如“排队中”、“进行中”、“完成了”、“失败了”、“被取消了”。
4. 召唤朋友、绑定到小群、以及把第一个任务放进队列，这三件事必须像原子一样，要么全成功，要么全不成功。
5. 如果因为网络不好，同一个命令发了两次，系统要能认出来，不会让朋友干两次同样的活，也不会在聊天窗口里发两次同样的回复。
6. 小群里看到的消息，必须完全来自ACP朋友干活时产生的事件，不能是别的地方随便塞进来的。

怎么一步步实现呢？（像搭积木一样） 我们不会一下子把所有东西都换掉，而是分几步走：

1. 短期目标（先修修补补）：先用着现在绑定小群的方法，但修复一些漏洞，确保所有给ACP的消息都经过核心大脑里一个专门的通道来处理。马上加上“命令去重”的检查，如果路由检查没通过，就明确告诉用户失败了，而不是偷偷走别的路。
2. 长期目标（换上全新的引擎）：把ACP所有重要的信息（比如朋友是谁、状态如何）都存到一个专门的、更可靠的数据库里。让小群里的消息完全由这个数据库里记录的事件来生成。最后，把以前依赖旧方法的地方都清理掉。

为什么不能全交给插件去做？ 因为现在的插件就像只能帮忙传个话，但不能决定话传给谁。当一条消息发到小群时，核心大脑需要先查一下“这个小群绑定的是哪个ACP朋友”，这个决定必须由核心来做。插件命令适合用来控制朋友（比如让它开始或停止），但不能代替核心大脑来决定每一条消息应该交给谁处理。所以，ACP具体干活的运行时可以做成插件，但决定消息路由的“大脑分支”必须放在核心里面。

我们已经有哪些可以用的积木了？ 好消息是，我们已经有一些做好的部分了，这次计划是在它们的基础上盖更高的楼，而不是拆掉重来。这些已有的积木包括：

• 小群可以绑定两种目标：subagent（普通副手）和 acp（会写代码的朋友）。
• 消息发到小群时，会先检查有没有绑定，有的话就按绑定的目标处理。
• 回复消息时，会用一种叫“webhook”的技术，让回复看起来像是从小群本身发出的。
• /focus（聚焦）和 /unfocus（取消聚焦）命令已经支持ACP目标了。
• 绑定关系会被记住，即使机器人重启了也能恢复。
• 当小群被归档、删除，或者执行了/unfocus、重置、删除等操作时，绑定关系会被正确清理。

一些需要特别注意的事情（像大人提醒小朋友一样）

• 安全控制：不是所有叫ACP的朋友都能随便请来。管理员可以设置一个“允许名单”，只允许名单上的朋友来工作。还可以限制它们能在电脑的哪个文件夹里活动，以及能使用哪些环境变量。
• 数量限制：为了防止请来太多朋友把系统累坏，可以设置每个用户最多能同时有几个ACP朋友，以及全局最多能有多少个。
• 出错恢复：如果负责管理ACP朋友的核心服务重启了，它能从数据库里重新加载所有还在工作的朋友，继续之前没干完的活。如果发现某个小群还绑着一个已经不存在的ACP朋友，它会明确告诉用户“绑定失效了”，而不会偷偷把消息交给别的普通机器人处理。
• 新命令：我们会增加一些新命令，比如 /acp spawn（召唤一个ACP朋友）、/acp cancel（取消当前任务）、/acp steer（给朋友一些指导）、/acp close（请朋友离开）、/acp sessions（看看现在有哪些ACP朋友在）。