小孩子才做选择！成年人给Grok Bot 一口气接上Claude Code, Codex, DSH, Pi

Grok Bot 用到飞起，但额度也跑得飞快？

本地项目已积攒大量代码、文档、上下文，不愿意为了 Grok Bot 搬家同步？

云端 Grok Bot 四通八达，调用本地 Coding Agent 两眼抓瞎？

终端命令一时爽，注入攻击火葬场？

本篇就教你如何通过加密通信，让你的 Grok Bot 可以像调用自己的 Bot 一样，和本地 Coding Agent 双向通话，实现并肩作战！

TL;DR

用开源的 Reason Network，把本地电脑上的 Claude Code、Codex、dsh、pi 等和 Grok Bot 放进同一个私有团队：多轮对话，双方都能主动发起，谁回信都能即时叫醒对方。多 Agent 通信从此比居家办公还方便！

AI; DR

把链接丢给你的 Claude Code，说一句「照着装」就行：https://github.com/xiaozhenliu/agent-mesh

效果展示：

图 1：Robin 是我的 Grok Bot。它发来的消息进入了本地 Claude 会话，Claude 在同一会话中处理并回复。图中截取了来信和回复两处，未改写原文

Grok Bot已经很好用，但它和你的Claude不熟

在Grok Bot里面开多个Bot，非常丝滑。他们可以在群聊里沟通，也能彼此发送私信。一个@就能唤起同伴，一个名字就能呼唤朋友。可是Grok 额度不是很够，重任务还得靠其他Agent。这时候该怎么交接任务？

最直接的方法一直都有：

调用终端，用 -p 非交互命令发起任务。

但一条终端命令就能叫起的Claude，究竟算不算队友呢？

跟Grok Bot自己的Bot队友比：

• Claude进程不持久，发起一次后就关闭；下次Grok Bot要和它沟通，得找到当时的ID，用resume来对话

• 如果换成tmux的交互式操作，则需要时刻检查交互界面产生的上下文，达不到我们节约额度的目的。

还有个棘手问题：终端命令权限很大。如果仅仅在云电脑调用也就罢了。如果在本机的Grok Bot上允许终端调用，那么万一Grok Bot读到要求他执行终端操作的恶意内容而去执行，岂不是相当于把本地机器暴露在网络攻击中吗？

如果我想让Claude真正成为Grok Bot的队友，中间也许要提问，做完可能要修改，过一会儿还得接着讨论。也就是说，Grok Bot 得随时找到正在负责这件事的那个 Claude，Claude 也得能主动找回来。

而且如果除了Claude，我还想接入Codex，DSH，Pi，并且让他们彼此都认识，都能互相沟通，我总不会要自己去创建每条沟通路径吧！有没有更简单方便的办法？

图 2：保留完整往返方向的交互时序示意（不含中间传递过程）

每个Bot都接入同一个网络，并且知道彼此的身份

免费开源的Reason Network正好解决了这个问题。

它的底层是每台电脑各运行一个 Reason Network 后台进程，MCP、hook 或插件把本机的 Agent 会话接进去。后台进程之间同步“谁在做什么”的会话名册，再按地址把消息送到目标会话。跨机器通过 iroh 建立加密连接，优先直连，连不通时再经网络中继转送。

图 3：依据 Reason Network v0.10.7 官方设计文档绘制。每台电脑有自己的目录和信箱，消息能否自动送入空闲会话取决于客户端适配。

本来，Reason Network已经对很多常用Agent如Claude Code， Codex，Pi等做了适配。但，轮到Grok Bot，此处有坑！

Grok Bot 的云电脑会休眠，睡着时没有进程替它收信。

于是，我让保持在线的本地机器（此处是Mac）跑一个常驻转发程序。Grok Bot 发给本地 agent 的任务由它代发，回信也回到这里；有消息需要 Grok Bot 处理时，再由它触发云端的 webhook routine，可以唤起Grok Bot。

本来我想得很简单，这个webhook 把信息传递过去就可以了，结果，又出现一个坑！消息长度超过4000个字符以后，从某个地方开始，信息被截断了！

解决方案是：让信息正文走消息通道（相当于邮箱），webhook 只负责通知Grok Bot 醒来取信，然后Grok Bot自己去取全文。

图 4：原理示意。蓝色路径传全文，橙色路径触发唤醒，绿色路径表示醒来后取信

门铃只要能把人叫来，不必把整封信都塞进去。取回的正文还要核对，没取到则请求重投。

这样，本地有问题或结果时才需要叫 Grok Bot 回来，不必为了询问进度反复唤醒它。唤醒和后续处理仍会消耗 Grok Bot 的用量，重活则由本地 agent 使用原来的环境和订阅完成。

消息只解决通信问题，不替你决定权限

在这个解决方案里，Grok Bot 发给本地会话的是任务消息。传输做加密，转发时校验签名，但这些都不能替 agent 判断一条请求该不该执行。通信通道不额外授予本机执行权限，也不会自动收紧 agent 原本已有的权限。

图 5：真实来信附带的权限提醒。协作方不能代替用户授权；这张图展示提醒内容，不代表已经证明能拦截所有提示注入

图 5：真实来信附带的权限提醒。协作方不能代替用户授权；这张图展示提醒内容，不代表已经证明能拦截所有提示注入。

所以，我不需要为了这条通道打开 Grok Bot 的本机命令自动批准。至于本地 agent 能读哪些文件、能执行哪些操作，仍然要在本地的权限和沙箱设置里决定。

从Grok Bot开始，到五路诸侯齐聚

为了检验多个Agent的通信而不是两两通信，我在起草这篇文章的时候，让 Grok Bot 安排 Claude Code 和 dsh 一起检查。dsh 可以检查自己实际怎样收到消息，Claude 则对照文档，追问其中一条判断的依据。

图 6：10 月 19 日 18:41–18:45 的实际往返，压缩了消息内容。每条箭头对应一次发送。

在这个示例中，我的整个网络名称叫做gr-network, 而每个agent会话 （一个Grok Bot被当作一个会话）都有自己的名字，一般会根据仓库-Agent自己取名，一个仓库同个agent有多个会话会自动在名字后面加序号。

这带来另一个坑：已经归档的DSH会话，会找不到收信方！为此，我目前的设计是对找不到名称的归档会话进行名称回收和复用。不过你可以以自己的习惯来修改方案。

DSH 处理示例：

图 7：dsh 端的两次回报；中间较长的技术评审内容省略。

图 7：dsh 端的两次回报。

其中一条意见，dsh 最后承认属于推断，撤回了；成立的问题和修改建议，由 Claude 汇总给 Grok Bot。

图8：Robin（Grok Bot）派出任务，Claude 与 dsh 往返评审，再将结果交回 Robin 汇总。

它们不需要共享彼此完整的会话上下文。Claude 看文档，dsh 查自己的运行记录，各自拿出能核实的东西，再通过提问把分歧说清楚。而我只需要和Grok Bot直接沟通就可以。

这也是多 Agent 参与的意义：每个会话继续处理自己熟悉的工作，需要另一边的信息时能直接问，完成后能把结果交回去。每个Agent都使用自己的环境和上下文。

注意事项

我已经把这套方案做成了Agent可以直接下载使用的github repo。代码和安装说明都在这里：https://github.com/xiaozhenliu/agent-mesh。

把链接交给你的 Claude Code 或 Codex，让它读 AGENT-INSTALL.md 安装。本地装好后，按它给出的提示在 Grok Bot 创建 webhook routine、完成云端接入；需要你操作或批准的地方，它会提醒。随后验证两边都能发起消息、收到回复。

其中grok bot创建routine后会有Webhook URL 和 key，需要给到本地脚本。

如果你的电脑上设置了TUN转发，可能还会有其他加密解密，ip地址之类的坑！详情我写在代码库里了。

目前双向实测过Grok bot 和 Claude Code、Codex、pi、dsh通信，方案适用于macOS、Linux、Windows。但仅在本地macOS + Grok Bot自带Linux 上完全跑过。Reason Network本身也在不断演进，例如我测试到一半它正好更新了dsh支持。如果你测试后有什么问题，欢迎指出，一起完善！

注意：本地机器需要保持在线，参与协作的Agent会话需要事先启动；这套通信适用于已经存在的Agent，目前不会替你把关掉的会话自动恢复成一个永久运行的 bot。