在我们进行“智能助理”Chat应用项目的过程中，遇到了一个典型的挑战。虽然大家都熟知的文生图、文生视频的AI Bot可以完成非常复杂的工作流，但它们基本都是一次对话解决一个任务的模式。这种任务往往相对独立，比如根据给定的文本生成图片或视频，结果也是即时的。相对来说，这种模式比较简单，因为用户和AI之间的交互并不涉及过多的上下文理解和动态变化。
A.上下文理解的重要性
在多轮对话场景下，上下文的理解能力尤为重要。用户可能会逐步提供信息或修改已有的信息，AI需要在这个过程中保持对每个步骤的清晰认知。例如，在业务办理时，用户可能先提供姓名，然后修改地址，最后再确认手机号。AI不仅要记住每一个信息，还要确保前后信息的一致性。如果AI在这一过程中“迷失”了上下文，可能会导致操作失败，或者更糟糕的是引发信息混乱。
B.状态机的必要性
在实践中我们发现，要解决这一问题，状态机（State Machine）是不可或缺的功能。在多轮对话中，状态机能够帮助AI追踪每个任务的进展，并明确地知道当前所处的阶段。状态机的引入让AI不再只是“无状态”地处理每一轮对话，而是能够通过识别当前状态和过往状态，来合理地预测下一步该做什么。
C.状态机的优势
- 任务分段与管理，状态机可以将任务划分为若干个明确的阶段，帮助AI清晰地知道每个任务的进展。比如，修改地址这个任务可以分为“获取地址信息”、“确认修改”、“完成修改”三个状态。每一个状态都有其特定的任务目标，AI只需专注于当前的状态，并根据状态变化调整行为。
- 上下文保持与追踪，当用户进行多轮对话时，状态机能够帮助AI记录每一个对话的状态转变，确保AI始终保持对话的上下文。如果用户在填写信息的过程中返回去修改某个字段，AI可以根据状态机回到相应的状态并重新开始，而不是从头再来。
- 错误处理与回退机制，在复杂的业务办理过程中，错误处理是不可避免的。如果用户输入了错误的信息或需要更正某些步骤，状态机可以迅速定位错误发生的位置，并引导用户回退到正确的步骤。这避免了因为一个小错误导致整个流程重置的问题。
- 动态调整，状态机的灵活性允许在对话过程中根据用户的需求动态调整。用户可以在不同的状态之间切换，而AI可以通过状态机确保整个对话的逻辑顺畅，不会因为跳跃式的对话内容导致信息丢失或混淆。
D. 状态机与大模型的结合
在实践中，我们尝试了将状态机与大模型结合起来，以应对复杂的业务办理任务。比如，在处理银行账户信息修改时，我们将这个任务分为多个阶段：验证身份、输入新信息、确认修改。在每个阶段，AI不仅根据用户的输入提供反馈，还能够利用状态机确保每个步骤的有序进行。
在大模型的加持下，AI能够更加灵活地理解用户的意图，即使用户的表达不够精准，AI也可以通过上下文推测出正确的操作。状态机则确保整个流程的逻辑性和连贯性，防止AI在复杂对话中“迷失方向”。
E.状态机与工作流设计思路
在设计状态机时，关键在于明确任务的不同阶段，并确保每个阶段都有明确的入口、出口和状态转移条件。我们可以把状态机设计为一种结构化的框架，用于管理业务流程中的各种状态变迁。
状态机的基本设计
1 · 状态 States
每个状态代表任务的某个特定阶段。在业务办理过程中，比如用户修改个人信息，可能包括“身份验证”、“输入新信息”、“确认信息”、“完成修改”四个状态。
2 · 事件 Events
事件是触发状态变化的条件，比如用户的输入、系统的反馈、外部验证等。状态机基于事件进行状态转移。
3 · 转移 Transitions
每个状态与下一个状态之间的关系由转移条件定义。当满足某个事件条件时，状态机会根据转移规则切换到相应的状态。
4 · 结束状态 Final State
当任务完成时，进入结束状态，这意味着任务流的结束。
状态机代码示例
from transitions import Machine
# 定义业务办理流程中的状态
states = ['start', 'validate_identity', 'input_new_info', 'confirm_info', 'finish', 'error']
# 定义状态机
class BusinessWorkflow:
def __init__(self, user):
self.user = user
self.info = None # 用户新输入的信息
self.identity_verified = False # 身份验证状态
# 事件和方法
def validate_identity(self):
# 假设身份验证通过
self.identity_verified = True
print(f"身份验证成功，欢迎{self.user}！")
def input_new_info(self, info):
self.info = info
print(f"收到新信息：{info}")
def confirm_info(self):
print(f"确认信息：{self.info}，信息无误")
def error_handling(self):
print("发生错误，回退到上一步")
# 初始化对象
workflow = BusinessWorkflow("用户A")
# 定义状态机
machine = Machine(model=workflow, states=states, initial='start')
# 定义状态转换
machine.add_transition(trigger='start_process', source='start', dest='validate_identity', before='validate_identity')
machine.add_transition(trigger='input_info', source='validate_identity', dest='input_new_info', before='input_new_info')
machine.add_transition(trigger='confirm', source='input_new_info', dest='confirm_info', before='confirm_info')
machine.add_transition(trigger='finish_process', source='confirm_info', dest='finish')
machine.add_transition(trigger='error', source='*', dest='error', before='error_handling')
# 测试状态机流程
workflow.start_process() # 从start状态到validate_identity状态
workflow.input_info("新地址：123号") # 输入新信息
workflow.confirm() # 确认信息
workflow.finish_process() # 完成流程
- 定义状态：我们在 states 列表中定义了整个业务流程中可能出现的状态，比如开始（start）、身份验证（validate_identity）、输入信息（input_new_info）、确认信息（confirm_info）、完成（finish）和错误处理（error）。
- 事件触发状态转换：通过 trigger 来定义每个状态之间的转换条件，比如当用户通过身份验证后，触发 input_info 事件，进入 input_new_info 状态，接受用户输入的新信息。
- 状态机处理流程：我们定义了每个状态下应该执行的动作，比如验证身份、接受新信息、确认信息等。在错误发生时，还可以通过 error 事件回到适当的状态，进行重新输入或修改。
F. 状态机与工作流设计的结合
在真实的项目中，状态机会根据业务流程的复杂程度进一步扩展，包含更多的状态、转移条件和事件。在设计过程中，需确保每个状态都有明确的触发条件和处理逻辑。通过这样的状态机设计，可以将AI与用户之间的多轮对话任务结构化，让AI始终知道当前任务的进展，避免出现上下文混淆的问题。
哈，还真是，这么看来，这与OS APP后端开发别无二致。
G. 动态验证和调整
随着对话的进行，状态机还可以动态调整。例如，用户在输入信息时突然决定修改之前的内容，状态机可以根据用户的需求返回到相应的状态重新开始，而不影响整个任务流。
这种动态验证和调整机制对复杂业务场景尤为重要，特别是在涉及身份验证、信息修改或多轮确认的流程中，AI能够准确地理解用户的需求并做出相应的调整。
H. 目前较为可靠的方案
基于成本、效率和可靠性三大因素的平衡，可以结合任务导向系统、状态机、Transformer模型和知识图谱，创建一个既能控制开发成本，又能在复杂业务场景中高效、可靠运行的智能系统。
任务导向对话系统 + 状态机（低成本、可靠性高）
- 用于处理标准化的业务流程，管理业务步骤。
- 用于身份验证、信息更新等具有明确结构的业务。
基于Transformer的对话模型（如GPT-4o、kimi 64、豆包64）
- 用于处理复杂、多轮对话和灵活的用户需求。
- 提升自然语言处理能力，减少人工干预，适合用于客户服务中的开放式对话。
知识图谱 + 任务导向系统（高可靠性）
- 用于补充业务中的领域知识推理，确保复杂业务中的合规性和精确性。
- 适合用于涉及专业领域的复杂业务场景，尤其是需要高可靠性和精确判断的场景。
I. 状态机与工作流设计的挑战
- 状态设计复杂性：如果业务流程过于复杂，状态设计和管理可能会变得非常复杂。如何合理划分状态、设计转移条件，并确保状态机的灵活性，是一个值得深思的问题。
- 状态的回退和跳跃：用户的需求变化较快，可能会跳过某些步骤或返回修改。这就需要状态机设计中考虑回退机制和跳转逻辑，确保整个流程的灵活性和容错能力。
- 与大模型的配合：虽然状态机能很好地管理多轮对话中的流程，但与大模型的结合需要确保模型能够准确理解用户意图，并基于当前状态做出合适的响应。因此，状态机的设计需要与大模型的上下文理解能力紧密配合，避免出现信息错位或流程中断。
写在最后
以上是关于我们在开展国内toC工具类产品处理信息管理和业务服务的思路，这也是基于场景、成本、风险等一系列因素来考量设计。另外，大语言模型的性能也至关重要，对话的理解力、分段、意图的识别都会影响Agent的执行。
状态机代表了一种“工具理性”，它依赖于固定的逻辑和流程来解决问题，忽视了人类智慧中的不可预测性与创造性。业务扩展能力弱，而真正的智能，应该能够自主地理解上下文，适应变化，并通过学习与推理来解决问题。这也是为什么状态机在应对复杂多变的业务场景时，虽然保证了服务的可靠性，但仍然没有完全实现智能化的根本原因。
哲学家海德格尔曾提出，“工具的本质不在于其功能，而在于它被使用时的背景与意图”。状态机是在当前技术背景下的过度产物，它无法解决“智能”的终极问题。随着深度学习与自然语言处理技术的进步，大模型在自主理解上下文、推理复杂关系上的能力逐步提升，智能助理不再仅仅是依赖预定义逻辑和流程的“任务执行器”。
而是要具备自我学习、灵活适应和创造性的能力。我们不仅需要从技术上不断优化模型的性能，更要从哲学的角度重新思考AI的“智能”内涵。技术的发展始终在解决人类所提出的问题，但我们不能忽视背后的问题本质：我们真正追求的是什么样的智能？
7 Comments
delta 9 gummies
Good shout.
florida dispensary
Nice
巴厘島爪哇
我高度评价, 这里分享真实经验。你的博客 就是 关于这些的。请继续。
艺术与海洋
我热爱, 充满真情实感。你的网站 就是 关于这些的。请继续。
風車景觀
我早就想, 参观你们描述的目的地。谢谢启发。
Josephseirm
我总是关注 出行博客。鼓舞人心找到这样的文章。 这个页面 就是 最好的例子。很出色。
Lawrence
我高度评价, 充满真情实感。这个页面 就是 关于这些的。加油。
Feel free to visit my blog post: 水戶名勝