五年报表分析转大模型，我在Agent项目里踩过的权限和日志坑

关注

原创 2026-09-05 09:21:49 414 阅读 AI 写同款· GEO 优化 ›

Java开发者转大模型方向：三天吃透Agent与Skill开发实战 大模型应用开发正从算法训练转向工程落地，企业真正稀缺的是能把模型稳定接入业务流程的工程型人才。对于拥有Java背景的开发者而言，Agent应用开发是最自然的切入点——并发控制、事务管理、权限治理、模块化设计等既有工程能力，几乎可以直接迁移到Agent工具链与Skill封装中。Claude Code与Codex是当前主流的Agent工具，前者偏向结对式代码协作，后者适合批量任务自动化，而企业级落地的关键则在于Skill的输入输出定义、权限最小化、日志可观测性和回归验证。从跑通最小闭环、理解Agent机制，到开阅读详情

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

摘要

摘要
从写SQL出报表到搭建智能分析 Agent，很多人以为大模型接上数据库就算完了。真正卡住线上效果的，反而是权限配置、日志追踪和可观测性。本文从一个真实项目出发，拆解我在简历里如何把这段经历写清楚，以及为什么你的 Demo 能跑通，上线第一天就崩。

---

1. 数据分析经验，真的值钱吗
2. 一个真实项目：从报表到 Agent
3. 排查过程：为什么 Demo 能跑通，上线就崩
4. 代码解释：核心逻辑拆解
5. 失败原因：业务错误、配置错误、环境错误怎么区分
6. 适用边界：什么时候该用 Agent，什么时候不该用
7. 总结：简历里怎么写这段经历

---

1. 数据分析经验真的值钱吗

文章插图 1

很多人转型大模型方向时，第一反应是学 LangChain、学 RAG，觉得自己报表做得再好也没用。但我踩过几个真实项目后发现，数据分析出身的开发者，在 Agent 项目里有几个独特的优势，但这些优势在简历上很容易被忽略。

第一个优势是指标理解能力。写报表的人，天然清楚什么是"日活"、什么是"转化率"，不会像纯开发那样被业务方一句话带跑偏。第二个优势是 SQL 和数据结构化能力。Agent 调数据、调工具，本质还是在和结构化信息打交道。第三个优势是可观测意识——报表讲究准确性、完整性，这和 Agent 上线要求的日志可追溯、权限可审计是一脉相承的。

问题在于，简历上怎么写？大多数人会写"使用 LangChain 搭建了数据分析 Agent"，但面试官看不到你做了什么取舍，看不到你踩过什么坑。接下来我会用一个真实项目，把这段经历拆清楚。

---

2. 一个真实项目：从报表到 Agent

文章插图 2

项目背景

我所在的团队有一个内部数据看板，业务方每天都要问"这个月转化率为什么跌了"。原来的做法是分析师手动拉数，平均耗时 4-6 小时。我的任务是用大模型做一个智能分析 Agent，让业务方能用自然语言提问，系统自动给出答案并附带数据来源。

输入与输出

输入：业务方的自然语言问题，例如"上周华东区转化率下降的原因是什么？"
输出：包含归因分析、关键指标对比、建议操作的 Markdown 报告，以及完整的查询 SQL 和执行日志。

步骤拆解

1. 意图识别：用 LLM 判断问题是属于"指标查询"、"归因分析"还是"趋势预测"。
2. Schema 检索：根据意图从元数据表匹配相关的表结构和字段定义。
3. SQL 生成：用 LLM 生成查询语句，并经过规则引擎做安全校验。
4. 结果解释：将查询结果回填给 LLM，生成自然语言回答。
5. 日志记录：全程记录意图、SQL、执行时间、结果条数，用于后续排查。

---

3. 排查过程：为什么 Demo 能跑通，上线就崩

项目上线第一天，系统频繁报错，用户反馈"明明 Demo 跑得挺好，为什么正式环境老出问题？"我开始按以下步骤排查。

现象一：权限报错，非业务账号无法查询

验证动作：查看后台日志，发现错误集中在 DatabasePermissionError: permission denied for table dwd_order。

原因定位：Demo 阶段用的是管理员账号直连数据库，没有经过权限层。上线后切换为业务账号，才暴露出问题。

解决方案：接入统一的数据库权限中间件，为每个 Agent 请求打上用户身份标签，做细粒度行级权限控制。

现象二：SQL 生成正确，但执行超时

验证动作：检查执行日志，发现某条 SQL 执行时间超过 30 秒，触发超时熔断。

原因定位：业务方问的是"近一年数据"，生成的 SQL 是全表扫描，没有走索引。

解决方案：在 SQL 生成环节加入查询预算约束，超过 10 万行返回的查询强制要求带上时间分区条件。

现象三：结果解释与原始数据对不上

验证动作：人工核对 Agent 输出和直接查库的结果，发现数字不一致。

原因定位：LLM 在解释结果时，对"同比"和"环比"的算法理解有误，导致偏差。

解决方案：将解释逻辑从 LLM 生成改为规则引擎 + 模板填充，只让 LLM 负责语义层面的总结。

---

优快云资料领取方式

4. 代码解释：核心逻辑拆解

以下是我在项目中用的 Agent 核心调用链代码，重点看意图识别和 SQL 生成部分。

async def analyze_question(question: str, user_id: str):
    # 1. 意图识别：让 LLM 判断问题类型
    intent_prompt = f"""
    请判断以下问题的意图类型：
    - metric_query: 单纯查询某个指标
    - attribution: 分析指标变化原因
    - trend: 预测或描述趋势

    问题：{question}
    """
    intent_result = await llm_chain.run(intent_prompt)

    # 2. 根据意图匹配 Schema
    schema = await metadata_service.get_schema(intent_result.type, user_id)

    # 3. SQL 生成，加入安全约束
    sql_prompt = f"""
    表结构：{schema}
    用户问题：{question}

    生成 SQL，必须满足：
    - 不超过 10 万行查询
    - 禁止 SELECT *
    - 必须包含 WHERE 时间条件
    """
    raw_sql = await llm_chain.run(sql_prompt)
    validated_sql = sql_validator.validate(raw_sql)

    # 4. 执行查询并记录日志
    result = await db.execute(validated_sql, user_id=user_id)
    log_entry = {
        "question": question,
        "intent": intent_result.type,
        "sql": validated_sql,
        "rows": len(result),
        "user": user_id,
        "timestamp": datetime.now()
    }
    await audit_log.save(log_entry)

    # 5. 结果解释
    explanation = await explain_result(result, intent_result.type)
    return explanation

逐段说明：

意图识别：输入是用户问题，输出是意图类型。这里用 few-shot prompt 让 LLM 做分类，而不是直接生成 SQL，因为分类比生成 SQL 更容易验证准确性。
Schema 检索：根据意图和用户 ID 获取对应的表结构和字段权限，这一步是关键——不同业务方能看到的数据范围不同，必须在检索阶段就隔离。
SQL 生成：prompt 里明确写了三条安全约束，避免生成危险查询。sql_validator 是一个基于正则和 AST 的校验层，会二次检查 LLM 输出的合法性。
日志记录：每条请求都存一份审计日志，包含原始问题、意图、最终执行的 SQL、返回行数。这是上线后排查问题的核心依据。
结果解释：这里我把解释逻辑拆成了单独的方法，方便后续替换实现方式。

---