数据分析转大模型做 Agent，别只盯 Prompt，权限和日志才是交付线

发布时间：2026/7/22 3:41:45

聊《别急着换赛道：数据分析经验在 AI 项目里到底值多少？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

>摘要：从写 SQL 报表到搭智能分析 Agent，很多人以为换条赛道就是重新学一套技术栈。实际做过几个交付项目后发现，真正决定能不能上线的，不是大模型能生成多流畅的自然语言，而是权限隔离、查询审计和失败可观测。本文结合近期招聘 JD 和我自己的踩坑经历，把数据分析背景的人转大模型应用开发的能力要求拆清楚，给出一份可以照着练的排序。

数据分析的新机会
自然语言 BI 的假象与真实边界
指标解释 Agent：让大模型“看懂”业务，而不是硬编数字
数据工具调用：从 Demo 顺滑到生产崩溃的那道坎
项目案例：我把一套内部报表拆成了可观测的 Agent 流
总结：按 JD 反推练习顺序

数据分析的新机会

最近看了几十份“智能分析工程师”“AI 数据产品”的 JD，发现一个很现实的分化：初级岗位还在问你会不会调 API、写 Prompt；中高级岗位几乎清一色要求工具调用设计、权限隔离、链路追踪和异常回滚。也就是说，行业对这类人才的评价标准已经从“能不能跑通 Demo”变成了“能不能扛住线上流量和审计”。

数据分析出身的人其实有天然优势。你习惯把模糊的业务问题翻译成明确的字段、口径和过滤条件，这恰好是 Agent 最缺的骨架。但劣势也很明显：传统报表交付的终点是一张图或一个 CSV，而 Agent 交付的终点是一套可追溯、可拦截、可解释的决策流。很多人一开始就扎进 LangChain 教程里练 Prompt 编排，结果面试被问到“用户越权查了其他部门的明细怎么办”“查询失败了怎么重放”时直接卡壳。

我的判断是，转大模型方向不要先卷模型能力，先补工程化短板。Prompt 只是入口，权限和日志才是交付线。

自然语言 BI 的假象与真实边界

NL2SQL 是最容易做出 Demo 的切入点，也最容易在生产环境翻车。

我们在内部试点过“自然语言问数”，初期用合成表和精简 Prompt，模型生成的 SQL 看着挺漂亮。但接入真实业务库后，问题集中爆在三个地方：一是口径冲突，比如“活跃用户”在运营那边指近 30 天登录，在财务那边指产生过有效订单；二是分区和时效，报表用的 T+1 宽表和大模型实时查的明细表不在一个层级；三是空值和边界情况，模型会自信地拼出一个看似合理但分母为零的查询。

后来我们不再试图让 Prompt 记住所有业务细节，而是把指标拆成结构化词典。每个指标绑定来源表、计算逻辑、更新频率和适用角色，Agent 在生成 SQL 前先做口径校验，不匹配的查询直接走人工确认。这个改动没有让模型更聪明，但把错误率压下去了大半。

所以自然语言 BI 的真实边界不是“模型能不能翻译”，而是“业务规则能不能被机器读懂”。数据分析的经验在这里价值很高，前提是你愿意把那些藏在文档和口头沟通里的口径显性化。

指标解释 Agent：让大模型“看懂”业务，而不是硬编数字

指标查出来之后，下一步是让 Agent 给出可读的解释。很多人会让大模型直接根据数字写一段分析，这基本等于把幻觉风险交给模型。

我们的做法是把“计算”和“叙述”彻底拆开。Agent 的流程是：先调用数据工具拿到原始结果和置信度，再把这些结构化结果喂给大模型，同时附带一条业务上下文模板。模板里固定了几类解释模式，比如环比下跌要提示是否受节假日影响、是否涉及新渠道剔除、是否需要下钻到区域或品类。大模型只负责组织语言，不负责发明事实。

class MetricExplainer: def __init__(self, llm_client, business_rules: dict): self.llm = llm_client self.rules = business_rules def explain(self, metric_result: dict, user_context: dict) -> str: # 先做业务规则校验，不满足条件就截断，不让模型自由发挥 if not self._validate_rule(metric_result["metric_name"], user_context): return f"[口径受限] {metric_result['metric_name']} 当前角色不可解释，请联系数据 owner。" prompt = self._build_narrative_prompt(metric_result, user_context) return self.llm.chat(prompt) def _validate_rule(self, metric_name: str, ctx: dict) -> bool: allowed_roles = self.rules.get(metric_name, {}).get("explain_roles", []) return ctx.get("role") in allowed_roles

这段代码很基础，但它传达了一个取舍：宁可让 Agent 返回一句“当前无法解释”，也不要让它编出一段像那么回事的分析。数据分析的人应该比任何人都在意这个底线。

数据工具调用：从 Demo 顺滑到生产崩溃的那道坎

真正拉开差距的是工具调用层。Demo 里调用数据库就是execute(sql)，生产环境里你至少得处理三件事：谁在调用、能查到什么范围、出错了怎么留痕。

近期大模型应用圈有个很明显的风向转变：企业不再只看演示视频，开始要求在简历和面试里讲清楚权限校验、请求追踪、可观测性接入。这不是玄学，而是线上出事后的复盘成本太高。一个 Agent 如果每次调用都黑盒执行，排查一次异常可能要花半天；如果每一跳都有 trace_id 和结构化日志，问题定位时间能缩短好几个量级。

我在写工具封装时，会把权限检查和日志记录作为装饰器前置，而不是等业务函数跑完再补。下面是一个简化版的工具调用包装器，核心思路是统一入参、强制权限过滤、记录完整调用链：

import uuid import logging from functools import wraps from typing import Any, Callable logger = logging.getLogger("agent.tool") def secure_tool_call(func: Callable) -> Callable: @wraps(func) def wrapper(user_id: str, role: str, params: dict, *args, **kwargs) -> Any: trace_id = str(uuid.uuid4())[:8] start_meta = {"trace_id": trace_id, "tool": func.__name__, "user": user_id, "role": role} logger.info(f"[{trace_id}] 开始调用 {func.__name__}, meta={start_meta}") try: allowed_params = get_allowed_params(role, func.__name__) filtered_params = {k: v for k, v in params.items() if k in allowed_params} result = func(user_id, role, filtered_params, *args, **kwargs) logger.info(f"[{trace_id}] 调用成功, 返回行数={len(result) if isinstance(result, list) else 'N/A'}") return result except PermissionError as e: logger.warning(f"[{trace_id}] 权限拒绝: {e}") raise except Exception as e: logger.error(f"[{trace_id}] 执行异常: {e}", exc_info=True) raise RuntimeError(f"工具调用失败: {e}") from e return wrapper

项目案例：我把一套内部报表拆成了可观测的 Agent 流

拿我们内部的销售看板来说。原来是一堆定时跑的 SQL 脚本，输出 CSV 丢到共享盘。转成 Agent 后，第一步不是接大模型，而是把每张表的查询包进@secure_tool_call，按部门角色配置allowed_params。销售只能看自己区域的聚合数据，区域经理可以看明细，财务看全量。

第二步是加 traceid。每次用户提问，系统生成一个短 ID，贯穿 Prompt 编排、SQL 生成、工具调用、结果返回全过程。日志里不记敏感数据内容，只记入参类型、过滤条件、执行耗时和返回状态。出了问题不用翻代码，直接按 traceid 拉链路，三分钟内能定位是口径配置错了，还是 SQL 超时，还是权限策略漏配。

第三步才是接 LLM。模型只负责把用户口语转成结构化查询意图，真正的数据获取和解释全部走上面封好的工具。这样即使模型抽风，也不会直接打到生产库。

总结：按 JD 反推练习顺序

别一上来就啃框架。按实际交付需求倒着练：

1. 先把数据接口包安全：写一个带权限校验和结构化日志的工具调用层，能拦越权、能追异常。
2. 把指标词典化：选 5~10 个常用指标，写成包含来源表、口径、更新频率、适用角色的 JSON/YAML。
3. 再接 LLM 做意图识别和 SQL 生成：用你上面的词典做校验，跑不通的查询走人工确认。
4. 最后补可观测性：trace_id、调用耗时、失败重试、结果缓存，这些才是面试里能讲出深度的部分。

Prompt 写得再漂亮，上线前也得过权限、日志、回滚这三关。数据分析的人把业务口径和工程习惯结合起来，转起来反而比纯后端快。