智能体分析

了解 ClickHouse 如何赋能智能体分析

AI 工作负载无论具体用例如何，通常都会有一组共同要求：

• 高查询并发
• 亚秒级响应时间
• 大规模全保真数据

本文将说明 ClickHouse 如何在实时分析、数据仓库和可观测性等场景中满足这些要求，以及这些用例如何逐步汇聚为面向智能体应用的统一数据平台。

​

面向智能体工作负载的 ClickHouse

实时分析

AI 驱动的应用功能，例如生成洞察、异常检测、推荐，以及面向产品数据的自然语言接口，都需要在事务写入和分析读取之间建立紧密的反馈闭环。 其标准架构是 Postgres + ClickHouse：

• Postgres 负责事务和应用状态，ClickHouse 负责分析。
• ClickHouse 提供快速摄取、针对数十亿行数据的亚秒级查询，以及面向客户应用所需的并发能力。

随着应用越来越具备智能体能力，这种组合也变得更加关键。 智能体必须持续查询实时产品数据，这会同时提升查询频率和并发度。 ClickHouse 通过原生的 Postgres + ClickHouse 集成来解决这一问题，提供自动数据复制和统一的开发者体验，无需再管理单独的 CDC 管道。

数据仓库

自然语言分析界面 (有时也称为 AI Analyst) 正从实验走向生产环境。 用户用日常英语提问，并期望在几秒内得到答案。

这对基础设施的含义在于：一条自然语言查询不会只生成一条 SQL 查询——通常会在短时间内连续生成数十条，因为智能体需要探索可用数据集并评估多条推理路径。 因此，内部分析师工作负载在并发和延迟特征上，开始越来越像面向外部客户的工作负载。

传统数据仓库是为低频、批处理式查询而设计的。它们优化的是大量查询下的整体吞吐量，而不是高并发下的亚秒级响应时间。在这种架构上运行 AI Analyst 工作负载，要么会带来不可接受的延迟，要么成本增长速度快于其创造的价值。

ClickHouse 从一开始就是为高并发交互式查询而构建的：可支持 PB 级数据、数千并发用户，以及针对数十亿行数据的亚秒级响应时间。

可观测性

传统可观测性技术栈建立在三个彼此分离的支柱之上——指标、日志和链路追踪——并通过对数据进行预聚合和采样来控制存储成本。对于人工主导的工作流，这种权衡可以接受，但对 AI SRE 来说却行不通。 自动化事件分诊、根因分析和异常关联需要细粒度、高基数、长保留周期的数据。一个 AI 智能体如果要将某种错误模式与三天前的一次部署事件关联起来，就无法依赖采样日志或降采样指标。

支撑 AI SRE 的架构，是以存储在列式存储中的宽结构化事件为基础的单一事实源。全保真事件只存储一次，而指标、链路追踪和 SLO 都是在查询时从中派生，而不是在摄取时预聚合。 ClickHouse 非常适合这种模型：

• 对日志和事件数据提供高压缩
• 针对高基数宽事件提供亚秒级查询
• 能以生产基础设施规模高效摄取
• 成本模型基于算力和存储，而不是按每 GB 摄取收费

ClickStack 是 ClickHouse 基于这一模型构建的可观测性技术栈，并使用 OpenTelemetry 作为数据采集层。 它既提供开源版本，也提供托管服务。

​

数据仓库与可观测性的融合

长期以来，数据仓库和可观测性一直是彼此独立的领域，各自对应不同的供应商、采购方和技术栈。而如今，这种分离越来越像是一种沿袭下来的惯例，而非技术上的硬性要求。 如今，这两个领域都会将数据写入对象存储。两者都要求在高并发下实现交互式、低延迟的查询。而在数据层面，同一类事件往往会被存储两次——一次在可观测性平台中，一次在数据仓库中——两者之间还隔着一层脆弱的同步机制。 如果将所有这些数据以开放格式统一存储一次，并让 AI Analyst 和 AI SRE 工具都能直接查询，就可以消除这种重复，并让两类工作流共享同一上下文。

​

平台层：面向智能体的接口与 LLM 可观测性

除了数据库，还需要另外两个组件，才能构建完整的智能体分析平台。

面向智能体的接口

当 AI 智能体成为数据交互的主要入口时，数据平台需要以智能体可消费的方式提供其能力——兼容 MCP 的 API、自然语言接口，以及无需针对每个用例单独定制的智能体框架。Agentic Data Stack 将 ClickHouse 与 LibreChat 结合，提供了一种开箱即用的方式，可在你的数据之上部署分析智能体。

LLM 可观测性

随着智能体日益普及，追踪其执行过程、监控模型性能、跟踪成本，以及调试多步骤工作流中的故障，已成为核心工程需求。Langfuse 运行在 ClickHouse Cloud 之上，提供可大规模扩展的实时 LLM 可观测性。