1. 从“能聊天”到“能办事”对话式 AI 的第五次能力跃迁如果你在过去两年里持续关注对话式 AI 和聊天机器人会发现一个很明显的分水岭早期大家比拼的是“能不能流畅对话”后来比拼的是“能不能理解上下文”再往后是“能不能调用工具”而现在——也就是我把它称为“第五阶段”的这个节点——比拼的核心变成了能不能稳定地完成一件完整的事。这个变化听起来好像只是措辞上的微调但实际做项目的人都知道这背后是完全不同的工程逻辑。前几个阶段你只要把模型接进来、把提示词调好、把上下文窗口撑大基本就能跑出一个像样的 Demo。但到了“办事”这个层面问题就变得复杂了模型要能拆解任务、要能记住中间状态、要能在多轮对话里保持目标不漂移、还要在工具调用失败时知道怎么兜底。这些东西光靠一个提示词模板是解决不了的。我写这一篇是想把“对话式 AI 第五阶段”这件事拆开来讲清楚。它到底和前面四个阶段有什么本质区别为什么很多团队在第四阶段做得不错一到第五阶段就卡住如果你现在正在做聊天机器人、智能客服、任务型对话系统或者只是想搞清楚 ChatGPT 这类产品下一步会往哪走那这篇内容应该能给你一些可以直接参考的东西。需要先说明一点这里说的“第五阶段”不是某个官方定义而是我在实际项目里总结出来的一套观察框架。它不一定严谨但足够实用——尤其是当你要判断一个对话式 AI 项目到底处在什么水平、下一步该往哪补的时候这个框架比很多技术文档都好用。2. 五个阶段的划分逻辑为什么“办事能力”是分水岭2.1 前四个阶段各自解决了什么问题先把前面四个阶段快速过一遍这样你才能看清第五阶段到底新在哪。第一阶段单轮问答。这是最原始的形态用户问一句系统答一句没有上下文没有记忆。典型代表就是早期的规则型客服机器人你问“营业时间”它回“9:00-18:00”你再问“那周末呢”它就不知道你在说什么了。这个阶段的核心技术是意图识别加模板匹配工程上很简单但体验很割裂。第二阶段多轮上下文。模型开始能记住前面几轮说了什么用户可以说“帮我订一张去北京的票”然后接着说“改成后天”系统能理解“改成后天”指的是那张票。这个阶段的关键突破是上下文窗口的管理以及对话状态跟踪DST的引入。但这时候的“记忆”还是很脆弱的轮次一多就容易丢信息。第三阶段指令遵循与角色扮演。大模型进来之后大家发现只要提示词写得好模型可以扮演各种角色、遵循复杂指令。你可以让它“用客服的语气回答不要用专业术语遇到不确定的问题就说需要转人工”。这个阶段让聊天机器人的“人设”变得可控但本质上还是“说得好听”不代表“做得对”。第四阶段工具调用与检索增强。这是最近两年最热的方向。模型可以调用外部 API、可以查知识库、可以执行代码。你问“今天天气怎么样”它知道去调天气接口你问“公司报销政策是什么”它知道去检索内部文档。这个阶段让对话式 AI 从“嘴炮”变成了“有手有脚”但问题也很明显单次工具调用可以多步任务就容易乱。第五阶段任务闭环与自主执行。这就是我们现在说的“能办事”。它要求模型不仅能调用工具还要能规划步骤、管理中间状态、处理异常、验证结果最终把一个完整任务从头到尾做完。比如“帮我安排下周去上海的出差”它要能拆成查航班、比价格、选酒店、看日程冲突、发确认邮件这一串动作而且中间任何一步出问题都要能自己调整。2.2 第五阶段的三个硬指标怎么判断一个对话式 AI 是不是真的到了第五阶段我一般看三个指标。第一个是任务完成率而不是对话流畅度。很多团队还在用“用户满意度”或者“回复相关性”来衡量但这些指标在第五阶段是不够的。你要看的是用户提出一个复合任务系统能不能在不人工干预的情况下把它做完。比如“帮我退掉上周买的那件衣服然后重新下单换个大一号的”这个任务涉及查订单、发起退货、重新下单、可能还要处理差价能闭环才算数。第二个是异常恢复能力。第五阶段的系统一定会遇到工具调用失败、信息缺失、用户中途改主意这些情况。关键不是不出错而是出错之后能不能自己兜回来。比如查航班接口超时了它是直接报错还是能换个数据源重试或者至少告诉用户“航班信息暂时查不到我先帮你把酒店定好稍后再确认航班”。第三个是状态保持的持久性。前几个阶段的上下文管理基本是“对话内记忆”一轮对话结束就忘了。但第五阶段的任务往往跨会话、跨天。用户今天说“帮我盯着这个项目的进度”明天再问“进度怎么样了”系统得能接上。这背后需要的是持久化的任务状态存储而不是简单的对话历史拼接。注意很多团队在第四阶段做得很好工具调用很顺但一上第五阶段就发现模型“记不住事”。根本原因不是模型不行而是架构里缺少任务状态层。对话历史不等于任务状态这是两回事。3. 任务规划与拆解第五阶段最容易被低估的环节3.1 为什么“让模型自己规划”往往不靠谱一说到任务规划很多人的第一反应是“让模型自己拆解步骤”。这个思路在简单任务上没问题比如“帮我查一下明天北京的天气”模型直接调天气接口就完了。但一旦任务变复杂纯靠模型自由发挥的规划就会出问题。我踩过的一个典型坑是让模型规划“帮我安排一次团队建设活动”它给出的步骤是“确定人数→选地点→定时间→发通知”。看起来没问题但实际执行时你会发现它没有考虑“预算”这个约束也没有考虑“地点要离公司近”这个隐含条件。结果就是规划出来的步骤虽然逻辑通顺但执行到一半发现预算超了或者选的地点太远整个任务就得推倒重来。问题的根源在于模型的规划是“语言层面”的不是“约束层面”的。它擅长把任务拆成看起来合理的步骤但不擅长在拆解过程中同时满足多个硬性约束。而这些约束往往才是任务能不能真正完成的关键。3.2 我实际用的“约束前置”规划法后来我调整了做法不再让模型直接输出步骤而是先让它把约束条件列出来再基于约束生成规划。具体分三步。第一步约束提取。用户提出任务后先让模型识别出所有显性和隐性约束。比如“帮我安排一次团队建设活动”显性约束可能是“下周五之前”“预算人均200以内”隐性约束可能是“不能占用周末”“地点要在市区”“要能容纳20人”。这一步的输出是一个约束列表而不是行动计划。第二步约束校验。把约束列表拿给用户确认或者至少让模型自己检查一遍有没有冲突。比如“人均200以内”和“要能容纳20人”可能就有冲突因为能容纳20人的场地通常人均成本更高。这一步能提前暴露很多问题避免执行到一半才发现做不了。第三步基于约束生成规划。这时候再让模型拆解步骤它就会带着约束去规划而不是天马行空。比如它会优先推荐“市区内人均150左右的轰趴馆”而不是“郊区的高端度假村”。这个方法的实测效果比直接让模型规划好很多。任务完成率大概能从40%左右提升到70%以上尤其是在涉及预算、时间、地点这类硬约束的场景里。3.3 规划粒度的控制技巧还有一个容易被忽略的点是规划粒度。拆得太粗执行时容易卡住拆得太细又容易过度设计。我的经验是规划粒度以“单步可验证”为准。也就是说每一步做完之后你都能明确判断它是成功还是失败。比如“查航班”这一步成功就是拿到了航班列表失败就是接口报错或者没有结果。而“安排出差”这种粒度就太粗了做完之后你没法判断它到底算不算完成。具体操作上我会在提示词里加一句“请把任务拆解成若干步骤每个步骤都必须有明确的完成标准且单步执行时间不超过30秒。”这个约束能有效防止模型把任务拆得太粗或太细。另外对于多步任务我建议在规划阶段就标注出哪些步骤可以并行、哪些必须串行。比如“查航班”和“查酒店”可以并行但“选航班”必须在“查航班”之后。这个信息在执行阶段非常有用能显著缩短任务总耗时。4. 工具调用的稳定性从“能调”到“调得稳”的工程细节4.1 工具描述的质量决定调用成功率很多人以为工具调用就是“把 API 文档扔给模型”但实际做下来你会发现工具描述的质量直接决定了调用成功率。我见过一个典型的反面案例某个团队接了一个“查询订单状态”的工具描述写的是“根据订单号查询订单状态”。结果模型经常把“订单号”和“用户ID”搞混调用失败率很高。后来他们把描述改成“根据订单号查询订单状态订单号格式为18位数字以字母开头例如A123456789012345678”调用成功率立刻上去了。这里的关键是工具描述要包含足够的“判别信息”。模型需要知道这个工具和其他工具的区别在哪什么情况下该用它什么情况下不该用。具体来说一个好的工具描述应该包含工具的功能是什么一句话说清输入参数的格式和约束类型、长度、示例什么场景下应该调用这个工具什么场景下不应该调用如果有容易混淆的工具调用失败时的常见原因4.2 参数校验与重试机制工具调用失败是常态不是异常。所以参数校验和重试机制是必须的。我的做法是在工具调用层加一道“参数校验”逻辑。模型输出的参数先不直接发给 API而是先过一遍校验规则。比如日期格式对不对、必填字段有没有缺、数值范围是否合理。校验不通过的话不直接报错而是把校验结果返回给模型让它重新生成参数。这个机制能解决大部分“模型参数格式不对”的问题。实测下来加上参数校验之后工具调用的首次成功率能从60%左右提升到85%以上。重试机制也要分情况。如果是网络超时直接重试就行如果是参数错误重试前要先让模型修正参数如果是业务逻辑错误比如“订单不存在”重试就没意义了应该直接告诉用户。提示重试次数不要超过3次。超过3次还失败大概率不是偶发问题继续重试只会浪费时间。这时候应该走降级逻辑比如换备用工具、或者告诉用户“这个功能暂时不可用”。4.3 工具调用链的编排第五阶段的任务往往涉及多个工具调用而且这些调用之间有依赖关系。怎么编排这些调用是一个很考验工程能力的地方。我一般用“状态机”的思路来管理工具调用链。每个工具调用是一个状态节点节点之间的跳转条件由前一个节点的执行结果决定。比如“查航班”成功后跳转到“选航班”失败则跳转到“重试或降级”。这种编排方式的好处是逻辑清晰、容易调试。你可以清楚地看到任务卡在了哪个节点而不是面对一团乱麻的调用日志。另外对于可以并行的工具调用我建议用异步方式执行。比如“查航班”和“查酒店”同时发起等两个都返回后再做下一步决策。这样能把任务总耗时从“串行时间之和”降到“最长单步时间”用户体验会好很多。5. 多轮对话中的目标漂移第五阶段最隐蔽的坑5.1 目标漂移是怎么发生的多轮对话里有一个很隐蔽的问题用户聊着聊着话题就偏了。比如用户本来是想“订机票”聊到一半问了一句“那边天气怎么样”模型回答了天气之后用户接着说“那帮我看看有没有靠窗的座位”这时候模型可能就忘了最初的任务是“订机票”而开始处理“选座位”这个新任务。这个问题在第四阶段还不明显因为那时候的任务大多是单轮的。但到了第五阶段任务变复杂、轮次变多目标漂移就成了一个高频问题。我观察下来目标漂移主要有三个原因一是模型对“当前任务”的跟踪不够强。它把每一轮对话都当成独立的请求来处理而不是放在一个持续的任务上下文里。二是用户的语言本身就有歧义。“那帮我看看有没有靠窗的座位”这句话既可以理解为“在订机票这个任务里选座位”也可以理解为“单独查一下座位信息”。模型很难自动区分。三是缺乏显式的任务状态标记。如果系统里没有明确记录“当前正在执行的任务是什么”模型就只能靠对话历史来推断而对话历史里往往充满了干扰信息。5.2 用“任务锚点”防止目标漂移我的解决方案是在对话状态里加一个“任务锚点”。简单说就是每次用户提出一个新任务时系统显式地记录下这个任务的目标和关键约束。后续每一轮对话都先检查当前输入是否与任务锚点相关如果不相关就判断是“任务切换”还是“任务补充”。具体实现上我会在提示词里加入这样的逻辑当前任务锚点{task_anchor} 用户最新输入{user_input} 请判断 1. 用户输入是否与当前任务相关 2. 如果相关是补充信息还是修改需求 3. 如果不相关是否是一个新任务 4. 如果是新任务是否应该暂停当前任务这个判断逻辑看起来简单但实际效果很好。它能把目标漂移的概率降低很多尤其是在长对话场景里。5.3 任务切换与恢复的处理有时候用户确实需要切换任务比如“先别管机票了帮我看看酒店”。这时候系统要能优雅地暂停当前任务并在合适的时候恢复。我的做法是给每个任务维护一个“任务栈”。新任务压栈当前任务暂停用户说“回到刚才那个”时从栈里弹出上一个任务继续执行。这个机制在实测中很实用尤其是用户在多件事之间来回切换的时候。需要注意的是任务栈不能太深。我一般限制在3层以内超过3层就提示用户“当前有多个任务在进行中建议先完成一个再开始新的”。否则用户自己也会乱。6. 持久化任务状态跨会话记忆的工程实现6.1 对话历史不等于任务状态这是我在项目里反复强调的一点对话历史是“说了什么”任务状态是“做到哪了”。两者不能混为一谈。很多团队的做法是把所有对话历史拼起来塞给模型让它自己从中推断任务进度。这在短对话里还行但一旦对话轮次超过20轮或者跨了会话模型就很难准确推断出“当前任务做到哪一步了”。正确的做法是单独维护一个任务状态对象里面记录任务目标已完成步骤当前步骤待完成步骤关键约束中间结果比如已经查到的航班列表这个状态对象在每次对话开始时加载对话结束后保存。模型每次只需要看这个状态对象而不是翻遍所有对话历史。6.2 状态存储的选型与结构设计状态存储的选型要看具体场景。如果是单机部署用 SQLite 就够了如果是分布式部署Redis 或者 MongoDB 更合适。关键不是用什么数据库而是状态结构的设计。我一般用 JSON 来存任务状态结构大概是这样{ task_id: task_20250101_001, goal: 安排下周去上海的出差, constraints: { time: 下周三之前, budget: 人均2000以内 }, steps: [ {name: 查航班, status: completed, result: ...}, {name: 选航班, status: in_progress, result: null}, {name: 查酒店, status: pending, result: null} ], created_at: 2025-01-01T10:00:00Z, updated_at: 2025-01-01T10:05:00Z }这个结构的好处是清晰、可扩展。新增步骤只需要往 steps 数组里加修改约束只需要改 constraints 对象。6.3 状态过期与清理策略任务状态不能无限期保存。我一般设置7天的过期时间超过7天没有更新的任务状态自动清理。这个时间可以根据业务场景调整比如电商场景可能3天就够了项目管理场景可能需要30天。清理策略上我建议用“软删除”而不是直接删。也就是先把状态标记为“已过期”过一段时间再真正删除。这样万一用户回来找还能恢复。另外对于已完成的任务我建议保留一个精简版的记录只保留任务目标和完成时间不保留中间步骤。这样既能支持“历史任务查询”又不会占用太多存储空间。7. 异常处理与降级策略让系统“办不成事”时也不崩7.1 异常分类与处理原则第五阶段的系统一定会遇到异常。关键是把异常分清楚不同异常用不同策略。我一般把异常分成三类第一类是技术异常。比如网络超时、接口报错、数据库连接失败。这类异常的处理原则是“重试优先”因为大概率是偶发问题。第二类是业务异常。比如“订单不存在”“余额不足”“没有符合条件的航班”。这类异常重试没用应该直接告诉用户并给出替代方案。第三类是逻辑异常。比如模型输出了格式不对的参数、任务规划出现了循环依赖。这类异常需要“修正后重试”也就是把异常信息返回给模型让它重新生成。7.2 降级策略的设计降级策略的核心思想是当主要路径走不通时至少给用户一个“部分可用”的结果。比如“查航班”接口挂了降级策略可以是换备用数据源重试如果备用源也不行返回“航班信息暂时不可用但可以帮你先查酒店”如果酒店也查不了至少告诉用户“系统暂时繁忙请稍后再试”而不是直接报错这个思路在实测中很有效。用户对“部分可用”的容忍度远高于“完全不可用”。哪怕只是告诉用户“我记下了你的需求稍后帮你处理”也比直接报错好。7.3 用户沟通的话术设计异常处理不只是技术问题也是沟通问题。同样一个异常不同的说法给用户的感受完全不同。我总结了几条话术设计原则不要暴露技术细节。用户不需要知道“接口返回了500错误”只需要知道“暂时查不到”。给出明确的下一步。比如“请稍后再试”不如“我5分钟后再帮你查一次”。保持任务连续性。如果任务做到一半失败了要告诉用户“已完成的部分还在只需要重试失败的那一步”。注意异常话术要提前写好模板不要临时让模型生成。模型在异常场景下容易生成不准确或者过度承诺的内容提前写好模板更可控。8. 从第四阶段到第五阶段的迁移路径8.1 先补状态层再补规划层如果你现在的系统还在第四阶段想往第五阶段走我的建议是先补状态层再补规划层。原因很简单没有状态层规划层做出来也没用。因为规划出来的步骤需要被记录、被跟踪、被恢复这些都需要状态层支撑。很多团队一上来就搞任务规划结果规划出来的步骤执行到一半就丢了根本原因就是状态层没建好。状态层的建设可以从最简单的开始先用一个 JSON 文件存任务状态跑通“记录-读取-更新”的流程再考虑上数据库。8.2 规划层从“半自动”开始规划层不要一上来就追求全自动。我建议从“半自动”开始模型生成规划但需要用户确认后才执行。这样既能积累规划质量的数据又能避免模型乱规划导致的错误。等规划质量稳定了再逐步放开自动执行。放开的时候也要加限制比如“只对置信度高于80%的规划自动执行”。8.3 异常处理要提前设计异常处理不要等到出问题了再补。在系统设计阶段就要把异常分类、降级策略、话术模板都设计好。我一般会在项目初期就建一个“异常处理清单”列出所有可能出现的异常和对应的处理策略。这个清单在后续开发中会不断补充但初期就要有。9. 实测中的几个反直觉发现9.1 模型能力不是瓶颈架构才是这是我最深的一个体会。很多人觉得第五阶段做不好是因为模型不够强但实际做下来你会发现同样的模型架构设计得好任务完成率能差出好几倍。我做过一个对比实验同一个任务用同样的模型一套架构是“对话历史自由规划”另一套是“任务状态约束前置规划”。前者的任务完成率大概在35%左右后者能到75%以上。模型没变变的是架构。所以如果你现在卡在第四阶段上不去先别急着换模型先看看架构里有没有任务状态层、有没有约束校验、有没有异常处理。9.2 用户对“慢一点但做对”的容忍度很高很多人担心多步任务会让用户等太久。但实测下来用户对“慢一点但做对”的容忍度远高于“快但做错”。一个任务如果能在30秒内完成但结果是错的用户会很生气。但如果能在2分钟内完成结果是对的用户反而会觉得“这个系统挺靠谱”。所以第五阶段的设计原则应该是“先做对再做快”。不要为了追求响应速度而牺牲任务完成率。9.3 显式确认比隐式推断更有效在多步任务里我原本以为模型应该尽量“隐式推断”用户的意图减少打扰。但实测下来显式确认的效果更好。比如“帮我订一张去北京的票”与其让模型推断“哪天走、几点走、什么舱位”不如直接问一句“请问您计划哪天出发”。虽然多了一轮对话但后续的返工率大大降低。这个发现让我调整了很多设计。现在我的原则是关键信息缺失时宁可多问一句也不要猜。猜错的成本远高于多问一句的成本。10. 写在最后第五阶段不是终点把对话式 AI 做到“能办事”这个层面已经能解决很多实际问题了。但我在实际项目里越来越感觉到第五阶段可能只是一个过渡形态。因为“办事”这件事本质上要求系统对业务逻辑有很深的理解。而现在的做法更多是靠提示词和工具调用来“模拟”这种理解。真正要做到稳定可靠可能还需要在业务逻辑层做更多的工作而不是把所有压力都压在模型身上。我目前的一个探索方向是把业务逻辑从提示词里抽出来做成独立的“业务规则引擎”模型只负责“理解意图”和“生成回复”具体的任务执行交给规则引擎。这样模型和业务逻辑解耦系统的稳定性和可维护性都会好很多。这个方向还在验证中等有更多结果了再分享。如果你也在做类似的事情欢迎交流。
1. 从“能聊天”到“能办事”对话式 AI 的第五次能力跃迁如果你在过去两年里持续关注对话式 AI 和聊天机器人会发现一个很明显的分水岭早期大家比拼的是“能不能流畅对话”后来比拼的是“能不能理解上下文”再往后是“能不能调用工具”而现在——也就是我把它称为“第五阶段”的这个节点——比拼的核心变成了能不能稳定地完成一件完整的事。这个变化听起来好像只是措辞上的微调但实际做项目的人都知道这背后是完全不同的工程逻辑。前几个阶段你只要把模型接进来、把提示词调好、把上下文窗口撑大基本就能跑出一个像样的 Demo。但到了“办事”这个层面问题就变得复杂了模型要能拆解任务、要能记住中间状态、要能在多轮对话里保持目标不漂移、还要在工具调用失败时知道怎么兜底。这些东西光靠一个提示词模板是解决不了的。我写这一篇是想把“对话式 AI 第五阶段”这件事拆开来讲清楚。它到底和前面四个阶段有什么本质区别为什么很多团队在第四阶段做得不错一到第五阶段就卡住如果你现在正在做聊天机器人、智能客服、任务型对话系统或者只是想搞清楚 ChatGPT 这类产品下一步会往哪走那这篇内容应该能给你一些可以直接参考的东西。需要先说明一点这里说的“第五阶段”不是某个官方定义而是我在实际项目里总结出来的一套观察框架。它不一定严谨但足够实用——尤其是当你要判断一个对话式 AI 项目到底处在什么水平、下一步该往哪补的时候这个框架比很多技术文档都好用。2. 五个阶段的划分逻辑为什么“办事能力”是分水岭2.1 前四个阶段各自解决了什么问题先把前面四个阶段快速过一遍这样你才能看清第五阶段到底新在哪。第一阶段单轮问答。这是最原始的形态用户问一句系统答一句没有上下文没有记忆。典型代表就是早期的规则型客服机器人你问“营业时间”它回“9:00-18:00”你再问“那周末呢”它就不知道你在说什么了。这个阶段的核心技术是意图识别加模板匹配工程上很简单但体验很割裂。第二阶段多轮上下文。模型开始能记住前面几轮说了什么用户可以说“帮我订一张去北京的票”然后接着说“改成后天”系统能理解“改成后天”指的是那张票。这个阶段的关键突破是上下文窗口的管理以及对话状态跟踪DST的引入。但这时候的“记忆”还是很脆弱的轮次一多就容易丢信息。第三阶段指令遵循与角色扮演。大模型进来之后大家发现只要提示词写得好模型可以扮演各种角色、遵循复杂指令。你可以让它“用客服的语气回答不要用专业术语遇到不确定的问题就说需要转人工”。这个阶段让聊天机器人的“人设”变得可控但本质上还是“说得好听”不代表“做得对”。第四阶段工具调用与检索增强。这是最近两年最热的方向。模型可以调用外部 API、可以查知识库、可以执行代码。你问“今天天气怎么样”它知道去调天气接口你问“公司报销政策是什么”它知道去检索内部文档。这个阶段让对话式 AI 从“嘴炮”变成了“有手有脚”但问题也很明显单次工具调用可以多步任务就容易乱。第五阶段任务闭环与自主执行。这就是我们现在说的“能办事”。它要求模型不仅能调用工具还要能规划步骤、管理中间状态、处理异常、验证结果最终把一个完整任务从头到尾做完。比如“帮我安排下周去上海的出差”它要能拆成查航班、比价格、选酒店、看日程冲突、发确认邮件这一串动作而且中间任何一步出问题都要能自己调整。2.2 第五阶段的三个硬指标怎么判断一个对话式 AI 是不是真的到了第五阶段我一般看三个指标。第一个是任务完成率而不是对话流畅度。很多团队还在用“用户满意度”或者“回复相关性”来衡量但这些指标在第五阶段是不够的。你要看的是用户提出一个复合任务系统能不能在不人工干预的情况下把它做完。比如“帮我退掉上周买的那件衣服然后重新下单换个大一号的”这个任务涉及查订单、发起退货、重新下单、可能还要处理差价能闭环才算数。第二个是异常恢复能力。第五阶段的系统一定会遇到工具调用失败、信息缺失、用户中途改主意这些情况。关键不是不出错而是出错之后能不能自己兜回来。比如查航班接口超时了它是直接报错还是能换个数据源重试或者至少告诉用户“航班信息暂时查不到我先帮你把酒店定好稍后再确认航班”。第三个是状态保持的持久性。前几个阶段的上下文管理基本是“对话内记忆”一轮对话结束就忘了。但第五阶段的任务往往跨会话、跨天。用户今天说“帮我盯着这个项目的进度”明天再问“进度怎么样了”系统得能接上。这背后需要的是持久化的任务状态存储而不是简单的对话历史拼接。注意很多团队在第四阶段做得很好工具调用很顺但一上第五阶段就发现模型“记不住事”。根本原因不是模型不行而是架构里缺少任务状态层。对话历史不等于任务状态这是两回事。3. 任务规划与拆解第五阶段最容易被低估的环节3.1 为什么“让模型自己规划”往往不靠谱一说到任务规划很多人的第一反应是“让模型自己拆解步骤”。这个思路在简单任务上没问题比如“帮我查一下明天北京的天气”模型直接调天气接口就完了。但一旦任务变复杂纯靠模型自由发挥的规划就会出问题。我踩过的一个典型坑是让模型规划“帮我安排一次团队建设活动”它给出的步骤是“确定人数→选地点→定时间→发通知”。看起来没问题但实际执行时你会发现它没有考虑“预算”这个约束也没有考虑“地点要离公司近”这个隐含条件。结果就是规划出来的步骤虽然逻辑通顺但执行到一半发现预算超了或者选的地点太远整个任务就得推倒重来。问题的根源在于模型的规划是“语言层面”的不是“约束层面”的。它擅长把任务拆成看起来合理的步骤但不擅长在拆解过程中同时满足多个硬性约束。而这些约束往往才是任务能不能真正完成的关键。3.2 我实际用的“约束前置”规划法后来我调整了做法不再让模型直接输出步骤而是先让它把约束条件列出来再基于约束生成规划。具体分三步。第一步约束提取。用户提出任务后先让模型识别出所有显性和隐性约束。比如“帮我安排一次团队建设活动”显性约束可能是“下周五之前”“预算人均200以内”隐性约束可能是“不能占用周末”“地点要在市区”“要能容纳20人”。这一步的输出是一个约束列表而不是行动计划。第二步约束校验。把约束列表拿给用户确认或者至少让模型自己检查一遍有没有冲突。比如“人均200以内”和“要能容纳20人”可能就有冲突因为能容纳20人的场地通常人均成本更高。这一步能提前暴露很多问题避免执行到一半才发现做不了。第三步基于约束生成规划。这时候再让模型拆解步骤它就会带着约束去规划而不是天马行空。比如它会优先推荐“市区内人均150左右的轰趴馆”而不是“郊区的高端度假村”。这个方法的实测效果比直接让模型规划好很多。任务完成率大概能从40%左右提升到70%以上尤其是在涉及预算、时间、地点这类硬约束的场景里。3.3 规划粒度的控制技巧还有一个容易被忽略的点是规划粒度。拆得太粗执行时容易卡住拆得太细又容易过度设计。我的经验是规划粒度以“单步可验证”为准。也就是说每一步做完之后你都能明确判断它是成功还是失败。比如“查航班”这一步成功就是拿到了航班列表失败就是接口报错或者没有结果。而“安排出差”这种粒度就太粗了做完之后你没法判断它到底算不算完成。具体操作上我会在提示词里加一句“请把任务拆解成若干步骤每个步骤都必须有明确的完成标准且单步执行时间不超过30秒。”这个约束能有效防止模型把任务拆得太粗或太细。另外对于多步任务我建议在规划阶段就标注出哪些步骤可以并行、哪些必须串行。比如“查航班”和“查酒店”可以并行但“选航班”必须在“查航班”之后。这个信息在执行阶段非常有用能显著缩短任务总耗时。4. 工具调用的稳定性从“能调”到“调得稳”的工程细节4.1 工具描述的质量决定调用成功率很多人以为工具调用就是“把 API 文档扔给模型”但实际做下来你会发现工具描述的质量直接决定了调用成功率。我见过一个典型的反面案例某个团队接了一个“查询订单状态”的工具描述写的是“根据订单号查询订单状态”。结果模型经常把“订单号”和“用户ID”搞混调用失败率很高。后来他们把描述改成“根据订单号查询订单状态订单号格式为18位数字以字母开头例如A123456789012345678”调用成功率立刻上去了。这里的关键是工具描述要包含足够的“判别信息”。模型需要知道这个工具和其他工具的区别在哪什么情况下该用它什么情况下不该用。具体来说一个好的工具描述应该包含工具的功能是什么一句话说清输入参数的格式和约束类型、长度、示例什么场景下应该调用这个工具什么场景下不应该调用如果有容易混淆的工具调用失败时的常见原因4.2 参数校验与重试机制工具调用失败是常态不是异常。所以参数校验和重试机制是必须的。我的做法是在工具调用层加一道“参数校验”逻辑。模型输出的参数先不直接发给 API而是先过一遍校验规则。比如日期格式对不对、必填字段有没有缺、数值范围是否合理。校验不通过的话不直接报错而是把校验结果返回给模型让它重新生成参数。这个机制能解决大部分“模型参数格式不对”的问题。实测下来加上参数校验之后工具调用的首次成功率能从60%左右提升到85%以上。重试机制也要分情况。如果是网络超时直接重试就行如果是参数错误重试前要先让模型修正参数如果是业务逻辑错误比如“订单不存在”重试就没意义了应该直接告诉用户。提示重试次数不要超过3次。超过3次还失败大概率不是偶发问题继续重试只会浪费时间。这时候应该走降级逻辑比如换备用工具、或者告诉用户“这个功能暂时不可用”。4.3 工具调用链的编排第五阶段的任务往往涉及多个工具调用而且这些调用之间有依赖关系。怎么编排这些调用是一个很考验工程能力的地方。我一般用“状态机”的思路来管理工具调用链。每个工具调用是一个状态节点节点之间的跳转条件由前一个节点的执行结果决定。比如“查航班”成功后跳转到“选航班”失败则跳转到“重试或降级”。这种编排方式的好处是逻辑清晰、容易调试。你可以清楚地看到任务卡在了哪个节点而不是面对一团乱麻的调用日志。另外对于可以并行的工具调用我建议用异步方式执行。比如“查航班”和“查酒店”同时发起等两个都返回后再做下一步决策。这样能把任务总耗时从“串行时间之和”降到“最长单步时间”用户体验会好很多。5. 多轮对话中的目标漂移第五阶段最隐蔽的坑5.1 目标漂移是怎么发生的多轮对话里有一个很隐蔽的问题用户聊着聊着话题就偏了。比如用户本来是想“订机票”聊到一半问了一句“那边天气怎么样”模型回答了天气之后用户接着说“那帮我看看有没有靠窗的座位”这时候模型可能就忘了最初的任务是“订机票”而开始处理“选座位”这个新任务。这个问题在第四阶段还不明显因为那时候的任务大多是单轮的。但到了第五阶段任务变复杂、轮次变多目标漂移就成了一个高频问题。我观察下来目标漂移主要有三个原因一是模型对“当前任务”的跟踪不够强。它把每一轮对话都当成独立的请求来处理而不是放在一个持续的任务上下文里。二是用户的语言本身就有歧义。“那帮我看看有没有靠窗的座位”这句话既可以理解为“在订机票这个任务里选座位”也可以理解为“单独查一下座位信息”。模型很难自动区分。三是缺乏显式的任务状态标记。如果系统里没有明确记录“当前正在执行的任务是什么”模型就只能靠对话历史来推断而对话历史里往往充满了干扰信息。5.2 用“任务锚点”防止目标漂移我的解决方案是在对话状态里加一个“任务锚点”。简单说就是每次用户提出一个新任务时系统显式地记录下这个任务的目标和关键约束。后续每一轮对话都先检查当前输入是否与任务锚点相关如果不相关就判断是“任务切换”还是“任务补充”。具体实现上我会在提示词里加入这样的逻辑当前任务锚点{task_anchor} 用户最新输入{user_input} 请判断 1. 用户输入是否与当前任务相关 2. 如果相关是补充信息还是修改需求 3. 如果不相关是否是一个新任务 4. 如果是新任务是否应该暂停当前任务这个判断逻辑看起来简单但实际效果很好。它能把目标漂移的概率降低很多尤其是在长对话场景里。5.3 任务切换与恢复的处理有时候用户确实需要切换任务比如“先别管机票了帮我看看酒店”。这时候系统要能优雅地暂停当前任务并在合适的时候恢复。我的做法是给每个任务维护一个“任务栈”。新任务压栈当前任务暂停用户说“回到刚才那个”时从栈里弹出上一个任务继续执行。这个机制在实测中很实用尤其是用户在多件事之间来回切换的时候。需要注意的是任务栈不能太深。我一般限制在3层以内超过3层就提示用户“当前有多个任务在进行中建议先完成一个再开始新的”。否则用户自己也会乱。6. 持久化任务状态跨会话记忆的工程实现6.1 对话历史不等于任务状态这是我在项目里反复强调的一点对话历史是“说了什么”任务状态是“做到哪了”。两者不能混为一谈。很多团队的做法是把所有对话历史拼起来塞给模型让它自己从中推断任务进度。这在短对话里还行但一旦对话轮次超过20轮或者跨了会话模型就很难准确推断出“当前任务做到哪一步了”。正确的做法是单独维护一个任务状态对象里面记录任务目标已完成步骤当前步骤待完成步骤关键约束中间结果比如已经查到的航班列表这个状态对象在每次对话开始时加载对话结束后保存。模型每次只需要看这个状态对象而不是翻遍所有对话历史。6.2 状态存储的选型与结构设计状态存储的选型要看具体场景。如果是单机部署用 SQLite 就够了如果是分布式部署Redis 或者 MongoDB 更合适。关键不是用什么数据库而是状态结构的设计。我一般用 JSON 来存任务状态结构大概是这样{ task_id: task_20250101_001, goal: 安排下周去上海的出差, constraints: { time: 下周三之前, budget: 人均2000以内 }, steps: [ {name: 查航班, status: completed, result: ...}, {name: 选航班, status: in_progress, result: null}, {name: 查酒店, status: pending, result: null} ], created_at: 2025-01-01T10:00:00Z, updated_at: 2025-01-01T10:05:00Z }这个结构的好处是清晰、可扩展。新增步骤只需要往 steps 数组里加修改约束只需要改 constraints 对象。6.3 状态过期与清理策略任务状态不能无限期保存。我一般设置7天的过期时间超过7天没有更新的任务状态自动清理。这个时间可以根据业务场景调整比如电商场景可能3天就够了项目管理场景可能需要30天。清理策略上我建议用“软删除”而不是直接删。也就是先把状态标记为“已过期”过一段时间再真正删除。这样万一用户回来找还能恢复。另外对于已完成的任务我建议保留一个精简版的记录只保留任务目标和完成时间不保留中间步骤。这样既能支持“历史任务查询”又不会占用太多存储空间。7. 异常处理与降级策略让系统“办不成事”时也不崩7.1 异常分类与处理原则第五阶段的系统一定会遇到异常。关键是把异常分清楚不同异常用不同策略。我一般把异常分成三类第一类是技术异常。比如网络超时、接口报错、数据库连接失败。这类异常的处理原则是“重试优先”因为大概率是偶发问题。第二类是业务异常。比如“订单不存在”“余额不足”“没有符合条件的航班”。这类异常重试没用应该直接告诉用户并给出替代方案。第三类是逻辑异常。比如模型输出了格式不对的参数、任务规划出现了循环依赖。这类异常需要“修正后重试”也就是把异常信息返回给模型让它重新生成。7.2 降级策略的设计降级策略的核心思想是当主要路径走不通时至少给用户一个“部分可用”的结果。比如“查航班”接口挂了降级策略可以是换备用数据源重试如果备用源也不行返回“航班信息暂时不可用但可以帮你先查酒店”如果酒店也查不了至少告诉用户“系统暂时繁忙请稍后再试”而不是直接报错这个思路在实测中很有效。用户对“部分可用”的容忍度远高于“完全不可用”。哪怕只是告诉用户“我记下了你的需求稍后帮你处理”也比直接报错好。7.3 用户沟通的话术设计异常处理不只是技术问题也是沟通问题。同样一个异常不同的说法给用户的感受完全不同。我总结了几条话术设计原则不要暴露技术细节。用户不需要知道“接口返回了500错误”只需要知道“暂时查不到”。给出明确的下一步。比如“请稍后再试”不如“我5分钟后再帮你查一次”。保持任务连续性。如果任务做到一半失败了要告诉用户“已完成的部分还在只需要重试失败的那一步”。注意异常话术要提前写好模板不要临时让模型生成。模型在异常场景下容易生成不准确或者过度承诺的内容提前写好模板更可控。8. 从第四阶段到第五阶段的迁移路径8.1 先补状态层再补规划层如果你现在的系统还在第四阶段想往第五阶段走我的建议是先补状态层再补规划层。原因很简单没有状态层规划层做出来也没用。因为规划出来的步骤需要被记录、被跟踪、被恢复这些都需要状态层支撑。很多团队一上来就搞任务规划结果规划出来的步骤执行到一半就丢了根本原因就是状态层没建好。状态层的建设可以从最简单的开始先用一个 JSON 文件存任务状态跑通“记录-读取-更新”的流程再考虑上数据库。8.2 规划层从“半自动”开始规划层不要一上来就追求全自动。我建议从“半自动”开始模型生成规划但需要用户确认后才执行。这样既能积累规划质量的数据又能避免模型乱规划导致的错误。等规划质量稳定了再逐步放开自动执行。放开的时候也要加限制比如“只对置信度高于80%的规划自动执行”。8.3 异常处理要提前设计异常处理不要等到出问题了再补。在系统设计阶段就要把异常分类、降级策略、话术模板都设计好。我一般会在项目初期就建一个“异常处理清单”列出所有可能出现的异常和对应的处理策略。这个清单在后续开发中会不断补充但初期就要有。9. 实测中的几个反直觉发现9.1 模型能力不是瓶颈架构才是这是我最深的一个体会。很多人觉得第五阶段做不好是因为模型不够强但实际做下来你会发现同样的模型架构设计得好任务完成率能差出好几倍。我做过一个对比实验同一个任务用同样的模型一套架构是“对话历史自由规划”另一套是“任务状态约束前置规划”。前者的任务完成率大概在35%左右后者能到75%以上。模型没变变的是架构。所以如果你现在卡在第四阶段上不去先别急着换模型先看看架构里有没有任务状态层、有没有约束校验、有没有异常处理。9.2 用户对“慢一点但做对”的容忍度很高很多人担心多步任务会让用户等太久。但实测下来用户对“慢一点但做对”的容忍度远高于“快但做错”。一个任务如果能在30秒内完成但结果是错的用户会很生气。但如果能在2分钟内完成结果是对的用户反而会觉得“这个系统挺靠谱”。所以第五阶段的设计原则应该是“先做对再做快”。不要为了追求响应速度而牺牲任务完成率。9.3 显式确认比隐式推断更有效在多步任务里我原本以为模型应该尽量“隐式推断”用户的意图减少打扰。但实测下来显式确认的效果更好。比如“帮我订一张去北京的票”与其让模型推断“哪天走、几点走、什么舱位”不如直接问一句“请问您计划哪天出发”。虽然多了一轮对话但后续的返工率大大降低。这个发现让我调整了很多设计。现在我的原则是关键信息缺失时宁可多问一句也不要猜。猜错的成本远高于多问一句的成本。10. 写在最后第五阶段不是终点把对话式 AI 做到“能办事”这个层面已经能解决很多实际问题了。但我在实际项目里越来越感觉到第五阶段可能只是一个过渡形态。因为“办事”这件事本质上要求系统对业务逻辑有很深的理解。而现在的做法更多是靠提示词和工具调用来“模拟”这种理解。真正要做到稳定可靠可能还需要在业务逻辑层做更多的工作而不是把所有压力都压在模型身上。我目前的一个探索方向是把业务逻辑从提示词里抽出来做成独立的“业务规则引擎”模型只负责“理解意图”和“生成回复”具体的任务执行交给规则引擎。这样模型和业务逻辑解耦系统的稳定性和可维护性都会好很多。这个方向还在验证中等有更多结果了再分享。如果你也在做类似的事情欢迎交流。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
