数据分析师用14行代码回答1个问题，这工具把流程压到5行

一个数据分析师每天重复多少次这样的动作：加载CSV、写df.describe()、眯眼看列名、写14行pandas代码回答一个问题，然后重来一遍。有人统计过，平均每个分析任务要切换7次窗口，复制粘贴12次。当数据量超过百万行时，这套流程开始像用算盘做气象预测。

大语言模型（LLM，Large Language Model）现在能代写那14行代码，还能自己运行。这就是数据分析智能体（Data Analysis Agent）的核心逻辑：你用英语提问，它生成pandas代码，在隔离的Python环境里执行，读取输出，再用自然语言返回答案。没有手动清洗，没有单元格之间的复制粘贴。

本文梳理4种从生产环境验证过的实现模式——从5行代码的快速启动，到完全自定义的分析流水线。

模式一：LangChain的5行捷径

create_pandas_dataframe_agent是CSV到答案的最快路径。它把你的数据框（DataFrame）包装成工具调用型智能体，通过隔离的Python交互式环境（REPL，Read-Eval-Print Loop）编写并执行pandas代码。

安装依赖：

pip install langchain-experimental langchain-openai pandas

加载数据并创建智能体：

import pandas as pd
from langchain_openai import ChatOpenAI
from langchain_experimental.agents.agent_toolkits import (
create_pandas_dataframe_agent,
)

df = pd.read_csv("sales_data.csv")

llm = ChatOpenAI(model="gpt-4o", temperature=0)

agent = create_pandas_dataframe_agent(
llm,
df,
agent_type="tool-calling",
verbose=True,
allow_dangerous_code=True,
)

allow_dangerous_code=True这个参数不是装饰性的。智能体确实会针对你的数据框执行真实Python代码，必须显式授权。这条命令只应在隔离环境里运行——绝不要放在存有敏感数据的生产服务器上。

执行查询：

result = agent.invoke("What are the top 5 products by total revenue?")
print(result["output"])

智能体会检查数据框的列名和数据类型（dtypes），生成类似df.groupby('product')['revenue'].sum().nlargest(5)的表达式，执行后把结果翻译成自然语言返回。

多数据框支持。传入数据框列表即可跨数据集比对：

df_2024 = pd.read_csv("sales_2024.csv")
df_2025 = pd.read_csv("sales_2025.csv")

agent = create_pandas_dataframe_agent(
llm,
[df_2024, df_2025],
agent_type="tool-calling",
verbose=True,
allow_dangerous_code=True,
)

result = agent.invoke(
"Which products grew more than 20% between 2024 and 2025?"
)

适用场景：小到中型数据集（100万行以内，能装进内存）、快速探索性分析、原型验证。

局限：智能体会把数据框的前几行和列名发给LLM当上下文。列数超过100的宽表会让模型注意力过载。数据量更大时，切到模式二。

模式二：当数据框装不下的时候

数据规模突破内存边界——几百万行、多张关联表、或者任何适合用数据库的场景——需要换架构。

核心思路不变：LLM生成查询语句，在隔离环境执行，解析结果。变的只是执行层从pandas换成SQL引擎。

具体实现通常是这样的结构：

1. 把CSV导入临时SQLite或DuckDB
2. 智能体接收数据库模式（schema）而非原始数据
3. LLM生成SQL查询而非pandas代码
4. 执行引擎返回聚合结果

这种模式把上下文消耗从O(n)降到O(1)，n是数据行数。1000万行和100行的表，传给LLM的上下文量几乎相同，都是表结构和字段类型。

一个细节：DuckDB在这个场景里比SQLite更顺手。它支持直接查询CSV文件而不需要预先导入，语法更接近pandas的向量化风格。对于"找出连续7天销售额下滑的门店"这类时序问题，DuckDB的窗口函数写起来比pandas的rolling+apply组合更不易出错——而LLM恰好擅长生成这种标准SQL。

边界情况处理。当用户问"这张表有什么问题"时，SQL模式的智能体会先跑DESCRIBE和SELECT COUNT(*)，再抽样检查异常值。这比pandas模式更省token，因为不需要把样本数据塞进上下文。

模式三：自定义工具链

前两种模式都是开箱即用。但生产环境往往有额外约束：必须用内部的数据脱敏服务、审计日志要记录每次查询、或者需要对接特定的可视化平台。

这时候需要拆解智能体的内部结构，自己组装。

一个数据分析智能体至少包含四个组件：

规划器（Planner）：把用户问题拆成可执行的子步骤。比如"各区域Q3同比增长"会被拆成"定位日期列→筛选7-9月→按区域分组→计算同比→排序"。

代码生成器：针对每个子步骤生成具体代码。可以用Few-shot prompting，给几个正确示例引导LLM模仿。

执行沙箱：隔离的运行环境。常见的选择有：Docker容器、受限Python解释器（如RestrictedPython）、或者远程的无服务器函数（Serverless Function）。

结果解释器：把执行输出（可能是DataFrame、图表文件、或者错误堆栈）转换成用户能理解的回答。

LangChain的AgentExecutor把这四步串成循环：规划→生成→执行→观察→（必要时）重新规划。自定义时，你可以替换其中任意一环。

一个实际改造案例：某金融科技公司把执行沙箱换成了内部Jupyter Kernel Gateway，因为合规要求所有计算必须在审计过的环境里完成。他们保留了LangChain的规划器和代码生成器，但重写了工具调用接口——从本地REPL变成HTTP请求到远程Kernel。

改造代价：原本5行代码的启动变成200行配置。收益：通过了SOC 2审计。

模式四：多智能体协作流水线

最复杂的分析任务需要多个角色配合。想象一个场景：用户上传了3张CSV，问"为什么华东区上季度利润率下滑"。

这涉及：

- 数据工程师：检查表关联关系，处理缺失值
- 分析师：计算利润率趋势，定位异常时间点
- 领域专家：结合外部知识（比如竞品促销、天气数据）解释原因

单智能体很难同时做好这三件事。多智能体架构把任务路由给不同角色，通过共享状态协作。

实现框架通常用LangGraph或类似的状态机工具。每个节点是一个专用智能体，边定义流转条件。比如：