Grab 正在把 AI Agent 引入分析工作流，并将机械化分析工作占比从 2 月的 44% 降至 6 月的 30%。这项变化的关键不只是“让模型写 SQL”，而是把 Agent 自主性、认证数据、上下文管理和人工监督组合成一套可控的自助分析体系。
变化不在于少写几条 SQL
传统分析流程中，大量时间消耗在重复性任务上：确认指标定义、查找数据表、拼接 SQL、生成常规报表，以及回答结构清晰但反复出现的问题。这些工作通常需要分析师介入，却不一定需要复杂的业务判断。
Grab 的实践显示，AI Agent 可以承接越来越多的指标、数据和 SQL 请求，让分析师从机械执行转向问题定义、结果验证和业务解释。这里的核心衡量方式也很重要：目标不是让 Agent 取代分析师，而是降低机械化工作在整个分析工作中的占比。
可以把一次分析请求拆成四层：
- 理解问题：识别用户要查询的指标、时间范围、维度和过滤条件。
- 选择数据：从认证过的数据集和指标定义中选择可信来源。
- 生成与执行：生成 SQL，执行查询，并检查结果是否符合基本约束。
- 人工把关：对高风险、异常或影响决策的结果进行复核。
这种拆分让 Agent 的职责边界更清晰。它可以自主完成低风险、结构化的任务，但不应默认拥有无限的数据访问权或业务决策权。
四个支柱决定 Agent 是否可用
1. 适度的自主性
Agent 需要能够连续完成多个步骤，而不是每生成一条 SQL 就等待人工确认。例如，它可以先识别指标，再查找指标对应的数据集，生成 SQL，执行查询，并根据结果补充说明。
但自主性必须与权限绑定。只读查询、固定指标和有限时间范围可以允许更高程度的自动化；涉及用户隐私、财务数据、生产写入或关键经营结论的请求，则应强制进入人工审核流程。
2. 认证数据
如果 Agent 只能访问杂乱的表结构，它会把数据发现问题重新交给分析师。认证数据集、统一指标定义和明确的数据所有者，可以显著减少“同一个指标有三种算法”的情况。
一个可行的数据目录至少应记录：
- 指标名称和业务定义
- SQL 或计算逻辑
- 数据集负责人
- 更新频率和数据延迟
- 可用维度与时间范围
- 已知限制和适用场景
认证数据并不意味着数据永远正确，而是让 Agent 知道应该优先使用什么、遇到冲突时应该向谁提问。
3. 上下文管理
分析请求很少是孤立的。用户可能在第一轮提到“本月订单”，第二轮改成“按城市拆分”，第三轮又要求“排除取消订单”。如果上下文管理不当，Agent 可能遗忘筛选条件，或者把不同口径混在一起。
实用做法是把上下文拆成结构化状态，而不是只依赖完整聊天记录：
{
"metric": "completed_orders",
"definition": "已完成且未取消的订单数",
"time_range": {
"start": "2025-06-01",
"end": "2025-06-30"
},
"dimensions": ["city"],
"filters": ["country = 'SG'"],
"source": "certified.orders_daily",
"requires_review": false
}
这样做有两个好处：一是后续步骤能直接消费结构化信息；二是人工审核时，可以清楚看到 Agent 采用了什么口径，而不必重新阅读全部对话。
4. 人工监督
人工监督不是每一步都点击确认，而是根据风险分级。低风险任务可以自动执行，高风险任务需要在执行前或发布结果前审批。
例如，可以把以下情况设为必须复核：
- 查询个人或敏感业务数据
- 使用未认证的数据集
- 查询结果与历史基线差异过大
- 生成对外发布或影响经营决策的结论
- Agent 无法解释指标来源或筛选条件
这类机制能把分析师的时间集中到真正需要判断的地方，而不是让他们成为每次 SQL 执行的人工按钮。
一个可改造的最小 Agent 工作流
下面的示例不依赖第三方模型或数据库，使用 Python 标准库模拟一个受控的分析 Agent。它展示了可以怎样实践：先从认证指标目录中解析请求，再生成只读 SQL，最后根据风险规则决定是否需要人工审核。接入真实系统时，可以把 parse_request 替换为模型调用，把 execute_query 替换为数据仓库客户端。
将代码保存为 analytics_agent.py 后直接运行：
from dataclasses import dataclass
from typing import Dict, List
@dataclass(frozen=True)
class Metric:
name: str
expression: str
source: str
certified: bool = True
METRICS: Dict[str, Metric] = {
"completed_orders": Metric(
name="completed_orders",
expression="SUM(completed_orders)",
source="certified.orders_daily",
),
"gross_booking_value": Metric(
name="gross_booking_value",
expression="SUM(gross_booking_value)",
source="certified.orders_daily",
),
}
@dataclass
class Request:
metric: str
start_date: str
end_date: str
dimension: str = "city"
country: str = "SG"
def parse_request(text: str) -> Request:
# 真实系统中，这一步可以由 LLM 输出结构化 JSON 后再做校验。
return Request(
metric="completed_orders" if "订单" in text else "gross_booking_value",
start_date="2025-06-01",
end_date="2025-06-30",
dimension="city",
country="SG",
)
def build_sql(request: Request) -> str:
metric = METRICS[request.metric]
if not metric.certified:
raise ValueError("指标未通过认证")
return f"""SELECT {request.dimension}, {metric.expression} AS value
FROM {metric.source}
WHERE order_date >= '{request.start_date}'
AND order_date < '{request.end_date}'
AND country = '{request.country}'
AND order_status = 'completed'
GROUP BY {request.dimension}
ORDER BY value DESC;"""
def needs_review(request: Request, sql: str) -> bool:
risky_terms = ["DROP", "DELETE", "UPDATE", "INSERT", "personal_id"]
return any(term in sql.upper() for term in risky_terms)
def main() -> None:
request = parse_request("查询 2025 年 6 月新加坡各城市的完成订单")
sql = build_sql(request)
print("生成的只读 SQL:\n")
print(sql)
print("\n是否需要人工审核:", "是" if needs_review(request, sql) else "否")
if __name__ == "__main__":
main()
运行命令：
python analytics_agent.py
生产环境还需要补充 SQL 解析器、参数化查询、权限校验、查询超时、结果脱敏和审计日志。示例中的字符串拼接只是为了演示流程，不能直接用于包含用户输入的生产查询。
从自助分析到分析师增效
自助分析的价值不只是缩短一次问答的等待时间。随着 Agent 处理更多指标、数据和 SQL 请求，组织可以重新设计分析师的工作分配：
- Agent 处理口径明确、重复出现的查询
- 分析师维护指标定义和认证数据集
- 分析师检查异常结果与边界案例
- 业务团队通过自然语言获取可追溯的分析结果
- 复杂问题进入人工主导的探索式分析流程
这里存在一个容易被忽略的反馈回路：Agent 运行时发现的歧义，会暴露数据目录和指标体系中的缺口。每一次失败都不只是模型问题，也可能说明指标命名、数据血缘或业务定义需要改进。
落地时应关注什么
可以用下面的清单评估一个分析 Agent 是否适合扩大范围：
- 是否有少量明确的认证指标作为起点
- 是否能展示指标定义、数据来源和筛选条件
- 是否只允许访问必要的数据集
- 是否对查询结果做空值、数量级和时间范围检查
- 是否区分低风险自动执行与高风险人工审核
- 是否记录提示词、生成 SQL、执行身份和最终结果
- 是否用机械化工作占比、人工介入率和错误率衡量效果
Grab 将机械化分析工作从 44% 降至 30%，说明这类项目的重点是重新分配分析工作，而不是简单追求“自动化率”这个单一数字。可靠的 Agent 需要自主性，也需要数据治理、上下文约束和明确的人类责任边界。对于其他团队，较稳妥的路径是从认证指标和只读查询开始，逐步扩大任务范围，同时保留可解释、可审计、可撤回的控制点。