Chatter-to-Commit：从混乱消息到结构化事件的LLM管道

一个生产级LLM管道，将非正式的WhatsApp消息转换为结构化事件，支持周期感知的时间推理和原生人机协作循环，已应用于农业车队追踪。

在农业车队管理的实际场景中，操作员不会填写结构化表单。他们使用WhatsApp发送简短、缩写、充满拼写错误的消息，例如：

D LS SOC          → 卡车D，开始装货，SOC站点
A,B enter KN4     → 卡车A和B，进入KN4站点
H LS              → 卡车H，开始装货，站点???（未知）
sorry D not B     → 更正：刚才的事件是D，不是B
D lefy            → 拼写错误："D left"（D离开）

挑战在于：如何从这些缩写、代码混杂、拼写错误且上下文依赖的消息中，可靠地提取结构化事件。正确的解释往往需要知道卡车在持续运营周期中的当前状态。

Chatter-to-Commit正是为解决这一实际问题而构建的生产级系统。

系统采用分层管道设计，从原始消息到最终提交事件，经过多个处理阶段：

WhatsApp Group
  ↓
Baileys WebSocket
  ↓
wa_listener (Node.js)  ──POST──→  fleet_pipeline (FastAPI/Python)
                                      ↓
    Level1 ←── Level2 ←── Level3 (LLM) ←── Committer
      ↓                                    ↓
    SQLite (WAL mode)              WebSocket → Dashboard

• wa_listener：Node.js服务，监听WhatsApp实时事件
• fleet_pipeline：FastAPI后端，编排整个处理流程
• Level 1：消息提取，解析Baileys事件或WA聊天记录
• Level 2：基于规则的词汇丰富，匹配卡车/站点注册表
• Level 3：LLM推理，生成结构化JSON输出
• Committer：确定性后处理，应用业务规则

当系统置信度低或实体无法解析时，会触发人机协作循环：

Committer创建HITL问题
  ↓
wa_notifier调用Node.js /send-reply
  ↓
  (bot在WA群组中引用原始消息)
  💬 未知站点'XY'。请回复站点代码，如SOC
  ↓
  (操作员在WA中回复——无需Web UI)
ingest.py检测contextInfo.stanzaId匹配 → 路由为HITL答案
  ↓
重新处理原始消息，将operator_clarification注入LLM上下文

这种设计的精妙之处在于：操作员的手机已经打开，通过WA回复路由澄清信息意味着零上下文切换。bot_wa_message_id与question_id在SQLite中的映射让ingest路由能在O(1)时间内检测回复，无需扫描。

解析Baileys实时事件或WA聊天记录导出，将非结构化文本转换为结构化字典。保留wa_message_id作为msg_id，使HITL问题能够引用原始WA消息。

使用模糊令牌匹配对照卡车/站点注册表。构建候选集而不做提交决策——将它们送入LLM上下文窗口。

向任何OpenAI兼容服务器发送结构化提示，包含：

• 运营上下文（卡车周期定义、站点注册表、状态码）
• 滚动的L3_CONTEXT窗口（最近12个已提交事件，用于时间推理）
• 所有解析规则
• 如果是HITL重新处理，包含operator_clarification

LLM必须输出严格JSON。非JSON输出 → 消息保持。