Files

T

jesse-uxandGrok (agent loop) 9e29310941 合并 staging，并让发问准备的检查跟上新位置

两条按源码原文查找的检查改认搬走后的写法，意思没有放宽。对照脚本挪到测试目录，镜像构建不再去找测试文件。业务代码和三个开关的默认值没改。

自测：相关前端测试 40 通过，失败 0，取消 0。假时钟仍是并行 160、串行 210。tsc 0 错，lint 0 error。

Co-Authored-By: Grok (agent loop)

2026-10-14 10:56:17 +08:00

1.9 KiB

Raw Blame History

发问准备并行：本轮量到的和没量到的（2026-10-14）

开关都还关着。用户发问后的第一行，这轮不会变快。

进程内假时钟

命令：node node_modules/tsx/dist/cli.mjs tests/consult-prep-parallel-ab.mts（在 frontend 目录）。

假延迟：注销检查 50 毫秒，读会话 80 毫秒，解析模型 80 毫秒。这不是数据库实测。

	逻辑耗时	同时进行的步数
串行	210	1
并行	160	2

并行比这三条假延迟的相加更短。它不能代替「首帧中位数下降两成」的开启条件，因为本机没有量 Postgres。

审核密钥不在这台机器上。测试里把审核挂起 1500 毫秒，第一小段在 400 毫秒内已经写出，然后才收到拦截。这是假等待，不是供应商的真实时间。

版本缓存

行为测试：15 秒内第二次解析不再查库、不再做地址检查；清缓存后会再查；缓存关掉后每次都查；查库失败和空结果不会被记住。没有量到真实「准备模型」那一段快了多少，所以缓存时间保持 0。

两个领域一起算

命令：.venv\Scripts\python.exe frontend\scripts\research\consult-domain-concurrency-ab.py

本轮没有启动计算服务，也没有带星盘网络库的镜像。任务书起草时的试算大约只快一成，热缓存时反而更慢，达不到快两成五。默认仍是一个一个算。

仍然关闭的原因

开关	现在	要打开还缺什么
发问准备并行	关	本机 Postgres 上鉴权、注销检查、读会话、读模型各 30 次的中位数，并且首帧中位数至少快两成
模型版本缓存	0 毫秒	同上，准备模型那一段至少快一半
两个领域一起算	1	带星盘网络库的镜像上墙钟至少快两成五，争用时 429 不增加，响应除约定字段外一致

1.9 KiB Raw Blame History