《我用数据分析经验做了次 AI 项目，最先失效的是旧方法》看起来是个大话题，但真落到项目里，常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。

摘要

> 从报表工程师到做 Agent，我以为最难的是调模型，结果第一个拦路虎是权限和日志。本文复盘一次真实项目，讲清楚小团队如何避免过度设计，把 Agent 真正跑起来。

目录

• 数据分析的天花板，我碰过
• 自然语言 BI 不是噱头，但也不是聊天机器人
• 指标解释 Agent 的核心：让模型知道边界在哪
• 工具调用：SQL 生成只是第一步
• 项目复盘：Demo 能跑，上线却崩了
• 总结：小团队的取舍之道

---

目录

• 数据分析的天花板，我碰过
• 自然语言 BI 不是噱头，但也不是聊天机器人
• 指标解释 Agent 的核心：让模型知道边界在哪
• 工具调用：SQL 生成只是第一步
• 项目复盘：Demo 能跑，上线却崩了
• 总结：小团队的取舍之道

数据分析的天花板，我碰过

做了五年数据分析，从取数写 SQL，到搭报表，再到做预测模型，每一步都觉得自己离业务更近了一点。但说实话，越往后越感觉碰壁——业务方问的问题越来越灵活，"这个指标为什么跌了"背后往往要串联十几个表、几十个口径，报表再漂亮也只能回答"是什么"，解释不了"为什么"。

今年我开始接触 Agent 方向，第一个想法是：能不能让模型自己查数、自己解释？听起来很顺，真正做起来才发现，最难的不是让模型生成 SQL，而是让模型在正确的边界内工作。

我踩过最大的坑，是用 Demo 的思路去做生产。Demo 里模型生成了 SQL，查到了数据，看起来一切完美。但上线之后，问题一个个冒出来：权限失控、查询耗时不可控、模型幻觉编造指标，日志里完全没有可追溯的痕迹。

所以这篇文章不讲怎么搭一个能跑的 Agent，而是讲怎么让一个 Agent 真正能上线——尤其是小团队，资源有限，更要避免过度设计。

---

自然语言 BI 不是噱头，但也不是聊天机器人

市面上自然语言 BI 的产品很多，核心思路都是：用户问一句自然语言，模型转成 SQL，查数据库，返回结果。

这个流程本身没有技术难度，难的是结果的可信度。

我之前的项目中，业务方最关心的不是"能不能问"，而是"模型返回的数据对不对"。有一次模型把"毛利率"和"净利率"的口径搞混了，返回的结果完全错误，业务方直接质疑了整个系统的可靠性。

所以做自然语言 BI，首先要解决的不是模型能力，而是指标口径的管理。我的做法是把核心指标和口径定义成一个结构化文档，让模型在生成 SQL 之前先"查阅"这份文档，而不是凭训练数据里的模糊记忆去猜。

# 指标口径定义示例（JSON 结构，供模型上下文使用）
METRIC_SCHEMA = {
    "metrics": {
        "gross_margin": {
            "name": "毛利率",
            "formula": "(revenue - cost) / revenue",
            "filters": {"status": "completed"},
            "granularity": "day"
        },
        "net_profit": {
            "name": "净利润",
            "formula": "revenue - cost - tax - expense",
            "filters": {},
            "granularity": "month"
        }
    }
}

这段代码不是生产级的完整实现，只是一个示意——实际项目中这个 schema 会更大，会包含表关系、字段注释、口径变更历史等。但核心思路是一样的：把模型可能幻觉的领域，变成可查的结构化知识。

---

指标解释 Agent 的核心：让模型知道边界在哪

我做的第一个 Agent 版本，模型可以回答"上周毛利率为什么下降了"，但经常给出一些看起来很合理但实际没有数据支撑的解释。比如模型会说"因为某地区的订单量下降"，但实际上那个地区根本没有数据异常。

后来我调整了设计：让 Agent 在解释之前，必须先验证每一个因果链上的节点是否有数据支撑。

async def explain_metric_drop(metric: str, period: str, context: dict):
    # 第一步：查询指标变化
    change = await query_metric_change(metric, period)

    # 第二步：如果变化存在，再拆解到子维度
    if change.significant:
        breakdown = await drill_down(metric, period, dimensions=["region", "product"])
        # 第三步：每个维度都要有数据支撑才能归因
        reasons = [d for d in breakdown if d.has_data]
    else:
        reasons = []

    # 第四步：用模型生成解释，但限制在 reasons 范围内
    explanation = await llm.generate(
        prompt=build_prompt(metric, change, reasons),
        temperature=0.3  # 解释类任务温度要低
    )
    return explanation

这个流程的关键点：

• temperature 设低：解释类任务不需要创造性，需要准确性
• 先验证再解释：模型不能在没有数据的情况下编故事
• 归因范围受控：模型只能从有数据支撑的维度里选原因

---

工具调用：SQL 生成只是第一步

很多教程讲 Agent 工具调用，重点都在"如何让模型学会调用工具"。但实际项目中，工具调用本身不是最难的部分，调用之后的权限控制和结果校验才是。

我遇到的一个具体问题：模型生成的 SQL 没有 WHERE 条件，直接跑全表查询，把数据库拖慢了。这不是模型能力问题，是权限没有隔离。

我的解决方案是在工具调用层加一个中间件，拦截所有 SQL，做三件事：

class SQLValidator:
    def validate(self, sql: str, user_role: str) -> ValidationResult:
        # 1. 检查是否有全表扫描风险
        if self.detect_full_scan(sql):
            return ValidationResult(rejected=True, reason="可能全表扫描")

        # 2. 根据角色注入 WHERE 条件
        sql = self.inject_filters(sql, user_role)

        # 3. 限制查询结果行数
        sql = self.limit_rows(sql, max_rows=10000)

        return ValidationResult(approved=True, sql=sql)

这套逻辑不需要多复杂，但必须存在。小团队可以不用昂贵的网关方案，自己写一个轻量级的中间件就够了。

---

项目复盘：Demo 能跑，上线却崩了

我的项目经历了三个阶段，每个阶段踩的坑都不一样：

第一阶段：Demo 跑通了，自信满满。 模型能生成 SQL，能返回数据，业务方看了也很满意。这个阶段最容易产生错觉——觉得项目已经完成了。

第二阶段：上线第一周，问题爆发。 有用户问了一个很刁钻的问题，模型返回了错误数据；有查询超时导致服务抖动；日志里没有任何线索可以追溯。这个阶段最痛苦，因为你知道问题出在哪，但修复成本比预想的高得多。

第三阶段：重新设计，把权限和日志放在第一位。 我花了一周时间，把之前的 Agent 推倒重来，核心改动就三件事：权限隔离、查询限流、完整日志。改完之后，系统稳定了很多，业务方也开始真正用起来。

这三个阶段的顺序，我觉得值得所有想从数据分析转型做 Agent 的人参考。不要跳过第一阶段直接做第三阶段，但一定要在第二阶段之后认真做第三阶段。

---

总结：小团队的取舍之道

从数据分析转大模型 Agent 开发，我以为最难的是技术门槛，结果发现工程化能力才是真正的小团队分水岭。

几个具体的建议：

1. 别一上来就追求全自动。先做半自动，模型生成 SQL，人工确认后执行，积累信任再逐步放开。

2. 权限和日志优先于模型调优。模型效果差一点可以接受，权限失控和日志缺失是致命问题。

3. 指标口径是资产，不是附属品。把口径管理做成独立模块，Agent 和其他系统都能复用。

4. 小团队不要过度设计。用轻量中间件替代复杂网关，用结构化文档替代重型知识库，够用就行。

5. Demo 和上线之间隔着一条沟。这条沟叫"权限、日志、可观测性"，跨过去之前不要觉得自己已经准备好了。

我现在的判断是：数据分析背景的人在 Agent 开发中有独特优势——对数据口径敏感、对查询逻辑有直觉、对结果准确性有执念。但这些优势只有在工程化能力补齐之后才能真正发挥出来。

权限和日志，这些以前做报表不太关心的问题，现在是 Agent 能不能上线的生死线。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

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