以 BotManager 七步管线依次处理插件、群聊、客服会话、过滤、图片、AI 与后处理，保持通道和业务逻辑解耦。
WECHAT · AI CUSTOMER SERVICE
微信公众号 AI 客服机器人
通道接入、基础应答与人工接管的第一线
将 Agent 能力接入微信公众号及其他消息通道，负责消息归一化、关键词知识检索、会话归档、人工接管与数据回流。
18类业务场景
4类消息通道
7 步消息处理管线
50%+基础咨询自动应答内部估算
口径说明：自动应答率为业务运营观察，尚未形成大样本统计。
01
PROBLEM & SCOPE
先定义问题和责任边界。
业务问题
- 公众号非工作时段响应慢，重复问题占用有限人力；不同通道的消息格式、群聊规则和客服会话状态不一致。
- 向量数据库在轻量部署与可维护性上成本偏高，需要更透明、可本地维护的检索方案。
我的职责
产品定义 / 通道架构 / MVP 开发
- 团队
- 3 人创业团队
- 周期
- 2026.04 - 至今
- 交付状态
- 业务验证中
02
PRODUCT DECISIONS
关键决策，不只是功能列表。
知识检索从 ChromaDB 迁移到 JSON 关键词检索，使用 jieba 分词并以字符 bigram 兜底，提高透明度和部署稳定性。
明确 AI 为一线基础应答层，复杂、敏感和低置信度问题必须转人工。
03
SYSTEM ARCHITECTURE
从输入到反馈的产品链路。
消息通道
公众号 / iLink / Gewechat / itchat
业务调度
七步消息管线与客服会话状态
知识检索
JSON 关键词、jieba 与字符 bigram 兜底
模型桥接
GLM / OpenAI 协议 / 本地模型备选
归档回流
本地记录、COS 同步与人工确认
实现栈
Python微信公众号 APIGLM-4-FlashJSON 关键词检索jieba字符 bigramCOS
04
EVIDENCE & OUTCOMES
展示证据，也说明证据边界。
支持公众号、iLink、Gewechat 与 itchat 等通道适配，统一进入同一消息处理管线。
会话本地归档并同步至 COS，供 Service Agent 拉取、清洗和人工确认。
内部运营观察显示基础重复咨询自动应答约 50%+，但仍按估算口径展示。
指标边界
自动应答率为业务运营观察，尚未形成大样本统计。
05
PRODUCT EVIDENCE
界面、流程与实现证据。
06
TRADE-OFFS & NEXT
取舍、风险和下一步。
关键取舍
- 关键词检索牺牲部分语义召回，换取更轻量、透明和稳定的部署；复杂检索由 Service Agent 承担。
- 通道层只做基础路由与归档，避免在机器人内堆叠全部业务逻辑。
下一步验证
- 按场景统计转人工原因、命中词和误答样本，完善关键词和同义词治理。
- 增加通道级健康检查和本地模型降级，降低云端 API 不可用影响。
07
CROSS-PROJECT RELATIONSHIPS