作者来自 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! Id 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-cavemanelastic-caveman 验证了一个简单假设去除 AI 响应中的 “对话噪音”只保留信号并测量其影响。方法如下普通模式完整的对话式 AI 输出包含问候、解释和结束语。原始 caveman 模式只返回原始数据仅保留最小结构标签。我们使用 MCP在一个真实的 Elasticsearch 实例上进行了测试数据来自实际的 support ticket 和 Salesforce case在 8 个生产场景中对两种模式进行对比。结果64% token 减少准确性为零损失以下是我们在 8 个真实 MCP 工具调用中观察到的结果Elastic-Caveman 项目成功在不影响质量或功能的前提下优化了 AI 响应大小。MetricResultScenarios tested8Success rate88%Token reduction63.6% averageTotal normal tokens1,284Total Caveman tokens467Tokens saved817Max reduction (single scenario)91.5%关键保留项0% 损失技术准确性API 路径ES|QL 语法字段名称关键发现每一个字段名、case ID、ES|QL 查询、账户名称以及情感分数都被完全保留——不是近似保留而是完全一致地保留。真实示例前后对比示例 1列出索引减少 87%用户Show me my indices/显示我的索引普通模式107 tokensOf course! Id be happy to help you see your indices. Heres 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 whats stored in your cluster:-- salesforce-cases-- support-ticketsThese are all the indices I found. If youd like to dive deeper into any specific index, just let me know and Ill 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 areaNormal mode (208 tokens):Sure thing! Id be happy to help you write that ES|QL query. What youre looking for is a query that will filter for open tickets with critical priority and group them by product area. Heres how you can accomplish this...【普通模式输出】150 tokensCaveman mode (52 tokens):FROM support-tickets WHERE status Open AND priority Critical | STATS count COUNT(*) BY product_area | SORT count DESC | LIMIT 100 Filters opencritical, 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 ticketsCaveman 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%载荷较小普通模式中的冗余内容最多ESQL 生成70–75%数据密集型搜索35–40%实际数据占比高可删除的“冗余内容”较少完整评估拆解在针对真实 MCP 数据的 8 个场景中不同查询类型的 token 节省情况如下场景普通 tokensCaveman tokens减少比例T节省 tokensMCP 工具T1: List all streams1181091.5%108platform.streams.list_streamsT2: List indices1071486.9%93platform.core.list_indicesT3: Get index mapping1434072.0%103platform.core.get_index_mappingT4: Generate ES|QL query2085275.0%156platform.core.generate_esqlT5: Execute ES|QL aggregation1494470.5%105platform.core.execute_esqlT6: Search recent tickets22114335.3%78platform.core.searchT7: Search escalated cases19812835.4%70platform.core.searchT8: ES|QL stats by priority1403674.3%104platform.core.execute_esqlTOTALS1,28446763.6%817技术准确性验证准确性检查结果详情ES|QL 语法保留PASSFROM, WHERE, STATS, SORT, LIMIT 完全一致字段名称保留PASSaccount_id, sentiment_score, product_area 完全一致索引名称保留PASSsupport-tickets, salesforce-cases 未改变Case ID 保留PASSCASE-0012, CASE-0002 完全一致账户名称保留PASSPinnacle Financial, United Oil Gas Corp 完全一致数值保留PASS情感分数 -0.94、-0.88天数 18、7 完全一致优先级/状态标签PASSCritical、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支持的 agentsClaude 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