作者：来自 Elastic 朱杰
一次生产故障，诊断 Agent 在几分钟内发起了数百次日志查询。每次查询慢一秒，整条诊断链路就多等几分钟 ------ Agent 还没开始推理，SLA 已经烧完了。
日志检索的成本模型，正在被一件事彻底改写：查询的发起者，从人换成了 Agent。
而这一次，钟摆不会停在历史上的任何一端 ------ 因为 Elastic 已经把四个时代的所有形态，做进了同一套引擎里面。
一、钟摆的四段史
每一段摆动，都由三个变量决定：谁在查、查多少次、要多快。 从来不由技术时尚决定。
1. schema-on-read 时代：轻 schema，重扫描
以 Splunk 为代表：日志按时间戳分桶压缩落盘，hot/warm/cold 分层，字段级 schema 延迟到查询时才抽取，索引层只保留时间分桶与关键词位置。
驱动力很朴素：日志格式高度不确定，先存下来再说。
2. 老 ELK 时代：schema-on-write，重索引，轻扫描
入库即建倒排索引，全文检索毫秒级。代价是写入 CPU、索引膨胀、存储成本。
驱动力换了：人要搜得爽。 可观测性从事后排查，变成了日常操作台。
3. 降本叙事时代：列存 + 暴力扫描
只对时间戳和标签建索引，原始日志文本不建索引。查询时先按时间戳和标签小范围定位，再用 CPU 实时扫描。列式存储 + 高压缩 + SIMD 向量化 + 多核并行，让 "暴力扫描" 变得可以接受。新版本 ELK 也支持这种模式。
这个方案成立，靠四个前提：
- 低价值日志，先落盘归档
- 不知道将来会怎么分析
- 大部分时候在应用出错时事后排查
- 查询频次低------这条最少被明说，却是整个方案的地基
驱动力再换：日志量指数增长，存储成本压倒一切。
4. Agent 时代：钟摆又回到了索引方案，但不是那个旧 ELK
Agent 一上岗，第四条前提直接失效。存储换计算的轨道重新成立 ------ 不是技术翻烧饼，而是成本函数的自变量换了人。
摆锤又回到了索引方案：Agent 要的正是当年 ELK 给人的东西 ------ 入库即索引、毫秒级命中、高并发不退化，用存储换速度 。于是出现一个反直觉的结论：被 "降本" 叙事宣判过时的那套东西，正在被 Agent 重新需要。
但如果真的只是回到旧 ELK，那纯扫描这些年就白走了：重新背上索引膨胀的锅，也装不下海量低价值日志。
真正的答案是：Elastic 已经自我革新，把四段历史全部收进了同一套引擎 - 全新的 ELK 9.5。
- schema-on-read → runtime field，写入时不定义、查询时才抽取，零写入代价
- schema-on-write → 高度优化的各种索引和多样的文本搜索一直都在那里，服务高价值日志的极速检索
- 硬扫描 → ES|QL 列式向量化执行 + SIMD + 多核并行，覆盖不建索引的原文
- 纯列式存储 → logsdb columnar / synthetic source，把索引与存储膨胀压回可接受区间
- 向量与混合检索 → 外加一层旧 ELK 根本不存在的能力，支持语义和多模态及知识库联合搜索
- 新的高性能时序数据库 → 一条查询内就可以关联日志、指标、分布式追踪多源数据
钟摆没有在四个时代之间选边，Elastic 把四个时代变成了同一根旋钮上的四个刻度。 每一类日志、每一个生命周期阶段，各自落在成本曲线的最优点上------共用一套查询语言、一套权限模型、一套 Agent 接入面、把日志扩展到全面的可观测
为什么查询频次会暴涨到跨越临界点？为什么日志系统还需要 向量检索 ？往下看。
二、成本交叉点：摆锤为什么必然回摆
- 扫描方案 ：建库成本低，成本几乎全部发生在查询时，随查询次数线性累加
- 索引方案 ：建库时一次性付出，之后每次查询成本极低，近似与查询次数无关
两条曲线必然相交。交点的横轴不是数据量，是查询频次。
人类时代，一天几十次查询，规则检测数百次，远在交点左侧；Agent 时代，单个 Agent 一次任务几百次查询 × 7×24 巡检，跨过交点若干个数量级。
延迟同样有交叉：扫描延迟随命中数据量增长、方差大；索引检索近似常数、可预测。
交点的具体位置因场景而异，难以精确量化------这恰恰说明它必须是可配置项，而不是厂商替你选定的架构。
三、重新定义高价值日志
什么是高价值日志？业务运行关键日志 （交易链路、支付、订单状态机）和企业安全关键日志（认证、权限变更、外联行为、审计）。
它们的特征不是事后排查，而是：
- 高频定时检测
- 定时预防业务中断
- 及时发现安全漏洞
判断一份日志该不该建索引，不看它"是什么"，看五项：查询频次、延迟要求、业务关键性、谁在查(人/规则/Agent)、生命周期阶段。
正确的架构是分层，不是二选一：
| 层级 | 策略 | 服务对象 |
|---|---|---|
| 高价值层 | 全字段索引 + 向量索引 | Agent 高频检测 |
| 中间层 | 只索引热点字段，其余仅保留列式 doc_values | 常规查询 |
| 归档层 | 纯扫描 | 低频备查，成本最低 |
同一份数据可以随生命周期在层间迁移。钟摆的两端不是对立面，是配置项。
四、Agent 如何改变日志查询
不只是"变多了"，是四个维度同时变化。
1. 数量：乘法级放大
2026 年 8 月， Anthropic 公布一个未发布研究版 Claude 将黎曼 ζ 函数临界线上非平凡零点比例的下界从 41.6% 提升到 67.2%。实现方式：主 Agent 协调约 60 个子 Agent，合计执行约 2400 条 shell 命令、编写数百个 Python 脚本、完成数千次数值验证并互相审阅。
把"数值验证"换成"日志检测"，把"shell 命令"换成"日志查询"------这就是一次运维诊断任务的真实形态。
再叠加分级触发的乘法效应：初级巡检发现异常 → 触发高级诊断 Agent → 再 fan-out 一组子 Agent。7×24 不间断，没有下班时间。
2. 模式：从经验命中到假设验证
人靠经验一次命中；Agent 靠广度做假设验证， ReAct 循环里每一步推理都伴随一次查询。
Agent 宽泛扫描返回的海量原文会直接撑爆 context window。所以 Agent 需要的不是"能扫完"，而是过滤与聚合能下推到引擎侧，一次返回精确结果。
3. 延迟：预算被步数放大
Agent 链路是串行的：20 步 × 单次 10 秒 = 200 秒，没人会等。 LLM 推理本身已吃掉大部分时间预算，留给检索的窗口极窄 ，而且编排系统需要的是可预测的延迟 ------ 扫描延迟的方差天然更大。
4. 并发：扫描不是慢一点，是退化
多个 Agent 并发扫描，互抢 CPU 与 IO 带宽。扫描没有可复用的中间结构，第 N 个并发查询不会因为前 N-1 个而变便宜。 索引检索资源占用小、缓存友好、天然高并发。
扫描方案在 Agent 并发下不是 "慢一点"，是 "全面退化"。
五、不只是索引回归：Agent 排障需要"日志 + 知识"的联合检索
这是本轮钟摆和历史上任何一次都不同的地方。
人和 Agent 的根本差异
人看到一条报错，脑子里立刻浮现"这个我见过"------检索发生在人的记忆里。Agent 同样需要搜索 记忆 ，它的"经验"必须被外部化成可检索的语料。
所以 Agent 排障 = 日志检索 + 知识库检索 + 记忆检索，缺一不可。
Agent 需要检索的几类非日志语料
- Agent 自身的长短记忆：
- 运维知识库与 Runbook：告警处置手册、SOP、变更规范
- 代码与配置：用报错信息反查抛出点、调用链上下文、近期变更
- 软件设计与架构文档：服务依赖、容量假设、超时与重试的设计意图
- 历史故障记录(最有价值)：过往 incident、RCA 报告、工单与处置结论
为什么必须是向量检索
日志里写的是 connection reset by peer，知识库里写的是"连接被重置"------关键词永不相交，语义高度相关。 报错文本的字面表达每次都不同(堆栈、ID、主机名各异)，但故障模式相同。关键词检索要求提问者已经知道正确术语，而 Agent 恰恰不知道。 "给定一条错误日志，召回历史相似故障"------这是语义和混合检索问题
一次 Agent 诊断，需要引擎同时提供四种能力
| 能力 | 用途 | 底层依赖 |
|---|---|---|
| 全文与结构化检索 | 定位具体错误日志 | 倒排索引 |
| 聚合与基线统计 | 异常检测、突增识别 | 列式 doc_values |
| 跨信号关联 | logs + metrics + traces 联查 | 统一查询层 |
| 语义召回 | 匹配知识库与历史故障 | 向量索引 + 混合检索 |
关键论断：这不是四个系统，必须是一个系统
拼装方案意味着：4 套 API、4 套权限模型、4 份数据副本、4 处延迟。跨系统关联只能在 Agent 侧做，等于把 join 塞进 LLM 的 context------既贵又不可靠。
Agent 需要的是一次调用拿到已关联好的证据包，而不是自己去缝合。
现代日志系统的能力边界已经外扩：它不再是"日志搜索引擎"，而是 Agent 的证据检索层。
钟摆不是回到原点，是螺旋上升：索引层不仅回来了，还多了 向量索引 这一层；列存与暴力扫描也没有被丢弃，而是下沉为低价值数据的档位。
六、为什么几乎只有 Elastic 能满足全部条件
把第五节的四项能力和四个时代的档位放在一起对照，答案自然浮现：
- 列存日志引擎：扫描强，但缺倒排与向量，知识库类语料无处安放，Agent 高频高并发下退化
- 向量数据库：语义强，但没有日志的时序、聚合与保留期治理能力
- 传统 schema-on-read 方案：灵活，但达不到 Agent 要求的延迟与并发
- 多系统拼装：回到上一节的困境 ------j oin 塞进 context
而 Elastic 在同一套引擎里同时给出：倒排索引、列式存储与向量化扫描（ES|QL）、runtime field、logsdb、向量与混合检索、以及从 index： false、match_only_text、doc_values-only 到稀疏/稠密向量的连续可调索引粒度------索引不是开关，是旋钮。生命周期策略让数据在档位之间迁移，不搬家、不换栈。
这不是 Elastic 多了一个功能，而是 Agent 时代的需求，恰好落在了 Elastic 长期积累的能力交集上。
Agent 上岗后，衡量标准从"每 GB 存储成本"变成了"每个 Agent 任务的端到端成本与延迟"。
Agent 不会抱怨查询慢。它只会失败，或者悄悄烧掉你十倍的算力预算。