企业官网建设流程全解析

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 做到“能办事”这个层面，已经能解决很多实际问题了。但我在实际项目里越来越感觉到，第五阶段可能只是一个过渡形态。

因为“办事”这件事，本质上要求系统对业务逻辑有很深的理解。而现在的做法，更多是靠提示词和工具调用来“模拟”这种理解。真正要做到稳定可靠，可能还需要在业务逻辑层做更多的工作，而不是把所有压力都压在模型身上。

我目前的一个探索方向是：把业务逻辑从提示词里抽出来，做成独立的“业务规则引擎”，模型只负责“理解意图”和“生成回复”，具体的任务执行交给规则引擎。这样模型和业务逻辑解耦，系统的稳定性和可维护性都会好很多。

这个方向还在验证中，等有更多结果了再分享。如果你也在做类似的事情，欢迎交流。