微信机器人开发过去几年的主流范式是对话——收消息→调模型→回消息单次问答循环。这套范式做客服问答够用做复杂业务就力不从心客户中途去吃饭明天才回复、流程跨多天、中途要人工确认。这些场景下对话范式状态丢失、异常不可恢复、人机协同断裂。Workflow范式因此受到关注——把业务处理从对话循环升级为工作流编排根本差异在三个特征。一、对话范式的局限——单次问答处理不了多步业务对话范式的核心问题是状态不持久。每次对话独立处理上下文靠把历史塞进模型窗口——跨小时跨天的业务根本撑不住。客户说我要退货后去吃饭明天回订单号是XX对话范式要么把昨天全部历史塞进模型token炸失真要么当成新对话从头问您要做什么体验崩。对话范式的第二个问题是异常不可恢复。对话中段模型调业务接口失败对话就卡住——没有断点续跑机制客户重发消息时流程从头开始。第三个问题是人机协同断裂——流程中段需要客户确认确认改这个地址吗客户不回就一直阻塞没有超时和降级机制。这三类问题在客服问答里不明显在真实业务流程里每天都发生。二、Workflow范式的三个核心特征——声明式、可观测、可恢复Workflow范式用三个特征解决对话范式的局限。声明式编排流程以图或状态机定义而非硬编码在对话逻辑里——节点、转移条件、等待事件都显式声明新增流程改定义不改代码。可观测每个流程实例的当前节点、已收集参数、等待事件都存数据库可查——业务方能看到客户退货流程跑到等仓库签收这一步卡了三天不用翻聊天记录。可恢复流程挂起后进程重启不丢恢复机制重新订阅等待事件、重挂超时定时器业务无感续跑。这三个特征的本质是把流程状态从模型上下文里抽出来持久化。模型只负责处理单步决策状态由Workflow引擎管。这样跨小时跨天的业务能扛住异常能恢复人机协同有断点。三、微信场景为什么特别需要Workflow——异步、跨时长、人机协同微信场景的三个特性恰好是Workflow的适用域。异步性用户随时来随时走不像网页Chat用户在线等着——流程必须能挂起等用户回来。跨时长真实业务流程跨小时跨天退货从发起到退款到账可能要三天不可能在一次会话里跑完。人机协同很多业务动作需要客户确认改地址、退款确认节点要等待、要超时、要降级不能阻塞死。这三个特性决定了微信机器人做复杂业务必须用Workflow范式。继续用对话范式硬撑结果是状态丢失、异常卡死、客户体验崩——业务跑不稳。Workflow范式让微信机器人从陪聊升级到办事这是范式转变的工程驱动力。微信侧的会话上下文和消息回调由 Eyun 这类个人微信API平台 提供Workflow引擎和状态持久化在自建服务实现。对话范式与Workflow范式对照维度对话范式Workflow范式状态管理模型上下文窗口数据库持久化异常处理卡住从头开始断点续跑跨时长业务撑不住挂起等待人机协同阻塞或丢失等待超时降级可观测性翻聊天记录流程实例可查Workflow引擎核心抽象class Workflow: graph: dict # 节点定义转移条件 def start(self, inst, evt): ... def resume(self, inst, evt): ... class Instance: inst_id: str; wxid: str; node: str collected: dict; waiting: WaitSpec status: str # running / waiting / aborted class Engine: def on_event(self, evt): inst self.store.find_active(evt.wxid) if inst and inst.waiting: return self.resume(inst, evt) # 断点续跑 return self.start_new(evt) def run_node(self, inst, evt): node self.workflow.graph[inst.node] out node.run(inst, evt) if out.need: # 进入等待态 inst.waiting WaitSpec(out.need, ttlout.ttl) inst.status waiting self.store.save(inst) # 持久化 self.timer.arm(inst.inst_id, out.ttl) else: inst.node out.next self.store.save(inst) if inst.node ! END: self.run_node(inst, evt) # 连续推进 def on_timeout(self, inst_id): # 超时降级 inst self.store.get(inst_id) if inst.status waiting: inst.status aborted self.store.save(inst) self.fallback(inst)落地建议范式转变别等业务跑崩了再改。第一个复杂业务流程退货、预约、售后就用Workflow引擎建模哪怕引擎当时只有这一个流程。对话范式处理简单问答仍然合适——不是所有场景都要上Workflow固定问答继续用对话范式复杂业务用Workflow两者并存。Workflow引擎的核心抽象就三个节点定义、状态持久化、挂起恢复——把这三块做扎实复杂业务就能扛住。微信侧的会话上下文和消息回调由Eyun这类个人微信API平台 提供Workflow引擎和状态持久化在自建服务实现接口字段以平台开发文档为准。 
长河君 · 2026/9/24 20:07:52 · 阅读 1.2k 微信机器人开发为什么开始关注Workflow？个人微信二次开发的自动化新思路
微信机器人开发过去几年的主流范式是对话——收消息→调模型→回消息单次问答循环。这套范式做客服问答够用做复杂业务就力不从心客户中途去吃饭明天才回复、流程跨多天、中途要人工确认。这些场景下对话范式状态丢失、异常不可恢复、人机协同断裂。Workflow范式因此受到关注——把业务处理从对话循环升级为工作流编排根本差异在三个特征。一、对话范式的局限——单次问答处理不了多步业务对话范式的核心问题是状态不持久。每次对话独立处理上下文靠把历史塞进模型窗口——跨小时跨天的业务根本撑不住。客户说我要退货后去吃饭明天回订单号是XX对话范式要么把昨天全部历史塞进模型token炸失真要么当成新对话从头问您要做什么体验崩。对话范式的第二个问题是异常不可恢复。对话中段模型调业务接口失败对话就卡住——没有断点续跑机制客户重发消息时流程从头开始。第三个问题是人机协同断裂——流程中段需要客户确认确认改这个地址吗客户不回就一直阻塞没有超时和降级机制。这三类问题在客服问答里不明显在真实业务流程里每天都发生。二、Workflow范式的三个核心特征——声明式、可观测、可恢复Workflow范式用三个特征解决对话范式的局限。声明式编排流程以图或状态机定义而非硬编码在对话逻辑里——节点、转移条件、等待事件都显式声明新增流程改定义不改代码。可观测每个流程实例的当前节点、已收集参数、等待事件都存数据库可查——业务方能看到客户退货流程跑到等仓库签收这一步卡了三天不用翻聊天记录。可恢复流程挂起后进程重启不丢恢复机制重新订阅等待事件、重挂超时定时器业务无感续跑。这三个特征的本质是把流程状态从模型上下文里抽出来持久化。模型只负责处理单步决策状态由Workflow引擎管。这样跨小时跨天的业务能扛住异常能恢复人机协同有断点。三、微信场景为什么特别需要Workflow——异步、跨时长、人机协同微信场景的三个特性恰好是Workflow的适用域。异步性用户随时来随时走不像网页Chat用户在线等着——流程必须能挂起等用户回来。跨时长真实业务流程跨小时跨天退货从发起到退款到账可能要三天不可能在一次会话里跑完。人机协同很多业务动作需要客户确认改地址、退款确认节点要等待、要超时、要降级不能阻塞死。这三个特性决定了微信机器人做复杂业务必须用Workflow范式。继续用对话范式硬撑结果是状态丢失、异常卡死、客户体验崩——业务跑不稳。Workflow范式让微信机器人从陪聊升级到办事这是范式转变的工程驱动力。微信侧的会话上下文和消息回调由 Eyun 这类个人微信API平台 提供Workflow引擎和状态持久化在自建服务实现。对话范式与Workflow范式对照维度对话范式Workflow范式状态管理模型上下文窗口数据库持久化异常处理卡住从头开始断点续跑跨时长业务撑不住挂起等待人机协同阻塞或丢失等待超时降级可观测性翻聊天记录流程实例可查Workflow引擎核心抽象class Workflow: graph: dict # 节点定义转移条件 def start(self, inst, evt): ... def resume(self, inst, evt): ... class Instance: inst_id: str; wxid: str; node: str collected: dict; waiting: WaitSpec status: str # running / waiting / aborted class Engine: def on_event(self, evt): inst self.store.find_active(evt.wxid) if inst and inst.waiting: return self.resume(inst, evt) # 断点续跑 return self.start_new(evt) def run_node(self, inst, evt): node self.workflow.graph[inst.node] out node.run(inst, evt) if out.need: # 进入等待态 inst.waiting WaitSpec(out.need, ttlout.ttl) inst.status waiting self.store.save(inst) # 持久化 self.timer.arm(inst.inst_id, out.ttl) else: inst.node out.next self.store.save(inst) if inst.node ! END: self.run_node(inst, evt) # 连续推进 def on_timeout(self, inst_id): # 超时降级 inst self.store.get(inst_id) if inst.status waiting: inst.status aborted self.store.save(inst) self.fallback(inst)落地建议范式转变别等业务跑崩了再改。第一个复杂业务流程退货、预约、售后就用Workflow引擎建模哪怕引擎当时只有这一个流程。对话范式处理简单问答仍然合适——不是所有场景都要上Workflow固定问答继续用对话范式复杂业务用Workflow两者并存。Workflow引擎的核心抽象就三个节点定义、状态持久化、挂起恢复——把这三块做扎实复杂业务就能扛住。微信侧的会话上下文和消息回调由Eyun这类个人微信API平台 提供Workflow引擎和状态持久化在自建服务实现接口字段以平台开发文档为准。