11. HistoryPanel 與可選「FactorResearch」輔助層（評估結論）
本文檔回答路線圖中的評估項：是否需要在 HistoryPanel 之上再抽象一層輕量 API（工作名 FactorResearch），專門計算 IC/IR、分位數組合收益、long-short 曲線等？
11.1. 1. 当前能力边界（已满足的部分）
以下能力已由 HistoryPanel 及相關 API 覆蓋，無需重複造輪子：
因子列生產：
assign、__setitem__、returns、kline、apply_ta等；截面變換：
rank、zscore(method='cs'|'ts')；粗組合與基準：
portfolio（等權/加權、groups、benchmark）；研究向收益展示：
cum_return、normalize與mask=；可視化：
plot與(M,L)mask 高亮；與計量工具銜接：
to_df_dict、手工長表化後接 pandas / statsmodels（見教程 2.5 §11）。
對「輕量因子研究 + 粗驗」目標，上述已構成完整底座。
11.2. 2. 若增加 FactorResearch 层，能解决什么？
典型封裝可包括：
給定 因子列 與 收益列（或標籤），輸出 逐期 IC、IC 均值/IR；
分位數組合（按截面分桶）的淨值或收益序列；
多空組合（top minus bottom）的時間序列。
這些均可用現有 rank / portfolio / values + pandas 在用戶側或獨立模塊中幾十行實現；封裝的價值在於 API 穩定、參數約定統一、減少複製粘貼錯誤。
11.3. 3. 结论（短期不引入类库级 FactorResearch）
結論：當前階段不在 qteasy 內核或 HistoryPanel 上強制增加 FactorResearch 類/子模塊。
理由簡述：
職責清晰：
HistoryPanel已定位爲三維研究容器與顯式對齊/重採樣；IC/IR、分位組合等屬於研究工作流約定更強的「分析配方」，放在獨立教程、示例或未來可選包中更合適，避免 HP API 膨脹。避免錯誤預期：單獨命名模塊易讓用戶以爲框架已內置「發表級因子檢驗」（如多重檢驗、樣本劃分、HAC 標準誤），而實際仍需用戶在 statsmodels 等側完成推斷。
與中期「內置因子庫」的關係：頂層路線圖中的 內置因子庫（M2.1） 若落地，更自然的做法是 因子定義 + 註冊 + 與 FactorSorter/回測銜接；批量 IC/分層可作爲因子庫周邊的 可選工具函數，而非 HistoryPanel 實例方法。
維護成本：IC 需約定收益前瞻窗口、停牌、退市、權重（市值加權 vs 等權）等，參數組合多，若無統一數據契約易引發支持成本。
11.4. 4. 若未来引入，建议形态（备忘）
若社區需求明確，推薦 獨立模塊（例如 qteasy.research.factor_stats 或項目外 qteasy-research），而非 HistoryPanel 方法：
入參：
HistoryPanel或DataFrame+ 列名 + 前瞻期數；出參：
DataFrame/Series（可再繪圖爲輔）；文檔：明確 非 替代 Backtester，且 不 內置 Fama–MacBeth / Newey–West（仍導出到 statsmodels）。
屆時應配套 TDD 與英文 ValueError 契約，與現有 HP 測試風格一致。
11.5. 5. 与教程的关系
實操路徑以 教程 2.5：使用 HistoryPanel 操作和分析歷史數據 的 §9–§11 爲準；本設計文檔僅記錄 架構層面的評估結論，不增加用戶必讀的 API 面。