1. 从RPC到状态机Agent 的本质角色转变很多刚开始做 Agent 开发的朋友都把 Agent 当成一个“更聪明的大模型 API”——给个 prompt丢进去然后等它返回一段文字。这种思路在本地 demo 阶段完全没问题你用一个循环让模型自主决策、调用工具、再观察结果跑通一个 ReAct 式的例子就觉得万事大吉。但一旦把 Agent 放到生产环境事情就完全变了。你遇到的第一个问题往往不是模型不够聪明而是状态丢了。Agent 跑了一个小时中间经历了三次工具调用、两次网络重试最后因为一次数据库连接超时整个任务回滚到初始状态。或者更糟Agent 以为自己在做第 5 步实际上系统记录它还停留在第 2 步。这时候你会发现一个关键事实Agent 根本不是“无状态的 API 调用”它本质上是一个长期运行的、分布在多个节点上的状态机。每一轮“思考—行动—观察”都是一次状态转移每次工具调用都会改变系统状态而整个运行过程跨越的时间尺度可能是小时甚至天跨越的物理边界可能是多个服务、多个容器、甚至多个数据中心。我见过不少团队在架构评审时把 Agent 画成一个简单的 request-response 框然后质疑为什么生产环境里 Agent 的表现和测试环境差这么多。问题的根源就在这里——Agent 的可靠性和传统微服务的可靠性有着本质区别你不能用“调用一个函数”的心态去设计一个“运行一整天且需要自我纠错”的系统。这个认知转变是整篇文章的基础。一旦你把 Agent 视为分布式状态机可靠性问题就从“prompt 写得好不好”变成了“状态怎么存、怎么恢复、怎么在多个副本之间保持一致”整个技术栈的选择也随之改变。2. 为什么说 Agent 本身就是一个状态机2.1 状态机视角下的 Agent 运行模型一个标准的 Agent 运行循环无论是 ReAct 范式还是更复杂的 Plan-and-Execute 范式都可以抽象成这样一个模型Agent 处于某个状态 S接收输入 I通过大模型的推理产生动作 A执行动作后获得观察 O然后转移到下一个状态 S。如果用代码来表达大概是这样的class AgentStateMachine: def __init__(self, initial_state: State): self.state initial_state def step(self, observation: Observation) - Action: # 第一步结合当前状态和观察让模型决定下一步动作 action self.llm.decide(self.state, observation) # 第二步执行动作产生副作用 result self.execute(action) # 第三步把执行结果和新的上下文合并更新状态 self.state self.transition(self.state, action, result) return action这个模型里的关键在哪里关键在于state.transition这一步不是纯粹的函数式变换它伴随着真实世界的副作用。Agent 调用了一个支付接口钱就真的转出去了Agent 调用了一个文件系统接口文件就真的被删除了。这就是为什么不能把 Agent 当作无状态函数来处理。如果 Agent 崩溃了你不能像重启一个 Web 服务那样直接让它重新开始因为重新开始意味着重复执行副作用——用户可能被扣了两笔钱文件可能被重复处理。状态机思维要求你把“状态”和“计算”分离让状态本身具备持久化、可恢复、可校验的能力。从状态机的角度Agent 的生命周期可以分为几个关键阶段初始化时创建初始状态、每次迭代时基于当前状态做出决策、执行动作后记录新状态、任务完成时落定终态。这些阶段的可靠性直接影响最终结果的可信度。2.2 内存之外状态的三个层次说到状态很多人的第一反应是“上下文窗口”。确实大模型 API 是天然的“内存”但它的容量有限而且放在 API 调用里非常昂贵。生产环境里的 Agent 状态管理远不止是拼 prompt 这么简单。我习惯把 Agent 的状态分成三个层次分别对应不同的存取策略和可靠性等级短期状态也叫工作记忆指当前任务上下文中的对话记录、中间推理过程、临时变量。这部分状态变动最快、体量最大但丢失后影响相对可控。实践中通常放在内存里配合定期序列化快照做兜底。不过要注意快照不是万能的如果 Agent 在两步之间崩溃快照只能恢复到上一个检查点中间丢失的状态转移需要靠日志重建。中期状态指任务级的状态包括当前执行到计划的哪一步、完成了哪些子目标、积累了哪些中间结果、哪些工具调用已经产生了副作用但尚未确认。这部分状态是可靠性设计的核心必须持久化到数据库或消息队列中并且需要支持事务性的更新。你可以把它理解成数据库里的一条任务记录每次状态转移都是一次行更新只不过更新内容由大模型来决定。长期状态也叫永久记忆是跨任务的领域知识、用户偏好、历史行为模式。很多人喜欢把长期记忆直接塞给大模型让它在每个请求时全量携带。但这样做既浪费 token 又没有任何可靠性保障——模型一旦忘记或者说输出不稳定没有数据库做兜底整个记忆体系就是空中楼阁。这三层状态恰好对应了可靠性的不同要求短期状态要快、中期状态要稳、长期状态要一致。设计状态存储时如果混为一谈后面排查问题会非常痛苦。3. 基础设施可靠性Agent 与微服务的四个关键差异在讨论“怎么把 Agent 做可靠”之前先搞清楚一个更有意思的问题Agent 基础设施的可靠性设计和传统微服务有什么不同3.1 失败的成本不对称传统微服务中一个请求失败的成本是有限的——最多就是这次请求没成功用户可以重试。但 Agent 的失败成本是不对称的Agent 可能已经执行了十几次工具调用其中涉及扣款、建表、发消息等副作用操作。此刻如果系统崩溃你不能简单地说“这个任务失败了请重新开始”因为重新开始意味着把副作用再执行一遍。这也是 Agent 可靠性设计中最棘手的问题。传统微服务可以通过幂等设计来解决重试问题但 Agent 的每一步动作是由大模型决定的你无法事先为每一步都设计好幂等键。一个更可行的思路是引入“副作用记录”——把每一步已经产生的副作用记录在案重跑时先检查和补偿已有的副作用再做下一步。3.2 决策的不可预测性微服务的逻辑是确定的同样的输入同样的代码路径输出基本一致。但 Agent 的每一步决策都来自大模型的采样具有天然的随机性。你今天测试通过的任务明天可能因为模型版本升级或者概率波动出现完全不同的行为路径。这种不可预测性给可靠性带来了两个挑战第一你无法通过传统的单元测试和契约测试来保证 Agent 的行为正确性因为输出本身就带随机性第二你无法通过简单的超时和重试机制来应对异常因为一个“卡住”的 Agent 可能不是在等待响应而是在无限循环中反复做无用功。因此在 Agent 基础设施中传统的静态超时通常不够用需要引入动态的“循环检测”和“进度评估”。隔一段时间检查一下 Agent 是否取得了实质性的进展如果没有就进行干预。这个机制在大模型领域有一个名字叫“死亡循环检测”在分布式系统里本质上是一个“心跳 进度指标”的问题。3.3 确定性边界需要一套“语义内核”兜底大模型的输出不可控但状态转移可以做到可控。这里的关键是把“决策”和“执行”分离大模型负责做语义层面的决策比如判断当前任务需要调用哪个工具、下一步的目标是什么而状态转移本身由一套确定性的“语义内核”来执行。我实践下来最顺手的架构是 Semantic Kernel 模式。大模型是语义大脑负责理解任务、拆解目标、决定调用顺序内核是语义内核负责执行状态转移、维护状态一致性、处理并发和重试。内核里没有模糊逻辑只有确定性的状态机转移表和校验规则。大模型说“下一步要调用 payment 接口”内核会先验证当前状态是否允许这个调用、是否已经执行过相同的调用、调用参数是否符合预定义 schema然后才真正执行。这样设计的好处是即使大模型的决策偶尔出错内核也会在状态层面上把错误拦截下来不会让脏状态扩散到整个系统。3.4 资源生命周期Agent 不是短连接传统服务的资源生命周期和请求绑定请求进来创建连接请求结束释放连接。但 Agent 运行时间可能长达数小时它需要的 CPU、内存、GPU如果本地推理、API 调用额度、外部系统连接等资源都需要按任务级别来管理。如果你用传统微服务的心态给 Agent 设计限流和配额一定会遇到这样的问题某个用户触发的 Agent 正在长期运行占用了大量资源但你无法像释放 HTTP 连接一样中途释放它因为释放就意味着任务中断任务中断就意味着已经产生的副作用需要补偿。这就是为什么 Agent 基础设施里需要引入“任务调度器”或“执行沙箱”的概念。每个 Agent 实例运行在自己的容器/进程空间里有自己的资源配额、日志流和超时策略调度器负责在异常时强制回收资源同时触发补偿流程。简而言之你需要把 Agent 当成“有状态的长期作业”来管理而不是“可丢弃的请求”来管理。4. 让 Agent 可靠落地基础设施设计实操聊完了底层认知下面进入实操环节。这部分我会按照一个具体的 Agent 平台来展开设计目标是可以直接抄作业。4.1 架构分层与核心组件我采用的架构和传统后端开发中常见的“表示层—应用层—领域层—基础设施层”分层对应上了这样团队里每个人都能快速对齐分层职责核心组件可靠性关键表示层面向用户的交互界面如聊天窗口、任务面板WebSocket 网关、SSE 通道连接保活、消息有序推送应用层任务编排、会话管理、用户请求入口任务管理器、会话服务会话与状态映射、请求幂等领域层核心业务逻辑状态机转移、工具调用决策、任务分解Agent 引擎、工具注册中心、语义内核状态转移幂等、工具调用的可观测性基础设施层状态存储、消息队列、任务调度、日志与追踪数据库、Redis、MQ、调度器持久化一致性、故障恢复、监控告警这套分层的核心逻辑是把“Agent 的业务逻辑”和“基础设施能力”彻底解耦。Agent 引擎只负责“基于当前状态做出决策”不关心状态存在哪里调度器只负责“在合适的时间把 Agent 放到合适的资源上跑”不关心 Agent 具体在干什么。4.2 状态存储从内存到数据库的路径状态存储是整个可靠性的基石。我的推荐做法是“内存 Redis MySQL 三级存储”内存存放当前正在运行的 Agent 会话的工作记忆要求读写极快不做持久化。Redis存放每个 Agent 实例的运行时状态当前步骤、中间结果、工具调用记录TTL 设置成任务的预计最长运行时间支持快速恢复。MySQL/PostgreSQL存放任务级的状态快照和审计日志一旦 Redis 中的数据丢失可以从数据库恢复整个任务上下文。一个关键的设计细节是每次状态写入都带上 version 字段更新时使用乐观锁UPDATE agent_task SET state ?, version version 1 WHERE id ? AND version ?这样可以防止多个调度节点同时对同一个任务做状态更新出现“状态回退”这种经典分布式问题。我在项目里实测下来乐观锁的代价微乎其微但对一致性的保护非常有效尤其是多个 Agent 协作或人工介入干预时这个字段能挡住大量低级的并发 bug。4.3 持久化和恢复流程光有存储还不够恢复流程的设计才是真正拉开差距的地方。我把 Agent 的持久化恢复两条路径写下来正常持久化路径Agent 每一步执行完毕后将最新状态通过事务写入数据库同时向消息队列发送一条“状态变更”事件供其他系统消费比如前端推送进度、监控系统更新指标。崩溃恢复路径调度器通过心跳机制发现某个 Agent 实例失联后会从数据库读取该任务最近的持久化状态然后在新的节点上重新拉起 Agent。拉起后需要按照日志回放已执行的步骤判断哪些副作用已经产生并对未完成的部分进行补偿或重试。这里有一个很实在的经验不能只保存 Agent 的“当前状态”还要保存“执行轨迹”。我在设计表结构时加了一张 agent_execution_trail 表记录每一次动作的输入、输出、耗时、异常信息。恢复时拿着这条轨迹可以反向推导出哪些工具已经被调用过、产生了什么效果避免重复执行。这个表在排查问题时价值极大因为它让 Agent 的每一步都有据可查不再是一个黑盒。4.4 调度与资源管理调度是 Agent 基础设施里最容易低估的部分。我见过很多团队把 Agent 跑在普通的 Web 服务器进程里结果一个 Agent 占用了全部线程池其他请求全部排队。生产环境里推荐的方案是独立的 Worker 池。每个 Agent 实例是一个单独的工作单元调度器按照任务优先级和资源现状把任务分配给合适的 WorkerWorker 启动时向调度器注册自己的资源容量内存、GPU、并发数调度器维护一个任务队列每个任务绑定其所需的资源类型Worker 执行任务时通过租约机制声明任务锁执行完释放如果 Worker 失联租约会过期调度器将其上的任务重新排队租约机制我用 Redis 实现SET key value EX timeout 原子操作搞定简单可靠。租约时长设置为任务心跳周期的 3 倍太短会导致频繁抢锁太长会延迟故障恢复。5. 多 Agent 协作从单机状态机到分布式一致性5.1 消息传递还是共享状态生产环境里很少有单个 Agent 独立解决所有问题的场景。常见的设计是多个 Agent 协作——一个 Planner Agent 负责拆解任务多个 Worker Agent 并行执行子任务一个 Reviewer Agent 负责结果审查。此时你要面对的是“分布式状态机之间的同步”问题比单个 Agent 的状态管理复杂一个量级。实现多 Agent 协作有两种思路共享状态模式所有 Agent 读写同一个状态数据库。优点是实现简单、状态天然一致缺点是并发冲突严重而且一旦状态库出问题所有 Agent 同时瘫痪。消息传递模式Agent 之间通过消息队列通信每个 Agent 维护自己的局部状态通过“消息”同步状态转移。优点是各 Agent 松耦合、故障隔离好缺点是分布式一致性难保证可能出现消息乱序或丢失。我的建议是优先采用消息传递模式但混合使用共享状态做“任务级台账”。简单来说任务级的状态谁在做什么、做到哪一步了放在共享数据库里Agent 之间的交互细节通过消息队列传递。这样既避免了大量并发写数据库的问题又保留了全局可观测性。5.2 编排器模式与事件驱动模式在多 Agent 协作的架构选型上我实践过两种模式各有适用场景。编排器模式Orchestrator一个中央 Agent 负责接收用户请求、拆解任务、分发给各个 Worker 并汇总结果。优点是逻辑清晰、控制力强缺点是中央 Agent 成为单点一旦它挂掉所有子任务都悬空。适合任务流程相对固定的场景。事件驱动模式Event-driven没有中央控制节点Agent 通过事件总线互相发现和协作。一个 Agent 完成某个步骤后发布事件另一个 Agent 监听相关事件并触发自己的动作。优点是高扩展性和容错性缺点是调试困难、流程不可预测。适合任务高度动态、参与者不固定的场景。综合来看生产项目中我倾向于“双模式混合”用编排器做顶层任务分解把子任务封装为可以独立运行的事件驱动流程。顶层编排器负责全局进度的把控子任务内部靠事件驱动保持灵活性。这样既能在任务级别保证确定性又能让每个子任务有足够的自由度。这里特别提醒一个坑不要把事情想得太完美Event-driven 模式的调试难度远超预期。我建议在任何 Agent 发布事件时都带上全局唯一的 Trace ID把所有事件链条串起来否则线上出了问题你连“是哪一步导致的错误”都定位不到。6. 实操经验问题排查与框架选型速查6.1 五个高频问题的排查思路在实际运行中Agent 基础设施出的问题大多数集中在以下几个方面。我把常见的症状、原因和排查方向整理成一张表可以对照排查症状可能原因排查方向Agent 任务莫名其妙中断日志显示 execution terminated due to error状态存储超时导致状态读取失败查看数据库慢查询日志、连接池配置、Redis 超时参数同一任务被重复执行用户被重复扣费调度器在 Worker 失联后重新调度但没有做幂等控制检查任务租约是否正常释放、执行轨迹表是否记录完整Agent 无限循环始终在做同样的事情大模型决策陷入局部循环执行结果没有改变状态引入进度检查机制设定最大重复步数和语义雷同检测多个 Agent 协作时状态互相覆盖不同 Agent 同时更新同一任务的状态行检查数据库乐观锁是否生效查看状态更新时间戳任务恢复后行为与崩溃前不一致只恢复了快照没有恢复执行轨迹补全恢复流程恢复时先回放 agent_execution_trail这里面我想重点展开一下“无限循环”的问题。大模型的上下文长度有限如果 Agent 陷入了循环它的上下文窗口会被自己的输出塞满最终表现为 token 耗尽或者上下文溢出。一个实用的兜底方案是记录 Agent 最近 N 步动作的语义摘要计算两两之间的相似度如果连续 N 步高度雷同就主动中断并让模型重新规划。这个机制不需要复杂的算法用简单的向量相似度或文本去重就能覆盖大部分场景。6.2 主流的 Agent 框架怎么选很多刚入门的读者会问现在框架这么多我应该用哪个我说下自己的体会如果是从零搭一套生产级的 Agent 基础设施推荐 Semantic Kernel。它对状态管理、Planner、Memory 的抽象比较完整底层接 LLM 和接传统代码一样自然非常适合做大工程。如果团队偏轻量任务复杂度不高LangChain 或 LlamaIndex 生态的上手成本低社区资源丰富但要注意它们更偏“开发套件”而不是“生产平台”状态管理和可观测性要自己补。如果侧重 AI Agent 自动化交互AutoGen 或 CrewAI 这类框架在多 Agent 协作方面有优势但 RAG 能力、持久化方案要额外设计。如果只是做验证性 demo手写一个 ReAct 循环其实就够了不必过早引入框架带来的抽象层和依赖。框架选型的底层逻辑是一致的看你的核心诉求是“可控性”还是“开发速度”。生产系统的可靠性永远偏向可控性。6.3 关于 Agent 安全的补充虽然本文的核心是可靠性但安全和可靠性往往是一体两面。基础设施层面至少要做到两件事一是工具调用的白名单机制。Agent 能调用的工具必须经过预定义和校验参数必须符合 schema必要时增加人工审批环节。不能因为 Agent 是“智能体”就放弃边界控制。二是完整的审计日志。每一次状态变更、每一次工具调用、每一次人机交互都要记录在案。可靠性问题排查到最后你会发现审计日志是最重要的生产资料没有之一。7. 写在最后回到开头的问题Agent 到底是什么我的答案是它不是更智能的函数而是更复杂的分布式系统。当你用分布式状态机的视角去看它可靠性问题就有了清晰的解题框架状态要持久化、转移要幂等、恢复要走轨迹、资源要隔离、协作要一致。这个过程本身其实很“App Agent”——大模型负责灵活决策工程师负责搭建确定性内核。一套可靠的 Agent 基础设施本质上就是大模型的灵活性和传统分布式系统的确定性之间的桥梁。希望这篇内容对你搭建自己的 Agent 平台有用也欢迎实践后有心得回来交流探讨。