一、要解决的问题
Claude Code、Codex 这类本地 AI 编程工具默认只能在电脑前用。出门在外想让它跑个脚本、改份文件、排个版，传统思路是：
- 买公网 IP / 域名
- 做内网穿透（frp、ngrok、cloudflare tunnel）
- 在本地起服务，把端口暴露出去
这三条路都能走通，但都在解决同一个问题：外部如何主动访问我的电脑。而我真正需要的只是：让电脑里的 Agent 收到一条任务指令。
这篇文章分享一种更轻的实现：用微信消息做触发器，电脑主动连出去轮询消息，本地执行后再把结果送回来。整条链路不存在由外部主动发起的入站连接，也不需要公网 IP。
二、方案总览
整个链路可以拆成 6 段：
| 阶段 | 组件 | 职责 |
|---|---|---|
| 触发端 | 手机微信 | 发送指令，如「把这篇文章排个版」 |
| 协议层 | 微信消息中转服务（我用的 iLink） | 接收微信消息，提供可轮询的 API |
| 渠道桥 | clawbot（自研） | 轮询中转服务，接入消息并归一化，回发结果 |
| 路由/权限 | bot_core | 检查白名单、路由命令、管理上下文 |
| 执行端 | ClaudeRunner | 调用本地 Agent 的 CLI，读取文件、跑命令、生成结果 |
| 回流 | clawbot / lark-cli | clawbot 直接把文本/图片/文件回传微信；lark-cli 把长结果写进飞书文档，再回传链接 |
架构图示：
手机微信 │ │ 发送消息 ▼ iLink 中转服务 ▲ │ 主动轮询 │ clawbot（本地） │ │ IncomingMessage / TurnRequest ▼ bot_core │ │ 路由命令 ▼ ClaudeRunner │ │ 启动本地 Agent ▼ 本地 Agent（Claude Code / Codex 等） │ │ 文本 / 图片 / 文件 ▼ clawbot ───────────▶ 微信 │ │ 长结果 / 文档 ▼ lark-cli → 飞书文档 → 链接回微信三、关键设计一：不另起 Agent，只借微信协议层
腾讯开源了openclaw-weixin插件，做的是「用微信操控 OpenClaw 这个 AI Agent」。我本地使用的是 Claude Code 和 Codex，所以并不能完全照搬过来。
我只复用了它的通信协议这一层，接入、归一化、回发这些逻辑用标准库自己实现，整个桥梁叫 clawbot。它只做三件事：
- 接入：通过 iLink Bot API 把微信私聊消息收进来；
- 归一化：把 iLink 消息格式转成平台无关的
IncomingMessage； - 回发：把
bot_core处理后的结果发回微信。
clawbot不实现 AI 对话逻辑。意图识别、命令路由、模型调用、工具执行全部委托给bot_core与ClaudeRunner。
真正的执行仍然交给已有的 bot_core：它检查身份、路由命令，再调用 ClaudeRunner 启动我电脑里的 Agent。
四、关键设计二：利用出站连接绕过 NAT
家庭宽带的 NAT，默认阻断的是外部发起的入站连接。外部请求无法直接定位到内网中的某台设备。但由内网主动发起的出站连接是畅通的：浏览器、微信、SSH 出去都是电脑自己连出去。
所以我没有让手机直接连电脑，而是让电脑主动连 iLink：
电脑 ──出站──▶ iLink ◀──微信── 手机这条链路里：
- 手机把消息发给微信服务器
- 微信把消息同步到 iLink
- 电脑上的 clawbot 主动轮询 iLink，问一句「有新消息吗」
- 有新消息就拉下来处理，没消息就空转
- 消息经 bot_core 路由，由 ClaudeRunner 执行本地 Agent
- Agent 在本地执行任务，结果经 bot_core 交回 clawbot，再通过 iLink 回到微信
手机到电脑的数据流向看起来是「反向」的，但网络连接方向始终是电脑主动出站。因此不需要公网 IP、不需要端口映射、不需要内网穿透。整条链路中，不存在由外部主动发起的入站连接。
五、关键设计三：任务执行与结果闭环
一开始我以为，「能触发、能收到完成通知」就够了。实际用下来发现还差半步：任务结果还躺在电脑里，人在外面只能收到一句「写完了」。
clawbot 本身就能把 Agent 的输出（文本、图片、文件）回传到微信。但对于写文章、跑数据这类长结果，直接发在微信里并不方便阅读和批注。所以我把lark-cli接进了链路：Agent 跑完后调用lark-cli把结果写进飞书文档，再把文档链接回给我。
完整调用链（以写入飞书文档为例）：
手机微信 ↓ iLink ↓ clawbot ↓ bot_core ↓ ClaudeRunner → 本地 Agent ↓ lark-cli create-doc --content ... ↓ 飞书文档链接 → 回传微信如果只是返回简短文本或图片，Agent 输出经 bot_core 直接由 clawbot 回传微信即可，不需要经过飞书。
手机上点开链接就是可阅读、可批注、可转发的内容，而不只是「完成」两个字。
六、安全设计：三道闸
远程触发本地高权限工具，风险很直接。电脑里的 Agent 能读文件、跑脚本、改代码；手机远程发来的，已经不只是一条聊天消息，而是一条可能在本机执行的指令。
我给自己留了三道闸：
第一道：身份白名单
bot_core 只响应预先配置的微信身份。没在白名单里的消息直接丢弃，避免任何人都能往你的电脑发指令。
第二道：按项目指定工作目录
每个任务默认在指定项目目录下启动 Agent，避免日常任务一上来就在整个家目录里找文件。
但这里必须说清楚：工作目录只是默认活动范围，不是安全隔离。尤其开了 Agent 的--dangerously-skip-permissions后，它仍然可以访问目录外的文件。这个参数的名字已经把风险写明白了。
第三道：系统级隔离
对于高风险任务，用受限账户、沙箱或容器运行 Agent。白名单解决「谁能发」，工作目录解决「默认从哪开始」，真正的隔离才解决「出事时能碰到哪里」。
七、踩坑与选型建议
1. 微信消息中转必须走 iLink 吗？
我用的是 iLink（ilinkai.weixin.qq.com），这是腾讯内部的微信 Bot 网关，通过 openclaw-weixin 扫码登录接入。理论上换成其他方案也能实现同样思路——Wechaty 的多协议 Puppet、Windows 上的 wxhelper / WeChatFerry（Hook 注入个人微信进程）、企业微信官方 API（wechatpy）都能提供可轮询/可推送的消息通道。但每种方案在协议稳定性、封号风险、平台限制上差别很大，clawbot 的protocol.py也需要相应改写。如果只是想跑通这套思路，我推荐直接沿用 iLink 路径；换协议前先评估账号风险。
2. 为什么不直接用飞书/钉钉机器人？
也可以。我选微信是因为手机里最常打开的就是它，发起任务的摩擦最小。飞书更适合看工具调用和执行状态；微信第一版只给结果。
3. 轮询会不会很费资源？
clawbot 轮询间隔可以配置，平时 5-10 秒一次，只发一个 HTTP 请求，资源消耗极低。也可以配合 iLink 的长轮询或 webhook 做优化，但第一版先保证简单可靠。
4. 为什么不直接内网穿透？
内网穿透解决的是「从外面访问本地服务」，而我需要的是「让本地任务被触发」。如果只是为了发一条指令，让电脑主动出站比暴露端口到公网安全得多。
5. Agent 的权限提示怎么处理？
远程运行时建议先在本地把常用操作跑一遍，让 Agent 记住权限选择；或者给 bot_core 配置一个固定的允许列表。不要每次远程任务都弹权限确认，否则体验会崩。
八、总结
这套方案的核心不是「怎么从外面控制电脑」，而是「怎么让电脑主动建立出站连接来接任务」。
它的价值在于：
- 无需公网 IP 或内网穿透
- 不引入第二套 Agent 框架
- 复用已有的 bot_core + Agent + lark-cli 工具链
- 通勤、外出时也能把短任务发出去，回来直接看结果
如果你也在用本地 Agent 做工作流，不妨先问问自己：我真的需要让外部连进电脑吗？与其研究怎么让外部连入电脑，不如让电脑主动建立出站连接。
我是 RestartHua，C++ 老兵，现在用 Python 和 AI 做工具、写文章。
 agent和组件)