抖音评论里捞到高意向客户、加进企微、多轮 AI 代回——这条获客链路的最后一棒，官方到底给不给 API？一份把官方文档、开源生态、我们自己的踩坑史放在一起的技术档案。
// 调研日期 2026-07-21 · 官方文档逐条实抓 · 三路并行取证
「运营的员工企微号、好友一对一单聊、客户发消息→程序自动多轮回」——在企微官方体系里没有任何合规接口能做，2024–2026 也没放开的迹象。能做到的方案全在灰色地带。
Akke 的获客链路是一条流水线：抖音公域捞人 → 判意向 → 私信触达 → 加进企微 → 在企微里多轮跟进。前面几段都自动化了，卡点就在最后这一棒——企微好友单聊里的多轮 AI 代回。
企微这一棒现在跑的是云电脑 GUI 自动化（wecom_reply_loop.py）：截屏让视觉模型「看」聊天窗读消息 → 调 chatReply 生成话术 → GUI 逐字打字发送。能跑，但脆——靠盯屏、坐标会漂、发送方判断非确定性、且封号风险始终悬着。于是自然要问：这一棒能不能换成官方 API？
企微开放平台里，涉及「给外部客户发消息」的接口就这四条。逐条对着官方文档实抓核实——每条都在「好友单聊多轮自动回复」这个需求上撞墙，只是撞的方式不同。
用户点名要看的这条接口——只能发给企业内部成员。接收者只有 touser / toparty / totag 三种，全是组织架构维度，文档通篇没有 external_userid，触达不到外部客户。
能定向到单个外部客户（一次上限 1 万人）。但 API 调用不直接发出——只创建群发任务、推到成员客户端的「群发助手」，必须员工手动点「发送」。且是单向推送，客户回复走不回 API，不构成会话。
唯一官方全自动多轮通道，能接 LLM。但严格被动：用户先发消息后 48 小时内、最多回 5 条；用户再发言才重置。且客户走的是「微信客服号入口」——不是运营员工号的好友关系，没有人设、朋友圈、好友这一层。
能拉到运营号与外部好友单聊的全量消息，但没有任何发送能力。技术上可做「入站读取」的一条腿，代价是：付费席位 + 客户端明示「聊天记录将被存档」+ 客户需知情同意，且拉取有延迟。
官方 2025 年上了「智能机器人」（支持流式回调接大模型），是最接近的新东西——但它只对企业内部成员开放（内部单聊 / 内部群 @），刻意绕开了「外部好友身份」。若未来向外部客户开放，才有翻盘可能，现在够不着。
把所有候选通路（含我们现状的云电脑 GUI）摊在同一张热力图上：能不能主动发外部、能不能真多轮、保不保住好友身份、接不接 LLM、合不合规不封号。绿=满足，黄=受限，红=不满足。
只有最后一行「云电脑 GUI」五个维度全绿——但它换来的代价是最后一格：合规红线。官方那五条里，凡是「合规不封号」的，必然在「主动发 / 多轮 / 好友身份」某一格是红或黄。合规与「员工号好友单聊全自动」在企微生态里互斥，这是整份调研最硬的结论。
既然官方不给，社区怎么做？关键前提：「个人微信」和「企业微信」是两套完全不同的生态——绝大多数明星 hook / 协议项目做的是个人微信，针对企微且能规模化的极少。先看封号风险排序（估值，立项前需逐仓核对）：
个微 pad/iPad 协议（gewechat 系）正被腾讯风控，还传出 Wechaty iPad 协议方被腾讯起诉。企微协议逆向门槛/风险更高，社区基本没有开源。风险与法律双高，直接排除。
个微最能打的 WeChatFerry（6.8k★）已于 2026-07-10 归档停更。企微 hook 更冷——多数停在企微 3.0.27 老版本，仅个别适配到 4.1.36，企微一升级偏移量就失效。
Wechaty 个人微信起家，纯开源 puppet（web/pad）大多已死。要驱动企微只有句子互动的 WorkPro 商业 puppet（付费 token）——等于把非官方企微能力外包给一家 SCRM 公司。
模拟真人点击，不碰内存不碰协议，风控只看「行为统计异常」。ChatGPT-On-CS（数千★，多平台客服工程化）、wx_work_auto（专啃企微 PC DirectUI）可抄工程结构。
whyiyhw/chatgpt-wechat、razertory/gpt-wework 底层走企微自建应用 / 微信客服 API，敢标「安全不封号」。证明「多轮 + 接 LLM」在官方框架内合规可做——但只能承接微信客服入口 / 已是外部联系人的客户。
解密本地数据库读聊天记录，纯本地不与服务器交互，风险极低。但只能读、不能回，不满足自动回复需求——只能作入站信号的一个来源。
微伴 / 探马 / 尘锋 / 句子互动这些产品的「AI 智能回复」拆开看，全都停在同一条线前——因为官方接口根本没开员工号单聊这个口子。
都是企微官方认证服务商，能力就是官方三件套的包装。所谓「AI 智能回复」= AI 侧边栏起草话术 + 员工点一下发出，或半自动群发到「群发助手」。发送动作始终是人。
早年靠个微/企微 RPA 协议起家（这正是它能做真多轮的原因），近年在洗白转合规——开源了基于微信客服接口的 puppet，产品把 AI 自动回复主推到微信客服通道上，个微协议已不再公开主打。
《账号使用规范》明文禁止「第三方外挂接入」。2024 公告点名打击五类：多开聚合、规避群发上限、非官方单聊自动回复、外挂收集客户数据、朋友圈自动化——「单聊自动回复」正是第一梯队。
处罚是账号阶梯封禁（限功能→短封→永封），执法对象是使用侧的企业号/成员号，不公告点名服务商。所以「某 SCRM 被处罚」查不到实锤，但「用外挂功能导致成员号被批量封」的用户案例大量存在。
严格按需求定义（员工企微号 · 好友单聊 · 客户发消息→AI 自动多轮回），市面上没有任何合规产品能做到。合规世界只有三个替代形态（见结论）。我们云电脑上的方案B，在官方定义里和这些灰色工具踩的是同一条红线。
为什么说「GUI 能跑但脆」不是空话——这是我们自己在企微 GUI 代回、加好友、话术三条线上反复踩、反复修的实录。它同时解释了：即使换 API 不可行，把 GUI 做稳也不轻松。
\n 被企微当 Enter=发送，一条回复被切成多条气泡、无上限 → 封顶 3 条 + 切段兜底--remote-debugging-port 只暴露腾讯文档 webview，聊天不在 CDP target 里force-renderer-accessibility 无效把位置 / 布局 / 发送方归属这类任务交给视觉模型 + 隐式机制、没有确定性兜底，就会静默丢单。GUI 代回的每一次「看歪」都是一次潜在的错发或漏回——API 若能替代，价值不只是省心，更是把非确定性换成确定性。可惜官方这条路不通。
官方 API 替代不了当前的 GUI 自动化。合规世界里，「好友单聊全自动」不存在，只有这三个各有取舍的替代形态：
真多轮 AI、接 LLM、零封号。但入口是客服号不是好友关系，且受「用户先发言 + 48h/5 条」约束。
好友关系保留，AI 把话术送到侧边栏，最后一厘米人工确认。头部 SCRM 的主流形态。
AI 生成个性化内容批量推到群发助手，员工一键确认。单向触达、非对话，每客户约 30 条/月。
别为了 API 推翻好友关系。核心资产是「客户加了运营的企微好友」这层信任，方案B 的 GUI 自动化虽然踩红线，但它守住了这层关系。值得做的三件事：① 继续沿 RPA 路线优化 GUI 代回（抄 ChatGPT-On-CS / wx_work_auto 的工程结构）；② 做半-API 混合——入站消息改走「会话存档 API」读取（比抓屏可靠），出站仍 GUI 点发；③ 把微信客服通道作为承接公域来客的新增补充渠道去小规模验证，而非替换好友通道。