15 Commits

Author	SHA1	Message	Date
ThearchyHelios	ac8b194ca8	评测时限不算排队（续）：within 看得更勤（不超过时限的 1/20），一段的头尾有一头在暂停就整段不算——以前一段只看尾巴，拿到名额后的头一段整段算进去，PostgreSQL 全量满载时那条测试偶发超时；测试改成排 2 秒、时限 1 秒，给拿到名额之后的几次写库留够余地	2026-10-19 13:46:09 +08:00
ThearchyHelios	62089f2849	复核「另外两处」：评测每题的时限、算期望的时限都不算排队等运行名额的那一段（within 代替 asyncio.wait_for，作答那次运行在 slots 里还排着队时不走表；算期望的运行排着队时把截止时刻往后挪），满载时不再被记成超时、触发止损；同源队（SourceLanes）跟发名额一样，拿这个源的咨询锁之前备好「哪些别的属主确实不在了」，持锁期间只用持锁的那条连接，拿锁之后才出现的属主这一次当活着。slots 加 waiting(run_id, here=)：本进程里的直接看、不查库。补测试：排队 0.8 秒、时限 0.3 秒照样答完不记超时（改前的写法这条不过）；within 暂停的那几段不算、不暂停照样超时；同源队持锁期间不查「谁还活着」、没了的进程照样让位、拿锁之后才出现的属主不删	2026-10-19 13:31:46 +08:00
ThearchyHelios	4e3623885b	合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算） ... # Conflicts: # backend/app/api/schedules.py # backend/app/main.py	2026-10-19 12:21:38 +08:00
ThearchyHelios	89cd135174	补多进程协调的单测（两种库）：别的进程用库里的行装出来（登记着的同伴、从没登记过的已经没了的进程）——谁还活着、名额按优先级先给交互类、一类到了上限不挡别的类、没了的进程占着的名额收回而活着的同伴的不碰、同源队几个进程共用且跳过没了的进程的位置、接手运行只碰属主不在了的（升级前没记属主的照不在了处理）、停止和记事件交给活着的属主、属主不在了的停止直接接手放弃、当班到期交接、同一本每日账并发记不越过上限、SQLite 第二个进程（以及 AGENTLAB_WORKERS 大于 1）拒绝启动；评测说明里的并发一段照现在的名额说	2026-10-19 12:14:39 +08:00
ThearchyHelios	0d9f1d9339	用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样 ... - 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里） - 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres	2026-10-19 12:07:06 +08:00
ThearchyHelios	87f0d62f9b	多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁	2026-10-19 11:40:33 +08:00
ThearchyHelios	271bc6e782	口径标签逐格判：引用了好几列的查询，每个数按它自己那一格标 ... 真实模型下问「上周的销售额是多少」，助手写 SUM(amount) AS 销售额, COUNT(*) AS 订单数, MIN / MAX(paid_date) AS 区间首日 / 末日，报告四列都引用了，口径「周销售」只取 SUM(amount)。按「全部引用列」投影后还是 4 列，对不上口径的 1 列，整条比、 四个数都标相关口径，说明整段兜底。 - ledger/match._cells / _cell（algo 4）：整条（含按全部引用列投影）没证明、又引用了这条查询两列以上的，被引用的每一列单独 投影到那一列，和每份口径的每个指标读的那一列（card_reads；口径版本没有口径卡的按取数的每一列）逐个比，仍只走 match_template / explain_sql_diff，上次的投影规则照用：投影不了（分组列、DISTINCT……）、过了时限、不可比的格照用整条 查询的那一个候选。结果记在 queries[].cells {列名: {status, candidates}}，另记 one_row（sql_semantics.one_row：不分组的 聚合，一定只出一行）。整条这一层的结论、候选一字不改；老工件没有 cells，照旧按整条读。 - ledger/labels：单元格按它那一格的结论标（_view）；指标用了同一条查询的好几格时，只有那条查询一定只出一行才把逐格的 结论合起来用（多行的结果里每一列各自对得上，不等于每一行的几列一起对得上）。整题照拍板 L1 不变：每个数都证明来自 同一份口径才等价；一格证明了、别的格只是相关的整题不等价，原因写「有的数和相关口径不一致，不来自口径」（以前一律说 「这次的推理」）。出具入口照 ledger/issue 现有判法只在整题等价时给，没有放宽。 - 逐格证明了的口径各处都算上（labels.candidates_of）：工件 meta 的 calibers（召回按旧版本反查）、ledger/uses 的使用记录、 召回时找原答案对应的那一格、E4；E1 另数各种结论各几格（cells），E2 的兜底比例按标签上给人看的那一份说明数。 - GET /runs/{id}/ledger 的 queries 带上逐格的 cells（遮罩同候选）；证据片段的 ledger 键、轮次摘要的计数本来就按每个数的 标签，数据变了、形状不变。前端只补类型；check-ledger 加一段：同一条查询一格来自口径（正文挂小标记）、一格相关（差在哪 先说多查了几列），整题不等价不给出具。 - 评测逐题比 SQL（eval/score.sql_match）取和期望配上的那一格（score.matched_cells：评分时配上的格），没给时取逐格证明了 的那一格；结果带 column。runner、rescore 传它。 测试：tests/test_ledger_cells.py（同一条查询一列等价、一列不等价各自标对；两份口径只证明了一份标那一份；口径多个指标按列 配对；指标跨两格只在一行的查询上用逐格结论；分组列、DISTINCT 逐格也不投影；照真实例子造的虚构库真跑一遍：销售额标等价 已证明，订单数、首末日标相关，整题不等价、不给出具、不自动出具，证据片段的 ledger 键一致；评测取配上的那一格）。去掉逐格 再跑，10 条失败；去掉「一行才合起来用」、去掉评测取格，各 1 条失败。	2026-10-17 13:07:19 +08:00
ThearchyHelios	67b13a921b	评测页检查守住估不出金额时的写法；估算说明去掉重复的半句 ... 接着「评测估算和每题平均花费：有估不出金额的调用时不再写成 0 美元」那一项：check-evals 加一节，在浏览器里核对开跑对话框 上一次都估不出时写「估不出花费」和原因、不出现 $0，估出一部分时写「至少约 …（每项至少约 …）」；评测总览都估不出时花费写 「金额无法估算」、不写每题平均，估出一部分时写「≥」和「每题至少约」。 在浏览器里看到「估不出花费 · …估不出花费：…」说了两遍，runner.estimate 全估不出那一句的说明去掉了重复的「估不出花费」。 验证：check-evals 110 项全过（新加 5 项）；test_eval_runner.py::test_the_estimate_says_it_cannot_price_instead_of_zero 通过。	2026-10-17 12:11:55 +08:00
ThearchyHelios	4aa3e6f01f	评测估算和每题平均花费：有估不出金额的调用时不再写成 0 美元 ... 价格目录里没有助手模型时（真实模型验收的接入就是这样），第一次评测估不出、照实写了；第二次起估算按上一次的每题平均 花费算，而每题平均是「估得出的那部分」除以题数 = 0，开跑对话框写「约 $0」、评测总览写「每题约 $0」，像不花钱。 - eval/stats.summarize：每题平均花费一分都没估出来（有估不出的调用、估得出的部分是 0）时为 None，估出了一部分的照给； - eval/runner.estimate：上一次的调用金额都估不出时照实写估不出（带次数和原因，金额上限只管得住估得出的调用）；估出了一部分 的标 at_least、带上另有几次估不出，说明写「实际至少这么多」；老总表里每题平均记成 0、却有估不出的调用的也按估不出算； - 按角色用量里裁判那一份（runner.judge_usage）补上估不出的次数：以前只有金额和次数，裁判模型不在价格目录里时写成 $0； - 评测页：开跑对话框估出一部分时写「至少约 …（每项至少约 …）」，总览的每题平均有估不出的写「每题至少约 …」，一分都没估出来 的不写（金额那一格已是「金额无法估算」）。 providers/usage 的汇总形状不变：cost_usd 是估得出的那部分、unpriced_calls 是估不出的次数，和运行的 usage 是全系统一个口径 （细案 01 做法 3 定的），前端的金额写法（runCostText）一直按这两项一起写「≥」或「金额无法估算」；漏掉的是只读 cost_usd 去算 平均、做估算的这几处。模块说明里把这条写明了。 测试：test_eval_stats.py::test_the_per_case_cost_is_not_zero_when_calls_could_not_be_priced、 test_eval_runner.py::test_the_estimate_says_it_cannot_price_instead_of_zero（全估不出、估出一部分、目录价是 0 的才是真 不花钱）、test_eval_runner.py::test_the_judge_role_keeps_its_unpriced_calls。去掉修复回跑三条都失败。	2026-10-17 11:40:27 +08:00
ThearchyHelios	ccb2b2baa8	评测停止、中断、到了上限后的计数照实分开：没跑的题单独计 not_run，stop_reason 写停下的原因 ... 验收：评测停止或中断后，没跑的题计入 errors、done = total、stop_reason 为 null，读起来像全评完了、出了很多错。 原因：runner._counts 把 cancelled、skipped 都算进 done（TASK_DONE），cancelled 又算进 errors；停止、中断走 _close → _conclude(status, None, error)，原因写进了 error、stop_reason 是 None；服务重启后的整理（startup、reconcile_stale） 和排队中就停掉（cancel_queued）只改了逐项状态，计数还是旧的、stop_reason 也没写。 改法： - _counts：done 只算真的跑过的（ok、partial、failed）；停止、中断时没评完的（cancelled）和到了上限、止损之后没开评 的（skipped）单独计 not_run；errors 只算 failed；skipped 只算评了、但期望算不出、不评分的（verdict），不再混进没开评 的。done + not_run + running + pending = total。 - 停止、中断是「停下」不是「出错」：_close 把原因记进 stop_reason（STOPPED / INTERRUPTED），error 留空；整体出错照旧 记 error。到了上限、止损本来就写 stop_reason，不变。还没备好几臂就停下的那一支（bare）同样写 stop_reason 并重算计数。 - core/job_runtime 的 close_job、cancel_queued 加一个可选的 finish：状态改好、提交之前在同一个事务里补一步。评测的 startup、reconcile_stale、stop 用它记 stop_reason、按改好的逐项状态重算计数（_closing）。起草、剖析、探查不传， 行为不变（它们的测试全过）。 - stats.summarize 的 not_run 也只算没跑的（cancelled、skipped），出错的另列 errors（以前 not_run 里混着出错的）。 前端：评测页总览「N 项没评（停止、中断，或者到了上限、止损之后没开评）」和「M 项出错」分两行；类型补上 not_run、 errors 的说明。停下的原因本来就照 stop_reason 显示。 测试（test_eval_runner）：停止之后 stop_reason 是「评测已停止」、error 为空，errors 为 0、done 是评完的题数、not_run 是其余，总表的 not_run、errors 同样分开；重启整理成 interrupted 时 stop_reason 是中断的说法、计数重算（not_run 1、 running 0）；新增一条排队中就停掉的：not_run 等于题数、pending 归零；到了金额上限没开评的那题记 not_run、不记跳过。 去掉修复回跑挂 4 条。check-evals 的停止夹具照服务端改，核对停下的原因、不当成出错、没评的单列。评测、起草、剖析、 探查、定时维护相关的测试 548 条全过；tsc、check-copy 通过，check-evals 103 项全过。	2026-10-17 09:10:52 +08:00
ThearchyHelios	9e33c0f801	评测的两个通知事件照实叫「定时评测有退步」「定时评测没有评完」（复核 L3） ... eval.regressed、eval.failed 只在定时发起的评测收尾时推（runner._conclude 只认 trigger == "schedule"），手动发起的那次人自己 在看、不推，这和细案 01 做法 15 把这两个事件放在定时一节里一致。可订阅时的叫法却是「评测有退步」「评测失败」，没写「定时」： 有人给全局渠道勾上「评测失败」、再手动发起一次评测并止损停下，渠道里收不到任何消息，界面上也没处说为什么。 - notify/service.EVENTS 和前端 NOTIFY_TEXT.eventLabel 同一句改成「定时评测有退步」「定时评测没有评完」（test_notify_events 逐字对照两边）。eval.failed 不只是失败：到了上限、止损停下（partial）同样推，所以叫「没有评完」，和消息标题本来的说法一致。 - notify_eval 的消息标题也带上「定时」：定时评测「题集名」有退步 / 没有评完。 - 新测试：两个事件的叫法带「定时」；手动发起的评测止损停下，订阅了这两个事件的全局渠道收不到任何消息（去掉 trigger 的判断 这一条就失败）。 - 模块说明、接口说明里引用旧叫法的几处一并改。	2026-10-16 18:23:03 +08:00
ThearchyHelios	40daf37107	评测发起后立刻交给后台再读回；补「复核要重来」的测试 ... 为什么：发起评测时提交之后、交给后台之前还 await 了几次读回，这中间别的请求读到「排队中、却没在这个进程里跑」会把它 当成服务重启留下的、标中断。改成提交之后立刻交给后台，再读回。 - test_eval_runner：复核给了 retry_instruction 时带着这次运行的图、照那句话重来一次，第二次复核（attempt=1）不再要重来， 两次作答运行都记在这一题名下	2026-10-16 17:15:17 +08:00
ThearchyHelios	a0cdb16617	重评时把评分规则版本记进指纹；去掉几处没用的导入 ... 为什么：按新规则重评之后，和别的评测比时「评分规则」那一项要照实标出变了；总表上另记重评的时间。	2026-10-16 17:11:09 +08:00
ThearchyHelios	df6c3ce10d	定时页照实显示非工作流目标；评测停止时几臂一起收尾；工作流题的测试 ... 为什么：这一波后端开始接受评测题集、数据源维护这两种定时目标（总方案 X4），定时页要能把它们照实列出来、点进去 不报错；界面上不能有点了没用的入口。 - 定时页列表：非工作流目标写种类（评测题集 / 数据源维护）和目标名，不标运行类别，「编辑」写成「查看」 - 详情：非工作流目标的设置只读地列出名称、目标、频率、时区、补发宽限，不出工作流那张表单（选工作流、输入模板、 Webhook 对它们不适用）；页头的启用、立即运行、删除和触发历史照常 - 立即运行发起的是一次评测时说「已发起一次评测」（以前会落到「未能发起运行」）；触发历史写评测的编号 - types.ts：Schedule 加 target_kind / target_id / target_label / target_name / target_exists，触发记录加 eval_run_id； 文案进 SCHEDULE_TEXT - check-schedules 加一段「目标不是工作流的定时任务」 - runner：还没准备好就被停下、出错时，按 pair_id 找全几臂一起收尾 - 测试：工作流题按钉住版本跑探索运行（不发正式运行、不建图）；钉住基线的接口 - 后端几句给人看的话按文案规范改（不用「跑」「钉」）	2026-10-16 17:04:05 +08:00
ThearchyHelios	2371e75f17	评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段） ... 为什么：第 2 波只有题集和期望答案的来源，评测本身跑不起来。这一段把细案 01 做法 9–12、16、17 的后端接上， 量的是用户在问数据页拿到的同一轮，而不是另抄一份编排。 - eval/answer.py：无头作答，串起 answer_ops → chat/turn 的决定 → launch_run(origin=eval，带目录视图、只读、遮罩) → 等终态（停在审批的取消、记「评测不代批」；驳回记路径「被驳回」）→ review_of_run → 按同一规则重来一次； 工作流题按钉住版本的图跑探索运行（不发正式运行，免得被 pick_base 和应用视图取到）。用量按角色记 - eval/runner.py：用 core/job_runtime，一次评测一个任务，题 × 重复 × 臂一项；A/B 几臂共用期望、同一题同时开跑； 开评拍目录快照、记上传表格版本和表结构哈希的前后；并发不超过 max_parallel 和全局并发的四分之一；每题时限； 评测单独一本账（开跑前估算、每题预留后找补、触顶不再开新题）；止损；能停、只重试没做完的、重启标中断不续跑 - eval/score.py：六种期望、五种结论（量纲不同单列）、维度配对与弱匹配、路径不对直接不通过、口径 dual 两版都报； 逐题 E1 用口径账本的 compare_queries（总方案 X2，不另写 signals）；SCORER_VERSION 可重评（eval/rescore.py，只读封存） - eval/judging.py：结论裁判走按需裁判同一条路（evidence._judge_now），文字要点由裁判判、单列不计准确率；花费经 judge.charged_to 记在评测那本账上（engine/judge.py 只加了一个上下文变量和取账本的一处） - eval/stats.py、eval/compare.py：准确率与可追溯准确率 + Wilson 区间、各项分布、P50/P90、按角色成本、引用率、逐题 E1； 选基准、逐题转移与归因、指纹差异、A/B 配对表与精确 McNemar；「目录贡献」预设对照（当前 vs 关，可加只用已核实） - eval/cleanup.py + core/artifact_store.forget：保留最近 N 次 + 钉住的基线 + A/B 另几臂，删结果、明细工件、底下的运行和 引用行，工件文件一条引用都不剩才删；总表永久保留 - engine/tolerance.py：双盲复算的 _agree / _delta_pct 原样搬来共用（dual_check 改 import，行为不变） - 设置加 eval 一组（builder 读、admin 写）和 GET /api/settings/eval/spend；题集预算在全站缺省上覆盖，每日上限只能往下收 - api/evals.py：发起（单臂 / A/B / 目录贡献预设）、估算、进度、逐题、停止、重试、重评、钉基线、和上一次比、配对表、清理 - main.py 的 lifespan：影子起草和评测的启动整理、关停（评测先于运行停，停时取消自己发起的运行） - 测试：test_eval_e2e（dual_check_shop + 剧本模型：按支付日 330 通过且 SQL 等价，按下单日 310 不通过、差在 time； 目录对照 1:0；和上一次比找到退步、归因做法变）；通知事件、定时接口形状的老测试按新事件和新字段更新	2026-10-16 16:38:09 +08:00