微信机器人开发过去几年的主流范式是"对话"——收消息→调模型→回消息，单次问答循环。这套范式做客服问答够用，做复杂业务就力不从心：客户中途去吃饭明天才回复、流程跨多天、中途要人工确认。这些场景下对话范式状态丢失、异常不可恢复、人机协同断裂。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, ttl=out.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引擎和状态持久化在自建服务实现，接口字段以平台开发文档为准。