本文字数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 是因缺少索引导致的 p9999 百分位延迟恶化仅影响企业租户该问题埋藏在 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 那样去排查场景。过程中没有任何辅助脚手架或提示只有问题和工具。ScenarioSystem Prompterror-root-cause过去 10 分钟内部分用户的结账请求失败。请找出根本原因。latency-spike过去 15 分钟内api-server 的 p99 延迟激增。什么变慢了为什么segmented-regression过去 10 分钟内部分用户的 API 错误率上升。请找出退化集中的细分群组segment并查明原因。service-health-check对过去一小时内的 api-server 进行常规状态检查。总结关键的 SLI流量、错误率、延迟并指出任何异常或值得进一步关注的情况。不要将常规波动升级为故障。请保持简明扼要。noisy-signals我们希望降低日志摄入成本。应该丢弃或限制哪些最严重的噪音信号每次运行都会分配一个专属沙箱一个全新且用完即弃的临时目录、一个单一的 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 个百分点之间。下方数据为综合总分。你自己运行评估将会获得丰富的数据点从而可以从多个维度剖析结果。场景ClickStack MCPClickHouse SQL MCP差值error-root-cause93%73%20ppnoisy-signals64%45%19pplatency-spike60%43%17ppsegmented-regression75%60%15ppservice-health-check61%54%7pp我们使用 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 获取。我们期待社区提交新的测试场景、改进评分机制并参与贡献。