1. 先聊一个问题为什么Demo能跑一上生产就崩1.1 一次真实的线上事故现场先讲一件我最近亲历的事。团队把一个Agent部署到生产环境用来做客户工单的自动分类、方案检索和邮件回复。开发环境里跑得行云流水demo演示时客户也点头满意。上线第三天凌晨2点17分告警响了。日志里只有一行触目惊心的错误agent execution terminated due to error.这个错误几乎人人都见过但真正让人崩溃的是后面的连锁反应。Agent在第17步调用CRM接口创建了一条客户跟进记录然后在第23步给客户发送了确认邮件接着在模型API超时后整个执行流程被强制终止。重启Agent之后它没有从第18步继续而是直接从第1步重新开始执行。结果就是CRM里出现了两条跟进记录客户收到了两封一模一样的确认邮件而Agent自己浑然不觉因为它每轮执行都只是从头想了一遍。这个场景一点都不新鲜。任何把Agent从demo推向生产的人迟早都会撞上同一堵墙Agent的长期运行和传统API服务是两种完全不同的可靠性模型。传统API是无状态的请求来了算一下返回结果完事。Agent不是Agent是一个拿着工具、盯着外部世界、分多步做决策的循环流程。它在第15步做的决定取决于第1步到第14步的输入、推理和工具返回结果。一旦循环中断整个决策链就断了。1.2 从单次问答到长期运行的质变很多人对Agent的第一印象来自ChatGPT式的单轮问答你问一个问题模型返回一段回答。这种模式天然是无状态的顶多带个上下文窗口一次调用的生命周期以秒计算崩溃了重发一次请求就行。但一旦进入真正的Agentic AI应用——自动化运维、多步骤业务流程、自主数据分析、无人值守的定时任务——事情就变了。Agent不再是回答一个问题而是在执行一系列相互依赖的操作。它要调用内部工具、访问外部数据库、和另一个Agent协作、根据上一步的结果修正下一步的策略。这个过程的时长可能是几分钟、几小时甚至跨天。这时候你就没法再用请求-响应的心态看待它了。一个运行了一小时的Agent本质上是一台在多个节点之间搬运状态、持续做出决策的分布式进程。它的大脑LLM每次推理是无状态的但它的肉身——调用的外部系统、写入的数据库、累积的上下文、沉淀的记忆——全部是有状态的。这些状态散布在不同的地方任何一个环节失联、漂移、被覆盖整个Agent的认知就会和现实脱节。1.3 一个核心判断Agent的思考也是一种状态这里我要抛出一个核心观点也是整篇文章的基石Agent的推理过程本身就是一种状态而且是最容易被忽略的状态。传统观点认为状态是数据库里存的数据缓存里的KV而Agent的思考是计算不是状态。但实际上Agent每一步推理的中间结论、它对某个方案的选择、它决定调用哪个工具、它暂时搁置的备选路径这些都是状态。想象一下你在纸上推导一道数学题写到第三步发现思路不对要回到第二步重推。如果你的草稿纸被风吹走了你就只能从第一步重新开始。Agent的上下文窗口就是它的草稿纸一旦进程崩溃、上下文丢失它就只能从头思考。更麻烦的是Agent的思考状态和外部世界状态是双向耦合的。它根据外部系统的返回值决定下一步怎么做它的动作又会改变外部系统的状态。这就形成了一个分布式系统中典型的状态-动作-状态循环。所以我的结论是长期运行的Agent在工程上必须被当作一个分布式状态机来对待而不是一个能调用工具的大模型。这个视角一旦建立很多原本模糊的问题就会变得清晰为什么需要检查点为什么需要幂等为什么记忆那么容易污染为什么多Agent协作那么难答案全都藏在这四个字里状态机。2. Agent的状态到底散落在哪里四张状态地图既然要把Agent当分布式状态机对待第一件事就是搞清楚它的状态到底存在哪里我把它拆成四个位置每个人的系统可能略有不同但这四张地图基本能覆盖90%以上的场景。2.1 LLM上下文正在消逝的短期状态第一张地图也是最容易理解的LLM的上下文窗口。Agent的推理链、工具返回结果、用户指令、历史对话都通过上下文传给模型。它是Agent做决策的工作内存。但问题在于这段状态是易失的。进程崩溃、API超时、上下文溢出触发截断策略都会导致这段状态的丢失或变形。而且上下文本身有长度上限Agent跑得越久早期的重要决策越可能被截断策略挤出去。你没法像读数据库一样精确恢复它在第15步到底基于什么理由选了方案B上下文里只有模糊的痕迹。所以把上下文当作唯一的决策依据是长期运行Agent的第一大隐患。它本质上是分布式系统里的进程内寄存器掉电即失。2.2 外部系统世界状态第二张地图是Agent所有工具调用所触及的外部系统——数据库、CRM、工单系统、文件存储、第三方API。这是Agent执行动作后留下的世界状态也是最容易引发可靠性事故的状态。传统分布式系统里有个概念叫真实来源source of truthAgent系统的真实来源就是这些外部系统。Agent读到的数据、写入的数据、删除的数据都发生在它们身上。问题是Agent对这些外部系统的操作是不可控的相同的动作执行两次数据库里就会多两行记录读到了一个过期的缓存Agent就会基于错误的事实做决策。世界状态的另一个特征是它不随Agent进程的生死而变化。Agent崩溃了外部系统里它上次写入的数据还在。这意味着Agent恢复后的行为必须与它崩溃前的足迹保持一致否则整个系统就会进入一种你说你有理但数据不答应的混乱状态。2.3 Agent记忆层缓存的经验第三张地图是记忆层。短期记忆对应当前会话的摘要和关键结论中期记忆可能是一些跨会话的工作笔记、未完成任务、偏好设定长期记忆则是沉淀到向量库或知识库里的经验教训。记忆层的本质是一个缓存它的作用是让Agent不必每次都从零开始推理而是能复用过去的结论和模式。但缓存有个经典问题缓存一致性。外部世界已经变了记忆里存的还是老版本。你上次告诉Agent这个客户偏好邮件沟通这周客户改了偏好但Agent的长期记忆还在按照一周前的事实做决策。更严重的是记忆污染。记忆一旦被写入就会被后续所有会话共享。一次失败的排查过程、一个错误的业务结论如果被当作经验固化到长期记忆里影响的不只是当前这个Agent实例而是整个Agent群的后续行为。这个话题我在第5章专门展开。2.4 编排层运行轨迹与恢复点第四张地图是编排层的运行轨迹。包括当前执行到哪一步、已经完成了哪些工具调用、每一步的结果是什么、重试了几次、还有哪些分支没有走完。这是Agent系统的控制状态。很多Agent框架其实没把这张地图持久化Agent跑完就完事了所有轨迹都存在内存里。这种设计在短任务里没问题但一旦任务以小时计进程被调度系统杀掉、机器重启、Pod被重新调度轨迹就没了。Agent醒来之后面对的是白纸一张它不知道自己是新手还是老兵。我一直强调一个观点编排层状态是Agent系统中最应该被严肃对待的状态因为它决定了崩溃后Agent到底能恢复到哪一步。事件溯源、检查点、工作流引擎这些基础设施本质上都是在为这张地图提供持久化保障。2.5 为什么说这就是分布式状态机把这四张地图放在一起看你就能理解我为什么坚持用分布式状态机来定义长期运行的AgentLLM上下文 进程内的易失工作区外部系统 远程共享存储记忆层 分布式缓存与知识库编排层 控制器状态与恢复日志Agent每做一次决策就是一次状态转移。它读取外部系统的状态结合自己的上下文和记忆产生一个动作这个动作写入外部系统同时改变编排层的进度然后它再读取新一轮的外部状态继续决策。整个过程就是一台横跨多个计算节点、多个存储节点的分布式状态机。用这个视角去审视Agent很多可靠性问题就不再是玄学而是分布式系统教科书的经典命题状态如何持久化如何保证不丢失多个写入方如何保持一致崩溃后如何恢复下一个章节我讲一个长期运行Agent最典型、也最致命的故障模式。3. 长期运行的头号杀手状态与执行如何失同步3.1 崩溃恢复从检查点重新开始没那么简单假设你已经听了建议给Agent加了检查点机制每执行完10步保存一次运行轨迹。Agent在第23步崩溃重启后从第20步的检查点恢复。听起来很美好但这里藏着一个很多团队栽过跟头的细节检查点恢复的是Agent的执行轨迹不是外部世界的状态。在第20步到第23步之间Agent可能已经调用了一个外部API在对方的系统里创建了一条数据。这个调用成功了但Agent还没来得及把结果写回自己的检查点就崩溃了。恢复之后Agent从第20步重新执行它会再次调用同一个外部API再创建一条数据。你以为做了恢复实际上制造了重复。这就是分布式系统里最经典的两阶段提交难题在Agent场景的复现Agent执行动作的提交发生在外部系统而Agent记录动作的提交发生在本地的检查点两个提交无法保证原子性。要么你接受至少一次语义然后必须处理重复要么你设计恰好一次语义这需要外部系统配合提供幂等接口。大多数业务系统都只能给你至少一次所以问题就提前了。3.2 重试陷阱同一个副作用被执行了两次我再展开说重试这件事。很多Agent框架默认支持工具调用失败后自动重试看起来是个贴心的容错设计。但重试背后有个前提被重试的操作必须是幂等的。这里的幂等指的不是重试不会报错而是重试不会产生新的副作用。现实里最常见的非幂等操作包括发邮件通知重试一次就是多发一封创建/更新工单没有幂等键的接口重试就是多一条记录扣减库存或余额这几乎是最危险的非幂等操作外部第三方系统开票、下单、转账这些系统的接口通常不提供幂等语义重试一次就是一次真实后果我在项目里见过最惨的一次事故Agent调用支付接口给客户退款第一次调用超时了——注意是超时不是失败。框架自动重试第二次调用成功但第一笔其实也扣款成功了。客户的账户被退了两笔钱。事后排查发现支付网关确实处理了两笔第一笔只是响应包在网络传输中丢了Agent那边看是超时。这就是分布式系统里经典的超时不等于失败。所以在Agent的基础设施设计里所有可能产生副作用的工具调用都必须携带幂等标识。请求ID、业务幂等键、去重表一套都要配齐。这个我放在第4章4.2节详细讲。3.3 记忆污染坏经验被写进了长期记忆第三个失同步的场景比前两个更隐蔽也更难追踪记忆污染。Agent在运行过程中会把一些结论写入记忆层这些结论可能来自一次失败的尝试、一个错误的假设、或者某个外部系统短暂故障时的异常数据。举个例子Agent在凌晨3点调用某个第三方天气API失败了连续重试3次都失败。然后Agent把这句经验写进了长期记忆天气API不稳定不可信。第二天天气API早就恢复了但新的Agent会话启动时读到了这条记忆于是遇到天气相关的任务时自动绕过这个API选择了另一个数据源——那个数据源不仅收费更高数据还更旧。整个团队排查了两天才定位到问题源头竟然是前一天凌晨的瞬时故障被固化成了一条永久记忆。记忆污染的本质是把瞬时异常当成了长期事实。LLM本身并不擅长区分这次失败和这个系统总失败它天然倾向于把局部经验泛化成一般结论。如果没有一层额外的防护机制对写入记忆的内容做筛选、验证和时效管理长期运行的系统一定会被自己写下的错误经验逐渐吞噬。3.4 一条完整的故障链路复盘为了让你更直观地理解这几个问题如何串在一起我复盘一遍我实际处理过的一条完整故障链路某Agent负责夜间自动巡检服务器磁盘发现使用率超过90%就触发扩容流程。某个凌晨磁盘使用率确实超过了阈值Agent正常进入扩容流程调用云平台API创建了一块新磁盘。第一次调用超时Agent框架自动重试第二次调用成功但云平台实际创建了两块磁盘第一块也成功了只是响应丢失。Agent随后在编排层记录了扩容流程已完成的轨迹其中引用的是第二次调用的请求ID第一块的ID没有记录进来。第二天运维看到账号下多了两块未挂载磁盘其中一块完全不在任何Agent轨迹里以为是被攻击了。排查了很久才发现是重试埋下的雷。而更烦人的是Agent把云平台创建磁盘接口超时率偏高写进了长期记忆后续所有涉及云平台的操作都被它加了一层保守策略——多等30秒再校验结果。整个系统的执行效率被拖慢了而这一切的起点仅仅是一次普通的超时重试。这个链路里检查点、幂等、记忆污染三个问题全部踩中了。它不是个例而是长期运行Agent系统里每天都在发生的事情。看完这些故障模式接下来我讲怎么从基础设施层面把它们一个个摁住。4. 把Agent当状态机来设计基础设施可靠性四件套4.1 事件溯源与检查点把决策过程落盘既然Agent是一个分布式状态机那状态机的可靠性基础设施第一件套就是事件溯源Event Sourcing 周期性检查点Checkpoint。事件溯源的核心思想是不保存Agent的当前状态而是保存它从开始到现在经历过的所有事件。每个事件都是一条不可变的、有序的日志记录。举个例子事件的典型结构大概是这样的{ event_id: evt_8f3a2b, agent_id: agent_crm_001, task_id: task_2024_0719_001, sequence: 47, timestamp: 2024-07-19T02:17:33.821Z, type: tool_call, payload: { tool: crm.create_follow_up, arguments: {customer_id: c_8891, note: 确认退款意向}, request_id: req_612df4 }, result: { status: success } }Agent每执行一步决策——不管是LLM推理结论、工具调用请求、外部返回结果还是用户新给的指令——都往事件日志里追加一条记录。这样Agent的完整执行轨迹就是一条不可变的事件流。有了事件流检查点的作用就变了它不是保存Agent的瞬时状态快照而是记录我已经处理到第几条事件了。崩溃恢复时Agent只需要从事件的游标位置继续重放即可。事件日志是从外部系统拿不到的执行细节比如Agent在每一步的推理理由、它考虑过但放弃的备选方案、工具返回结果的完整内容。这些信息在外部系统里只会留下片面的痕迹只有事件日志能完整还原Agent当时是怎么想的。实话说做完整的事件溯源在Agent场景有额外成本。每条LLM的推理结论都要序列化、持久化存储和写入压力会明显增加。我通常采用折中方案LLM推理步骤只记录摘要和关键结论工具调用步骤记录全量参数和返回结果的必要字段。推理的完整思维链要不要存取决于你后续需不需要做可解释性分析大多数业务场景存摘要就够了。检查点的间隔也需要权衡。间隔太短写入压力大间隔太长崩溃时丢失的事件多恢复时重放的成本高。我一般建议以外部副作用为基准每次工具调用落一条事件、每三轮推理落一个轻量检查点。实际操作时可以根据Agent的平均执行时长动态调整。4.2 幂等性设计让每次工具调用都可安全重放第二件套幂等性。这也是我前面反复强调的重点这里展开讲具体做法。对所有可能产生副作用的工具调用统一要求携带一个全局唯一的幂等键。这个键的生成规则建议是任务ID 步骤序号 动作类型的组合保证同一个任务中同一个动作永远生成同一个键。外部系统在处理请求时先查一下这个幂等键是否已经处理过处理过就直接返回上次的结果不再执行新的操作。这里有一个容易忽略的细节幂等键不是给框架看的是给外部系统看的。如果你的外部系统不支持幂等判断光靠Agent本地记录键是没用的。跨系统调用尤其是第三方提供的HTTP API第三方怎么实现幂等是你控制不了的。这种时候我能给的唯一建议是在上游做预检宽松代码。比如发邮件。你没法让邮件服务为你的重试去重但Agent可以在调用前先向自己的事件日志写入一封待发送邮件的记录状态是pending等邮件服务确认发送后再把状态改成sent。恢复时Agent看到pending状态就主动去邮件服务查一下这封邮件到底发了没有。这种先记账、后执行、对账兜底的模式比盲目重试可靠得多。还需要对工具调用做分类管理读操作天然幂等重试无风险放心重试纯写操作有幂等键支持可安全重试但重试次数要有限制纯写操作无幂等键支持默认不重试改为标记失败进入人工/半自动处理级联操作如创建订单扣库存发通知必须拆成多个可独立幂等的子步骤各自对账这一套规则看起来繁复但它是唯一能让你在凌晨3点安心睡觉的东西。Agent的可靠性本质上就是每个动作都能被安全地重放。4.3 编排层与恢复逻辑从手写循环到状态机引擎第三件套是编排层。早期Agent框架的编排逻辑往往是简单的手写循环调用模型→解析意图→执行工具→追加上下文→继续循环。这种循环在单次任务里够用但长期运行任务需要的是更底层的状态机语义。我建议把编排逻辑从代码里抽离出来用显式的状态定义来管理Agent的执行生命周期。至少定义这些状态阀值RUNNING正常执行中WAITING_INPUT等待用户或外部系统输入TOOL_CALLING正在执行工具调用RETRYING工具调用失败处于退避重试CHECKPOINT到达检查点正在保存事件日志PAUSED被暂停等待外部条件触发恢复TERMINATED_ERROR异常终止等待恢复决策COMPLETED任务正常完成每个状态之间的迁移条件都要明确。比如RETRYING到TOOL_CALLING的迁移条件是重试间隔已到且重试次数未超上限到TERMINATED_ERROR的迁移条件是重试到达三次上限。把这些逻辑写成状态迁移表比散落在各个回调里的if-else清晰得多也方便做故障后的精确恢复。恢复逻辑也要提前设计好不是简单重跑就完事。当Agent进入TERMINATED_ERROR恢复决策至少有三种选择重放恢复从最近的检查点重放事件日志适合工具调用已完成、但编排状态未保存的场景语义恢复保留已完成步骤的最终结果跳过重放从上一步决策直接继续适合工具副作用已经生效、重放会导致重复的场景人工接管把事件摘要发给运维人员由人来决定下一步适合副作用不明确、风险较高的场景这三种恢复策略的选择标准是外部世界的状态是否已经被Agent的动作改变。如果前几步的动作已经在外部系统里生效了首选语义恢复如果还没生效首选重放恢复。判断依据就是前面说的事件溯源日志和外部系统状态的对账结果。4.4 超时、重试、熔断与死信Agent级容错三板斧第四件套是经典分布式系统的容错工具但应用到Agent场景时参数和经验值都有讲究。先说超时。LLM推理的超时设置不能太激进尤其长上下文场景下模型的响应时间波动很大。我见过的生产配置一般是单次LLM调用超时60秒工具调用超时按工具类型区分内部工具20秒内必有响应第三方外部API给到45秒。有人会说45秒太长了但你要理解Agent的工具调用等待时间会直接叠加到整个任务的执行时长上而长期运行的Agent最怕的就是单个步骤把整个链路拖死。超时设置的本质是上限保护不是期望时长。再说重试策略。LLM调用的重试通常是指数退避抖动——第一次失败后等2秒第二次4秒第三次8秒加上一个随机抖动因子避免多个Agent同时重试打爆API。但对工具调用的重试我要特别强调先判断副作用是否可能已经发生再决定能不能重试。凡是有可能已经生效的写操作一律不走自动重试而是走先前的幂等键对账流程。熔断器的思路也适用但要针对不同外部系统分别设熔断阈值。如果连续5次调用CRM接口失败就熔断CRM的调用让Agent不要继续尝试写操作转向缓存读取或者挂起等待人工处理。熔断阈值不要设得太低因为外部系统的短暂抖动很常见阈值越低误熔断的概率越大。我通常是以观察窗口错误率的组合来触发比如30秒内错误率超过50%就熔断。最后是死信队列。Agent无法处理的任务不应该静默丢弃也不应该无限重试而是应该进入一个专门的主题。我在生产实践中看到最成功的模式是建一个人工复核队列。Agent执行失败、达到重试上限、或触发安全策略被中止时把完整的事件日志摘要、出错位置、尝试过的操作、失败原因打包成一条审核消息推给运维人员。人工审核后可以做出三种处置重试一次、修复逻辑后重放、标记为废弃。这套机制简直是长期运行Agent的救命稻草它把系统自己扛不住的问题优雅地交给了人类处理。有了这四件套打底你的Agent至少不会再出现崩溃后一切重来重复副作用这种基础级事故。但还远远不够接下来我要讲一个更隐蔽的可靠性隐患记忆体系。5. 记忆体系比想象中更复杂的可靠性问题5.1 短期、中期、长期记忆的实现边界现在Agent的记忆已经几乎成了标配功能但很多人对记忆的实现边界是模糊的。我从可靠性角度重新梳理一下三层记忆的实现边界短期记忆通常承载在当前会话的上下文窗口里对应Agent处理当前任务的工作记忆。它的可靠性问题主要在于上下文溢出——任务太长早期关键信息被截断。实践中可以通过周期性摘要来解决每几轮对话把已有内容压缩成结构化摘要把摘要留在上下文里原始细节落盘到事件日志。这样即使上下文被截断Agent也能通过摘要和事件日志找回关键信息。中期记忆是跨会话但不长期保留的工作状态比如当前正在处理的客户列表今天已经完成的三项任务。它通常存在Redis或关系数据库里有天然的生命周期管理。中期记忆的可靠性重点在于过期清理很多系统的中期记忆没有TTL导致上周的任务状态这周还在干扰Agent的决策。务必给每条中期记忆打上时间标签和有效期。长期记忆是向量库或知识库里的经验沉淀包括用户偏好、业务流程、历史教训。长期记忆的写入门槛应该是最高的因为它的影响面最大、负面后果最难修复。在我的团队里有一条铁律长期记忆不允许Agent自动写入必须经过校验流程。一种简单有效的形式是提出写入提案→短期试用→定期复核→正式固化。Agent先提出一条候选记忆系统把它放在一个专门的候选区只有经过多次验证、被证明是正确的经验才有可能被提升为长期记忆。5.2 记忆读写最常见的三个坑第一坑写入路径不保证原子性。很多系统的记忆写入由Agent自己完成Agent先调用向量库写入再更新关联索引这两个操作之间如果崩溃就可能出现索引指向了不存在的向量或向量存在但索引里找不到的数据碎片。我在项目里遇到过Agent明明记得客户张先生上个月投诉过物流问题但检索系统就是找不到这条记忆的来源记录后来一查是向量库写入了、索引没更新成功。解决思路是引入一个记忆写入日志每次写入先记录日志、再执行写库、完成后标记日志状态像数据库的预写日志一样。第二坑读取结果的时效性。长期记忆里的内容默认是历史事实但Agent读取时往往不加时效判断。一条客户要求优先邮件沟通的记忆可能已经是一年前的旧信息。要么让记忆在写入时就自带有效期字段并定期刷新要么让Agent在读取时把记忆内容和用户当前的明确指令做优先级排序——用户当前的明确指令永远高于长期记忆里的隐含偏好。这个优先级规则要写死在系统里不能只靠大模型的自觉。第三坑记忆的去重与矛盾处理。多个Agent会话可能对同一件事写下互相矛盾的记忆。比如会话A经历了一次支付接口超时写下支付API不可靠会话B后来成功调用了同一接口十几次却没有覆写这条负面记忆。长期记忆里就同时存在不可靠和数据正常两条矛盾记录LLM检索到哪条就信哪条行为完全不可预测。这里需要一道记忆合并/冲突裁决逻辑新写入的记忆如果与旧记忆冲突不能简单覆盖也不能简单共存而是应该在冲突标记下交由人工或规则裁决。5.3 防御性记忆框架的思路像a-memguard那样思考最近社区里讨论比较多的是面向LLM Agent记忆的主动防御框架类似a-memguard的路线。我没有直接复现过它但它的设计思路非常值得借鉴本质上是把网络安全里的纵深防御应用到记忆层。这个思路的核心有几点读时校验、写时审查、溯源追踪。读时校验是Agent读取某条记忆时先检查这条记忆的来源、写入时间、置信度和有效期来源不明的记忆压低权重甚至忽略。写时审查是Agent想要写入一条记忆时先经过安全规则过滤比如拦截包含敏感信息的记忆、拦截明显情绪化或偏激的结论、拦截与已知事实冲突的内容。溯源追踪则是每条记忆都保留完整的来源记录——是哪一个Agent、在哪个任务、基于哪些事件产生这条记忆的一旦发现记忆出了问题可以回溯到源头进行批量修正。我之前在自己项目里实现过一个简化版重点就加了三条规则记忆写入必须携带来源事件ID没有来源的记忆直接拒收。记忆在候选区观察24小时期间可以被其他会话投票认同或质疑只有正向投票超过阈值的才进入长期区。每条长期记忆带last_verified时间超过30天未被复核的自动降级为低置信度读取时会在提示词里备注该记忆已过期仅供参考。这套机制跑起来之后记忆污染引起的线上行为漂移明显减少。所以如果你现在还只是在用记忆还没给记忆加防护强烈建议把记忆体系当作一个独立的可靠性子系统来运维而不是Agent的一个附属功能。6. 多Agent协作状态机变成了状态机网络6.1 通信机制与共享状态单Agent的可靠性问题解决之后下一个复杂度台阶就是多Agent协作。多个Agent同时运行每个都是一台状态机它们之间必然要共享信息、传递任务、协调行为。这就相当于把单台状态机扩展成了状态机网络可靠性问题也从单点崩溃升级成了分布式一致性问题。先说通信机制。多Agent之间的通信我见过的实现可以归为两大类消息传递和共享黑板。消息传递模式下Agent之间通过消息队列或直接调用传递指令和结果每个Agent是独立的执行单元状态隔离性最好但消息丢失、重复投递、顺序错乱这些分布式消息系统的问题一个不少。这里尤其要注意Agent消息队列必须做持久化和去重否则一个Agent给另一个Agent的消息丢了接收方还在傻等整个协作流程就永久挂起。共享黑板模式下Agent们共用一个数据结构每个Agent可以在上面写入自己的成果、读取别人的成果。实现上最常用的是共享数据库或内存表。这种模式状态一致性更直观但并发冲突是噩梦——两个Agent同时写入黑板上的同一个字段后写的覆盖先写的先写Agent的所有推理就白做了。我在一个实际项目里见过两个Agent同时抢着更新同一个客户标签字段A写高价值客户B写待跟进最终标签被后写的B覆盖A背后的整个营销策略全部执行错了。6.2 多Agent写入同一份外部状态时的冲突通信机制之外更麻烦的是多个Agent同时对外部系统写入。还是用CRM场景举例假设你的系统里有三个Agent销售线索Agent负责识别新客户并写入CRM客户维护Agent负责更新客户信息数据分析Agent周期性从CRM拉数据做分析。三个Agent同时操作同一批客户记录没有冲突协调机制的话数据很快就会变成一团乱麻。个体Agent一次写错数据自己检查可能还能发现。但多个Agent互相覆盖、互相引出新的状态变化错误会在系统里传播放大最后谁都说不清哪条数据是哪个Agent写的、基于什么逻辑写的。我给这类系统提过一个很土但有效的建议写操作必须带所属Agent和业务理由的双重标记。每次写入不仅写业务数据本身还要写一个审计字段标注是哪个Agent、基于哪个事件、带着什么目的写入的。一旦数据出问题沿着审计字段往回查就能追溯到源头定位是谁在什么时候、基于什么理由写出了这条数据。这个做法成本很低但排障效率提升不是一点半点。6.3 死锁、活锁与收敛性问题多Agent协作里最隐蔽的可靠性问题是死锁和活锁。Agent A在等待Agent B的确认结果才能决策下一步Agent B在等待Agent A提供前置数据才能开始工作。如果两个Agent各自的超时和等待逻辑没有互相协调这个协作就直接卡死了——两个Agent都会进入等待中状态但等待他们的不是人类是彼此。活锁更阴险。Agent A发现数据不完整向Agent B发出补全请求Agent B按照自己的逻辑补全后发现数据格式和Agent A期望的不一致于是回滚Agent A发现数据被回滚了再次向Agent B发出补全请求。两个Agent看似都在忙碌实际上在无限循环兜圈子任务永远无法完成。处理死锁和活锁的方法和分布式系统经典做法一样全局超时协作协调器。给每个Agent之间的消息交互设置最大等待时间超时强制进入异常分支不允许无限等待。同时引入一个协调器来负责任务的调度和依赖关系的管理避免Agent之间直接互相等待——所有的依赖关系都通过协调器传递协调器知道谁等谁能识别出循环依赖并主动打破。我见过不少团队嫌协调器重觉得Agent之间直接沟通更智能。但实测下来只要Agent数量超过三个没有协调器的纯对等协作几乎必然出现某种形式的循环等待。所以我的建议是哪怕协调器只是一个简单的状态表服务也一定要有。它不需要替代Agent的智能只需要负责管理Agent之间谁在对谁负责这个关系。最后再说收敛性。多Agent团队的最终结果应该收敛到一个确定状态而不是每次跑完都不一样。如果你的多Agent系统跑十次出十个结果说明某个环节的状态没被明确管理。常见做法是给整个协作任务定义一个共同的事实基线——所有Agent读取的外部状态以这个基线为准所有Agent写入的结果回到这个基线里校验冲突。基线就是那个分布式状态机的全局状态寄存器每个Agent是它的一个并发分支。只要设计者在架构上把全局状态和分支状态的边界划清楚收敛性问题就解掉了大半。7. 落地建议生产级Agent的可靠性检查清单7.1 上线前问自己七个问题写到这里我不想再讲太多理论了直接给一份我每次带着团队评审Agent系统时用的检查清单。如果你正在把一个Agent从demo推向生产建议逐条过一遍你的Agent崩溃后能从哪一步恢复是永远从头开始还是能从最近的检查点重放如果答案是从头开始你的Agent只适合短任务不适合长期运行。所有可能产生副作用的工具调用都能通过幂等键安全重放吗别跟我说应该没问题要真的去外部系统验证过。Agent的记忆写入有来源验证和时效管理吗没有来源的记忆、不会过期的记忆迟早变成污染源。如果LLM API连续失败5次你的系统会自动进入什么状态是无限重试打爆API还是优雅降级、进入人工接管多个Agent同时对外部系统写入时谁负责冲突解决如果没有协调者建议先别上线多Agent。你的检查点多久保存一次保存本身可靠吗检查点如果写在本地磁盘Pod一重启就没了等于白做。从demo到生产你改了什么如果答案是什么都没改那你大概率还没准备好。这七个问题里只要有一个答不上来我都建议先别急着上量。因为Agent的故障不是概率事件而是必然事件——运行时间足够长每个问题都会出现。7.2 从能跑到扛得住的演进路径踩过足够多的坑之后我总结了一条Agent基础设施的演进路径分享给正在路上的团队第一阶段先把事件日志做成标配。不管你的Agent现在是简单循环还是框架编排强制要求每一步决策都记录事件日志工具调用带请求ID任务有全局ID。这一步不改架构成本极低但它为后面所有可靠性能力提供了数据基础。第二阶段引入状态管理。把Agent的执行生命周期用显式状态定义出来加检查点、加恢复逻辑。这个阶段要把崩溃后怎么办从口头讨论变成实际代码。第三阶段做记忆治理。给记忆层加来源登记、有效期、候选区、冲突裁决。记忆的可靠性治理越早做越好因为记忆一旦被污染历史包袱会越来越大清洗成本是指数增长的。第四阶段再考虑多Agent。多Agent协作的前提是单个Agent已经扛得住了。否则你面临的不是一个Agent出错而是多个Agent互相放大彼此的错。多Agent的调试成本比单Agent高一个量级先把单点的可靠性打牢再上。我个人在实际操作中的体会是Agent技术迭代很快模型越来越强、框架越来越成熟但长期运行的Agent本质上是一个分布式状态机这个判断短期内不会变。LLM负责解决思考质量而基础设施负责解决思考的连续性。很多团队把所有精力都花在提示词优化和模型选型上却忽略了后者——结果就是线上Agent总在奇怪的地方翻车怎么调prompt都没用因为问题根本不在想得不够好而在想的过程中断了。最后再分享一个我在项目里反复验证过的小技巧所有线上Agent的运行状态除了技术指标之外一定要多关注一个指标——从上次检查点以来的未完成动作数。这个数字越大说明Agent越接近一次失控的边缘。你可以给这个指标设一个告警阈值比如超过20就提醒人工介入。这个指标帮我提前拦截过至少三次潜在的线上事故比单纯监控CPU、内存有用得多。Agent的可靠性不会从模型能力里自动长出来它必须靠基础设施一层层垒上去。把Agent当状态机把你的状态机加固好你的Agent才能真正从能跑变成扛得住。
