最近百度 DuMate 升级的消息在开发者圈子里有不少讨论。这次升级对外释放的核心信息是背后的智能引擎把任务完成率做到了 99% 以上。很多同学看到这个数字第一反应可能是“又是宣传口径”。但如果从工程维度去看一个面向真实用户场景的智能任务引擎要把完成率稳定在 99%并不是只靠一个更大的模型就能解决的。这篇文章不打算重复发布会式的表述而是聚焦工程实现任务完成率到底怎么定义、智能引擎处理任务的链路是什么、提升完成率有哪些关键手段以及一个可以运行的最小实现。不管你是做大模型应用、智能客服还是做 Agent 类产品都可以把这篇当成一份可落地的工程笔记。需要先说明的是本文不会给出 DuMate 内部架构的细节因为外部公开信息有限能确认的是这次升级的重点是“智能引擎”和“任务完成率”这两个关键词。我会围绕这两个关键词把通用技术路径讲透。文章包含完整代码示例、指标口径、常见问题排查和工程建议有基础的开发者可以直接跳到代码部分新手建议从第 1 节往下读。1. 背景DuMate 升级背后为什么要看任务完成率1.1 这次升级在讲什么从公开信息看DuMate 的定位更偏向智能助手和任务型智能体方向。早期类似产品更多强调“能聊天”用户问什么都能答但答完之后事情并没有被真正办成。而这次升级说的“智能引擎任务完成率超 99%”意味着产品重心从单轮问答转向了端到端的任务处理。也就是用户说“帮我把这个订单退掉”系统不光要理解这句话还要真正完成查询订单、校验状态、发起退款、返回结果这一整串动作。这种转变背后是产品评判标准的改变。聊天场景看的是回答是否流畅、信息是否准确任务场景看的是事情有没有办成。用户不会因为你解释了订单状态就满意他要的是退款流程被正确触发。因此任务完成率成为比响应准确率更核心的指标。文章后面会说明完成率也不是一个简单的除法不同口径下的 99% 含金量完全不同。1.2 为什么任务完成率比准确率更值得关注传统 NLP 系统评估经常用准确率、召回率、F1 值这些指标衡量的是“模型判断得对不对”。但在任务型智能引擎里判断对只是第一步。系统识别出用户要退款但如果调用了错误的接口或者执行到一半超时或者重复提交了两笔退款用户依然会认为这个助手“不好用”。任务完成率衡量的则是端到端的结果一个任务从接到用户输入开始经过理解、编排、执行、反馈最终是否以用户预期的方式结束。它可以理解为任务完成率 成功完成用户任务的数量 / 系统受理任务的总数量这个指标天然包含了模型能力、接口稳定性、重试策略、人工兜底等多层因素。这也解释了为什么很多团队发现模型效果测试分数很高线上任务完成率却不理想。模型只是链路中的一个环节真正的瓶颈往往在执行层和兜底层。1.3 99% 的合理预期先看口径看到 99% 这个数字我的建议是先问一句这个完成率是怎么统计的是首次执行成功率还是经过重试和人工兜底之后的最终完成率是用户主动确认成功还是系统单方面认为成功有没有把平台内部可以兜底的场景也算进去不同口径算出来的数字差异非常大。如果只统计“模型成功识别出意图”的比例大部分场景做到 95% 以上并不难如果统计“用户最终在页面上完成了下单”难度会明显上升。一个可信的任务完成率至少要区分三个层次首次执行成功率不经过任何重试和兜底第一次就把任务做完。最终任务完成率允许重试、补偿、降级、人工接管后的最终结果。业务结果达成率以业务系统的最终数据为准比如订单是否真实创建、退款是否真实到账。DuMate 声称超过 99%大概率指经过完整链路保障后的最终完成率。这个数字要成立背后必须有稳定的重试机制、兜底机制和监控体系。下面从一次任务的完整链路开始拆解。2. 智能引擎如何处理一次任务2.1 一次任务处理的完整链路把“任务完成”这个目标拆开一次任务处理通常包含下面几个环节输入接入接收用户的文本、语音或指令。意图识别判断用户想做什么属于哪个业务场景。槽位抽取提取完成任务所需的参数比如订单号、商品 ID、时间、地址。任务编排把目标拆成一个或多个子任务确定执行顺序。工具调用调用内部 API 或外部工具完成查询、创建、修改等操作。结果生成把执行结果组织成用户能看懂的语言。反馈回流记录成功或失败原因把失败样本送入改进闭环。这个链路看起来不复杂但每一个环节都可能成为完成率的杀手。意图识别错了后面全部白做参数缺了接口必然报错工具调用失败任务只能中断。所以高完成率的产品绝对不是某一个模型很强而是整条链路每一层都做了容错设计。2.2 理解层从用户输入到结构化意图理解层是任务的起点。它的目标是把自然语言转成结构化指令。以一次退款任务为例系统需要知道意图refund_order 槽位{order_id: SO20250101001, reason: 商品质量问题}现代实现一般有两种方式一种是基于大模型的 Prompt 抽取一种是传统的规则加模型分类。大模型方式灵活适合长尾表达规则方式稳定可控适合高频标准化场景。实际工程中两者通常组合使用规则兜住高确定性场景模型处理开放表达。下面是一个简化版的任务理解 Prompt 模板你是一个任务理解引擎。 请从用户输入中识别意图和抽取关键槽位。 可选意图create_order下单、query_order查单、refund_order退款、schedule_meeting预约会议。 输出 JSON 格式{intent: xxx, slots: {xxx: xxx}}。 用户输入{user_input}这里的重点不是 Prompt 写得多花哨而是要给模型一个清晰的输出结构和边界。意图枚举越明确模型越容易稳定输出槽位定义越具体下游任务编排越容易执行。2.3 执行层工具调用与任务编排理解层输出了“用户想做什么”执行层负责“真正把事做成”。一个复杂任务往往要拆成多个子任务。比如“下单并预约配送时间”需要先创建订单再查询可配送时段最后预约物流。任何一个子任务失败整体任务都可能失败。执行层的关键设计是任务编排和工具抽象。每一个工具都应该有清晰的入参、出参、错误码。常见做法是让模型具备函数调用能力模型根据意图选择工具再传递对应参数。为了便于工程控制生产环境通常不会让模型直接调用真实接口而是让模型生成“工具调用意图”由后台代码做参数校验、鉴权、限流和实际发送。这里特别要提醒幂等设计。任务引擎经常需要重试如果重试导致同一个订单被创建两次那完成率再高也没有意义。工具层必须支持幂等键比如用request_id或task_id作为唯一标识让重复调用不产生重复业务数据。2.4 反馈层失败恢复与经验回流一次任务失败后系统不能直接放弃。反馈层要做三件事记录失败原因、执行补偿措施、把样本回流到评测集。失败原因要分类比如参数缺失、接口超时、业务规则不满足、模型识别错误。不同原因的处置方式完全不同。参数缺失可以反问用户补全接口超时可以重试或切换备用通道业务规则不满足可能需要人工介入模型识别错误则需要更新 Prompt 或补充训练数据。把每次失败样本都记录下来定期分析就能逐渐定位完成率损失最大的环节。这也是为什么评测集和监控体系对智能引擎这么重要。3. 把任务完成率做到 99% 的工程手段3.1 意图识别不是单选题很多团队做智能引擎时会把意图识别当成一个多分类问题给一段文本判断它属于哪个意图。这样做的局限在于真实用户表达往往模糊、间接、口语化。用户说“这个商品我不想要了”可能是在退款也可能是在取消订单还可能只是吐槽。更稳妥的做法是让意图识别输出带置信度的结果并设置阈值。高置信度直接执行低置信度进入澄清追问更低置信度转入人工兜底。这样避免“硬猜”导致的方向性错误。同时要保留一个 fallback 意图所有无法识别的输入都落到这里由兜底链路处理。我见过不少接入大模型的团队第一版只靠 Prompt 做意图识别没有置信度判断结果是模型经常给出似是而非的结果任务完成率反而比规则版更低。原因不是模型能力不够而是缺少不确定性管理。3.2 状态管理与多轮上下文任务的第二个特点是多轮性。用户说“帮我退一下订单”系统问“哪个订单”用户回答“就是昨天买的那件衣服”。如果系统不维护上下文第二轮就无法理解“那件衣服”指什么。状态管理要区分短期会话状态和持久化状态。短期状态存在于一次会话中保存当前意图、已抽取的槽位、等待用户补充的字段持久化状态则对应到用户、订单、设备等业务实体。还有一个容易被忽略的点状态存储在服务端还是客户端。为了安全和一致性建议把关键任务状态保存在服务端客户端只保存会话标识。多轮依赖提升完成率的主要方式是减少信息缺失。大量任务失败是因为槽位不全而不是模型不会执行。所以对话管理里可以增加“主动澄清”和“默认值补全”策略在进入执行层之前尽量把参数补齐。3.3 重试、超时与补偿真实系统中接口调用失败是常态。网络抖动、服务超时、数据库锁冲突都会导致任务执行中断。如果失败后立即放弃完成率很难超过 90%。高完成率系统的标配是重试机制。重试需要注意三点区分错误类型网络超时可重试业务校验失败不可重试。使用指数退避第一次失败等待较长时间再重试避免对下游造成压力。保证幂等重试必须携带唯一的请求标识避免重复操作。除了重试长任务还要考虑超时控制。一个任务如果超过用户可接受的时长继续等待只会让体验更差。此时可以降级为异步任务告诉用户“处理中完成后通知你”也可以直接转人工。补偿措施指的是部分子任务已完成但整体失败时要进行反向操作比如创建了订单但支付超时需要自动取消未支付订单。3.4 兜底策略人工交接与二级方案把完成率做到 99%光靠自动链路不可能覆盖所有边界情况。真正让完成率接近 100% 的往往是兜底策略兜住了最后那 1% 到 3% 的疑难任务。兜底分两层方案级兜底一个工具调用失败后尝试备用接口、缓存结果、相似逻辑降级。人工级兜底自动链路多次失败后把上下文完整转交给人工客服或运营人员。这里要强调的是人工兜底不能简单丢一个问题给人工而是要把意图、槽位、已执行步骤、失败原因全部打包。人工看到的应该是一份“任务处理轨迹”而不是一句“用户说要退款”。完善的人工兜底流程本身也是保证完成率口径成立的重要前提。4. 实战从零实现一个轻量智能任务引擎为了把前面的理论落到代码上这一节我们实现一个最小可运行的智能任务引擎。它包含意图路由、任务执行、失败重试、完成率统计四个核心模块。整个项目只有一个 Python 文件不依赖第三方库方便直接复制运行。4.1 项目结构与配置建议先创建这样一个目录结构task_engine_demo/ └── engine_demo.py配置信息直接写在代码里。为了贴近真实使用我把意图规则、执行器成功率、重试次数、测试样本都集中放在一个配置字典中。实际项目中这些配置应放入配置文件或配置中心。下面先看完整代码随后逐段解释。4.2 核心代码实现# 文件路径task_engine_demo/engine_demo.py import random import time from dataclasses import dataclass, field from enum import Enum from typing import Optional class TaskStatus(Enum): PENDING pending RUNNING running SUCCESS success FAILED failed RETRYING retrying GIVEUP giveup dataclass class Task: task_id: str task_type: str payload: dict status: TaskStatus TaskStatus.PENDING max_retries: int 3 retry_count: int 0 result: dict field(default_factorydict) error: str first_attempt_success: Optional[bool] None class IntentRouter: def __init__(self, rules: dict): self.rules rules def route(self, user_input: str) - str: for task_type, keywords in self.rules.items(): for kw in keywords: if kw in user_input: return task_type return fallback class TaskExecutor: def __init__(self, success_rate: float 0.8): self.success_rate success_rate def execute(self, task: Task) - bool: print(f[执行] {task.task_id} | 类型{task.task_type}) # 模拟任务耗时 time.sleep(0.05) # fallback 直接视为转入人工兜底算作闭环 if task.task_type fallback: task.result {code: 0, message: 已转入人工兜底流程} task.status TaskStatus.SUCCESS return True # 用随机数模拟真实接口调用的成功与失败 if random.random() self.success_rate: task.result {code: 0, message: success} task.status TaskStatus.SUCCESS return True task.error executor internal error task.status TaskStatus.FAILED return False class TaskEngine: def __init__(self, router: IntentRouter, executor: TaskExecutor): self.router router self.executor executor self.tasks [] def submit(self, user_input: str) - Task: task_type self.router.route(user_input) task Task( task_idftask-{len(self.tasks) 1}, task_typetask_type, payload{input: user_input}, ) self.tasks.append(task) self._run(task) return task def _run(self, task: Task) - None: while task.retry_count task.max_retries: task.status TaskStatus.RUNNING ok self.executor.execute(task) if task.retry_count 0: task.first_attempt_success ok if ok: return task.retry_count 1 if task.retry_count task.max_retries: break task.status TaskStatus.RETRYING wait_ms 100 * (2 ** task.retry_count) print(f[重试] 第{task.retry_count}次等待{wait_ms}ms) time.sleep(wait_ms / 1000) task.status TaskStatus.GIVEUP print(f[放弃] {task.task_id} 达到最大重试次数) def compute_metrics(tasks): total len(tasks) first_success sum(1 for t in tasks if t.first_attempt_success) final_success sum(1 for t in tasks if t.status TaskStatus.SUCCESS) first_rate first_success / total * 100 if total else 0 final_rate final_success / total * 100 if total else 0 return { total: total, first_success: first_success, first_rate: round(first_rate, 2), final_success: final_success, final_rate: round(final_rate, 2), } def main(): config { router_rules: { create_order: [下单, 购买, 买, 订], query_order: [查, 订单, 物流, 记录], refund_order: [退款, 退货, 退掉], schedule_meeting: [预约, 会议], }, executor_success_rate: 0.8, max_retries: 3, samples: [ 我要买一杯咖啡, 帮我查一下订单状态, 这个商品我要退款, 帮我预约明天下午三点的会议, 下单两本书, 退款申请, 查一下物流到哪了, 我要购买会员, 把昨天的订单退掉, 预约本周五上午的面试会议室, 买一张电影票, 查询上周的消费记录, 退货商品有质量问题, 帮我订一份午饭外卖, 查询优惠券使用情况, ], } router IntentRouter(config[router_rules]) executor TaskExecutor(success_rateconfig[executor_success_rate]) engine TaskEngine(router, executor) for sample in config[samples]: task engine.submit(sample) print( f[结果] {task.task_id} | 类型{task.task_type} | f状态{task.status.value} | 结果{task.result or task.error} ) print(- * 60) metrics compute_metrics(engine.tasks) print(f[统计] 总任务数{metrics[total]}) print(f[统计] 首次执行成功率{metrics[first_rate]}%) print(f[统计] 最终任务完成率{metrics[final_rate]}%) if __name__ __main__: main()这段代码是一个刻意简化的模型但它已经包含了真实引擎的四个关键部分。IntentRouter负责把用户输入路由到对应任务类型对应理解层TaskExecutor模拟外部接口调用并随机产生成功或失败对应执行层TaskEngine中的_run方法实现了重试逻辑对应稳定性保障compute_metrics统计首次成功率和最终完成率对应指标观测。4.3 运行与预期输出在命令行运行python engine_demo.py由于执行器使用了随机概率每次输出不会完全一样。正常情况下会看到类似下面的输出[执行] task-1 | 类型create_order [结果] task-1 | 类型create_order | 状态success | 结果{code: 0, message: success} ------------------------------------------------------------ [执行] task-2 | 类型query_order [结果] task-2 | 类型query_order | 状态success | 结果{code: 0, message: success} ------------------------------------------------------------ ... [统计] 总任务数15 [统计] 首次执行成功率80.0% [统计] 最终任务完成率100.0%从统计结果可以看到重试机制的价值。我把执行器成功率故意调低到 80%是为了演示即使首次执行只有八成左右成功经过最多三次重试后最终完成率会非常接近 100%。真实生产系统的接口成功率通常更高但重试逻辑同样是提升完成率最直接的手段之一。4.4 如何把示例迁移到真实生产这个示例只适合入门理解如果要迁移到生产环境需要做以下几件事把规则路由替换为模型规则混合的意图识别并增加置信度阈值判断。把TaskExecutor中的模拟逻辑替换为真实的 API 调用并接入超时控制和错误码分类。把内存中的self.tasks替换为数据库或消息队列保证任务状态可恢复。引入配置中心管理重试次数、超时时间、各场景的执行策略。增加任务追踪 ID把每一轮的输入、输出、耗时、重试次数、失败原因完整记录。这样改写之后示例中的思路就能应用到真实业务中。5. 任务完成率的度量、评测与监控5.1 先统一指标口径很多团队在完成率目标上争论不休本质是口径不统一。建议至少区分下面几个指标指标名称定义注意事项请求受理率系统成功受理的任务数 / 用户发起请求总数排除直接拒绝、非法请求的情况首次执行成功率不重试、不兜底第一次执行就成功的比例反映模型和接口的真实质量最终任务完成率经过重试、补偿、降级后成功完成的比例对外宣传通常使用这个口径业务结果达成率以业务库最终数据为准确认业务真实发生需要与业务系统对账用户满意率用户明确反馈满意或完成闭环的比例适合长期体验评估每次分析完成率时先说明用的是哪个口径再分析数据否则容易得出错误结论。比如最终完成率 99% 但首次执行成功率只有 80%说明系统大量依赖重试和兜底从用户体验角度仍存在优化空间。5.2 评测集离线与线上评测集是完成率持续优化的基础。建议维护三类数据历史日志样本从线上日志中抽取正常和异常任务。用户反馈样本用户主动投诉或给出低分评价的任务。运营构造样本覆盖新业务场景和边界情况的模拟样本。每条评测样本至少包含字段原始输入、期望意图、期望槽位、期望执行路径、最终状态。模型升级前先跑一遍离线评测集对比新旧版本的完成率变化。线上则通过小流量实验验证。这种方式可以避免“模型指标涨了线上任务完成率却降了”的尴尬情况。评测样例可以用 JSON 组织[ { case_id: case_001, input: 我要把昨天的订单退掉, expected_intent: refund_order, expected_slots: {time: 昨天}, expected_status: success } ]5.3 线上监控与告警线上监控的核心是围绕完成率建立可观测体系。每次任务执行都要打点记录关键信息建议至少包含{ task_id: task-1736150400123-1, scene: create_order, model_version: your-model-version, first_attempt: 0, retry_count: 1, final_status: success, latency_ms: 823, need_human: 0, error_type: }监控告警建议关注四个指标最终任务完成率、首次执行成功率、重试率、兜底率。完成率跌破目标阈值时要立即定位是模型问题、接口问题还是配置问题。重试率突然升高很可能说明上游接口不稳定。兜底率持续偏高说明自动链路存在系统性短板需要专项优化。6. 常见问题与排查思路问题现象常见原因解决思路任务完成率长期上不去失败样本分散在多个环节没有集中优化按链路拆解完成率找到损失最大的环节优先处理单场景完成率特别低意图规则或 Prompt 对高频表达覆盖不足补充该场景的线上样本更新规则和 Prompt重试导致重复下单工具调用不具备幂等性在接口层增加 request_id 幂等校验兜底占比过高自动链路能力不足过于依赖人工分析兜底原因针对 Top 问题补充自动处理能力模型升级后完成率下降新版本模型在特定场景表现回退保留旧版本模型做 A/B 对比后回滚用户中断后任务无法恢复任务状态没有持久化把任务状态写入数据库支持断点恢复排查完成率问题时建议按下面的顺序检查先看指标口径是否一致再看失败集中在哪一个环节然后看失败原因分类最后针对最大的一类原因做专项优化。不要一开始就调模型很多完成率损失发生在执行层和兜底层模型改得再频繁也解决不了接口超时的问题。7. 最佳实践与工程建议7.1 架构上把理解、执行、兜底分层智能任务引擎最怕把所有逻辑堆在同一个大模型调用里。一旦模型输出不理想整个任务失败且无法定位问题。建议把系统拆成理解层、执行层、兜底层三层。理解层负责从自然语言到结构化意图执行层负责调用工具和编排任务兜底层负责处理异常和人工交接。每一层独立迭代、独立评测、独立监控这样完成率的损失点才能清晰呈现。分层之后每一层的优化路径也更明确。理解层问题看 Prompt 和标注数据执行层问题看接口稳定性和幂等性兜底层问题看人工处理效率。不要试图用一个万能模型覆盖所有环节。7.2 稳定性与安全幂等、最小权限、限流任务引擎在真实生产中会触达订单、支付、退款等核心业务稳定性和安全边界必须提前设计。重试要幂等接口要超时调用要限流权限要最小化。智能体能够调用的工具范围应该严格受限每次调用前校验用户身份和操作权限避免越权操作。生产环境还有一个容易被忽视的问题外部接口的依赖方向。如果智能引擎下游同时依赖多个内部服务最好引入熔断机制。某个服务故障时任务可以降级为“转人工处理”而不是长时间卡在等待状态。这种降级策略可以有效保护整体完成率。7.3 数据闭环让每次失败都变成下一轮样本智能引擎最珍贵的资产是真实任务数据。每次失败、每次人工兜底、每次用户不满都是下一轮优化的数据来源。建议团队建立一个“失败样本评审”机制每周固定分析新增失败样本判断失败原因模型识别错误、规则覆盖不足、接口问题还是流程设计缺陷。然后按优先级修复。数据闭环还包括成功样本的积累。用户走通一条路径后这组输入、中间状态、最终结果也可以作为正样本。后续做评测集、模型微调、Prompt 优化时这些数据都能派 任务完成率99%的智能引擎工程实现：从意图识别到兜底策略
最近百度 DuMate 升级的消息在开发者圈子里有不少讨论。这次升级对外释放的核心信息是背后的智能引擎把任务完成率做到了 99% 以上。很多同学看到这个数字第一反应可能是“又是宣传口径”。但如果从工程维度去看一个面向真实用户场景的智能任务引擎要把完成率稳定在 99%并不是只靠一个更大的模型就能解决的。这篇文章不打算重复发布会式的表述而是聚焦工程实现任务完成率到底怎么定义、智能引擎处理任务的链路是什么、提升完成率有哪些关键手段以及一个可以运行的最小实现。不管你是做大模型应用、智能客服还是做 Agent 类产品都可以把这篇当成一份可落地的工程笔记。需要先说明的是本文不会给出 DuMate 内部架构的细节因为外部公开信息有限能确认的是这次升级的重点是“智能引擎”和“任务完成率”这两个关键词。我会围绕这两个关键词把通用技术路径讲透。文章包含完整代码示例、指标口径、常见问题排查和工程建议有基础的开发者可以直接跳到代码部分新手建议从第 1 节往下读。1. 背景DuMate 升级背后为什么要看任务完成率1.1 这次升级在讲什么从公开信息看DuMate 的定位更偏向智能助手和任务型智能体方向。早期类似产品更多强调“能聊天”用户问什么都能答但答完之后事情并没有被真正办成。而这次升级说的“智能引擎任务完成率超 99%”意味着产品重心从单轮问答转向了端到端的任务处理。也就是用户说“帮我把这个订单退掉”系统不光要理解这句话还要真正完成查询订单、校验状态、发起退款、返回结果这一整串动作。这种转变背后是产品评判标准的改变。聊天场景看的是回答是否流畅、信息是否准确任务场景看的是事情有没有办成。用户不会因为你解释了订单状态就满意他要的是退款流程被正确触发。因此任务完成率成为比响应准确率更核心的指标。文章后面会说明完成率也不是一个简单的除法不同口径下的 99% 含金量完全不同。1.2 为什么任务完成率比准确率更值得关注传统 NLP 系统评估经常用准确率、召回率、F1 值这些指标衡量的是“模型判断得对不对”。但在任务型智能引擎里判断对只是第一步。系统识别出用户要退款但如果调用了错误的接口或者执行到一半超时或者重复提交了两笔退款用户依然会认为这个助手“不好用”。任务完成率衡量的则是端到端的结果一个任务从接到用户输入开始经过理解、编排、执行、反馈最终是否以用户预期的方式结束。它可以理解为任务完成率 成功完成用户任务的数量 / 系统受理任务的总数量这个指标天然包含了模型能力、接口稳定性、重试策略、人工兜底等多层因素。这也解释了为什么很多团队发现模型效果测试分数很高线上任务完成率却不理想。模型只是链路中的一个环节真正的瓶颈往往在执行层和兜底层。1.3 99% 的合理预期先看口径看到 99% 这个数字我的建议是先问一句这个完成率是怎么统计的是首次执行成功率还是经过重试和人工兜底之后的最终完成率是用户主动确认成功还是系统单方面认为成功有没有把平台内部可以兜底的场景也算进去不同口径算出来的数字差异非常大。如果只统计“模型成功识别出意图”的比例大部分场景做到 95% 以上并不难如果统计“用户最终在页面上完成了下单”难度会明显上升。一个可信的任务完成率至少要区分三个层次首次执行成功率不经过任何重试和兜底第一次就把任务做完。最终任务完成率允许重试、补偿、降级、人工接管后的最终结果。业务结果达成率以业务系统的最终数据为准比如订单是否真实创建、退款是否真实到账。DuMate 声称超过 99%大概率指经过完整链路保障后的最终完成率。这个数字要成立背后必须有稳定的重试机制、兜底机制和监控体系。下面从一次任务的完整链路开始拆解。2. 智能引擎如何处理一次任务2.1 一次任务处理的完整链路把“任务完成”这个目标拆开一次任务处理通常包含下面几个环节输入接入接收用户的文本、语音或指令。意图识别判断用户想做什么属于哪个业务场景。槽位抽取提取完成任务所需的参数比如订单号、商品 ID、时间、地址。任务编排把目标拆成一个或多个子任务确定执行顺序。工具调用调用内部 API 或外部工具完成查询、创建、修改等操作。结果生成把执行结果组织成用户能看懂的语言。反馈回流记录成功或失败原因把失败样本送入改进闭环。这个链路看起来不复杂但每一个环节都可能成为完成率的杀手。意图识别错了后面全部白做参数缺了接口必然报错工具调用失败任务只能中断。所以高完成率的产品绝对不是某一个模型很强而是整条链路每一层都做了容错设计。2.2 理解层从用户输入到结构化意图理解层是任务的起点。它的目标是把自然语言转成结构化指令。以一次退款任务为例系统需要知道意图refund_order 槽位{order_id: SO20250101001, reason: 商品质量问题}现代实现一般有两种方式一种是基于大模型的 Prompt 抽取一种是传统的规则加模型分类。大模型方式灵活适合长尾表达规则方式稳定可控适合高频标准化场景。实际工程中两者通常组合使用规则兜住高确定性场景模型处理开放表达。下面是一个简化版的任务理解 Prompt 模板你是一个任务理解引擎。 请从用户输入中识别意图和抽取关键槽位。 可选意图create_order下单、query_order查单、refund_order退款、schedule_meeting预约会议。 输出 JSON 格式{intent: xxx, slots: {xxx: xxx}}。 用户输入{user_input}这里的重点不是 Prompt 写得多花哨而是要给模型一个清晰的输出结构和边界。意图枚举越明确模型越容易稳定输出槽位定义越具体下游任务编排越容易执行。2.3 执行层工具调用与任务编排理解层输出了“用户想做什么”执行层负责“真正把事做成”。一个复杂任务往往要拆成多个子任务。比如“下单并预约配送时间”需要先创建订单再查询可配送时段最后预约物流。任何一个子任务失败整体任务都可能失败。执行层的关键设计是任务编排和工具抽象。每一个工具都应该有清晰的入参、出参、错误码。常见做法是让模型具备函数调用能力模型根据意图选择工具再传递对应参数。为了便于工程控制生产环境通常不会让模型直接调用真实接口而是让模型生成“工具调用意图”由后台代码做参数校验、鉴权、限流和实际发送。这里特别要提醒幂等设计。任务引擎经常需要重试如果重试导致同一个订单被创建两次那完成率再高也没有意义。工具层必须支持幂等键比如用request_id或task_id作为唯一标识让重复调用不产生重复业务数据。2.4 反馈层失败恢复与经验回流一次任务失败后系统不能直接放弃。反馈层要做三件事记录失败原因、执行补偿措施、把样本回流到评测集。失败原因要分类比如参数缺失、接口超时、业务规则不满足、模型识别错误。不同原因的处置方式完全不同。参数缺失可以反问用户补全接口超时可以重试或切换备用通道业务规则不满足可能需要人工介入模型识别错误则需要更新 Prompt 或补充训练数据。把每次失败样本都记录下来定期分析就能逐渐定位完成率损失最大的环节。这也是为什么评测集和监控体系对智能引擎这么重要。3. 把任务完成率做到 99% 的工程手段3.1 意图识别不是单选题很多团队做智能引擎时会把意图识别当成一个多分类问题给一段文本判断它属于哪个意图。这样做的局限在于真实用户表达往往模糊、间接、口语化。用户说“这个商品我不想要了”可能是在退款也可能是在取消订单还可能只是吐槽。更稳妥的做法是让意图识别输出带置信度的结果并设置阈值。高置信度直接执行低置信度进入澄清追问更低置信度转入人工兜底。这样避免“硬猜”导致的方向性错误。同时要保留一个 fallback 意图所有无法识别的输入都落到这里由兜底链路处理。我见过不少接入大模型的团队第一版只靠 Prompt 做意图识别没有置信度判断结果是模型经常给出似是而非的结果任务完成率反而比规则版更低。原因不是模型能力不够而是缺少不确定性管理。3.2 状态管理与多轮上下文任务的第二个特点是多轮性。用户说“帮我退一下订单”系统问“哪个订单”用户回答“就是昨天买的那件衣服”。如果系统不维护上下文第二轮就无法理解“那件衣服”指什么。状态管理要区分短期会话状态和持久化状态。短期状态存在于一次会话中保存当前意图、已抽取的槽位、等待用户补充的字段持久化状态则对应到用户、订单、设备等业务实体。还有一个容易被忽略的点状态存储在服务端还是客户端。为了安全和一致性建议把关键任务状态保存在服务端客户端只保存会话标识。多轮依赖提升完成率的主要方式是减少信息缺失。大量任务失败是因为槽位不全而不是模型不会执行。所以对话管理里可以增加“主动澄清”和“默认值补全”策略在进入执行层之前尽量把参数补齐。3.3 重试、超时与补偿真实系统中接口调用失败是常态。网络抖动、服务超时、数据库锁冲突都会导致任务执行中断。如果失败后立即放弃完成率很难超过 90%。高完成率系统的标配是重试机制。重试需要注意三点区分错误类型网络超时可重试业务校验失败不可重试。使用指数退避第一次失败等待较长时间再重试避免对下游造成压力。保证幂等重试必须携带唯一的请求标识避免重复操作。除了重试长任务还要考虑超时控制。一个任务如果超过用户可接受的时长继续等待只会让体验更差。此时可以降级为异步任务告诉用户“处理中完成后通知你”也可以直接转人工。补偿措施指的是部分子任务已完成但整体失败时要进行反向操作比如创建了订单但支付超时需要自动取消未支付订单。3.4 兜底策略人工交接与二级方案把完成率做到 99%光靠自动链路不可能覆盖所有边界情况。真正让完成率接近 100% 的往往是兜底策略兜住了最后那 1% 到 3% 的疑难任务。兜底分两层方案级兜底一个工具调用失败后尝试备用接口、缓存结果、相似逻辑降级。人工级兜底自动链路多次失败后把上下文完整转交给人工客服或运营人员。这里要强调的是人工兜底不能简单丢一个问题给人工而是要把意图、槽位、已执行步骤、失败原因全部打包。人工看到的应该是一份“任务处理轨迹”而不是一句“用户说要退款”。完善的人工兜底流程本身也是保证完成率口径成立的重要前提。4. 实战从零实现一个轻量智能任务引擎为了把前面的理论落到代码上这一节我们实现一个最小可运行的智能任务引擎。它包含意图路由、任务执行、失败重试、完成率统计四个核心模块。整个项目只有一个 Python 文件不依赖第三方库方便直接复制运行。4.1 项目结构与配置建议先创建这样一个目录结构task_engine_demo/ └── engine_demo.py配置信息直接写在代码里。为了贴近真实使用我把意图规则、执行器成功率、重试次数、测试样本都集中放在一个配置字典中。实际项目中这些配置应放入配置文件或配置中心。下面先看完整代码随后逐段解释。4.2 核心代码实现# 文件路径task_engine_demo/engine_demo.py import random import time from dataclasses import dataclass, field from enum import Enum from typing import Optional class TaskStatus(Enum): PENDING pending RUNNING running SUCCESS success FAILED failed RETRYING retrying GIVEUP giveup dataclass class Task: task_id: str task_type: str payload: dict status: TaskStatus TaskStatus.PENDING max_retries: int 3 retry_count: int 0 result: dict field(default_factorydict) error: str first_attempt_success: Optional[bool] None class IntentRouter: def __init__(self, rules: dict): self.rules rules def route(self, user_input: str) - str: for task_type, keywords in self.rules.items(): for kw in keywords: if kw in user_input: return task_type return fallback class TaskExecutor: def __init__(self, success_rate: float 0.8): self.success_rate success_rate def execute(self, task: Task) - bool: print(f[执行] {task.task_id} | 类型{task.task_type}) # 模拟任务耗时 time.sleep(0.05) # fallback 直接视为转入人工兜底算作闭环 if task.task_type fallback: task.result {code: 0, message: 已转入人工兜底流程} task.status TaskStatus.SUCCESS return True # 用随机数模拟真实接口调用的成功与失败 if random.random() self.success_rate: task.result {code: 0, message: success} task.status TaskStatus.SUCCESS return True task.error executor internal error task.status TaskStatus.FAILED return False class TaskEngine: def __init__(self, router: IntentRouter, executor: TaskExecutor): self.router router self.executor executor self.tasks [] def submit(self, user_input: str) - Task: task_type self.router.route(user_input) task Task( task_idftask-{len(self.tasks) 1}, task_typetask_type, payload{input: user_input}, ) self.tasks.append(task) self._run(task) return task def _run(self, task: Task) - None: while task.retry_count task.max_retries: task.status TaskStatus.RUNNING ok self.executor.execute(task) if task.retry_count 0: task.first_attempt_success ok if ok: return task.retry_count 1 if task.retry_count task.max_retries: break task.status TaskStatus.RETRYING wait_ms 100 * (2 ** task.retry_count) print(f[重试] 第{task.retry_count}次等待{wait_ms}ms) time.sleep(wait_ms / 1000) task.status TaskStatus.GIVEUP print(f[放弃] {task.task_id} 达到最大重试次数) def compute_metrics(tasks): total len(tasks) first_success sum(1 for t in tasks if t.first_attempt_success) final_success sum(1 for t in tasks if t.status TaskStatus.SUCCESS) first_rate first_success / total * 100 if total else 0 final_rate final_success / total * 100 if total else 0 return { total: total, first_success: first_success, first_rate: round(first_rate, 2), final_success: final_success, final_rate: round(final_rate, 2), } def main(): config { router_rules: { create_order: [下单, 购买, 买, 订], query_order: [查, 订单, 物流, 记录], refund_order: [退款, 退货, 退掉], schedule_meeting: [预约, 会议], }, executor_success_rate: 0.8, max_retries: 3, samples: [ 我要买一杯咖啡, 帮我查一下订单状态, 这个商品我要退款, 帮我预约明天下午三点的会议, 下单两本书, 退款申请, 查一下物流到哪了, 我要购买会员, 把昨天的订单退掉, 预约本周五上午的面试会议室, 买一张电影票, 查询上周的消费记录, 退货商品有质量问题, 帮我订一份午饭外卖, 查询优惠券使用情况, ], } router IntentRouter(config[router_rules]) executor TaskExecutor(success_rateconfig[executor_success_rate]) engine TaskEngine(router, executor) for sample in config[samples]: task engine.submit(sample) print( f[结果] {task.task_id} | 类型{task.task_type} | f状态{task.status.value} | 结果{task.result or task.error} ) print(- * 60) metrics compute_metrics(engine.tasks) print(f[统计] 总任务数{metrics[total]}) print(f[统计] 首次执行成功率{metrics[first_rate]}%) print(f[统计] 最终任务完成率{metrics[final_rate]}%) if __name__ __main__: main()这段代码是一个刻意简化的模型但它已经包含了真实引擎的四个关键部分。IntentRouter负责把用户输入路由到对应任务类型对应理解层TaskExecutor模拟外部接口调用并随机产生成功或失败对应执行层TaskEngine中的_run方法实现了重试逻辑对应稳定性保障compute_metrics统计首次成功率和最终完成率对应指标观测。4.3 运行与预期输出在命令行运行python engine_demo.py由于执行器使用了随机概率每次输出不会完全一样。正常情况下会看到类似下面的输出[执行] task-1 | 类型create_order [结果] task-1 | 类型create_order | 状态success | 结果{code: 0, message: success} ------------------------------------------------------------ [执行] task-2 | 类型query_order [结果] task-2 | 类型query_order | 状态success | 结果{code: 0, message: success} ------------------------------------------------------------ ... [统计] 总任务数15 [统计] 首次执行成功率80.0% [统计] 最终任务完成率100.0%从统计结果可以看到重试机制的价值。我把执行器成功率故意调低到 80%是为了演示即使首次执行只有八成左右成功经过最多三次重试后最终完成率会非常接近 100%。真实生产系统的接口成功率通常更高但重试逻辑同样是提升完成率最直接的手段之一。4.4 如何把示例迁移到真实生产这个示例只适合入门理解如果要迁移到生产环境需要做以下几件事把规则路由替换为模型规则混合的意图识别并增加置信度阈值判断。把TaskExecutor中的模拟逻辑替换为真实的 API 调用并接入超时控制和错误码分类。把内存中的self.tasks替换为数据库或消息队列保证任务状态可恢复。引入配置中心管理重试次数、超时时间、各场景的执行策略。增加任务追踪 ID把每一轮的输入、输出、耗时、重试次数、失败原因完整记录。这样改写之后示例中的思路就能应用到真实业务中。5. 任务完成率的度量、评测与监控5.1 先统一指标口径很多团队在完成率目标上争论不休本质是口径不统一。建议至少区分下面几个指标指标名称定义注意事项请求受理率系统成功受理的任务数 / 用户发起请求总数排除直接拒绝、非法请求的情况首次执行成功率不重试、不兜底第一次执行就成功的比例反映模型和接口的真实质量最终任务完成率经过重试、补偿、降级后成功完成的比例对外宣传通常使用这个口径业务结果达成率以业务库最终数据为准确认业务真实发生需要与业务系统对账用户满意率用户明确反馈满意或完成闭环的比例适合长期体验评估每次分析完成率时先说明用的是哪个口径再分析数据否则容易得出错误结论。比如最终完成率 99% 但首次执行成功率只有 80%说明系统大量依赖重试和兜底从用户体验角度仍存在优化空间。5.2 评测集离线与线上评测集是完成率持续优化的基础。建议维护三类数据历史日志样本从线上日志中抽取正常和异常任务。用户反馈样本用户主动投诉或给出低分评价的任务。运营构造样本覆盖新业务场景和边界情况的模拟样本。每条评测样本至少包含字段原始输入、期望意图、期望槽位、期望执行路径、最终状态。模型升级前先跑一遍离线评测集对比新旧版本的完成率变化。线上则通过小流量实验验证。这种方式可以避免“模型指标涨了线上任务完成率却降了”的尴尬情况。评测样例可以用 JSON 组织[ { case_id: case_001, input: 我要把昨天的订单退掉, expected_intent: refund_order, expected_slots: {time: 昨天}, expected_status: success } ]5.3 线上监控与告警线上监控的核心是围绕完成率建立可观测体系。每次任务执行都要打点记录关键信息建议至少包含{ task_id: task-1736150400123-1, scene: create_order, model_version: your-model-version, first_attempt: 0, retry_count: 1, final_status: success, latency_ms: 823, need_human: 0, error_type: }监控告警建议关注四个指标最终任务完成率、首次执行成功率、重试率、兜底率。完成率跌破目标阈值时要立即定位是模型问题、接口问题还是配置问题。重试率突然升高很可能说明上游接口不稳定。兜底率持续偏高说明自动链路存在系统性短板需要专项优化。6. 常见问题与排查思路问题现象常见原因解决思路任务完成率长期上不去失败样本分散在多个环节没有集中优化按链路拆解完成率找到损失最大的环节优先处理单场景完成率特别低意图规则或 Prompt 对高频表达覆盖不足补充该场景的线上样本更新规则和 Prompt重试导致重复下单工具调用不具备幂等性在接口层增加 request_id 幂等校验兜底占比过高自动链路能力不足过于依赖人工分析兜底原因针对 Top 问题补充自动处理能力模型升级后完成率下降新版本模型在特定场景表现回退保留旧版本模型做 A/B 对比后回滚用户中断后任务无法恢复任务状态没有持久化把任务状态写入数据库支持断点恢复排查完成率问题时建议按下面的顺序检查先看指标口径是否一致再看失败集中在哪一个环节然后看失败原因分类最后针对最大的一类原因做专项优化。不要一开始就调模型很多完成率损失发生在执行层和兜底层模型改得再频繁也解决不了接口超时的问题。7. 最佳实践与工程建议7.1 架构上把理解、执行、兜底分层智能任务引擎最怕把所有逻辑堆在同一个大模型调用里。一旦模型输出不理想整个任务失败且无法定位问题。建议把系统拆成理解层、执行层、兜底层三层。理解层负责从自然语言到结构化意图执行层负责调用工具和编排任务兜底层负责处理异常和人工交接。每一层独立迭代、独立评测、独立监控这样完成率的损失点才能清晰呈现。分层之后每一层的优化路径也更明确。理解层问题看 Prompt 和标注数据执行层问题看接口稳定性和幂等性兜底层问题看人工处理效率。不要试图用一个万能模型覆盖所有环节。7.2 稳定性与安全幂等、最小权限、限流任务引擎在真实生产中会触达订单、支付、退款等核心业务稳定性和安全边界必须提前设计。重试要幂等接口要超时调用要限流权限要最小化。智能体能够调用的工具范围应该严格受限每次调用前校验用户身份和操作权限避免越权操作。生产环境还有一个容易被忽视的问题外部接口的依赖方向。如果智能引擎下游同时依赖多个内部服务最好引入熔断机制。某个服务故障时任务可以降级为“转人工处理”而不是长时间卡在等待状态。这种降级策略可以有效保护整体完成率。7.3 数据闭环让每次失败都变成下一轮样本智能引擎最珍贵的资产是真实任务数据。每次失败、每次人工兜底、每次用户不满都是下一轮优化的数据来源。建议团队建立一个“失败样本评审”机制每周固定分析新增失败样本判断失败原因模型识别错误、规则覆盖不足、接口问题还是流程设计缺陷。然后按优先级修复。数据闭环还包括成功样本的积累。用户走通一条路径后这组输入、中间状态、最终结果也可以作为正样本。后续做评测集、模型微调、Prompt 优化时这些数据都能派