聊《我用数据分析经验做了次 AI 项目,最先失效的是旧方法》之前,先说一句实在的:别急着背概念,先看它在真实项目里到底解决什么问题。
摘要
很多数据分析师转型做Agent时,以为学会调API、写Prompt就万事大吉。我踩过的坑告诉我:Demo跑通只是第一步,真正让项目从"能演示"变成"能上线"的,是权限控制和可观测性。这篇文章用一次智能分析Agent的实战经历,拆解从报表思维到Agent思维的转变过程,以及那些在Demo阶段被忽略、上线后却致命的问题。
目录
- 数据分析的新机会
- 自然语言BI:从报表到对话
- 指标解释Agent:不只是查数据
- 数据工具调用:SQL是基础,权限是底线
- 项目案例:Demo到上线的距离
- 总结
数据分析的新机会

做数据分析的这几年,我见过太多人转型焦虑。报表做得再好,也只是"人找数据";大模型来了,变成了"数据找人"。这个转变看似简单,但真正做起来才发现,技术栈的迁移只是表层,思维方式的转变才是核心。
我的转型路径是从SQL报表开发,到自然语言查询,再到现在的智能分析Agent。中间踩过不少坑,但回头看,最大的收获不是学会了什么新工具,而是理解了"什么才是真正的工程化"。
很多人问我:数据分析转大模型,最难的是什么?我的答案是:不是模型调用,不是Prompt工程,而是从"单点任务"到"系统思维"的转变。报表开发是确定性的,输入固定,输出固定;Agent是概率性的,输入固定,输出不固定。这种不确定性,要求开发者具备完全不同的思维方式。
自然语言BI:从报表到对话

自然语言BI(NL2SQL)是很多人转型的第一步。技术上不难,调个API,拼个Prompt,跑通一个Demo。但真正用起来,问题就来了。
我做过一个项目,把传统的销售报表升级成自然语言查询。Demo阶段,测试数据非常干净,模型回答准确率很高。但上线后,业务人员问的问题千奇百怪,模型经常"幻觉"出错误的SQL。
这里有个关键认知:NL2SQL不是简单的"翻译",而是"理解+执行"。模型需要理解业务语境,生成正确的SQL,还要处理边界情况。我的经验是,Demo阶段要用真实数据测试,而不是清洗过的测试数据。
# 一个简单的NL2SQL示例
def generate_sql(question: str, schema: dict) -> str:
prompt = f"""
根据以下数据库schema,将自然语言问题转换为SQL:
问题:{question}
Schema:
{json.dumps(schema, ensure_ascii=False, indent=2)}
只返回SQL,不要解释。
"""
response = call_llm(prompt)
return extract_sql(response)
这个Demo能跑,但上线会崩。为什么?因为缺少权限控制和日志追踪。

指标解释Agent:不只是查数据
智能分析Agent的核心价值,不只是查数据,而是解释数据。从"销售额是多少"到"为什么销售额下降了",这个转变需要模型具备推理能力。
我做的指标解释Agent,流程是这样的:
1. 用户提出问题
2. Agent理解问题,确定需要的指标
3. 调用数据工具获取数据
4. 分析数据,生成解释
5. 返回结果
Demo阶段,这个流程很顺畅。但上线后,问题出现了:
- 用户问"为什么销售额下降",Agent返回了错误的数据
- 模型生成的解释逻辑不通
- 没有记录用户的问题和Agent的回答
这些问题,单靠优化Prompt解决不了。需要的是系统性的工程化方案。
数据工具调用:SQL是基础,权限是底线
数据分析师做Agent,天然优势是懂SQL、懂业务。但很多人忽略了一个问题:Agent调用数据工具时,权限怎么控制?
我见过一个项目,Agent可以直接执行任意SQL。结果有一次,模型生成了一个DROP TABLE的语句,虽然被数据库拦截了,但风险极大。
权限控制不是可选的,是必须的。我的做法是:
1. 定义白名单SQL模板,只允许SELECT
2. 限制查询时间范围,避免全表扫描
3. 记录所有SQL执行日志,便于审计
# 带权限控制的数据工具调用
class SecureSQLExecutor:
def __init__(self, allowed_tables: list, max_rows: int = 1000):
self.allowed_tables = allowed_tables
self.max_rows = max_rows
def execute(self, sql: str, user: str) -> dict:
# 1. 解析SQL,检查表名是否在白名单
table_names = self._extract_tables(sql)
if not self._is_allowed(table_names):
raise PermissionError(f"无权访问表: {table_names}")
# 2. 限制查询行数
if "LIMIT" not in sql.upper():
sql += f" LIMIT {self.max_rows}"
# 3. 执行并记录日志
result = self._run_sql(sql)
self._log_execution(user, sql, result)
return result
def _log_execution(self, user: str, sql: str, result: dict):
# 记录到日志系统,便于追溯
log_entry = {
"user": user,
"sql": sql,
"rows": result.get("row_count", 0),
"timestamp": datetime.now().isoformat()
}
logger.info(json.dumps(log_entry, ensure_ascii=False))
这个代码片段展示了基本的权限控制和日志记录。看起来简单,但很多Demo项目根本不做这些。
项目案例:Demo到上线的距离
我最近做了一个智能分析Agent项目,用来帮助业务人员分析销售数据。整个过程可以分为几个阶段:
阶段一:Demo开发(2周)
- 使用LangGraph构建工作流
- 集成大模型API
- 用测试数据验证流程
Demo阶段很顺利,模型回答准确率90%以上。但问题也在这里:测试数据太干净了。
阶段二:权限改造(1周)
- 定义SQL白名单
- 限制查询范围
- 添加用户鉴权
这个阶段发现了很多问题。比如,模型经常生成包含敏感表的SQL,需要重新调整白名单。
阶段三:日志系统(1周)
- 记录用户问题
- 记录Agent思考过程
- 记录SQL执行结果
日志系统上线后,发现模型经常"幻觉"出错误的数据。有了日志,才能定位问题。
阶段四:可观测性(1周)
- 接入APM工具
- 设置关键指标监控
- 配置告警规则
可观测性不是锦上添花,而是上线的必要条件。没有监控的Agent,就像没有刹车的车。
这个项目前后花了5周,其中Demo只用了2周。剩下的3周,都是在解决权限、日志和可观测性问题。
总结
数据分析转大模型,最大的误区是认为学会了调API、写Prompt就能做Agent。实际上,Demo跑通只是开始,真正考验工程能力的是权限控制、日志记录和可观测性。
我的建议是:
1. 不要只关注模型效果,要关注系统可靠性
2. 权限控制要从第一天就开始设计,不要等上线前才补
3. 日志系统要记录完整的执行链路,便于问题追溯
4. 可观测性要覆盖关键指标,及时发现问题
报表思维是确定性的,Agent思维是不确定的。接受这种不确定性,用工程化的手段控制风险,才能做出真正能上线的智能分析Agent。
最后说一句:Prompt只是门槛,权限日志才是生死线。这句话我踩了坑才懂,希望你们不用踩。
资料展示
下面是我整理的AI大模型学习资料和工具包预览,适合收藏后按主题逐步学习。



如果你想看完整资料目录,可以在评论区留言「资料」;也欢迎告诉我你更关注AI大模型里的哪类内容。


186

被折叠的 条评论
为什么被折叠?



