聊《做过数据分析的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。
摘要
很多做数据分析的同学转大模型，第一个项目往往是智能分析 Agent——用自然语言查数据、出报表。Demo 跑通很容易，但交给团队用就出问题。这篇文章不聊 Prompt 怎么写，聊一个更实际的门槛：权限控制、操作日志、可观测性。这些不是"锦上添花"，而是 Demo 变产品的分水岭。
目录
- 数据分析的新机会
- 自然语言 BI 为什么容易做，却难用好
- 指标解释 Agent：不只是翻译 SQL
- 数据工具调用：从单点到工作流
- 项目案例：从 Demo 到可维护项目
- 总结
---
数据分析的新机会
我在带团队做 AI 数据产品时，见过一个现象：数据分析背景的同学，转大模型开发反而比纯后端快。
原因很实际。数据分析的人懂指标、懂数据口径、懂业务逻辑，这些在写 Prompt 和定义 Agent 行为时，比写代码本身更重要。
但问题也在这里。
很多做数据分析的同学，习惯的是"出结果"。报表跑通、数据准确，任务就结束了。但 Agent 不一样，它要面对的是真实用户、真实权限、真实数据泄露风险。
我见过一个案例：一个分析师用 LangChain 写了个智能分析 Agent，本地跑通，能回答"上月销售额为什么下降"，团队很兴奋。结果上线第一天，有用户通过对话拿到了公司级敏感指标，权限没控制，日志没记录，事后追查不到是谁问的、问了什么。
这不是技术能力问题，是工程化思维缺失。
自然语言 BI 为什么容易做，却难用好
自然语言转 SQL，现在随便一个模型都能做。Demo 阶段，你输入"上个月华东区的销售额"，Agent 生成 SQL，查库，返回结果，看起来很完美。
但真实环境里，你会遇到这些问题：
权限问题：不同部门的人问同样的问题，应该看到不同的数据。销售只能看自己区域，财务可以看全公司，高管可以看明细。这个权限控制，不是在 Prompt 里加一句"只返回用户有权限的数据"就能解决的，需要在 SQL 生成阶段就注入用户权限过滤条件。
口径问题："销售额"是含税还是不含税？是下单时间还是发货时间？分析师知道，但模型不知道。你需要把口径定义成可查询的知识库，而不是每次让模型自己猜。
结果验证：模型生成的 SQL 能不能跑？有没有语法错误？返回结果是否合理？这些都需要在 Agent 流程里加校验环节。
我最近在做的一个项目，就是在自然语言 BI 上加了权限注入层。核心思路是：在 SQL 生成之前，先把用户身份对应的数据权限条件拼进 WHERE 子句，而不是让模型自己去判断。
# 权限注入示例：在 SQL 生成前注入数据权限条件 def inject_permissions(user_id, base_query): # 从权限服务获取用户可见的数据范围 allowed_regions = get_user_regions(user_id) allowed_departments = get_user_departments(user_id) # 注入权限条件 if allowed_regions: base_query += f" AND region IN ({format_values(allowed_regions)})" if allowed_departments: base_query += f" AND department IN ({format_values(allowed_departments)})" return base_query这个改动看起来简单，但它是 Demo 和产品的关键区别。
指标解释 Agent：不只是翻译 SQL
数据分析转大模型，一个很自然的延伸是做指标解释 Agent——用户问"为什么销售额下降"，Agent 不仅返回数据，还能解释原因。
这个场景比单纯的自然语言 BI 更复杂，因为涉及多步推理。
我见过一个实现方案：第一步，Agent 生成 SQL 拿到数据；第二步，对比历史数据，找出异常点；第三步，关联维度分析，定位下钻方向；第四步，生成自然语言解释。
问题出在第三步和第四步。
关联维度分析需要模型自己决定查哪些维度，这个过程不可控。模型可能查了无关维度，浪费调用次数，也可能漏掉关键维度，给出错误结论。
自然语言解释需要模型"编故事"，但编得对不对，没人能实时验证。
我的解决方案是把可解释的部分固化，把不可控的部分暴露出来让用户确认。
具体来说，维度分析用预定义的规则引擎，而不是让模型自由发挥。规则引擎根据业务逻辑，决定在什么情况下应该下钻到哪个维度。模型只负责生成解释文本，不负责决定分析路径。
同时，所有生成的解释都会记录操作日志，包括：用户问了什么、模型做了什么分析、最终给出的结论是什么。这样事后可以追溯，也可以用来优化模型。
数据工具调用：从单点到工作流
数据分析的人做 Agent，最容易犯的错误是把所有工具调用写在一起。
比如一个"销售分析 Agent"，用户问一个问题，Agent 要：查数据、做对比、生成图表、写解释。这四个步骤如果写成一个函数，代码会很长，而且一旦某个环节出错，整个流程就崩了。
更好的做法是把每个工具调用拆成独立步骤，用工作流管理。
我最近在用的方案是 LangGraph，它允许你把 Agent 流程定义成有向图，每个节点是一个工具调用，边是流转逻辑。这样做的好处是：
每个节点可观测：你可以看到每一步花了多少时间、调用了什么模型、返回了什么结果。
每个节点可重试：如果某个工具调用失败，可以单独重试，不影响其他步骤。
每个节点可替换：如果某个步骤的模型效果不好，可以单独替换，不需要重写整个流程。
from langgraph.graph import StateGraph, END # 定义状态 class AnalysisState(TypedDict): question: str sql: str data: pd.DataFrame insight: str chart_url: str # 定义节点 def generate_sql(state: AnalysisState) -> AnalysisState: # 调用模型生成 SQL state["sql"] = llm.generate_sql(state["question"]) return state def execute_query(state: AnalysisState) -> AnalysisState: # 执行 SQL，注入权限条件 state["data"] = db.execute(inject_permissions(state["sql"])) return state def generate_insight(state: AnalysisState) -> AnalysisState: # 基于数据生成洞察 state["insight"] = llm.generate_insight(state["data"]) return state # 构建工作流 workflow = StateGraph(AnalysisState) workflow.add_node("generate_sql", generate_sql) workflow.add_node("execute_query", execute_query) workflow.add_node("generate_insight", generate_insight) workflow.add_edge("generate_sql", "execute_query") workflow.add_edge("execute_query", "generate_insight") workflow.add_edge("generate_insight", END) app = workflow.compile()这个结构看起来比单函数复杂，但它给你的是可维护性。权限控制、日志记录、错误处理，都可以加在对应的节点里，而不是整个流程里打补丁。
项目案例：从 Demo 到可维护项目
去年我带团队做了一个智能分析 Agent，最初版本就是一个 Demo：用户问问题，Agent 生成 SQL，查库，返回结果。内部测试没问题，就准备上线。
上线前做了一次代码审查，发现了三个问题：
第一，没有权限控制。所有用户都能查到所有数据，包括敏感指标。这个问题如果不在上线前解决，风险很大。
第二，没有操作日志。用户问了什么、模型返回了什么、数据从哪张表查的，全部没有记录。出了问题没法追查。
第三，没有结果校验。模型生成的 SQL 没有经过验证就直接执行，有注入风险，也有性能风险。
我们花了两周时间做了以下改造：
权限控制方面，我们在 SQL 生成前注入用户权限条件，并在数据返回后二次校验，确保没有越权数据泄露。
操作日志方面，我们在每个节点加了日志记录，包括输入、输出、耗时、模型调用次数。日志集中存储，支持按用户、按时间、按问题类型查询。
结果校验方面，我们加了一个 SQL 解析器，在生成 SQL 后检查是否有危险操作（如 DROP、DELETE），以及查询复杂度是否超出阈值。
改造后的 Agent，上线后运行了三个月，处理了上万次查询，没有出现权限泄露或数据错误。团队反馈是：可观测性提升后，排查问题从几小时缩短到几分钟。
这个案例的核心结论是：Demo 和产品的差距，不在模型能力，在工程化细节。
总结
数据分析转大模型，优势在业务理解，短板在工程化思维。
很多分析师做 Agent，习惯的是"出结果"，但 Agent 面对的是真实用户和真实风险，权限、日志、可观测性不是可选项，是必选项。
我的建议是：
先做一个能跑通的 Demo，验证你的场景是否可行。然后停下来，不要急着加功能，先把权限控制、操作日志、结果校验这三件事做好。这三件事做好了，你的 Agent 才是一个可以交给团队用的产品，而不只是一个演示。
技术能力决定你能走多快，工程化能力决定你能走多远。数据分析转大模型，这是一次机会，也是一次升级。
资料展示
下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。
如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。
