Elastic-caveman : 在不损失 Elastic 最佳效果的情况下，将 AI 响应 tokens 减少64%

作者：来自 Elastic Sri Kolagani

了解如何使用 elastic-caveman，在保留 Elastic 代理能力优势的同时减少 AI 响应的 token 消耗。

Agent Builder 现已正式发布。通过 Elastic Cloud Trial 开始使用，并查看这里的 Agent Builder 文档。

当通过 AI 助手查询 Elasticsearch 时，你需要的是事实：索引名称、字段映射、Elasticsearch 查询语言（ ES|QL ）查询、案例 ID、情感分数。但现有的大语言模型（large language model - LLM ）接口会在每个响应外层包裹大量对话性冗余内容：

复制代码

"Of course! I'd be happy to help you..."

"This should give you a good overview..."

"Feel free to let me know if you need anything else!"

这不仅令人困扰，而且成本高昂。每个 token 都会产生费用并增加延迟。对于生产环境中的 Elasticsearch 查询，这种开销会快速累积。在本文中，我们介绍 elastic-caveman，并分享在一个受控实验中的结果：在 8 个真实的 Model Context Protocol（ MCP ）场景中对一个 Elasticsearch 集群进行测试。结果显示：平均减少 63.6% token、节省 817 个 tokens，并且技术准确性完全没有损失。

引入 elastic-caveman

elastic-caveman 验证了一个简单假设：去除 AI 响应中的 "对话噪音"，只保留信号，并测量其影响。方法如下：

普通模式：完整的对话式 AI 输出，包含问候、解释和结束语。
原始（ caveman ）模式：只返回原始数据，仅保留最小结构标签。

我们使用 MCP，在一个真实的 Elasticsearch 实例上进行了测试，数据来自实际的 support ticket 和 Salesforce case，在 8 个生产场景中对两种模式进行对比。

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

以下是我们在 8 个真实 MCP 工具调用中观察到的结果：Elastic-Caveman 项目成功在不影响质量或功能的前提下优化了 AI 响应大小。

Metric	Result
Scenarios tested	8
Success rate	88%
Token reduction	63.6% average
Total normal tokens	1,284
Total Caveman tokens	467
Tokens saved	817
Max reduction (single scenario)	91.5%

关键保留项（0% 损失）：

技术准确性
API 路径
ES|QL 语法
字段名称

关键发现：每一个字段名、case ID、ES|QL 查询、账户名称以及情感分数都被完全保留------不是近似保留，而是完全一致地保留。

真实示例：前后对比

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

用户：*Show me my indices/*显示我的索引

普通模式（107 tokens）：

复制代码

Of course! I'd be happy to help you see your indices. Here's a comprehensive list of all the indices in your Elasticsearch cluster. Each entry shows the index name along with relevant metadata. This should give you a good overview of what's stored in your cluster:-- salesforce-cases-- support-ticketsThese are all the indices I found. If you'd like to dive deeper into any specific index, just let me know and I'll be glad to assist!

Caveman mode (14 tokens):

复制代码

Indices: salesforce-cases, support-tickets

Saved: 93 tokens (86.9%)

示例 2：生成 ES|QL 查询：减少 75%

User: Show me open critical tickets grouped by product area

Normal mode (208 tokens):

复制代码

Sure thing! I'd be happy to help you write that ES|QL query. What you're looking for is a query that will filter for open tickets with critical priority and group them by product area. Here's how you can accomplish this...

【普通模式输出】（150+ tokens）

Caveman mode (52 tokens):

复制代码

FROM support-tickets
WHERE status = "Open" AND priority = "Critical"
| STATS count = COUNT(*) BY product_area
| SORT count DESC
| LIMIT 100

Filters open+critical, groups by product_area, counts, sorts desc.

Saved: 156 tokens (75.0%). ES|QL syntax is character-for-character identical in both modes.

示例 3：搜索最近的支持工单：减少 35%

User: Show me 5 recent support tickets

Caveman mode (143 tokens):

复制代码

5 recent tickets, newest first:
Case     | Priority | Status    | Account               | Subject                                    | Days | Sentiment
CASE-0012 | Critical | Open      | Pinnacle Financial    | Regulatory reporting: incorrect tax calcs  | 2    | -0.94
CASE-0021 | Critical | Escalated | Riverstone Capital    | Security audit blocking renewal            | 2    | -0.93
CASE-0046 | Medium   | Open      | Blackrock Partners    | Pen test findings need vendor response     | 2    | -0.70
CASE-0006 | High     | Open      | United Oil & Gas      | Unauthorized access -- urgent               | 3    | -0.91
CASE-0017 | High     | Open      | Riverstone Capital    | Renewal paperwork stalled                  | 4    | -0.86

All negative sentiment. Two critical cases from April 7. All case IDs, priorities, account names, and sentiment scores preserved verbatim.

删除什么 vs 保留什么

当我们清理输出时，会移除对话性填充内容，例如："当然！我很乐意帮你......"、"这应该能让你更好地理解......"、"你需要我帮你优先排序这些吗？"之类的表达。

同时保留所有事实性内容，例如 ES|QL 片段，如 FROM support-tickets WHERE status = "Open"；字段名如 sentiment_score、product_area 和 resolution_hours；以及索引名称，如 support-tickets 和 salesforce-cases。

我们还保留具体标识符和业务实体，例如 case ID（ CASE-0012、CASE-0002 ）、账户名称（ Pinnacle Financial、United Oil & Gas Corp ），以及所有数值信息，例如 sentiment_score -0.94、重复计数 47、持续时间 18 days，或指标如 27.0 average hours。

这样处理后的文本会高度聚焦在查询语法、实体和数值上，只移除礼貌性的 "外壳" 内容。

结果按操作类型有所不同：

查询类型	Token 减少	原因
元数据列表	85--92%	载荷较小，普通模式中的冗余内容最多
ES	QL 生成	70--75%
数据密集型搜索	35--40%	实际数据占比高，可删除的"冗余内容"较少

完整评估拆解

在针对真实 MCP 数据的 8 个场景中，不同查询类型的 token 节省情况如下：

场景	普通 tokens	Caveman tokens	减少比例	T节省 tokens	MCP 工具
T1: List all streams	118	10	91.5%	108	platform.streams.list_streams
T2: List indices	107	14	86.9%	93	platform.core.list_indices
T3: Get index mapping	143	40	72.0%	103	platform.core.get_index_mapping
T4: Generate ES\|QL query	208	52	75.0%	156	platform.core.generate_esql
T5: Execute ES\|QL aggregation	149	44	70.5%	105	platform.core.execute_esql
T6: Search recent tickets	221	143	35.3%	78	platform.core.search
T7: Search escalated cases	198	128	35.4%	70	platform.core.search
T8: ES\|QL stats by priority	140	36	74.3%	104	platform.core.execute_esql
TOTALS	1,284	467	63.6%	817

技术准确性验证：

准确性检查	结果	详情
ES\|QL 语法保留	PASS	FROM, WHERE, STATS, SORT, LIMIT 完全一致
字段名称保留	PASS	account_id, sentiment_score, product_area 完全一致
索引名称保留	PASS	support-tickets, salesforce-cases 未改变
Case ID 保留	PASS	CASE-0012, CASE-0002 完全一致
账户名称保留	PASS	Pinnacle Financial, United Oil Gas Corp 完全一致
数值保留	PASS	情感分数 -0.94、-0.88；天数 18、7 完全一致
优先级/状态标签	PASS	Critical、Escalated、Open 完全一致
空值保留	PASS	低优先级 resolution hours 的 null 保留
错误信息保留	PASS	工具校验错误按原文完整保留

这对 Elastic 用户的意义

对于在 Elasticsearch 上构建 AI 助手的团队来说，64% 的 token 减少意味着在规模化场景下 64% 的输出成本节省、更快的流式响应，以及更多上下文窗口空间可以留给真实数据，而不是冗余填充内容。当你在凌晨 2 点调试 ES|QL 查询时，你不需要一个 AI 告诉你"很乐意帮你"；你只需要查询结果本身。

更大的图景：重新思考 AI 接口

这个实验揭示了一个本质问题：对话式 AI 接口优化的指标可能是错位的。它们优化的是"听起来像人"，但用户往往只想要准确、快速的数据。

对于技术工作流，尤其是数据查询，有一个很强的理由去做模式切换：

对话模式：用于探索或学习
原始模式（caveman mode）：用于明确知道自己要什么并且需要快速结果时

Elastic MCP server 使这一点成为可能：它返回结构化、准确的响应，在两种模式下都无需修改即可使用。

elastic-caveman 如何工作

elastic-caveman 是一个 Agent Skill，本质上是一个带 YAML front matter 的 markdown 文件，任何兼容的 AI agent 都可以读取并遵循它。没有运行时、没有二进制文件、没有 API 调用。只有改变 agent 与 Elasticsearch 交互方式的指令。

安装方式如下：

复制代码

npx skills add srikolag/elastic-caveman

支持的 agents：Claude Code、Cursor、Codex、Windsurf、GitHub Copilot、Gemini CLI、Roo

触发方式：/elastic-caveman

禁用方式："normal mode" 或 "verbose"

实际运行效果

我们使用 Claude 模型测试 elastic-caveman，以衡量其对 token 使用量和成本的影响：

使用 elastic-caveman：输入 368 tokens，输出 1.6k tokens，总成本 $0.11。
未使用 elastic-caveman：输入 367 tokens，输出 1.8k tokens，总成本 $0.12。

Prompt: Get me the critical support tickets from the support-tickets index in kibana for Pinnacle Financial

该测试展示了 elastic-caveman 的效率提升。
https://www.bilibili.com/video/BV1JD9bBJEhh/

接下来是什么

caveman mode 只是一个开始。可以考虑动态模式切换：在一次会话中随时在精简模式和对话模式之间切换。或者采用混合方式：成功时保持简洁，在错误发生时切换为解释型输出。也可以为团队定义自定义 verbosity 等级，在两者之间找到平衡点。目标不是让 AI 助手变得机械，而是让用户能够控制信噪比。

自己试试

在你的 Elasticsearch 数据上测试 caveman mode：

启动 Elastic MCP server
安装 elastic-caveman
在 normal mode 和 caveman mode 下分别运行查询
对比 token 数量与准确性
完整评估方法与脚本可在 GitHub 仓库中获取

核心结论

在 8 个真实 Elasticsearch 场景中，elastic-caveman 实现了平均 64% 的 token 减少，同时零准确性损失，并且 100% 保留 ES|QL 语法、字段名称和技术数值。

有时候最好的 AI 回复并不是最 "啰嗦" 的那个。有时候你只需要数据本身；而使用 elastic-caveman，你可以让它快 64%。

准备优化你的 Elasticsearch AI 工作流了吗？可以查看 Elasticsearch Labs 获取更多教程、集成与 AI + Elasticsearch 研究内容，或者直接开始使用 Elasticsearch 构建应用。

想优化你的 Elasticsearch AI 工作流？查看 Elasticsearch Labs 获取更多教程、集成与研究内容。准备亲自试试？现在就开始用 Elasticsearch 构建吧。

原文：https://www.elastic.co/search-labs/blog/elastic-caveman-ai-token-reduction