WeClaw：一根更顺的管道
——七种定义与一次祛魅
一个物体在不同距离上被看，会显出不同的样子。站得远，它是一个微信机器人；走近一步，它是一条桥；再近，它是一座网关；再近，它是一间宿主环境；一直走到贴脸，你会发现那不是一件物件，而是一间正在运转的调度室。
一、桥接器：README 的第一行
英文 README 的第一行只有一句：
WeChat AI Agent Bridge — connect WeChat to AI agents (Claude, Codex, Gemini, Kimi, etc.).
请注意两个词：Bridge，以及 connect。它没有说「微信机器人」，没有说「自动化工具」，也没有说「中间件」。
桥的语义里天然包含三件事：桥有两个端点，而这两个端点都不归桥所有；桥自身不生产任何东西，它的全部价值在于让两岸能够相通；桥是有方向的，哪一岸是起点，决定了它把什么送到哪儿。
一端是微信——通过腾讯 iLink Bot 协议接入，包含二维码登录、长轮询收发、CDN 媒体加解密；另一端是 AI Agent——Claude、Codex、Gemini、Kimi 等本地或远端的智能体。WeClaw 自己，就是中间那一段。
这个定义自带一个难度声明。桥的难点从来不在桥身，而在两岸。微信这一端是私有协议，且上游还在持续演进；Agent 那一端是别人的二进制程序，今天这个版本，明天可能换一种调用方式。WeClaw 是一座架在两个会自己移动的岸之间的桥，它必须两端都能跟上，自己才不会被留在中间。
「桥」是它诚实的最小定义：它只承诺连接，不承诺智能——但这座桥的两岸都在移动。
二、网关：从直通车到总机
Bridge 是结构描述，WeClaw 给自己的正式身份则是 Gateway——中文写作「微信 AI Agent 桥接网关」。多出来的这半句，才是它显出工程野心的地方。
桥是点对点的，一段桥对应固定的一对端点；网关是一对多的，它是一个统一入口，入口背后是协议转换、鉴权、路由、限流、后端复用。桥回答「把谁连到谁」，网关回答「谁可以通过我，用什么方式，到达哪一类后端，以及被怎么管」。
WeClaw 越过桥、长成网关，有四处硬证据：
多后端统一。 一个微信账号同时上线多个 Agent，@claude、/cx、/ds 各是一个人格，别名系统把「选谁」从选择题变成输入法里的一个缩写。这是把一束线接进一个总机。
抽象层的存在。 agent.Agent 接口只有七个方法，却统一了三种截然不同的接入范式：ACP（长驻子进程，stdio + JSON-RPC 2.0，复用进程与会话）、CLI（每条消息新起进程，--resume 续会话）、HTTP（OpenAI 兼容 chat/completions）。对上层而言，它调用的永远只是「一个 Agent」；下面到底是子进程、命令还是网络请求，被这一层协议翻译吃掉了。协议转换，正是网关的核心职能。
对外暴露服务。 weclaw start 会在 127.0.0.1:18011 起一个 OpenAI 兼容 API 网关。外部程序可以按标准方式调用——微信不再是终点，而是消息的起点。到这一步，它已经不满足于「把微信接到 AI」，它开始「把 AI 接出去」。
权威边界的管理。 iLink 签名、Token 鉴权、长轮询的重连与退避，都是典型的网关级议题——网关是唯一掌握凭证与协议细节的地方，也是唯一能统一约束流量的地方。
还有一个常被忽略的网关特征：它连「并发与失败」都要统一管。项目里有名为免费池（free pool）的机制，把多个 HTTP 型 Agent 编成一组，请求随机分发，谁先返回 200 就把结果透传给谁，全部失败才报错——教科书式的故障转移。网关之所以需要它，是因为网关恰恰处在那个「后端会挂、但入口不能挂」的位置上。桥可以线断就断，网关不行。
代价也很清楚：网关要有状态（会话、游标、默认 Agent 的持久化切换）、要处理并发、要兜底失败。换来的东西很值——一次接入，多处复用。
三、Agent Host：它管的是进程，不是消息
再往下走，会撞上最重要、也最容易被忽略的一副面孔：
WeClaw 并非一个简单的「微信机器人」，而是一个本地 AI Agent 的主机环境（Agent Host）。
Host，宿主。这个词把视角翻转了：不是 WeClaw 在「使用」Agent，而是 WeClaw 在「承载」Agent。Agent 是住进来的租客，WeClaw 是房东——它提供住处（工作目录、环境变量、PATH 回退），管理生命周期（启动、常驻、会话重置、健康检查），还要替租客处理那些它自己处理不了的麻烦。
判断一个系统是不是 Host，看它管不管进程的生死，而不是管不管消息的转发。WeClaw 管。七个方法里，Health 与 SetCwd 是纯粹的宿主职责——前者是活下去的能力，后者是「你被安排在哪间屋子里干活」。三种接入范式在宿主视角下也各有了身份：ACP 是常驻的仆人，CLI 是随叫随到的零工，HTTP 是远方的智者。
三个细节最能说明身份。
权限自动放行。 ACP 协议下，Agent 调用工具前要向客户端请求权限；在桌面 IDE 里这会弹窗让用户点「允许」。但微信场景里没有「用户在场」——照搬弹窗逻辑，流程会永远卡死。WeClaw 的做法是直接代答 allow，同时把工具名提取出来，化作一条「正在调用工具：read_file」的进度通知推给用户。一代一告之间，流程不断，知情不减。宿主替租客签字，但要把签了什么告诉主人。
启动环境的自举。 守护进程环境下 PATH 常常缺失。当 exec.LookPath 找不到可执行文件时，它会回退到 zsh -lic "which claude" 去问一遍登录 shell，确保在 launchd、systemd 这类极简环境里，nvm、brew、mise 装出来的工具也能被找到。这行代码的价值不在技术含量，而在姿态：宿主会替租客把路铺平，哪怕铺得有点丑。
ACP 的双方言。 标准 ACP 走 session 模型，Codex 的 app-server 是另一套 thread 与 turn 模型。WeClaw 靠一个协议探测，从命令名和参数里自动判别该说哪种方言。房东同时会说两种方言，租客换了一批又一批，不用先问「你是哪儿来的」，听一句就知道该怎么接话。
Host 的代价，是接手一整类脏活：僵尸进程、会话过期、PATH 缺失、权限弹窗、跨平台服务化（plist 与 service 文件都得自己写）。这些在「桥」的定义里根本不存在，在「Host」的定义里却绕不过去。
四、多智能体协作操作系统
再往上一层，就是「一个组织的调度长」：
WeClaw 是一个以个人微信为入口、以多种 AI Agent 为后端、以文件系统为共享记忆的多智能体协作操作系统。
这句话里三个关键词，恰好对应操作系统的三个基本要素：
入口，对应终端 shell。你的手指此刻在微信里，所有能力都从这一个入口被唤出。
Agent 为后端，对应进程。Agent 是可被调度、可被切换、可被并行拉起的计算单元，各自有身份（别名）、会话、工作目录。
以文件系统为共享记忆，对应文件系统与共享内存。这一条最容易被轻视，却最见野心：Agent 之间传上下文，用的不是内部总线，而是文件。~/.weclaw/hub/shared 是一个带 YAML frontmatter 的共享文件池，Agent 把结果写进去，另一个 Agent 读出来。作者自己把它评为这个项目最核心的创新，我同意。
在文件系统这个基座上，调度器是可以数出来的：/debate 让两个 Agent 就同一话题正反交锋三轮，生成完整辩论文档；/roundtable 是多方圆桌；/hub pipe 是流水线——把上一个 Agent 的输出直接喂给下一个，支持 @1、@-1 这样的绝对与相对编号；再往上是 /workflow，一套迷你 DSL，step、parallel、branch、save、@N 引用齐备，最多十步、五路并行分支，还带 panic recover 兜底。
一个设计选择值得停下来想一秒：为什么协作的介质是文件，而不是消息总线？因为在个人尺度上，文件的优势压倒性地大——纯文本、可读、可搜、可跨进程、可持久、不依赖任何平台。它的代价是缺乏事务与结构化索引，跨 Agent 引用只能靠命名和编号，规模一大就容易乱。但这是「个人」的操作系统——个人尺度的乱和团队尺度的乱，不是一回事。
到这一层，它已经不是一个机器人，而是一个能开会、能分工、能留档的小型组织——只不过员工都是 AI，会议室就是文件系统。
五、微信即 shell
把前四层叠起来看，会浮出一个更根本的问题：WeClaw 到底把微信当成了什么？
读这部分代码，能清楚感到作者是在把微信当成一个操作系统的 shell 来经营。
和 Unix shell 对照，一一都对得上。输入是自然语言与斜杠命令；输出是文本、图片、文件；后台有 cron 守护（/todo、/timer、/cron 三套时间机制，全部 JSON 持久化，重启不丢）；文件系统是 Hub；进程池是 Agent；至于管道 |，/hub pipe 直接实现了它。命令体系用注册表模式管理约二十个斜杠命令，覆盖会话管理、工作区切换、发布、播客生成、剪藏。最激进的是 /sh 与 /$——把微信直接变成远程终端，虽然只是受限的伪终端（白名单命令加路径沙箱），但意图非常明确：这台聊天框，就是我的 shell。
为什么是微信，而不是自建一个更漂亮的 Web 终端？
答案不在技术里，在动线里。shell 的真正价值从来不是「能执行命令」，而是「统一入口」加「可组合」——所有工具从同一个地方进、同一个地方出，输出还能被下一个工具接手。微信恰好满足这两点，而且额外满足两个自建 UI 给不了的条件：它无处不在（不装客户端、不记地址、不配端口），以及它私密（一对一对话里，人才敢问真正重要的问题）。用一个已经在手上的终端，去装一个还没有的终端，这笔账怎么算都划算。
也正因为微信成了 shell，它的「命令」才有资格叫命令，而不是「功能按钮」。功能按钮是你去点它；命令是你去说它。前者要求你记住界面，后者只要求你组织一句话。
更硬的证据是命令的可组合程度：/save 把结果写进 Hub，/hub 再把 Hub 里的文件读回上下文，/hub pipe 把两者接成一条管道。成熟度的标志不是命令多，而是命令之间能互相吃。
代价是「能力高度集中在一个通道里」，安全边界因此格外要紧。WeClaw 的处理是个人尺度的：Shell 模式限定白名单与路径沙箱，出站敏感信息有脱敏，README 也如实提示跳过权限的参数「请了解风险后再启用」。这不是企业级安全模型，但与「个人软件」的定位自洽——自己家的门，用自己觉得够用的锁。
微信不是被 WeClaw「接入」了 AI，而是被它「当成」了操作系统：聊天框即终端，一条消息即一次系统调用。
六、PAOS 的连接与编排层
前面几层一直在问「WeClaw 自己是什么」。这一层换个问法：它在一幅更大的图里，站在什么位置？
一幅完整的个人智能操作系统（PAOS，Personal AI Operating System）由七层构成：感知（浏览器插件）、记忆（Knowly）、执行（yuangs CLI）、治理（TAAGE）、打包（Sourcepack）、扩展（MCP），以及最关键的一层——连接与编排。WeClaw 正是这一层：它是系统的壳和总线，其他所有能力最终都要通过一条微信消息，触达它的主人。
为什么说「连接与编排」是七层里最关键的？因为其余六层都是能力，而能力不被连接，就等于不存在。一个再好的记忆系统，你不打开它，它就只是一堆文件；一个再强的执行工具，你的手不在键盘边，它就只是一段脚本。连接层决定了其他能力能不能被调用、能不能被组合、能不能沉淀——它是把七块拼图粘成一张图的那个动作。
一次完整的闭环最能说明问题：你在手机上说一句「帮我查一下并整理成文」——WeClaw 把它路由给合适的 Agent；Agent 调用 MCP 工具去搜索、取数；结果经 Knowly 沉淀为可检索的知识；成稿再由 WeClaw 推回微信。整个过程，你的手指没有离开聊天窗口，也没有打开过任何一个工具。
操作系统的定义从来不是「很多东西」，而是「一切资源的调度入口」。WeClaw 之于 PAOS，正如 shell 之于 Unix。
PAOS 的七层是横向铺开的能力矩阵，而 WeClaw 是纵向穿过去的那根轴。它自己不带多少能力，但它决定了能力从哪里进来、到哪里去、留下什么痕迹。这也是它与商业 AI 产品的分野：商业产品通常是「一个 App 一个能力」，能力与界面绑定，用完即走；PAOS 是「一个入口一张网络」，入口越少，网络越密，个人资产积累越厚。
把总线的职责压在一个 IM 通道上，是有风险的——它是单点，微信这一端出问题，整个系统的触达路径就断了。但权衡的另一面是：唯一入口带来的心智负担最小。你不需要记住六七个入口，只需要记住一个聊天框。对一个人的操作系统来说，「记得住」本身就是硬指标。
七、祛魅：它不生产智能，只修管道
七层定义一路抬高，从桥到网关，从宿主到操作系统，从 shell 到总线。到这一步，必须做一件逆着前文的事：把它拉回来。
第一刀：它不生产智能。
没有训练任何模型，没有做任何推理优化，没有一行自研算法。它接进来的每一个「聪明」，都来自别人——Claude 的推理、Codex 的代码、Gemini 的长文与多模态、DeepSeek 的便宜与快。连「听懂语音」都不是它做的：微信服务端已完成 ASR 转写，它直接取用 VoiceItem.Text，一行语音识别代码都没写。知道「不做什么」，往往比知道「做什么」更显功力。这个项目最清醒的地方，就是从头到尾没有假装自己是那个大脑。
第二刀：它不是「更聪明的 AI」，它是「更顺的管道」。
而技术史反复证明，真正改变格局的往往不是最强的模型，而是最顺的管道。模型是公共品——今天最强的那个，半年后会被免费开源的替代；接口是私人物品——谁把智能接到你手边，谁就决定了它什么时候出现、以什么方式出现、为谁服务、留不留痕。管道是稀缺品。
第三刀：它带着个人软件的全部印记。
README 自称「仅供个人学习，不作商业用途」，合规身份存疑；messaging/handler.go 约 2794 行，是典型的巨型文件；测试覆盖不均，安全模型是个人尺度的；Hub 用文件做协作总线，个人够用，规模一大就露出结构化不足的短板。这些不是被掩盖的缺点，而是它在「一个人、一台小主机、一个二进制」这个约束下，自愿接受的取舍。
第四刀，有点自嘲：连它最得意的那部分工作，也全是在修管道。
那个几百行的 Node 代理，做的事情是把某个客户端里「计费为零」的端点数理化，拆解它的限流、重试与队列深度。它高明吗？高明。它聪明吗？不聪明——它一个字的内容都没有生成，只是把请求排得更整齐、把失败处理得更体面。WeClaw 恰是这样：价值密度几乎全部集中在「让智能顺利抵达」，而不在「让智能出现」。先承认这一点，才读得懂它。
祛魅之后，还剩下什么？
剩下的是它真正的价值主张：机制与策略分离。商业 AI 产品总把机制和策略捆绑销售——它决定你用什么模型、怎么存数据、能不能导出；WeClaw 只负责机制（消息收发、会话保持、Agent 生命周期），把策略的权杖交还给你（用哪个模型、写什么 prompt、Hub 里怎么流转）。这不是口号，是代码结构上的事实：三种接入范式可选，Hub 是纯文本，配置在你自己的 ~/.weclaw/config.json 里。你在编程你自己的认知环境。
尾声：一个可以反复使用的判断框架
以后评估任何一个 AI 网关，就看四件事：
- 能不能出现在你最常待的地方；
- 能不能记住你；
- 能不能主动找你；
- 能不能接上你自己的工具。
WeClaw 四条全中。这就是它意义的最短版本。
它不是又一个更聪明的 AI，它是一根更顺的管道——不生产智能，只是把智能接到你手边，让每一次对话，都沉淀为个人的资产。
雨轩于听雨轩 🌧️🏠