当您通过 AI 助手查询 Elasticsearch 时，真正想要的是什么？是索引名称、字段映射、ES|QL 查询语句、案例编号，还是情感分数？这些事实性数据才是核心。然而，当前的大语言模型接口在每次响应中都会附带大量对话式填充内容——例如“当然！我很乐意帮助你……”“这应该让你对整体情况有个很好的了解……”“如果还需要其他帮助，请随时告诉我！”——不仅令人烦躁，而且成本高昂。每个 token 都意味着开销和延迟，在生产环境的 Elasticsearch 查询场景下，这种消耗会迅速累积。
本文介绍一款名为 elastic-ca veman 的工具，并分享一项对照实验的结果——该实验针对 Elasticsearch 集群，在八个真实的 MCP（模型上下文协议）场景中进行了测试。核心发现：平均减少了 63.6% 的 token，节省了 817 个 token，且技术准确性没有任何损失。换句话说，剔除客套话，只保留实质内容，效果令人瞩目。
认识 elastic-ca veman
elastic-ca veman 验证了一个简单的假设：从 AI 响应中剥离出纯粹的信号，然后衡量其影响。具体做法如下：
- 普通模式：完整的对话式 AI，包含问候、解释和结束语。
- 原始人模式（Ca veman mode）：仅包含最少结构标签的原始数据。
在两种模式下，使用 MCP 连接一个真实的 Elasticsearch 实例，并基于实际的支持工单和 Salesforce 案例数据，测试了八个生产场景。
结果：Token 减少 64%，准确性零损失
下面展示在八个真实 MCP 工具调用中的发现：elastic-ca veman 成功优化了 AI 响应的规模，且未牺牲质量或功能。
| 指标 | 结果 |
|---|---|
| 测试场景数 | 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
以上就是我找到的所有索引。如果你想深入了解某个具体的索引，请告诉我，我会很乐意提供帮助！
原始人模式（14 个 Token）：
索引：salesforce-cases, support-tickets
节省：93 个 Token（86.9%）
示例 2：生成 ES|QL 查询 —— 减少 75%
用户：显示按产品领域分组的未解决的关键工单
普通模式（208 个 Token）：
好的！我很乐意帮你编写这条 ES|QL 查询语句。你要做的是过滤出状态为“未解决”且优先级为“关键”的工单，然后按产品领域分组。以下是实现方法……
接着是实际查询语句，外加 150 多个 Token 的分步解释
原始人模式（52 个 Token）：
FROM support-tickets
WHERE status = "Open" AND priority = "Critical"
| STATS count = COUNT(*) BY product_area
| SORT count DESC
| LIMIT 100
过滤条件：未解决 + 关键，按 product_area 分组、计数、降序排序。
节省：156 个 Token（75.0%）。两种模式下，ES|QL 语法都是逐字符一致的。
示例 3：搜索最近的支持工单 —— 减少 35%
用户：显示 5 条最近的支持工单
原始人模式（143 个 Token）：
5 条最近工单，按最新排列：
| 案例编号 | 优先级 | 状态 | 账户名称 | 主题 | 天数 | 情感评分
CASE-0012 | 关键 | 未解决 | Pinnacle Financial | 监管报告：错误的税务计算 | 2 | -0.94
CASE-0021 | 关键 | 已升级 | Riverstone Capital | 安全审计阻止续订 | 2 | -0.93
CASE-0046 | 中 | 未解决 | Blackrock Partners | 渗透测试结果需供应商回复 | 2 | -0.70
CASE-0006 | 高 | 未解决 | United Oil & Gas | 未经授权访问——紧急 | 3 | -0.91
CASE-0017 | 高 | 未解决 | Riverstone Capital | 续订文书停滞 | 4 | -0.86
所有情感评分均为负面。4 月 7 日有两条关键案例。所有案例编号、优先级、账户名称和情感评分被逐字保留。
什么被移除，什么被保留
在优化输出时，会去除对话式的填充内容，比如“当然！我很乐意帮助你……”“这应该能让你有个很好的了解……”或“需要我帮你确定这些的优先级吗？”。同时，会保留所有事实性内容：ES|QL 代码片段（如 FROM support-tickets WHERE status = "Open"）、字段名称（如 sentiment_score、product_area、resolution_hours）、索引名称（如 support-tickets 和 salesforce-cases）。此外，还保留具体的标识符和业务实体：案例编号（如 CASE-0012、CASE-0002）、账户名称（如 Pinnacle Financial 和 United Oil Gas Corp），以及所有数值（情感评分 -0.94、统计数量 47 个重复项、持续时间 18 天、平均 27.0 小时等）。编辑后的文本严格聚焦于查询语法、实体和数字，只丢弃了礼貌性的框架内容。
不同操作类型的结果也有所差异：
| 查询类型 | Token 减少比例 | 原因 |
|---|---|---|
| 元数据清单 | 85–92% | 载荷小，普通模式下填充内容最多 |
| ESQL 生成 | 70–75% | 查询语句本身一致，解释部分被移除 |
| 数据密集搜索 | 35–40% | 实际数据占主导，填充空间减少 |
完整的评估分解
以下是在全部八个场景中，针对真实 MCP 数据的 Token 节省情况，按查询类型划分：
| 场景 | 普通 Token | 原始人 Token | 减少比例 | 节省 Token | MCP 工具 |
|---|---|---|---|---|---|
| T1：列出所有流 | 118 | 10 | 91.5% | 108 | platform.streams.list_streams |
| T2：列出索引 | 107 | 14 | 86.9% | 93 | platform.core.list_indices |
| T3：获取索引映射 | 143 | 40 | 72.0% | 103 | platform.core.get_index_mapping |
| T4：生成 ESQL 查询 | 208 | 52 | 75.0% | 156 | platform.core.generate_esql |
| T5：执行 ESQL 聚合 | 149 | 44 | 70.5% | 105 | platform.core.execute_esql |
| T6：搜索最近工单 | 221 | 143 | 35.3% | 78 | platform.core.search |
| T7：搜索已升级案例 | 198 | 128 | 35.4% | 70 | platform.core.search |
| T8：按优先级统计 ESQL | 140 | 36 | 74.3% | 104 | platform.core.execute_esql |
| 总计 | 1,284 | 467 | 63.6% | 817 |
技术准确性验证：
| 准确性检查项 | 结果 | 详情 |
|---|---|---|
| ESQL 语法保留 | 通过 | FROM、WHERE、STATS、SORT、LIMIT 完全一致 |
| 字段名称保留 | 通过 | account_id、sentiment_score、product_area 逐字保留 |
| 索引名称保留 | 通过 | support-tickets、salesforce-cases 未改变 |
| 案例编号保留 | 通过 | CASE-0012、CASE-0002 精确保留 |
| 账户名称保留 | 通过 | Pinnacle Financial、United Oil Gas Corp 精确保留 |
| 数值保留 | 通过 | 情感评分 -0.94、-0.88；开放天数 18、7 精确保留 |
| 优先级/状态标签 | 通过 | Critical、Escalated、Open 逐字保留 |
| 空值保留 | 通过 | 低优先级的 resolution_hours 为 null 保留 |
| 错误消息保留 | 通过 | 工具验证错误逐字引用 |
信息零损失。Token 减少 64%。
这对 Elastic 用户的意义
对于在 Elasticsearch 上构建 AI 助手的团队来说，64% 的 Token 减少意味着：规模化部署时输出成本节省 64%、流式响应更快、以及更大的上下文窗口空间用于处理实际数据而非填充内容。当你在凌晨两点调试一条 ES|QL 查询时，你不需要 AI 告诉你它很乐意帮忙；你只需要查询结果。
更宏观的视角：重新思考 AI 界面
这个实验揭示了一个根本性问题：对话式 AI 界面总是在错误的指标上进行优化——它们追求听起来像人类，而用户往往只需要快速准确的数据。
对于技术性工作流，尤其是数据查询，有一个强有力的理由支持模式切换：
- 对话模式：用于探索或学习。
- 原始人模式：当你明确知道自己想要什么并且需要立即得到结果时。
Elastic MCP 服务器通过返回结构化、准确的响应，使得这两种模式都能完美运行，无需修改。
elastic-ca veman 的工作原理
elastic-ca veman 是一种 Agent Skill，即一个包含 YAML 前置元数据的 Markdown 文件。任何兼容的 AI Agent 都可以读取并执行这些指令。它无需运行时、无需二进制文件、无需 API 调用——只是一组指令，重新定义了你的 Agent 在处理 Elasticsearch 时的说话方式。
安装命令：npx skills add srikolag/elastic-ca veman
支持的 Agent：Claude Code、Cursor、Codex、Windsurf、GitHub Copilot、Gemini CLI、Roo
触发方式：/elastic-ca veman；关闭方式：normal mode 或 verbose
实际运行效果
我们使用 Claude 模型测试了 elastic-ca veman，以衡量其对 Token 使用量和成本的影响：
- 使用 elastic-ca veman：Token 用量为 368（输入）+ 1.6k（输出），成本为 $0.11。
- 未使用 elastic-ca veman：Token 用量为 367（输入）+ 1.8k（输出），成本为 $0.12。
提示词：从 support-tickets 索引中获取 Pinnacle Financial 的关键支持工单，并显示在 Kibana 中
此测试展示了 elastic-ca veman 的效率。视频缩略图
下一步计划
原始人模式仅仅是个开始。未来可考虑动态模式切换：在会话过程中随时切换简洁与详细模式。或者混合模式：成功时简洁，出错时详尽。也可以为团队定制详细的级别，以满足中间需求。目标不是让 AI 助手变得机械，而是让用户能够控制信号与噪声的比例。
亲自尝试
使用你的 Elasticsearch 数据测试原始人模式：
- 设置 Elastic MCP 服务器。
- 安装 elastic-ca veman。
- 在普通模式和原始人模式下分别运行查询。
- 比较 Token 数量和准确性。
结论
在八个使用真实 Elasticsearch 数据的真实场景中，elastic-ca veman 实现了平均 64% 的 Token 减少，且准确性零损失——ES|QL 语法、字段名称和技术值的保留率为 100%。有时，最好的 AI 响应并不是最健谈的那一个。有时你只需要数据——而借助 elastic-ca veman，你可以快 64% 获取它。
