架构设计

原文来源：https://mp.weixin.qq.com/s/tp9H0IR9a4SWBioLMCDehA 架构师（JiaGouX）｜我们都是架构师！架构未来，你来不来？ 最近半年写/用 Agent 的人，大概率都踩过同一类坑：模型未必是瓶颈，系统一"动手"，工程侧立刻露馅。并发乱、状态飘、日志不可读、工具权限没边界、失败不可回放……最后你会发现，提示词再华丽，也兜不住这些问题。 这篇我想把 OpenClaw（Clawdbot）的架构拆开讲清楚。我更关心的是：它怎么把这类系统做得更稳、更可控。 起因是我在 X 上刷到一条关于 Clawdbot 架构的拆解帖。它不是"神话能力"，而是用一套很工程的语言，把组件边界、执行链路、可靠性取舍讲得很清楚。 原帖作者 @Hesamation 的出发点很实在：他想搞清楚 Clawdbot 的记忆系统到底怎么工作、可靠性如何。最后他发现，真正值得学的不是"它能做什么"，而是"它怎么把这些事做得更稳"。 太长不看版（6 条） OpenClaw 的本体是 TypeScript CLI 进程，外加一个负责多渠道接入的 Gateway Server；它不是 Web App。 它把可靠性放在第一位：默认串行，显式并行（lane queue）。并发不是"性能技巧"，先是"可靠性问题"。 Agent Runner 更像一条装配线：模型选择与 Key 冷却、Prompt 组装、历史加载、上下文窗口守护，然后驱动工具循环。 记忆不神秘：JSONL 转录（可回放）+ Markdown 记忆文件（可编辑）；检索用 向量 + 关键词 混合，落在 SQLite（FTS5）。 工具调用的安全边界必须系统化：allowlist + 结构化拦截（重定向/命令替换/子 Shell/链式执行等直接拒绝），别把"自觉"当机制。 浏览器不主要靠截图：用 语义快照（Accessibility Tree/ARIA） 把"看网页"降维成"读结构"，成本更低、成功率更稳。 图 1：原始架构图（原图） 图 2：OpenClaw 核心链路 先把它放回正确的分类：它到底是什么 很多人聊 Agent，一开口就是"自治"“多智能体"“进化”。但落地时，你更需要先回答一句话：你做的是聊天机器人，还是"能在你的机器上执行工具的系统”？ OpenClaw 的定位很明确：它是一个 运行在你机器上的进程，负责三件事： 接收来自不同渠道的消息（Telegram、Discord、Slack 等）。 调用 LLM API（OpenAI、Anthropic、本地模型等）。 在本地或受控环境里执行工具（Shell、文件、浏览器、进程），再把结果回写给你。 这句话看起来朴素，但它把架构重心直接钉死了：执行的可控性、状态的可追溯性、失败的可解释性。 ...

原文来源：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）： ...