AKKE决策调研 · DECISION RESEARCH · 2026
① 框架横评 ② 装修场景选型 ③ RAG 行业建模 ④ 用户建模
任务 1 / 8五大战略 · 主题4 · 微信自动化工作流（加V后两场景）

微信自动回复工作流 · 框架横评

抖音获客 → 客户加微信（个微 / 企微） → 用「小艳」人设在微信里自动 / 半自动回复、维系、聊到到店。本页横评的不是「用哪个 agent 框架」，而是把工作流拆成大脑层与通道层两件事，逐一对齐 Akke 仓库现状。

结论
微信自动回复工作流 = 共享大脑（chatReply）+ 微信通道 substrate 两层。大脑层无需引任何编排框架——人设 / 知识 / few-shot / 蒸馏 / 客户画像在 src/lib/llm.ts 已是成品；真正的选型全在通道层三条 substrate，而且没有任何一个「现成框架」能同时做到「官方合规代答外部微信客户」+「云端横扩」——这是产品边界，不是工程量。
不引框架
大脑层结论 — chatReply 已是大脑
3
通道层 substrate 数（均已调研，部分已建）
kf API
最合规路线 — 但卡 ICP 备案死锁
WDA PoC
唯一已验证可跑（PoC PASS，单机）

01拆解问题：微信自动回复工作流 = 大脑 + 通道

先把「这是什么问题」问清楚，再谈选型。它是两层问题，不是一层。

很容易把这道题误读成「我们要不要上一个 AI agent / workflow 框架来做微信客服」。这是错的拆法。Akke 的对话大脑——「小艳」人设、知识库、few-shot 示例、蒸馏规则、跨会话客户画像——早已沉淀在 src/lib/llm.ts · chatReply 里，并已在抖音 DM 场景跑了几个月。微信自动回复缺的从来不是「大脑」，而是把这颗大脑接到微信消息流的那根管子。

图1 · 微信自动回复工作流的两层架构
大脑层 · BRAIN（已成品，复用）复用 chatReply
小艳 人设 system prompt stage 机 ice_break / nurture / decision 知识库 + few-shot + 蒸馏规则 跨会话客户画像 memory.ts sanitize / 防泄漏
▲   同一颗大脑，对接不同管道   ▲
通道层 · SUBSTRATE（真正的选型）三条并存
方案 A
企微 kf API
官方回调 · 最合规 · 卡 ICP
方案 B
企微 PC UI 自动化
Windows GUI · 待探针
方案 C
WDA-iPhone UI
PoC PASS · 单机
大脑层与通道层解耦：换通道只换「管子」，大脑零改动。src/lib/wecom/process.ts 的 ai 模式即直接调 chatReply；WDA PoC 的 ECHO 路径预留同款接口。
WHETHER 先于 HOW：别一上来问「用 LangGraph 还是 Dify」。先问清楚——大脑已经有了，编排层根本不缺框架；缺的是微信通道，而微信通道的核心矛盾是合规与横扩不可兼得。把这层想清楚，框架横评的答案自然收敛：编排层「不引」，通道层「三选一并行验证」。

02大脑 / 编排层：要不要引一个框架

这层已定调，简写。结论：不引——任何通用编排框架对 Akke 都是净负收益。

LangGraph / Dify / Coze / n8n 是 2026 年主流的四类编排底座，定位各异 Jimmy Song 2026 横评n8n Blog：

图2 · 编排框架 vs Akke 自研栈 — 五维适配矩阵
编排底座定位有状态
编排		复用
chatReply		商业
许可可用		引入
净收益		总评
LangGraph代码框架 ●●●●○ ●●○○○ MIT 重写编排11/20
Dify可视化平台 ●●●○○ ●○○○○ 附限制 大脑外移8/20
Coze拖拽 bot ●●○○○ ●○○○○ 托管 黑箱托管7/20
n8n低代码自动化 ●●○○○ ●○○○○ 禁嵌 SaaS 许可出局6/20
Akke chatReply自研大脑 ●●●●○ ●●●●● 自有 已是成品18/20
来源：各框架官方文档 / 许可证 + 仓库现状核验。编排「有状态」靠现有 Cron + 阶段机 + 队列已经满足；引框架的代价是把已沉淀的人设 / 知识 / 蒸馏全部外移重做。

结论一句话：编排这层 Akke 已经赢了。Cron 触发 + conversations 阶段机 + message_queue 审批闸 + chatReply 推理，本身就是一套定制编排管线；引任何通用框架都意味着「把大脑搬到别人家重写一遍」，净收益为负。开源「接微信」项目（dify-on-wechat / LangBot）之所以要 Dify / LangGraph，是因为他们没有大脑——这恰恰反证了 Akke 不需要。

03微信通道层横评 （本页核心）

六条 substrate × 六个维度。这才是真正要做决策的地方。

把「接微信」的所有现实路线摊开，共六类：三条 Akke 已建（kf API / 企微 PC UI / WDA-iPhone），三条外部对照（个微 wechaty / 开源接微信 / 第三方 SCRM）。核心矛盾贯穿全表——合规的不能横扩，能横扩的不合规。

图3 · 微信通道 substrate 六维横评矩阵
通道 substrate 官方 AI
代答外客		 封号 /
合规风险		 云端
横扩		 接入
成本		 数据
自主		 Akke
现状
企微 kf API (方案A) 是·唯一 ●○○○○ ●●●●● ●●●○○ ●●●●● 代码就绪·卡ICP
企微 PC UI (方案B) 灰区 ●●○○○ ●●○○○ ●●●○○ ●●●●● 探针待跑
WDA-iPhone UI (方案C) 灰区 ●●●○○ ●○○○○ ●●●●○ ●●●●● PoC PASS
wechaty 个微 否·违协议 ●●●●● ●●●○○ ●●●●○ ●●●●○ 不考虑
开源接微信
dify-on-wechat / LangBot		 视底层 ●●●●○ ●●●○○ ●●○○○ ●●●●○ 仅印证
第三方 SCRM
卫瓴 / 微伴 / 句子互动		 copilot 为主 ●○○○○ ●●●●○ ●○○○○ ●●○○○ 未采用
● 越多 = 该维度越「强 / 越高」；封号风险列 ● 越多代表风险越大（越差）。蓝底 = Akke 三条已建 substrate。来源：企微官方文档（94677 等）+ wechaty 封号风险综述 + 句子互动 / 卫瓴官网 + 仓库 grep 核验。
图4 · 落地可行度评分（对 Akke 当前现实）
WDA-iPhone (方案C)
82
企微 kf API (方案A)
55
企微 PC UI (方案B)
48
第三方 SCRM
35
开源接微信
30
wechaty 个微
14
「落地可行度」= 今天能不能在 Akke 实际跑通 × 风险可承受度。WDA 已 PoC PASS 故最高；kf API 合规天花板最高但被 ICP 备案锁死、扣分；wechaty 因违协议 + 封号最高垫底。评分为本调研基于证据的定性判断，非外部基准。

外部三条对照路线 — 调研要点

wechaty 个微
网页协议基本只剩 2017 前老号能用，iPad 付费版「听说被腾讯告过」；Hook 类封号率 >80%，协议模拟异地 IP / 高频即封。违反微信协议，主号不可上。知乎 / 蓝点网综述
开源接微信
dify-on-wechat / chatgpt-on-wechat / LangBot 底层 = 自建回调 + 微信协议(gewechat 等) + 自有 LLM。和 Akke 的 kf 方案同构——只是大脑换成 Dify。对 Akke 仅作架构印证，不直接采用。GitHub LangBot / dify-on-wechat
第三方 SCRM
句子互动 / 卫瓴 / 微伴：企业合同制、私有部署首年 20 万起 + 年维 5 万。卫瓴 AI 偏「销售 copilot」（提示坐席）非客户侧自动代答；句子互动主打 Agentic 数字员工但按业务结果计费、贵。数据不自主。句子互动官网 / 36氪
一句话穿透：「现成框架」这条路在微信场景集体失灵——开源项目和 SCRM 要么底层就是 kf 协议（=方案A 同构）、要么是销售辅助而非客户代答、要么数据不自主 + 贵。没有一个能既官方合规代答外部客户、又云端横扩、还数据自主。这正是为什么 Akke 要自己在三条 substrate 上验证，而不是买一个框架。

04三条已建 substrate 深读

每条都已落代码 / 探针 / PoC，带仓库证据。

方案 A · 企微微信客服 kf 官方 API — 最合规，但 ICP 死锁

官方唯一明确支持「AI 代员工回复外部微信客户」的路线：会话在 state 0（新接入）/ 1（智能助手接待）时可直接 kf/send_msg，接收靠回调 + kf/sync_msg 拉取，人工接管是状态机原生能力。代码全部上线：wecom-proxy/（独立 Fly app，固定出口 IP 209.71.88.154）、src/lib/wecom/ crypto·client·process + 单测、回调 api/wecom/kf/callback、WECOM_KF_MODE echo/ai 开关、wecom_kf_state / channel 两个 migration 已上生产。 .ev grep PASS

✓ 优势

  • 官方合规、可信 IP 白名单、有人工接管状态机
  • 云端横扩天花板最高（无设备绑定）
  • 数据全自主，直连 chatReply（ai 模式已写）
  • 代码零改动可复活，只等域名

✗ 劣势 / 阻塞

  • 硬阻塞：回调域名 ICP 备案主体校验 — vercel.app / fly.dev / 裸 IP 全被拒（实测 Domain entity verification failed）
  • 48h / 5 条窗口，AI 拆条回复要计数；超窗唤回手段待研究
  • send 仅 state 0/1；1:1 好友单聊需桥接进 kf 会话
  • 当前两台 proxy 机器已停机省钱（冻结待域名）
解锁路径：公司侧拿到已备案域名 → 子域 CNAME 到 Vercel → 按依赖链（回调 URL → 可信 IP 209.71.88.154 → 绑应用 → 切 API 接待）复活，代码零改动。这是中期「官方合规云端化」的唯一正路。

方案 B · 企微 PC（Windows）客户端 UI 自动化 — 待 Windows 探针

方案 A 冻结待域名后转向，复用无影 GUI 自动化家族。已有可行性探针 worker/scripts/wecom-chat/probe_wecom_ui.py + README + 设计 spec。下一步 blocker 是人工：需要一台装好企微客户端、登录主号的 Windows 机器跑探针，回传 output，再在「UIAutomation 无障碍树 / OCR / 会话存档 API（付费）」三条读消息路线间裁定。 .ev grep PASS

✓ 优势

  • 不依赖 ICP 域名，绕开方案 A 死锁
  • 复用成熟的无影 GUI 自动化栈
  • 数据自主、企微合规外壳（非 hook 个微）

✗ 劣势 / 未知

  • 读消息路线未定（无障碍树 / OCR / 付费存档）
  • 需常驻 Windows 机器，横扩弱于 kf API
  • 探针未跑，可行性尚未实证

方案 C · WDA-iPhone UI 自动化 — PoC PASS，但单机

唯一已验证可跑的 substrate：worker/wechat_reply_wda.py + wechat_wda_helpers.py 全闭环（消息列表锚点 → 会话气泡 → extract_latest_inbound → send_wechat_reply），PoC 已 PASS。骨架照 iOS WDA 抖音 DM 收件箱轮询复用。 .ev grep PASS

✓ 优势

  • 今天就能跑——闭环 PoC 已 PASS
  • 个微 / 企微皆可（操作的是真机 App UI）
  • 验证「微信自动回复范式」成本最低

✗ 劣势 / 天花板

  • iPhone 单机，无法云端横扩
  • 抢抖音前台（同机 WDA 资源互斥）
  • UI 自动化合规属灰区，规模化有风控风险

05决策

大脑层「引框架净收益」为负；通道层按「短期验证 → 中期合规云化 → 备选」排序推进。

-
BRAIN LAYER
引编排框架净收益 = 负
①
SHORT TERM
WDA 验证范式（已 PASS）
②
MID TERM
攻 ICP 解锁 kf API 官方云化
③
BACKUP
企微 PC UI 作 Windows 备选
图5 · 推荐推进路径（时间轴）
NOW
① WDA 验证
用已 PASS 的 PoC 验证微信自动回复范式 + 大脑效果，单机够用
UNLOCK
② 攻 ICP
公司备案域名 → 复活 kf API → 官方合规 + 云端横扩
FALLBACK
③ 企微 PC
域名久拖不决时，跑 Windows 探针定读消息路线
大脑层（chatReply）三条路径全程复用、零改动。决策的全部张力在通道层「合规 ↔ 横扩」的取舍上。
给决策者一句话：微信自动回复不缺「框架」——缺的是一根能同时合规又横扩的微信管子，而它今天还不存在。所以正确做法不是「选一个框架」，而是短期用 WDA 把范式跑起来拿效果，中期死磕 ICP 备案把 kf API 这条官方云化正路打通，企微 PC UI 留作备选。

06资料来源

联网核实 + 仓库 grep 核验，两类证据。

企微官方 · kf API
企业微信开发者中心 · 发送消息 94677 · 微信客服 API 文档（48h / 5 条窗口、state 0/1、回调配置）
wechaty / 封号
企微·个微机器人调研 · 蓝点网封号事件 · 知乎 wechaty 封号
开源接微信
LangBot · dify-on-wechat · Dify 接入微信生态
第三方 SCRM
句子互动官网 · 卫瓴·协同CRM（36氪）（价格：私有部署首年 20 万起 + 年维 5 万）
编排框架横评
Jimmy Song · 2026 开源 AI Agent 平台对比 · n8n Blog · 9 框架对比
仓库 grep 核验 (.ev)
方案A：wecom-proxy/ · src/lib/wecom/ · api/wecom/kf/callback · 20260610*_wecom_*.sql · WECOM_KF_MODE｜方案B：worker/scripts/wecom-chat/probe_wecom_ui.py｜方案C：worker/wechat_reply_wda.py + wechat_wda_helpers.py — 全部命中

底座定论与 ICP 阻塞细节锚定 memory docs/claude-memory/project_akke_wecom_kf_integration.md（2026-06-10 深度调研 20 来源定稿 + 06-11 方案B 转向 + 06-26 个微 / 企微评估）。