微信面向 Agentic 的 OLAP 架构探索

01

OLAP 遇见 Agentic：从服务“人”到服务 Agent

Agent 正在广泛进入日常工作，软件交互也从“人操作工具”转向"Agent 自主决策与执行”。其核心能力可以概括为感知、记忆、推理和行动。在这种变化下，OLAP 基础设施的服务对象也开始从“人”向"Agent"延伸。演讲中把 2026 年称为 Agent 元年：模型能力和工程化成熟度同时提升，使“说一句话，让 Agent 去完成任务”逐渐成为新的软件交互方式。

微信目前常见的 Agent 场景包括平台客服、领域助手和智能推荐等。平台客服用于回答用户平台相关问题；领域助手如 AI 志愿助手，可为用户提供领域特定问题分析；智能推荐则通过实时交互获取更个性化的推荐结果。

当访问主体变成 Agent，基础设施面临三个直接问题：传统可观测工具难以描述动态决策过程；多轮与长周期任务依赖高效的记忆存储、检索和召回；Agent 的自动化访问频率高，数据库稳定性与访问保护也变得更加重要。

02

Agent 可观测性探索：从系统监控到决策过程理解

传统可观测面向确定性系统：调用拓扑固定，可以提前埋点，QPS、延迟、错误率等指标也相对明确，HTTP 200 等技术结果通常可以作为成功信号。Agent 则是一段动态决策过程，存在四个结构性盲区：执行路径运行时生成，无法完全依赖预埋点；Token 随上下文增长，成本难以归因；技术执行成功不等于语义结果正确；多轮交互会快速放大 Trace 与上下文数据量。因此，Agent 可观测不只是“监控”，而是“理解“，还要回答走了哪条路、做得对不对、成本花在哪里，以及底层数据存储是否撑得住。

团队采用 Langfuse + OLAP 的方式构建可观测体系。Agent 通过 Langfuse SDK 上报 Trace、Span、Generation、Token、Cost、Score 等数据；Langfuse 提供 Trace 追踪、Evaluation 评估、Prompt/Dataset 管理和成本分析等能力，底层由 ClickHouse 承接高吞吐写入和多维分析。

观测平台可以把一次 Agent 调用的链路、每一步输入输出、工具调用、Token 和延迟呈现出来，使动态过程可视化、可评估、可回放。其中 Evaluation 可以结合 LLM-as-a-Judge 与人工校准判断正确性、完整性等结果质量，Prompt/Dataset 则承接提示词管理、数据集和实验样本。

Agent 可观测数据的典型特征是“海量写入 × 半结构化 × 多维分析”。Trace 中包含大量自然语言文本和 JSON，需要长期留存；metadata、tool calls 等扩展属性变化快；查询又天然带有时间窗口、多维过滤和指标聚合等 OLAP 特征。ClickHouse 通过列存、稀疏索引、多级压缩与冷热分层降低存储成本，PPT 给出的结论是存储成本可降至传统方案的 1/10；同时原生 JSON/MAP 数据类型能兼顾灵活接入和多维查询；查询侧再利用 IO 剪裁、执行引擎以及稀疏索引、主键索引等能力，支撑时间窗口过滤、联合查询和高吞吐指标聚合。

然而，在大规模业务场景下，社区版 Langfuse 存在多方面的瓶颈。首先仅支持 ClickHouse 单分片存储，存储、写入和大数据量查询都受单机能力限制。

接入侧，原有链路依赖 S3 历史数据回放和 RMW 合并更新，容易产生读放大、大量 ClickHouse 点查、Redis ingestion queue 堆积及 S3 上传延迟等瓶颈。

查询侧还存在 Traces 表主键粒度为天级别、按 ID 查询需要扫描一整天，input/output 的 ILIKE 匹配需要全表扫描，以及 traces、observations、scores 多表 JOIN 等问题；推理等场景中的多模态日志，在列存下点查性能也较弱。

针对上述瓶颈，首先做了分布式架构改造，把单分片扩展为支持多分片 ClickHouse 集群，使存储、写入和查询分析在物理上得到分散与解耦，并配合多副本高可用和冷热存储下沉，支撑大规模 Agent 可观测数据。

其次是高吞吐接入链路。针对社区原生链路导入吞吐不佳的问题，团队新增 Proxy 模块，兼容 Langfuse V4 OTel 等接口；PPT 中的链路由 Proxy 接入 Pulsar，再经 Sinker 模块消费 Pulsar 写入 ClickHouse。逐字稿给出的结果是，相比原生导入链路，吞吐提升 10 倍以上。

查询侧则跟进 Langfuse V4，从 Trace-centric 的双实体模型转向 observations-centric 的单实体 Immutable 模型：SDK 上报时将 Trace 公共属性传播到每条 Observation，使查询更接近基于 Observation 的宽表模型，从而减少 JOIN 和更新；同时在内核增加行级索引和后过滤能力，提升多模态等场景的点查性能并降低不必要的 CPU 消耗。

Trace 数据不仅用于观测，也会用于 SFT 监督微调和模型蒸馏训练。由于 Langfuse SDK 版本和接口较多，不同用户的上报格式容易不统一，团队因此制定规范化上报标准和上报 SDK，并提供上报文档 Skill，让 AI 按规范生成上报代码，便于后续数据利用。

03

Agent 记忆底座探索：从 OLAP 数据库到远程记忆服务

记忆的核心作用，是把历史信息变成当前决策可用的上下文。用户请求进入后，系统从短期和长期记忆中召回当前任务状态、历史事件、用户偏好等信息，组装到 Prompt 中，再交给模型推理和工具调用。这样才能实现跨轮次连续服务、个性化、历史结果复用，以及经验和反馈的持续沉淀。

生产级 Agent 的记忆通常包含四层：短期记忆记录当前对话、任务状态和中间结果；Skill 描述一类任务的步骤、规则和工作流；Mem0 负责判断哪些信息值得记住、更新和召回，典型内容包括用户事实、偏好和历史经历；Memory Storage 负责长期记忆的持久化。算法更关注记忆如何提取、筛选和更新，基础设施侧则重点解决存储和服务能力。

大规模 Agent 通常运行在沙箱中，实例可能销毁、重启、扩容或迁移，但记忆不能随实例消失；多个 Agent 也常需要共享文档、规则、代码或 RAG 语料。因此需要远程存储保证记忆持久化，并让不同实例能够访问同一份数据。

团队在 OLAP 数据库基础上引入 BM25 全文检索、ANN 向量检索及混合检索能力，并结合 OLAP 原生的聚合分析和综合排序能力，使语义检索与结构化检索可以在一套 SQL 分析体系中完成，单条 SQL 即可完成复杂过滤、检索、统计和排序。

对于亿级向量数据，又引入基于磁盘的 DiskANN：通过 PQ 量化压缩向量，将压缩后的向量放在内存，graph 和全精度向量放在 SSD。PPT 中的对比显示，相比 HNSW，内存占用降低 90% 以上，QPS 约降低 40%。

面向多 Agent 在线服务，团队基于微信后台框架设计高 QPS 路由架构，按 Agent 做哈希路由，使不同 Agent 的请求落到不同节点，减少相互干扰；同时支持精细化限流、水平扩容以及副本间读写分离，以满足高 QPS、低延迟和稳定性要求。

在存储底座之上，服务形态主要有两种。一种是 Memory API/SDK，提供通用的记忆更新、删除和访问接口，远程存储直接使用 OLAP 向量数据库。另一种是面向文件系统的记忆服务，因为文件系统和命令行是 Agent 沙箱更自然的上下文访问接口，可减少 Agent 学习新 API 的成本。

基于 OLAP 数据库的记忆服务把前面扩展的向量检索、全文检索、混合检索等能力统一在一层 Query/Pivot 之下，再通过通用 Memory API 提供给 Agent 使用。

文件系统方案以 OLAP 向量数据库作为远程存储，通过 FUSE 将数据库操作封装成文件系统访问，并挂载到 Agent 沙箱中，Agent 无需学习 SQL 或复杂数据库 API，就可以像读写文件一样访问上下文与记忆。

在文件视图上，系统通过 OverlayFS 支持 User、Group、Agent 三层目录树，通过不同的（User, Group, Agent）组合得到不同目录视图，并按照上层覆盖下层的规则合并为沙箱内统一的目录树。演讲中提到，多个 Agent 共享的记忆可放在 Agent 层，个性化记忆可放在 User 层。问答环节还补充了本地缓存机制：文件系统存在 base/delta 分层，delta 层使用本地 SQLite 缓存；访问优先读取本地，未命中再拉取远端，更新先写本地，再主动 push 到远程。

04

Agent 访问保护：从“人”访问到"Agent"访问

过去“人”访问数据库通常是有限次、有意图、可追责的慢操作；Agent 访问则可能是无限次、按规则自动执行、难归因的操作，一个很小的错误也可能被瞬间放大。同时还会带来过度授权、SQL 注入与恶意载荷、审计追责困难和隐蔽数据泄露等风险。

核心思路是把 Agent 当“人”看。每个需要访问数据库的 Agent，都先在上游注册身份并获取数据库访问权限；后续访问携带相应的身份信息和动态票据完成权限认证，并上报审计日志。系统还可以基于身份进行默认限流，对异常访问进行快速封禁和拦截。

05

问答环节

Q1：Langfuse 只能单分片部署，如何改成多分片？

基于 Langfuse V4 版本做了一个整体架构升级，上述接入链路可以直接 Hash 接入多分片的 ClickHouse 集群，团队还适配了 Langfuse Web 的查询，使其访问分布式表，并按项目进行分库分表和权限管控。

Q2：文件系统的记忆存储如何实现？

底层以 OLAP 作为远程存储，通过 FUSE 封装成 AgentFS 并挂载进 Agent 运行的沙箱；读文件等操作会被翻译为数据库访问。为降低全部走远程带来的延迟和带宽开销，文件系统采用 base/delta 分层，delta 层使用本地 SQLite 缓存，未命中再拉取远端，更新则先写本地再主动 push 到远程。