导读本文以一次灰度发布故障为完整演示拆解阿里云 Elasticsearch 9.4 Agent Builder 如何用 Skill 固化经验、用 Tool 锁定口径、用 Workflow 守住人工确认做到能力可复用、权限不放开、审批不跳过。开篇一条告警为什么总要查这么久处理过线上告警的人大概都熟悉这个场景一条 5xx 告警弹出来确认“服务在报错”只要几秒但接下来的调查才是真正耗时的部分。找索引、选时间窗口、写查询、比版本、提取 trace、翻发布记录、核对回滚规则、整理审批单——每一步都不难难的是串起来做而且换个人来查口径和顺序可能又不一样。更关键的是这些经验往往只存在于个别工程师的脑子里既没法复用也没法审计。阿里云 Elasticsearch 9.4 的 Agent Builder 把这些环节收拢到一处。团队把排查经验写成 Skill把数据接口写成 ToolAgent 根据用户请求组织调用碰到需要人拍板的步骤交给 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 接着调用两项 Tool960 次失败的分布SQLTransientConnectionException840 次DataAccessResourceFailureException90 次TimeoutException30 次——几乎全跟数据库连接有关。样本还返回了deployment.idDEP-20260715-018、主机名和trace.id拿着这些就能去查调用链和应用日志。这个调用顺序不是模型自己发挥的。login-log-investigationSkill 写死了排查路径先统计整体和版本分布→错误集中时对异常版本做归类和取样→需要判断发布关联时再查发布记录和回滚规则。Skill 还要求回答里标明分析窗口区分日志统计事实“关联判断和待验证项”避免把推测说成结论。演示中还用到了其他类型的 ToolIndex 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-approvalSkill。这个 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 高效新体验。