自动回复的完成条件，是正确消息进入正确买家的会话，并且能在存储里再次看到它。
背景与约束
多店铺客服要同时处理本地加密消息库、不同客户端实例、多个店铺和买家、大模型上下文、UI 与协议发送，以及人工接管。最高风险不是少回一条，而是把内容发给错误的人。
因此每条消息进入系统时就要绑定实例、店铺和买家；发送之后还要继续确认目标会话里是否出现对应记录。
我的工作
读取端通过 Frida hook sqlite3_key 取得当前实例的数据库密钥，再用原生 SQLite 打开 SQLCipher。历史消息按会话哈希落在 64 张表中。读取端维护分片游标，按会话增量轮询，并用 mid 去重，同时绑上实例、店铺和买家。
飞鸽链路上，我 Hook webpack IM 模块捕获协议消息，分析 Pigeon protobuf 与 pigeon_sign，再用 curl_cffi 接入收发。同一套回复、转接和调度可以同时服务 UI 通道和协议通道。
发送端用 pywinauto 适配 Edit / CEF 输入框，也保留协议发送。无论走哪条通道，发送后都查询数据库或消息存储：是否产生新记录、是否属于目标买家、内容摘要是否一致、时间是否落在任务窗口。
调度上，同一店铺与买家的任务串行处理，并加上大模型会话缓存、并发限制、降级重试和人工接管。回复生成、发送和确认是分开的状态，而不是一次函数返回。
关键链路
SQLCipher / 协议消息
→ 实例、店铺、买家绑定
→ 大模型回复
→ UI 或协议发送
→ 数据库二次确认
→ 成功 / 降级 / 人工接管
对应状态是：
message_observed
→ context_bound
→ answer_generated
→ send_dispatched
→ final_state_confirmed
已经实现
- Frida 获取 SQLCipher 密钥；
- 64 张消息分片表增量读取；
mid去重与游标维护；- 实例、店铺、买家上下文绑定；
- 按店铺与买家串行处理；
- 大模型会话缓存和并发限制；
- Pigeon protobuf 与
pigeon_sign； - curl_cffi 协议收发；
- pywinauto 适配 Edit / CEF；
- 人工接管与降级重试；
- 发送后的数据库终态确认。
验证方式
发送动作执行后，任务不会立刻标成成功。终态检查看五件事：是否出现新记录、记录是否属于目标买家、内容摘要是否一致、时间是否位于任务窗口、是否出现失败或重复。
UI 点击、HTTP 成功和发送函数返回，作为动作证据保留。落库记录才是完成证明。身份串行保证同一买家的回复按顺序发生，人工接管可以在确认前介入。
从事实推出的设计判断
现有实现已经按业务身份串行，并在发送后查库。后续可以把 queue key、keyed mailbox 和接管租约做进同一条调度，用来表达崩溃恢复和人工协同。dispatched 和 confirmed 继续分开：发出去和再次看见，不是同一个状态。
事实边界
本案例覆盖加密消息读取、身份绑定、双通道发送、串行调度、人工接管和数据库终态确认。吞吐、热点会话和长期运营指标作为独立观测。
封面为视觉意象。
