导读：本文以一次灰度发布故障为完整演示，拆解阿里云 Elasticsearch 9.4 Agent Builder 如何用 Skill 固化经验、用 Tool 锁定口径、用 Workflow 守住人工确认，做到能力可复用、权限不放开、审批不跳过。
开篇：一条告警，为什么总要查这么久
处理过线上告警的人大概都熟悉这个场景：一条 5xx 告警弹出来，确认"服务在报错"只要几秒，但接下来的调查才是真正耗时的部分。找索引、选时间窗口、写查询、比版本、提取 trace、翻发布记录、核对回滚规则、整理审批单------每一步都不难，难的是串起来做，而且换个人来查，口径和顺序可能又不一样。更关键的是，这些经验往往只存在于个别工程师的脑子里，既没法复用，也没法审计。
阿里云 Elasticsearch 9.4 的 Agent Builder 把这些环节收拢到一处。团队把排查经验写成 Skill，把数据接口写成 Tool，Agent 根据用户请求组织调用；碰到需要人拍板的步骤，交给 Workflow。查询继续走 Elasticsearch 的权限体系，生产动作继续走既有审批。能力可以复用，边界也得以守住。
Agent Builder 核心对象只有四个：Agent Chat、Agent、Skill、Tool。Workflow 通过 Workflow Tool 与 Agent 协作，处理确定性流程和人工确认。各对象的定义见 Agent Builder 技术文档，阿里云侧的模型接入步骤见阿里云 ES Agent Builder 使用指引。具体能力如下：
下面用一次灰度发布引发的登录故障走一遍完整流程。演示运行在阿里云 Elasticsearch 9.4 实例上，大模型通过 AI Connector 接入 AlibabaCloud AI Search 接口（演示模型选择 qwen3-max）。日志统计、发布记录、策略阈值和流程状态均为实际调用返回。
登录接口触发 5xx 告警，灰度发布刚过去十几分钟。值班人员确认异常后，在 Kibana Agent Chat 里打了一句话：
分析最近 13 分钟的登录失败日志。影响有多大？错误集中在哪个版本？十几分钟前刚发布的
auth-service灰度版本是否相关？如果已经满足回滚条件，请发起审批。
一句话里包含了四个子任务：定量影响面、定位版本、关联发布、触发审批。Agent 会按 Skill 规定的顺序逐步处理，而不是把所有查询一股脑丢给模型。下文将分 5 部分对视频 Demo 中的内容作详解。
一、数据基础：字段统一，权限锁死
调查要对比发布前后、对比稳定版本和灰度版本，前提是字段定义一致------时间、环境、服务、版本、状态码如果各写各的，错误率根本没法比。
演示数据共 26,400 条访问日志，按固定规则生成：发布前后各 12,000 条生产登录日志，另有 1,200 条 staging 登录日志和 1,200 条 production 支付服务日志。后两组不参与故障统计，专门用来验证权限隔离。
所有日志入库前经过同一条 Ingest Pipeline：校验必填字段，统一映射为 @timestamp、service.name、service.version、http.response.status_code、trace.id、error.type、deployment.id，同时删除令牌和用户标识。
这里的关键是权限隔离。Agent 使用的角色只能读取 production 环境的 auth-service 日志及对应发布策略，staging 数据和支付服务日志对它完全不可见。用第二个演示账号验证：能查到 24,000 条生产登录日志，staging 和支付服务返回 0。也就是说，Agent 看到的数据和人工查询完全一样，不会因为接了 LLM 就多看到任何东西。机制详见阿里云 Elasticsearch 高安全性能力。
到这一步，字段结构和可见范围已经对齐，后续所有查询都可以在 Kibana 中重复执行。
二、定量：影响面有多大，问题在哪个版本
告警只告诉你"有 5xx"，不告诉你多严重、谁在报错。Agent 调用的第一项 Tool 是 login_logs.summarize_failures------接收起止时间，用参数化 ES|QL 按版本统计请求量、5xx 数量和错误率。
结果很明确。分析窗口内共 12,000 次生产登录请求，986 次返回 5xx，整体错误率 8.22%。但按版本拆开看：
灰度版本只承接了 10% 的流量，却贡献了 97.36% 的失败。稳定版本错误率 0.24%，基本是背景噪声。方向很明确：后续调查集中在灰度版本。
另外值得注意的是，查询口径是写死在 Tool 里的------索引、环境、服务、接口、计算公式、返回字段都是预定义的。用户换个问法，底层查询不会跟着变。配置方式见 ES|QL Tool 文档。
三、深入灰度版本：什么错、哪台机器、哪条 trace
知道"灰度版本在报错"还不够，得知道报什么错。Agent 接着调用两项 Tool：
960 次失败的分布：SQLTransientConnectionException 840 次，DataAccessResourceFailureException 90 次，TimeoutException 30 次------几乎全跟数据库连接有关。样本还返回了 deployment.id=DEP-20260715-018、主机名和 trace.id，拿着这些就能去查调用链和应用日志。
这个调用顺序不是模型自己发挥的。login-log-investigation Skill 写死了排查路径：先统计整体和版本分布→错误集中时对异常版本做归类和取样→需要判断发布关联时再查发布记录和回滚规则。Skill 还要求回答里标明分析窗口，区分"日志统计事实""关联判断"和"待验证项"，避免把推测说成结论。
演示中还用到了其他类型的 Tool：Index Search Tool 检索运行手册和历史排障资料，回滚阈值由参数化 ES|QL Tool 查正式策略记录，CMDB、工单、发布平台等外部系统则通过 MCP Tool 接入。四类 Tool 各有各的边界。
四、关联发布：那次灰度改了什么
错误全指向数据库连接池，而灰度版本恰好在告警前十几分钟刚发布。是巧合还是因果？得看发布记录和回滚规则怎么说。
login_logs.retrieve_release_policy 返回两条关键信息：
-
发布记录 ：灰度版本于告警前 16 分钟按 10% 流量发布，变更内容是把数据库连接池
maxPoolSize从 50 调到 10。 -
回滚策略 （
POL-REL-ROLLBACK-002）：灰度版本 5xx 错误率连续 5 分钟 ≥ 5%，且稳定版本 < 1%，即可发起回滚审批。
对照日志数据：灰度版本错误率 80%，稳定版本 0.24%，阈值条件满足。发布时间、配置变更（连接池缩容 5 倍）、错误类型（连接获取失败）三者完全吻合，足以提交回滚审批。当然，根因确认是回滚之后的事------观察指标是 10 分钟内整体 5xx 回落到 1% 以下，连接池超时不再持续出现。
五、审批：Workflow 停住，等人拍板
Agent 判断条件满足后，加载 production-rollback-approval Skill。这个 Skill 专门做参数校验：服务名、异常版本、目标版本、分析窗口、证据摘要、策略编号、验证计划，七项缺一不可。全部齐全后，才调 login_logs.request_rollback_approval 启动 Workflow。
Workflow 走到 waitForInput 就停住了，状态变为 Waiting。当班负责人看到版本、日志统计、策略编号和验证计划，然后决定批准、拒绝或要求补充材料。等待期间生产环境不会有任何变化。批准后 Workflow 状态变为 Success。
Agent Chat 保留了三轮对话中所有 Tool 调用和返回结果，每一步判断都可以回溯。阿里云另外提供了 Elasticsearch Agent Skills，可以检查实例、节点和集群健康状态。
回顾整个过程：ES|QL Tool 管查询，Skill 管顺序，Agent 根据上一步结果决定下一步调什么，Workflow 管需要人签字的环节。权限没绕过，审批没跳过，每一步都有调用记录可查。欢迎参考 Agent Builder 使用指引，和阿里云 Elasticsearch 9.4 一起开启 AI Agent 高效新体验。