从一个“跑了三天三夜的Agent突然失忆”说起聊聊状态管理的那些坑先给你讲一个让我头皮发麻的运维事故。去年冬天我们做了一个自动爬取竞品价格并生成调价建议的Agent。它跑得很好连续工作了三天完成了两万多件商品的价格监控。第四天早上运营主管给我打电话“王工你们的Agent从今天凌晨开始把所有商品的价格都调低了10%。”我赶紧查日志。发现Agent在凌晨三点左右处理到某一件商品的时候调用爬虫工具获取价格失败返回了一个空值。按理说它应该记录这个错误跳过该商品继续处理下一个。但它没有。因为它的“状态”在这一步丢失了——它忘了自己正在处理的是哪一批商品也忘了已经处理了多少件。于是它“重新开始”从列表的第一件商品开始重新爬、重新调价。而那件商品已经被调过价了再次调价就变成了“再降10%”。循环往复直到我们被用户投诉电话炸醒。这次事故的根本原因不是工具调用失败而是状态管理没做好。Agent在执行长周期任务时它的“记忆”——当前做到哪一步了、中间结果是什么、已经完成了哪些子任务——没有可靠地保存下来。一旦某个步骤出现异常整个状态就乱了它以为自己还在原来的轨道上其实已经脱轨了。从那以后我把“状态管理”列为智能体开发四大核心基础之一另外三个是工具调用、记忆系统和可观测性。这篇文章我就把状态管理这件事彻底讲透。什么是会话状态什么是上下文什么是检查点它们之间有什么关系怎么在2026年的主流框架里落地全部用我踩过的坑和填坑的经验来说话。一、为什么状态管理是智能体的“生命线”在传统软件里状态管理是个老生常谈的话题。你有全局变量、有数据库、有Redis。请求进来了你从存储里读状态处理完写回去。出错了有事务回滚。这套机制已经非常成熟。但智能体不一样。一个Agent的执行过程不是一次请求-响应而是一个可能持续几分钟、几小时甚至几天的长周期、多步骤、依赖外部反馈的动态过程。它的状态包括但不限于会话状态用户和Agent之间的对话历史谁说了什么Agent回了什么。任务状态当前正在执行的任务拆解到了哪一步已经完成了哪些子任务还有哪些待办中间结果工具调用返回的数据、计算出的临时值、从文档里提取的关键信息。决策轨迹Agent在每一步的“思考”内容——为什么选择这个工具为什么得出这个结论资源状态已经占用的token预算、已经消耗的时间、已经发送的请求数。这些状态不像传统软件的变量那样只在一次函数调用内存活。它们需要在Agent的整个生命周期中持久存在、可恢复、可审计。为什么这么难因为智能体的执行是非确定性的、分布式的、可能被随时中断的。模型调用可能超时工具API可能挂掉用户可能在中途关掉页面服务器可能重启。如果你的状态不落地Agent就是“金鱼脑”——重启就忘断点就乱。下面这张图是我自己画的帮助你理解状态在Agent执行流中的流转路径用户输入 → [会话状态加载] → [任务状态恢复] → LLM推理读取状态→ 工具调用更新状态→ [状态持久化] → 输出 → 等待下一轮每一次循环状态都要经历“加载-使用-更新-保存”四个阶段。少了任何一环Agent就会在某个意想不到的时刻崩溃。二、三态一体会话、上下文与检查点的关系在深入具体技术之前我们先理清三个容易混淆的概念。会话Session指的是用户与Agent之间的一次连续交互过程。它有一个唯一的session_id从用户第一次发消息开始到用户主动结束或超时关闭为止。会话的核心作用是隔离不同用户的交互数据。张三的会话不会污染李四的会话。会话通常需要持久化存储因为用户可能今天聊了一半明天接着聊。上下文Context指的是在单次LLM调用中传递给模型的所有信息。包括系统提示词、用户当前输入、历史对话摘要、工具调用记录、从长期记忆检索到的相关知识等。上下文是“模型能看到的全部”。它的长度受限于模型的上下文窗口所以你需要有取舍——不是所有会话历史都要放进去也不是所有记忆都要塞进来。上下文的管理策略直接决定了模型的推理质量和成本。检查点Checkpoint指的是在Agent执行过程中的某个时间点对完整状态的“快照”。这个快照包括会话状态、任务状态、中间结果、决策轨迹等所有信息。检查点的作用是故障恢复和状态回滚。当Agent在某个步骤出错时你可以恢复到上一个检查点从那里重新开始而不是从头再来。检查点也支持“时间旅行调试”——你可以把Agent的执行过程回放到某个步骤观察当时的决策环境这比看静态日志高效得多。用一个比喻来理解这三者的关系会话是整本书。有一个ISBN号session_id有章节结构有页码。上下文是当前翻开的这一页。你只能看到这一页的内容前一页已经翻过去了后一页还没看到。检查点是你在某些页码上夹的书签。书签记录了那一页的全部内容你随时可以回到那里不用重读前面的所有页。三、会话管理从“金鱼脑”到“大象脑”的第一步会话管理要解决的核心问题是怎么在多次交互之间识别同一个用户并恢复其对话状态最简单的方案是用一个键值存储以session_id为键存储整个对话历史消息列表。每次用户发消息先根据session_id加载历史拼接到上下文中然后调用LLM再把新的消息追加回去。这个方案在MVP阶段完全够用。但生产环境会遇到几个问题问题一会话膨胀。一个重度用户可能跟你聊了上千轮。你把所有历史都加载到上下文里token消耗爆炸响应时间线性增长。解决方案是会话压缩——保留最近N轮比如10轮的完整消息更早的消息用LLM生成一个摘要替换掉原始内容。这样上下文长度可控又不丢失关键信息。我们团队的做法是每20轮对话触发一次压缩把前15轮的对话压缩成200字以内的摘要保留后5轮全文。问题二跨会话的记忆。用户希望Agent记住他的偏好即使换了会话比如今天聊了明天再打开新会话。这就需要长期记忆而不是会话内状态。但MVP阶段不要做太复杂用简单的键值存储就够了。存储的内容只限于用户明确说“记住”的信息不要自动提取。问题三多设备同步。用户在手机上跟Agent聊了一半又在电脑上打开继续。两个设备要共享同一个会话状态。这要求会话存储是中心化的比如Redis或数据库而不是本地内存。我们早期用本地内存存会话结果用户换个设备就“失忆”投诉不断。后来全部迁移到Redis问题解决。2026年主流会话管理方案轻量级Redis JSON序列化。会话数据存为JSON字符串key为session:{session_id}。适合中小规模。企业级PostgreSQL 消息压缩。利用PostgreSQL的JSONB类型存储结构化会话数据配合pgvector做语义检索。适合需要审计、分析、长期存储的场景。云原生使用云厂商的会话托管服务如AWS ElastiCache for Redis、Azure Cache for Redis。免运维自动备份。会话管理的最佳实践清单每个会话分配唯一的session_id在客户端和服务端之间传递通常放在请求头或Cookie里。会话数据至少包含消息列表每条消息有role、content、timestamp、会话创建时间、最后更新时间、元数据用户ID、设备信息等。设置会话过期时间。比如30分钟无活动自动清理避免无限堆积。定期备份重要会话防止意外丢失。四、上下文管理在“有限窗口”里塞进“最有用”的信息如果说会话是“存下来”上下文就是“喂进去”。上下文管理的核心难题是模型的上下文窗口是有限的即使2026年最先进的模型也就几百万token但你的信息可能是无限的。你怎么选上下文窗口越大你塞进去的信息越多模型的推理质量通常越高。但代价是延迟线性增长、成本指数上升。而且过多的无关信息会干扰模型产生“上下文污染”。所以上下文管理的本质是信息筛选和优先级排序。我总结了一个“三层上下文构建法”在生产环境中已经验证有效。第一层系统层固定最高优先级系统提示词、工具定义、安全规则、输出格式约束。这一层是“宪法”每次调用都必须带上且通常被prompt caching缓存成本很低。建议把这一层压缩到最小——只留真正必要的规则不要写长篇大论的“行为准则”。我们有一个内部工具专门分析系统提示词中哪些句子被模型“忽略”了定期清理冗余。第二层会话层可变中等优先级用户的历史消息、Agent的历史回复、工具调用的记录。这一层采用“滑动窗口摘要”策略。具体做法保留最近K轮K通常为5到10的完整对话对于超过K轮的早期对话每M轮M通常为20生成一个摘要摘要本身作为一条特殊消息继续保留。这样你既不会丢失太久远的信息脉络又不会让上下文无限膨胀。一个优化的方法是使用摘要链——不止一个摘要而是摘要的摘要形成金字塔结构。第三层知识层按需检索最低优先级从长期记忆或RAG向量库中检索到的相关知识。这一层不是每次调用都需要的只有在模型“觉得”需要额外信息时才触发检索。触发时机可以是用户明确提问涉及外部知识、模型在推理中自评“信息不足”、或者周期性更新比如每10轮刷新一次。2026年的最佳实践是让Agent自己决定何时检索而不是每次固定检索。实战技巧上下文压缩即使有了分层策略上下文还是可能很长。下面几个压缩方法值得一试工具调用压缩只保留工具名称、关键参数和返回值摘要不保留完整的输入输出。比如get_weather(city北京)返回了{temp:22, condition:晴}压缩成天气查询:北京→22°C晴。消息去重连续重复的“思考”内容只保留第一次。数值归一化把长数字串格式化成易读形式比如“1234567890”变成“12.3亿”。结构化替换用特殊token替代长文本比如[DOC_SUMMARY]代表一篇文档摘要模型在训练阶段就学会了这种token的语义需要模型支持。上下文管理的一个关键决策什么时候用“摘要”什么时候用“原始消息”我的判断标准是需要精确引用的场景用原始消息比如法律条文、代码片段需要理解脉络的场景用摘要比如情绪变化、话题演变。对于客服场景大多数时候摘要就够了对于代码审查必须用原始代码。五、检查点Agent的“时光机”与“后悔药”检查点是状态管理的最高级形态。它把Agent在某个时刻的完整状态序列化保存下来包括会话、任务进度、中间变量、决策轨迹、甚至模型内部的部分隐藏状态如logits、注意力权重——虽然这在生产环境中很少用。检查点有三大用途。用途一故障恢复。Agent在执行一个长任务时突然服务器重启了。没有检查点任务必须从头开始。有检查点你可以从最后一个检查点恢复只丢失从检查点到崩溃之间的那部分工作。这在处理大数据、长时间运行的任务时至关重要。我们那个“三天三夜跑飞”的Agent如果每处理100件商品存一个检查点崩溃后最多损失100件而不是全部重来。用途二调试与审计。你可以把Agent的执行过程“回放”到某个检查点观察当时的决策状态步进式调试。这对于排查复杂的逻辑错误非常有帮助。LangGraph的checkpointer接口就支持检查点的列出、恢复、分支从某个检查点fork出新执行路径等操作。用途三实现“撤销”和“重试”。用户说“上一步错了我想回到之前的状态”或者Agent自己发现某步决策错误想回退到更早的状态重试。有检查点这些就能优雅实现。我们一个金融Agent的“复盘”功能就是基于检查点做的——每一笔交易决策都保存检查点用户不满意可以回滚到决策前重新选择参数。2026年检查点的主流实现方案LangGraph的MemorySaver和SqliteSaver内置的检查点机制支持将状态保存到内存或SQLite数据库。MemorySaver适用于单次运行的开发调试SqliteSaver适用于需要持久化的生产环境。LangGraph的检查点粒度是“图的一个节点执行后”你可以通过配置checkpoint_ns来控制保存频率。自定义序列化如果你的状态包含自定义对象、文件句柄、数据库连接等无法直接JSON序列化的内容你需要自己实现__getstate__和__setstate__方法。一个常见陷阱是工具调用返回的requests.Response对象不能序列化你需要把它转换成字典再存。我们被这个坑过多次后来统一封装了一个SerializableResult类。云存储备份重要Agent的检查点可以定期备份到S3或OSS防止本地存储损坏。对于金融级应用我们甚至做了跨区域备份。检查点的存储开销与性能权衡保存一个完整状态可能需要几KB到几MB不等。对于高频调用的Agent每次节点执行后都保存检查点会带来显著的I/O开销。优化策略异步保存保存操作放到后台线程不阻塞主流程。增量保存只保存从上一次检查点以来的状态变更delta而不是全量状态。LangGraph的Checkpointer接口支持这种模式。采样保存每隔N步保存一次而不是每一步都保存。根据我们的经验每5步保存一次可以在故障恢复成本和性能之间取得平衡。六、主流框架中的状态管理实践2026年的Agent框架对状态管理的支持已经非常成熟。下面我以自己的使用经验对比一下LangGraph、CrewAI和Dify在这方面的差异。LangGraph生产级状态机的标杆LangGraph把Agent建模为一个状态图状态是一个类型化的字典TypedDict。开发者可以显式定义状态的schema包括哪些字段是可选的、哪些是只读的。状态更新是不可变的——每次节点执行后返回一个新的状态对象而不是修改原有的。这保证了状态的追踪性和回滚能力。LangGraph的检查点机制非常强大。你可以在图的任何节点执行后自动保存检查点支持从任意历史检查点恢复甚至可以从一个检查点创建新的分支类似于Git的分支。这对于A/B测试和调试非常有用。我们曾经用这个功能复现了一个生产环境bug从失败会话的最后一个检查点恢复然后在本地步进式运行定位到了问题出在工具调用的参数解析。CrewAI基于角色的状态隔离CrewAI的核心抽象是Agent、Task和Crew。每个Agent有自己的短期记忆对话历史Crew负责协调多个Agent共享的状态如全局任务列表。状态管理相对简单不支持显式的检查点。但CrewAI提供了process参数来控制任务的执行模式sequential顺序、hierarchical层级和consensus共识。不同模式下状态的共享方式不同。CrewAI适合那些任务分解清晰、多角色协作的场景。但如果你需要精细的状态控制和故障恢复它的能力就显得不足了。我们一般在CrewAI外面再包一层状态管理——用Redis保存每个Agent的输出主控程序负责检查点保存。Dify平台化的状态托管Dify作为一个低代码平台把状态管理完全托管了。你不需要关心序列化、存储、恢复这些细节。Dify的工作流节点之间通过“变量”传递状态变量可以是字符串、数字、文件等类型。Dify的会话管理也是内建的提供会话变量长期和临时变量短期两种。Dify的优点是开箱即用缺点是黑盒。你没法像LangGraph那样精细控制检查点的保存时机和内容。对于简单的MVP项目这完全够用对于复杂的企业级应用还是得上LangGraph。建议的选型路径MVP阶段用Dify或CrewAI的托管状态少写代码。需要精细控制状态和故障恢复时迁移到LangGraph SqliteSaver/RedisSaver。极大规模分布式部署用LangGraph 自定义的分布式检查点存储如etcd或ZooKeeper。七、状态管理的常见陷阱与解决方案陷阱一状态序列化失败。你的状态对象里有一个datetime类型或者一个自定义类的实例JSON序列化报错。解决方案使用支持更多类型的序列化库如orjson支持datetime、UUID等或pickle但pickle有安全风险不要用于不受信任的数据。我们最后统一用msgspec性能好且支持类型注解。陷阱二状态版本不兼容。你升级了Agent代码状态的schema变了。从旧检查点恢复时反序列化失败。解决方案给每个状态schema打上版本号在__setstate__方法里做迁移。比如if version 1: convert_to_v2(state)。陷阱三检查点爆炸。你把每个节点执行后的状态都存了很快磁盘就满了。解决方案设置检查点保留策略比如只保留最近100个检查点或者按时间清理保留7天。定期运行清理脚本删除旧的、不再需要的检查点。陷阱四跨Agent状态污染。两个Agent实例不小心用了同一个session_id导致状态混乱。解决方案在session_id中加入Agent类型和实例标识比如客服Agent_v1_{uuid}。使用命名空间隔离不同Agent的会话存储在不同的Redis key前缀下。陷阱五状态与外部系统不一致。Agent的状态里记录了“已经发送了邮件”但实际上邮件发送失败了。解决方案采用“两阶段提交”模式——先更新状态标记为“待发送”再执行操作操作成功后更新状态标记为“已发送”。如果操作失败状态回滚或者进入“重试”状态。八、给开发者的落地建议总结一下从零开始为一个智能体设计状态管理建议分三步走。第一步MVP阶段。只用内存存储会话状态每次请求从内存中加载。不做检查点不做持久化。写日志就够了。这个阶段的目标是验证业务逻辑不追求高可用。你可以用最简单的Flask 全局字典实现。第二步生产就绪阶段。将会话状态迁移到Redis实现多实例共享。引入LangGraph或自研简单的检查点机制至少每完成一个“阶段”保存一次状态比如每处理10条数据。处理会话过期和自动清理。这个时候你需要考虑状态的大小和序列化性能。第三步规模化阶段。实现分层状态存储热数据在Redis冷数据在数据库。启用检查点的异步保存和增量保存。建立状态监控和告警比如检查点保存失败率过高时告警。引入状态版本管理和迁移工具支持不停机升级。最后我想用那个“三天三夜跑飞”的事故结尾。事故发生后我花了整整一周重构了那个价格监控Agent的状态管理。用LangGraph RedisSaver每处理50件商品保存一个检查点增加了一个看门狗协程每10分钟检查一次状态是否“健康”实现了自动恢复机制——如果检测到Agent卡在某个商品超过5分钟自动回滚到上一个检查点重试。自从那次重构之后这个Agent再也没有跑飞过。而且因为有了检查点我们甚至可以在它运行过程中“热升级”代码——从最新的检查点恢复用新代码继续执行。
智能体状态管理：会话、上下文与检查点
发布时间：2026/5/19 1:58:04
从一个“跑了三天三夜的Agent突然失忆”说起聊聊状态管理的那些坑先给你讲一个让我头皮发麻的运维事故。去年冬天我们做了一个自动爬取竞品价格并生成调价建议的Agent。它跑得很好连续工作了三天完成了两万多件商品的价格监控。第四天早上运营主管给我打电话“王工你们的Agent从今天凌晨开始把所有商品的价格都调低了10%。”我赶紧查日志。发现Agent在凌晨三点左右处理到某一件商品的时候调用爬虫工具获取价格失败返回了一个空值。按理说它应该记录这个错误跳过该商品继续处理下一个。但它没有。因为它的“状态”在这一步丢失了——它忘了自己正在处理的是哪一批商品也忘了已经处理了多少件。于是它“重新开始”从列表的第一件商品开始重新爬、重新调价。而那件商品已经被调过价了再次调价就变成了“再降10%”。循环往复直到我们被用户投诉电话炸醒。这次事故的根本原因不是工具调用失败而是状态管理没做好。Agent在执行长周期任务时它的“记忆”——当前做到哪一步了、中间结果是什么、已经完成了哪些子任务——没有可靠地保存下来。一旦某个步骤出现异常整个状态就乱了它以为自己还在原来的轨道上其实已经脱轨了。从那以后我把“状态管理”列为智能体开发四大核心基础之一另外三个是工具调用、记忆系统和可观测性。这篇文章我就把状态管理这件事彻底讲透。什么是会话状态什么是上下文什么是检查点它们之间有什么关系怎么在2026年的主流框架里落地全部用我踩过的坑和填坑的经验来说话。一、为什么状态管理是智能体的“生命线”在传统软件里状态管理是个老生常谈的话题。你有全局变量、有数据库、有Redis。请求进来了你从存储里读状态处理完写回去。出错了有事务回滚。这套机制已经非常成熟。但智能体不一样。一个Agent的执行过程不是一次请求-响应而是一个可能持续几分钟、几小时甚至几天的长周期、多步骤、依赖外部反馈的动态过程。它的状态包括但不限于会话状态用户和Agent之间的对话历史谁说了什么Agent回了什么。任务状态当前正在执行的任务拆解到了哪一步已经完成了哪些子任务还有哪些待办中间结果工具调用返回的数据、计算出的临时值、从文档里提取的关键信息。决策轨迹Agent在每一步的“思考”内容——为什么选择这个工具为什么得出这个结论资源状态已经占用的token预算、已经消耗的时间、已经发送的请求数。这些状态不像传统软件的变量那样只在一次函数调用内存活。它们需要在Agent的整个生命周期中持久存在、可恢复、可审计。为什么这么难因为智能体的执行是非确定性的、分布式的、可能被随时中断的。模型调用可能超时工具API可能挂掉用户可能在中途关掉页面服务器可能重启。如果你的状态不落地Agent就是“金鱼脑”——重启就忘断点就乱。下面这张图是我自己画的帮助你理解状态在Agent执行流中的流转路径用户输入 → [会话状态加载] → [任务状态恢复] → LLM推理读取状态→ 工具调用更新状态→ [状态持久化] → 输出 → 等待下一轮每一次循环状态都要经历“加载-使用-更新-保存”四个阶段。少了任何一环Agent就会在某个意想不到的时刻崩溃。二、三态一体会话、上下文与检查点的关系在深入具体技术之前我们先理清三个容易混淆的概念。会话Session指的是用户与Agent之间的一次连续交互过程。它有一个唯一的session_id从用户第一次发消息开始到用户主动结束或超时关闭为止。会话的核心作用是隔离不同用户的交互数据。张三的会话不会污染李四的会话。会话通常需要持久化存储因为用户可能今天聊了一半明天接着聊。上下文Context指的是在单次LLM调用中传递给模型的所有信息。包括系统提示词、用户当前输入、历史对话摘要、工具调用记录、从长期记忆检索到的相关知识等。上下文是“模型能看到的全部”。它的长度受限于模型的上下文窗口所以你需要有取舍——不是所有会话历史都要放进去也不是所有记忆都要塞进来。上下文的管理策略直接决定了模型的推理质量和成本。检查点Checkpoint指的是在Agent执行过程中的某个时间点对完整状态的“快照”。这个快照包括会话状态、任务状态、中间结果、决策轨迹等所有信息。检查点的作用是故障恢复和状态回滚。当Agent在某个步骤出错时你可以恢复到上一个检查点从那里重新开始而不是从头再来。检查点也支持“时间旅行调试”——你可以把Agent的执行过程回放到某个步骤观察当时的决策环境这比看静态日志高效得多。用一个比喻来理解这三者的关系会话是整本书。有一个ISBN号session_id有章节结构有页码。上下文是当前翻开的这一页。你只能看到这一页的内容前一页已经翻过去了后一页还没看到。检查点是你在某些页码上夹的书签。书签记录了那一页的全部内容你随时可以回到那里不用重读前面的所有页。三、会话管理从“金鱼脑”到“大象脑”的第一步会话管理要解决的核心问题是怎么在多次交互之间识别同一个用户并恢复其对话状态最简单的方案是用一个键值存储以session_id为键存储整个对话历史消息列表。每次用户发消息先根据session_id加载历史拼接到上下文中然后调用LLM再把新的消息追加回去。这个方案在MVP阶段完全够用。但生产环境会遇到几个问题问题一会话膨胀。一个重度用户可能跟你聊了上千轮。你把所有历史都加载到上下文里token消耗爆炸响应时间线性增长。解决方案是会话压缩——保留最近N轮比如10轮的完整消息更早的消息用LLM生成一个摘要替换掉原始内容。这样上下文长度可控又不丢失关键信息。我们团队的做法是每20轮对话触发一次压缩把前15轮的对话压缩成200字以内的摘要保留后5轮全文。问题二跨会话的记忆。用户希望Agent记住他的偏好即使换了会话比如今天聊了明天再打开新会话。这就需要长期记忆而不是会话内状态。但MVP阶段不要做太复杂用简单的键值存储就够了。存储的内容只限于用户明确说“记住”的信息不要自动提取。问题三多设备同步。用户在手机上跟Agent聊了一半又在电脑上打开继续。两个设备要共享同一个会话状态。这要求会话存储是中心化的比如Redis或数据库而不是本地内存。我们早期用本地内存存会话结果用户换个设备就“失忆”投诉不断。后来全部迁移到Redis问题解决。2026年主流会话管理方案轻量级Redis JSON序列化。会话数据存为JSON字符串key为session:{session_id}。适合中小规模。企业级PostgreSQL 消息压缩。利用PostgreSQL的JSONB类型存储结构化会话数据配合pgvector做语义检索。适合需要审计、分析、长期存储的场景。云原生使用云厂商的会话托管服务如AWS ElastiCache for Redis、Azure Cache for Redis。免运维自动备份。会话管理的最佳实践清单每个会话分配唯一的session_id在客户端和服务端之间传递通常放在请求头或Cookie里。会话数据至少包含消息列表每条消息有role、content、timestamp、会话创建时间、最后更新时间、元数据用户ID、设备信息等。设置会话过期时间。比如30分钟无活动自动清理避免无限堆积。定期备份重要会话防止意外丢失。四、上下文管理在“有限窗口”里塞进“最有用”的信息如果说会话是“存下来”上下文就是“喂进去”。上下文管理的核心难题是模型的上下文窗口是有限的即使2026年最先进的模型也就几百万token但你的信息可能是无限的。你怎么选上下文窗口越大你塞进去的信息越多模型的推理质量通常越高。但代价是延迟线性增长、成本指数上升。而且过多的无关信息会干扰模型产生“上下文污染”。所以上下文管理的本质是信息筛选和优先级排序。我总结了一个“三层上下文构建法”在生产环境中已经验证有效。第一层系统层固定最高优先级系统提示词、工具定义、安全规则、输出格式约束。这一层是“宪法”每次调用都必须带上且通常被prompt caching缓存成本很低。建议把这一层压缩到最小——只留真正必要的规则不要写长篇大论的“行为准则”。我们有一个内部工具专门分析系统提示词中哪些句子被模型“忽略”了定期清理冗余。第二层会话层可变中等优先级用户的历史消息、Agent的历史回复、工具调用的记录。这一层采用“滑动窗口摘要”策略。具体做法保留最近K轮K通常为5到10的完整对话对于超过K轮的早期对话每M轮M通常为20生成一个摘要摘要本身作为一条特殊消息继续保留。这样你既不会丢失太久远的信息脉络又不会让上下文无限膨胀。一个优化的方法是使用摘要链——不止一个摘要而是摘要的摘要形成金字塔结构。第三层知识层按需检索最低优先级从长期记忆或RAG向量库中检索到的相关知识。这一层不是每次调用都需要的只有在模型“觉得”需要额外信息时才触发检索。触发时机可以是用户明确提问涉及外部知识、模型在推理中自评“信息不足”、或者周期性更新比如每10轮刷新一次。2026年的最佳实践是让Agent自己决定何时检索而不是每次固定检索。实战技巧上下文压缩即使有了分层策略上下文还是可能很长。下面几个压缩方法值得一试工具调用压缩只保留工具名称、关键参数和返回值摘要不保留完整的输入输出。比如get_weather(city北京)返回了{temp:22, condition:晴}压缩成天气查询:北京→22°C晴。消息去重连续重复的“思考”内容只保留第一次。数值归一化把长数字串格式化成易读形式比如“1234567890”变成“12.3亿”。结构化替换用特殊token替代长文本比如[DOC_SUMMARY]代表一篇文档摘要模型在训练阶段就学会了这种token的语义需要模型支持。上下文管理的一个关键决策什么时候用“摘要”什么时候用“原始消息”我的判断标准是需要精确引用的场景用原始消息比如法律条文、代码片段需要理解脉络的场景用摘要比如情绪变化、话题演变。对于客服场景大多数时候摘要就够了对于代码审查必须用原始代码。五、检查点Agent的“时光机”与“后悔药”检查点是状态管理的最高级形态。它把Agent在某个时刻的完整状态序列化保存下来包括会话、任务进度、中间变量、决策轨迹、甚至模型内部的部分隐藏状态如logits、注意力权重——虽然这在生产环境中很少用。检查点有三大用途。用途一故障恢复。Agent在执行一个长任务时突然服务器重启了。没有检查点任务必须从头开始。有检查点你可以从最后一个检查点恢复只丢失从检查点到崩溃之间的那部分工作。这在处理大数据、长时间运行的任务时至关重要。我们那个“三天三夜跑飞”的Agent如果每处理100件商品存一个检查点崩溃后最多损失100件而不是全部重来。用途二调试与审计。你可以把Agent的执行过程“回放”到某个检查点观察当时的决策状态步进式调试。这对于排查复杂的逻辑错误非常有帮助。LangGraph的checkpointer接口就支持检查点的列出、恢复、分支从某个检查点fork出新执行路径等操作。用途三实现“撤销”和“重试”。用户说“上一步错了我想回到之前的状态”或者Agent自己发现某步决策错误想回退到更早的状态重试。有检查点这些就能优雅实现。我们一个金融Agent的“复盘”功能就是基于检查点做的——每一笔交易决策都保存检查点用户不满意可以回滚到决策前重新选择参数。2026年检查点的主流实现方案LangGraph的MemorySaver和SqliteSaver内置的检查点机制支持将状态保存到内存或SQLite数据库。MemorySaver适用于单次运行的开发调试SqliteSaver适用于需要持久化的生产环境。LangGraph的检查点粒度是“图的一个节点执行后”你可以通过配置checkpoint_ns来控制保存频率。自定义序列化如果你的状态包含自定义对象、文件句柄、数据库连接等无法直接JSON序列化的内容你需要自己实现__getstate__和__setstate__方法。一个常见陷阱是工具调用返回的requests.Response对象不能序列化你需要把它转换成字典再存。我们被这个坑过多次后来统一封装了一个SerializableResult类。云存储备份重要Agent的检查点可以定期备份到S3或OSS防止本地存储损坏。对于金融级应用我们甚至做了跨区域备份。检查点的存储开销与性能权衡保存一个完整状态可能需要几KB到几MB不等。对于高频调用的Agent每次节点执行后都保存检查点会带来显著的I/O开销。优化策略异步保存保存操作放到后台线程不阻塞主流程。增量保存只保存从上一次检查点以来的状态变更delta而不是全量状态。LangGraph的Checkpointer接口支持这种模式。采样保存每隔N步保存一次而不是每一步都保存。根据我们的经验每5步保存一次可以在故障恢复成本和性能之间取得平衡。六、主流框架中的状态管理实践2026年的Agent框架对状态管理的支持已经非常成熟。下面我以自己的使用经验对比一下LangGraph、CrewAI和Dify在这方面的差异。LangGraph生产级状态机的标杆LangGraph把Agent建模为一个状态图状态是一个类型化的字典TypedDict。开发者可以显式定义状态的schema包括哪些字段是可选的、哪些是只读的。状态更新是不可变的——每次节点执行后返回一个新的状态对象而不是修改原有的。这保证了状态的追踪性和回滚能力。LangGraph的检查点机制非常强大。你可以在图的任何节点执行后自动保存检查点支持从任意历史检查点恢复甚至可以从一个检查点创建新的分支类似于Git的分支。这对于A/B测试和调试非常有用。我们曾经用这个功能复现了一个生产环境bug从失败会话的最后一个检查点恢复然后在本地步进式运行定位到了问题出在工具调用的参数解析。CrewAI基于角色的状态隔离CrewAI的核心抽象是Agent、Task和Crew。每个Agent有自己的短期记忆对话历史Crew负责协调多个Agent共享的状态如全局任务列表。状态管理相对简单不支持显式的检查点。但CrewAI提供了process参数来控制任务的执行模式sequential顺序、hierarchical层级和consensus共识。不同模式下状态的共享方式不同。CrewAI适合那些任务分解清晰、多角色协作的场景。但如果你需要精细的状态控制和故障恢复它的能力就显得不足了。我们一般在CrewAI外面再包一层状态管理——用Redis保存每个Agent的输出主控程序负责检查点保存。Dify平台化的状态托管Dify作为一个低代码平台把状态管理完全托管了。你不需要关心序列化、存储、恢复这些细节。Dify的工作流节点之间通过“变量”传递状态变量可以是字符串、数字、文件等类型。Dify的会话管理也是内建的提供会话变量长期和临时变量短期两种。Dify的优点是开箱即用缺点是黑盒。你没法像LangGraph那样精细控制检查点的保存时机和内容。对于简单的MVP项目这完全够用对于复杂的企业级应用还是得上LangGraph。建议的选型路径MVP阶段用Dify或CrewAI的托管状态少写代码。需要精细控制状态和故障恢复时迁移到LangGraph SqliteSaver/RedisSaver。极大规模分布式部署用LangGraph 自定义的分布式检查点存储如etcd或ZooKeeper。七、状态管理的常见陷阱与解决方案陷阱一状态序列化失败。你的状态对象里有一个datetime类型或者一个自定义类的实例JSON序列化报错。解决方案使用支持更多类型的序列化库如orjson支持datetime、UUID等或pickle但pickle有安全风险不要用于不受信任的数据。我们最后统一用msgspec性能好且支持类型注解。陷阱二状态版本不兼容。你升级了Agent代码状态的schema变了。从旧检查点恢复时反序列化失败。解决方案给每个状态schema打上版本号在__setstate__方法里做迁移。比如if version 1: convert_to_v2(state)。陷阱三检查点爆炸。你把每个节点执行后的状态都存了很快磁盘就满了。解决方案设置检查点保留策略比如只保留最近100个检查点或者按时间清理保留7天。定期运行清理脚本删除旧的、不再需要的检查点。陷阱四跨Agent状态污染。两个Agent实例不小心用了同一个session_id导致状态混乱。解决方案在session_id中加入Agent类型和实例标识比如客服Agent_v1_{uuid}。使用命名空间隔离不同Agent的会话存储在不同的Redis key前缀下。陷阱五状态与外部系统不一致。Agent的状态里记录了“已经发送了邮件”但实际上邮件发送失败了。解决方案采用“两阶段提交”模式——先更新状态标记为“待发送”再执行操作操作成功后更新状态标记为“已发送”。如果操作失败状态回滚或者进入“重试”状态。八、给开发者的落地建议总结一下从零开始为一个智能体设计状态管理建议分三步走。第一步MVP阶段。只用内存存储会话状态每次请求从内存中加载。不做检查点不做持久化。写日志就够了。这个阶段的目标是验证业务逻辑不追求高可用。你可以用最简单的Flask 全局字典实现。第二步生产就绪阶段。将会话状态迁移到Redis实现多实例共享。引入LangGraph或自研简单的检查点机制至少每完成一个“阶段”保存一次状态比如每处理10条数据。处理会话过期和自动清理。这个时候你需要考虑状态的大小和序列化性能。第三步规模化阶段。实现分层状态存储热数据在Redis冷数据在数据库。启用检查点的异步保存和增量保存。建立状态监控和告警比如检查点保存失败率过高时告警。引入状态版本管理和迁移工具支持不停机升级。最后我想用那个“三天三夜跑飞”的事故结尾。事故发生后我花了整整一周重构了那个价格监控Agent的状态管理。用LangGraph RedisSaver每处理50件商品保存一个检查点增加了一个看门狗协程每10分钟检查一次状态是否“健康”实现了自动恢复机制——如果检测到Agent卡在某个商品超过5分钟自动回滚到上一个检查点重试。自从那次重构之后这个Agent再也没有跑飞过。而且因为有了检查点我们甚至可以在它运行过程中“热升级”代码——从最新的检查点恢复用新代码继续执行。
