mcpField
C
crucible-investigation-methodology

crucible-investigation-methodology

github.com/terrylicaAgent 工作流151 次安装1 天前更新
代码仓库

关于 crucible-investigation-methodology

crucible-investigation-methodology 是面向 Agent 的数值市场数据假设调查技能，结合因果数据编码、对抗式验证、并行分析、逐笔研究、空检验复测与计算任务编排。

主要功能

  1. 01将市场数据编码为滚动五分位令牌
  2. 02通过串行验证关卡检验发现
  3. 03综合多个专业 Agent 的并行分析
  4. 04扩展逐笔亏损分析
  5. 05使用正交空检验复测发现
  6. 06借助 pueue 编排长时间扫描

适用场景

  1. 01筛查市场数据假设
  2. 02用样本外数据检验信号
  3. 03调查亏损交易的相关条件
  4. 04运行并行计算扫描

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/terrylica/cc-skills --skill crucible-investigation-methodology

安装后在 Claude Code 中输入/crucible-investigation-methodology确认已加载。

附带文件references/evolution-log.md

详细介绍

调查方法论——6 种执行模式

自我演进技能：如果此处的任何模式在实践中失败（结果错误、浪费算力），请更新本节并追加到 references/evolution-log.md。不要拖延。

这 6 种模式用于执行 a-research-foundations。它们是基础原理的“如何”，而基础原理回答的是“为什么”。针对新假设，按大致顺序应用。

1. 面向大模型的数据表示——五分位令牌

在让 Agent “查看”数值市场数据之前，先将数据编码为逐根 K 线的令牌序列，使用因果窗口内的滚动五分位排名。

规范模式：

idx  dir  body_q  range_q  dur_q  uwick_q  lwick_q  loc  sess  fwd+H...

每个五分位数都是因果 200 根 K 线滚动窗口中的 1..5（见 Skill A §1）。Agent 可以识别 +1:5:1|+1:5:1|+1:5:1 这样的模式（三根连续快速大幅上涨的 K 线），而这在浮点数空间中无法直观看出。

上下文预算规则：60 KB 的令牌化统计表可放入 Agent 上下文；67 MB 的原始 K 线数据则不行。

完整参考：findings/methodology/01-llm-native-data-representation.md。

2. 串行对抗性关卡（A/B/C/D/E 协议）

在信任任何样本内正向结果之前，必须依次通过 4—5 个独立关卡。

关卡问题可发现的问题
A — 方向性拆分优势来自做多、做空还是两者？看似扩散、实则具有方向性的优势
B — 镜像对称性反向触发条件是否呈现镜像优势？样本窗口漂移抬高一侧结果
C — 样本外时间拆分（按时间顺序 80/20）该发现能否在后续留出数据上成立？样本内过拟合
D — 跨资产重测该结果能否在其他标的上复现？资产特定过拟合
E — 全历史逐年检验至少 60% 的年份是否为正？单年偶然获利

**关卡 C 不可妥协。**没有经过时间拆分的样本外检验，绝不报告正向结果。

判定结果分类：

  • 全部通过 → validated-cross-asset（升级）
  • A+B+C 通过，D 失败 → validated-asset-specific（缩小范围，不要淘汰）
  • C 失败 → 淘汰并归档，附上 resurrect_if: 条件

完整参考：findings/methodology/05-serial-adversarial-gates.md。

3. 多视角 Agent 综合分析（4—5 个并行专家）

当无法进行暴力穷举时，并行启动 4—5 个采用不同分析视角的专家 Agent。结果趋同 = 验证；结果分歧 = 诊断。

规范视角集合：

  1. 模式动机 / n-gram
  2. 市场状态 / 趋势分类器
  3. 形态 / 影线猎手
  4. 信息论学家 / 意外度
  5. 隐藏信号猎手 / 怀疑派评论者——务必纳入；避免确认偏差

规则：

  • 使用相同的原始数据，采用不同的视角提示词
  • 向每个 Agent 说明：“使用打乱后的零假设进行检验，说明尝试了多少个变体，在未用于筛选的数据上确认胜出结果，并要求零假设检验 z > 2 且逐年保持稳定”
  • 第 5 个 Agent 明确询问：“前 4 个 Agent 意见一致；你赞同还是反对？”
  • ≥3/5 趋同 = 很可能是真实结果；只有 1 个 Agent 发现 = 很可能是视角特定的伪象

分歧也是信息。如果两个 Agent 发现不同信号，应分别独立检验。

完整参考：findings/methodology/04-multi-lens-agent-synthesis.md。

4. 用于亏损复盘的逐笔交易增强

当某个信号有时有效、有时失效时，将汇总层面的问题转化为逐行问题。

流程：

Step 1 — Run signal across full history → collect N trade outcomes
Step 2 — Compute 20-30 causal features at each trigger bar
Step 3 — Emit parquet (per-trade × feature matrix)
Step 4 — Ship to multi-lens agents (§3)
Step 5 — Each agent hunts filters
Step 6 — Evaluate filters via shuffled-null + OOS

必备特征类别（每类至少一项）：

  • 趋势／市场状态（SMA、斜率、自相关）
  • 波动率状态（rv、区间压缩、Kaufman ER）
  • 模式上下文（触发时及滞后期的五分位数）
  • 枯竭／聚集（距上次信号的 K 线数、窗口内信号数量）
  • 位置（以 ATR 标准化的距波段高点距离）
  • 日历（小时、星期、月份、交易时段）

交易时段示例：基准值从 +0.178 bps 提升至筛选后的 +0.514 bps（提升 2.9 倍）。

完整参考：findings/methodology/06-per-trade-enrichment-postmortem.md。

5. 正交零假设级联（正交零假设复测）

当信号通过一种零假设检验后，在采信之前，使用正交零假设再次检验。交易时段示例：

  • 阶段 F-B 打乱了波动率预测列 → +0.370 信号在该零假设下“失效”，z = −5.15
  • 阶段 C 打乱了触发掩码（恰当的零假设）→ +0.439 信号通过检验，z = +5.74

如果只做阶段 C 检验，我们就会采信一个可能错误的零假设。如果只做阶段 F-B 检验，我们就会错过一个真实信号。

规则：每当出现正向结果时，至少找出一个正交零假设并进行复测。常见的正交组合：

  • 特征打乱 AND 掩码打乱
  • 置换 AND 区块自助法
  • 打乱选择 AND 参数法（例如二项分布尾部）

如果信号通过两项检验，可信度会更高。如果通过一项但未通过另一项，则应调查原因——这种差异能揭示信号机制的相关信息。

6. 计算编排（pueue + 包装脚本）

长时间并行扫描需要在 上通过 pueue 执行，并遵循特定规范。

反面模式（会静默失败，出现耗时为 0 秒的“成功”任务）：

ssh <gpu-host> '~/.local/bin/pueue add -- bash -c "VAR=1 python script.py"'

正确模式：

cat > /tmp/run.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
export VAR="${VAR:-default}"
cd /tmp
exec uv run --python 3.14 --with numpy --with pandas python -u /tmp/script.py
EOF
scp /tmp/run.sh <gpu-host>:/tmp/
ssh <gpu-host> 'chmod +x /tmp/run.sh && ~/.local/bin/pueue add --group mygroup --label "job" -w /tmp -- /tmp/run.sh'
ssh <gpu-host> '~/.local/bin/pueue wait <id> --quiet; tail -50 ~/.local/share/pueue/task_logs/<id>.log'

要点：

  • 使用包装脚本（绝不内联 bash -c）——pueue 的 sh -c 包装会剥掉内联引号
  • 使用 python -u 输出未缓冲的标准输出（否则日志会空白 40 分钟）
  • 使用 pueue restart --in-place <id>（不要直接用 restart，否则会创建新的任务 ID）
  • 使用 fork 多进程上下文，通过 COW 共享预计算数组

完整参考：findings/methodology/08-compute-orchestration-pueue.md。

另请参阅：扩展模式见 Skill(devops-tools:pueue-job-orchestration)。

确认次数（暂定）

模式已确认备注
1. quintile-tokens3定性扫描、阶段 B 统计、逐笔交易 CSV
2. serial-gates1 个主要结果（NGRAM3FU 通过 4 道门槛）已验证的模板
3. multi-lens agents3Act-2 定性分析、阶段 C 统计、阶段 L 亏损复盘
4. per-trade-enrichment1阶段 L——需要重新确认
5. orthogonal null cascade1F-B 与 C——原则本身的发现
6. pueue orchestration30+ 个任务置信度很高；标准基础设施

执行后反思

使用此技能后：

  1. 某个模式是否发现了 Bug、节省了时间或产出了经过验证的发现？将上表中的 confirmed 加一；并在 references/evolution-log.md 中注明交易时段／审计文件夹。
  2. 某个模式是否失效（误导了你、浪费了计算资源）？在表格中降级并简要注明；在演进日志中添加相关条目，并链接到失败的交易时段。
  3. 是否出现了新的执行模式？起草一个新章节，并追加到演进日志。
  4. 计算反面模式是否再次让你中招？重新检查 §6 的措辞，明确说明陷阱。

评论

支持 Markdown