Jyotisha/docs/tasks/PROGRESS-consult-latency-quickwins-20261005.md

# PROGRESS：普通对话耗时两项快修 — 2026-10-05

基线：任务书写成时已部署的是 `1252de3e`。开工时 `origin/staging` 为 `853772bc`（相对已部署提交只有文档）。执行中又快进到 `4c64733f`（再加一份纳迪研究任务书，产品代码与 `853772bc` 相同）。分支 `codex/consult-latency-quickwins-20261005`，工作树 `.worktrees/consult-latency-quickwins-20261005`。测试基线工作树停在 `853772bc`，没有改它。

未推送，未部署。用量页没有登录打开。修复版本：待发布。

## 做了什么

1. 咨询路径上，校正闸不再为官方快照干等。请求里已有「外部证据可以后做」这个标记时：先复用当天已经验证的官方快照；没有就查当天的失败记录；都没有就记 `deferred_in_consultation`，不起 4 秒子进程，也不标成已验证。直接做生时校正、请求里没有这个标记时，仍走原来的官方快照。顶层那一次前台核对仍做（BUG-301 不推翻）。BUG-1231。
2. 普通对话补上分段计时。分类耗时、第 0 步、第 1 步的耗时和供应商 token，以及第 1 步开始到第一个正文字的时间，写入运行日志和用量账本里已有的 JSON 字段。用量页多一列「分段」。不改表。BUG-1232。
3. 记录：BUG-1231、BUG-1232、CHANGELOG、本文件、状态板改为「已实现待验收」。

推理强度、精简说明、第 0 步关闭思考，按产品决定不在本单。

## T0 环境缺口

本轮没有登录态，也没有测试账号。公开接口测到：

| 检查 | 结果 |
| --- | --- |
| `GET https://staging.jyotisha.chat/api/health` | 200。`deployment.gitCommit` = `1252de3e6363f3097668efa1b1d5d47186c9c2d0` |
| `POST https://staging.jyotisha.chat/api/consultation_workflow` | 404。公网边缘没有这条 Python 引擎路由 |
| 本机 `vedastro` 模块 | 未安装 |

任务书里的 4.6 秒是沙箱网络下测的。当前测试环境跑的仍是改前版本。要确认生产机器是不是也在等这 4 秒，请在这次上线之前看现在的 `/admin/usage` 或容器日志：工具耗时是否接近「领域数 × 4 秒以上」。这次上线之后，同一处不应再出现这段等待；新的「分段」列用来看分类、第 0 步、第 1 步。

## T1 耗时

本机没有 VedAstro SDK，产品路径的冷热耗时没有重测。下表「改前」用任务书里的沙箱数字，「改后」是本轮测试能证明的行为。

| 场景 | 改前 | 改后 |
| --- | --- | --- |
| 装了 SDK、按产品路径，每个领域 | 约 4.6 秒，第二轮仍约 4.6 秒 | 本机测不了秒数。测试证明：不起快照子进程，状态是 `deferred_in_consultation`，不是已验证 |
| 同一天再问，上次是超时或失败 | 再等约 4.6 秒（失败不进缓存） | 负缓存同日命中，文件不重写，子进程不调用 |
| 下一个 UTC 日 | 任务书未单列 | 当天的负缓存失效，重新记 `deferred_in_consultation` |
| 当天已经有已验证的官方快照 | 顶层能用缓存，校正闸仍去等 | 校正闸复用同一份缓存。整数小时和进闸后变成的浮点小时，用原始请求对齐，避免对不上键 |
| 生时校正自己的请求（没有咨询标记） | 走原来的官方快照 | 仍走原来的 gateway，返回字段与现场结果逐项相同 |
| 顶层前台 VedAstro | 照旧（BUG-301） | 照旧。标记只作用在校正闸，不作用在顶层 gateway |

3 位公开名人 × 父母 / 年运、冷热各两轮：环境缺口，没有秒数。

## T2 产品在哪里看

用量页 `/admin/usage` 的「分段」列，旧记录没有这些数时显示「—」。数字来自用量账本已有的 JSON 字段，没有新表、没有迁移。同一组数也在服务端日志 `[agent-observability]` 里。本轮没有登录，页面没有点开；列的文字由单元测试锁住。

| 你看到的 | 含义 | 没有数时 |
| --- | --- | --- |
| 分类 180 ms | 分类这一步的耗时 | 分类 — |
| 第 0 步 … · 推理 · 出 · 入 · 缓存入 | 决定要不要排盘的那一步。耗时是毫秒；后面四个是供应商返回的 token | 该项为 — |
| 第 1 步 … | 写答案的那一步，字段同上 | 同上 |
| 写到正文 450 ms | 第 1 步开始，到第一个正文字出现。第 0 步的旁白不计 | 写到正文 — |
| 各领域工具耗时 | 原有字段，本单没有改含义 | 原样 |

日志和用量记录里的对应名字：`classification.durationMs`、`modelSteps`（只保留第 0 步和第 1 步）、`answer.reasoning_ms`、工具调用上原有的 `durationMs`。供应商没返回的 token 是空值，不估算。这些字段里没有提示词、答案正文、出生资料、用户标识。

## 开工预检

读了 `docs/research/pre_work_error_ledger.md`。本单不涉及碎片目录或镜像仓，没有再读两份碎片清扫。`scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45` 的结果：

| 项 | 结果 |
| --- | --- |
| Python 运行时 | 通过 |
| 外部引擎适配器 | 通过 |
| 远端可见 | 通过，远端是 `https://git.copse.top/root/Jyotisha.git` |
| 碎片扫描 | 90 秒超时 |
| 聚焦测试 | 45 秒超时 |
| 检查当时的分支 | 比 `origin/staging` 落后 1 个提交；随后已快进到 `4c64733f` |

碎片扫描和聚焦测试超时是这次预检命令自己的时限，不是远端同步失败。没有新的镜像路径要记。

磁盘：开工时 G: 约 557 GB 空闲，D: 约 135 GB，C: 约 24 GB。

## 已完成的检查

| 项 | 结果 |
| --- | --- |
| 新增 Python 测试 + 增长合同 | 11 项通过 |
| 两个新 Python 文件的 ruff | 通过。`jyotish_api_server.py` 里原有的 ruff 问题没有顺手改 |
| 前端计时测试 | 4 项通过，0 失败，0 cancelled |
| `tsc --noEmit` | 0 错 |
| `npm run lint` | 0 error，126 条既有 warning，没有为消 warning 改业务代码 |
| v5 打分文件 | 工作区没有改动。没有重跑 77 例 |
| 生时校正打分 | 没改 |

全量 `pytest tests`、英文对照、隐私测试、全量 `npm test`、快速门：见下面「套件对照」。对照完成前，不把本单说成套件已通过。

## 套件对照

前端全量 `npm test`（本机，不设 CI）。基线工作树 `853772bc`，本分支在快进后的产品代码上。两边都是退出码 1，cancelled 0，skipped 0。

| | tests | pass | fail | cancelled |
| --- | --- | --- | --- | --- |
| 开工基线 | 4844 | 4700 | 144 | 0 |
| 本分支 | 4848 | 4703 | 145 | 0 |

多出来的 4 个测试是本单的计时测试，全量里 4 个都通过。144 条旧失败名字与基线逐条相同。多出来的那 1 条是 `database roles have no cluster privileges`：全量并行时 Docker 里的 Postgres 正在关闭，`psql` 报 `the database system is shutting down`。这条测试不读本单改过的文件。单独重跑该文件：2 项通过，0 失败。不是这次改动引进的。

英文对照 `tests/test_report_english_dictionary.py` 与隐私 `tests/test_repo_privacy_markers.py`：一起跑，退出码 0。

`tsc --noEmit`：0 错。`npm run lint`：0 error，126 条既有 warning。

全量 `pytest tests`（`--tb=line`，退出码以失败名单为准；日志里的短摘要计数行没有落盘）。用量页没有用浏览器点开。

| | 失败条数 | 与对方相比多出来的名字 |
| --- | --- | --- |
| 开工基线 `853772bc` | 130 | — |
| 本分支 | 131 | `tests/test_consultation_native_layers.py::test_the_new_layer_leaves_every_existing_output_unchanged` |

其余 130 条名字与基线相同。多出来的这一条是既有的盘缓存抖动：缓存命中读回的 VedAstro 请求清单键序和现场重算不一样。这条测试会先跑掉新层再比整份输出，并且会剥掉 `vedastro_gateway`。它用的请求没有咨询标记，不走本单的校正闸开关。全量里失败一次。单独再跑：第一次失败，紧接着再跑一次通过。快速门里又失败一次，失败后用同一比较再跑，差异条数是 0。不记成新 bug。

v5 打分文件没有改动，没有重跑 77 例。

快速门 `scripts/run_quality_gate.py --profile quick`：退出码 1。1056 通过，1 跳过，1 失败。唯一失败仍是上面那条盘缓存测试。失败后立刻用同一比较再跑一遍，两边剥掉易变字段后差异条数是 0。这条失败跟着缓存时序走，不跟着本单的校正闸开关走。门禁跑完后，5 份待处理的 oracle 模板只多了回车换行，已还原，不进提交。

`next build`：这个工作树的 `frontend/node_modules` 是指到主检出的联接，Turbopack 拒绝「联接指向项目根以外」。改用门禁同一条 webpack 构建（`next build --webpack`）：编译 3.6 分钟通过，TypeScript 2.5 分钟通过。收集页面数据时停在 `/api/consult`，原因是 Windows 不允许为 Skill 运行别名建符号链接（`EPERM`，`SKILL.md` → 临时目录）。路由表没有打出来，所以没能在这台机器上确认 `/` 仍是 Static。首页源文件没改。没有为了构建去改符号链接，也没有在工作树里重装依赖。

## Claude 验收（2026-10-05，Linux，Node 22）

**结论：通过，快进合入 staging。** 环境是 Linux，Node v22.14，Python 3.13。基线工作树是 `4c64733f`，被验分支是 `137ed6f4`。

| 项 | 基线 `4c64733f` | 本分支 `137ed6f4` | 判定 |
| --- | --- | --- | --- |
| Python 全量 `pytest tests`（-n 4） | 62 失败 | 62 失败，名单逐条相同 | 通过 |
| 新增 Python 测试 + 增长合同 | — | 11 passed | 通过 |
| 快速门 Python 段 | — | `pytest` ✓；唯一红是 npm test 步，即下一行的同一批环境失败 | 通过 |
| 前端 `npm test` | 4932 / 24 fail / 0 cancelled | 4936 / 24 fail / 0 cancelled，失败名单逐条相同，新增 4 条全过 | 通过 |
| `tsc --noEmit` / `npm run lint` | — | 0 错 / 0 error、126 warning | 通过 |
| `next build`（Turbopack，硬链 node_modules） | `/` ○ Static | `/` ○ Static | 通过 |
| 首屏 gzip（index.html 引用 JS+CSS，gzip -9 求和） | 636,225 B | 636,225 B（0%） | 通过 |

24 条前端失败与 62 条 Python 失败，两边名单相同，属于本机无 Docker / 无模型凭据等环境项。执行方在 Windows 上看到的 Docker 关停与盘缓存抖动，这次在 Linux 上没有出现。

**T1 实测**（补上执行方的环境缺口）：在隔离 venv 里装 VedAstro SDK，走产品路径（`defer_optional_external_evidence: true`）。3 位名人 × 父母 / 年运，跑两轮共 12 次，每次都用全新的缓存目录。

| | 每领域耗时中位 | 校正闸 `official_closure_reason` |
| --- | --- | --- |
| 改前 `4c64733f` | 4.47 s（首次 5.89 s） | `official_raw_response_missing` |
| 改后 `137ed6f4` | 1.66 s（首次 2.02 s） | `deferred_in_consultation` |

- 每个领域省下约 2.8 s，降幅约 63%。
- 任务书写的「≤1.0 s」**没有达到**。我用 cProfile 拆过剩下的 1.66 s：
  - 约 1.33 s 是顶层前台 VedAstro 的等待上限（`vedastro_foreground.finish → _join_foreground_vedastro`）；
  - 引擎本体约 0.07 s（盘缓存是热的）。
- 顶层这次等待是决策记录第 3 条（BUG-301）明确要保留的。任务书的 1.0 s 目标，是照着「外网全屏蔽」时的 0.75 s 定的，定得不对。这是任务书的问题，不是实现的问题。
- 本沙箱里顶层 VedAstro 拿不到已验证的结果，所以「复用当日已验证快照」这条路径没有被线上式请求走到，只有单元测试 `test_same_day_verified_snapshot_is_reused_ahead_of_the_negative_cache` 覆盖。

**审查意见（不阻断，留给后续）**：

1. 咨询路径从来不启动快照子进程，所以负缓存里存的只会是固定的 `deferred_in_consultation` 包，起不到「记住失败」的作用。而且它每人每天在 `api_scratch` 里写一个文件，没有清理。以后可以简化成不写盘。
2. `modelSteps` 默认第 1 步就是写答案的那一步。如果模型连续调用两次工具，第 1 步其实是第二次工具调用，这时 `answer.reasoning_ms` 记为空值。读数据时要注意这一点。
3. 部署后由产品在 `/admin/usage` 的「分段」列看一轮真实数字。这一列本轮没有在浏览器里点开过。