月底账单出来了，模型费用是预估的 3 倍。但当你打开可观测系统排查，从延迟、错误率到调用量，所有指标都挑不出毛病。钱显然花出去了，但没有一个工具能告诉你，花在了哪里，为什么。
以一次服务器巡检为例。用户让 Agent 完成全面巡检并给出处理建议。这个任务实际经历了四个阶段：需求对齐、方案确认、多工具执行、结果探索。从用户单向下达指令，到 Agent 自主调用工具，再到双方围绕结论反复追问，上下文在每一轮对话中持续膨胀。
但打开可观测系统，你看到的只有一条 200 的请求记录。延迟正常，错误率为零，一片绿灯。Agent 走了什么路径、调了哪些工具、结论是否可靠，无从得知。
不是系统坏了，而是它从未被设计来观测这类场景。
传统可观测工具并非不够好，而是为另一种系统设计的。APM 和链路追踪之所以在微服务中有效，是因为请求路径在部署时就已确定，监控系统沿着既定路线采集即可。Agent 的工作方式完全不同，将传统工具直接套用，会暴露出四个结构性盲区。
动态路径。 Agent 的执行路径是运行时生成的，每次运行都可能是一条全新的路，无法提前埋点，也无法用预定义的链路拓扑来追踪；
成本不透明。 每一次模型调用都在消耗 Token 预算，上下文随对话轮次滚雪球式增长。三轮对话下来成本可能翻数倍，但你只看得到一个总数，无法归因到具体哪一步；
静默偏差。 Agent 可以在技术层面完全正常地返回一个错误的结论，状态码 200，延迟达标，没有异常日志，但用户已经被误导。系统从未被设计来判断一个回答在语义上是否正确；
多轮交互。 Agent 的工作建立在持续累积的上下文之上，每一轮对话都在注入新的信息，文本量急剧膨胀。当上下文窗口增长到数万 Token 时，传统的采集和存储方案在数据量与查询性能上都难以支撑。
这四个盲区相互叠加：路径不可追踪导致成本无法归因，成本无法归因使静默偏差更难被发现，多轮交互又将一切放大。要解决这些问题，需要的不是在现有工具上修补，而是一套为 Agent 重新设计的可观测范式。
面对上述盲区，最直觉的反应是升级工具，采集更多指标，部署更细的埋点。但这条路走不通，因为问题不在于采集能力不足，而在于观测维度本身就错了。
传统可观测体系关心三件事：服务是否在线、响应是否够快、请求是否成功。在确定性系统中这就够了，因为"请求成功"和"结果正确"基本是同一回事。Agent 打破了这个等号：一个请求可以在技术上完全成功，在语义上彻底失败。
这意味着 Agent 可观测需要回答一组全新的问题：
Agent 走了哪条路？ 执行路径是动态生成的，系统必须能在事后完整还原每一次运行的实际链路，而非依赖预定义的拓扑；
Agent 做得对不对？ 状态码和延迟衡量的是"有没有完成"，而 Agent 场景需要判断的是"做得好不好"。系统需要具备语义层面的评估能力，识别那些看起来成功、实际上错误的输出；
钱花在了哪里？ Token 消耗随上下文逐轮累积，成本可以在几轮对话内翻数倍。系统需要将费用归因到每一个 Session、每一轮对话、每一次模型调用，而非月底给你一个总数；
数据撑得住吗？ 多轮交互产生的 Trace 和 Token 事件远超传统场景，存储和查询方案必须同时解决性能与成本的问题。
这四个问题，就是衡量一套 Agent 可观测体系是否有效的标准。
上一节提出了 Agent 可观测的四个核心问题。ClickHouse + Langfuse 的组合，正是为回答这些问题而设计的，Langfuse 负责链路追踪与质量评估，ClickHouse 提供高性能存储与分析底座，二者结合，将 Agent 的每一次决策从不可见变为可解释、可归因、可改进。
可观测的第一步，是让数据先被看见。Agent 产生的 Trace、日志、指标与 Token 消耗，通过 OpenTelemetry 统一采集后写入 ClickHouse。列式存储加高压缩比，海量数据下依然亚秒级响应。
数据落地后，提供两条互补的观测路径。Grafana 面向运维团队，支持构建深度自定义的监控大盘：Token 用量分布、上下文增长趋势、延迟热力图、高风险 Session 排名，配合告警规则，异常发生即可感知。Langfuse Dashboard 面向业务团队，开箱即用地展示 Trace 数量、成本趋势、模型调用分布等核心视图，无需额外配置，不用跳出工作流就能掌握 Agent 运行状态。
同一份数据，两个视角，运维看全局，业务看重点。
链路追踪是 Agent 可观测的核心。Agent 的执行路径是动态生成的，如果拿不到完整的链路数据，成本归因、质量评估、问题定位都无从谈起。
Langfuse 提供了一套五层结构的追踪模型：User → Session → Trace → Generation → Span。这五层对应两个观察视角。
宏观视角：看清故事全貌。回答"谁、在什么场景下、花了多少、做了什么"。
从 User 出发，能看到一个用户的完整行为轨迹；下钻到 Session，能看到一次对话跨越多轮的 Token 累积与成本增长；再到 Trace，能看到单次请求的耗时、花费与执行结果。
以服务器巡检为例。一个用户在一次巡检工作 Session 中发起了三次 Trace，第一次表达"我想巡检这台机器"，第二次明确"公网可达，无备份，均衡模式"，第三次要求"一步步安全审计"。三次对话下来，Token 从 14.8K 滚到 30.6K，单次请求成本随之翻了 5 倍。宏观视角让你一眼看到这个雪球是如何滚起来的。
微观视角：还原执行现场。回答"Agent 具体做了什么、每一步花了多少、问题出在哪里"。
进入具体的 Trace 内部，可以看到它由多个 Generation 和 Span 组成：每个 Generation 记录了一次模型调用的完整 Prompt 与输出、耗时与 Token 消耗；每个 Span 记录了一次工具调用的入参、返回与执行时间。
继续上面的例子。第三次 Trace 内部展开了 11 个 Generation，每一步都被完整记录：理解指令并拆解为 7 个执行步骤（$0.002）、确认当前用户身份（$0.0007）、检查各用户文件数量（$0.004）……直到最后一个 Generation 综合所有步骤生成完整安全风险报告，Token 爆发至 30,571，单步花费 $0.060。每一个 Span 都可追溯到具体调用了哪个工具、传入了什么参数、返回了什么结果。
两个视角结合，Agent 的执行过程从一条不可见的黑箱路径，变成了一段有起点、有分支、有决策、有代价的完整故事。一个目的，多轮交互，从用户到 Span，每一步都有迹可循。
有了完整的链路数据，下一个问题是：怎么判断 Agent 做得好不好？
传统 Trace 质量评估关心的是"请求有没有完成"：状态码 200、延迟达标、日志里没有 error，就算通过。但这套标准在 Agent 场景下会失效：Agent 可以在技术层面完全正常地返回一个低质量的结论——格式工整、语气自信、没有任何异常，但事实错误、逻辑缺失、关键检查项遗漏。
Agent 场景真正需要评估的维度复杂得多：执行完整性（是否真正完成了每一步）、推理正确性（结论是否有逻辑支撑）、工具调用质量（工具结果是否被正确使用）、语义相关性（输出是否真正回答了问题）等。这些维度没有标准答案，规则无法穷举，人工标注成本又高到无法规模化。
Langfuse 给出的解法是双轨评估机制。
LLM as a Judge 自动评分。 由一个独立的大模型阅读完整的 Trace，按预设维度自动打分：完整性、正确性、有害性、一致性、幻觉检测、上下文利用率等十余个维度可以并行评估。整个过程无需人工介入，可以对所有 Trace 全量覆盖，实现真正的规模化质量监控。
人工标注校准。 关键样本由业务专家审阅，对 LLM 的自动评分进行纠偏，确保评估标准随业务演进持续对齐。LLM 保证覆盖面，人工保证准确性，两者互补。
这套机制能够识别传统监控无法发现的问题。同样是 HTTP 200 的成功响应，背后的完整性评分可能天差地别：一个发现了漏洞但建议不完整（0.20），一个只规划了方案没有执行工具（0.65），一个多步执行并输出了完整风险报告（0.95）。从指标看毫无差别，从质量看天壤之别。
评估结果以分数的形式直接附着在每条 Trace 上，和链路数据、Token 消耗共同构成 Agent 的完整画像。质量不再是一个模糊的主观判断，而是一个可以被追踪、被对比、被持续优化的量化指标。
Agent 的成本问题有两层：一层是 Token 花在哪里看不清，另一层是承载这些数据本身就要花钱。
第一层由 Langfuse 的链路追踪解决，每一次模型调用的 Token 消耗都精确落到 Generation 和 Span 上，成本可以逐层归因到 User、Session、Trace、模型，甚至单个工具调用。账单不再是月底才能看到的一个总数，而是一个随时可以下钻的结构化数据集。
第二层，就是 ClickHouse 的价值所在。
Agent 可观测面对的是典型的海量写入、高频查询、长期留存场景。Trace 事件、Token 级明细、多轮对话上下文，规模随使用量线性增长。传统数据库在这种负载下要么性能崩塌，要么存储费用高到离谱，"可观测"本身变成了新的成本黑洞。
ClickHouse 从底层解决了这个矛盾。
极致查询性能。 公开基准测试（JSONBench）显示，在同等硬件条件下，ClickHouse 的数据加载速度比 Bigquery、Elasticsearch 等主流方案快 37 倍，查询速度快 20 倍。数千万级的 Trace 按模型、按 Session、按时间窗口做多维聚合依然保持亚秒级响应，在 Dashboard 上拖动时间轴、切换筛选条件的体验是实时的。
极致存储成本。 ClickHouse 通过四层优化将存储成本降至传统方案的 10%：去掉正排行存节省约 40% 空间，稀疏索引替代倒排索引使索引体积下降 80%，ZSTD 压缩叠加 Delta 与 LowCardinality 编码大幅提升压缩比，热数据放 SSD、冷数据沉降到对象存储，冷数据的单位空间成本可降至热数据的 1/50。长期留存历史 Trace 用于复盘和趋势分析，不再是一笔需要犹豫的开销。
原生 JSON 列式存储。 ClickHouse 原生支持 JSON 列式存储，将文档按字段自动拆分成独立的列，这对 OpenTelemetry 采集的数据尤为关键：一次模型调用的 usage、cost、content 等字段嵌套层级深、结构灵活，ClickHouse 在查询时只读取用到的字段，既保留 JSON 的灵活性，又获得列存的性能与压缩优势，避免了传统方案"要么解析成表、要么整块存字符串"的两难。
极致性能让每一次成本归因查询都能秒级响应，极致存储让长期留存成为可负担的默认选项，原生 JSON 让半结构化的 Agent 数据无需预建模就能高效分析。三者共同构成了 Agent 可观测体系的经济基础：只有底座足够便宜、足够快，Token 级归因才不会停留在口号上。
前面四节解决的是"数据怎么采、怎么存、怎么看"。但还有最后一步，谁来看？
传统可观测体系的使用者是运维工程师。他们打开 Dashboard、写 SQL、调整告警阈值，靠经验从海量指标中捕捉异常。但在 Agent 场景下，数据规模和维度都远超人力处理的边界：成千上万条 Trace、数十个评分维度、逐层嵌套的 Token 消耗，靠人盯、靠人查，很快就会力不从心。
更自然的方式是：让 Agent 自己来读这些数据。
ClickHouse 提供了官方的 MCP Server，将数据库的列表、Schema 查询、只读 SQL 执行等能力封装成标准的 MCP 协议接口。任何支持 MCP 的 Agent 客户端或框架，Claude、Cursor 等对话客户端，LangChain、Claude Agent SDK、OpenAI Agents SDK、CrewAI 等开发框架，都可以通过一次配置直接接入，让 Agent 具备查询 ClickHouse 的原生能力。
LibreChat 是一个典型的落地示例。作为开源的多模型对话界面，它通过 MCP 协议直接连接 ClickHouse，让运维、业务、分析人员都能用自然语言完成查询、可视化和归因分析，不需要写 SQL，也不需要切换工具。
用自然语言查数据。 "帮我检查一下 openclaw1 这个数据库下都有什么数据"，Agent 自动调用 list_databases 和 list_tables，返回完整的数据库概览，连同每张表的用途、字段数、分类都整理清楚。不需要记 SQL，不需要切到 DBA 工具，对话即查询；
用自然语言做 Dashboard。 "从成本、行为、安全三个维度帮我整理一份 Dashboard"。Agent 自动补齐关键数据查询，生成完整的 HTML Dashboard，包含成本分析、行为指标、安全告警与风险评分。从"想看什么"到"看到什么"，中间不需要 BI 工程师；
用自然语言定位问题。 当 Dashboard 出现异常波动时，不必手动写 SQL 逐层下钻，直接把问题抛给 Agent，"P99 延迟为什么在昨天下午突然上升？"。Agent 结合 Trace 数据、Token 消耗、工具调用链给出归因分析，甚至主动提出修复建议。
这是整个方案的闭环点：Agent 产生的数据，最终又由 Agent 自己读取、分析、呈现。可观测体系从"给人看的工具"升级为"给 Agent 用的能力"，数据不再需要翻译成图表才能被理解，问题也不再需要拆解成 SQL 才能被回答。Agent 自己读懂自己的数据，是 Agent 时代可观测体系最自然的终点。
回到开篇那个场景：月底账单是预估的 3 倍，打开监控大盘却一片绿灯。
现在，这个困境有了答案。打开 Grafana，你能看到 Token 消耗在哪个时间段突然翻倍；切到 Langfuse，你能定位到是哪个 Session 的上下文滚成了雪球；展开 Trace，你能看清 Agent 在第几个 Generation 做出了错误决策、调用了哪些工具、输出了什么结果；LLM as a Judge 的评分告诉你那份报告的完整性只有 0.20，远不是"状态码 200"所暗示的那样。而这一切，你甚至不需要自己写一行 SQL。把问题直接交给 Agent，它会读懂这些数据，给出归因与建议。
从"浑然不知"到"每一步有迹可循"，改变的不只是工具，而是认知方式。Agent 可观测的本质，不是监控更多指标，而是让 AI 系统的每一次决策都可解释、可归因、可改进。ClickHouse + Langfuse 的组合之所以成立，正是因为它同时提供了这三件事所需要的底座：足够快的查询让归因随问随得，足够省的存储让长期留存成为默认，足够开放的接口让 Agent 自己也成为使用者。
当可观测系统开始理解 Agent，Agent 才真正开始被信任。
好消息：ClickHouse Shanghai User Group 第 3 届 Meetup 火热报名中，将于 2026 年 5 月 16 日在上海市浦东新区世纪大道 1568 号中建大厦 33 层 Optiver 上海 举行，扫码免费报名：
/END/
面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出 &图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。