从报表到 Agent：数据分析转大模型，我踩过最痛的权限和日志坑

codeingg

266人浏览 · 2026-08-20 11:00:16

codeingg · 2026-08-20 11:00:16 发布

这篇我按“先跑起来、再讲取舍”的方式写《别急着换赛道：数据分析经验在 AI 项目里到底值多少？》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

摘要：数据分析转大模型开发，SQL 和指标理解是优势，但很多人以为接个模型、写个 Prompt 就能跑通。实际做项目才发现，权限控制、日志追踪、可观测性才是从 Demo 走向生产的核心门槛。本文复盘一个电商数据 Agent 的完整开发过程，分享踩过的坑和可复用的方案。

---

数据分析的新机会

文章插图 1

数据分析转大模型，不是换个工具那么简单，而是从"人问数据、人出结论"变成"人问自然语言、Agent 自动执行"。这个转变里，你的优势是对数据的理解，但短板是对 Agent 工程化的陌生。

我见过很多同行，接到需求后直接上 LangChain 或 Dify，接个模型、写个 Tool，跑通 Demo 就交付了。结果上线后问题一堆：权限没校验、日志查不到、模型幻觉导致数据被误用。这些不是模型的问题，是工程化的问题。

我最近做了一个电商数据 Agent 项目，从需求到上线用了三周。最开始的假设是：模型能理解业务指标，工具能正确调用 SQL，剩下的就是 Prompt 工程。结果第一个坑就推翻了这个假设——权限控制。

---

自然语言 BI 和指标解释 Agent

文章插图 2

自然语言 BI 的核心是把用户的问题转成可执行的查询。这里有两个层次：

1. 查询转译：用户说"上个月华东区的 GMV"，Agent 需要理解"上个月"是时间范围、"华东区"是区域维度、"GMV"是指标。
2. 指标解释：用户问"GMV 为什么下降"，Agent 需要拆解指标、定位原因。

我最初的实现是直接用 LLM 生成 SQL。效果很差——模型经常幻觉字段名、写错聚合逻辑。后来换了方案：先让模型输出结构化意图，再由代码生成 SQL。

from pydantic import BaseModel
from typing import Optional

class QueryIntent(BaseModel):
    metric: str          # 指标名称，如 GMV、订单量
    dimensions: list[str] # 维度，如 区域、时间
    filters: dict[str, str] # 过滤条件，如 区域=华东
    time_range: Optional[str] # 时间范围，如 2026-07-01~2026-07-31

这个结构让模型先输出意图，再校验意图合法性，最后生成 SQL。好处是错误可以被提前拦截，而不是等到 SQL 跑错了才发现。

---

CSDN资料领取方式

数据工具调用：权限控制是核心

这是我最痛的坑。

我最初的假设是：用户问什么问题，Agent 就执行什么查询。结果第一个内测用户问了一个敏感问题——"导出所有用户的手机号"。模型直接生成了 SQL，差点就把数据导出来了。

权限控制不是锦上添花，是上线的底线。

我后来加的权限校验逻辑很简单，但很关键：

def check_query_permission(user_role: str, query_intent: QueryIntent) -> bool:
    """
    根据用户角色校验查询权限
    """
    # 普通员工不能查询敏感字段
    sensitive_fields = ["phone", "id_card", "email"]
    if user_role == "employee":
        for field in sensitive_fields:
            if field in str(query_intent.filters):
                return False

    # 所有用户不能导出超过 1000 条记录
    if query_intent.time_range and "导出" in query_intent.metric:
        return False

    return True

这段代码看起来简单，但加完之后我才发现另一个问题：日志没记录权限校验的结果。排查问题的时候，完全不知道是哪个环节拦截的。

---

项目案例：电商数据 Agent 的完整开发

场景描述

电商数据 Agent 的目标是让业务人员通过自然语言查询数据。输入是用户问题，输出是数据结果 + 文字解释。

排查过程

上线后第三天，业务反馈"查询结果不对"。我按以下链路排查：

1. 现象确认：用户问"上周各区域订单量"，返回的结果是空。
2. 日志检查：发现模型输出的意图是 time_range=None，时间范围没解析出来。
3. 验证假设：把同样的问题直接发给模型，要求输出 JSON，结果时间范围解析正确。
4. 定位根因：发现问题出在意图解析的 Prompt 里，没有明确告诉模型"上周"是相对时间，需要转成绝对日期。
5. 修复方案：在 Prompt 里加了一句"如果用户说'上周'，请使用当前日期计算具体时间范围"。

这个排查过程说明：模型本身没问题，问题出在 Prompt 和上下文传递。

代码解释

核心代码是意图解析模块：

def parse_query_intent(user_question: str, current_date: str) -> QueryIntent:
    """
    解析用户问题为结构化意图
    输入：用户问题、当前日期
    输出：QueryIntent 对象
    """
    prompt = f"""
    当前日期：{current_date}
    用户问题：{user_question}

    请将用户问题解析为以下结构化格式：
    - metric: 指标名称
    - dimensions: 维度列表
    - filters: 过滤条件
    - time_range: 时间范围（如 2026-07-01~2026-07-31）

    如果用户说'上周'、'本月'等相对时间，请转换为绝对日期。
    """

    response = call_llm(prompt)
    intent = parse_json_response(response)

    # 校验意图合法性
    if not validate_intent(intent):
        raise ValueError(f"意图校验失败: {intent}")

    return intent

这段代码的关键点：