Elastic-caveman：AI输出Token减少64%

你在使用AI助手查询Elasticsearch时，真正需要的是什么？其实是实实在在的信息：索引名称、字段映射、ES|QL查询语句、案例编号、情感分数等。然而，当前的大语言模型（LLM）接口每次回复都会附带大量客套话——

“当然！我很乐意帮助你……”
“这应该让你对整体情况有个很好的了解……”
“如果还需要其他帮助，请随时告诉我！”

这类填充内容不仅令人烦躁，更直接转化为实际成本。每增加一个token，就意味着多一分延迟和开销。在生产环境中频繁调用Elasticsearch查询时，这笔账愈发刺眼。今天介绍的elastic-ca veman正是专门解决此问题的工具。以下是基于八个真实MCP场景，在真实Elasticsearch集群上运行的对照实验结果：token平均减少63.6%，节省817个token，技术准确性零损失。

认识elastic-ca veman

elastic-ca veman的核心理念非常朴素：将AI响应中除“信号”之外的全部内容剥离，然后观察实际效果。具体来说，通过两种模式进行对比：

普通模式下，AI输出为完整对话——包含问候、解释、结束语。原始人模式则仅保留最基本的结构标签和最纯粹的数据。两种模式通过MCP连接到同一个真实的Elasticsearch实例，并使用实际的支持工单和Salesforce案例数据，测试了八个不同的生产场景。

结果：Token减少64%，准确性零损失

八次真实MCP工具调用的结果直观呈现如下：

指标	结果
测试场景数	8
成功率	88%
Token减少比例	平均63.6%
普通模式总Token	1,284
原始人模式总Token	467
节省的Token	817
单场景最大减少比例	91.5%

而真正关键的信息做到了0%损失：

技术准确性、API路径、ES|QL语法、字段名称——全部完好。所有字段名称、案例编号、ES|QL查询语句、账户名称和情感分数，不是“近似”保留，而是原封不动地保留。

真实示例：改造前后对比

示例1：列出索引 —— 减少87%

用户提问：显示我的索引

普通模式（107个token）输出：

当然！我很乐意帮你查看索引。以下是你的Elasticsearch集群中所有索引的完整列表。每个条目都显示了索引名称以及相关的元数据。这应该能让你对集群中存储的内容有一个很好的了解：-- salesforce-cases-- support-tickets