【MCP 工具】上下文 AI： Runbook 直接嵌入 Elastic Agent Builder

海兰

223人浏览 · 2026-06-14 16:58:03

海兰 · 2026-06-14 16:58:03 发布

1. 引言：

一位使用AI工具的开发者正准备合并一个 Pull Request，他在编辑器里随口问了一句：

“现在合并安全吗？”

几秒钟后，他得到了一个靠谱的答案——不需要花 10~15 分钟翻各种仪表盘，不需要在 Slack 上 @SRE，更不需要在深夜打扰正在值班的同学。

这不是魔法。本文将展示如何在 Elastic Agent Builder 中构建三个 MCP 工具，分别读取端点健康状态、近期部署记录和 SLO 燃烧率。核心思路是把平台团队的解读规则——那些原本活在 Runbook 和资深 SRE 脑海里的经验——直接编码进工具的描述里。

最终得到的是一种上下文 AI：一个能够依据平台团队一次性写好的规则，自动对生产信号进行推理的智能体。

2. 问题所在：为什么开发者像在"盲飞"？

一位开发者要把一个看起来无害的改动合入主干：把调用下游推荐服务的超时时间从 2 秒改为 5 秒。但在按下"Merge"按钮前，一个念头挥之不去：

现在的服务足够健康，能承受这个变更吗？

要回答这个问题，他只有两条路：

手动翻看仪表板：打开 APM 页面，查错误率、翻延迟曲线、找到 SLO 页面、搜索最近的部署记录。这一趟下来至少 10 分钟，而且你得清楚该看什么、该怎么解读。
找 SRE：在 Slack 上 @平台团队。这会造成中断，延长决策时间，而且根本没法规模化。

问题的本质并不是数据缺失。Elastic 本来就在采集一切：链路、指标、错误日志、部署标记和 SLO 预算。真正的问题是：把多个信号关联起来需要大量的心智负担和领域知识，而多数开发者并不具备这些。

一名有经验的 SRE 知道：

部署后 p99 在 5 分钟内冒尖是正常的；
在发布窗口期内错误率低于 0.5% 可以接受；
当 SLO 预算剩余不足 20% 时合并代码很危险。

这些知识活在 Runbook、口口相传的经验和脑子里。那么，如果平台工程师能够把这些知识编码进工具，让任何开发者都能在自己的编辑器里直接查询，会怎样？

3. 工具描述携带领域知识

要理解这套方案为什么有效，我们需要从 LLM 的底层机制说起。

3.1 LLM 的 Function Calling 机制

LLM 本质上是一个文本预测引擎。它接收文本输入，输出文本。它本身无法调用 API、查询数据库或执行任何外部操作。但当应用层给 LLM 提供一组"可用工具"的描述时，LLM 可以在推理过程中决定调用哪个工具、传入什么参数。

整个过程可以用下面这张图来理解：

具体流程如下：

工具注册：应用层将可用工具以 JSON Schema 格式注册给 LLM，包含工具名称、功能描述、参数定义。
推理决策：当用户提问时，LLM 分析问题和可用工具，判断是否需要调用工具来获取外部数据。
参数生成：LLM 根据用户意图和工具描述，生成符合 Schema 的参数。
执行与反馈：应用层执行工具调用，将结果返回给 LLM，LLM 基于结果继续推理或给出最终回答。

3.2 工具描述 = 隐性 Prompt

这里有一个关键的洞察：工具描述（description）会被完整送入 LLM 的上下文窗口。这意味着你在描述里写的每一个字——阈值定义、基线参考、因果关系判断——都会成为 LLM 推理时的"隐性 Prompt"。

举个例子，当你定义一个工具描述为：

“错误率超过 1% 通常意味着引入回归。如果该现象与一次近期部署同时发生，那么部署很可能是根因。”

LLM 在调用这个工具后，会自动将返回的数据与这段描述中的规则进行匹配，从而得出"当前错误率 1.2% + 10 分钟前刚部署 = 部署引入回归"的结论。你不需要在每次对话中重复这些规则，它们被固化在工具层面。

3.3 MCP 协议：标准化工具暴露方式

MCP（Model Context Protocol）是 Anthropic 提出的开放标准，它定义了 LLM 应用与外部工具之间的通用交互协议。

MCP 的核心价值在于解耦。它把工具生态分成了三层：

MCP Server：暴露工具、资源和提示模板（如 Elastic Agent Builder 的 MCP 端点）。
MCP Client：管理与服务器的通信（如 Claude Code、Cursor 中的 MCP 客户端）。
MCP Host：用户实际交互的 AI 应用（如 Claude Desktop、VS Code）。

当 Host 启动时，Client 连接到所有配置的 MCP Server，获取每个 Server 提供的工具列表及其描述，然后将这些描述注入 LLM 的上下文。LLM 据此决定何时调用哪个工具。

MCP 与 Function Calling 的关系：MCP 不替代 Function Calling，而是标准化了工具的暴露、发现和调用方式。Function Calling 是 LLM 表达"我想用某个工具"的机制，MCP 是"这个工具在哪里、怎么调用"的基础设施。

3.4 整体架构

把以上所有组件串起来，整个系统的数据流如下：

关键洞察：平台工程师一次性写好工具（查询 + 解读规则），每个开发者都能在自己的编辑器里直接获得生产环境的上下文信息。查询负责拉取数据，描述负责教代理怎么读懂这些数据。

4. 准备工作：从零开始的完整清单

4.1 环境要求

组件	要求	说明
Elastic Cloud 部署	Stack 9.3+ 或 Elastic Cloud Serverless	需启用 Agent Builder 功能
APM 数据	已接入 APM 的服务	若无数据，可用 `elastic/apm-integration-testing` + `opbeans-node` 生成模拟流量
MCP 客户端	Claude Code、Cursor 或 VS Code + MCP 扩展	Claude Code 对 MCP 支持最成熟
Node.js	18+	用于 `mcp-remote` 桥接
ES\|QL 基础	了解基本语法	`FROM`、`WHERE`、`STATS`、`EVAL` 等

4.2 确认 Agent Builder 已启用

登录 Kibana，进入 Stack Management > Advanced Settings
搜索 agentBuilder，确保 xpack.agentBuilder.enabled 为 true
在左侧导航栏中应能看到 Agent Builder 入口（通常在底部）

4.3 确认数据索引存在

在 Kibana Dev Tools 中执行以下命令，确认所需索引存在：

# 检查 APM 追踪数据
GET _cat/indices/traces-apm-*?v

# 检查部署注解数据
GET _cat/indices/observability-annotations?v

# 检查 SLO 索引（版本号可能不同）
GET _cat/indices/.slo-observability.*?v

如果 SLO 索引不存在，说明尚未配置 SLO。需要在 Observability > SLOs 中先创建 SLO 定义。

4.4 生成 API Key

在 Kibana 中：

进入 Stack Management > API Keys
点击 Create API Key
命名如 agent-builder-mcp
权限配置（最小权限原则）：
- Kibana 权限：feature_agentBuilder.read
- 索引权限：traces-apm.*（read）、observability-annotations（read）、.slo-observability.*（read）
复制生成的 Base64 编码密钥（格式如 ApiKey xxx）

生产环境建议将 API Key 有效期设为 30~90 天，并配置定期轮换。

5. 在 Agent Builder 中创建工具：完整实操步骤

5.1 进入工具管理界面

在 Kibana 左侧导航栏点击 Agent Builder
点击底部或侧边栏的 Tools 标签
你会看到预置工具列表（如 platform.core.generate_esql、platform.core.execute_esql 等）
点击 New tool 创建自定义工具

5.2 工具一：`get_endpoint_health` —— 端点健康快照

步骤 1：填写基础信息

字段	值
Tool ID	`get_endpoint_health`
Type	`esql`
Description	`返回某服务端点的当前健康状态：错误率、延迟分位数(p50/p95/p99)和吞吐量。在做出变更前用此工具评估服务是否健康。解读指南：错误率低于0.5%为健康，0.5%-1%为升高(请检查近期部署)，超过1%表明存在问题。对于延迟，将p99与服务基线进行比较：checkout通常低于500ms，product-search低于200ms。在部署后15分钟内出现p99突然飙升，意味着部署可能引入回归。`
Tags	`apm`, `reliability`, `health`

步骤 2：编写 ES|QL 查询

在 ES|QL 编辑器中粘贴：

FROM traces-apm-*
| WHERE service.name == ?serviceName
  AND @timestamp >= NOW() - ?timeWindow
  AND transaction.duration.us IS NOT NULL
| STATS
    total_transactions = COUNT(*),
    error_count = SUM(CASE(event.outcome == "failure", 1, 0)),
    p50_latency_ms = PERCENTILE(transaction.duration.us, 50) / 1000,
    p95_latency_ms = PERCENTILE(transaction.duration.us, 95) / 1000,
    p99_latency_ms = PERCENTILE(transaction.duration.us, 99) / 1000
  BY service.name
| EVAL error_rate_pct = ROUND(error_count / total_transactions * 100, 2)
| EVAL throughput_per_min = ROUND(total_transactions / ?windowMinutes, 1)

步骤 3：定义参数

点击 Infer parameters，系统会自动识别查询中的参数变量。然后补充描述：

参数名	类型	描述
`serviceName`	keyword	要检查的 APM 服务名称，如 `opbeans-node`
`timeWindow`	keyword	分析时间窗口，ES\|QL 时长格式，如 `30 minutes`、`1 hour`
`windowMinutes`	integer	时间窗口对应的分钟数，用于计算每分钟吞吐量

步骤 4：保存

点击 Save。工具创建完成。

设计要点说明：

查询采用 traces-apm-* 原始事务数据，比预聚合的 metrics-apm.transaction.1m-* 更具可移植性，后者需要有持续流量才会填充。
工具描述就是 Runbook：它不但说"返回健康指标"，还直接给出错误率阈值、延迟基线，以及如何将尖刺与部署关联的规则。这些规则会被 AI 代理在推理时直接引用。

5.3 工具二：`get_recent_deploys` —— 近期部署时间线

步骤 1：填写基础信息

字段	值
Tool ID	`get_recent_deploys`
Type	`esql`
Description	`返回某服务过去24小时的部署历史，包含版本号、时间戳和部署信息。用此工具了解部署时间线以辅助评估服务健康。关键模式：若部署发生在15分钟以内，错误率升高或延迟增加可能是正常现象(预热期)；若指标在部署后立即恶化，部署很可能是原因；短时间窗口内(2小时内)多次部署会增加风险，因为难以隔离是哪一次变更导致的问题。`
Tags	`apm`, `deploys`, `change-tracking`

步骤 2：编写 ES|QL 查询

FROM observability-annotations
| WHERE service.name == ?serviceName
  AND @timestamp >= NOW() - 24 hours
| SORT @timestamp DESC
| KEEP @timestamp, service.version, service.environment, message
| LIMIT 10

步骤 3：定义参数

参数名	类型	描述
`serviceName`	keyword	要查询部署历史的 APM 服务名称

步骤 4：保存

5.4 工具三：`get_slo_status` —— 错误预算燃烧率

步骤 1：填写基础信息

字段	值
Tool ID	`get_slo_status`
Type	`esql`
Description	返回某服务最近一小时的SLO燃烧率。响应包含：SLI值(当前达标率)、错误预算目标、以及燃烧率百分比。燃烧率表示服务消耗错误预算相对于允许阈值的快慢。解读：燃烧率低于100%意味着消耗慢于限额(可持续)；100%-200%意味着消耗快于计划(谨慎变更)；超过200%意味着消耗速度是允许值的两倍(推迟非关键变更)；超过500%应立即排查。注意：该工具衡量过去一小时的瞬时燃烧率，而非整个SLO窗口期的累计消耗。暂时的高燃烧率并不代表整体预算已耗尽。
Tags	`slo`, `reliability`, `budget`

步骤 2：编写 ES|QL 查询

FROM .slo-observability.sli-v*
| WHERE slo.id == ?sloId
  AND @timestamp >= NOW() - 1 hour
| STATS
    sli_value = AVG(slo.numerator) / AVG(slo.denominator)
  BY slo.id, slo.name
| EVAL error_budget_target = 0.995
| EVAL burn_rate_pct = ROUND((1 - sli_value) / (1 - error_budget_target) * 100, 1)

步骤 3：定义参数

参数名	类型	描述
`sloId`	keyword	SLO 标识符，请使用目标服务的 SLO ID

步骤 4：保存

关于 SLI 索引的提示：.slo-observability.sli-v* 的版本后缀取决于你的 Stack 版本（例如 Stack 9.3 中可能是 v3.6）。建议先用 GET _cat/indices/.slo-observability.*?v 核实并调整索引模式。

6. SLO 燃烧率的数学原理

6.1 核心公式

燃烧率（Burn Rate）衡量的是错误预算消耗速度相对于允许速度的倍数。

Burn Rate = Error Rate / (1 - SLO Target) = (1 - SLI Value) / (1 - SLO Target)

其中：

Error Rate = 当前观测到的错误率（或 1 - SLI 值）
SLO Target = 目标服务水平（如 99.5% = 0.995）
Error Budget = 1 - SLO Target = 允许的不可靠性比例（如 0.5%）

6.2 直观理解

我们用一张图来理解燃烧率的计算逻辑：

燃烧率	含义	行动建议
< 100%	消耗慢于限额，可持续	正常变更
100%~200%	消耗快于计划	谨慎变更，关注趋势
200%~500%	消耗速度是允许值的两倍	推迟非关键变更
> 500%	严重超速消耗	立即排查

举例：假设 SLO 目标是 99.5%（错误预算 0.5%），当前一小时 SLI 值为 99.0%（即错误率 1.0%）：

Burn Rate = (1 - 0.990) / (1 - 0.995) = 0.010 / 0.005 = 2.0 = 200%

这意味着当前错误预算消耗速度是允许速度的 2 倍。如果持续这个速度，30 天的错误预算将在 15 天内耗尽。

6.3 为什么用燃烧率而不是直接看错误率？

指标	问题	燃烧率优势
错误率绝对值	阈值随意，缺乏业务上下文	直接与 SLO 目标关联
SLO 累计消耗	滞后，发现问题时预算已耗尽	预测性，提前预警
简单阈值告警	噪音多，容易误报	多窗口验证，减少误报

燃烧率告警的核心思想来自 Google SRE Book：通过测量错误预算消耗速度，你可以在预算耗尽之前就收到预警，而不是等到违约后才知晓。

7. 通过 MCP 连接到你的编辑器

三个工具在 Agent Builder 中创建完成后，它们会自动通过 MCP Server 端点对外暴露。接下来配置 MCP 客户端进行连接。

7.1 获取 MCP Server URL

Elastic Agent Builder 的 MCP 端点格式为：

https://<your-kibana-host>/api/agent_builder/mcp

7.2 Claude Code 配置

Claude Code 的配置文件位置：

macOS/Linux: ~/.claude.json
Windows: %USERPROFILE%\.claude.json

编辑配置文件，添加 MCP Server：

{
  "mcpServers": {
    "elastic-agent-builder": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://your-kibana-url/api/agent_builder/mcp",
        "--header",
        "Authorization: ApiKey your-base64-api-key"
      ]
    }
  }
}

配置说明：

mcp-remote 是一个桥接工具，允许仅支持本地 stdio 传输的 MCP 客户端（如 Claude Code）连接到远程 HTTP MCP Server。
--header 参数用于传递认证信息，每个请求都会带上这个 Header。
-y 参数让 npx 自动确认安装，无需交互。

或者使用环境变量方式（更安全的做法）：

{
  "mcpServers": {
    "elastic-agent-builder": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://your-kibana-url/api/agent_builder/mcp",
        "--header",
        "Authorization: ApiKey ${ELASTIC_API_KEY}"
      ],
      "env": {
        "ELASTIC_API_KEY": "your-base64-api-key"
      }
    }
  }
}

7.3 Cursor 配置

Cursor 支持两种配置方式：

方式一：全局配置（~/.cursor/mcp.json）

{
  "mcpServers": {
    "elastic-agent-builder": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://your-kibana-url/api/agent_builder/mcp",
        "--header",
        "Authorization: ApiKey your-base64-api-key"
      ]
    }
  }
}

方式二：项目级配置（在项目根目录创建 .cursor/mcp.json）

这种方式更适合团队协作，可以将配置纳入版本控制（注意：不要将 API Key 提交到仓库，使用环境变量或 .env 文件）。

7.4 VS Code 配置

安装 MCP 扩展后，在设置中添加：

{
  "mcp.servers": [
    {
      "name": "elastic-agent-builder",
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://your-kibana-url/api/agent_builder/mcp",
        "--header",
        "Authorization: ApiKey your-base64-api-key"
      ]
    }
  ]
}

7.5 验证连接

配置完成后，重启你的编辑器/AI 客户端，然后提问：

“你现在有哪些可用的 Elastic 工具？”

代理应列出 get_endpoint_health、get_recent_deploys 和 get_slo_status。如果未列出，检查：

mcp-remote 是否已正确安装（npx mcp-remote --version）
API Key 权限是否包含 feature_agentBuilder.read
Kibana URL 是否可访问（尝试在浏览器中打开 https://your-kibana-url/api/agent_builder/tools）
查看 Claude Code / Cursor 的 MCP 日志输出是否有错误信息

8. 实战场景：“合并这个 PR 安全吗？”

8.1 场景设定

团队里的一个开发者准备合并一个 PR：将 opbeans-node 中调用推荐服务的超时时间从 2 秒改为 5 秒。合并前，他向代理发问：

开发者：“我打算合并 PR #42，它把 opbeans-node 中推荐服务的超时时间从 2 秒改成了 5 秒。现在合并安全吗？”

8.2 推理链：三步交叉验证

AI 代理会依次（或并行）调用三个工具，将结果结合 PR 的上下文进行联合解读。整个过程的决策流如下：

第一步：检查端点健康

代理调用 get_endpoint_health(serviceName="opbeans-node", timeWindow="30 minutes", windowMinutes=30)
返回：p99=480ms, 错误率=0.3%, 吞吐量=120/min
代理判断：p99 在 500ms 基线内，错误率 < 0.5% 为健康 → 当前状态正常

第二步：检查近期部署

代理调用 get_recent_deploys(serviceName="opbeans-node")
返回：最近部署 12 分钟前 v2.3.1，环境 production
代理判断：12 分钟 < 15 分钟预热窗口 → 仍在预热期，指标可能尚未稳定

第三步：检查 SLO 燃烧率

代理调用 get_slo_status(sloId="opbeans-node-availability")
返回：燃烧率=210%，SLI=99.47%，目标=99.5%
代理判断：210% > 200% 警戒线 → 错误预算消耗过快

综合推理：

代理将三个信号与 PR 上下文关联：

超时从 2s 改为 5s → 更多请求可能落入长尾延迟区间
当前燃烧率 210% → 已经在以 2 倍速度消耗错误预算
12 分钟前刚部署 → 系统处于预热期，引入变更风险叠加

结论：不建议现在合并。增加超时可能进一步拉高长尾延迟，恶化燃烧率，导致 SLO 违约。

8.3 代理的最终建议

代理：“根据检查结果，当前不建议直接合并。opbeans-node 的错误率目前正常（0.3%），p99 为 480ms，处于基线范围内。但注意，最近一次部署发生在 12 分钟前，仍处于 15 分钟预热窗口，指标尚在稳定期。更关键的是，该服务的 SLO 燃烧率当前为 210%，已超过 200% 的警戒线——这意味着错误预算正在以允许速度的两倍被消耗。此时引入增加下游超时的变更，可能拉高长尾延迟，进一步恶化燃烧率，有 SLO 违约风险。建议等待燃烧率回落至 100% 以下且预热窗口结束后再评估合并。”

8.4 为什么这个回答有价值？

AI 代理完成了以下推理步骤：

数据获取：拉取当前 p99、错误率、部署时间、燃烧率
规则匹配：将数据与工具描述中的阈值规则对比（p99 < 500ms = 正常；错误率 < 0.5% = 健康；燃烧率 > 200% = 危险）
关联分析：将 PR 中的"超时增加"与"当前高燃烧率"关联——超时增加意味着更多请求可能落入长尾延迟，而长尾延迟正是 SLO 违约的常见原因
风险评估：综合三个信号，给出"不建议合并"的明确结论和"等待燃烧率回落"的具体行动建议

这就是上下文 AI 的核心价值：不是简单返回原始数据，而是基于平台团队编码的领域知识进行跨信号推理。

9. ES|QL 查询优化建议

9.1 性能优化

优化项	建议	原因
时间范围	尽量缩小 `timeWindow`	减少扫描数据量
索引选择	使用具体索引名而非通配符	避免扫描无关索引
前置过滤	将 `WHERE` 条件放在 `STATS` 之前	减少聚合计算量
采样	高流量场景可考虑采样	平衡精度与性能

9.2 查询调试

在 Kibana Discover 或 ES|QL 控制台中先手动测试查询：

FROM traces-apm-*
| WHERE service.name == "opbeans-node"
  AND @timestamp >= NOW() - 30 minutes
| STATS count = COUNT(*) BY service.name

确认返回结果符合预期后，再将其封装为工具。

9.3 参数类型注意事项

参数类型	适用场景	示例
`keyword`	字符串匹配、枚举值	服务名、时间窗口描述
`integer`	数值计算	分钟数、限制条数
`date`	时间范围	特定时间点
`boolean`	开关选项	是否包含预热期

10. 故障排查与常见问题

10.1 工具创建问题

症状	可能原因	解决方案
“Infer parameters” 未识别参数	参数名拼写不一致	检查 `?paramName` 与查询中变量名是否一致
查询执行超时	时间范围太大或数据量过多	缩小 `timeWindow`，添加更精确的 `WHERE` 条件
返回空结果	索引不存在或数据不匹配	在 Dev Tools 中手动测试查询，确认索引和数据存在
SLO 索引找不到	版本后缀不匹配	用 `GET _cat/indices/.slo-observability.*?v` 确认实际索引名

10.2 MCP 连接问题

症状	可能原因	解决方案
代理说"没有可用工具"	MCP Server 未连接	检查 `mcp-remote` 进程是否运行，查看客户端日志
401 Unauthorized	API Key 无效或权限不足	确认 API Key 包含 `feature_agentBuilder.read` 权限
连接超时	网络或防火墙问题	确认 Kibana URL 可访问，检查是否需要 VPN
`mcp-remote` 命令未找到	Node.js 或 npx 未安装	安装 Node.js 18+，验证 `npx --version`
工具返回乱码或格式错误	ES\|QL 语法错误	在 Kibana Dev Tools 中测试查询，修正语法

10.3 推理质量问题

症状	可能原因	解决方案
代理忽略工具描述中的规则	描述不够明确或过长	将关键规则放在描述开头，使用清晰的"如果…那么…"结构
代理过度依赖某个工具	工具描述权重不平衡	确保每个工具描述都包含明确的"何时使用此工具"指引
代理给出矛盾结论	工具结果冲突	在描述中明确优先级规则（如"SLO 燃烧率优先于延迟指标"）

11. 进阶：扩展你的工具库

11.1 添加更多上下文工具

基于本文模式，你可以继续扩展：

工具	用途	数据源
`get_error_logs`	获取近期错误日志详情	`logs-apm.error-*`
`get_infrastructure_metrics`	检查 CPU/内存/磁盘	`metrics-system.*`
`get_alert_history`	查看近期告警记录	`.internal.alerts-*`
`get_dependency_health`	检查下游服务健康	`traces-apm-*`（按 `service.name` 过滤）

11.2 多服务关联查询

当变更涉及多个服务时，可以创建跨服务查询工具：

FROM traces-apm-*
| WHERE service.name IN (?serviceNames)
  AND @timestamp >= NOW() - ?timeWindow
| STATS
    error_rate = SUM(CASE(event.outcome == "failure", 1, 0)) / COUNT(*) * 100
  BY service.name
| SORT error_rate DESC

11.3 与 CI/CD 集成

在 CI Pipeline 中调用 Agent Builder API 进行自动化检查：

# 在合并前自动检查服务健康
curl -X POST "https://your-kibana-url/api/agent_builder/tools/_execute" \
  -H "Authorization: ApiKey $ELASTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "tool_id": "get_endpoint_health",
    "tool_params": {
      "serviceName": "'"$SERVICE_NAME"'",
      "timeWindow": "30 minutes",
      "windowMinutes": 30
    }
  }'

12. 总结：什么时候该用 MCP 工具，而不是 ping SRE？

借助 Elasticsearch、Agent Builder 和 MCP，开发者可以在自己的编辑器里，在几秒钟内就回答"现在合并安全吗？"这一类问题，而完全不用打扰 SRE。

层面	角色	价值
Elasticsearch	数据底座	承载着所有信号：链路、部署标记、SLO 预算
Agent Builder	知识编码层	平台团队编码如何解读这些信号：阈值、预热窗口、关联规则
MCP	连接层	把这些工具带进开发者的日常工作环境
LLM	推理层	基于编码的规则进行跨信号联合推理

查询负责拉取数据，描述负责教代理怎么读懂这些数据。平台工程师一次性写下 Runbook，团队里的每一个开发者都能随时从中获益——这就是上下文 AI 为研发效能带来的真正改变。

附录：快速参考卡

A. 工具配置速查

{
  "id": "get_endpoint_health",
  "type": "esql",
  "description": "返回某服务端点的当前健康状态...",
  "tags": ["apm", "reliability", "health"],
  "configuration": {
    "query": "FROM traces-apm-* | WHERE service.name == ?serviceName AND @timestamp >= NOW() - ?timeWindow AND transaction.duration.us IS NOT NULL | STATS total_transactions = COUNT(*), error_count = SUM(CASE(event.outcome == \"failure\", 1, 0)), p50_latency_ms = PERCENTILE(transaction.duration.us, 50) / 1000, p95_latency_ms = PERCENTILE(transaction.duration.us, 95) / 1000, p99_latency_ms = PERCENTILE(transaction.duration.us, 99) / 1000 BY service.name | EVAL error_rate_pct = ROUND(error_count / total_transactions * 100, 2) | EVAL throughput_per_min = ROUND(total_transactions / ?windowMinutes, 1)",
    "params": {
      "serviceName": { "type": "keyword", "description": "APM服务名称" },
      "timeWindow": { "type": "keyword", "description": "ES|QL时长格式" },
      "windowMinutes": { "type": "integer", "description": "窗口分钟数" }
    }
  }
}

B. MCP 客户端配置速查

{
  "mcpServers": {
    "elastic-agent-builder": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://your-kibana-url/api/agent_builder/mcp",
        "--header", "Authorization: ApiKey your-base64-api-key"
      ]
    }
  }
}

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

深入理解 AI Agent · AGENT #02：Agent 的四大核心机制，拆开来看每个都在干什么

AI Agent技术社区

MCP协议开发实战：从零搭建AI Agent工具链

本文介绍了MCP协议在AI工具链中的应用与实践。MCP协议旨在解决异构工具集成难题，为AI模型提供标准化、安全的工具调用接口。文章详细解析了MCP的核心架构，包括Server、Client、Transport等组件，以及通信流程与安全模型。通过实战示例，指导读者开发计算器和文件系统工具Server，并集成到Claude等AI客户端中。进阶部分展示了如何构建复杂工具链，包括API集成、数据库查询和多

AI Agent技术社区

AI Tool 设计：粒度、参数与错误恢复怎么做

AI Agent技术社区

所有评论(0)

查看更多评论

海兰

@s060403072

已为社区贡献27条内容

【MCP 工具】上下文 AI： Runbook 直接嵌入 Elastic Agent Builder

海兰

1. 引言：

2. 问题所在：为什么开发者像在"盲飞"？

3. 工具描述携带领域知识

3.1 LLM 的 Function Calling 机制

3.2 工具描述 = 隐性 Prompt

3.3 MCP 协议：标准化工具暴露方式

3.4 整体架构

4. 准备工作：从零开始的完整清单

4.1 环境要求

4.2 确认 Agent Builder 已启用

4.3 确认数据索引存在

4.4 生成 API Key

5. 在 Agent Builder 中创建工具：完整实操步骤

5.1 进入工具管理界面

5.2 工具一：get_endpoint_health —— 端点健康快照

5.3 工具二：get_recent_deploys —— 近期部署时间线

5.4 工具三：get_slo_status —— 错误预算燃烧率

6. SLO 燃烧率的数学原理

6.1 核心公式

6.2 直观理解

6.3 为什么用燃烧率而不是直接看错误率？

7. 通过 MCP 连接到你的编辑器

7.1 获取 MCP Server URL

7.2 Claude Code 配置

7.3 Cursor 配置

7.4 VS Code 配置

7.5 验证连接

8. 实战场景：“合并这个 PR 安全吗？”

8.1 场景设定

8.2 推理链：三步交叉验证

8.3 代理的最终建议

8.4 为什么这个回答有价值？

9. ES|QL 查询优化建议

9.1 性能优化

9.2 查询调试

9.3 参数类型注意事项

10. 故障排查与常见问题

10.1 工具创建问题

10.2 MCP 连接问题

10.3 推理质量问题

11. 进阶：扩展你的工具库

11.1 添加更多上下文工具

11.2 多服务关联查询

11.3 与 CI/CD 集成

12. 总结：什么时候该用 MCP 工具，而不是 ping SRE？

附录：快速参考卡

A. 工具配置速查

B. MCP 客户端配置速查

所有评论(0)

温馨提示：您尚未绑定手机号

海兰

5.2 工具一：`get_endpoint_health` —— 端点健康快照

5.3 工具二：`get_recent_deploys` —— 近期部署时间线

5.4 工具三：`get_slo_status` —— 错误预算燃烧率