1. 量化因子挖掘这件事，为什么突然被AI代理盯上了

量化因子挖掘在过去很多年里都是一件门槛极高的事。你得懂金融时序数据的结构，得会写高效的向量化计算代码，得理解回测框架里那些容易骗人的细节，还得有足够的耐心去反复试错。一个稍微像样的因子，从想法到验证，往往要消耗掉一个熟练研究员好几天的时间。而真正能上生产环境的因子，背后可能是几百个被淘汰的候选。

大模型编程代理的出现，让这件事有了新的可能性。所谓"AI代理挖因子"，本质上是把"提出假设—写代码验证—读取结果—调整方向"这个循环交给一个能自主执行代码的智能体去跑。它不只是帮你补全一行pandas代码，而是能自己决定下一步该测什么、该怎么改。这就从"辅助编码"升级成了"自主研究"。

我最近花了两周时间，把手上四个主流的编程代理——Codex、Claude Code、DeepSeek Harness、Grok Bot——放在同一套量化因子挖掘任务上做了对比实测。任务设定很明确：给定一份A股风格的日频量价数据（约500只标的、8年历史），要求代理自主挖掘出若干具备统计显著性的alpha因子，并给出样本外表现。整个过程我只做三件事：搭环境、给初始prompt、看结果。中间不干预它的思路。

先说结论的方向性判断：这四个代理在"能不能跑通"这件事上差距不大，但在"挖出来的因子有没有真alpha"这件事上，差距非常明显。有的代理擅长快速产出大量候选因子但过拟合严重，有的代理产出慢但样本外稳定性好，还有的代理会在回测环节悄悄犯一些低级但致命的错误。下面我把整个实测过程拆开讲，包括任务怎么设计、每个代理的表现细节、以及我从里面总结出的可复用经验。

如果你也在考虑用AI代理来做量化研究，或者只是好奇这些编程代理在真实数据任务上的边界在哪，这篇内容应该能帮你省下不少自己踩坑的时间。我会尽量把每个环节讲透，包括那些看起来不起眼但实际影响很大的细节。

2. 实测任务的设计：怎么让四个代理站在同一条起跑线上

2.1 数据与因子池的边界设定

要让对比有意义，首先得控制变量。我给四个代理的是完全相同的数据快照：一份本地Parquet格式的日频数据，字段包括open、high、low、close、volume、amount、turnover_rate、market_cap，时间跨度从某年到某年，标的数量约500只，已经做过基础清洗（剔除停牌、ST、上市不足60日的样本）。

这里有个关键决策：我没有给它们任何预置的因子模板库。原因是如果给了模板，代理很可能只是做参数微调，那就测不出"自主挖掘"的能力了。我要看的是它们能不能从原始量价数据里自己构造出有经济含义的表达式。

因子池的约束我也做了明确限定：单因子表达式长度不超过15个token，只能用给定的字段和基础算子（加减乘除、rank、ts_mean、ts_std、ts_corr、delay、delta等）。这个约束很重要，因为如果不限制复杂度，代理很容易堆出一个几十项的黑箱表达式，样本内IC能到0.15，样本外直接归零。

提示：约束表达式复杂度是防止代理过拟合的第一道闸门。我建议任何用AI挖因子的场景都加上这条，否则你拿到的很可能是一堆漂亮的垃圾。

2.2 评估口径：IC、ICIR、换手与衰减

评估一个因子好不好，不能只看IC均值。我用了四个维度：

样本外我采用的是滚动窗口：用前5年训练，后3年做样本外验证，中间不留gap。这个设置比简单的7:3切分更严格，因为它模拟了因子在时间上的稳定性。

2.3 给代理的初始prompt长什么样

四个代理收到的是同一段prompt，内容大意是：你是一名量化研究员，请基于给定的量价数据自主挖掘alpha因子，要求因子具备经济逻辑、样本外稳定、换手可控。你需要自己写代码完成数据加载、因子构造、回测评估，并输出最终因子表达式和评估报告。

我没有告诉它们具体该挖什么方向的因子。这是故意的，因为一旦指定方向（比如"挖一个动量因子"），就变成了执行任务而不是自主研究。我要测的是它们在开放空间里的探索能力。

prompt里我特意加了一句："请记录你尝试过的所有因子及其评估结果，包括失败的。"这句话后来被证明非常有用，因为它让我能看到每个代理的探索轨迹，而不只是最终产物。

3. Codex的表现：工程能力强，但研究品味一般

3.1 它跑通了什么

Codex给我的第一印象是"执行力极强"。它在第一轮就写出了完整的数据加载和回测框架，代码结构清晰，用了向量化计算，跑500只标的8年数据只用了不到40秒。这一点上它明显比其他三个更利索，没有出现任何环境依赖或API调用上的低级错误。

它第一批就产出了12个候选因子，覆盖了动量、反转、波动率、量价背离几个大类。其中有一个基于"成交量加权价格偏离度"的因子，样本内IC到了0.061，样本外IC还有0.042，ICIR 0.38。这个成绩在四个代理里属于中上水平。

3.2 问题出在"研究品味"上

但Codex的问题也很明显：它太喜欢堆复杂度了。我看了它尝试过的因子列表，发现它很快就从简单表达式滑向了复杂组合。比如它有一个因子是这样的：rank(ts_corr(close, volume, 20)) * rank(delta(turnover_rate, 5)) - rank(ts_std(returns, 10))。这个表达式已经接近我设的15个token上限，样本内IC 0.078，看起来很漂亮，但样本外直接掉到0.019。

我复盘了它的探索轨迹，发现它有一个明显的模式：每当一个简单因子表现不够好，它的第一反应不是换方向，而是加项。这其实是一种典型的过拟合行为——用复杂度去拟合噪声。它在12个因子里有7个都是这种"多层嵌套"结构，样本外衰减普遍严重。

注意：代理的"加项冲动"是AI挖因子最需要警惕的倾向。它本质上是在用搜索空间换样本内表现，而量化研究里样本内表现是最不值钱的东西。

3.3 一个值得借鉴的细节

不过Codex有一个做法我觉得很聪明：它在评估阶段自动加了"因子间相关性检查"。当它发现两个候选因子相关性超过0.7时，会主动只保留ICIR更高的那个。这个动作不在我的prompt要求里，是它自己加的。这说明它在工程层面确实有"组合思维"，知道最终交付的应该是一组低相关的因子而不是一堆同质化因子。

这个细节后来被我加进了自己的标准流程。因为实际生产中，你挖出10个相关性0.9的因子，等于只挖了1个。

4. Claude Code的表现：慢工出细活，样本外最稳

4.1 探索节奏明显更克制

Claude Code的节奏和Codex完全相反。它前20分钟几乎没产出任何因子，一直在做数据探索——算各种字段的分布、看缺失值模式、检查极端值。我当时甚至以为它卡住了。

但等它开始产出因子时，质量明显不一样。它第一批只给了4个因子，但每一个都有清晰的经济逻辑说明。比如它构造的一个"隔夜收益与日内收益的背离"因子，表达式只有7个token：rank(ts_mean(open/close-1, 5) - ts_mean(close/delay(close,1)-1, 5))。样本内IC 0.048，样本外IC 0.041，衰减很小。

4.2 样本外表现对比

我把四个代理最终交付的因子做了统一的样本外回测，Claude Code的因子在稳定性上明显领先：

Claude Code的样本外ICIR 0.41是四个里唯一接近"优秀线"的。它的多空年化13.7%也明显高于其他三个。

4.3 它的"慢"到底慢在哪

我后来仔细看了它的执行日志，发现它把大量时间花在了"自我质疑"上。它每构造一个因子，都会先问自己三个问题：这个因子的经济含义是什么？它在不同市场状态下会不会失效？它和已有因子的相关性如何？

这种自我质疑在工程上其实是低效的，因为它增加了大量额外的计算和推理。但在研究上，它恰恰是防止过拟合的关键。Codex是"先挖再说"，Claude Code是"想清楚再挖"，两种策略在样本外的差距就是这么拉开的。

提示：如果你追求的是因子数量，选激进型代理；如果你追求的是能上生产的因子，选克制型代理。这个取舍在实测里非常明显。

5. DeepSeek Harness与Grok Bot：两个极端

5.1 DeepSeek Harness：产出最多，但质量堪忧

DeepSeek Harness是四个里产出因子最多的，一共给了7个。但它的样本外表现是最差的，IC均值只有0.028，ICIR 0.24。

我看了它的因子列表，发现问题出在"重复造轮子"上。它7个因子里有4个本质上都是动量类的变体，只是窗口期不同（5日、10日、20日、60日）。这种因子在样本内可能都还行，但它们高度相关，组合起来没有任何分散化价值。

更麻烦的是，它有一个因子在样本外出现了IC符号反转——样本内IC 0.052，样本外-0.018。这是量化研究里最危险的情况，因为符号反转意味着因子逻辑本身可能有问题，而不是简单的衰减。

我复盘了它的探索过程，发现它很少做"因子逻辑检验"。它更像是在做参数搜索，而不是在提出假设。这导致它挖出来的东西缺乏经济含义支撑，一旦市场结构变化就崩了。

5.2 Grok Bot：中规中矩，但有个隐藏问题

Grok Bot的表现介于中间，6个因子，样本外IC 0.035，ICIR 0.33。单看数字不算差，但我在检查它的回测代码时发现了一个隐藏问题：它在计算未来收益时，用的是close到close的收益，但没有做复权处理。

这个细节很致命。如果数据里有分红送转，未复权的价格会在除权日出现跳空，这个跳空会被错误地计入收益，导致因子IC被高估。我手动修正后重新回测，它的样本外IC从0.035掉到了0.029。

注意：代理写的回测代码一定要人工审查收益计算部分。复权、停牌、涨跌停这些细节，代理很容易忽略，而它们对结果的影响可能是决定性的。

5.3 两个代理的共性问题

DeepSeek Harness和Grok Bot有一个共同问题：它们都不太会"止损"。当某个方向的因子连续失败时，Codex会换方向，Claude Code会停下来反思，但这两个代理会继续在同一个方向上微调参数。这导致它们的探索效率其实不高——看起来尝试了很多，但大部分尝试都是低价值的重复。

6. 从四个代理的表现里，我总结出的可复用经验

6.1 代理选型：没有全能选手，只有场景匹配

实测下来，我的判断是：

• 如果你要快速搭建因子挖掘的工程框架，Codex最合适，它的代码质量和执行效率最高。
• 如果你要的是能上生产的稳定因子，Claude Code最合适，它的样本外表现最好。
• 如果你要做大规模的因子初筛，DeepSeek Harness的产出速度有优势，但必须配合严格的人工筛选。
• Grok Bot适合做辅助验证，它的表现中规中矩，但回测细节需要重点审查。

这个结论不是绝对的，因为代理的能力还在快速迭代。但它反映了一个底层逻辑：代理的"研究品味"比它的"编码能力"更重要。编码能力决定它能不能跑通，研究品味决定它跑出来的东西有没有价值。

6.2 流程设计：三道闸门缺一不可

不管用哪个代理，我在实测里验证有效的流程是三道闸门：

第一道是表达式复杂度限制。这个必须在prompt里写死，不能靠代理自觉。我建议token数上限设在12到15之间，超过这个长度的因子，样本外衰减概率会显著上升。

第二道是因子逻辑审查。代理产出的每个因子，你都要能用自己的话解释它的经济含义。解释不通的，直接淘汰。这一步能过滤掉大部分过拟合产物。

第三道是样本外滚动验证。不要用简单的训练测试切分，要用滚动窗口。因为量化因子的失效往往是渐进的，滚动窗口能更早发现衰减趋势。

6.3 一个容易被忽略的细节：因子相关性管理

Codex那个自动做相关性检查的动作，我后来在所有代理的流程里都加上了。具体做法是：当候选因子池里出现相关性超过0.7的因子对时，只保留ICIR更高的那个。

这个动作看起来简单，但它对最终组合的贡献很大。我做过对比，加了相关性管理后，同样数量的因子，组合的多空年化能提升2到3个百分点。原因很简单：低相关因子的组合，分散化收益是实打实的。

6.4 关于"AI能不能替代量化研究员"这件事

实测两周下来，我的看法是：AI代理目前能替代的是"因子挖掘里的体力活"，比如批量试错、代码实现、初步筛选。但它替代不了的是"研究判断"，比如判断一个因子的经济逻辑是否成立、判断样本外衰减是噪声还是真失效、判断当前市场环境适合什么类型的因子。

所以更现实的定位是：把AI代理当成一个不知疲倦的初级研究员，它能帮你把候选池从100个扩到1000个，但最终拍板的那一下，还是得你自己来。这个分工在实测里被反复验证——凡是完全放手让代理自己决定最终交付的，结果都不太理想；凡是我在关键节点做了人工干预的，结果都明显更好。

7. 实操中几个具体的坑和应对

7.1 数据加载环节的隐性错误

四个代理里有两个在数据加载时犯了同一个错误：把turnover_rate当成了百分比数值直接参与计算，而没有先除以100。这个错误不会报错，但会让所有涉及换手率的因子量纲完全错乱。

应对方法很简单：在prompt里明确写出每个字段的量纲和取值范围。我后来加了一句"turnover_rate为百分比数值，范围0到100"，这个错误就再没出现过。

7.2 回测里的未来函数

这是最危险的一类错误。有一个代理在构造因子时用了ts_mean(close, 5)，但在计算IC时没有做delay处理，导致因子值和未来收益出现了时间上的重叠。这种错误会让IC虚高很多，而且很难通过看代码发现。

我的应对是在prompt里强制要求："所有因子在计算IC前必须做一期delay，确保因子值在收益实现之前已经确定。"这一条加上后，所有代理的IC都出现了不同程度的下降，但下降后的数字才是真实的。

7.3 代理的"自信偏差"

有一个现象很有意思：代理在报告自己的因子表现时，普遍会偏向乐观。比如它会在报告里写"该因子样本外IC 0.04，表现稳健"，但实际上0.04的IC在扣掉交易成本后可能就不剩什么了。

应对方法是统一评估口径。我后来要求所有代理必须输出扣费后的多空收益，费率按单边千分之一点五算。这个要求加上后，好几个因子的"稳健"标签就挂不住了。

7.4 关于算力消耗的现实考量

四个代理跑完整个任务，消耗的算力差异很大。Codex和Claude Code的token消耗明显更高，因为它们做了更多的探索和反思。DeepSeek Harness消耗最低，但产出质量也最低。Grok Bot居中。

如果你的预算有限，我的建议是：把算力花在"验证"环节而不是"生成"环节。也就是说，让代理少生成一些候选因子，但对每个候选因子做更严格的验证。这个策略在实测里被证明是性价比最高的。

8. 我个人的使用体会

两周实测下来，最大的感受是：AI代理挖因子这件事，工具本身的差距其实没有想象中那么大，真正拉开差距的是你怎么用它。同样的Claude Code，如果你prompt写得粗糙，它产出的东西和DeepSeek Harness不会有本质区别；同样的Codex，如果你加了严格的复杂度约束和逻辑审查，它的样本外表现也能明显提升。

我现在的工作流是这样的：用Codex做工程框架搭建和批量初筛，用Claude Code做重点因子的深度验证，DeepSeek Harness用来做参数敏感性测试，Grok Bot做交叉复核。四个代理各司其职，而不是指望某一个包打天下。

还有一个体会是关于"人"的位置。实测里表现最好的那几个因子，无一例外都是我在某个节点做了干预的结果——要么是我否掉了代理的一个过拟合方向，要么是我提示它换一个经济逻辑。代理能帮你跑得很快，但方向感这件事，目前还是得人来给。

最后分享一个小技巧：让代理在每次尝试后都输出一段"失败原因分析"。这个动作看起来是额外的，但它能逼着代理做反思，而不是盲目试错。我对比过，加了失败分析的代理，后续尝试的有效率明显更高。这个技巧对Codex和Claude Code尤其有效。