一个研究生用一年写了一千个函数——StatsPAI 是 Agent 时代的计量学统一场论吗？

上周读到斯坦福一个研究生在不到一年里写了三十万行 Python 代码——309,709 行，658 个源文件，1020+ 个注册函数，81 个子模块。一个人。一个 import statspai as sp。

我第一反应不是佩服。我怕。

怕什么？怕这是又一个"把所有东西塞进一个包"的野心项目，几个月后就被遗忘在 PyPI 的角落里。但读完它的 paper、翻完源码、对了 R/Stata 的验证数据之后——我改主意了。

这件事值得认真谈谈。

1. 一个"胶水工"的日常

想象你是一个做实证研究的人。

你有一份面板数据，想看看某项政策对就业的影响。你要跑 Callaway-Sant'Anna 的 staggered DiD。Python 这边——用 csdid 可以，但 Sun-Abraham 没有。换 differences？有 Sun-Abraham，但 Mammen 联合置信带没有。Rambachan-Roth 敏感性分析？对不起，Python 生态里基本没有——你得把结果倒回 R，跑 HonestDiD。

等你好不容易凑齐了 DID，老板说：再跑个合成控制法对比一下。

这时候你打开另一个包。API 不一样。结果对象不一样。输出格式不一样。你开始当胶水工——手工对齐 index、处理重复 bootstrap、拼 LaTeX 表格。

这不是做研究。这是在当人肉适配器。

StatsPAI 的野心就是消灭这个适配器。

2. 一千个函数的统一 API

StatsPAI 的核心赌注很简单：把所有计量方法塞进一套 API 里。

import statspai as sp

# 你跑 IV 回归
iv = sp.ivreg('lwage ~ (educ ~ nearc4) + exper + expersq', data=df)

# 换 staggered DiD
cs = sp.callaway_santanna(df, y='lemp', t='year', i='countyreal', g='first_treat')

# 输出——同一套方法
iv.summary()       # 文本摘要
iv.to_latex()      # LaTeX 表格
iv.to_docx()       # Word 文档
iv.cite()          # 方法的 BibTeX 引用

# 切回 DiD 也全一样
cs.summary()
cs.to_latex()

纸面上很美。我问的第一个问题是：这真能跑出和 R/Stata 一样的结果吗？

答案比我想象的好。

StatsPAI 内置了 64 个 R 对齐模块、61 个 Stata 对比模块。闭式估计量，三者匹配到机器精度——DML PLR 系数差异仅 1.1 × 10⁻¹⁶。迭代算法，差异在预声明容差内。他们还跑了 1000 次 Monte Carlo 覆盖：名义 95%，OLS 实际 95.2%，DiD 95.5%，强 IV 96.2%。

这事说起来平淡，做起来极苦。每一行对比代码背后，可能都有一两天调试 R 包版本兼容性、处理数值舍入差异、校准 bootstrap 种子的脏活。

但我必须说另一件事。

3. 十次"正确性修复"说明了什么

翻 PyPI 的版本历史时我注意到一个模式。

v1.12.0：sp.dml 的 KFold 应改为 StratifiedKFold。 v1.13.1：sp.callaway_santanna(method='reg') 影响函数缩放错误。 v1.16.0：sp.qreg 的 Powell sandwich SE 偏差了 √n 倍。sp.xtabond Arellano-Bond GMM 需要完全重建。 v1.18.0：sp.feols 在没有固定效应时会静默忽略 weights= 参数。

十个版本。十处标着"⚠️ correctness"的修复。不是小修小补——qreg 的标准误偏了 √n 倍，这意味着如果你用受影响的版本跑回归、写论文、算置信区间，你论文里的所有显著性判断可能都是错的。

这不是对 StatsPAI 的否定。

坦白说，任何一个从零构建的复杂统计包，正确性 bug 都是不可避免的。Stata 也有 patch，R 的 CRAN 包也经常修。不同的是——Stata 有 40 年的积累和数十万用户替你发现 bug，StatsPAI 只有 212 个 GitHub stars 和 1 个外部 issue。

一个人写的验证测试，覆盖不了十万个人踩过的坑。

我对这个问题的判断是：StatsPAI 的验证分层标签（Certified / Validated / Stable / Experimental）是更有价值的透明度创新，但尚不能替代传统统计软件的社区验证。"Certified"标签的正确性取决于有多大的人群在用——用的人多了，藏在角落的 bug 才会被挖出来。

4. "Agent-Native"到底是什么意思

StatsPAI 自称"第一个 Agent-Native 的统计包"。这也是最让我纠结的部分。

它做了三件事：

(1) tool_manifest()——把一千多个函数签名序列化成 OpenAI/Anthropic 的 tool-use JSON Schema。这样 Claude 或 GPT 可以直接把 StatsPAI 函数当作工具调用。

(2) MCP Server——实现 Model Context Protocol 规范，让任何 MCP 兼容的 AI 客户端可以直接调用 StatsPAI 估计量。

(3) remediate()——当 Agent 调用失败时，返回结构化的修复建议。

技术上这三件都成立。问题是：这叫"Agent-Native"还是"Agent-Ready"？

我的看法是后者。

tool_manifest() 本质上是对 Python 函数签名的 JSON Schema 批量导出。LangChain 的 @tool 装饰器做同样的事。MCP Server 是对 MCP 规范的合规实现。remediate() 是一个"错误类型 → 修复提示"的映射表——实用，但不打动人。

真正的 Agent-Native 设计需要的是什么？我列几个：

• Agent 能理解"这个方法要求面板数据且有处理前时期"——不仅是类型约束，还有领域假设约束
• 当 Agent 发现数据不满足平行趋势假设时，能自动推荐替代方法（合成控制？BJS？敏感性边界？）——不是靠 LLM 猜，而是从方法学的拓扑结构中推理
• 校验链——"先跑平衡性检验，通过后再估计 ATT"——被编码为可执行的 DAG，而不是留给 Agent 自己琢磨

这不丢人。一个人一年能做出第一步已经是壮举。但把第一步包装成"Agent-Native"，就像把一辆装了 GPS 的马车称为"自动驾驶汽车"。

更公平的评判：StatsPAI 是 Agent-Ready——为 Agent 调用做了最完善的准备。但和真正的 AI 原生架构之间，还有一段不小的距离。这段距离不是技术深度的问题，是设计起点的差异——你是"把现有 API 适配给 Agent"，还是"为了 Agent 而重新设计 API 的形态"？StatsPAI 做的是前者，做得很好。后者是另一个故事。

5. 它在 Python 生态里到底该站哪

Python 因果推断的生态有一个奇怪的结构。

DoWhy 有 7200+ stars，做了图形因果模型和反事实估计。EconML 有 3800+ stars，在 Microsoft 的 PyWhy 组织下，专攻异质处理效应的 ML 估计——meta-learners、因果森林、policy learning。CausalML 有 5000+ stars，来自 Uber，专注 uplift 建模和 treatment 优化。linearmodels 有 2500+ stars，管面板回归、IV、GMM。DoubleML 是学术团队维护，专门实现 Chernozhukov 的 DML 框架。

每个包精一个方向。但没有任何一个覆盖"从 desciptive statistics 到 publication table"的完整工作流。

StatsPAI 想填的就是这个洞。

它的真实定位不是替代这些包——paper.md 自己也说"不是要替代每个专门实现"。它是 "全栈胶水层"：不跟你比每个方法的深度，但你要在一个项目里比较五种方法、出三种表格格式、附带完整的引用和诊断——只有它能做。

"广度换深度"的策略，代价是明确的。任何单一设计，专门包都提供更多边缘选项和更细调优。用 linearmodels 跑 IV，你能控制比 StatsPAI 更多的细节。做 DML，DoubleML 的文档和社区讨论远比 StatsPAI 的几个段落丰富。

所以 StatsPAI 的价值高度依赖你的工作流：如果你在比较多种方法 → 值得用。如果你在深耕一种方法 → 不值得引入额外依赖层。

6. 那它到底行不行

我把这个问题拆成三个场景来答。

教学场景——行。 学生不用装四五个包、学四五套 API。一个 sp. 前缀走天下。Card 1995 的教育回报 IV、Lee 2008 的选举 RD、Callaway-Sant'Anna 的最低工资 DID——都打包在 sp.datasets 里，开箱即用。

探索性分析——谨慎行。 快速试多种方法是 StatsPAI 的强项。但要养成两个习惯：锁定版本（pip install statspai==1.18.0），关键结果用 R 或 Stata 交叉验证一次。这不需要跑全量对比——对照一个系数和标准误即可。五分钟的事，但能救命。

发表级研究——风险高。 十次正确性修复的历史意味着：你今天锁定的版本，明天可能被发现一个新 bug。如果你的论文已经被接受、在 revisions 阶段——换版本可能改变你的结果。这是真实风险。

我不敢说"别用 StatsPAI 发论文"。但我敢说：用 StatsPAI 发论文，必须自己验证所用方法在同版本 R 或 Stata 上的数值一致性。不验证就提交，是在赌——赌一个单作者项目的验证覆盖恰好覆盖了你用的那个分支。我自己做研究会验证。你不一定要信我，但建议信一下这个逻辑。

7. 最后——它是不是"scikit-learn 时刻"

2010 年 scikit-learn 出现的时候，Python ML 生态是一盘散沙。每个算法的接口都不一样。scikit-learn 做了一件看起来简单的事：fit() + predict() + transform()，统一所有 ML 算法。

它当然不是每个算法的最优实现。但 API 的一致性创造了网络效应——所有后续的 ML 库都自觉兼容或模仿它。

StatsPAI 想做同样的事，但它在 2026 年面临的赛道比 2010 年艰难得多。

2010 年的 scikit-learn 有一整个学术社区在背后——INRIA、巴黎南大学、法国的 ML 社区。StatsPAI 目前是一个斯坦福研究生为主力。scikit-learn 的对手是散装 MATLAB 脚本和自研代码。StatsPAI 的对手是 Stata、R 的整个 CRAN 生态、以及己方 Python 生态里的 DoWhy、EconML。

这不是一个人能打赢的仗。

但 StatsPAI 证明了统一计量 API 是可行的。这件事本身就有价值——即使它最终不是那个"大一统终端"，未来也会有人沿着它走通的路线，用社区的力量重建一个更经得起验证的版本。或者——StatsPAI 自己如果能转型为社区项目，吸引 2-3 个核心贡献者和一群外部验证者，它就有机会成为那个标准。

我赌五毛：两年后再看，StatsPAI 对因果推断生态的最大贡献，不是它的 1020 个函数，而是它定义了"一个计量 API 长什么样"。就像 scikit-learn 的 fit/predict 已经被内化到 ML 从业者的肌肉记忆里，StatsPAI 的 sp.regress() / sp.did() / sp.dml() 的统一签名可能成为后来者的参照系——即使后来者不叫 StatsPAI。

---

最后说一句。

翻 StatsPAI 的 repo 时最打动我的，不是那 30 万行代码。是 CHANGELOG 里一行行"⚠️ correctness fix"。一个研究生，发现自己写错了，公开标注、立即修复、写入版本日志。这种事在学术软件里远比我们想象的少。大部分学界出的代码，"跑通就行，修不修看缘分"。

StatsPAI 在诚实这件事上，至少比很多学术软件做得更好。

---

#StatsPAI #CausalInference #AgentNative #Python #Econometrics #FeynmanLearning #智柴系统实验室🎙️