# Agent渡劫48关-第7关-State、Context、Memory到底有什么区别？

> 聊天记录不是Memory，Context也不是State。

```text
[读者] 正在做多轮Agent的工程师
[痛点] State/Context/Memory混为一谈，重启丢状态
[现在读] 多租户客服平台要跨会话、可恢复、可审计
[读完] 能画出三者的边界、持久化与权限模型
```

```text
[旧方案] 用聊天记录数组当全部状态
    |
    v
[新需求] 多租户、跨会话、可恢复、权限隔离
    |
    v
[冲突] 聊天记录既不是结构化State，也不是长期Memory
    |
    v
[后果] 重启丢单、串租户、记忆越权、审计断链
```

我是老李，在一个多租户全球智能客服 Agent 平台做架构。系统覆盖多企业、多项目、多语言、多渠道，支持 IM、电话、邮件和企业数字人入口，并连接 CRM、订单、支付、物流、工单、知识库。任务是处理退款、改地址、查物流等。

早期 V1，我们用内存字典按 session_id 存聊天记录，每轮把整个消息列表塞给模型。订单号、流程节点、用户偏好全混在消息里，靠模型自己“记住”。

后来一次发布重启，正在进行的退款流程全部丢失；多租户之间偶尔串数据；模型把历史聊天当长期记忆，把 A 企业的订单信息带给了 B 企业。

State、Context、Memory 到底该怎么分？

服务重启后，订单退款流程怎么恢复到正确节点？

长期记忆怎么带来源、过期和权限边界，避免串租户？

# 01、故事

订单 ORD-2024-001 进入退款流程，节点从 collect_reason 推进到 verify_order。V1 把 State 放在内存字典，key 是 session_id。用户说“我要退款”，Agent 记下原因，准备核对订单。

服务重启后，内存字典清空。用户再次发消息，Agent 从 collect_reason 重新开始。更糟的是，租户 A 和租户 B 的 session_id 发生碰撞，A 的订单信息出现在 B 的会话里。

> 现场有订单
> 节点有流转
> 内存有风险
> 重启有代价

# 02、问题

旧方案失效：内存字典无法跨进程、跨实例共享，也无法恢复。业务影响：退款中断、客诉升级、合规审计断链。技术表现：Context 把聊天记录当 State，模型无法可靠调用 Tool。

完成标准：State 结构化、可持久化；Context 可组装、可裁剪；Memory 可审计、可隔离、可过期。

> 旧法不可靠
> 业务受牵连
> 标准要可验
> 边界要清晰

# 03、原理

State 是 Agent 运行时的结构化数据，比如租户 ID、订单号、当前节点、已填槽位。它需要 Checkpoint 持久化，Thread 标识一次会话，Session 标识用户跨线程的边界。

Context 是当前模型可见的 token 序列，由系统提示、Tool 定义、最近消息、RAG 结果等临时组装而成。它不负责长期存储。

Memory 是跨轮次或跨会话的长期信息，必须有来源、过期时间和权限边界。

反直觉判断：聊天记录既不是 State，也不是 Memory，它只是 Context 的一部分原材料。

> 状态是骨架
> 上下文是视图
> 记忆是仓库
> 三者不同源

# 04、架构

```text
[输入] 用户退款请求
    |
    v
[模块] Agent Runtime + StateGraph
    |
    v
[数据/状态] State: {tenant_id, order_id, node, slots} / Thread: conversation_id
    |
    v
[处理] Context Builder 从 State + Memory + RAG 组装当前请求
    |
    v
[输出] 模型决策 -> Tool 调用 -> Checkpointer 持久化 State
```

边界：State 只存运行时结构化数据；Context 是临时视图；Memory 是独立治理的长期资产。收益：可恢复、可审计、可隔离。代价：序列化约束、存储成本、复杂度上升。适用条件：多轮、多租户、需要跨会话的 Agent。

> 输入有租户
> 模块有状态
> 组装有上下文
> 持久有检查点

# 05、实战一次

环境：Python 3.11，langgraph 0.2.50（需按当前官方文档核验）。依赖：langgraph、langchain-core。配置：无需额外服务。

核心实现 V1：用内存字典存 State，模拟重启丢失。

```python
from typing import TypedDict

state_db = {}

class RefundState(TypedDict):
    tenant_id: str
    order_id: str
    node: str
    reason: str

def run(session_id: str, user_input: str) -> RefundState:
    state = state_db.get(session_id)
    if state is None:
        state = {"tenant_id": "t1", "order_id": "ORD-2024-001", "node": "collect_reason", "reason": ""}
    state["reason"] = user_input
    if state["node"] == "collect_reason":
        state["node"] = "verify_order"
    elif state["node"] == "verify_order":
        state["node"] = "check_policy"
    elif state["node"] == "check_policy":
        state["node"] = "issue_refund"
    state_db[session_id] = state
    return state

print(run("s1", "我要退款"))
```

启动：python v1.py。请求：我要退款。验证：输出 node=verify_order。模拟重启：新进程 state_db 为空，再次调用返回 node=collect_reason。

未在当前环境实测，以下为预期结果。

示例输出：

```text
{'tenant_id': 't1', 'order_id': 'ORD-2024-001', 'node': 'verify_order', 'reason': '我要退款'}
```

> 环境要明确
> 实现要完整
> 跑通再暴露
> 问题留后文

# 06、排查

现象：重启后退款流程丢失。怀疑：内存字典。检查：代码中全局 dict。证据：新进程 state_db 为空。根因：State 未持久化。修复：引入 Checkpointer。

**错误尝试：**把聊天记录存入 Redis 就认为恢复了 State。为什么错误：聊天记录无结构，无法可靠恢复订单号和当前节点。

现象：多租户串数据。怀疑：thread_id 无租户隔离。检查：session_id 只用 uuid。证据：A 租户看到 B 租户订单。根因：缺少租户复合键。修复：thread_id = f"{tenant_id}:{conversation_id}"。

现象：长期记忆越权。怀疑：历史消息全塞 Context。检查：Context Builder 无权限过滤。证据：模型引用了其他租户订单。根因：Memory 无权限边界。修复：Memory 带 tenant_id，检索强制过滤。

> 排查有现象
> 怀疑要验证
> 根因要定位
> 修复要隔离

# 07、优化

根因：State 未持久化、thread_id 无租户、Memory 无治理。修改：V2 使用 LangGraph SqliteSaver 作为 Checkpointer；thread_id 使用复合键；Memory 表带 tenant_id、source、expire_at；Context Builder 按权限过滤。

原因：Checkpointer 能按 thread_id 恢复 State；复合键保证租户隔离；Memory 治理保证可审计。新行为：重启后从 checkpoint 恢复；跨租户查询返回空；长期记忆可追溯。验证：模拟重启恢复状态；跨租户检索无结果。

> 优化有依据
> 修改有原因
> 行为有变化
> 验证有证据

# 08、演进

```text
[同一输入]
    |
    +--[V1] 内存字典存聊天记录 / 重启丢状态、串租户
    |
    +--[V2] StateGraph + Checkpointer + Memory治理 / 重启可恢复、租户隔离
    |
[Trade-off]
得到：可恢复、可审计、可隔离
失去：开发复杂度、存储成本、序列化约束
适用边界：多轮、多租户、需要跨会话的Agent
```

比较：正确性提升，稳定性提升，复杂度上升，成本上升，适用范围扩大，遗留问题包括 Memory 检索质量和过期策略。

> 演进有代价
> 取舍有边界
> 适用有范围
> 遗留有清单

# 09、洞见

## 9.1 State是订单，不是聊天记录

反直觉判断：聊天记录不是 State，它只是 Context 的原材料。State 必须结构化，才能驱动流程节点和 Tool 调用。

## 9.2 Context是临时视图，不是存储

反直觉判断：Context 不是 State，它每次请求都要重新组装。把 Context 当 State 会导致重启后无法恢复。

## 9.3 Memory是资产，必须治理

Memory 需要来源、过期时间和权限边界。没有治理的长期记忆会变成越权入口。

## 9.4 Checkpoint是State的时间机器

Thread 是会话边界，Session 是用户跨线程边界。Checkpointer 按 thread_id 保存 State，实现恢复。

## 9.5 多租户隔离要从键设计开始

复合 thread_id 是最小成本、最有效的隔离手段。

> 洞见有依据
> 判断有反直觉
> 治理有边界
> 设计有隔离

# 10、系统落地

原来有什么：内存字典、聊天记录、无租户隔离。本篇新增：State 结构化、Context Builder、Memory 治理、Checkpointer、复合 thread_id。

现在能做什么：重启恢复、跨会话记忆、租户隔离、审计追踪。还缺什么：Memory 检索质量、过期策略、跨区域持久化。下一步：与 RAG、Tool Calling、Trace 结合。

> 落地有新增
> 能力有提升
> 缺口有清单
> 下一步有方向

# 11、小结

```text
Q1 → State用结构化订单+节点，Context是模型可见输入，Memory是跨会话长期信息
Q2 → 用Checkpointer + 复合thread_id，重启恢复
Q3 → Memory带来源、过期、权限，Context Builder过滤
状态 → 多租户客服Agent具备可恢复、可隔离、可审计的状态与记忆边界
```

> 小结有答案
> 状态有边界
> 记忆有治理
> 系统有闭环

# 12、作业

## 12.1 理解题：State和Context的本质区别是什么？

参考答案：State 是持久化的结构化运行时数据，Context 是当前请求临时组装的模型输入。

## 12.2 实战题：用LangGraph实现一个带Checkpointer的退款流程，重启后恢复。

参考答案：使用 SqliteSaver，thread_id=tenant:conversation，State 包含 order_id 和 node。

## 12.3 排障题：多租户Agent串数据，如何排查？

参考答案：检查 thread_id 是否含 tenant_id，检查 Context Builder 是否按租户过滤。

## 12.4 架构判断题：为什么不能把聊天记录直接当Memory？

参考答案：聊天记录无结构、无来源、无过期、无权限，无法治理；Memory 需要独立存储和检索。

> 作业有理解
> 实战有检查
> 排障有方法
> 判断有依据

# 13、思考

State 是骨架，Context 是视图，Memory 是仓库。三者混用，重启就丢，租户就串，记忆就越权。把边界画在持久化和权限上，Agent 才能从 Demo 走向生产。

> 状态定骨架
> 上下文定视图
> 记忆定边界
> 持久定真章

我是老李，在一个多租户全球智能客服 Agent 平台做架构。系统覆盖多企业、多项目、多语言、多渠道，支持 IM、电话、邮件和企业数字人入口，并连接 CRM、订单、支付、物流、工单、知识库。任务是处理退款、改地址、查物流等。

Agent渡劫48关-第7关-State、Context、Memory到底有什么区别？

用订单号与流程节点讲清State、Context、Memory的边界，连接Checkpoint、Thread、Session与持久化，解决重启丢状态和租户串数据

架构师

人工智能

编程语言

架构设计

State、Context、Memory三者边界清晰：State是结构化持久化数据，Context是临时组装视图，Memory是需治理的长期资产。聊天记录仅属Context原材料。核心方案采用LangGraph Checkpointer持久化State，复合thread_id实现租户隔离，Memory表带来源、过期和权限边界。解决重启丢状态、跨租户串数据问题，实现可恢复、可审计、可隔离的生产级多租户Agent架构。

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

State、Context、Memory三者边界清晰：State是结构化持久化数据，Context是临时组装视图，Memory是需治理的长期资产。聊天记录仅属Context原材料。核心方案采用LangGraph Checkpointer持久化State，复合thread_id实现租户隔离，Memory表带来源、过期和权...

Agent渡劫48关-第7关-State、Context、Memory到底有什么区别？-腾讯云开发者社区-腾讯云

Agent渡劫48关-第7关-State、Context、Memory到底有什么区别？

Agent渡劫48关-第7关-State、Context、Memory到底有什么区别？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐