状态机

RAG 项目做到后面，往往不是「检索一次然后生成」这么简单——要先判断问题类型，事实类走向量检索，计算类走代码工具，拿不准的再走多路召回，最后汇总。用一串 if/else 加函数调用写，三个分支之后就没人敢改了。LlamaIndex 的 Workflows 模块就是给这种复杂度准备的：它把流程拆成「事件」在节点间流动，每个节点是一个被装饰器标记的异步函数。 心智模型 不用记太多，抓住两个概念： Event（事件）：在节点之间传的数据对象，比如 QueryReceived、RetrievalDone、ResponseReady； Step（步骤）：一个异步函数，用 @step 标记，声明它监听哪些事件、又发出哪些事件。 框架帮你做的是并发调度：多个步骤可以同时跑，事件到了就触发。比起手写 asyncio.gather 加回调，这种声明式写法让流程拓扑一眼看清。 一个多分支问答的骨架 @step async def route(self, ev: QueryReceived) -> Union[RetrieveFactual, RunCalculator]: kind = await classify(ev.query) if kind == 'fact': return RetrieveFactual(query=ev.query) return RunCalculator(query=ev.query) 检索和计算两个步骤并行监听各自事件，跑完都发出 ContextReady，再由汇总步骤合并成最终回答。新增分支，就是加一个事件类和一个步骤函数，不用动老代码。 判断 事件驱动框架的好处在「可观测」：每个事件是一条明确的边界，配合日志你能知道流程卡在哪一步。对那些已经从单轮 RAG 长出来、但还没复杂到要上重型编排引擎的团队，Workflows 是一个比 LangGraph 更轻的中间档——它不抢你的控制权，只把流程显式化。 补一个心智提醒：事件驱动不是银弹。流程只有两三个节点时，写 Workflows 反而比直接 async 更啰嗦。它的甜区是「四五个分支、要并发、要可观测」的中等复杂度。如果你只是线性检索加生成，别为了用框架而用框架——直接函数调用最清楚，也好调试。 框架是手段，把流程画清楚才是目的。别让工具本身，变成新的复杂度来源；分支少的时候，最朴素的函数调用，反而是最不容易出错、最好调试的选择。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LlamaIndex

链式调用为什么不够用 早期 Agent 框架（包括 LangChain 最初的 Chain）本质是一条线性管道：输入进，输出出，中间串几个步骤。但真实的智能体任务充满了循环、分支与回退——写完代码要跑测试，测试挂了得回头改，改完再跑；查资料发现方向错了，要退回去换检索词。线性管道表达不了这种「根据中间结果动态决定下一步去哪」的控制流，于是很快就撞上了天花板。LangGraph 由 LangChain 团队推出，把 Agent 的运行时建模成一张有状态的图：节点是计算步骤，边是转移条件，状态在节点间流动。这一步抽象转换，让 Agent 从「脚本」变成了「可循环的程序」。 节点、边与共享状态 LangGraph 的核心三件套。**节点（node）**是一个普通 Python 函数，接收当前状态、返回要更新的状态片段。**边（edge）**决定下一个节点是谁：固定边写死转移，条件边根据状态里的字段动态路由，比如 if error: go to fix_node else: go to review_node。**状态（state）**是一张被所有节点读写的共享字典，通常用 TypedDict 或 Pydantic 定义，还能配 reducer 决定多个节点写同一字段时是覆盖还是追加（比如消息列表用 add_messages 累加而非替换）。 这套抽象的好处是可控：你能在图里画出循环，能加人在环（human-in-the-loop）的断点，能让某个节点失败后走兜底分支。相比「一个大 prompt 让模型自己决定调什么工具」的黑盒 Agent，LangGraph 把控制流交还给开发者——模型负责推理，图负责流程。 检查点与持久化是它的护城河 真正让 LangGraph 区别于玩具框架的，是 checkpointer。图在每一步执行完都会把状态持久化（可以落 SQLite、Postgres），于是 Agent 可以随时中断、第二天恢复、甚至把状态序列化后在另一个进程里接着跑。这对长周期任务（比如要跑几小时的代码修复 agent、跨多轮对话的客服）至关重要：进程崩了不丢进度，用户随时能插入一条指令让它从当前节点继续。这也是生产级 Agent 系统和 demo 的分水岭。 与其他框架的分工 AutoGen 偏多智能体对话，CrewAI 偏角色分工的角色扮演式协作，LangGraph 偏底层的可控状态图。如果你要的是「快速搭一个多角色剧本」，CrewAI 更顺手；如果你要的是「能调试、能持久化、能上生产的确定性流程」，LangGraph 更可靠。很多团队的做法是用 LangGraph 做编排内核，把工具层通过 MCP 接进来——协议管工具互联，图管流程控制，各司其职。 收束 Agent 编排的演进方向很清楚：从不可控的单 prompt 黑盒，走向有状态、可观测、可恢复的图。LangGraph 抓住了「状态」这个要害。对开发者而言，理解节点、条件边、reducer、checkpointer 这四个概念，比盲目堆工具调用更重要——因为 Agent 的可靠性，从来不是某个模型多聪明，而是流程有没有被好好地组织起来。 ...

两种编排哲学 在AI Agent的工作流设计中，一直存在两种根本不同的哲学： 状态机模式：预先定义好所有状态和转移条件，Agent按照预定的路径执行任务。 自由流程模式：让LLM自主决定下一步做什么，不预设执行路径。 这不是技术偏好的问题，而是对"AI Agent应该有多大的自主权"这一核心问题的不同回答。 状态机模式：可控优先 工作原理 状态机模式将任务分解为有限的状态集合，每个状态对应一组可执行的操作和转移条件。Agent在任意时刻处于某个状态，执行该状态的操作后根据结果转移到下一个状态。 [接收任务] → [分析意图] → [检索信息] → [生成答案] → [质量检查] → [返回结果] ↓ ↓ [信息不足] → [追问用户] [质量不达标] → [重新生成] 优势 确定性高：执行路径可预测，容易测试和调试。同一个输入永远走同一条路径。 可控性强：每个状态可以设置明确的成功条件和失败处理策略。不会出现Agent"跑偏"的情况。 可观测性好：状态转移日志清晰，问题定位容易——知道在哪个状态出了问题。 合规友好：对于金融、医疗等需要审计的场景，状态机可以提供完整的执行轨迹。 劣势 灵活性差：无法处理预定义路径之外的情况。如果用户的问题不在预设流程内，Agent要么报错要么走一个不太合适的流程。 开发成本高：需要预先枚举所有可能的状态和转移条件，对于复杂任务来说工作量巨大。 维护困难：需求变化时需要修改状态图，可能影响多个状态的逻辑。 适用场景 客服流程（问题类型固定，处理流程标准化） 审批流程（步骤固定，需要审计追踪） 数据处理管道（步骤明确，输入输出格式固定） 自由流程模式：灵活优先 工作原理 自由流程模式不预设执行路径，而是让LLM在每一步根据当前状态自主决策下一步行动。Agent观察当前环境、可用工具和历史信息，选择最优的下一步操作。 while not task_complete: observation = get_current_state() thought = llm.reason(observation, history) action = llm.select_action(thought, available_tools) result = execute_action(action) history.append((observation, thought, action, result)) 优势 灵活性极高：可以处理任意复杂的任务，不受预设路径的限制。 开发成本低：不需要预先设计所有流程，只需提供工具集和总体目标。 适应性强：遇到意外情况可以自主调整策略，不需要人工干预修改流程。 劣势 不可预测：同一个任务可能走完全不同的执行路径，测试和调试困难。 可靠性低：Agent可能陷入循环、选择次优策略、甚至做出不合理的操作。 可观测性差：自由流程的执行轨迹可能很长且混乱，问题定位困难。 安全风险：没有预设的约束，Agent可能执行不安全或超出预期的操作。 适用场景 研究分析（问题开放，探索路径不固定） 创意任务（需要灵活的思维路径） 复杂问题解决（无法预先枚举所有情况） 混合方案：受控自由 在实践中，纯状态机和纯自由流程都不是最优解。我们提出了"受控自由"的混合架构： 双层架构 外层状态机：定义任务的高阶段流程和安全边界。比如"必须先验证用户身份→然后才能执行操作→操作后必须记录日志"。 ...

两种编排哲学 在AI Agent的工作流设计中，一直存在两种根本不同的哲学： 状态机模式：预先定义好所有状态和转移条件，Agent按照预定的路径执行任务。 自由流程模式：让LLM自主决定下一步做什么，不预设执行路径。 这不是技术偏好的问题，而是对"AI Agent应该有多大的自主权"这一核心问题的不同回答。 状态机模式：可控优先 工作原理 状态机模式将任务分解为有限的状态集合，每个状态对应一组可执行的操作和转移条件。Agent在任意时刻处于某个状态，执行该状态的操作后根据结果转移到下一个状态。 [接收任务] → [分析意图] → [检索信息] → [生成答案] → [质量检查] → [返回结果] ↓ ↓ [信息不足] → [追问用户] [质量不达标] → [重新生成] 优势 确定性高：执行路径可预测，容易测试和调试。同一个输入永远走同一条路径。 可控性强：每个状态可以设置明确的成功条件和失败处理策略。不会出现Agent"跑偏"的情况。 可观测性好：状态转移日志清晰，问题定位容易——知道在哪个状态出了问题。 合规友好：对于金融、医疗等需要审计的场景，状态机可以提供完整的执行轨迹。 劣势 灵活性差：无法处理预定义路径之外的情况。如果用户的问题不在预设流程内，Agent要么报错要么走一个不太合适的流程。 开发成本高：需要预先枚举所有可能的状态和转移条件，对于复杂任务来说工作量巨大。 维护困难：需求变化时需要修改状态图，可能影响多个状态的逻辑。 适用场景 客服流程（问题类型固定，处理流程标准化） 审批流程（步骤固定，需要审计追踪） 数据处理管道（步骤明确，输入输出格式固定） 自由流程模式：灵活优先 工作原理 自由流程模式不预设执行路径，而是让LLM在每一步根据当前状态自主决策下一步行动。Agent观察当前环境、可用工具和历史信息，选择最优的下一步操作。 while not task_complete: observation = get_current_state() thought = llm.reason(observation, history) action = llm.select_action(thought, available_tools) result = execute_action(action) history.append((observation, thought, action, result)) 优势 灵活性极高：可以处理任意复杂的任务，不受预设路径的限制。 开发成本低：不需要预先设计所有流程，只需提供工具集和总体目标。 适应性强：遇到意外情况可以自主调整策略，不需要人工干预修改流程。 劣势 不可预测：同一个任务可能走完全不同的执行路径，测试和调试困难。 可靠性低：Agent可能陷入循环、选择次优策略、甚至做出不合理的操作。 可观测性差：自由流程的执行轨迹可能很长且混乱，问题定位困难。 安全风险：没有预设的约束，Agent可能执行不安全或超出预期的操作。 适用场景 研究分析（问题开放，探索路径不固定） 创意任务（需要灵活的思维路径） 复杂问题解决（无法预先枚举所有情况） 混合方案：受控自由 在实践中，纯状态机和纯自由流程都不是最优解。我们提出了"受控自由"的混合架构： 双层架构 外层状态机：定义任务的高阶段流程和安全边界。比如"必须先验证用户身份→然后才能执行操作→操作后必须记录日志"。 ...

引言 Agent的状态管理是一个容易被忽视但至关重要的架构问题。无状态的Agent就像一个没有记忆的人——每次对话都从零开始。而有状态的Agent则能记住过去的交互、维持任务进度、在故障后恢复执行。 2026年，随着Agent从简单对话走向复杂任务执行，状态管理已经成为Agent架构中最具挑战性的设计问题之一。 一、Agent状态的类型 1.1 对话状态 最基础的状态类型，包括： 当前对话的历史消息 用户的偏好和上下文 对话中的实体和指代关系 1.2 任务状态 Agent执行复杂任务时的进度状态： 当前任务的目标和约束 已完成的步骤和待完成的步骤 中间结果和待处理的数据 任务的时间线和依赖关系 1.3 环境状态 Agent所处环境的状态快照： 已连接的工具和服务 文件系统的当前状态 外部系统的状态（数据库、API等） 环境变量和配置 1.4 学习状态 Agent在学习过程中积累的状态： 已学到的策略和模式 反思记录和经验教训 性能基线和改进目标 二、状态管理架构 2.1 状态存储分层 ┌─────────────────────────────────┐ │ 内存状态（In-Memory） │ ← 最快，易失 ├─────────────────────────────────┤ │ 会话存储（Redis/Memcached） │ ← 快速，会话级 ├─────────────────────────────────┤ │ 持久存储（PostgreSQL/MongoDB） │ ← 可靠，长期 ├─────────────────────────────────┤ │ 归档存储（S3/OSS） │ ← 低成本，历史 └─────────────────────────────────┘ 2.2 状态序列化 Agent状态需要序列化后存储。2026年的主流方案： JSON序列化：可读性好，兼容性强。适合简单状态和小规模数据。 Protocol Buffers：高效紧凑，支持schema演进。适合大规模生产环境。 自定义二进制格式：极致性能，但维护成本高。适合特殊场景。 选择时需要考虑：序列化/反序列化速度、存储大小、schema演进支持、可读性需求。 2.3 状态版本控制 状态会随时间变化，需要版本控制来支持： 回滚：出问题时回退到之前的版本 审计：追踪状态变更历史 调试：复现问题时需要知道当时的状态 建议采用类似Git的版本控制策略：每次状态变更生成一个diff，按时间链存储。 ...