一、先说结论：贵的不是"思考"，是"搞清楚数据是什么"
过去一年，企业给 AI Agent 算账时，注意力几乎都压在"每百万 token 单价"上，仿佛只要模型够便宜，落地就顺理成章。但真正跑在生产里的团队会发现，一笔被长期低估的成本并不发生在推理本身，而发生在推理之前——Agent 为了搞清楚"我面对的数据到底是什么意思"，反复付出的探索开销。Elastic 在 2026 年 10 月的一篇工程博客里，把这块成本第一次量化到了一张对照表上：同一个 Agent、同一个模型、同一份数据，唯一的区别是能不能读到预先算好的上下文，结果输入 token 从约 228 万降到约 65 万，工具调用从 33 次降到 9 次，端到端延迟从 213 秒降到 64 秒。
这组数字很抓眼球，但必须先给它套上口径的缰绳：它是厂商自测、单次对照实验（n=1）的结果，场景是一道被特意挑选出来的"账户分析"战略问题，运行时模型标注为 claude-sonnet-5、外加 LangChain Deep Agent Harness，预算时（预计算上下文）用的是更小的 claude-haiku-4-6。换句话说，这不是一项独立第三方的基准测试，也不覆盖任意企业数据，更不能直接搬到你的工单库或合同库上得出"我也能省 71%"的结论。它真正的价值，不在百分比本身，而在于指出了一类此前没有名字的成本——数据发现成本。
二、什么是"数据发现成本"：每次提问都重新认识一遍世界
博客给这类 Agent 的定位很直白：查询企业数据的 Agent，会把大部分 token 消耗在"数据发现"上，也就是搞清楚有哪些 schema、字段代表什么业务含义、实体之间在庞杂的文档和数据源里如何相互关联。麻烦在于，即使这些数据没有任何变化，Agent 下一次被问到时，仍会把这整套认知流程从头再做一遍。
作者举了一个很具体的反面例子：向数据 Agent 提出"总结一下影响我们最大客户的那些问题"。一个能力不错的 Agent 在没有辅助时会这样动作——先列出所有索引，弄清哪些数据存在；再读 mapping，判断哪个字段表示"客户"、哪个表示"问题"；然后扫描合同，给每个客户账户估值，找出最大的那个。就在这个过程里，它很可能漏掉一个关键事实：有 5 个账户其实隶属于同一家母公司，于是它把"最重要的客户关系"给算小了；它也不知道 account_id 在 tickets 索引里有时为 null，于是查询在无声中返回了错误的部分数据行。
这里的洞见值得反复咀嚼：模型的推理本身没有错，错在 Agent 在能够开始推理"数据表达的业务含义"之前，已经把大部分预算花在了"弄清楚数据是什么"上。这才是很多企业 AI 账单的隐藏结构——钱不是烧在答案上，是烧在每次重新查户口上。而一旦把问题这样定义，解决方向也就跟着清晰了：能不能让"理解数据"这件事只做一次，而不是每次提问都做一遍？
三、对照实验的完整数字：把厂商的表原样摊开
为了不把结论讲成玄学，把博客里那张核心对照表按原文口径列出。实验强调"相同的 system prompt、相同的模型和数据，唯一变量是 Agent 能否从上下文引擎读取预计算的上下文单元"。表格如下（均为该单次实验值，非统计均值）：
- 工具调用次数：无上下文层 33 次，有上下文层 9 次。
- 输入 token 数量：无上下文层约 2,279,253，有上下文层约 653,511，正文标注降幅约 71%。
- 端到端延迟：无上下文层 213 秒，有上下文层 64 秒。
- 是否发现"母公司—子公司"这层关联：无上下文层"否"，有上下文层"是"。
- 成本：以基线为参照，正文称降低约 71%。
需要补充一个常被标题吞掉的细节：这些节省不是零成本换来的。博客写明预计算阶段处理了约 63.6 万个输入 token，也就是说，系统在你提问之前，先用一套自动化流程把原始数据"读了一遍、蒸馏成结构化的上下文单元"存好。省下来的运行时开销，是把认知工作从"每次查询"前移到了"提前算一次"。这笔账是否划算，取决于同一批数据被查询的频率——问得越频繁、越稳定，预算时的摊销越值；一次性、临时性的探索，预算时的投入可能反而不划算。
四、第二组数字要单独看：别把两个测试平均成一个
同一个 Elastic 团队在另一篇配套文章里，给出了针对其自身支持（support）Agent 的结果：预计算上下文让支持 Agent 的输入 token 减少约 58%、延迟降低约 40%，机制同样是"减少了重复检索"。
这组数字很重要，但绝不能和前面那组的 71%、71% 去求平均，也不能相加，因为它们是两套不同的口径：71%/降 71% 来自一道模拟的账户分析战略问题、特定模型栈、n=1；58%/40% 来自真实的支持问答场景、不同的数据源与衡量方式。把它们揉成"平均能省 65%"是对数据的滥用，也是这类厂商技术博客最容易被下游自媒体误读的地方。正确的读法是：在"每次查询都要重新做数据发现"这类场景里，把上下文预计算出来能显著压成本、压延迟；具体压多少，取决于场景、数据稳定性和模型选型，需要你在自己的数据上重跑，而不是引用别人的百分比。
同时给这两组数据都标注一下立场：它们是利益相关方（上下文层产品的提供方）的自测，天然带着"证明产品有用"的动机。这不等于数字造假，但意味着实验条件、被选题目、模型版本的选择都可能偏向有利结果。把厂商自测当作"机制可行"的证据是合理的，当作"你的项目也能达到"的承诺是危险的。
五、它由哪五块拼成：一个可以对着自查的清单
博客把这套"上下文引擎"拆成五个组件，这个拆解比数字本身更有工程参考价值，因为它告诉你省 token 不是靠某个魔法开关，而是靠一条完整的流水线：
- 数据源：上下文可以来自任意索引或数据流，也可以经由连接器从外部应用取，还能来自 Agent 自己产生的 trace（或通过 OpenTelemetry 从别的框架送过来的 trace）。
- 自动化流程：负责把上下文"喂"进存储。它们是带专用步骤的工作流，会搜索原始内容、用 LLM 或其他模型处理结果、为检索构建结构化输出、校验来源信息、应用访问控制、跟踪状态，最后把知识单元写进专门的索引。
- AI index（上下文存储）：以向量库为基础，带混合搜索能力，schema 和 mapping 专门为"Agent 检索"而设计，存的就是那些预计算好的结构化上下文单元。
- Agent 记忆：随着任务推进，Agent 可以用 remember、recall、forget 三类动作存取记忆；跨组织共享记忆被列为"接下来的路线图"，也就是当时尚未完全落地。
- 反馈循环：每次交互都生成一条 trace，记录 Agent 在哪儿成功、在哪儿受阻、token 花在了哪些环节；循环会在这些 trace 里找低效点，回头建议修改自动化流程。
这套结构里最容易被低估的是"自动化流程可以用小型、低成本模型跑"这一点。博客明确说，预计算阶段可以用更便宜的模型、甚至直接用查询语言来做，省下来的成本会体现在之后的每一次查询上。这就把"要不要上上下文层"从一道玄学题变成了一道摊销题：前期用便宜模型把知识蒸馏一次，后期用贵模型每次提问都少绕路。
六、它想补的是谁的短板：和几种现有方案摆在一起看
上下文工程不是新词。博客自己列了一张"现有方案各自的权衡"表，这张表的价值在于诚实——它没有宣称上下文引擎要取代别人，而是定位为"对现有方案的补充"。把这几种方案摊开，能帮企业 IT 判断自己现在卡在哪一格：
- 静态上下文文件/目录：Agent 读人工写的说明。问题是内容会逐渐过时，也无法从真实使用中学习。
- Agentic RAG：Agent 搜原始数据块，不断循环检索直到满意。问题是每次执行任务都要重新组装知识，且容易漏掉跨文档的关联。
- 用 grep 的编程 Agent：Agent 直接翻文件。问题是慢、费 token，还难判断哪个匹配才是对的。
- 更长的上下文窗口：把数据直接塞进窗口推理。问题是长窗口仍面临上下文退化和注意力问题，而且窗口越长，后续每一轮交互的成本越高。
可以看出，上下文引擎真正瞄准的是两个共性痛点："每次查询的数据发现成本"和"上下文漂移"。前者靠预算时预计算来消除，后者靠"从真实 trace 持续改进"来缓解。理解了这层定位，你才不会把它误当成又一个 RAG 变体——它补的正是 RAG 在跨文档关联和重复组装上的那块短板，前文那个"漏掉 5 个账户同属一家母公司"的例子，就是跨文档关联缺失的典型症状。
七、为什么说"每个阶段其实都是搜索问题"
博客里有一个反直觉但很有用的判断：一般人把"搜索"只当作最后一步的检索动作，但实际上这条流水线的每个阶段都依赖"找到对的信息"。作者把四个阶段各翻译成一种搜索问题：
- 收集（Gather）：要处理从 GB 到 PB 规模的数据，不可能持续全量重处理，得兼顾高召回和高精确——用 Agent 搜索理解意图、用词法搜索做精确匹配、用语义搜索提召回，再靠工作流自动化。
- 构建（Build）：知识单元预先算好 Agent 原本要在运行时自己推导的内容；保留什么、舍弃什么，取决于它将来怎么被检索，所以需要 embedding、元数据字段和为检索设计的组合字段。
- 检索（Retrieve）：放进上下文窗口的内容必须相关、完整又简洁；噪声太多，Agent 会干脆忽略它、转头去重新翻原始数据源——这本质上是个相关性问题。
- 改进（Improve）：trace 和对话记录都是非结构化数据，要发现反复出现的故障及其共同模式，靠的是混合搜索。
这段抽象对企业落地的启示很实在：上下文层的成败，不取决于你买没买某个向量库，而取决于你在"收集—构建—检索—改进"这四段里，每一段的检索质量是不是都做扎实了。任何一段偷懒——比如构建阶段字段设计得不好，或检索阶段噪声太大——最后都会以"Agent 又回去翻原始数据、token 账单反弹"的形式惩罚你。
八、给企业决策者的冷水：三个别急着签合同的理由
把厂商的兴奋劲儿调回去，这篇博客至少有三处必须被写进内部评估的风险项：
其一，样本与场景的脆弱性。所有亮眼数字都建立在一次被精挑细选的模拟问题上，跨场景外推能力完全未经验证；把 71% 写进你自己的立项报告，是在用一个 n=1 的厂商实验冒充你的项目预测。其二，预计算不是免费的午餐。数据一旦频繁变动，预算时算好的上下文就可能过时，你得持续重算，摊销模型随之改变；对高频查询友好、对低频一次性查询未必划算。其三，访问控制与安全被明确放进了这条流水线。自动化流程里专门列了"校验来源信息、应用访问控制"——这意味着上下文层会把大量业务知识预先聚合成结构化单元，一旦权限没配好，它反而可能成为跨权限泄露的新聚合面：Agent 拿到的不再是零散原始记录，而是被蒸馏过、看起来"权威"的业务结论，泄露时破坏力更大。
九、中小企业怎么把这一步走得稳：一个不依赖具体厂商的落地顺序
如果要用一句话把 Elastic 这篇工程博客翻译成企业能执行的方案，那就是：先给你的数据建一层"只算一次的说明书"，再谈降 token。具体可以按这个顺序推进，而不必被某家产品绑定：
- 第一步，量出你现在的"数据发现成本"。挑 3 到 5 个高频 Agent 任务，统计它们在真正回答前平均要做多少次工具调用、消耗多少输入 token。没有这组基线，任何"省了多少"都无法证伪。
- 第二步，识别那些"几乎不变的知识"。哪些是数据源用途、字段业务含义、实体关联关系、常见异常趋势？这些正是预算时该蒸馏的对象，而真正高频变动的部分留给运行时检索。
- 第三步，用便宜的模型先跑预计算。不必一上来就用最贵的模型做上下文生成，先用小模型把结构化上下文单元造出来，把省下来的预算留给真正需要强推理的那几步。
- 第四步，把权限和来源校验前置。上下文单元在生成时就带上访问控制和来源标注，别让"蒸馏后的结论"绕过你原有的数据权限边界。
- 第五步，让生产 trace 反哺上下文。把 Agent 在哪受阻、token 花在哪记录下来，定期回看，持续修订你的预计算流程——这是这套机制和普通"写死的静态说明"最本质的区别：它会从真实使用中学习。
把五步走完，你收获的不会是一个从别人博客抄来的百分比，而是自己数据上的一条新基线。这才是这类"降本故事"对企业真正该留下的东西。
十、一句话总结
这次 Elastic 的实验值得记住的不是"降 71%"这个数字，而是它给一类隐性成本命了名：数据发现成本。当企业把 Agent 从 demo 推向生产，账单里最冤枉的一部分，往往花在 Agent 反复查户口、而不是反复思考上。把"认识数据"这件事从每次提问前移到提问之前、只做一次，是上下文工程给出的解法——但它是厂商的 n=1 自测、需要摊销思维来权衡、并且把访问控制一并推上了台面。真正该做的，是在自己的高频任务上先量出基线，再用便宜模型把稳定知识预算成上下文，然后让生产 trace 持续修正它。数字会因场景而异，但"贵的不是思考、是搞清楚数据是什么"这个判断，大概率在你家也一样成立。