RD-Agent：微软用 LLM 循环自动跑完数据科学实验
Research and development (R&D) is crucial for the enhancement of industrial productivity, especially in the AI era, where the core aspects of R&D are mainly focused on data and models. We are committed to automating these high-value generic R&D processes through R&D-Agent, which lets AI drive data-driven AI. 🔗https://aka.ms/RD-Agent-Tech-Report
秒懂
- 它是什么？
- RD-Agent 是一个把数据科学研发流程交给 LLM 自动迭代的框架，目标是让 AI 自己提出假设、写代码、跑实验并改进。本文基于其 README 与公开资料，拆解它的机制、用法与适用边界。
- 适合谁用？
- RD-Agent 适合那些愿意投入时间配置 LLM 后端、并需要处理结构化数据科学或量化交易任务的团队，尤其是已经有 MLE-bench 或 Kaggle 类工作流的组织。它不适合希望开箱即用、没有 GPU 或无法稳定调用商用 LLM API 的团队，也不适合需要处理非表格数据或强实时交互的场景。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是研发流程的重复劳动
RD-Agent 要解决的问题很具体：在数据科学和机器学习研发中，大量时间花在重复的循环里，提出假设，写代码验证，看结果，再改代码。这个循环本身高度结构化，却极度消耗人力。RD-Agent 的定位是把这一整条循环交给 LLM 驱动，让 AI 自己写实验代码、执行、读取反馈并生成下一步改进。它面向的受众是那些需要频繁做数据探索、特征工程、模型调参的团队，尤其是量化交易和 Kaggle 类竞赛场景。根据 README，它已经在 MLE-bench 上取得了领先成绩，但这不意味着它适合所有 ML 任务。它解决的是流程自动化，而不是算法创新。
核心机制：从因子挖掘到强化学习后训练
从仓库结构和新闻条目看，RD-Agent 不是一个单一脚本，而是一套场景化框架。它最早以因子挖掘（factor）场景起家，后来扩展出 data_science 场景，再到 Kaggle Agent，以及面向 LLM 微调和强化学习后训练的 FT-Agent 与 Agent² RL-Bench。这些场景共享一个抽象：LLM 作为研发主体，围绕某个目标反复生成代码、运行、观察指标、再生成。README 中提到的“Reasoning as Gradient”一文暗示其设计哲学，把推理过程当作梯度信号来指导下一次迭代。实际机制上，它依赖 LiteLLM 作为默认后端来对接多种 LLM 提供商，这意味着模型选择是插件化的。它不是一个单体模型，而是一个编排层，外加针对不同研发任务的场景模板。
运行方式：从 PyPI 安装到启动 Web UI
安装入口很标准，通过 PyPI 的 rdagent 包分发，支持 Linux 平台，Python 版本要求未在 README 中明示，但仓库有 mypy 和 Ruff 检查，代码质量门槛不低。启动交互界面用 `rdagent server_ui` 命令，这个命令会构建并服务一个前端，用于实时查看 trace。但注意 README 明确写了该 UI 目前不包括 data_science 场景。配置上，你需要先设置 LLM 提供商，既然 LiteLLM 是默认后端，那么你至少需要配置一个 API key 或本地模型端点。具体配置键在 README 中没有列出，文档站 rdagent.readthedocs.io 应该会有更细的说明。对于快速体验，官方提供了 live demo 链接，可以直接在浏览器里看效果，而不必本地部署。
一个真实的局限：场景支持不均衡
RD-Agent 最明显的短板是不同场景的成熟度差异很大。README 中，data_science 场景虽然被多次提及，但 Web UI 发布时明确排除了它，这说明该场景的交互工具链还未完全跟上。factor 场景（量化因子挖掘）显然是亲儿子，相关论文和技术报告最详细，而 Kaggle Agent 更像是 data_science 的包装。如果你打算用 RD-Agent 处理非表格数据或需要自定义视觉、文本流水线，现有材料没有给出任何证据表明它能胜任。另外，MLE-bench 的成绩是特定模型组合（如 o3 加 GPT-4.1）下的结果，换用弱模型可能大幅退化。它不是一个模型无关的万能代理，而是高度依赖底层 LLM 的推理能力。
替代方案：AIDE 与通用 Agent 框架
README 中直接提到了 AIDE 作为对比对象，在 MLE-bench 表格里 AIDE o1-preview 的成绩低于 RD-Agent。AIDE 走的是更轻量的路线，专注于单轮代码生成与执行反馈，没有 RD-Agent 那么重的场景模板和 trace 系统。另一个替代方向是通用 agent 框架，比如 LangChain 或 AutoGPT，但它们没有针对数据科学研发的内置循环，你需要自己实现“读结果、改代码”的逻辑。RD-Agent 的差异在于它把研发循环固化成框架，而不是留给你拼装。如果你只需要跑一个 Kaggle 竞赛，AIDE 可能更快上手；如果你要长期维护一套自动实验流水线，RD-Agent 的场景抽象更有价值。
维护与升级成本：活跃但依赖外部模型
仓库的 last push 日期是 2026 年 9 月，v0.8.0 发布于 2025 年 11 月，说明项目仍在持续迭代。从版本节奏看，v0.6.1 到 v0.7.0 间隔约两周，v0.7.0 到 v0.8.0 间隔四个月，不算特别频繁，但也没有停滞。许可证是 MIT，商用没有版权障碍，但你需要自己承担 LLM API 费用。升级成本主要来自两点：一是场景模板可能随版本变化，比如 UI 命令的行为调整；二是底层依赖 LiteLLM 更新可能导致配置格式变化。由于项目用 pre-commit、mypy 和 Ruff，代码质量有保障，但这也意味着你如果想二次开发，需要遵守较严格的风格约束。没有看到官方提供长期支持承诺，所以生产环境使用前需要锁定版本。
编辑结论
RD-Agent 适合那些愿意投入时间配置 LLM 后端、并需要处理结构化数据科学或量化交易任务的团队，尤其是已经有 MLE-bench 或 Kaggle 类工作流的组织。它不适合希望开箱即用、没有 GPU 或无法稳定调用商用 LLM API 的团队，也不适合需要处理非表格数据或强实时交互的场景。在采用前，你应当先验证三件事：确认你的 LLM 提供商能通过 LiteLLM 正常接入，检查你计划运行的场景（如 data_science 或 factor）是否在最新版本中仍被官方维护，以及评估每轮迭代的 token 成本是否在你的预算内。RD-Agent 的核心价值在于把“写实验代码”和“根据结果改代码”这两步自动化，但它不会替你判断业务问题是否值得研究，也不会降低对数据质量的要求。
社区笔记