一个熟练的 pandas 用户每天重复同一个动作：加载 CSV，写 df.describe()，眯眼看列名，再写 14 行代码回答一个业务问题。重复 20 次，一天过去了。
LangChain 最新放出的工具把这个流程压缩到一句话。你问"哪款产品在 Q3 营收增长超 20%"，Agent 自己写代码、自己跑、自己返回答案。整个交互不超过 10 秒。
这不是 demo，是已经能进生产环境的四种实现路径。
5 行代码的暴力美学
最快的路径叫 create_pandas_dataframe_agent。安装依赖只需要 langchain-experimental 和 langchain-openai，加载数据后 5 行代码完成初始化。
核心参数 allow_dangerous_code=True 是强制项。Agent 会在沙箱环境里执行真实 Python 代码，所以必须显式授权。官方文档加粗警告：永远不要在存有敏感数据的生产服务器上跑这个。
执行逻辑很直白。Agent 把 DataFrame 的前几行和列类型发给 LLM 当上下文，LLM 生成类似 df.groupby('product')['revenue'].sum().nlargest(5) 的表达式，沙箱执行后返回自然语言结果。
多表对比也支持。把两个 DataFrame 装进列表传进去，可以直接问"2024 到 2025 年哪些产品增长超 20%"。Agent 会自动处理表关联和计算逻辑。
适用边界很清晰：内存能装下的中小数据集（100 万行以内），快速探索性分析，原型验证。
100+ 列的宽表会踩坑。Agent 把列名和样本数据塞进 prompt，列太多会挤爆模型的注意力窗口。数据量上去之后，得换第二种模式。
大表的解法：让数据库替 Agent 扛
Pattern 2 的核心思路是"不把数据喂给 LLM，把问题翻译给数据库"。用 SQL 替代 pandas，用查询计划替代全量传输。
LangChain 的 SQL Agent 走这个路线。它连接数据库后，先读取 schema 和采样数据，把用户的自然语言问题转成 SQL，执行后把结果摘要返回。整个过程 LLM 只接触元数据，不碰原始行数据。
性能差距很明显。一个 5000 万行的表，pandas 模式要把头几行全塞进 prompt，SQL 模式只需要几十字节的 schema 描述。延迟从秒级降到毫秒级。
但 SQL Agent 有另一个坑：LLM 写的查询可能全表扫描。生产环境必须加一层查询审计，或者限制只读权限。
第三种模式：工具链组装
前两种都是开箱即用。Pattern 3 开始拆零件。
核心组件是 PythonREPLTool 和自定义工具的组合。你可以把公司内部的特征工程库、专有算法、甚至另一个微服务，包装成 Agent 可调用的工具。Agent 的决策逻辑不变：理解问题→选择工具→执行→整合结果。
一个典型场景：用户问"预测下季度华东区的退货率"。Agent 调用内部预测模型工具获取基准值，再调用天气数据工具查台风季影响，最后用 Python 工具做敏感性分析。三个工具串成工作流，全程无人工介入。
这种模式的生产门槛最高，但天花板也最高。
工具描述的质量直接决定 Agent 的调用准确率。描述写得太泛，Agent 会乱选工具；写得太细，prompt 又太长。目前业内没有统一的最佳实践，全靠反复调试。
第四种：完全自定义的流水线
Pattern 4 把 LangChain 的 orchestration 层也拆了，只用底层抽象自己搭。
适合的场景很具体：有现成的特征平台，有固定的分析范式，需要把 Agent 嵌进现有产品工作流。比如一个电商后台，运营点击"分析流失用户"，背后触发的是预设好的多步骤 pipeline：拉取 cohort 数据→跑生存分析→生成可视化→推送结论到钉钉。
这种模式下 Agent 更像一个"会写代码的调度员"，而不是通用助手。它的价值在于把人工判断的环节自动化，比如根据数据分布自动选择统计检验方法，或者根据异常值比例决定是否做对数变换。
四种模式从快到慢、从封闭到开放，覆盖了 90% 的数据分析自动化场景。
但所有模式共享同一个未解问题：当 Agent 生成的代码出错，或者结果明显违背业务常识，谁来背锅？目前的主流做法是"人机回环"——Agent 给出答案后必须人工确认才能写入下游系统。
这引出一个更底层的追问：如果每个结论都需要人复核，我们到底省下了什么？
热门跟贴