test: 增加 Deep Research 取数基准与可核验性能证据

.github/workflows/pr.yml

@@ -38,7 +38,9 @@ jobs:
       - name: Install dependencies
         run: bun install --frozen-lockfile
       - name: Typecheck
-        run: bun run typecheck
+        run: |
+          bun run typecheck
+          bun node_modules/typescript/bin/tsc --project scripts/bench/tsconfig.json
 
   focused-tests:
     name: Focused tests
@@ -70,6 +72,7 @@ jobs:
             awk -F/ '
               /^packages\/[^/]+\// { print $1 "/" $2 }
               /^apps\/electron\// { print "apps/electron" }
+              /^scripts\/bench\// { print "scripts/bench" }
             ' /tmp/changed-files.txt | sort -u
           )
 

docs/benchmarks/2026-10-19-Trail-性能数据面试说明.md

@@ -0,0 +1,93 @@
+# Trail 性能数据：面试说明与追问
+
+## 30 秒版本
+
+> 这组数据来自我为 Trail 补建的真实接口基准。研究 Runner 按策略选择数据能力，最多同时执行 4 项。我用同一套代码加串行执行闸门作为对照，固定 AAPL 价值分析、NVDA 风险复核、MSFT 成长分析三个任务，每个任务测 10 对，交替执行顺序。只计从开始取数到进入综合阶段的时间。30 对样本的两组中位数是 4.54 秒和 1.34 秒，降低约 70%。全部 220 次正式能力调用成功，成对的数据哈希一致。我保存了脚本、日志、环境与原始快照。这不包含模型综合时间，也不是一个历史串行版本到新版本的发布效果。
+
+这里的“我”应对应你实际审阅、理解并能维护的工作；本次脚本和实验由 Codex 在授权下执行，不能因有证据包就声称独立手写全部项目。
+
+## 1. 这组数字是不是模拟出来的？
+
+不是人工 `sleep` 模拟接口延迟。调用项目已有 Longbridge 真实适配器和本机 CLI，返回公开金融数据。只有计时后的报告综合使用本地规则，不请求付费模型。`payloads/` 保存实际取回的数据，`trials.jsonl` 保存逐次轨迹。
+
+2 秒的样本间隔用于控制请求节奏，发生在测量结束之后，不加入两组耗时。
+
+## 2. 你改了什么才变快？
+
+本次没有修改生产取数代码，验证的是已有并发调度相对串行执行的收益。最早相关 Runner 提交已经是 4 路并发，所以不能编造“我发现历史串行瓶颈并改掉”的经历。本次新增工作是性能基准与可审计证据。如果面试官问原模块由谁设计，应按本人真实开发过程回答。
+
+## 3. 串行对照是不是故意加延迟？
+
+没有人为给接口增加耗时。串行 Executor 使用 FIFO 互斥闸门，每次只有一个真实能力调用进入相同的 `super.run`；前一个完成就立即放行下一个，模拟依次等待请求结果的执行方式。并发组使用同一 Runner 原有 worker 池。排队时间计入取数总耗时，不是从单项耗时里手动求和捏造总时间。
+
+## 4. 为什么能并行？
+
+这三个策略中各个能力使用相同的证券标识，取财报、估值、新闻或 K 线时不依赖另一工具的返回值，所以可以并发。报告综合需要这些输入，因此在 worker 全部结束后才进行。若后续工具依赖前一步结果，就不能直接放进同一批无依赖并行任务。
+
+源码：`packages/shared/src/research/runner.ts` 的 `CONCURRENCY`、worker 循环和 `Promise.allSettled(workers)`。最多 4 路，有 3 项任务时实际只能同时执行 3 项。
+
+## 5. 为什么不是严格快 4 倍？
+
+串行时间近似各任务耗时之和；一批互相独立的并行任务接近最慢任务加调度成本。请求时间不一样，网络、CLI 进程启动、服务端调度及资源争用都会影响结果；成长策略只有 3 项，也没有 4 倍上限空间。4 是并发数上限，不是性能承诺。
+
+## 6. 测了多少次？成功率是什么？
+
+3 个固定任务，每个任务 10 对，每对两次运行，共 60 次正式运行。另有每任务一对预热，共 6 次，不入统计。正式调用数是 `4×20 + 4×20 + 3×20 = 220`，全部成功。
+
+可以说“本次 60 次正式运行均完成”，不能用这个小样本声称系统长期 100% 成功。最初综合策略预检有 2 项失败，已保留，不能省略后扩大到所有策略。
+
+## 7. 为什么用中位数？70.4% 怎么算？
+
+网络耗时会波动，中位数用于描述本次固定工作负载下的典型耗时，原始最小/最大值和均值也都提供。
+
+两组各 30 次的中位数为 4540.24945 ms 和 1344.13440 ms：
+
+`1 − 1344.13440 / 4540.24945 = 70.395142%`。
+
+70.4% 是“两组中位数之比”的降幅，不是每对降幅的平均值。逐对降幅中位数为 68.2%，统计量不同，并不矛盾。
+
+## 8. 三个任务长度不同，合并会不会误导？
+
+所以报告同时列出逐任务结果。每任务各占 10 对，没有让某个任务数量更多。价值分析降低 70.9%，风险复核 69.4%，成长分析 64.0%。合并 70.4% 只适用于这个等量任务集合；不能说每个任务都降低了 70.4%。
+
+## 9. 怎么知道不是少取数据才变快？
+
+两组使用同一策略和输入，检查计划能力都执行成功、传给综合器的数据包包含全部能力，并检查实际内容。独立审计要求财报三类报表均有数值，新闻非空且有标题/时间，EPS 有数值，K 线有数值价格。
+
+30 对的完整规范化数据哈希全部一致，说明这次短会话里，两组交付给后续流程的数据内容一致。哈希相等证明内容相同，不证明供应商数据绝对正确或最新。
+
+## 10. 是不是缓存导致并发更快？
+
+本次不启用应用级缓存和自动重试，并平衡先串行/先并发的顺序，避免每次总由后一组享受预热。每次新建 Router，但仍不能控制 CLI 或供应商服务端缓存。全部快照在本次会话中保持不变，也符合财务等低频数据的特征。
+
+因此只能报告本次真实调用条件下的结果；要回答完全冷缓存或跨日期稳定效果，需要另外设计实验，本轮没有这项证据。
+
+## 11. 模型生成报告也快了 70% 吗？
+
+没有测这个。计时止于 `synthesizing` 状态，模型综合的耗时不在分母。当前使用本地规则综合器，不能证明真实模型耗时、质量或 token 成本改善。模型如果很慢，取数阶段的改进对完整用户等待时间的占比可能较小。
+
+## 12. Planner 是 LLM 自主规划吗？
+
+本次验证的路径是 `strategyId → 预设能力列表 → 输入构建 → 有界 worker 池`。它是策略驱动的确定性编排，不能把这次结果说成验证了任意问题的模型自主拆解与动态工具选择。公司对比也不在这三个单标的任务中。
+
+## 13. 引用可追溯是什么意思？是不是答案一定正确？
+
+Runner 给报告分节附 `capabilityId`、`runId`、`fetchedAt` 和可用的 `instrumentId`。本次检查引用对应到实际成功的能力运行，另存 3 份完整实时报告，11 条引用都可沿运行 ID 找到数据。
+
+它证明来源记录的关联，不证明所有自然语言因果结论正确，也不证明模型的 confidence 已校准。不能把引用映射通过写成“模型准确率 100%”。
+
+## 14. 失败、超时和取消怎么办？
+
+现有 Executor 将失败、不可用和取消折叠为运行记录，Runner 等待 workers 后给出 completed/partial/failed 等状态。单能力超时上限 20 秒，最大 worker 数 4。正式实验保留所有尝试，只有两组都完成且校验通过的完整对才纳入性能统计，同时报告失败分母。
+
+本次相关源码测试验证了超时、取消及部分失败路径；联网性能样本没有触发这些异常，所以不能把单元测试通过描述为线上故障恢复已被长时间验证。预检失败未修复。
+
+## 15. 面试官现场要求复现时怎么做？
+
+展示 `manifest.json` 的基线 SHA、环境和协议，打开 `pairs.csv` 看逐次样本，运行离线审计重新计算结果；需要联网复测时按 `scripts/bench/README.md` 使用新目录，不覆盖原证据。
+
+新运行可能因接口、授权或网络改变而不同。保留新结果并解释范围，不为了得到 70.4% 修改校验或删除慢样本。
+
+## 自检
+
+不看答案，自己画出“策略 → worker → Executor → Router → CLI → 综合 → 引用”的路径，并解释为什么计时止于综合前。如果还解释不清 FIFO 闸门、数据哈希、中位数与两组对照的区别，应先练会再把数字放进简历。