如果你和我一样日常工作里有很大一块时间花在“读数据、做EDA、调特征、跑模型”这些事上那你最近应该也注意到了deer-flow这个名字。它是Dell那边的团队开源的一个项目一句话概括就是用大模型和多智能体把完整的数据科学流程串起来从一包CSV文件开始自动生成EDA报告、特征工程代码、模型训练脚本和评估结果。GitHub上Star涨得很快因为它踩中了一个很实在的痛点数据科学的入门门槛已经很低了但“从原始数据到可用模型”的中间环节仍然极其耗时。这篇文章我打算从架构、实操到避坑把我实际使用deer-flow的全过程梳理一遍适合对MLOps、LLM Agent和数据自动化感兴趣的人参考。1. DeerFlow解决的是数据科学里的“最后一公里”自动化问题1.1 它定位在哪介于AutoML和完整的数据科学Agent之间传统AutoML工具比如TPOT、AutoGluon、H2O解决的核心问题是“模型的搜索和调参”。它们的输入通常是已经清洗好的特征矩阵输出是一组模型指标和最优模型。但这里有个隐含前提数据已经被处理得足够整齐了。实际工作里的大部分时间恰恰花在“把数据变整齐”之前——你要先理解字段含义做缺失值处理观察分布想特征试模型再回来补特征。这一整条链路AutoML帮不了你。DeerFlow走的是更前面的一段。它从一份原始数据文件加一份数据字典开始先让LLM读明白“这个数据集到底在讲什么事”再基于这个理解自动规划后续步骤。所以它更像一个“会思考的数据分析师”而不是一个“会调参的黑盒子”。你给它一包数据它会自己决定先看什么、算什么、画什么、最后建什么模型。1.2 它和传统AutoML工具的本质区别我这里直接摘一张对比表方便你快速理解它的定位差异。维度传统AutoMLDeerFlow覆盖范围只覆盖模型训练与调参覆盖EDA、特征工程、训练、评估全流程输入要求需要相对规范的特征矩阵原始CSV加字段说明即可交互方式配置参数、调搜索空间每个阶段可暂停、给出反馈、干预方向可解释性偏弱只看指标结果生成分析结论和中间代码每一步有依据核心驱动算法搜索LLM推理 Agent编排适合场景竞赛冲榜、已清洗好的数据探索性分析、快速验证、流程自动化一句话总结传统AutoML帮你找“最好的模型”DeerFlow帮你走完“从原始数据到模型”的完整探索过程。1.3 适合谁用不适合谁用适合的几类人有数据基础但想加速探索流程的分析师和数据科学家。DeerFlow可以帮你快速产出一份EDA报告让你把精力放在业务判断上。需要频繁做“数据能不能预测”可行性验证的工程师。以前要写一堆脚本现在只要给CSV和字段说明几分钟就能看到初步结论。研究LLM Agent编排的开发者。DeerFlow的多Agent协作机制本身就是很好的参考实现。不适合的场景也很明确完全不懂数据的人。LLM输出仍然需要人来判断尤其是特征工程这一步业务常识仍然是不可替代的。追求极致模型精度的比赛场景。它的定位是流程自动化不是模型竞赛想刷榜还是得自己手动调。超大规模数据。它是基于样本探索的机制不适合直接灌几百GB的数据。2. 多智能体架构拆解谁在规划、谁在分析、谁在建模DeerFlow不是一个单体程序而是一组各司其职的Agent在Orchestrator的调度下协作完成数据科学流程。我刚开始用的时候以为它就是一个封装好的AutoML接口真正读了源码才发现它的架构设计更接近“组建一个虚拟数据团队”。2.1 Orchestrator整个流程的“项目经理”Orchestrator是整个系统的核心负责三件事理解任务目标、拆解执行步骤、分发子任务给对应Agent然后把结果汇总给用户。具体来说它会读取你给的任务描述和数据字典通过LLM生成一个初步的执行计划。比如任务目标是“预测用户是否会流失”它会规划出这样的流程先做探索性分析、再处理缺失值和异常值、构建特征、训练模型、评估结果。它不是一次性把整条流程跑完而是每完成一个阶段就把结果反馈给用户用户可以决定是否调整方向。这个机制很关键因为数据科学本质上是一个迭代过程不是一条直线走到底。我实际用下来Orchestrator最大的价值是“记住上下文”。它知道前面EDA发现了什么后面特征工程就会重点处理那些问题。比如EDA发现某个字段缺失率高达40%FeatureNerd就会自动考虑缺失值标记而不是简单填充了事。2.2 EDA Agent自动读数据、出图、写结论EDA Agent是第一个接触数据的组件它做的事情和数据分析师的前期工作一样加载数据、检查数据形状和类型、统计缺失值、分析分布、计算相关性然后把这些结果转化为可视化和文字结论。这里的核心难点不是画图而是“让LLM看懂数据”。DeerFlow的做法是给EDA Agent提供数据采样的统计摘要而不是让它直接读几万行原始数据。这样既控制了token成本又能保证LLM拿到足够的信息做判断。我见过它生成的EDA报告质量相当不错。不仅包含缺失值热力图、数值分布直方图、分类变量计数图这些常规图表还能用文字写出一段像样的分析结论比如“年龄字段存在177个缺失值建议用中位数填充Survived与Sex相关性明显女性存活率显著高于男性”。这已经达到了初级数据分析师的水平。2.3 FeatureNerd把领域经验变成特征代码FeatureNerd是DeerFlow里我最欣赏的组件它的职责是特征工程。别小看这一步特征工程是数据科学流程里最依赖经验和业务知识的环节也是以前最难自动化的一环。FeatureNerd接收EDA Agent的输出根据数据字典里的字段说明生成特征工程代码。比如它会自动决定对缺失值字段用均值还是中位数填充对类别字段用Label Encoding还是One-Hot Encoding是否创建组合特征是否进行标准化处理。更实用的是它生成的代码不是一次性写死而是会尝试运行、观察结果、再调整。比如它生成的填充代码如果因为数据类型不匹配报错它会自动改写重试。我在泰坦尼克数据上跑的时候它自动创建了一个FamilySize特征SibSp Parch 1这基本上是我自己会做的操作说明它对常见特征工程的套路确实有理解。2.4 Trainer与Evaluator模型方案的“执行层”特征工程完成之后Trainer会接手。它会根据任务类型分类、回归、时间序列等选择合适的算法自动生成训练脚本。常见的模型比如逻辑回归、随机森林、XGBoost、LightGBM它都会尝试然后用交叉验证对比效果。Evaluator则会计算多个评估指标比如准确率、精确率、召回率、F1分数、AUC等生成评估报告给出推荐模型。这一步同样是自动化的但它不会把结果强加给你而是把不同模型的表现呈现出来让你做最终选择。值得一提的是DeerFlow也支持做一些简单的超参数搜索但不深入。它不是用来替代Hyperopt或Optuna的而是让你在自动化流程里快速得到“够用”的基线模型。2.5 智能体之间怎么协作状态、上下文与反馈循环DeerFlow的多Agent不是简单的“一个调用另一个”而是有明确的状态管理和上下文传递机制。整个流程从Planner开始生成任务计划后每个Agent依次执行执行结果通过共享状态传递给下一个Agent。这个设计让我想到一个真实的团队协作场景项目经理拆解需求数据分析师做探索特征工程师写特征算法工程师训练模型测试评估效果每个环节的产出都是下一个环节的输入。DeerFlow只是把这个过程数字化了。3. 本地跑通DeerFlow环境、配置与第一个DEMO3.1 依赖管理为什么项目选了uvDeerFlow的安装方式和我见过的很多Python项目不太一样官方推荐用uv而不是pip。uv是一个用Rust写的Python包管理工具特点是快、锁文件可靠。对于DeerFlow这种依赖大量的项目来说uv比pip快了很多倍。我的安装步骤是这样做的git clone https://github.com/dell/deer-flow.git cd deer-flow uv sync如果你还没有安装uv先用官方脚本装一下curl -LsSf https://astral.sh/uv/install.sh | sh然后配置LLM API Keyexport OPENAI_API_KEYyour-api-key这里有一个很容易踩的坑DeerFlow的依赖里有pydantic、langchain、openai这些库如果直接用pip安装版本冲突会让你调很久。用uv sync的好处是它会严格按照lock文件安装基本不会出现依赖冲突问题。3.2 LLM配置后端选择与关键参数DeerFlow在设计上对LLM后端做了抽象也就是说你不一定非要用OpenAI的模型。它支持OpenAI、Anthropic、Google Gemini也支持通过兼容OpenAI协议的本地模型接入。我的建议是第一步先用OpenAI兼容接口跑通确认整个流程能走通之后再根据成本和效果换模型。在环境变量里配置好API Key和模型名称比如export OPENAI_API_KEYsk-xxx export OPENAI_MODELgpt-4o-mini模型选择上我个人是这样分配的规划、总结这些需要强推理能力的环节用gpt-4o级别的大模型EDA和特征工程这些偏执行的环节用gpt-4o-mini这类便宜模型。DeerFlow的架构支持在不同Agent里配置不同模型这个灵活度很实用。3.3 数据准备CSV、数据字典与任务描述DeerFlow和纯AutoML工具最大的区别之一就是它需要一份数据字典。别嫌麻烦这一步非常关键。LLM不像人一样知道“Survived”字段代表存活与否但你在数据字典里写清楚之后它就能做出准确的判断。我准备数据的方式是这样的建一个项目目录my_project/ ├── dataset/ │ └── train.csv ├── data_dict.json └── task.txtdata_dict.json长这样{ PassengerId: 乘客编号唯一标识, Survived: 目标变量1表示存活0表示死亡, Pclass: 船舱等级1/2/3, Name: 乘客姓名, Sex: 性别, Age: 年龄存在缺失值, SibSp: 同行的兄弟姐妹或配偶数量, Parch: 同行的父母或子女数量, Ticket: 船票编号, Fare: 票价, Cabin: 舱位号存在大量缺失值, Embarked: 登船港口 }task.txt里写一句任务描述“根据乘客信息预测Survived字段这是一个二分类任务。”数据字典写得越清楚后面EDA和特征工程的质量就越高。如果你对数据集有领域知识一定要写进去。比如“Age存在缺失值”FeatureNerd就会优先处理年龄缺失值而不是等EDA发现了才处理。3.4 执行流程从启动到产出报告的全过程数据和配置准备好之后就可以启动整个流程了。根据你下载的代码版本启动方式可能会有一点差异但逻辑是一样的指定任务描述、数据字典和数据文件的路径然后启动编排器。流程启动后DeerFlow会按照我们前面说的架构逐步执行。每个阶段结束都会产生中间产物用户可以在这些节点介入给出反馈比如“Age字段不要简单填充中位数请用基于Pclass和Sex的分组中位数填充”。Orchestrator会把反馈传给下一个Agent后面的流程就会按照你的新要求执行。整个流程跑完之后项目目录下会生成一个输出文件夹里面有EDA报告HTML/Markdown格式包含图表和结论特征工程脚本可直接运行的Python代码训练脚本和模型文件评估报告包含各模型指标对比4. 用泰坦尼克数据实测DeerFlow的输出质量到底怎么样4.1 实验设置与数据说明为了验证DeerFlow的实际效果我用经典的Titanic数据集做了一次完整的端到端测试。数据集包含891行、12列目标变量是Survived。我的配置参考如下配置项设置LLM ProviderOpenAI兼容接口规划/总结模型gpt-4o-miniEDA/特征模型gpt-4o-mini任务类型二分类评估指标Accuracy、F1、AUC从数据规模来看891行的数据量对Agent来说属于非常轻量的场景整个流程跑下来大概用了20多分钟其中有大量时间花在LLM推理和代码执行上。4.2 EDA输出洞察多于图表的“分析报告”DeerFlow生成的EDA报告是我认为整条流水线中最有价值的部分。它没有停留在“画出所有列的分布图”这种敷衍层面而是给出了有针对性的图表组合和文字结论。我还记得它输出的几个关键洞察缺失值分析Age缺失177条Cabin缺失687条。它建议Cabin不要直接填充而是创建一个“是否有Cabin信息”的二值特征这个思路非常有经验。目标变量分布Survived为正负样本约为342:549存在一定不平衡建议在评估时重点关注F1而不是准确率。单变量分析女性存活率约74%男性约19%Sex是预测力最强的特征。多变量分析Pclass和Fare高度相关高票价的乘客存活率更高但Pclass的区分度更直接。这些结论不是网上教程里的标准答案而是Agent根据当前数据集实际计算出来的。能自动产出这种水平的分析报告已经不是简单的图表堆砌了。4.3 特征工程与模型效果实测FeatureNerd生成的代码质量比我预期的要高。它执行的特征处理包括用中位数填充Age缺失值创建Cabin缺失标记特征对Sex、Embarked做Label Encoding创建FamilySize特征SibSp Parch 1对Age和Fare做标准化处理删除无关字段PassengerId、Name、Ticket这里要注意删掉PassengerId和Name是正确判断。很多新手做Titanic时会保留这两个字段结果模型学到一堆噪声。FeatureNerd基于数据字典里“姓名与存活无关”的说明自动做出了删除决策说明数据字典真的在起作用。模型表现方面它测试了三种算法模型AccuracyF1 ScoreAUCLogistic Regression0.790.740.85Random Forest0.810.760.87XGBoost0.820.770.88最终推荐了XGBoost这个结果和Kaggle上常见的Titanic公开基线非常接近。虽然不是顶尖成绩但对于一个完全自动化的流程来说这个水平已经足够在项目早期做可行性验证了。4.4 运行成本与等待时间的真实感受很多人关心用DeerFlow跑一个项目到底要花多少钱。以我的实测为例整个流程大约消耗了几万tokengpt-4o-mini的花费折合美元不到1块。即便换成gpt-4o级别的大模型一次完整运行的费用也在几美元以内相比人工分析的时间成本这个开销可以忽略不计。等待时间倒是比花费更需要你提前做好心理准备。整个流程不是一次性出结果而是分阶段执行每个Agent都要经历思考、生成代码、执行代码、观察结果、修正代码的循环。在数据量较大的情况下一个阶段的执行可能需要好几分钟。所以不要把它当成一个“点击就出结果”的工具它更适合在后台运行你隔一段时间回来看看进度。5. 深入使用后的避坑清单与调优思路5.1 成本控制哪个环节最烧token用了一段时间DeerFlow之后我最大的感触是如果不对LLM调用做规划账单会涨得很快。最烧token的环节不是最后的模型训练而是EDA和特征工程这两个阶段。原因在于这两个阶段涉及多次“生成代码→执行→报错→重新生成”的循环。一旦代码执行失败Agent会带着错误信息重新调用LLM一次失败可能会多消耗上千token。遇到复杂数据处理时这种失败可能反复发生。我建议的优化策略数据量较大的时候让DeerFlow先对数据做采样用样本探索而不是全量分析。在关键阶段用便宜的模型跑通流程最后用强模型做总结和模型选型。及时保存每个阶段的产物如果流程在中途失败可以从上一个成功的阶段续跑而不是从头再来。5.2 数据规模与运行时间的平衡策略DeerFlow在机制上决定了它更适合中小规模数据。原因在于Agent在探索阶段会反复读取和分析数据样本数据量越大每次分析和代码执行的时间就越长。我用几万行数据测试过整个流程跑下来基本可控但几百万行的数据就不太现实了。如果必须处理大数据集我的建议是先做预聚合或降采样把数据压缩到Agent能处理的规模跑通流程得到结论后再用全量数据训练最终模型。不要让Agent直接去啃全量数据那是自找麻烦。5.3 自定义Agent把业务逻辑接入流程DeerFlow真正的扩展性体现在它允许你添加自定义Agent。这个设计让它不只是一个开箱即用的工具还可以成为一个定制化的数据分析平台。比如我之前在自己的项目里给它加了一个“合规检查Agent”。因为公司内部有一套风控规则所有特征都必须经过规则校验才能用于建模。我以前需要手动跑一个脚本做检查现在把这个逻辑封装成一个自定义AgentOrchestrator会在特征工程完成后自动调用它只有通过检查的特征才会进入训练阶段。添加一个自定义Agent的流程大概是在agents目录下新建一个Agent类实现接收输入上下文、返回结果的接口然后在Orchestrator的调度逻辑里注册它。代码结构比我想象中清晰不需要理解所有内部实现只要按接口规范来实现就行。5.4 稳定性问题与我的解决思路LLM本身就是概率性的所以DeerFlow每次运行的结果会有一定差异。这既是特点也是缺点有可能这次生成的代码质量很高下次同一个数据集生成的代码就出现语法错误。DeerFlow本身内置了重试机制但我实测下来把重试次数调高一些会更稳。另外如果你发现某个Agent频繁在某类操作上报错可以在Prompt里补充更明确的指令或者修改对应的数据字典描述让LLM更容易理解你的意图。还有一个容易被忽略的点DeerFlow生成的中间产物是Python脚本理论上你完全可以在流程结束后手动修改这些脚本把Agent生成的代码改造成你自己的生产级数据处理流程。我经常这么干等于是让Agent先帮我写好初版代码我再在上面做业务化改造效率比自己从零开始写高不少。最后说一点个人体会。我是从AutoML工具转过来试DeerFlow的最大的感受不是它能不能替代数据科学家而是它把“从数据到模型”这条链路里最枯燥的部分接管了。把EDA、特征工程、训练这些重复劳动交给一个会思考的Agent自己专注在业务判断上这才是这类工具真正的价值。如果你也在研究LLM Agent落地方案我建议你拿一个自己没有接触过的数据集实测一次成本不高但你会对“自动数据科学”这件事产生完全不同的直觉。