DATAGEN 拆解：用 LangGraph 把假设、分析、写作串成一条多智能体流水线

它要解决的是流程编排，不是模型能力

数据分析的门槛往往不在某一步，而在步骤之间的衔接。提出假设、写代码、跑结果、画图、写成报告，每一环都有人做过工具，但把它们串成一条能回溯的链路需要人工搬运上下文。DATAGEN 的定位就是这条链路：README 把项目描述为「automated data analysis and research through a multi-agent system」，并列出 hypothesis_agent、process_agent、visualization_agent、code_agent、searcher_agent、report_agent、quality_review_agent、note_agent 八个角色。目标读者是能读 Python、愿意改 main.py 里 user_input 变量的研究者或数据工程师，而不是想点几下按钮就出图表的业务用户。仓库没有提供 Web 界面，也没有发布过 release。

八个 agent 的分工与 note_agent 的位置

从 README 的组件清单看，分工是沿着研究流程切的。hypothesis_agent 负责生成研究假设，process_agent 监督整个研究过程，code_agent 写分析代码，visualization_agent 出图，searcher_agent 做文献与网络检索，report_agent 写报告，quality_review_agent 做质量评审。note_agent 的角色比较特殊，README 在 Key Features 里把它称为「Note Taker agent」，作用是记录研究过程、维持上下文。这类设计通常是为了对抗长流程里的上下文丢失：当 code_agent 和 report_agent 之间隔了若干轮工具调用，谁记得上一轮假设被否掉的原因，就决定了最终报告会不会自相矛盾。README 没有给出 note_agent 具体写入什么格式、存在哪里，这一点需要读源码确认。

LangGraph 状态图里的人工介入点

工作流用 LangGraph 组织成一个状态图，README 列出的步骤是：假设生成、人工选择（继续或重新生成假设）、处理（包含数据分析、可视化、检索、报告撰写）、质量评审、按需修订。第二步是整条链路里唯一明确的人工卡点，也是这个项目和全自动 pipeline 的主要区别。假设一旦被接受，后续的处理阶段由 process_agent 调度，人不再介入，直到 quality_review_agent 给出评审结果。这种设计把人的判断力放在最贵的环节（方向选择），把机械环节交给 agent 循环。代价是如果假设阶段生成的几个候选都不靠谱，用户只能在「继续」和「重新生成」之间选，没有手动改写假设的入口，至少 README 没有提到。

agent_models.yaml：每个 agent 单独选模型

配置层是这个项目比较实用的一块。CONFIG_DIRECTORY 环境变量指向配置目录，默认是 config，README 建议本地开发时用 config_local 以免被 Git 跟踪。目录下的 agent_models.yaml 为每个 agent 指定 provider 和 model_config。README 给的示例里，hypothesis_agent 用 openai 的 gpt-5-nano，note_agent 用 google 的 gemini-2.5-pro，code_agent 用 anthropic 的 claude-haiku-4-5，temperature 都写成 1.0。provider 字段支持的取值在 README 中列为 openai、google、anthropic、ollama、groq。这个粒度的意义在于成本控制：把便宜的模型放在假设生成和笔记记录上，把强模型留给代码生成，是可以直接在 YAML 里表达的。temperature 的取值范围文档写的是 0.0 到 2.0。

跑起来需要的环境变量比想象中多

安装路径是标准的 Python 流程：git clone 仓库，conda create -n datagen python=3.10，pip install -r requirements.txt，然后把 .env Example 改名为 .env 并填值。需要留意的是必填项不止 API key。WORKING_DIRECTORY 是数据存储路径，README 注明它同时被 filesystem MCP server 使用；CONDA_ENV 是 conda 环境名；CHROMEDRIVER_PATH 指向 ChromeDriver 可执行文件，README 示例给的是 ./chromedriver-linux64/chromedriver。也就是说浏览器自动化是默认链路的一部分，仓库里是否自带这个二进制、还是需要自己下载对应平台的版本，README 没有说明。检索相关的是 FIRECRAWL_API_KEY 和 CRW_API_KEY/CRW_API_URL，后者默认指向托管云 https://fastcrw.com/api，自建时可以覆盖为本地地址。TAVILY_API_KEY 供 web-search MCP server 使用，GITHUB_TOKEN 供 github MCP server 使用。LANGCHAIN_TRACING_V2 打开后可以把过程送到 LangChain 做监控。

可选依赖实为硬约束：缺 key 会降级到什么程度

README 把 FIRECRAWL_API_KEY 标为 optional，紧接着补了一句「If this key is missing, query capabilities may be reduced」。这句话没有说明降级后的具体行为，是退回 Tavily，还是 searcher_agent 直接跳过网络检索只做本地推理，从文档看不出来。对依赖文献调研的研究场景来说，这个差别很大：如果 searcher_agent 静默返回空结果，report_agent 仍然会照常写出一份看起来完整的报告，只是引用来源缺失。同样地，CHROMEDRIVER_PATH 被标为 required，意味着没有浏览器环境时整条链路可能起不来，而不是某个功能不可用。这类「可选但影响结果正确性」的配置，是采用前最值得实测的部分。

什么时候它不合适：和纯 LangChain 脚本的差别

如果你的分析流程是固定几步、不需要假设生成和迭代评审，那么直接用 LangChain 写一个顺序链会更省事。DATAGEN 多出来的东西是状态图、评审回路和八个 agent 的协调开销，这些只有在任务本身需要多轮试错时才划算。反过来说，如果你要的是可复现的批处理 ETL，这个项目也不对路：它围绕「一次研究任务」组织，user_input 里写的是 datapath:YourDataName.csv 加一句自然语言指令，输出是图形化报告，而不是稳定的数据产物。另一个现实约束是模型供应商依赖。agent_models.yaml 里每个 agent 都要落到一个 provider，如果团队只采购了一家云的额度，就得把八个 agent 全部改成同一家，或者接受某些环节用本地 ollama 跑。README 没有给出各 provider 在工具调用能力上是否等价的说明，换供应商时这是需要自己验证的地方。

维护成本、许可证与上手前该确认的事

项目采用 MIT 许可证，允许商用和修改，具体义务以仓库中的 LICENSE 文件为准。仓库没有发布任何 release，默认分支是 main，这意味着没有版本号可以锁定，requirements.txt 里的依赖会随上游变动。README 提到配置目录可以切到 config_local 来隔离本地改动，这是应对配置漂移的一个现成手段。另一个维护信号是项目已经改过名，README 标题写着「DATAGEN (Previously AI-Data-Analysis-MultiAgent)」，clone 地址在文档里仍写作 starpig1129/DATAGEN，而仓库当前路径是 zi-yue-1129/DATAGEN，迁移痕迹还在。上手前建议先跑通最小路径：data 目录放一个 CSV，main.py 的 user_input 填 datapath 和一句指令，只配一个 provider 的 key，看假设生成和人工选择那一步是否正常出现，再逐步加上检索和浏览器相关配置。

编辑结论

如果你已经有一套固定的分析范式，只是想把假设、跑代码、画图、写报告这几步串起来，并且愿意自己准备 CSV、ChromeDriver 和至少一个模型供应商的 API key，DATAGEN 值得克隆下来跑一遍 main.py 看看流程是否符合你的习惯。如果你需要开箱即用的交互界面、或者希望不配置任何外部检索服务就能完成文献调研，这个项目目前给不了。上手前先确认三件事：config/agent_models.yaml 里每个 agent 的 provider 是否都有对应的 key，data 目录下的数据文件是否已经按 datapath 的写法填进 user_input，以及 CHROMEDRIVER_PATH 指向的二进制是否真的存在。

官方来源

1. Issues
2. License: MIT
3. README
4. zi-yue-1129/DATAGEN on GitHub