> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 智能体分析

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

export const Image = ({img, alt, size}) => {
  return <Frame>
      <img src={img} alt={alt} />
    </Frame>;
};

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

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

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

<div id="agentic-workloads">
  ## 面向智能体工作负载的 ClickHouse
</div>

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

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

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

  <Tab title="数据仓库" icon="database">
    自然语言分析界面 (有时也称为 AI Analyst) 正从实验走向生产环境。
    用户用日常英语提问，并期望在几秒内得到答案。

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

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

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

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

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

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

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

<div id="convergence-dwh-o11y">
  ## 数据仓库与可观测性的融合
</div>

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

<div id="platform-layer">
  ## 平台层：面向智能体的接口与 LLM 可观测性
</div>

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

**面向智能体的接口**

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

**LLM 可观测性**

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