官网友情链接： wechatapi.net

AI 微信机器人越来越依赖上下文。

客户上一句说了什么、之前有没有发图片、是否存在未关闭工单，这些信息都会影响模型理解。

但上下文并不是越多越好。

如果一个会话永远不结束，那么几天、几周甚至几个月前的问题都会不断进入当前判断。

客户昨天问：

“为什么登录失败？”

今天说：

“帮我发一下产品资料。”

如果系统仍然把昨天的故障会话当成当前上下文，AI就可能继续围绕登录问题理解客户。

所以微信二次开发中的会话除了“如何建立”，还需要一个重要概念：

TTL，也就是上下文有效期。

WechatApi 可以作为个人微信API接入层，把微信私聊、微信群、图片、语音、文件消息带入业务系统。本地会话层则需要定义一个问题什么时候开始、什么时候过期、什么时候建立新会话。

一、微信好友关系不是业务会话

客户可能和销售保持好友两年。

但一个具体业务问题可能只持续十分钟。

所以不能用：

contact_id

直接作为永久上下文。

应该建立独立：

conversation_session。

二、TTL解决什么问题

例如普通咨询：

30分钟无互动。

自动结束。

售后问题：

2小时或跟随工单。

人工接管：

直到客服关闭。

不同会话类型不同TTL。

三、一个具体例子

上午10点：

客户：“登录不上。”

机器人处理。

10:20问题解决。

10:25客户说：

“好了，谢谢。”

系统关闭会话。

下午4点：

客户：“把价格表发我。”

这是新会话。

不再加载上午完整故障上下文。

四、只依靠时间也不够

客户售后问题可能隔一天继续。

如果存在未关闭工单。

即使超过普通TTL，也可以重新关联到原业务会话。

所以TTL需要结合：

时间；
工单；
人工状态；
话题。

五、会话状态

活跃；
等待客户；
人工处理中；
已解决；
已关闭；
已过期。

TTL主要作用于：

活跃但长期无消息。

不是随意关闭所有会话。

六、AI上下文只读取当前有效会话

当前会话最近消息。

再加：

客户长期摘要。

而不是把全部历史都扔给模型。

这样上下文更干净。

七、长期信息应该放客户摘要

客户偏好；
历史重大问题；
已购买产品。

这些信息可以单独做长期摘要。

不需要通过“永不关闭会话”保存。

八、WechatApi 的位置

WechatApi 负责：

真实微信消息。

业务系统负责：

session；
TTL；
摘要；
工单关联；
关闭。

九、微信群TTL更短

群聊话题变化快。

一个问题可能5分钟后就完全过去。

群聊可以：

群 + 成员 + 时间窗口

建立短会话。

不要整群共用一个永久上下文。

十、引用消息可以重新激活历史话题

客户引用昨天某条消息。

这说明他明确回到旧问题。

系统可以重新打开历史会话。

引用关系优先于普通TTL判断。

十一、人工可以手动关闭

客服确认问题结束。

点击：

关闭会话。

AI以后不再把旧消息作为当前上下文。

十二、误关闭可以重新打开

重新打开保留日志。

不要删除原关闭记录。

十三、会话关闭时生成摘要

例如：

“客户反馈登录失败，最终通过重新授权解决。”

以后客户说：

“还是上次登录问题。”

系统可以先读摘要。

不需要加载几十条旧消息。

十四、TTL修改也要版本化

普通会话原来30分钟。

改成60分钟。

可以记录配置版本。

历史分析时知道当时使用什么规则。

十五、会话过期期间未发送AI回复要取消

AI任务生成后，客户会话被人工关闭。

发送前再检查会话状态。

旧AI回复直接取消。

防止机器人追着结束的问题回答。

十六、数据看板

平均会话时长；
自动过期；
人工关闭；
重新打开；
长期未关闭。

这些指标能发现会话规则问题。

十七、权限

客服能关闭自己负责会话。

主管能强制关闭异常会话。

系统配置TTL由管理员操作。

十八、总结

微信二次开发中的上下文管理，不只是“记住客户说过什么”。

还要知道：

这些信息什么时候不再属于当前问题。

WechatApi 可以把个人微信消息稳定带入系统。

本地会话层通过：

会话对象；
TTL；
关闭；
重新打开；
长期摘要；
工单关联；

让AI微信机器人既有记忆，又不会被旧问题长期污染。

真正好的上下文系统，不是记得最多，而是知道哪些信息现在还应该被记住。