第6篇Skill的状态管理与上下文控制适用人群进阶 | 字数约25,000字 | 预计阅读时间60分钟前言在前五篇中我们创作的 Skill 大部分是单轮的——用户输入一次Skill 输出一次任务结束。这适用于很多场景翻译、摘要、格式转换等。但有很多任务需要多轮交互——用户和 AI 之间来回对话逐步确认需求、逐步细化内容。比如客服咨询用户说我要退货→ AI 问订单号 → 用户提供 → AI 问原因 → ……需求收集用户说帮我设计一个功能→ AI 逐步询问细节学习辅导用户说帮我讲解这个概念→ AI 逐步深入根据反馈调整这些场景中AI 必须记住前面说过的话——否则就会出现我刚才说了什么你又问我一遍的糟糕体验。这就是状态管理要解决的问题。如果说提示词决定了 Skill “能不能做好”工具决定了 Skill “能做多大”那么状态管理决定了 Skill “能做多复杂”。第一章什么是状态1.1 一个直观的例子想象你正在用客服咨询 Skill 处理一个退货请求用户我要退货 AI好的请问您的订单号是什么 用户ORD-2026-0520 AI订单 ORD-2026-0520 已查到。请问退货原因是什么 用户产品尺寸不合适 AI好的已为您提交退货申请。预计退款将在 3-5 个工作日内到账。 → 如果没有状态管理对话会变成这样 用户我要退货 AI好的请问您的订单号是什么 用户ORD-2026-0520 AI好的请问您需要什么帮助 ← 它忘了刚才说要退货 用户我要退货啊刚才说了 AI请提供您的订单号 用户ORD-2026-0520 刚才给了 AI您的订单是 ORD-2026-0520请问需要什么帮助 ……状态管理要解决的就是这个问题——让 AI 记住对话进行到哪一步了以及已经知道了什么信息。1.2 状态的三个维度在 Skill 系统中状态State是 AI 在对话过程中需要记住的所有信息。它可以分为三个维度维度一对话进度 → 对话进行到哪一步了 → 下一步需要什么 → 示例{current_step: collecting_reason, completed_steps: [identified_order]} 维度二收集的信息 → 用户已经提供了什么信息 → 示例{order_id: ORD-2026-0520, customer_name: 张三} 维度三上下文约束 → 本次对话的特殊条件和偏好 → 示例{language: 中文, urgent: true, channel: web}1.3 有状态 vs 无状态维度无状态 Skill有状态 Skill每次调用独立不记得之前的事依赖之前的对话历史多轮对话支持有限容易失忆自然流畅不重复询问复杂度低单次输入→单次输出中高需要维护状态实现难度简单中等适用场景翻译、摘要、格式转换客服、需求收集、辅导第二章状态的类型2.1 按存储方式分类类型一对话上下文中的隐式状态这是最简单的方式——AI 通过看到完整的对话历史来知道当前状态。工作原理 每一轮对话系统都把完整的对话历史包括用户输入和 AI 回复传给 AI。 AI 通过阅读历史来了解我们已经说了什么和现在该做什么。 优点 - 实现简单不需要额外编码 - AI 能理解复杂的对话上下文 缺点 - Token 消耗大——对话越长历史越庞大 - 注意力稀释——早期对话内容在长对话中容易被遗忘 适用场景 - 短对话3-5 轮以内 - 不需要精确状态追踪的场景类型二显式状态变量把关键信息提取到明确的变量中而不是隐藏在对话历史中。工作原理 系统维护一个状态变量对象在每轮对话后更新。 AI 在每轮对话开始时读取状态变量了解当前进度。 状态变量示例 { current_step: asking_refund_reason, collected_info: { has_order_id: true, order_id: ORD-2026-0520, has_customer_name: false }, remaining_tasks: [ask_reason, confirm_refund, notify_customer] } 优点 - 精确——直接从变量读取不会漏掉 - 节省 Token——不需要把完整历史传进去 - 可控制——可以在应用层做状态校验 缺点 - 实现更复杂——需要定义状态结构 - 灵活性受限——变量结构是预设的 适用场景 - 长对话10 轮以上 - 需要精确状态追踪的场景 - 生产系统类型三外部持久化状态状态信息存储到外部系统数据库、文件等可以跨会话保持。工作原理 每轮对话结束后将状态保存到数据库。 下一轮对话开始时从数据库加载状态。 优点 - 跨会话可用——用户离开后回来对话可以继续 - 数据安全——不依赖对话历史状态持久化存储 缺点 - 实现最复杂——需要数据库和其他基础设施 - 延迟增加——每次读写都有 IO 开销 适用场景 - 需要长期跟进的任务 - 多个会话之间需要共享状态 - 需要查看历史记录的场景2.2 按生命周期分类会话级状态只在当前对话会话中有效。用户关闭对话框后状态消失。例子客服咨询 Skill 的状态 - 当前步骤正在收集退货原因 - 已收集的信息订单号、客户姓名 - 适用于一次性咨询用户级状态对同一个用户跨会话保持。用户今天退出明天回来状态还在。例子学习助手 Skill 的状态 - 用户学习进度已学完第三章 - 上次讨论到注意力机制的实现 - 适用于长期学习、跟进全局状态对所有用户都生效不受会话和用户影响。例子系统配置 Skill 的状态 - 当前模型版本GPT-4o - 默认语言中文 - 适用于系统级配置第三章状态管理在 Skill 中的实现3.1 在指令系统中定义状态管理在 Skill 的指令系统中需要明确定义如何管理状态。【状态管理规则】 你是一个多轮交互的客服助手。每次对话中需要记住以下信息 1. 对话进度用 current_step 表示 - greeting初始问候 - collecting_order收集订单号 - identifying_issue识别问题类型 - providing_solution提供解决方案 - confirming确认用户是否满意 - closing结束对话 2. 已收集的信息用 collected_info 对象表示 - order_id订单号如果已获取 - customer_name客户姓名如果已获取 - issue_type问题类型如果已识别 - preferred_solution用户偏好的解决方案如果已表达 3. 状态更新规则 - 每当用户提供新的信息立即更新 collected_info - 每当完成一个步骤将 current_step 推进到下一步 - 如果用户回到之前的步骤更新 current_step 回退 - 在回答开始时先回顾当前状态再基于状态构建回答3.2 在多轮对话中使用状态模板对于结构化程度高的多轮对话可以使用状态模板——在每轮输出中嵌入当前状态便于 AI 和系统追踪。【输出模板每轮通用】 回答内容针对用户本轮问题的回答 ---系统状态--- current_step: {当前步骤} collected_info: {已收集信息} next_needed: {下一步需要收集的信息} ---系统状态部分对用户不可见或者以极简方式呈现但对 AI 自身来说是提醒——知道自己当前在哪里、下一步要做什么。3.3 状态转移的引导在多轮对话中AI 需要主动引导用户进入下一状态用户我要退货 AI状态转移greeting → collecting_order 好的我来帮您处理退货。请问您的订单号是什么 用户ORD-2026-0520 AI状态转移collecting_order → identifying_issue 已查到您的订单 ORD-2026-0520。请问退货的原因是什么比如尺寸不合适、质量问题、或者不想要了 用户尺寸不合适 AI状态转移identifying_issue → providing_solution 了解了尺寸不合适我们可以提供换货或退货退款两种方案您更倾向于哪一种状态转移的关键用户提供信息后AI 自动推进状态每个状态AI 都明确告诉用户现在需要什么用户的回答决定了下一步状态3.4 状态回退处理在多轮对话中用户可能会回到上一步——这时候需要状态回退。用户算了我不退货了我想换货 AI状态回退providing_solution → identifying_issue 好的换货也可以。请问您想换什么商品还是同一款换不同尺寸还是换其他商品 用户还是回到开始吧我不换了 AI状态回退到初始 好的没问题。如果之后还有需要随时可以找我。请问还有其他可以帮您的吗状态回退的规则【状态回退规则】 1. 如果用户表达了改变主意的意图状态可以回退 2. 回退时已经收集的信息保留用户不需要重新提供 3. 每次回退后确认用户的新意图 4. 不要强行推进到用户不在的状态第四章上下文管理的深度技巧4.1 什么是上下文管理上下文管理Context Management和状态管理State Management是两个相关但不相同的概念状态管理记住对话进行到哪一步了和已经知道了什么 关注进度和信息 上下文管理维持对话的一致性——不重复、不矛盾、不遗忘 关注连贯性和一致性一个例子帮你区分状态当前步骤是 collecting_reason已收集 order_id ORD-123 → 状态管理确保 AI 知道现在该问退货原因了 上下文用户在前一轮提到我买的是红色款 → 上下文管理确保 AI 在后一轮不会说您买的什么颜色4.2 上下文一致性的维护问题1重复询问AI 已经问过了用户已经回答了但 AI 又问了同样的问题。用户我的订单号是 ORD-123 AI感谢您提供订单号。请问您的订单号是什么 ← 重复询问解决方案在指令中加入上下文记忆规则【上下文记忆规则】 1. 在生成回答前先回顾对话历史中已经出现的信息 2. 如果某项信息已经被用户提供过不再重复询问 3. 如果用户刚刚回答了你上一个问题在下一个回答中先确认收到再推进 4. 不要假装忘记——不要为了确认而重复问已提供的信息问题2前后矛盾AI 在后面说了一个和前面矛盾的信息。AI前一轮您的退款申请已经提交成功预计3-5天到账 AI后一轮请问您希望怎么处理退款 ← 前面已经提交了解决方案在处理流程中加入一致性检查步骤【一致性检查】 在每次输出前检查 1. 我本轮要输出的内容是否与之前已经说过的内容矛盾 2. 我本轮要询问的信息是否用户已经提供过了 3. 我本轮要推进的步骤是否已经完成了 如果检查发现问题先修正自己的认知再继续对话。4.3 长对话的上下文压缩当对话变得很长10轮以上完整的历史对话会占用大量 Token。这时候需要上下文压缩。压缩策略一摘要式压缩用摘要代替完整的对话历史原始对话历史10轮约3000 Token → 用户我要退货 → AI请提供订单号 → 用户ORD-123 → AI请问退货原因 → 用户尺寸不合适 → …… 压缩后的摘要100 Token 用户要求退货订单ORD-123原因为尺寸不合适已提供换货方案 用户正在考虑。当前步骤等待用户确认换货方案。指令中对压缩的处理【长对话处理规则】 当对话超过 8 轮时 1. 对早期对话前 5 轮做摘要压缩 2. 保留最近 3 轮的完整对话 3. 在回答开始时先确认压缩后的摘要是否正确 4. 如果用户提到早期对话中的内容先解压摘要再回复压缩策略二关键信息提取只保留对话中最核心的信息去掉过程性内容完整对话精简前的状态 { full_history: ……完整的对话历史…… } 压缩后的状态 { order_id: ORD-123, issue: 尺寸不合适已提供换货方案, customer_status: 正在考虑中, current_step: waiting_for_confirmation, escalation_needed: false }4.4 跨会话上下文某些场景下用户可能在多个会话中与同一个 Skill 交互。这时需要跨会话上下文。场景用户使用学习助手 Skill 第1天会话 用户帮我讲解一下机器学习的基本概念 AI讲解了基本概念 → 状态保存{topic: ml_basics, progress: basic_concepts_covered} 第2天会话 用户继续昨天的内容 → 加载状态看到昨天讲了基本概念 → AI好的昨天我们讲了机器学习的基本概念。今天我们进入下一部分监督学习。 第3天会话 用户我复习一下昨天讲的监督学习 → 加载状态看到昨天讲过监督学习 → AI好的监督学习的核心是……请问有什么具体问题吗跨会话上下文的实现【跨会话状态管理】 本 Skill 支持跨会话状态保存。 每次对话结束时状态会被保存。 下次对话开始时会自动加载上次的状态。 状态保存规则 1. 对话结束时自动保存当前进度和关键信息 2. 保存的信息包括当前主题、覆盖到哪一步、用户提到的重要问题 3. 不保存用户的个人隐私信息 4. 状态保存期限30 天 状态加载规则 1. 新对话开始时检查是否有未过期的历史状态 2. 如果有在首轮回复中自动引用历史状态 3. 如果用户说不记得了或重新开始重置状态第五章状态管理的反模式反模式1过度依赖对话历史表现不在指令中定义任何状态管理规则完全依赖 AI 从对话历史中自己理解当前状态。后果对话一长AI 就失忆——重复询问、前后矛盾。解决方案至少使用隐式状态管理——在指令中告诉 AI 去维护关键信息的列表。反模式2状态变量过于复杂表现定义了一个包含 20 字段的状态对象大部分字段在大多数场景中都用不上。后果AI 维护状态的负担重反而影响了核心任务的执行。解决方案状态变量只包含当前流程不可或缺的关键信息。冗余信息通过对话历史维护。反模式3忽略状态回退表现状态只能前进不能后退。用户说回到上一步AI 不知道怎么办。后果用户被迫完成当前流程体验极差。解决方案在状态管理规则中增加回退逻辑。反模式4跨会话状态冲突表现用户在不同设备/不同渠道上使用同一个 Skill状态冲突——在手机上说了一个事在电脑上 AI 不知道。后果信息不一致用户困惑。解决方案每个会话使用唯一的 session_id跨会话状态的加载需要用户确认。第六章实战——设计一个有状态的 Skill6.1 案例客服咨询 Skill我们设计一个客服咨询 Skill——这是最典型的多轮对话场景。功能定义用户提出售后问题Skill 逐步收集信息订单号、问题类型、用户需求Skill 提供解决方案Skill 确认用户是否满意状态设计{session_id:SES-20260520-001,current_step:greeting,steps_order:[greeting,collecting_order,identifying_issue,providing_solution,confirming,closing],collected_info:{order_id:null,customer_name:null,product_name:null,issue_category:null,issue_detail:null,preferred_solution:null},conversation_summary:用户需要退货帮助,escalation_needed:false,satisfaction_confirmed:false}指令系统中的状态管理规则【状态管理规则】 你的对话流程分为以下几个步骤按顺序推进 1. greeting问候→ 2. collecting_order收集订单号 3. identifying_issue识别问题→ 4. providing_solution提供方案 5. confirming确认→ 6. closing结束 状态推进规则 - 每当用户提供了当前步骤所需的信息自动推进到下一步 - 如果用户主动要求回到上一步状态回退 - 如果用户提出新的需求如从退货变成换货更新 issue_category 和 preferred_solution 已收集的信息不重复询问 - 每次回复前检查 collected_info 中的字段 - 如果某个字段已经有值不再问用户 - 如果用户主动修改了已提供的信息更新对应的字段 对话结束规则 - 当用户确认满意时状态标记为 closing - 当用户明确表示没有其他问题时结束对话 - 结束对话时生成对话总结6.2 案例需求收集 Skill另一个典型的多轮对话场景——逐步收集用户的需求。功能定义用户提出一个想要的功能Skill 通过多轮对话逐步明确需求细节最终输出一份结构化的需求文档状态设计{session_id:REQ-20260520-001,current_section:basic_info,sections_order:[basic_info,target_users,core_features,success_criteria,constraints,summary],collected:{basic_info:{feature_name:null,one_line_desc:null,business_value:null},target_users:{primary_users:null,usage_scenario:null,expected_frequency:null},core_features:{must_have:[],nice_to_have:[],not_in_scope:[]},success_criteria:{metrics:[],target_values:{}},constraints:{technical:[],business:[],timeline:null}}}指令中的需求收集流程【需求收集流程】 这是一个多轮需求收集 Skill。每次只问 1-2 个问题逐步收集信息。 每个章节的对话流程 1. 先介绍当前章节要讨论的内容 2. 提出 1-2 个引导性问题 3. 用户回答后提取信息填入状态 4. 确认理解是否正确 5. 进入下一个章节 如果用户提供了超出当前章节的信息 - 先记录到对应章节 - 不需要在当前章节深入讨论 - 到了对应章节再详细展开 如果用户对某个问题不确定 - 提供一些常见选项供参考 - 允许用户暂时跳过后续再补充 - 最终需求文档中标注待确认项 对话结束后 - 生成结构化的需求文档 - 包含所有已收集的信息 - 标注待确认项 - 提供下一的建议第七章状态管理的工具7.1 状态可视化对于复杂的状态管理可以通过状态可视化来追踪当前状态需求收集 Skill ┌─────────────────────────────────────────────┐ │ 需求收集进度 │ ├─────────────────────────────────────────────┤ │ ✅ 基本信息 → 已收集产品名称、一句话描述│ │ ✅ 目标用户 → 已收集主要用户、使用场景 │ │ ⏳ 核心功能 → 收集中必需要有2/3 │ │ ⬜ 成功标准 → 未开始 │ │ ⬜ 约束条件 → 未开始 │ │ ⬜ 总结 → 未开始 │ ├─────────────────────────────────────────────┤ │ 当前步骤询问第3个必需功能 │ │ 已完成40% │ └─────────────────────────────────────────────┘7.2 状态持久化存储对于需要跨会话保持状态的场景使用外部存储状态持久化存储接口 // 保存状态 save_state(session_id, state_object) → 将状态保存到数据库 → 自动关联到用户ID和会话ID // 加载状态 load_state(session_id) → 从数据库加载状态 → 如果会话不存在返回空状态 // 更新状态 update_state(session_id, field_path, value) → 只更新指定的字段 → 不覆盖其他字段 // 状态过期 expire_state(session_id) → 将状态标记为过期 → 过期的状态在加载时返回空7.3 状态测试状态管理是 Skill 中容易出问题的部分需要专门的测试状态测试清单 □ 状态推进测试 输入用户提供订单号 预期状态从 collecting_order 推进到 identifying_issue 测试结果通过/不通过 □ 状态回退测试 输入用户说回到上一步 预期状态回退到上一个步骤 测试结果通过/不通过 □ 信息保持测试 输入用户提供订单号后切换到另一个话题再回来 预期订单号没有被遗忘 测试结果通过/不通过 □ 跨会话测试 输入用户结束会话后重新开始 预期状态正确加载或按预期重置 测试结果通过/不通过 □ 长对话测试 输入连续 15 轮对话 预期状态保持正确没有出现重复询问或矛盾 测试结果通过/不通过第八章高级状态管理模式8.1 有限状态机FSM模式有限状态机是状态管理中最经典的模式。它的核心思想是系统在任何一个时刻都处于一个确定的状态中只有某些事件会触发状态转移。FSM 表示例客服 Skill 当前状态 → 触发事件 → 下一状态 ────────────────────────────────────────────── greeting 用户说要退货 collecting_order collecting_order 用户提供订单号 identifying_issue identifying_issue 用户说原因 providing_solution providing_solution 用户选择方案 confirming confirming 用户说满意 closing在指令中定义 FSM【对话流程——有限状态机模式】 本 Skill 的对话流程由以下状态组成。在任意时刻你只处于其中一个状态。 状态列表 S1: greeting初始状态 → 触发条件对话开始 → 行为问候用户询问需要什么帮助 S2: collecting_order → 触发条件用户表达了售后需求退货/换货/维修 → 行为询问订单号 → 转移到 S3 的条件用户提供了有效的订单号 S3: identifying_issue → 触发条件获得了订单号 → 行为询问具体问题 → 转移到 S4 的条件识别了问题类型 S4: providing_solution → 触发条件明确了问题 → 行为提供解决方案询问用户选择 → 转移到 S5 的条件用户选择了方案 S5: confirming → 触发条件方案已执行 → 行为确认用户是否满意 → 转移到 S6 的条件用户确认满意 S6: closing终止状态 → 行为结束对话提供后续联系方式 特殊转移规则 1. 在任何状态如果用户说算了、不做了 → 转移到 S6closing 2. 在任何状态如果用户说回到上一步 → 转移到上一个状态 3. 如果用户同时触发了多个转移条件选择优先级最高的那个FSM 模式的优点状态转移清晰AI 不容易迷路每个状态的行为明确定义输出质量稳定便于测试——每个状态和转移都可以单独测试FSM 模式的局限状态必须是预设的灵活性有限如果状态太多超过 10 个管理复杂度上升8.2 槽位填充Slot Filling模式槽位填充是另一种常见模式。它的核心思想是任务的完成需要收集一组槽位信息字段每轮对话填充一个或多个槽位所有槽位填满后任务完成。槽位定义退货场景 必填槽位 [order_id] 订单号 —— 未填 [reason] 退货原因 —— 未填 [solution] 用户选择的方案 —— 未填 选填槽位 [notes] 备注说明 —— 未填 所有必填槽位填满后 → 执行退货流程在指令中定义槽位填充【信息收集——槽位填充模式】 你需要收集以下信息才能完成退货处理 必填信息必须全部收集 1. 订单号order_id - 如何询问请问您的订单号是什么 - 验证必须是有效的订单格式 2. 退货原因reason - 如何询问请问退货的原因是什么 - 选项尺寸不合适 / 质量问题 / 不想要了 / 其他 3. 处理方案solution - 如何询问您希望怎么处理换货还是退款 - 选项换货 / 退款 选填信息 4. 备注notes - 如何询问还有其他需要备注的吗 - 如果用户说没有跳过 收集规则 1. 每轮对话只问 1 个必填信息 2. 先问必填再问选填 3. 如果用户在回答 A 时同时提供了 B 的信息同时填充 A 和 B 4. 所有必填信息收集完成后执行处理流程 5. 如果用户不确定某个信息提供默认选项或允许跳过槽位填充模式的优点聚焦于信息收集适合表单类场景自然支持用户一次提供多条信息的情况槽位之间的依赖关系清晰槽位填充模式的局限不擅长处理非信息收集类的多轮对话对槽位的顺序要求较高8.3 混合模式在实际应用中大多数 Skill 采用FSM 槽位填充的混合模式。混合模式示例 FSM 层控制对话的宏观流程 greeting → handling_issue → resolving → closing 在 handling_issue 状态中使用槽位填充模式 收集 order_id → 收集 reason → 收集 solution 在 resolving 状态中使用 FSM 模式 providing_solution → confirming → closing混合模式结合了两者的优点FSM 控制宏观流程槽位填充管理信息收集。8.4 状态模式的设计原则无论使用哪种模式以下设计原则都是通用的原则一最小状态原则 状态数量保持在能完成任务的最小值。不必要的状态增加复杂度。 好的5-7 个状态 需要警惕15 个状态 原则二可回溯原则 用户应该能回到之前的状态。单向推进的对话体验很差。 至少支持回退一步 原则三可中断原则 用户应该能随时切换话题之后再回来。 不需要必须按顺序完成当前流程 原则四状态透明原则 用户不一定需要看到完整的状态结构但 AI 应该能让用户知道目前到哪了。 例如我先帮您查一下订单信息然后了解具体问题最后给您处理方案。第九章状态管理的常见问题与解决方案9.1 AI “失忆”——忘记了之前的信息表现用户之前提供的信息AI 在后面又追问了一遍。原因状态管理规则没有生效AI 依赖对话历史来回忆但历史太长被截断或注意力稀释。解决方案【防止失忆规则】 1. 每次回复前先 review 当前状态中已收集的信息 2. 如果某项信息已有值绝不再次询问 3. 如需确认已收集的信息用确认而不是询问 ✅ 您说的订单号是 ORD-123 对吗 ❌ 请提供您的订单号9.2 状态漂移——对话逐渐偏离主线表现对话从 A 话题逐渐漂移到 B 话题、C 话题最终完全偏离了原来的任务。原因缺乏回到主线的机制。解决方案【对话主线维护规则】 1. 如果用户提出与当前任务无关的话题 - 先简单回应 - 然后引导回主线这个话题很有意思我们之后可以聊。现在我们先把退货处理完。 2. 如果用户连续 3 轮都在聊无关话题 - 主动提醒当前任务我们还剩下一步——确认处理方案您看…… 3. 如果用户明确表示先不谈这个了 - 保存当前状态 - 结束当前任务9.3 状态冲突——多设备/多渠道的状态不一致表现用户在手机上说我要退货在电脑上继续时 AI 不知道。原因没有做跨会话状态同步。解决方案在跨会话状态加载时增加用户确认步骤【跨会话状态加载规则】 当检测到历史状态时 1. 在回复开头提示用户我注意到您之前提到要处理订单 ORD-123 的退货是否继续 2. 如果用户确认加载状态继续 3. 如果用户说不或重新开始重置状态9.4 状态膨胀——状态对象越来越大表现对话越长状态对象越庞大最终包含了大量冗余信息。原因没有做状态清理。解决方案在关键节点如状态转移清理冗余信息【状态清理规则】 在每次状态转移时 1. 清理已经用完的信息如已处理的步骤信息 2. 保留后续还需要的信息 3. 对长对话10轮以上对早期状态做摘要压缩 4. 状态对象保持在 20 个字段以内第十章从状态管理到对话设计10.1 状态管理只是手段好对话才是目的掌握状态管理的技术很重要但更重要的是理解它的目的——创造自然、流畅、不让人烦躁的多轮对话。好的多轮对话体验应该是这样的用户我要退货 AI好的我来帮您处理。请问订单号是 用户ORD-123 AI查到您的订单了商品运动鞋白色。请问退货原因是 用户买小了 AI了解了。这款鞋我们支持换货换大一码就可以吗还是直接退款 用户换货吧 AI好的已经为您提交换货申请。新鞋预计 3 天发出。还有其他需要吗 用户没有了谢谢 AI不客气如果还有其他问题随时找我。这个对话之所以流畅是因为状态推进自然——每一步都是上一步的自然延伸信息不重复——没有问刚才已经提供的信息有上下文引用——“查到您的订单了商品运动鞋白色”让用户感觉 AI 真的知道对话可退出——用户随时可以说没有了10.2 状态管理 工具调用 提示词 完整 Skill回顾一下 Skill 的完整能力框架提示词设计第4篇 让 AI 知道怎么工作 保证输出质量 工具集成第5篇 让 AI 有手脚 突破信息边界和操作边界 状态管理第6篇 让 AI 有记忆 支持多轮复杂对话这三个能力组合起来就是一个完整的 Skill——能思考、能行动、能记住。写在最后状态管理是 Skill 从单轮工具进化到多轮助手的关键能力。回顾核心要点状态的三维度对话进度、收集的信息、上下文约束状态的三存储方式对话上下文隐式、显式变量精确、外部持久化跨会话上下文管理 vs 状态管理状态管理关注进度和信息上下文管理关注一致性和连贯性长对话需要压缩摘要压缩、关键信息提取跨会话需要持久化保存→加载→更新的循环两种经典模式FSM有限状态机控制流程、槽位填充收集信息常见问题可预防失忆、漂移、冲突、膨胀——每类问题都有对应的解决策略当你的 Skill 有了良好的状态管理用户会感觉AI 真的懂我在说什么——而不是每句话都要重新解释一遍。课后练习状态设计练习为你之前创作的会议纪要整理 Skill 设计一个多轮模式的状态——如果用户在第一轮输出后要求修改你怎么设计状态变量来追踪哪些部分需要修改状态回退练习设计一个需求收集 Skill 的状态回退逻辑——当用户说等等我之前说的那个需求我要改一下状态怎么处理跨会话练习设计一个学习助手 Skill 的跨会话状态结构——需要记住用户学到哪了、“上次问了什么问题”、“用户水平如何”。下一篇预告《第7篇Skill的错误处理与边界设计——让Skill更健壮》一个健壮的 Skill 不仅要能在正常情况下工作还要能在异常情况下不崩溃。下一篇我们讲解错误处理、异常降级和边界设计。没有状态的 Skill像一个没有记忆的人。有了状态的 Skill像一个可靠的伙伴。