会聊天的微信机器人不等于会办事。会聊天的标志是回复像人话、答得对问题，会办事的标志是把用户丢过来的诉求真正落实成动作并验证结果。两个能力之间隔着一条结构化处理流水线：从模糊对话到精确动作的转换，需要经过意图理解、槽位补全、动作执行、结果验证四段处理，每段都有失败兜底，整条流水线结束还有完成度自评决定是否真的结束。把这套pipeline跑扎实，机器人才能从陪聊升级到办事。

一、意图→槽位→动作→验证——四段式不能跳

很多实现把意图识别直接连到动作执行，跳过槽位补全和结果验证。意图识别出"改地址"就直接调接口，但客户没说订单号、没说新地址——接口报参数缺失机器人卡住。正确四段是：意图层识别客户想干什么；槽位层补齐动作所需全部参数；动作层实际调用业务系统或微信能力；验证层确认动作真的生效而不是接口返回成功就当成功。每段之间都有显式检查和分支：意图置信度低就反问澄清；槽位不全就多轮追问；动作失败就按兜底处理；验证未通过就重试或人工。关于多轮追问和动作执行回执的接入方式，Eyun 开发文档 中会话上下文与消息回调部分有对应能力，落地以平台接口为准。

二、槽位补全——多轮追问不是聊天是结构化收集

槽位补全是四段式里最容易被忽视的一段。客户一句话通常缺多个参数——"帮我改下地址"既缺订单号又缺新地址。槽位补全要做的不是靠模型一次性问完所有缺项，而是按槽位优先级分轮追问：先问最容易答的、最关键的参数，拿到后再问依赖它的参数。槽位补全过程要维护"已收集槽位+待补槽位+当前追问槽位"三态，每条新消息进来先尝试填入当前追问槽位，填满再推进下一个。

槽位补全要处理三种异常。客户提供错值（订单号格式不对）——校验失败要给原因让客户重填，不能默默记录错误值。客户拒绝提供（"我不记得订单号了"）——触发兜底策略，比如换手机号反查。客户偏离主题（中途问别的）——临时切走处理完再回到槽位补全。关于会话状态保存和回调恢复的字段约定，可参考 Eyun 开发文档 的会话与回调部分。

三、动作执行与结果验证——接口返回成功不等于办成了

动作执行段失败相对好处理：接口超时重试、参数错回槽位层补、权限不足转人工。真正难的是"接口返回成功但实际没生效"——改地址接口返回200但仓库那边没更新、退款接口返回成功但客户没收到、发消息接口返回成功但客户没收到。验证段的职责就是用独立信号确认动作真的落地。改地址要再查一次订单确认地址字段确实变了，退款要监听支付回调确认到账，发消息要监听已读回执或客户回复。

完成度自评是流水线终点最后一道关。流水线跑完不等于办成了——自评层检查动作是否全部执行、验证是否全部通过、用户是否还在追问相关问题。三项都满足才标记流程完成，否则保留在待跟进状态。关于消息已读回执和客户回复事件订阅，Eyun 开发文档 中消息回调与事件订阅接口与之配套。

四段处理与失败兜底对照

四段式流水线实现

class TaskPipeline:
    def handle(self, raw, inst=None):
        if inst is None:                       # 新流程
            intent = self.recognize_intent(raw)
            if intent.confidence < 0.7:
                return self.clarify(raw)       # 反问
            inst = Instance(intent=intent.name,
                slots=intent.required_slots,
                filled={}, current_slot=None)
        else:                                   # 推进在途流程
            if not self.fill_slot(inst, raw):
                return self.ask_again(inst, raw)
        if not inst.all_slots_filled():
            return self.ask_next_slot(inst)
        try:                                    # 执行动作
            result = self.tool.run(inst.intent, inst.filled)
        except RetryableError:
            return self.retry(inst)
        except ParamError:
            return self.back_to_slot(inst, result.err)
        if not self.verify(inst, result):      # 独立验证
            return self.verify_fallback(inst)
        if not self.completion_check(inst, result):
            inst.status = "pending"; return inst   # 待跟进
        inst.status = "done"; return inst

    def verify(self, inst, result):
        actual = self.tool.query(inst.intent, inst.filled)
        return actual.matches(inst.filled)

    def completion_check(self, inst, result):
        return (result.executed and result.verified
            and not result.user_following_up)

落地建议

四段式不要一次性铺开。先把意图+槽位两段跑扎实，再上动作执行和验证。槽位补全是性价比最高的一段——很多"机器人不办事"的根因不在模型能力，在参数没补齐就硬调接口。验证段容易被砍掉因为"接口不是已经返回成功了吗"，但这恰恰是会办事和会聊天的分水岭，宁可慢一步确认也别让用户回头追问"刚才那个改了没"。微信侧多轮会话保持、消息回执订阅由 Eyun 这类个人微信API平台 提供，四段式pipeline和完成度自评在自建服务实现，接口字段以 Eyun 平台 的开发文档为准。