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-ticketsSaved: 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 的效率提升。
接下来是什么
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