风控拦截、重试与人工审批

假设账户有 20 万元，单笔上限是账户的 50%，也就是 10 万元。某标的一手约 14 万元，即使研究信号看多，最小可交易单位也已经超过上限。正确结果是拒绝，不是不断输出同样的一手。

这个例子说明，缩量只能处理“数量可以调整”的问题，不能修复最小交易单位已经超过限额的问题。也不能为了让示例成功，临时提高风控上限。

订单金额的计算是：

订单金额 = 价格 × 数量

假设价格为 1,400 元、数量为 100 股：订单金额 = 1,400 × 100 = 140,000 元，超过 100,000 元上限，因此应直接结束。

可以把流程拆成：Chris 返回风险结论和建议上限；retry 节点更新 retry_count、订单上限和原因；再回到 Joe 重新计算。路由函数只读取状态并选择下一节点，不在判断时偷偷改状态。

“最多两次”必须先说清楚：是总共尝试两次，还是首次失败后额外重试两次。日志同时记录 attempt_no 和 retry_count，至少测试首次失败、最后一次允许重试和下一次超限。

如果输入和输出完全一样，重试没有新信息。网络暂时失败、数据刷新或明确的数量调整可能适合有限重试；最小可交易量超限、证券禁止买入等原因通常应直接结束。

halt 表示系统进入暂停状态，不能靠重新生成信号解除。恢复要有独立条件、操作记录和授权。reject 是否可重试，则要按错误类别判断。

如果 warning 给出较小金额，Joe 必须在上限内向下取整。若向下取整后低于最小交易单位，就不能强行向上取整。调整后仍要再次经过风控。

连续拒绝时，系统要输出最终原因和完整尝试历史，不能悄悄结束，让使用者误以为订单成交。

关闭自动审批后，流程在 Human 节点调用 interrupt，展示研究依据、量化信号、风控判断和订单信息。人输入 yes 或 no，再用同一个任务标识 resume。yes 才能到 Trader，no 进入 END。

interrupt 是暂停，resume 是恢复，checkpointer 是保存状态。三者不是一回事。跨进程重启要使用真正的持久化保存器，不能把内存里的演示当成重启保证。恢复时必须绑定正确的 thread_id，避免把甲订单的批准用于乙订单。

审批可以来自 HTTP、飞书或其他获授权渠道，但都要验证操作者身份、权限、订单版本和有效期。审批入口变化，不能降低审计要求。

大篇幅研究报告不必全部塞进 State。可以把报告保存成独立 artifact，在 State 中留下受控路径或标识、摘要、版本和校验信息。这样便于持久化、回读和审计。

报告更新后，旧审批不能自动覆盖新报告和新订单。审批卡片至少汇总研究依据、量化信号和风控判断，让人核对未知条件和授权范围，而不是看到结果不顺眼就临时破坏规则。

某个框架循环限制约 54，只是框架层的防护配置，不能替代订单层的明确重试上限。业务上限仍要由 attempt_no、retry_count 和错误类别共同控制。

加入 52 个因子、把树模型数量缩到约 100 并加入正则化后，模型仍可能不如简单 RSI。原因可能是特征重复、缺失、高噪声、标签设计、样本量不足和市场变化。复杂度增加，不会自动创造有效信息。

股票池从 16 只扩大到数千只时，行业权重、样本分布和共同波动结构都会变。SVD 保留前 4 个成分解释约 80%，只能说明压缩了大部分方差，不能证明剩余 20% 全是噪声，也不能证明预测更好。要比较预处理、载荷、解释方差和样本外表现。

XGBoost 和 LightGBM 的重要性排名可能因树结构、分裂规则、随机性和口径不同而变化。split 次数和 gain 不能直接混用。更稳妥的补充是时间外置换检验、去掉特征后的性能变化和跨时间稳定性。