ClickStack MCP 服务器基准测试：故障排查准确率提升 18%

本文字数：8714；估计阅读时间：22 分钟

作者：Brandon Pereira

编者按：本文译自 ClickHouse 原博客。 原文围绕「探讨 AI 代理在可观测性领域的结构化评估方法」展开。该测试量化了 MCP 协议在故障排查中的效能优势，并为评估 AI 代理在特定垂直领域的表现提供了可复现的基准框架。

上个月在旧金山举办的 Open House 上，我们发布了 ClickStack MCP server。这是一套专用的可观测性工具，为 AI 代理调查生产环境故障提供结构化的高级原语（primitives），从而无需手动编写原始 SQL。我们在会上分享了 ClickStack MCP 与通用 ClickHouse SQL 接口的初步基准测试对比结果：在定位根本原因和给出修复方案上，准确率提升了 18%；工具调用次数减少了 26%；且多次运行的结果一致性提升了 2.4 倍。

这些数据引发了不少关于测算方法的疑问，因此这里详细说明我们的具体做法。

推出供 AI 代理调查生产环境故障的 MCP（模型上下文协议）工具，也引入了一种新的风险。同一个问题问两次未必能得到相同的答案；此外，工具重构、参数重命名或查询逻辑的修改，都可能悄无声息地导致排查质量下降。如果没有结构化的衡量方法，就很难察觉这些问题。

我们需要验证两个问题：第一，新版 MCP 的故障排查效果是否优于旧版；第二，MCP 的表现是否真的比直接通过 SQL 查询 ClickHouse 的代理更好。为此，我们构建了hdx-evals。这是一个可复现的基准测试框架，它会注入完全相同的合成遥测数据，在不同配置下运行 Claude 代理，并对各方案的运行结果进行盲测评分。由于该框架会遍历 MCP 与模型的所有组合，我们还得到了一个额外的好处：每当新模型发布时，我们可以直接用hdx-evals在相同场景下测试其表现，再决定是否要将其投入生产环境。

hdx-evals现已开源，代码托管在 HyperDX 仓库中。如需对照代码阅读，请访问 github.com/hyperdxio/hyperdx/tree/main/packages/hdx-eval。

ClickStack MCP 与 ClickHouse MCP 对比

在介绍基准测试场景之前，我们先简要回顾一下，为什么要在 ClickHouse MCP 之外再专门构建一个 ClickStack MCP。如果你已经清楚两者的区别，可以直接跳到后面的故障场景部分。

ClickHouse MCP 允许 agent 通过 SQL 直接访问 ClickHouse。这种方式很灵活，但需要模型自行发现 schema、构建每个查询并组装多步调查工作流。在可观测性调查中，这会导致多余的工具调用、低效的查询、高基数结果，以及每次运行时的处理方式不一致。

相比之下，ClickStack MCP 针对常见的可观测性任务提供了更高层面的语义工具，例如查找重复事件模式、比较时间窗口、识别异常值，以及在日志和链路之间跳转。这些工具底层依然执行 SQL，但封装了查询逻辑，并返回便于 agent 处理的结构化结果。其目标是提高准确性和一致性，同时减少工具调用与常见查询错误。以下场景测试了这些优势是否适用于不同类型的调查。

故障场景

基准测试的质量取决于其测试的故障场景。如果场景过于干净，每个 agent 都会表现得非常出色。如果场景太脱离现实，测试结果就无法反映 MCP 在生产环境中的真实表现。

因此，每个hdx-evals场景都模拟了一次真实的故障：包含数千万条合成的日志和 span。数据采用固定的随机种子生成，确保每次运行的初始数据完全一致；真实的噪音数据中埋藏了预设的异常，同时还加入了干扰项——即在时间点和文本描述上伪装成真正问题的次要错误。如果 agent 看到第一个错误就立刻下结论，它将无法通过测试；而基于数据进行推理的 agent 则不会失败。

这些数据完全是合成的，并非来自 OpenTelemetry Demo、现有产品或真实的遥测记录。公开数据集通常包含大家熟知且记录详细的故障模式，它们可能已经存在于模型的训练数据中。重复使用这些数据可能导致 agent 直接认出熟悉的故障，而不是利用现有工具去开展调查。因此，生成原创场景有助于我们测试 agent 的实际调查能力，而非它已有的知识。

在 TypeScript 中，Trace 和日志由设定种子的伪随机数生成器（PRNG）确定性地生成，并直接写入 ClickHouse 表中，表结构与 ClickStack 真实的 OTel schema 保持一致。拓扑结构视场景而定，从单一的api-server，到多达 25 个命名的电商服务，外加约 100 个程序生成的后台服务以增加基数（cardinality）。数据量经过刻意设计：单在error-root-cause场景中，就在超过 1200 万个 span 和 1200 万条日志中，仅植入了 8 条失败的 trace。因此，该评估衡量的是 agent 能否在健康的数据基线之上，从相似的干扰项中分离出微小的植入故障，而不是单纯测试其统计错误的能力。

我们共构建了五个场景，分别考察不同的问题排查能力：

• error-root-cause 是一次由支付服务数据库超时引发的结账服务 500 错误，该问题隐藏在 25 个服务、2400 万条 span 和日志中。这里设置了 6 个干扰项，其中包括数据量达真实信号 10 倍的 CDN 错误激增，用来误导那些一上来就查询 WHERE StatusCode = 'ERROR' 的 agent。

• latency-spike 是因缺少索引导致的 p99（99 百分位延迟）恶化，仅影响企业租户，该问题埋藏在 5000 个租户的 2000 万条 span 中。其中设置了一个特性开关混淆项，它与受影响群体有 80% 的相关性但无因果关系；同时在同一时间窗口内，还在无关端点上设置了一个具有相同延迟范围的干扰项。

• noisy-signals 要求 agent 找出可被丢弃或限流的日志，以降低数据采集与存储成本。该数据集包含 1600 万条日志。每种数据量大但价值低的日志模式，都与来自同一服务、同一严重级别且同样常见却很关键的模式成对出现。例如，直接丢弃 notification-service 的所有 DEBUG 日志，不仅会删去常规的缓存命中消息，也会一并删掉用来确认通知发送状态的投递记录。

• service-health-check 是一份长达四小时、单一服务的数据集，包含 3600 万个事件，且未发生任何故障。agent 必须按比例提取出 4 个细微的新信号，同时不能对 2 个重复出现的模式触发告警。这项测试与其他测试同等重要，因为优秀的基准测试不仅要奖励正确的答案，也要惩罚看似笃定实则错误的结论。

• segmented-regression 是涉及 600 万条 trace 的错误激增，仅在两个维度（企业层级和缓存未命中）的交集处才会出现。单一维度无法暴露该问题，因此 agent 必须进行交叉比对才能发现。这是一个教科书级别的辛普森悖论场景。

以noisy-signals为例。agent 必须判断在 1600 万条日志中，哪些可以被丢弃或限流且不会丢失关键的运维信息。在notification-service DEBUG日志中，一半是常规的缓存命中消息，可以安全删除；另一半则记录了通知投递情况，必须作为审计轨迹保留。

这两类日志的服务和严重级别相同，因此仅按这些字段过滤无法将其分开。按完整的日志消息分组也无济于事，因为消息内的值差异很大。Agent 必须将相似的消息归类为模式，然后将无关紧要的缓存日志与关键的交付记录区分开来。该场景测试了 MCP 的事件模式工具能否让 Agent 找到正确的处理方法。

遥测数据的设置与初始化

在 Agent 开始处理事件之前，hdx-evals会分三个阶段构建 ClickStack 环境：资源配置（provisioning）、模式（schema）和数据生成。

资源配置阶段会创建评估账号、连接和数据源，以及分别面向 ClickStack MCP（基于 HTTP）和 ClickHouse MCP（基于 stdio）的 MCP 服务器定义。系统设置了包含 11 种非排查工具（如仪表盘、告警和已保存的搜索）的黑名单，确保 Agent 仅专注于查询工具。所有配置都会写入同一个eval.config.json文件，且该过程是幂等的，可以安全地重复运行。

模式阶段会创建评估表，作为 ClickStack 生产环境 OTel 表的结构克隆（CREATE TABLE ... AS default.otel_traces），因此它们直接继承了真实的模式、引擎和索引，而非近似结构。每个场景包含六张表：原始追踪和日志表，以及由两阶段物化视图流水线构建的汇总表，该流水线与 ClickStack 生产环境的元数据发现路径完全一致。这意味着当 MCP 询问“存在哪些字段”时，查询会命中预聚合的汇总表而非扫描原始数据——这也与 ClickStack UI 中实现自动补全和分面（facet）生成的优化机制相同。你可以在 ClickStack 文档中了解这些物化视图的更多工作原理。

数据生成阶段负责写入实际的遥测数据。所有随机性均由单一且带种子的伪随机数生成器（PRNG）控制，因此只要种子和基准时间固定，就能始终生成字节级完全一致的数据。每次运行的数据集保持不变，这让不同 MCP 之间的 A/B 对比具备了实际意义。数据会分批以流式传输，即便在处理数百万行数据时也能有效控制内存占用。

每个场景都会使用固定的“当前”时间，连同指令一起传递给 Agent。这能确保诸如“过去 10 分钟内”之类的表述始终指向预置数据中的相同时段，无论评估在何时运行。因此，数据集只需生成一次即可重复使用；每次运行前，框架会检查数据集是否存在，并在需要时创建。

运行器

数据预置完成后，hdx-evals会为每个 (MCP, model, run) 组合启动一个真实的 Claude Code 进程，让它像 SRE 那样去排查场景。过程中没有任何辅助脚手架或提示，只有问题和工具。

每次运行都会分配一个专属沙箱：一个全新且用完即弃的临时目录、一个单一的 MCP 服务器定义（仅限当前评估的服务器），以及一份移除了除排查工具外所有内容的工具权限文件。沙箱不提供 bash、写入、编辑、文件匹配（glob）或网络抓取（webfetch）功能，且读取权限仅限于当前运行的临时目录。这并非我们心血来潮的防范举措。在早期迭代中，我们发现 Claude 会在文件系统中四处翻找，试图寻找先前的运行输出、评分标准或标准答案——实际上它是在找捷径作弊，而不是去排查问题。将每次运行锁定在专属的一次性隔离沙箱中，彻底杜绝了这种情况。在沙箱内部，无法看到代码库根目录、历史运行记录，也看不到评估配置。

每个沙盒均采用了多层隔离机制。文件系统限制控制了 agent 的访问权限，而拒绝名单则限制了其可执行的操作。每次运行都在独立的进程组中执行，以确保运行器（runner）能在清理阶段可靠地终止 agent 及其所有子进程。超时发生时，系统会先发送平滑的SIGTERM信号，如果 5 秒后仍有存活的进程（例如孤立的 MCP 子进程），则会升级为针对整个进程组的SIGKILL信号。运行结束后临时目录将被永久删除，即便进程从未成功启动也是如此，因为泄露包含有效 API 密钥的 MCP 配置是绝对无法接受的。

任务通过一个简单的 worker 池进行分发。每个 (MCP, model, run index) 三元组会被展平放入队列，worker 会不断提取下一个可用单元，直到队列清空。单个任务运行失败不会导致整个批次崩溃，系统会将其记录为失败，随后 worker 池会继续处理后续任务。

每个 agent 都会获取相同的系统提示词（prompt）框架：分配 SRE 角色，固定锚点时间以确保“过去 10 分钟”在每次运行中都代表相同的时间段，并设定大约 15 到 25 次的工具调用额度，要求 agent 在此限度内给出最终答案。我们刻意不提供 schema 说明。agent 必须自行通过 MCP 探索 schema，因为 schema 的发现能力正是评估内容的一部分，而非直接给定的已知条件。每次运行的完整轨迹都会被记录，包括每次工具调用、每个返回结果以及消耗的每个 token。这使得评分环节能够精准重构 agent 得出结论的完整推导过程，而不只是看它最终给出了什么答案。

深入评分机制

每次运行都会生成最终答案：这是一段文本，agent 会在其中指明根本原因、引用证据，并排除其认为无关的因素。对该答案的评分是一个包含三个阶段的流水线：程序化检查、LLM 评审以及工具错误扣分，这三部分最终会综合为一个分数。

程序化检查是对最终答案直接执行的加权正则测试。每个场景都包含正向检查（agent 是否指出了正确的服务、错误类型、span）和负向检查（是否将问题归咎于不该出现的干扰项）。负向检查并不涉及语言理解，而是围绕因果关系短语，在一个极小的字符间距窗口内进行匹配。例如，error-root-cause中的 TLS 握手干扰项检查，仅当 "tls handshake" 出现在 "root cause" 或 "caused by" 前后 80 个字符内时才会触发。因此，"the root cause was a database timeout; TLS handshake was ruled out" 不会触发该检查，而 "the root cause was the TLS handshake failure" 则会触发。这是一种启发式规则，而非语义解析，因此才需要引入 LLM 评委来捕捉正则无法处理的情况。

LLM 评委会基于预设标准对同一个最终答案进行评分，用来衡量正则难以评估的指标，比如 agent 的推理是否连贯、证据是否支持其结论。关键在于，答案在交给评委之前会进行盲化处理，将 MCP 特定的工具名和品牌词替换为匿名标签（“MCP A”、“MCP B”）。这确保了评委是基于标准答案（ground truth）来评估回答质量，而不是受 agent 使用了什么工具得出结论所影响。评委打分占总分的 60%。

工具错误惩罚会对可归咎于 agent 的工具故障最多扣除 20% 的分数：包括查询超时、输入格式错误以及工具调用不当。限流、服务器 503 错误和 TCP 故障等基础设施错误会在计算惩罚前被过滤掉，这样 agent 就不会因为集群自身状态不佳而受罚。这项惩罚按比例而非按次数计算，因此 1 次调用中出现 1 次故障，与 20 次调用中出现 20 次故障的惩罚力度相同。

以上三部分综合为以下公式：

combined = clamp((0.4 × programmatic + 0.6 × judge) − penalty, 0, 1)

在评分标准设计上，有一点需要特别说明：负向检查与正向检查同等重要。在error-root-cause中，共设有 5 个负向检查，分别对应 5 个干扰项。它们采用间距正则匹配，仅当 agent 明确将错误归因于不相关的服务时才会触发。如果 agent 给出限定说明（例如“同时存在 SMTP 故障，但与结账错误无关”），则顺利通过。如果 agent 言之凿凿地将问题归咎于 CDN，则会被判定为不合格，哪怕它在答案的其他地方也指出了真正的根本原因。

经验总结

要构建一个能稳定提升 agent 性能的 MCP server，仅仅添加合适的工具是不够的。你还需要同时在多个维度上把控好细节。

工具描述与 schema 比表面看起来更重要。如果参数太少，或者参数描述模糊且存在歧义，agent 就无法按需调整查询。例如，若一个过滤参数仅被描述为“过滤结果”，模型就只能去猜测其语法和语义，结果要么是干脆不用，要么是每次调用的方式都不一致。反之，如果参数过多，模型出错或混淆的空间就会更大，从而导致更多幻觉和更低的一致性。寻找合适的表达粒度是一个需要不断校准的过程。

响应设计是最关键的交互面。返回正确的信息只是基本要求。优秀 MCP 工具与普通工具的区别，在于其处理边缘情况的方式。当返回的数据行数过多时，工具应当提供提示，引导 agent 执行更具针对性的查询。发生错误时，工具应返回具有可操作性的下一步建议，而不是直接抛出原始堆栈信息。我们发现，如果 agent 在首次调用工具时遇到含义不明的错误，它们通常会在后续的排查中彻底放弃使用该工具。

速度的影响会不断叠加。如果工具返回结果耗时过长，agent 再次调用它的概率就会降低。在排查初期尤其如此，此时 agent 仍在建立假设，响应迟缓会打断其分析节奏。生产级的查询性能直接决定了排查质量。

结果

以下结果对比了 ClickHouse MCP server（允许 agent 通过 SQL 直接访问数据）与 ClickStack MCP server 及其专门用于排查日志和链路追踪（traces）的可观测性工具。在全部五个场景中，ClickStack 的得分均更高，截至本文撰写时，其领先优势在 7 到 20 个百分点之间。下方数据为综合总分。你自己运行评估将会获得丰富的数据点，从而可以从多个维度剖析结果。

我们使用 Claude Opus 4.6 生成了这些结果，在每个场景下对每个 MCP 运行十次。多次重复评估可以减少单次运行表现过好或过差带来的影响。满分意味着智能体找出了所有预期的发现，避开了所有错误的结论，并满足由 LLM 评判的各项定性指标。

评估工作的下一步

该框架已顺利运转，但仍有许多实际工作要做。

当务之急是将评估接入 CI。这意味着要缩短初始化时间，利用 ClickHouse Cloud 的预填充数据库在小型机器上实现更快的并发，将整个流程容器化，并配置 GitHub Actions 以在 MCP 发生更改时自动执行评估。目前，评估还是一个需要刻意执行的手动步骤，但未来它应当成为一道准入关卡。

除了流水线，我们还计划扩大场景的覆盖范围。目前的五个场景主要关注链路与日志排查，这也是核心的 SRE 工作流。但 ClickStack 的功能远不止于此，仪表盘生成质量、告警成功率以及指标排查都应有专属的测试场景。框架在设计之初就具备了兼容这些场景的能力，因此接下来的工作就是将它们逐一落地。

我们的目标是，在未来版本的hdx-evals中，对 ClickStack MCP 的任何实质性变更（无论是新增工具、重命名参数，还是修改响应 Schema），在发布前都要经过可复现的基准测试。我们希望评估能成为开发工作流的核心环节，而不是事后补救的手段。

总结

随着可观测性日益由智能体驱动，我们为智能体提供的工具已成为生产故障处理链路的一部分。与该链路上的其他环节一样，这些工具的质量也必须可衡量。我们在 Open House 上分享的数据并非一次性结果，而是该框架反复运行得出的产物。这些测试基于确定性的数据并采用盲测机制，确保评分真实反映排查质量，而不受所用工具的影响。

因此我们才能满怀信心地改进 ClickStack MCP。在交付给用户之前，我们可以将每个新工具、Schema 变更或响应微调与上一版本以及原生 SQL 基线进行对比评估。

我们已经开源了hdx-evals，方便大家进行同样的测试。如果你正在开发用于可观测性的 MCP 工具，或者其他对 agent 一致性要求较高的项目，相关的框架、测试场景和评分流水线均可在 github.com/hyperdxio/hyperdx/tree/main/packages/hdx-eval 获取。我们期待社区提交新的测试场景、改进评分机制并参与贡献。