在 WorkBuddy 上通过 MCP 访问 Elastic 工具箱：企业级落地与实战指南

一、 引言：企业协同端与 Elastic MCP 网关的碰撞

随着大语言模型在企业级研发和运维工作流中的深度普及，研发与 SRE 团队日常的排障、研发动作正在快速向企业协同终端收拢。在腾讯内部，WorkBuddy（腾讯工作伙伴） 已经成为了连接员工与日常开发、运维系统的核心 AI 协同端。

在传统的运维和检索架构中，如果你想要在本地终端（如 WorkBuddy 客户端、Cursor 或 VS Code）中调度部署在 Elastic Cloud 上的智能体，或者直接利用 Elasticsearch

强大的日志和指标分析能力，你必须编写繁琐的中间件、手动转发 API，或者频繁在 Kibana 界面和工作软件之间来回切换。这不仅严重割裂了工作流，也推高了整体的研发和运维响应时间。

Kibana 官方最新推出的 Agent Builder MCP Server（Serverless / Stack GA 9.3+）彻底终结了这一痛点。

通过原生实现 Model Context Protocol（MCP，模型上下文协议），Kibana 直接充当了高可用的 MCP 远程服务端。用户可以直接使用 WorkBuddy 作为 MCP 客户端，通过一条安全通道，将云端

Elasticsearch（例如我的演示集群 lex-demo）上的各种分析工具直接挂载到本地会话中。

本文将作为一份详尽的、生产级可复制的用户指南，为你彻底剖析 Kibana MCP Server 的底层原语，手把手教你如何完成安全特权签发、本地客户端挂载。

二、 协议内核：为什么标准 MCP 层面没有 Agent 原语？

在着手配置之前，我们必须首先理清一个核心的技术概念：“在 WorkBuddy 等客户端中，大模型是如何感知并调用 Elastic 远程能力的？”

许多人在进行技术验证时，会产生一个直觉上的误区，认为 MCP 协议应该能直接向客户端传递一个名叫 “SRE Agent” 或 “Log Agent” 的智能体实体。但事实上，如果你查阅 Anthropic 牵头制定的标准 MCP

开源规范，你会发现标准 MCP 协议层面完全没有原生的 “Agent” 概念。

2.1 标准 MCP 协议的三大核心原语 (Primitives)

MCP 在设计之初，为了保证协议的极简性、状态的解耦性以及跨客户端的通用性，仅仅定义了三种核心交互原语：

1. Tools（工具）：
   • 定义：由服务端暴露的、可执行的、带有严格 JSON Schema 参数约束的函数（Functions）。
   • 机制：本地模型（Host LLM）通过阅读工具描述（Description），在需要时决定调用该工具，并自主组装符合 Schema 要求的参数。服务端执行后，返回纯文本或结构化数据。
   • 特点：有副作用（可以写数据、调接口），是 Agent 改变外部世界的唯一通道。
2. Resources（资源）：
   • 定义：由服务端托管的、只读的数据源。它类似于一个统一的 URI 资源定位符（如 postgres://db/table 或 elastic://streams/logs）。
   • 机制：本地客户端可以直接读取这些资源的内容，作为背景上下文（Context）输入给本地大模型。
   • 特点：无副作用，纯只读。
3. Prompts（提示词）：
   • 定义：由服务端预设好的提示词模版。
   • 机制：方便本地用户快速拉取并填入参数（如排障模版、代码重构模版），免去用户手写复杂提示词的麻烦。

由于协议层面只有这三种原语，这意味着**本地客户端的大脑（如 WorkBuddy 内部运行的大模型）在连接到 Kibana MCP Server 时，它看到的仅仅是一个“摊开的、无状态的工具和资源库”，而不是一个活生生的、有自主思考能力的

Agent。**

2.2 解决方案（Workaround）：将 Agentic 工作流封装为普通 Tool

那么，如果我们希望在本地 WorkBuddy 中一键执行复杂的、包含多轮思考、需要自主调度各种子工具的“Agent 级”诊断任务，该怎么办？

答案是：在 Kibana 服务端，利用 Workflow（工作流）将复杂的多步 Agentic 逻辑进行封装，并将其对外“伪装”成一个符合标准 MCP Primitives 的普通单次调用工具（Tools）。

┌─────────────────────────────────────────────────────────────────────────┐
│ WorkBuddy 客户端 (MCP Client)                                            │
│                                                                         │
│   发起了单次的、确定性的工具调用请求：                                        │
│   tools/call -> run_rca_diagnostic_workflow(service_name="checkout")    │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ (标准 JSON-RPC 2.0 报文)
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Kibana 远程安全沙箱 (MCP Server 端)                                      │
│                                                                         │
│   在服务端内部，该“工具”启动了一个完整、复杂的 Agentic Workflow 状态机：   │
│                                                                         │
│   [Step 1: 拉取最近日志] ──► [Step 2: 过滤 Error] ──► [Step 3: 调用 Agent] │
│                                                      (执行诊断与知识库匹配) │
│                                                                 │       │
│   [返回标准结构化 JSON 报告] ◄──────────────────────────────────┴───────┘   │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ (单次、确定的结构化输出)
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ WorkBuddy 客户端 (MCP Client)                                            │
│                                                                         │
│   优雅、低成本、高可控地在聊天框中渲染最终的 RCA 故障结论                 │
└─────────────────────────────────────────────────────────────────────────┘

为什么这种封装和伪装是企业级落地的最佳实践？

1. 协议合规与生态通用： WorkBuddy（腾讯工作伙伴）由于目前的客户端策略，仅支持纯底层的工具调用（Tools），不支持渲染复杂的前端 React UI（如 iframe 沙箱）。将复杂的 Agent 逻辑封装在 Tool 内部，使 WorkBuddy 无需做任何定制化适配，就能完美消费这些高级分析能力。
2. 绝对的可控性与安全边界： 如果本地模型直接调度一个个零散的原生工具，它可能会因为理解偏差，在多次自主调用中走向未知的逻辑分支。而封装在服务端的 Workflow 具有确定的步骤约束，大模型只在限定的 Step（如推理诊断阶段）发挥作用，整个执行链条完全在云端的可控沙箱内，绝不越界。
3. 极致的 Token 节省与低延迟： 本地与远端之间只发生一次结构化数据的交互，省去了本地模型反复“思考、判断、组装下一次工具参数”的大量网络 RTT（往返延迟）和多轮 Prompt 消耗，极大地降低了企业的 Token 费用。

三、 准备工作：在 lex-demo 上签发 MCP 专属凭证

要让本地的 WorkBuddy 安全、顺畅地连入你的 lex-demo 远程 Elasticsearch 集群，你必须签发一个专用的安全 API Key。由于 Kibana 负责 MCP 路由与应用层工具的管理，直接使用普通的

Elasticsearch 数据 API Key 会遇到 403 Forbidden 报错。

我们必须为 API Key 赋予 Kibana 应用级特权（Application Privileges）。

3.1 权限签发 Payload 详解

打开你的 Kibana 开发者工具（Dev Tools），运行以下 POST /_security/api_key 请求。这是一个生产级的、遵循最小权限原则（Least Privilege）的凭证模版：

POST /_security/api_key
{
  "name": "workbuddy-mcp-sre-key",
  "expiration": "30d",
  "role_descriptors": {
    "mcp-sre-accessor": {
      "cluster": ["monitor_inference"],
      "indices": [
        {
          "names": [
            ".ds-logs-apm.error-*",
            ".ds-metrics-hostmetricsreceiver.otel-*",
            "logs-abnormal_demo_*"
          ],
          "privileges": ["read", "view_index_metadata"]
        }
      ],
      "applications": [
        {
          "application": "kibana-.kibana",
          "privileges": [
            "feature_agentBuilder.read",
            "feature_actions.read"
          ],
          "resources": [
            "space:default"
          ]
        }
      ]
    }
  }
}

🔑 权限核心字段解析：

• cluster: ["monitor_inference"]：必选特权。允许该 Key 调用部署在 Elastic Inference Service (EIS) 上的 AI 语言模型及向量模型，用于工作流内部的语义理解和推理。
• indices：数据安全红线。在这里，我们将 API Key 的访问范围严格限定在 APM 错误日志流（.ds-logs-apm.error-*）、主机性能指标流（.ds-metrics-hostmetricsreceiver.otel-*）以及应用异常日志（logs-abnormal_demo_*）上。即使该 Key 丢失，攻击者也绝对无法查询你集群上的其他核心业务索引。
• application: "kibana-.kibana"：最关键的 Kibana 专属特权通道。 必须精确指向 kibana-.kibana，向 Kibana 注册：
  • feature_agentBuilder.read：允许客户端读取并列出 Agent Builder 中定义的所有工具与工作流。
  • feature_actions.read：允许客户端触发和执行这些工作流工具。
• resources: ["space:default"]：将工具库隔离在 Kibana 的 default（默认）工作空间中，防止跨 Space 越权。

运行该请求后，ES 会返回如下响应，请妥善保存其中的 api_key（即 Base64 编码后的凭证）：

{
  "id": "TGpIcFBad0JsSFdTVzFkT2dtLWU",
  "name": "workbuddy-mcp-sre-key",
  "expiration": 1786502400000,
  "api_key": "xxxxx=="
}

四、 客户端配置：在 WorkBuddy 中挂载 Elastic MCP Server

在 WorkBuddy 中，所有的外部工具扩展都需要通过配置文件进行挂载。整个过程非常简单，只需要在

WorkBuddy 中添加连接器，别填入正确的 mcpServer信息即可

4.1 WorkBuddy 核心 JSON 配置

在你的本地 WorkBuddy 安装目录下的 MCP 配置文件中，加入以下配置块。将第一步生成的 ApiKey 精准写入 Header 头：

{
  "mcpServers": {
    "lex-demo-agent-builder": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://lex-demo.kb.ap-east-1.aws.elastic-cloud.com/s/default/api/agent_builder/mcp",
        "--header",
        "Authorization:ApiKey V1Rob1dwOEJIT2laX2lPQWhxWE06cjAwbzJwN0RuTzJMQXNSeWptd29PZw=="
      ],
      "disabled": false
    }
  }
}

💡 配置原理解析：

1. npx：在本地无需手动全局安装任何依赖，npx 会自动、无感地拉取并执行 mcp-remote。它会作为本地的一个子进程（stdio 模式运行），将本地大模型的 stdio 标准输入输出，无缝打包成标准 JSON-RPC 2.0 报文，通过 HTTPS 协议代理发送到远程。
2. /s/default/ 路径：Kibana 采用 Space（空间）隔离路由。如果你的 Agent 部署在特定空间（例如名字叫 sre-space），请务必将路径修改为 /s/sre-space/api/agent_builder/mcp。
3. --header 注入：这是通过安全认证的唯一通道。请确保格式为 ApiKey <Base64_Key>，注意 ApiKey 与密钥之间有一个空格。

配置保存后，彻底重启你的 WorkBuddy 客户端。在对话窗口中，你会看到工具栏中新增了来自 lex-demo-agent-builder 的工具注册，这标志着连接已经完美建立！

五、 总结

在 AI 时代的微服务和数据架构中，我们不要被酷炫的“Agent”外表蒙蔽，而要回归系统工程学的本质。

通过本文的实战，我们明确了：

1. 原语至上：标准 MCP 协议只支持 Tools / Resources / Prompts，没有 Agent 原语。
2. 解耦设计：拒绝将 Raw Agent 直接挂载到本地（这会带来灾难性的 Token 飙升和不可控行为）。
3. 工作流伪装：在远程 Kibana Agent Builder 中，使用 Workflow 封装复杂的 Agentic 诊断动作，对外将其包装为标准、确定性的单次调用 Tool。
4. 协同提效：通过在本地 WorkBuddy（腾讯工作伙伴）中挂载这些 Workflow 工具，在不改变客户端纯 Tool 调用生态的前提下，实现了对 lex-demo 集群最深度、最安全、最省钱的 SRE 故障斩首排查。