Al Search x ES Agent Builder:让数据活起来，从搜索走向行动

导读 当 AI 应用从“回答问题”继续向“推进任务”发展，系统面对的要求也随之变化。自然语言交互解决的是理解、生成与总结；Search / RAG 把外部与企业数据接入上下文；Tools + Workflow 进一步把查询、计算与受控动作封装成能力，并用确定性流程组织起来。到了 Agent 阶段，系统开始围绕目标选择工具、多步推进，并根据中间结果调整下一步。但越接近行动，对上下文质量、工具边界、权限和执行过程的要求就越高。

这也是 ES Agent Builder 所要解决的问题：不是再提供一个“会回答”的入口，而是把 Elasticsearch 中的数据事实、可调用工具与治理机制组织进同一条执行链，让自然语言问题能够落到授权数据，查询和分析过程可以复核，必要的下一步动作也始终处于显式配置和可检查的边界内。

主要内容包括以下几个部分：

1. 从回答到行动，真正的难点在数据、口径和执行之间

2. 可信 Agent 的核心，不仅是生成查询，还要把三类能力放进一次执行

3. 把“可信”拆成三个边界，才能让执行过程真正可检查

4. 日志分析案例：把一次自然语言提问变成可复核的 ES |QL 执行链

5. 从一次对话到生产能力，关键是选择正确的封装层级

01

从回答到行动，真正的难点在数据、口径和执行之间

企业内部的数据往往已经沉淀在日志、文档、指标、历史记录和告警系统中，但用户提出问题时使用的是自然语言。第一个问题是两者之间存在数据断点：模型能够理解问题，却未必能直接访问真实数据。Search / RAG 可以补充外部上下文，但距离进一步的查询、分析和行动仍有差距。

第二个问题是查询路径和业务口径难以复用。同一个故障或指标问题，不同人员可能采用不同的字段、过滤条件、聚合方式和排查路径，结果容易依赖个人经验，也难以沉淀为稳定、可测试的能力。

第三个问题发生在答案之后。进入生产环境后，还需要解决数据权限、执行留痕、结果核验、过程复现以及外部能力调用等问题。ES Agent Builder 的定位，就是把 Elasticsearch 的检索与分析能力组织成 Agent 可调用的 Tools，并通过角色、API Key 和工具配置限定能力边界，减少额外的数据接口与权限拼接，让数据查询、工具调用和治理进入同一条执行链路。

02

可信 Agent 的核心，不仅是生成查询，还要把三类能力放进一次执行

生成查询只是起点。要让 Agent 真正完成任务，还需要数据事实、工具能力和治理机制协同工作。Elasticsearch 提供日志、文档、指标、告警等事实数据和访问控制；Tool 将自然语言意图转换为具体查询、分析和受控动作，并可通过参数化方式固化高频口径；治理机制则保证调用过程、参数、结果和异常可追踪、可复核。

在架构上，底层 Elasticsearch 负责事实数据与权限边界，中间模型层负责理解意图、规划步骤和总结结果，上层 Agent Builder 负责组织 Agents、Tools 和 Skills 的执行。一次请求通常经历“理解目标—选择能力—查询数据—推理返回—执行与留痕”几个环节，结果再按配置进入反馈和沉淀。

需要强调的是，Tool、Workflow 和外部动作不会自动执行，都需要显式配置、授权和校验。这样，Agent 的能力才不是单纯“生成答案”，而是在明确边界内完成可检查、可追踪的执行。

03

把“可信”拆成三个边界，才能让执行过程真正可检查

对于进入生产链路的 Agent，“可信”不能只依赖最终答案看起来是否合理，而要拆成可检查的机制。分享中将其归纳为数据边界、执行边界和运行边界。

数据边界首先回答“谁可以看什么”。查询沿用当前用户的角色与索引权限，结论能够回到授权范围内的 ES 数据。这样一来，自然语言只是入口，并不会绕开既有的数据访问边界。执行边界回答“系统做了什么”。Query DSL / ES|QL 可以被查看和复核，确定性步骤可以由 Workflow 固化；重要分析不再只留下一个自然语言答案，而是留下查询和流程证据。运行边界关注“过程如何被治理”，包括按配置保留调用、结果与异常证据，以及通过 MCP、A2A、REST 等方式对接外部能力。外部连接本身并不意味着无限执行，它仍然受配置、授权和流程约束。

这三个边界对应的不是三个独立模块，而是一条执行链上的连续约束。权限限制数据可见范围，查询和流程留下可复核证据，对外部能力的调用则始终处于显式配置中。对于日志分析、知识问答和运维排障这三类不同场景，输入的数据类型和任务目标虽然不同，但价值路径相同：先从数据得到可验证结论，再决定下一步行动。

04

日志分析案例：把一次自然语言提问变成可复核的 ES |QL 执行链

日志分析案例展示了这条链路如何落到具体任务。样例问题是：统计 2026-04-23（UTC）的成功请求，在样本数不少于 20 的 API 中，按平均 RT 从高到低列出Top 3，同时展示 Tool、参数、ES|QL 与结果。测试数据由 240 条合成日志、4 类 API 构成，主要字段包括 @timestamp、status_code 和 rt。

这个问题表面上只是一句自然语言，真正执行时却包含多个必须固定的口径。第一层是时间和状态过滤：统计窗口固定在 2026-04-23（UTC），成功请求限定为 2xx / 3xx。240 条日志中，共有 228 条成功请求进入本次统计。第二层是统计口径：按 API 聚合，计算 COUNT、AVG和 MAX，同时要求 COUNT(*) ≥ 20，再按 AVG 降序排列并返回 Top 3。样本门槛的作用，是避免极小样本直接进入排序。

在执行过程中，Agent 先识别目标与约束，然后调用参数化Tool。实际调用的 Tool 为 api_success_latency_rank，访问的索引为 api_access_logs。参数化 Tool 固化关键口径，Agent 负责理解自然语言并完成调用；生成的 ES|QL 则把时间、状态、样本门槛以及 COUNT / AVG / MAX、排序规则显式表达出来。这样，分析逻辑不再隐藏在一段模型回答中，而是转换成可以再次执行的查询证据。

案例返回的 Top 1 是 order_submit，平均 RT 为 1,250 ms，成功请求为 54。更重要的并不是这一个数字，而是结果同时保留了 Tool、参数、ES|QL 和返回数据。为了验证 Agent 的执行过程，可以直接在控制台独立执行同一条 ES|QL，核对 228 条成功记录和Top 3 是否一致。也就是说，验证对象从“模型说得像不像”变成了“同一口径能不能被独立复算”。

这个案例同时明确限定了结论边界：当前结果只能证明某个 API 存在延迟现象，不能直接证明根因。Agent 不应该因为看到平均 RT 较高就自动补出一个原因。根因仍然需要继续查看错误日志、Trace、指标以及变更记录。这里的处理方式是“现象 → 证据 → 下一步核验”，而不是从现象直接跳到推断。对于生产场景，这种结论边界与固定口径同样重要。

05

从一次对话到生产能力，关键是选择正确的封装层级

如果每次问题都依赖动态生成查询，灵活性很高，但稳定性、复用和审计都会受到限制。分享中把从一次对话走向可复用能力的过程分成三个层级：动态检索、参数化分析和流程与行动。

动态检索适合探索性问题以及数据范围变化较大的场景，可以允许动态生成查询，但需要检查语句与结果。当某一类分析频繁重复、口径已经明确时，更适合把它沉淀成参数化 ES|QL Tool，将关键条件设计为带类型的参数，使输出结构更稳定，也更便于测试、复用和审计。再往前一步，如果任务需要组织多个工具、领域步骤或外部动作，就进入 Skill / Workflow 层。越接近写操作和跨系统行动，对授权、审批和回滚的要求越高。

因此，生产化不是简单地把更多能力都交给 Agent，而是把不同稳定度、风险等级的任务放到合适的封装层：探索问题保留动态性，高频口径固化为 Tool，多步骤行动进入 Skill / Workflow。这样既保留自然语言交互的灵活性，也让关键分析和执行路径逐渐变成可测试、可复用的系统能力。

执行链跑起来之后，还需要利用运行结果继续改进能力。给出的参考架构中，Agent 执行产生问题、工具调用与结果，反馈和审计信息写回 ES；随后由 skill-distill 每 24 小时提炼候选建议，再经过人工复核确认风险、口径和优先级，最后将建议更新到Tool、Skill 或路由配置。该架构明确不是开箱即用的全自动流水线，候选优化仍需要证据、人工复核和发布治理。

这也构成了完整的三步路径：先接入数据与模型，让问题能够落到授权数据；再验证答案与行动，让查询、结果和下一步都可检查；最后建立反馈与治理，把运行过程本身变成后续改进的依据。对于 Agent 的落地，与其一开始追求覆盖更多复杂任务，更适合先选择一个高频、数据密集、结果可以核验的场景，把数据事实、工具能力和治理机制真正接成一条闭环。

结语

从 Chat、Search / RAG 到 Tools + Workflow，再到 Agent，变化并不是前一阶段被后一阶段替代，而是能力不断叠加。真正影响 Agent 能否进入实际流程的，也不只是模型是否能够理解问题，而是数据能否在权限范围内被访问，关键口径能否被固化，执行过程能否留下证据，动作能否始终受控，以及运行结果能否进入下一轮改进。

Elasticsearch Agent Builder 所展示的实践路径，最终落到一个非常具体的原则：先让自然语言问题抵达真实数据，再把高频、可验证的分析沉淀成 Tool，把跨步骤任务组织进 Skill / Workflow，并用权限、留痕、复核和人工治理约束整个执行过程。这样，Agent 才不是只停留在“解释数据”，而是能够在边界清晰、过程可检查的前提下，从搜索继续走向行动。

点个在看你最好看

SPRING HAS ARRIVED