在我们进行“智能助理”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的“智能”内涵。技术的发展始终在解决人类所提出的问题，但我们不能忽视背后的问题本质：我们真正追求的是什么样的智能？