调研报告

原文来源：https://mp.weixin.qq.com/s/jO38bghvaLpjOnQB8aY3uA 作者｜李志宇 博士 编辑｜Kitty 策划｜QCon 全球软件开发大会 随着大模型在企业和行业场景中持续落地，“记忆"正在成为继参数调优和上下文工程之后的下一个工程化核心。短时遗忘、知识碎片化、跨任务信息无法留存等问题，正在限制大模型的个性化、推理链延展与持续演化能力。 本文整理自记忆张量 CTO 李志宇博士在 2025 年 QCon 全球软件开发大会（上海站）的演讲分享。志宇博士结合他多年的研发与落地实践，系统剖析大模型记忆工程的核心技术：记忆分层管理、多粒度调度、可信更新与安全治理，并展示这些技术在金融、工业、知识管理等业务中的应用效果。通过对架构设计、实现细节和案例经验的讲解，帮助开发者与架构师全面理解如何构建具备长期留存与动态调度能力的"有记忆的 AI”，以及它在未来产业智能化演进中的角色与挑战。 预告：将于 4 月 16 - 18 召开的 QCon 北京站设计了「记忆觉醒：智能体记忆系统的范式重塑与产业落地」专题，旨在重新定义企业级记忆系统的未来——聚焦非显式偏好捕捉、记忆自主演化与生命周期管理等前沿方向，探索其在高端客服、个性化助理、企业决策等场景的深层价值。如果你也有相关方向案例想要分享，欢迎提交至 https://jinshuju.com/f/Cu32l5 。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 大模型性能缩放曲线的演进历史 我们公司名为"记忆张量"，单从名字便可看出，我们聚焦的是"记忆增强"——或者说"记忆优化"这一方向。去年十一月刚刚成立，不久前刚完成近亿元人民币的天使轮融资。 之所以选择"记忆"作为主攻点，根本原因在于我们判断：在大模型的演进史中，记忆将成为与 MCP 工具并列的下一个关键增强维度。2023 年以前，业界普遍通过扩大数据规模、参数量和训练量来换取性能提升，由此催生了千问、ChatGPT 等代表性范式。进入 2024–2025 年，人们逐渐发现，单纯堆参数与规模带来的收益开始递减，于是转向"后训练"与"推理增强"，DeepSeek-R1 便是这一阶段的典型产物。当后训练也逼近瓶颈时，Sam Altman 等人开始追问：下一步的突破口究竟在哪里？在 GPT-4 的更新日志里，OpenAI 把"全局记忆"列为令团队"兴奋到失眠"的新功能；而在 GPT-5、GPT-6 的路线图中，“记忆"与"个性化"被反复提及，被视为大模型面向应用场景的核心变量。 从实践层面看记忆增强的必要性 若把大模型业务服务做一次抽象，可自下而上划分为：底层的数据库存储与基础 AI 引擎；中间的 MCP 增强、知识库增强；最上层的业务逻辑。再将视角切换到单个用户与大模型的交互流程，就会发现其中同时存在动态与静态两类信息。所谓动态信息，指随每次查询而变化的个性化内容：用户临时贴入的参考材料、在 prompt 里约定的偏好等。查询一旦发出，模型先进行意图理解与任务规划，再进入信息增强链路——MCP 调用各类动态工具，并返回执行结果、校验信息、汇总结果；与此同时，知识库从预先处理好的企业静态知识中抽取内容，为模型提供补充。最终，响应结果既包含推理过程（think 部分），也包含知识性内容，以及用户对本次回答的点赞或点踩。 若沿着时间轴把记忆类型进一步展开，其复杂度远超直觉。假设我们在第 6 轮对话里需要引用一个月前第 2 轮的内容，又在第 5 轮里引用第 1 轮的细节，就必须保证用户在不同场景下都能准确召回、并同步更新已发生变化的记忆。再把视角拉远：大模型可能在多轮会话、多用户、多 Agent、多 App 之间穿梭，动态信息的量级与管理难度呈指数级上升。因此，我们希望在开发层面屏蔽这些复杂性，让应用开发者无需深陷动态信息的泥沼，从而显著降低落地成本。 ...

执行摘要 本报告从存储管理视角对自动驾驶大数据、多模态数据湖、Agent Infra Memory管理三个领域进行深度融合分析。核心发现是：三个领域本质上都在解决同一类问题——如何在容量、延迟、成本之间取得平衡的分层存储管理问题。 一、存储管理视角的通用抽象 1.1 核心抽象模型：存储器山 (Memory Mountain) 三个领域都可以用经典的"存储器山"模型来统一描述： 访问延迟 ▲ │ ┌─────────┐ <1ms │ │ 寄存器/ │ Context Window │ │ 工作记忆 │ (Working Memory) │ └─────────┘ 1-100ms │ ┌─────────┐ │ │ 缓存/ │ Session Buffer │ │ 短期记忆 │ (Short-term Memory) │ └─────────┘ 100ms-1s │ ┌─────────┐ │ │ 内存/ │ Vector DB + │ │ 中期记忆 │ Structured Store │ └─────────┘ 1s-10s │ ┌─────────┐ │ │ 磁盘/ │ Object Storage │ │ 长期记忆 │ (Long-term Memory) │ └─────────┘ >10s │ ┌─────────┐ │ │ 归档/ │ Cold Archive │ │ 永久存储 │ (Permanent Storage) │ └─────────┘ └──────────────────► 存储容量 1.2 数据/信息的层次化组织对比 维度 自动驾驶大数据 多模态数据湖 Agent Memory管理 L0: 实时流 CAN/DDS Topic流 实时摄入流 Context Window (4K-128K tokens) L1: 热数据 最近采集的ROS bag 热数据缓存 Session Buffer (10-100 messages) L2: 温数据 转换后的Parquet 温数据SSD缓存 Vector Memory + Structured Memory L3: 冷数据 OSS对象存储 对象存储(S3/OSS) 长期记忆存储 L4: 归档 冷归档存储 归档存储 永久知识库 二、分层存储模型的对比映射 2.1 “存储器山"模型的三域映射 +------------------------------------------------------------------+ | 存储器山模型 - 三域对比映射 | +--------------+------------------+------------------+---------------------------+ | 层级 | 自动驾驶大数据 | 多模态数据湖 | Agent Memory | +--------------+------------------+------------------+---------------------------+ | L0: 寄存器级 | Context Window | In-Memory Cache | Context Window (4K-128K) | | L1: 缓存级 | PolarFS Cache | L1 Memory Cache | Session Buffer | | L2: 内存级 | DataFusion | L2 SSD Cache | Vector DB + | | L3: 磁盘级 | OSS对象存储 | S3/OSS对象存储 | Long-term Memory Store | | L4: 归档级 | 冷归档存储 | Archive Storage | Permanent Knowledge Base | +--------------+------------------+------------------+---------------------------+ 2.2 层次之间的对应关系发现 关键发现：三个领域的层次结构高度同构 ...

执行摘要 本报告对Agent Infrastructure（Agent基础设施）领域进行了系统性深度调研，重点关注Memory管理层次模型。通过对LangChain、LangGraph、LangSmith、Zep、MemGPT等主流技术的分析，揭示了Agent Memory从简单会话存储到复杂知识图谱演进的技术脉络。 1. Agent Infra 分层架构 1.1 Agent执行动态追踪（Trace）层 LangSmith 是LangChain团队推出的LLM应用可观测性平台，截至2025年已处理超过10亿条Trace。 核心架构： Frontend (UI) + Backend API + SDK (Python/TypeScript) ↓ ClickHouse (Trace存储) + PostgreSQL (元数据) + Redis (缓存) 定价模式： Developer计划：免费，5,000 traces/月 Plus计划：$39/月/席位 Enterprise计划：支持私有化部署 1.2 Agent Context管理层 Context生命周期： 创建(Creation) → 传递(Transfer) → 更新(Update) → 销毁(Dispose) │ │ │ │ 初始化状态 节点间流转 Reducer合并 会话结束 LangGraph中的Context管理： class AgentState(TypedDict): messages: Annotated[list, add_messages] documents: list[str] counter: Annotated[int, add] 2. Memory管理深度分析（重点） 2.1 Memory层次模型 基于认知科学和计算机体系结构的启发，Agent Memory采用分层架构： ┌─────────────────────────────────────────────────────────┐ │ Working Memory (工作记忆) │ │ Context Window / Active Reasoning │ │ ~4K-128K tokens │ │ ▲ │ │ │ 实时访问 │ ├───────────────────┼─────────────────────────────────────┤ │ ▼ │ │ Short-term Memory (短期记忆) │ │ Session History / Conversation Buffer │ │ ~10-100 messages │ │ ▲ │ │ │ 快速检索 │ ├───────────────────┼─────────────────────────────────────┤ │ ▼ │ │ Long-term Memory (长期记忆) │ │ ┌───────────────┬───────────────┐ │ │ │ Fixed Attr │ Fuzzy Vector │ │ │ │ Memory │ Memory │ │ │ │ (用户画像) │ (Embedding) │ │ │ └───────────────┴───────────────┘ │ └─────────────────────────────────────────────────────────┘ 2.2 短期记忆（Short-term Memory） 工作记忆（Working Memory）： ...

执行摘要 本报告对多模态数据湖领域进行系统性深度调研，涵盖架构设计、存储格式、查询优化、数据治理及业界实践等核心维度。随着AI原生时代的到来，数据湖正经历从结构化分析向多模态AI就绪架构的根本性演进。 一、多模态数据湖架构 1.1 现代多模态数据湖核心架构组件 现代多模态数据湖采用分层解耦架构，各层职责明确： 访问层 (Jupyter/BI工具/ML框架/Agent接口) ↓ 计算层 (Spark/Flink/Trino/DuckDB/PyTorch/Ray) ↓ 表格式层 (Delta Lake/Iceberg/Hudi/Paimon) ↓ 存储格式层 (Parquet/Lance/ORC/Arrow) ↓ 对象存储层 (S3/GCS/Azure Blob/OSS) 核心组件解析： 组件层级 核心功能 代表技术 对象存储层 海量数据持久化、高可用、低成本 Amazon S3, 阿里云OSS 存储格式层 数据序列化、压缩、列式/行式布局 Parquet, Lance, Arrow 表格式层 ACID事务、Schema演进、版本控制 Iceberg, Delta Lake, Hudi 计算层 查询处理、ETL、ML训练 Spark, Flink, DuckDB 访问层 数据消费、可视化、应用集成 Tableau, Jupyter, LangChain 1.2 Data Lakehouse架构特点与优势 Lakehouse核心特征： 开放格式存储：基于Parquet/ORC等开放列式格式，避免厂商锁定 ACID事务支持：通过表格式层实现事务一致性 Schema演进：支持字段增删改，无需重写数据 时间旅行：数据版本回溯，支持可重现分析 统一批流：同一份数据支持批处理和流处理 Lakehouse vs 传统架构对比： 维度 传统数据仓库 数据湖 Lakehouse 数据类型 结构化为主 全类型 全类型 ACID支持 强 无 强 Schema管理 严格 灵活 灵活+演进 性能 高 低 高 成本 高 低 低 AI/ML支持 弱 中等 强 二、存储格式深度分析 2.1 Parquet格式 核心优势： ...

摘要 自动驾驶大数据是驱动智能驾驶技术演进的核心燃料。本报告从数据类型与特征、数据处理流程、技术挑战、主流解决方案和未来趋势五个维度，对自动驾驶大数据领域进行系统性调研，提炼核心洞察，为技术决策提供参考。 一、数据类型与特征 1.1 多模态数据类型全景 自动驾驶系统依赖多源异构传感器数据实现环境感知和决策控制，主要数据类型包括： 数据类型 传感器来源 数据特征 产生频率/规模 图像/视频数据 摄像头（8-12个） 2D视觉信息，含颜色、纹理、语义 30-60fps，每小时72-144GB 点云数据 激光雷达（LiDAR） 3D空间坐标、反射强度 10-20Hz，每小时36-252GB 毫米波雷达数据 Radar（3-5个） 距离、速度、方位角（4D成像） 10-50Hz，数据量相对较小 CAN总线数据 车辆总线系统 车速、转向角、油门/刹车踏板位置 100-1000Hz，结构化数据 DDS Topic数据 ROS2/中间件 传感器融合、决策指令、状态信息 实时流式数据 超声波数据 超声波雷达 近距离障碍物检测 低速场景辅助 GNSS/IMU数据 GPS+惯性测量单元 位置、姿态、加速度 1-100Hz 高精地图数据 预采集/实时构建 车道线、交通标志、拓扑关系 静态+动态更新 1.2 数据规模与产生速率 根据行业研究数据： 单车数据产生量： L2级别：每小时约2TB L4-L5级别：每小时16-20TB 研发阶段单车每日：近10TB 商用阶段单车每日：约2TB fleet级数据规模： 特斯拉：全球近200万辆车，每天提供约1600亿帧视频用于训练 累计数据量：特斯拉已收集超过30PB视频数据（2022年） 训练数据：1000万个精选人类驾驶视频（2023年初） 1.3 数据结构化程度分布 数据类型 格式示例 占比估算 特点 非结构化数据 原始视频、点云、图像 ~70-80% 体量大、处理复杂、价值密度低 半结构化数据 ROS bag、JSON、Protobuf ~15-20% 包含元数据和原始数据的混合 结构化数据 Parquet、CSV、CAN信号 ~5-10% 易于查询分析、价值密度高 关键洞察：自动驾驶数据的"冰山模型"——可见的标注数据和结构化数据仅占小部分，海量的原始非结构化数据才是训练端到端模型的关键。 ...