做微信智能体最容易踩的坑是所有指令都走一套响应流程。用户问今天发货吗和用户说帮我办退货走同一条大模型推理工具调用链路结果简单指令响应慢、复杂指令又因为链路太重出问题。问题出在没按指令的复杂度和业务价值分级响应。从用户指令到业务响应第一件事不是想怎么实现是想清楚这条指令承诺多快响应、响应不了怎么降级、用什么时效标准衡量。响应时效分层比堆能力更决定智能体能不能用。一、指令分级——不是所有指令都要秒级响应用户指令按响应时效要求分四级。秒级指令查询类订单状态、物流、库存用户等不了3秒不回复就以为没人。分钟级指令工具调用类创建退货单、修改地址、查询复杂业务需要调接口等返回1-3分钟可接受。小时级指令流程编排类多步骤售后、跨系统协同需要多轮交互和人工确认几小时内完成可接受。人工指令高风险或越权类退款审批、投诉升级、商务合作AI不处理直接转人工。分级的工程价值是资源匹配。秒级指令走轻量直答链路缓存命中规则回复不走大模型推理省时省成本。复杂指令才走重链路意图识别工具调用流程编排把重链路的算力投到真正需要的地方。不分级的后果是简单查询也走重链路响应慢且浪费算力复杂指令和简单查询抢同一套资源高峰期全崩。二、超时降级——承诺的时效不能兑现怎么办每级时效都要有超时降级方案。秒级指令超时缓存没命中走直查直查还慢就先回查询中稍等再异步返回结果不能让用户干等。分钟级指令超时工具调用超时就重试一次重试还超时转人工别让用户在对话里等3分钟没动静。小时级指令超时流程卡在某步就主动告知卡在哪、预计多久、要不要转人工让用户有预期。超时降级的工程关键是超时不等于失败是降级信号。秒级超时降级到分钟级分钟级超时降级到人工逐级降级而非直接报错。降级要带上下文——用户问的什么、卡在哪步、已收集哪些信息转人工时带上别让用户重述。指令路由和超时降级在 Eyun 开发文档 中有对应接口能力。三、时效承诺——让用户对响应速度有预期用户对响应速度的不满很多时候不是真慢是没预期。帮我查下物流等了30秒没回复用户不知道是在查还是没人理。如果回复正在为您查询物流约10秒内返回用户有预期就不会催。时效承诺的核心是给预期兑现预期给预期靠即时回执兑现预期靠SLA监控。时效承诺的工程实现是即时回执SLA埋点。指令进来先回执正在处理预计X秒/X分钟让用户有预期。处理过程中按SLA埋点监控实际耗时超时触发降级。SLA达成率要统计——某级指令经常超时要么是SLA定得不合理要么是链路有瓶颈两种都要查。承诺了不兑现比不承诺还伤体验。指令响应时效四级分层对照指令级别典型指令时效承诺超时降级秒级查询物流状态3秒内缓存→直查→异步回执分钟级创建退货单1-3分钟重试→转人工带上下文小时级多步骤售后流程当日内告知卡点预计时间人工级退款审批投诉转人工即回执直转人工不等待指令SLA路由与超时降级实现class CommandRouter: SLA { query: (second, 3), # 秒级3秒 tool: (minute, 180), # 分钟级3分钟 flow: (hour, 3600), # 小时级1小时 human: (human, None), # 人工级 } def route(self, raw): level self.classify(raw) # 指令分级 sla self.SLA[level] self.ack(raw, sla) # 即时回执给预期 if level query: # 秒级走轻量链路 return self.quick_reply(raw) if level human: # 人工级直转 return self.to_human(raw) # 复杂指令走重链路超时降级 try: return self.run_with_timeout(raw, sla[1]) except TimeoutError: return self.degrade(raw, level) def degrade(self, raw, level): # 逐级降级tool→human nxt self.next_level(level) if nxt human: return self.to_human(raw, ctxraw.context) return self.route(raw) # 降级重试落地建议指令分级先从查询类和工具调用类两级做起——秒级直答和分钟级工具调用覆盖80%指令量跑稳了再上流程编排和人工转接。超时降级必须带上下文传递降级到人工时用户不用重述问题这一条做不到降级就没意义。时效承诺的SLA达成率要持续统计经常超时的级别要查是SLA定得不合理还是链路有瓶颈别让承诺变成空头支票。微信侧的消息收发、指令路由和人工转接由Eyun这类个人微信API平台 提供SLA分级和超时降级在自建服务实现接口字段以平台开发文档为准。