微信 AI 客服落地：只走官方通道的一条完整链路

关键词：CodeBuddy、微信、自动回复、通道选型、幂等 事实依据：企业微信开发者中心《发送消息》《全局错误码》、微信开放社区《发送客服消息》、WorkBuddy / CodeBuddy 官方文档《Headless Mode》《CLI Reference》，检索日 2026-11-02；文中标注"本机实测"处均为本人真实执行结果

引言：这个需求的首要问题不是技术问题

想做一个"微信收到消息，AI 自动回"的工具，技术方案网上一大把。但真正开始动手，第一道拦住你的题不是技术，是合规。

我最初的想法是接个人微信号——用现成的自动化方案，几小时就能跑通。真去查规范才发现这条路是死的，而且死得很彻底。

把这一层想明白之后，剩下的才是常规工程：消息怎么接、上下文怎么管、回复怎么生成、发出去失败怎么办。下面按落地顺序讲，每一节都标注了官方依据或本机实测。

一、消息接入：先把红线划出来

1.1 哪些通道能做，哪些不能做

官方规则给这条线划得很清楚：未经腾讯许可，不得使用插件、外挂或其他第三方工具、服务接入本软件和相关系统——换句话说，用外挂类工具操控账号收发消息是被禁止的，这一条既覆盖普通个人微信号，也覆盖企业微信里的员工成员账号。

企业微信《违规场景及处罚规则》里列举的对应处罚是：未经许可使用插件、外挂或第三方工具接入（多开、批量自动加好友、规避群发次数限制等）→ 永久封禁违规成员账号；情节严重或造成恶劣影响时，不排除同时封禁企业账号及管理员账号。

目前市面上还在流通的两类做法：

• 注入方式：破解本地客户端劫持收发。个人号封号概率极高；企业微信注入还要求"锁死固定版本不能升级"，一次更新即失效。
• 协议方式：模拟客户端协议完成收发。技术上可行，但属于违规灰色地带。

这两条我都不做，本方案也不涉及。

1.2 官方可用通道对比

选型的关键约束是48 小时 / 5 条。这是平台规则，绕不过去，只能在设计里尊重它——我把它做成了本地主动拦截，而不是等接口报错（见第五节）。

二、整体架构：五层，以及各层的边界

整条链路是五段：

微信服务器 → ① 消息接入 → ② 上下文组装 → ③ 回复生成 → ④ 合规闸门 → ⑤ 回传发送 → 微信服务器

各层的职责边界我划得很死，因为边界不清是这类系统后期最难查的问题：

为什么要单独做一层闸门？ 因为生成是概率性的、发送是确定性副作用，这两件事必须解耦。否则"模型说了不该说的话"和"消息发不出去"会缠在一起，日志里只看到一个失败。闸门在生成之后、发送之前，且只有否决权（长度裁剪是唯一允许的修改，且必须记录）。

2.1 生成层为什么是双通道

这里有个必须先澄清的事实：CodeBuddy 不是一个可被外部程序直接调用的推理 API。它对外是 MCP、连接器、CLI 三种集成方式，其中适合"外部系统程序化调用它生成内容"的只有 CLI 无头模式：

codebuddy -p "根据上下文生成一条简短的客户回复" \
          --output-format json \
          --append-system-prompt "你是企业客服，语气专业克制，只回答事实性问题。" \
          --allowedTools "Read,mcp__kb__search" \
          --mcp-config ./config/mcp_servers.json

常用参数与用途：--append-system-prompt 注入业务规则、--resume <session_id> 复用多轮会话、--allowedTools / --disallowedTools 限定工具能力面、--mcp-config 挂载知识库。

据此我做了两条通道：

默认走 B，需要检索或工具时路由到 A；A 失败自动降级 B。

三、上下文管理：客服场景的默认答案是"短"

会话标识用 渠道 + 会话ID + 用户ID 三段哈希，避免跨渠道串号，同时必须把映射落库——否则无法把回复发回正确的会话。

上下文分三层：系统层（业务规则、语气、拒答策略，常驻）、摘要层（超出窗口的早期对话压缩）、原文层（最近 K 轮）。裁剪时按 token 预算从最近往回填，保证最近轮次完整不被截半。

过期清理分三档 TTL：原始消息 7 天、摘要 30 天、会话元数据 90 天。清理用惰性删除 + 每日定时兜底，避免实时路径变慢。

一个反直觉的取舍：微信客服和 ChatGPT 不一样——用户不会主动开新会话，一条消息往往就是一次独立问答。所以默认短窗口 + 强摘要，只有检测到"同一话题连续追问"才启用多轮记忆。强行拼历史会让回复答非所问，在客服场景那是负资产。

四、回复生成：模板、规则与兜底

提示词模板与业务规则分离：模板管结构，规则从配置注入，代码里不硬编码业务。

你是{brand}的在线客服助理。

# 身份与语气
{persona}

# 业务规则（按优先级从高到低，必须逐条遵守）
{rules}

# 输出格式
{output_format}

# 禁止事项
{forbidden}

规则以结构化配置存在，便于审计与热更新，例：不承诺任何时间、金额、赔付比例（优先级 90）、涉及法律判断只说明事实与流程，不做结论性意见（优先级 100）。

兜底分四级，任何一级都不能让异常冒到上层：

固定话术本身必须合规、不承诺任何事项——这是它在故障时仍能安全发出去的前提。

五、消息回传：幂等、预算与失败补偿

幂等做三层，缺一不可：

发送层的 msgid 之所以能防重，前提是官方要求这个 msgid 在客服账号内唯一，否则接口直接返回错误——注意，唯一性得由本地维护，接口并不替你幂等。也就是说，去重的可靠性来自本地发送记录，而不是平台兜底：重试之前先查本地表，命中就跳过，别指望重复提交同一个 msgid 会被平台静默吞掉。

关于"引用回复"：微信客服接口的现有公开文档未提供引用回复能力（未见 quote 字段）。所以关联原消息只能靠三个手段：会话级关联（回复天然落在同一会话）、msgid 幂等、业务侧可选前缀（如"关于您刚才问的："）。若强需求"引用某条具体消息"，现有公开接口没有现成手段，得改走图文或小程序卡片这类富文本通道。

发送预算本地主动拦截。48 小时 5 条是硬上限，我的实现是维护每会话的 {window_start, count}，发送前先判 count < 5，不够就不发、直接转人工——不等微信回 95001 才发现超了。用户新消息到达时重置窗口。

失败补偿。官方明确写了"接口返回成功不代表消息最终发送成功"，所以必须监听消息发送失败事件回调，把这类消息写进待补偿队列。

六、五个真实坑（前两个来自规范，后三个来自实测）

坑 1：个人号自动化不是"有风险"，是"必封"。 很多人把这里当成灰色地带，实际上官方处罚规则写得很死：外挂类行为永久封禁成员账号，情节严重或造成恶劣影响时，不排除连带封禁企业账号与管理员账号。账号资产是企业资产，别拿它试错。

坑 2：48 小时 / 5 条会悄悄决定你的产品形态。 用户不主动发消息，你连追一条的机会都没有。如果业务需要长期跟进，只能引导用户订阅消息，或在 48 小时窗口内主动发一条"已收到，正在核实"。这限制应该在设计阶段想清楚，而不是上线后才发现。

坑 3（实测）：接口返回成功不等于送达。 这条写在官方文档里，但我是在实际联调时才重视起来——它意味着必须有失败事件监听与补偿队列，否则你会看到"日志全绿，用户说没收到"。

坑 4（实测）：WorkBuddy CLI 与桌面端共存会端口冲突。

Error: listen EADDRINUSE: address already in use 127.0.0.1:13222 (use --port <number> to choose another port)

桌面端已占用默认端口，CLI 无头模式直接启动失败。解法是显式指定空闲端口（--port 13233）。另外 Windows 下 bin/codebuddy 是无扩展名的 shell 脚本，PowerShell 不能直接执行，需用 node 驱动或自行封装。

坑 5（实测）：未登录时 CLI 拒绝执行。

Authentication required. Please use /login command to sign in to your account

无头模式不携带交互式登录态，必须先完成一次授权；token 到期后所有调用会以同样方式失败。这不是偶发故障，是可预期的周期性事件，必须进监控，否则表现就是"服务突然全挂"。

七、怎么验证它真的能用

我在本机把这套骨架跑通了，测试覆盖这几条关键路径（全部通过）：

上线前必须过的四道检查：① 只用官方接口，全链路无注入组件；② 48h/5 条预算已本地拦截；③ 三层幂等都生效；④ 密钥只从环境变量读，日志里密钥一律脱敏。建议灰度：单客服账号 + 1% 流量，观察一周再放量。

八、Q&A

Q1：为什么不做个人微信自动化？规范明确禁止，且处罚是永久封禁，连带企业账号。技术上能跑通不等于能长期运营。

Q2：48 小时限制能绕过去吗？不能，这是平台规则。只能尊重它：窗口内主动发一条确认消息引导用户，或引导用户订阅消息。

Q3：WorkBuddy CLI 适合做高并发吗？不适合。它更像是"复杂请求的专家通道"，不是流水线默认通道——单次调用延迟高、登录态会过期、难以水平扩展。高频短回复应该走模型 API 直连。

Q4：自动回复能替代人工吗？不能。投诉、索赔、监管类意图必须转人工，这条我在规则层写死了，但兜底话术挡不住所有情况。

Q5：怎么保证不重复回复？三层幂等：接收用平台 msgid，发送用自生成的账号内唯一 msgid，中间层用 msgid+stage 标记阶段。

参考资料

• 企业微信开发者中心，《发送消息》（kf/send_msg 接口说明、48 小时 5 条限制、权限配置要求）
• 企业微信开发者中心，《全局错误码》（95001 次数限制 / 95002 时间限制 / 95018 会话状态或超 48 小时 / 45024 企业人数上限 / 40014 access_token 参数错误）
• 企业微信开放平台，《违规场景及处罚规则》（外挂类行为与封禁范围）
• 微信开放社区，《发送客服消息》（小程序与公众号客服消息额度说明）
• WorkBuddy / CodeBuddy 官方文档，《Headless Mode》《CLI Reference》（-p、--output-format、--append-system-prompt、--resume、--allowedTools、--mcp-config）