传统 BI 告警解决的是“发生了什么”：退货率上涨、客单价超过阈值、订单量突然下跌。但真正消耗分析团队时间的是下一步：打开多个 Dashboard，按产品、地区、渠道和客户分群逐层排查。Looker Agentic Workflows 目前以预览版形式提供，尝试把这段人工诊断链路交给后台智能代理自动执行。
它的关键变化不只是让用户用自然语言创建告警，而是让告警触发后继续执行 Key Driver Analysis（KDA），并将可能的驱动因素连同通知一起发送到 Slack 或邮箱。
从临时提问到持续运行的监控
Looker 的 Conversational Analytics 已支持通过自然语言查询业务数据。Agentic Workflows 则把一次聊天中的需求转成可持续执行的工作流。例如，业务人员可以提出：
- “每周监控退货率。”
- “平均订单金额超过 1,000 美元时通知我。”
- “当某个地区的转化率环比下降超过 15% 时，分析主要原因。”
代理会解析指标、时间粒度、阈值和通知意图，并生成一个待审阅的工作流计划。这个“先生成、再确认”的步骤很重要：自然语言适合表达目标，却可能遗漏指标口径、比较周期或边界条件；把计划展示给用户审阅，能降低“监控了错误字段”或“阈值理解错误”的风险。
对于数据团队而言，建议把工作流视作一种受治理的分析资产，而不只是个人提醒。创建前至少确认以下内容：
- 指标对应的 Explore、语义模型和统一定义是否正确。
- 阈值是绝对值、环比变化还是同比变化。
- 是否排除测试订单、未完成订单、退款延迟等异常业务状态。
- 告警频率是否足以避免渠道噪声和重复通知。
告警触发后，代理会继续追问“为什么”
普通告警往往只包含一个数字，例如“退货率从 4.2% 升至 6.8%”。收到消息的人仍要手动定位原因。Agentic Workflows 的设计重点在于：当指标越过设定条件后，后台代理可在底层数据模型上执行 Key Driver Analysis。
摘要中提到，代理能够识别诸如产品类别、客户 Cohort 等可能驱动指标变化的因素。最终通知不再只是红黄绿信号，而应包含可行动的诊断线索，例如：某产品类别的退货增加、某一批新客户的退款率异常，或某渠道带来了更低客单价的订单。
这并不意味着 KDA 输出可以直接被视为因果结论。它识别的是与指标变化高度相关、值得优先调查的切片。现实中还可能存在：
- 促销、价格调整、库存缺货等未被模型覆盖的业务事件。
- 数据延迟、ETL 重跑或维度映射变更造成的假异常。
- 多个维度同时变化，导致单一“主因”掩盖组合效应。
- 小样本分组在统计上看似剧烈、实际上没有业务代表性。
因此，KDA 最适合用来缩短排查路径，而不是替代分析师对口径、数据质量和业务事件的判断。
可以这样实践：先用一个工作流契约规范需求
Looker 会通过对话界面生成并管理工作流，摘要没有公开可直接调用的工作流 API 或 YAML Schema。团队仍可以先用一份版本化的“监控契约”明确需求，再由具有权限的用户在 Looker 对话界面中创建对应工作流。下面的 YAML 是团队约定示例，不是 Looker 的官方导入格式。
# monitors/weekly-return-rate.yaml
name: weekly-return-rate-watch
owner: commerce-analytics@example.com
metric:
explore: order_items
measure: return_rate
schedule:
cadence: weekly
timezone: America/Los_Angeles
condition:
operator: greater_than
threshold: 0.05
comparison: current_week
analysis:
type: key_driver_analysis
dimensions:
- product_category
- customer_cohort
- sales_channel
notifications:
slack_channel: "#commerce-alerts"
email:
- commerce-analytics@example.com
follow_up:
prompt: "Compare the top driver with the prior four weeks and check whether order volume also changed."
将 explore、measure、时区、阈值和通知目标替换为自己的业务定义后，可以用下面的命令把契约文件纳入代码审查，避免监控配置只存在于个人聊天记录中：
mkdir -p monitors
printf '%s\n' 'Review monitors/weekly-return-rate.yaml before creating or changing the Looker workflow.' > monitors/README.md
git add monitors/weekly-return-rate.yaml monitors/README.md
git diff --cached
随后在 Looker 的 Conversational Analytics 中，可以根据这份契约发出清晰的创建请求：
Monitor the return_rate measure in the order_items Explore every week.
Notify #commerce-alerts and commerce-analytics@example.com when it exceeds 5%.
When triggered, run Key Driver Analysis by product_category, customer_cohort,
and sales_channel. Show me the generated workflow plan for review before launch.
提示词中显式给出 Explore、Measure、阈值、频率、分析维度和接收方，比“监控退货率”更适合生产环境。创建后，应检查代理生成的计划是否采用了正确的度量字段、时间窗口和通知条件。
Slack 通知不是终点，而是调查入口
每条通知都带有返回 Looker Conversational Analytics 的直接链接。打开链接后，用户会进入一个已加载诊断发现的交互式会话，可以继续验证假设。
例如，收到“退货率异常”的通知后，后续问题可以更具体：
For the product category identified as the top driver,
compare return reasons with the previous four-week baseline.
Exclude orders that are still within the return window,
and break the result down by fulfillment center.
这一模式把协作节奏从“Slack 中提出问题，再等待分析师拉数”改成“通知提供初始证据，相关人员直接在同一语境中追问”。不过，面向广泛业务用户开放前，数据负责人应先确定哪些 Explore 可用于代理分析，哪些敏感维度不应出现在通知或对话结果中。
上线前的权限与治理检查
该功能适用于 Looker 26.08 及更高版本，且当前为预览功能。管理员需要在 Gemini in Looker 设置页启用 Agentic Workflows 预览开关；用户还需要 chat_with_agent 和 create_alerts 权限才能创建工作流。
建议从少量高价值、口径稳定的指标开始，例如退货率、客单价或关键漏斗转化率。上线前可以用下面的清单做一次审查：
- Looker 实例版本不低于 26.08，且预览功能已由管理员启用。
- 创建者具备
chat_with_agent与create_alerts权限。 - 监控指标来自受信任的 Explore，并有明确的业务定义。
- 阈值经过历史数据回测，能过滤常规波动。
- KDA 可使用的维度不存在不应暴露的敏感信息。
- Slack、邮件接收者对告警处理有明确责任人和升级路径。
- 管理员定期检查全实例工作流，并可调整或停用失效规则。
Agentic Workflows 的价值不在于增加更多告警，而在于让每一次告警附带下一步调查所需的上下文。先用少量可验证的监控建立信任，再逐步扩展到更多业务指标，通常比一次性把所有 Dashboard 都接入自动化更稳妥。