当AI 开始投研：从工具形态到工程落地

工具形态 · 工程落地 · 研究前沿

AI投研 · 智能体 · 研报复现 · 因子挖掘

2026年09月

资料来源与检索说明

本文属于独立整理性质的行业观察，素材来自公开可查的行业研究报告、开源项目文档与产品公开资料，并经作者重新组织与表述。文中所讨论的三条线索依次是：投研场景中 AI 工具形态的更迭、以自动化方式复现公开研究成果的工程做法，以及借助智能体开展因子探索的可行性与限度。三条线索合起来，正是从工具形态到工程落地的路径：形态先行分化，能力再被装进可复现的流程，最后才触及研究前沿的真实边界。

整理口径说明如下：

• 范围：仅覆盖上述三条线索所涉的工具形态、工程架构、开源框架与实证结论。与内部研究计划、既有系统架构相关的延伸判断、适用建议与行动清单，均不属对外内容，本文不作讨论。
• 表述方式：全文采用改写与抽象复述，不对任何来源作逐字引用，亦不保留其原有句子结构；涉及他人独创的分类、命名与判断时，均以概括性语言转述，不作为本文原创主张。
• 数据：文中出现的参数、规模与实证数值，均来自上述公开资料；未作外推，未补入新增数据。凡无法核实者，一律标注或不予写入。
• 第三方信息：文中提到的编辑器、智能体产品与开源框架，均属公开信息，其功能描述以各自官方文档或项目仓库为准。

第一章：工具形态的分野

1.1 能力边界的四次外扩

回看近几年的投研工具，其形态更迭可以做一条粗略的能力标尺来理解：模型能"看见"的范围有多大，以及它能"动手"到什么程度。沿着这条标尺，大致可以划出四个层次。

这条路径的内核并不复杂：可见范围与自主程度同时抬高。当模型能够一次读完整套工程、又能直接驱动终端与外部工具时，它便从"参谋"变成了"执行者"；而当它可以长期在线、被事件唤起并主动汇报时，它接手的角色又变成了"协作中的一员"。

1.2 三类形态各有所长

形态分化以后，挑选工具的问题就不再是"谁更聪明"，而是"这件事需要怎样的节奏与深度"。

若把三类样态摊在一起比对，选择逻辑大致是：写码这类高频、轻量、需要即时反馈的活，交给原生 IDE 或编码智能体都顺手；一旦任务需要多步骤拆解、跨文件改动，工程化程度更高的命令行智能体更合适；而要求长时间挂着、按事件触发、还要把结果送到多个渠道的工作，则更适合常驻型智能体来扛。

说到底，差异不在强弱，而在两个坐标上的错位：交互节奏是实时还是异步，介入深度是单文件还是整工程。

1.3 常驻型智能体的四个要件

第四层形态的内部结构，可以拆成四块来看，每块各管一件事：

• Gateway（调度中枢）：对外只有这一个入口；来自各个渠道的消息、技能调用与工具执行，都在这里统一校验、统一分发。
• Channels（接入渠道）：微信、QQ、钉钉、飞书、Telegram、Discord，加上 Web、API 与终端，都能接进来。
• Skills（流程模板）：每一项技能由一份说明文档加一组配套脚本构成；公开的技能市场上已有数千个现成技能包可供取用。
• Tools（底层能力）：从网页自动操作、文件与数据加工，到命令行执行与定时调度，这些基础动作均由此层供给。

一处安全提醒必须写在这里：凡是来源不明的自定义技能包，都有夹带提示词注入的可能，使用前应当核验其可信度。对重度依赖社区技能生态的体系而言，这项风险与效率红利是一枚硬币的两面。

1.4 形态选择背后的取舍

把上面几类形态放在真实工作流里衡量，取舍通常落在两处：响应速度与单位任务的资源开销。

交互式工具的优势是"随叫随到"——提出问题即刻得到反馈，适合需要反复试探、快速迭代的环节；代价是它必须占用人的注意力，无法在无人值守时推进工作。常驻型工具恰好相反，它的价值在于持续在线、按事件被唤起、并把结果主动送达；而在单次任务的资源效率上，它往往不占优势，长上下文与多渠道维护都会推高成本。

因此，两者并非互相取代，而是对应着不同的任务切分方式：实时、密集、需要人来回判断的工程活，交给交互式智能体；周期性、事件驱动、需要长期守望的活，交给常驻型智能体。 把任务按这个标准分完之后，“该用哪个"往往就不需要再争论了。

第二章：工程落地的起点——研报复现系统的架构

2.1 要解决的问题

公开研究材料数量持续增长，而研究精力却被大量重复性劳动吃掉。若能把公开成果的复现过程"自动化掉一部分”，研究者就能更快补齐短板、充实因子储备。这个朴素的目标，直接决定了系统的设计取向——不是让 AI 自由发挥，而是让它在受约束的流程里稳定输出。

2.2 三个 Skill 与一条配置总线

系统由三项职责分明的技能串接而成，彼此共享同一份配置文件：

report-parser  →  factor-reproducer  →  factor-library-manager
   解读研报            重建因子              入库与维护
        ↕                  ↕                      ↕
             config.yaml（统一配置总线，充当通用接口契约）

• report-parser：负责把待处理的研报转成结构化文档。
• factor-reproducer：依照解析结果把因子复现出来，形成可回测的实现。
• factor-library-manager：负责因子的元数据、绩效指标与版本沿革。

三者之间不靠隐含约定传参，而是统一读写 config.yaml。这条"单一配置总线"把接口契约从代码里抽了出来，避免了流程内部因参数散落而产生的口径漂移。

2.3 目录分层与配置维度

工程落地上采用的是分层目录，从输入到注册依次推进：

对应的 config.yaml 覆盖七个维度：project（项目）、database（数据库）、data（数据）、factors（因子）、backtest（回测）、benchmark + tolerance（基准与偏差容忍度）、output（输出）。其中"基准 + 容忍度"被单独列为一个维度——后文会看到，这正是质量控制闭环的挂载点。

第三章：工程落地的经验——六条可复用的做法

从这套系统的实践中，可以抽出六条适用范围很广的做法。它们的价值不在"用 AI 做投研"这句口号，而在于把不确定性一步一步收敛成流程约束。

3.1 用规则化模板约束产出，而不是放任模型自行发挥

若不加约束，直接把原始研究报告丢给 AI 去解析与复现，结果的可预期性很差；反之，先以 SKILL 把流程规则化，产出的准确率会有明显提升。这条经验的本质，是把"提示词的运气"换成"流程的确定性"——约束越是结构化，结果越稳定。

3.2 解析类任务要让模型"读"，而不是让它"写"

一条略反直觉、却极有价值的经验：处理研报解析这类任务时，让大模型动手写解析代码并不是好选择；更稳妥的做法是让它只发挥语义理解能力，直接输出信息摘要——这样得到的产物更稳定，也更少出错。换句话说，在"信息提取"上，模型的语义能力比它的代码能力更可靠；一旦中间插入一层代码，误差来源反而变多。

3.3 字段逐项比对并显式标注状态

在复现流程中引入字段比对环节，并对每一个字段打上 [OK] 或 [WARN] 标记。看起来繁琐，实为必要防线：字段一旦认错，整个复现会从头错到尾，而这类错误往往要到最终回测结果上才暴露，回头排查的成本极高。

3.4 用偏差容忍度驱动自动反思

配置里设好 benchmark + tolerance：一旦复现偏差越过设定阈值，系统就唤起模型自行复盘并修正。如此，“复现质量"便从主观感受变成可量化、可触发的闭环——质量不再只有"通过 / 否决"两种状态，中间存在一个可调的容忍区间。

3.5 把踩过的坑写进记忆，并自动带入上下文

将踩坑经验沉淀进 Memory，后续任务启动时会自动把它带进上下文，同样的错误便不会第二次发生。这是把个人经验转化为系统资产的典型做法——错误只犯一次，且不再依赖人的记性。

3.6 把高频函数收敛为公共模板

数据库访问、回测执行、图表绘制与绩效计算等高频函数，统一收纳进 code_template 供各项目调用。收益有两层：一是省去重复开发，二是避免项目之间的实现漂移——同一个指标若存在多份实现，口径分歧几乎必然出现。

这六条经验可以合并成一句话：在研报复现这条链路上，AI 的贡献主要是把流程做规范、把质量做成可核验的对象；研究判断本身，它不负责。

第四章：工程落地的延伸——AI 因子挖掘的三个开源框架

4.1 三个框架，三种取向

在"能否让 AI 直接挖因子"这一前沿问题上，目前已有若干开源尝试，它们的设计取向差异明显。

其中 RD-Agent 的五步闭环，是理解"AI 挖因子"的标准范式：

提出假设 → 搭建实验 → 生成并迭代代码（CoSTEER）
   → 计算因子并回测（Qlib） → 分析结果并反馈 → 回到起点、提出新假设

4.2 值得关注的四项设计

（1）依次接力，而非并行开会。 AlphaAgent 让三个 Agent 一个接一个往下走，而不是同时并进。这样能省下大量消息往返与上下文对齐的开销；代价是它们之间缺少互相审阅、彼此质疑的机会。这也解释了为何并行多智能体在"纠错"上更强，但更贵。

（2）因子交由 DSL 表达。 因子并不以自由代码书写，而是由预置的行情变量与若干时序、截面算子拼装成 DSL 表达式。如此，语法层面的合法性被提前锁死，模型只可能在语义理解上出偏差。这在工程上是极有效的护栏。

（3）入库设刚性门槛。 因子想进候选池，须先跨过几道关：|ICIR| 要大于 0.1，截面自相关要大于 0.6，并需通过十分组单调性检验；系统另设自动截面去重，一旦发现冲突，就把相似度最高的三个因子退回供改写。这一机制把"数量扩张"和"质量把关"分成了两件事。

（4）假设生成内置行为准则。 其中包括：新设计须先对上一轮结果做出归因；候选因子要横跨不同信息维度；若连续两轮都无改善，就必须更换算子族；同时要避免产出一批只改了窗口长度、实质雷同的因子。这些准则直指"AI 生成因子的隐性同质化”。

第五章：工程落地的边界——实证结论与能力定位

5.1 一组实证数据

围绕 RD-Agent 这条路线，公开资料中披露过一组相对完整的实证结果，而数据本身就带着明确的克制信号。

这组数据里最值得记住的，是因子层与组合层的背离：因子层面的指标多数优于基准，组合层面却并不稳定，且只有少数轮次刷新最优。这说明"找到好因子"与"拼出好组合"之间横着一道实质性的鸿沟——组合表现还取决于因子之间的相关性结构、权重配置与风险约束，而这些并不能由因子迭代自动解决。

5.2 能力边界与定位

把实证结果与前面的工程经验放在一起看，可以得出一条相当清晰的定位：AI 智能体擅长拓宽研究广度、提升研究效率；至于某个候选因子能否进入因子库，最终仍须由研究员拍板。

需要人工把关的环节，具体包括：样本外表现检验、边际贡献评估、跨 session 的重复剔除、经济逻辑审查，以及风险暴露控制。

三章内容合起来，指向同一个判断：AI 的用处集中在把流程做规范、把标准定下来、让结果可核验；至于下判断这件事，它并非替代者。 工具层的形态分化，解决的是"能力放在哪里"；工程层的流程约束，解决的是"结果是否稳定"；而前沿层的实证边界，提醒的是"哪些活还得人来干"。三者之中，没有一处支持"让 AI 自行产出可用策略"这种想法。

对量化研究而言，这一结论的现实意义可以概括为：把 AI 用在流程与效率上，收益是确定的；把 AI 用在判断上，则必须保留人类复核环节。

来源说明：本文由公开渠道的行业研究报告与公开产品资料整理而成，全文经重新组织与改写，不构成对任何来源的引用或转载。

免责声明：本文为独立研究整理，仅供交流参考，不构成投资建议，亦不构成任何形式的荐股；文中涉及的外部产品、开源项目与研究信息，均来自公开渠道，相关权利归各自权利人所有。