大家好我是二哥呀。昨天看到逛逛开源的 wechat-claude-code可以在微信里爽用 Claude Code我就想把这个功能引入到 PaiCLI 中。现在有了 Codex 和 Claude Code基本上只要有想法就可以很快去落地。给大家展示一下已经实现了基本的交互哈这markdown也是支持的分段搞得也是像模像样。这里多说一句。PaiCLI 是我用 Claude CodeCodex 开发的一个类 Qoder CLI 的 Agent 工具主要就是想给大家提供一个 Agent CLI 的实战体验。整体的交互体验参考了 Qoder CLI并且体验还是非常不错的虽然没办法和顶级的商业产品相比但阅读代码做一些多 Agent 调研使用 Chrome Devtools MCP 打开微信文章这些基本操作都已经实现了。其实之前写 OpenClaw 的微信交互方案的时候就觉得很有趣。今天有空刚好可以实践一下。我也会把自己完整的开发方案分享出来供大家在使用 Claude Code/Codex 开发的时候做一些参考。OK系好安全带我们粗粗粗发01、Codex 调研微信连 CC 的方案这一步非常关键。需要先搞清楚微信连 CC 的技术原理是什么。直接把这个提示词发给 Codex。wechat-claude-code 研究一下是什么原理为什么能在微信里链接 Claude Code微信侧靠 iLink Bot API扫码登录、长轮询收消息、发消息、发“正在输入”。这些关键词需要调研清楚。本机 daemon 负责收发与排队相当于 OpenClaw 当时的 Gateway方案是长轮询微信消息拿到消息后进入队列再调用 ClaudeClaude Code 侧就是启动本地 claude 进程通过把微信消息写进 stdin从 stdout 读取 Claude Code 的 stream-json 输出解析增量文本再流式推回微信。整体的技术方案并不复杂。但为了不出错我特意补了一手新的信息源。结合 https://paicoding.com/wechat-openclaw 这篇里提到的tencent-weixin/openclaw-weixin-clilatest两个之间有什么关联刚好我直接在实践微信官方的 clawbot 方案的时候写过一篇帖子里面提到了 openclaw-weixin-cli 插件。两种方案结合在一起就可以确认了。扫码拿 token、getupdates 长轮询收消息、sendmessage 回消息、context_token 路由会话、媒体走 CDN/AES、sendtyping 展示“正在输入”。搞清楚之后我们就要 Codex 给我们一个出完整的技术方案了。一定要确认清楚Codex 的理解和我们的理解是一致的。不理解的就和 Codex 反复沟通。否则后期开发很容易出错。所以大家有没有发现AI 确实很厉害了但依然需要我们开发者和 AI 之间保持同频。如果不能保持同频你就没办法描述清楚需求AI 搞错了你也发现不了。这一点非常非常的关键。02、Claude 再次确认调研对于我能力之外的需求我一般还会让 Claude 再次确认一下。方法很简单。就是让 Codex 把计划输出到文件中再把文件交给 Claude。刚好有最顶级的 Fable 5 可以用直接让调研分析一番。要做的不是“关 HITL”而是把交互式审批换成非交互式策略。iLink 扫码登录的是一个微信账号getupdates 会收到所有给这个号发消息的人。如果只校验 boundUserId sender那没绑定的人发来的消息怎么处理觉得 Claude 说的对的就可以修改一下开发计划。如果你没有 ClaudeCodex 重新开一个子 Agent 去做这件事也是 OK 的。开一个 subagent 重新审查一下我们的计划看看有没有漏洞记住一定要是子 Agent正所谓旁观者清当局者迷。主 Agent 很有可能会陷入定性思维觉得自己之前的计划是对的。看到没AI 时代并不意味着开发者就可以不动脑子相反我觉得开发者需要比以前更动脑子。否则你就会跟不上 AI 的理解和能力。就没办法发挥出 AI 的威力。啧啧啧。03、开发和测试开发阶段就很简单了。放到 docs/phase-23-wechat-channel.md 了开始实施吧这一步也可以交给一些物美价廉的 LLM比如说 DeepSeek V4 Pro也基本上不会出错。因为我们已经把开发需求讨论清楚了。剩下的其实就看我们个人对产品的把控了。比如说我觉得整个交互体验有点问题第一微信里收到的回复很奇怪啊思考过程如果要返回给微信侧的话应该也需要一个正常的 SSE 过程或者说不需要显示思考过程吧思考过程应该是在 PaiCLI 这侧显示才对再比如说交互方式应该优化为进入 PaiCLI 主交互后输入 /wechat扫码绑定并后台启动微信通道。你想要什么样的效果就反复和 Claude Code/Codex 沟通就好了。顶级模型的编码能力我觉得都很强了你想要什么样的功能什么样的交互体验基本上都可以实现。04、微信PaiCLI 的原理整体架构分三层。微信用户发一条消息PaiCLI 本地进程收到后交给 Agent 处理Agent 的输出再推回微信。连接层iLink Bot APIiLink Bot API 是微信官方提供的 Bot 网关所有和微信的通信都经过它。连接的第一步是扫码登录。PaiCLI 调用 iLink 的二维码接口拿到一个临时二维码用户在微信上扫码确认后iLink 返回一个 bot_token。后续所有请求都要带着这个 token相当于身份凭证。登录完成后PaiCLI 会把 token、账号 ID、绑定的用户 ID、工作区路径这些信息持久化到本地的 JSON 文件里。下次启动微信通道时直接读取本地凭证不需要重新扫码。只有当 iLink 返回 session expired错误码 -14时才需要重新绑定。收消息用的是长轮询。PaiCLI 向 iLink 发一个 getUpdates 请求带上一个同步游标syncBufiLink 会一直连着这个请求直到有新消息或者超时默认 35 秒才返回。有消息就返回消息列表和新的游标没消息就返回空。下一轮请求会带上新游标循环往复。iLink 会有一个 context_token 字段用来标识会话上下文。同一个用户在不同聊天窗口发的消息context_token 是不一样的回消息的时候要带上对应的 token否则消息会发到错误的窗口。长轮询的超时时间也是自适应的。首次启动用 35 秒作为默认值之后 iLink 服务端会在响应里带一个建议的超时时间PaiCLI 据此调整下一轮请求的等待时间。Agent 任务运行期间轮询超时会缩短到 3 秒这样可以更及时地检查 Agent 是否完成和刷新 typing 状态。发消息用 sendMessage 接口发“正在输入”状态用 sendTyping 接口。sendTyping 比较特殊需要先调一次 getConfig 拿到一个临时的 typing_ticket再用这个 ticket 去设置状态。每隔 5 秒刷新一次否则微信那边的“对方正在输入”提示就会消失。消息引擎消息引擎是整个微信通道的调度中枢。核心是一个事件循环。PaiCLI 启动微信通道后进入一个 while 循环每轮做三件事检查当前 Agent 任务是否完成、消费消息队列、发起下一轮长轮询。收到消息后先做两道过滤。第一道是消息去重用消息 ID 做判断避免网络抖动导致同一条消息被处理两次。第二道是身份校验只处理绑定用户发来的消息其他人发来的直接丢弃并记录日志。之后是命令解析。微信用户可以发送斜杠命令来控制通道。/help查看帮助/status查看通道状态和队列深度/clear清空当前会话历史/compact手动压缩上下文/pause暂停消息消费/resume恢复消费/stop取消正在运行的 Agent 任务消息队列是一个先进先出的队列每次 Agent 空闲时从队列头部取一条消息提交给 Agent 会话。提交之前先给微信用户发一个“正在输入”的状态提示Agent 运行期间每 5 秒刷新一次让用户知道 PaiCLI 在工作中。消息解析这块也需要处理多种消息类型。iLink 返回的每条消息里有一个 item_list 数组每个 item 可能是文本、语音转文字、图片或者文件。文本和语音转文字直接拼成提示词图片和文件会被标记为媒体附件。AgentAgent 负责把微信用户的消息交给大模型处理。PaiCLI 在启动微信通道时会创建一个 Agent 会话实例包含一个单线程的异步执行器。用户消息提交后Agent 在后台线程里执行不阻塞消息引擎的事件循环。这样消息引擎可以继续轮询新消息、响应旁路命令、刷新 typing 状态。上下文管理方面/clear会清空整个对话历史/compact会调用 LLM 对当前历史做一次摘要压缩。输出适配第一简化 Markdown。去掉代码块的语言标记java →、去掉标题的#前缀、去掉加粗的**标记。第二消息分段。微信单条消息有长度限制适配器把超过 3800 字符的回复按换行符切分成多条消息依次发送。第三思考过程和工具调用细节不发到微信微信用户只收到最终的文字回复。微信渲染器还做了流式发送。不是等 Agent 完全执行完才一次性推消息而是每积攒 180 个字符或者每隔 1.2 秒就 flush 一次让微信用户能实时看到回复在“打字”体验上更接近聊天而不是等邮件。05、PaiCLI 如何写到简历上项目名称PaiCLI 微信通道项目简介基于 iLink Bot API 的微信接入方案让用户通过微信消息与本地运行的 AI Agent 交互支持代码阅读、文件操作、多模型切换等功能。技术栈Java 21、OkHttp、Jackson、iLink Bot API、长轮询、非交互式安全策略核心职责基于 iLink Bot API 实现扫码登录和长轮询消息收发消息延迟控制在 1 秒内设计消息引擎的事件循环和异步队列调度支持旁路命令即时响应和普通消息排队处理开发双渲染器架构Agent 输出同时分发到本地终端和微信微信侧自动过滤思考过程、ANSI 码和 Markdown 格式支持 daemon 后台进程管理实现 7×24 小时无人值守运行提供 start/stop/restart/logs 全套运维命令
用Codex+iLink Bot API给Agent接入微信，基于这个开源Skill
大家好我是二哥呀。昨天看到逛逛开源的 wechat-claude-code可以在微信里爽用 Claude Code我就想把这个功能引入到 PaiCLI 中。现在有了 Codex 和 Claude Code基本上只要有想法就可以很快去落地。给大家展示一下已经实现了基本的交互哈这markdown也是支持的分段搞得也是像模像样。这里多说一句。PaiCLI 是我用 Claude CodeCodex 开发的一个类 Qoder CLI 的 Agent 工具主要就是想给大家提供一个 Agent CLI 的实战体验。整体的交互体验参考了 Qoder CLI并且体验还是非常不错的虽然没办法和顶级的商业产品相比但阅读代码做一些多 Agent 调研使用 Chrome Devtools MCP 打开微信文章这些基本操作都已经实现了。其实之前写 OpenClaw 的微信交互方案的时候就觉得很有趣。今天有空刚好可以实践一下。我也会把自己完整的开发方案分享出来供大家在使用 Claude Code/Codex 开发的时候做一些参考。OK系好安全带我们粗粗粗发01、Codex 调研微信连 CC 的方案这一步非常关键。需要先搞清楚微信连 CC 的技术原理是什么。直接把这个提示词发给 Codex。wechat-claude-code 研究一下是什么原理为什么能在微信里链接 Claude Code微信侧靠 iLink Bot API扫码登录、长轮询收消息、发消息、发“正在输入”。这些关键词需要调研清楚。本机 daemon 负责收发与排队相当于 OpenClaw 当时的 Gateway方案是长轮询微信消息拿到消息后进入队列再调用 ClaudeClaude Code 侧就是启动本地 claude 进程通过把微信消息写进 stdin从 stdout 读取 Claude Code 的 stream-json 输出解析增量文本再流式推回微信。整体的技术方案并不复杂。但为了不出错我特意补了一手新的信息源。结合 https://paicoding.com/wechat-openclaw 这篇里提到的tencent-weixin/openclaw-weixin-clilatest两个之间有什么关联刚好我直接在实践微信官方的 clawbot 方案的时候写过一篇帖子里面提到了 openclaw-weixin-cli 插件。两种方案结合在一起就可以确认了。扫码拿 token、getupdates 长轮询收消息、sendmessage 回消息、context_token 路由会话、媒体走 CDN/AES、sendtyping 展示“正在输入”。搞清楚之后我们就要 Codex 给我们一个出完整的技术方案了。一定要确认清楚Codex 的理解和我们的理解是一致的。不理解的就和 Codex 反复沟通。否则后期开发很容易出错。所以大家有没有发现AI 确实很厉害了但依然需要我们开发者和 AI 之间保持同频。如果不能保持同频你就没办法描述清楚需求AI 搞错了你也发现不了。这一点非常非常的关键。02、Claude 再次确认调研对于我能力之外的需求我一般还会让 Claude 再次确认一下。方法很简单。就是让 Codex 把计划输出到文件中再把文件交给 Claude。刚好有最顶级的 Fable 5 可以用直接让调研分析一番。要做的不是“关 HITL”而是把交互式审批换成非交互式策略。iLink 扫码登录的是一个微信账号getupdates 会收到所有给这个号发消息的人。如果只校验 boundUserId sender那没绑定的人发来的消息怎么处理觉得 Claude 说的对的就可以修改一下开发计划。如果你没有 ClaudeCodex 重新开一个子 Agent 去做这件事也是 OK 的。开一个 subagent 重新审查一下我们的计划看看有没有漏洞记住一定要是子 Agent正所谓旁观者清当局者迷。主 Agent 很有可能会陷入定性思维觉得自己之前的计划是对的。看到没AI 时代并不意味着开发者就可以不动脑子相反我觉得开发者需要比以前更动脑子。否则你就会跟不上 AI 的理解和能力。就没办法发挥出 AI 的威力。啧啧啧。03、开发和测试开发阶段就很简单了。放到 docs/phase-23-wechat-channel.md 了开始实施吧这一步也可以交给一些物美价廉的 LLM比如说 DeepSeek V4 Pro也基本上不会出错。因为我们已经把开发需求讨论清楚了。剩下的其实就看我们个人对产品的把控了。比如说我觉得整个交互体验有点问题第一微信里收到的回复很奇怪啊思考过程如果要返回给微信侧的话应该也需要一个正常的 SSE 过程或者说不需要显示思考过程吧思考过程应该是在 PaiCLI 这侧显示才对再比如说交互方式应该优化为进入 PaiCLI 主交互后输入 /wechat扫码绑定并后台启动微信通道。你想要什么样的效果就反复和 Claude Code/Codex 沟通就好了。顶级模型的编码能力我觉得都很强了你想要什么样的功能什么样的交互体验基本上都可以实现。04、微信PaiCLI 的原理整体架构分三层。微信用户发一条消息PaiCLI 本地进程收到后交给 Agent 处理Agent 的输出再推回微信。连接层iLink Bot APIiLink Bot API 是微信官方提供的 Bot 网关所有和微信的通信都经过它。连接的第一步是扫码登录。PaiCLI 调用 iLink 的二维码接口拿到一个临时二维码用户在微信上扫码确认后iLink 返回一个 bot_token。后续所有请求都要带着这个 token相当于身份凭证。登录完成后PaiCLI 会把 token、账号 ID、绑定的用户 ID、工作区路径这些信息持久化到本地的 JSON 文件里。下次启动微信通道时直接读取本地凭证不需要重新扫码。只有当 iLink 返回 session expired错误码 -14时才需要重新绑定。收消息用的是长轮询。PaiCLI 向 iLink 发一个 getUpdates 请求带上一个同步游标syncBufiLink 会一直连着这个请求直到有新消息或者超时默认 35 秒才返回。有消息就返回消息列表和新的游标没消息就返回空。下一轮请求会带上新游标循环往复。iLink 会有一个 context_token 字段用来标识会话上下文。同一个用户在不同聊天窗口发的消息context_token 是不一样的回消息的时候要带上对应的 token否则消息会发到错误的窗口。长轮询的超时时间也是自适应的。首次启动用 35 秒作为默认值之后 iLink 服务端会在响应里带一个建议的超时时间PaiCLI 据此调整下一轮请求的等待时间。Agent 任务运行期间轮询超时会缩短到 3 秒这样可以更及时地检查 Agent 是否完成和刷新 typing 状态。发消息用 sendMessage 接口发“正在输入”状态用 sendTyping 接口。sendTyping 比较特殊需要先调一次 getConfig 拿到一个临时的 typing_ticket再用这个 ticket 去设置状态。每隔 5 秒刷新一次否则微信那边的“对方正在输入”提示就会消失。消息引擎消息引擎是整个微信通道的调度中枢。核心是一个事件循环。PaiCLI 启动微信通道后进入一个 while 循环每轮做三件事检查当前 Agent 任务是否完成、消费消息队列、发起下一轮长轮询。收到消息后先做两道过滤。第一道是消息去重用消息 ID 做判断避免网络抖动导致同一条消息被处理两次。第二道是身份校验只处理绑定用户发来的消息其他人发来的直接丢弃并记录日志。之后是命令解析。微信用户可以发送斜杠命令来控制通道。/help查看帮助/status查看通道状态和队列深度/clear清空当前会话历史/compact手动压缩上下文/pause暂停消息消费/resume恢复消费/stop取消正在运行的 Agent 任务消息队列是一个先进先出的队列每次 Agent 空闲时从队列头部取一条消息提交给 Agent 会话。提交之前先给微信用户发一个“正在输入”的状态提示Agent 运行期间每 5 秒刷新一次让用户知道 PaiCLI 在工作中。消息解析这块也需要处理多种消息类型。iLink 返回的每条消息里有一个 item_list 数组每个 item 可能是文本、语音转文字、图片或者文件。文本和语音转文字直接拼成提示词图片和文件会被标记为媒体附件。AgentAgent 负责把微信用户的消息交给大模型处理。PaiCLI 在启动微信通道时会创建一个 Agent 会话实例包含一个单线程的异步执行器。用户消息提交后Agent 在后台线程里执行不阻塞消息引擎的事件循环。这样消息引擎可以继续轮询新消息、响应旁路命令、刷新 typing 状态。上下文管理方面/clear会清空整个对话历史/compact会调用 LLM 对当前历史做一次摘要压缩。输出适配第一简化 Markdown。去掉代码块的语言标记java →、去掉标题的#前缀、去掉加粗的**标记。第二消息分段。微信单条消息有长度限制适配器把超过 3800 字符的回复按换行符切分成多条消息依次发送。第三思考过程和工具调用细节不发到微信微信用户只收到最终的文字回复。微信渲染器还做了流式发送。不是等 Agent 完全执行完才一次性推消息而是每积攒 180 个字符或者每隔 1.2 秒就 flush 一次让微信用户能实时看到回复在“打字”体验上更接近聊天而不是等邮件。05、PaiCLI 如何写到简历上项目名称PaiCLI 微信通道项目简介基于 iLink Bot API 的微信接入方案让用户通过微信消息与本地运行的 AI Agent 交互支持代码阅读、文件操作、多模型切换等功能。技术栈Java 21、OkHttp、Jackson、iLink Bot API、长轮询、非交互式安全策略核心职责基于 iLink Bot API 实现扫码登录和长轮询消息收发消息延迟控制在 1 秒内设计消息引擎的事件循环和异步队列调度支持旁路命令即时响应和普通消息排队处理开发双渲染器架构Agent 输出同时分发到本地终端和微信微信侧自动过滤思考过程、ANSI 码和 Markdown 格式支持 daemon 后台进程管理实现 7×24 小时无人值守运行提供 start/stop/restart/logs 全套运维命令
