用途：面向 Elastic ML 异常检测的专家流程，覆盖四类任务——调查与根因分析（RCA）、分数与模型行为解释、作业生命周期排障、作业创建与配置。适用于回答“什么坏了”“哪个实体导致”“分数为何高/低”“作业为何缺文档”等问题。
主要能力：按用户意图选择模式。Investigate 用于 RCA、跨作业关联、影响范围与实体归因；Explain 用于分数解释、重归一化、模型边界与预测；Troubleshoot 用于缺文档、内存上限、datafeed 停止、生命周期与日历；Manage 用于创建作业、配置 datafeed、启动分析与取结果。安全与可观测性场景可结合对应参考文档。
使用方式：通过 elastic CLI 执行 Elasticsearch 操作，不直接调用 HTTP API，也不猜测凭据。若未安装 elastic CLI，需告知用户其用途。异常结果从 POST /.ml-anomalies-/_search 读取（Serverless 安全），作业与 datafeed 状态从 ML REST API 读取。Serverless 下旧版 /_ml/anomaly_detectors/{job_id}/results/ 返回 HTTP 410。文档末尾 Operations 表将 HTTP 简写映射为 elastic CLI 命令，例如 GET /_ml/anomaly_detectors 对应 elastic es ml get-jobs，POST /.ml-anomalies-/_search 对应 elastic es search --index '.ml-anomalies-' --input-file '<search-body.json>'。
关键规则：实体归因按 influencer_score 排序而非桶级 anomaly_score；多作业共同异常的实体是首要嫌疑，单作业实体多为下游受害者；multi_bucket_impact ≥ 3 表示持续偏移；RCA 必须用 datafeed 源索引的原始文档确认。分数解释需同时展示 initial_record_score 与 record_score，二者差距即重归一化故事；actual << typical 且 count/low_count 低表示缺失/中断异常。排障先看 memory_status，hard_limit 会损坏模型并导致下游误报，修复内存优先于 query_delay；配置变更需按停止 datafeed → 关闭作业 → 更新 → 打开 → 启动的顺序执行。
限制：资料未提供具体收费、价格、平台支持范围或效果保证；部分参考文档与 Operations 表末尾内容在资料中被截断，暂未提供完整细节。