Agent 设计中为什么要区分自然语言对话状态和结构化执行状态，分别存什么？｜美团算法面经解析

60 秒回答模板

我会把 Agent 状态分成两层。自然语言对话状态保存用户说过什么、系统问过什么、用户偏好、上下文摘要、未消歧的意图和需要给模型看的语义线索，主要服务于理解和生成。结构化执行状态保存任务 id、意图标签、slots、计划步骤、当前节点、工具调用记录、参数、工具结果引用、错误码、重试次数、权限确认、锁、版本号和最终产物，主要服务于执行器、回放和审计。二者不能混用：聊天记录不适合作为唯一事实源，因为它会被截断、压缩和模型误读；结构化状态也不该直接塞满模型上下文，因为里面有很多执行细节、敏感字段和低层状态。好的设计是：模型读取对话摘要和必要执行摘要，输出意图、补参或下一步动作；执行器用结构化状态驱动工具和状态机；每次工具结果再以可控摘要回写给模型。验证上要看多轮补参、异常恢复、工具重试、会话恢复、状态回放和隐私权限是否都能稳定工作。

考点 对话状态不是事实数据库

难度 真实面经题

回答目标让候选人说明 Agent 状态管理的核心边界：自然语言对话状态负责语义理解和交互连续性，结构化执行状态负责工作流推进、工具执行、恢复和审计，两者通过受控摘要和来源标记同步。

深入解析

对话状态服务理解

自然语言对话状态关注用户语义，包括原始用户消息、上下文摘要、用户偏好、指代关系、未解决问题、澄清历史和回答风格。它的作用是帮助模型理解当前用户到底想做什么，以及如何自然地继续对话。

执行状态服务动作

结构化执行状态关注任务推进，包括 normalized intent、slots、计划、当前节点、工具参数、工具结果引用、错误状态、重试次数、权限确认、版本号和产物 id。它的作用是让系统知道下一步该执行什么，以及失败后如何恢复。

为什么不能只用聊天记录

聊天记录是非结构化、冗长且容易被截断的。模型可能从旧话里误读事实，也无法可靠表达锁、版本、幂等键、工具状态和权限确认。把聊天记录当数据库，会让 Agent 在长会话、多工具和异常恢复时变得不可控。

为什么不能只用结构化状态

结构化状态适合机器执行，但不一定包含用户表达中的语气、偏好、上下文暗示和未明确说出的约束。如果只保留 slots 和节点状态，Agent 容易变成僵硬表单，无法处理指代、省略、多轮纠错和自然语言澄清。

两层状态如何同步

用户输入先更新对话状态，再由理解模块抽取意图和 slots 写入执行状态。工具执行后，原始结果作为 artifact 或结构化记录进入执行状态，再生成面向模型和用户的摘要进入对话状态。同步要有来源标记，区分用户事实、模型推断和工具事实。

恢复和审计依赖结构化状态

Agent 崩溃、超时或切换节点时，应从结构化状态恢复，而不是让模型重新读完整聊天记录猜进度。结构化状态可以记录每一步的输入、输出、状态版本和错误码，方便回放、审计、问题定位和幂等重试。

上下文注入要最小化

模型不需要看到全部执行状态。注入上下文时应只给当前决策所需的对话摘要、关键 slots、当前计划、可用工具和必要结果摘要。敏感字段、锁、内部错误栈和大工具结果应留在执行层，避免泄露和 token 膨胀。

验证覆盖多轮和异常

状态设计是否合理，要用多轮补参、用户改口、工具空返回、超时重试、会话恢复、并发请求和权限撤销来验证。指标包括状态迁移正确率、slot 保持率、错误恢复率、重复调用率、恢复后成功率和最终答案可追溯性。

易错点

把完整聊天记录当作 Agent 的唯一状态源，忽略执行进度、工具结果和错误恢复。
把所有结构化状态都塞进模型上下文，造成 token 膨胀、敏感信息泄露和决策干扰。
不区分用户事实、工具事实和模型推断，导致 Agent 用猜测字段执行高风险动作。
状态字段没有版本和默认值，新增字段后历史会话无法恢复。
工具结果只保存在自然语言摘要里，后续无法追溯原始返回和参数。
用户改口后没有失效旧 slots 和旧计划，导致 Agent 继续执行过期目标。
只测试最终回答，不测试 state diff、节点路径和异常恢复。
把对话状态和执行状态混成一个大 JSON，既难给模型读，也难给执行器可靠使用。

面试官追问

对话摘要应该保存什么粒度？

保存对当前任务有用的语义信息，例如用户目标、偏好、约束、澄清结论和未解决问题。不要把所有历史原文都常驻塞给模型。原文可以归档，运行时用摘要和必要片段，避免上下文过长和旧信息干扰。

结构化执行状态是否要暴露给 LLM？

只暴露当前决策需要的子集。例如当前 intent、已填 slots、下一步候选动作和关键工具结果摘要可以给模型；内部锁、完整错误栈、敏感 token、大 payload 和无关历史状态不应该直接进入模型上下文。

用户中途改口时两层状态怎么处理？

对话状态记录改口语义和澄清历史，执行状态要按规则撤销或失效相关 slots、计划和待执行工具。关键是标记哪些字段被用户覆盖，哪些工具结果已经过期，避免沿用旧状态继续执行。

工具返回结果应该存在对话状态还是执行状态？

原始工具结果和结构化字段应存在执行状态或 artifact 存储里，并带调用 id、schema 版本和时间。对话状态只保留面向模型继续推理的摘要或引用，防止长结果污染上下文。

如何避免模型把推断写成事实？

执行状态字段要有来源和置信度，区分 user_provided、tool_observed、model_inferred 和 system_default。高风险动作只能使用用户确认或工具观测的字段，模型推断字段需要追问或校验。

状态管理的验收指标有哪些？

可以看多轮 slot 保持率、状态迁移合法率、恢复后成功率、重复工具调用率、过期状态使用率、人工接管率和 trace 可追溯率。对长任务还要看崩溃恢复和超时重试后的最终一致性。