 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
|
2a4086ab73
|
认口径按答案引用的那几列比：整条比不等价时先投影再交现有的绑定和判等价
真实助手的 SQL 总会多选几列（订单数、日期常量、MIN / MAX、COALESCE），报告只引用其中一列，口径的取数也只选它的指标要的
那几列。以前整条比，「上周的销售额是多少」3/3 只标相关口径、从不自动出具。
做法：sql_semantics 新增 project_select / project_template / output_names。按方言切词、按括号深度认出最外层 SELECT
列表每一项在原文里的起止，只把留下的几项原样拼回去（选择列表前后一字不动，保真守卫照样看得到原文），拼完重新解析、
语法树要和「原树换成留下的几项」一模一样。只在确定去掉不影响时投影，否则照实给原因、照旧整条比：DISTINCT / DISTINCT ON、
出现在 GROUP BY 里、被 ORDER BY / HAVING / QUALIFY / 窗口用到（按别名、同样的写法、按位置）、有 LIMIT / OFFSET 又不是
只出一行的聚合、集合运算、*、可能改变行数或不认识的函数、去掉仅有的聚合、留下按任意一行取值的列、调换先后时引用别的
选择项的名字，一律不去。
ledger/match：整条比不等价时，答案一侧按报告引用了这条查询的哪几列（labels.referenced_columns）投影，口径一侧按口径卡
上每个指标读了这个取数节点的哪几列（labels.card_reads）投影，投影后照样交 match_template（不另开给信任的路）。被引用的
列两边怎么对上写进模块说明：答案按列名在快照结果列里找位置、口径按 cell() 里的列名在输出名里找位置，投影后按位置配对，
答案留下两三列时另试调换先后，每份口径取数最多试 12 种。证明了的候选记 projection；没投影可试的逐对和以前一字不差。
算法版本升到 3；E1 另数 proven_projected；对账按投影后留下的列配对（不用人选）。
测试：tests/test_sql_projection.py（该去的、不该去的各一组，语料里 305 种投影在虚构库上执行守门）、
tests/test_ledger_projection.py（多选一列 / 多几个聚合 / 日期常量列能证明；多一个分组列、DISTINCT、按别的列排序加
LIMIT、HAVING 用到多出来的聚合仍然证明不了且和不投影时一字不差；口径一侧投影、调换先后；真跑一次整题等价；对账配对）。
去掉投影再跑，7 条失败。
|
2026-10-17 11:47:26 +08:00 |
|
|
ThearchyHelios
|
d17a08bafb
|
合入 W4-c 账本前端：证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询；被驳回的那一步 node.failed 带 reason=rejected，画布、航迹、时间线、问数据过程都画「被驳回」
|
2026-10-16 22:29:02 +08:00 |
|
|
ThearchyHelios
|
b3dcddb52e
|
召回复核修正（后端）：人工节点不再挡召回、读不出召回卡记失败、旧版不再接着算、团队渠道一次召回只推一条、目录核对按数据源合并排队；账本接口带上召回标记，对账结果可以反馈
- W4R-01：召回只查新版图里会不会写外部系统（apps/backfill 抽出 graph_external_write，graph_side_effect 复用它）。召回图只有两版
的取数和口径卡，图里别处的人工节点、按流程使用的问题碰不到它；口径卡上游的人工节点 derive 本来就认作数据部分不能复用。
「按新版重新出具」走完整的正式运行，仍按 graph_side_effect 全套拒绝。原来带审批的口径升版后一组都不召回，L6 对它们失效。
- W4R-09：收尾时召回卡读不出、或缺了某个比较的旧值 / 新值，照实记重算失败（读不出召回卡），原答案一个不动。原来两边都是空，
按渲染比被当成「没变」，给每个原答案永久盖上「已核对，不影响」，收过尾之后再也不核对。
- W4R-12：这一版已经不是当前发布版（之后又发布了更新的版本）时不再发起召回、不给接着算，批次里写 continue_reason，接着算的
接口 409 带同一句。同启动时接着做只认当前发布版：新版本的召回覆盖更早的所有版本，再按旧版开「口径升到 vN」的待办只是添乱。
- W4R-13：开登录时一组答案几个主人就几条待办，全局渠道却按这一批（recall.batch_of_key：同一次召回、同一个来由）只在最早开的
那条上推一次，答案、待办按这一批汇总，几条的链到待办箱；别的几条连 task.opened 也不再推全局渠道。个人渠道照旧每人一条。
- W4R-11：目录审阅之后的核对按数据源排队、批量审阅的几张表合成一遍（catalog_pass，同一数据源一把锁）；查询快照按数据源在库里
筛、按运行结束时间分页、每张表凑够 BASIS_MAX_RUNS 次运行就停；冻结的表结构快照这一遍里按工件 id 只读一次。原来批量审阅
几十张表就同时起几十个后台任务，每个都全表扫查询快照、反复读同一份几 MB 的表结构快照。
- W4R-03（本包那一半）：GET /api/runs/{id}/ledger 加 recall：checked（已按 vN 核对，不影响）、basis（依据有变：哪一种、几项、
新出现几条错误级问题）、tasks（看的这个人手上说的是这个答案、还没处理的 recall 待办）。不放数、不放表名。几种状态都带。
- W4R-10（本包那一半）：新事件 ledger.feedback（对账运行上的封存后事件），POST /api/ledger/answers/{run}/reconcile/{rid}/feedback
{verdict: useful | unclear} 记反馈，同一个人改主意只算最后一次（app/ledger/feedback.py）；账本接口的 reconciled 每一项带
feedback {mine, useful, unclear}；统计 E2 的 feedback 数到它，去掉「第 4 波接上」的占位说法。离线核对页、封存后事件摘要
都认得这个事件。
测试：test_ledger_recall 新增七个用例、改了人工节点那一个（召回照算、重新出具照实拒绝）；新增 test_ledger_feedback；
test_ledger_api 的 E2 断言跟上。每个修复都先写失败的测试、去掉修复回跑确认抓得住。后端全量 14237 通过。
|
2026-10-16 22:16:58 +08:00 |
|
|
ThearchyHelios
|
9886e10be2
|
账本接口：刚跑完未封存答 pending 只限结束后两分钟内，早就结束、一直没封存的照实答「运行还没有封存」
复核 W4R-08：上一次给 GET /api/runs/{id}/ledger 加的 pending 分支没有时间界限——成功结束、要比对、没封存的运行一律答
pending。它本来只为 runner 落库 run.finished 之后、封存之前的那一下（页面收到 run.finished 立刻来取）。封存出了错、或者是
封存这件事之前的老数据，会永远答 pending：每个轮次底部、证据面板都转两分钟「正在比对口径」，再取一次还是 pending；改之前
答的 ineligible「运行还没有封存，不比对」才是实情。
- ledger/view.py：新增 SEAL_GRACE_S = 120（和页面等比对结论的上限 store/ledger.ts 的两分钟同一个量级），_just_finished 看
finished_at 在不在这段时间里（没记结束时间的不算；库里读回 naive 的按 UTC 算，同 db/base.UTCDateTime）。只有刚结束的才答
pending，其余照旧走 ineligible（NOT_SEALED）；_stamp 里的局部 datetime 导入挪到模块顶上
- 测试：刚跑完的那条补上 finished_at=现在；新增一条结束已久、一直没封存的和一条没记结束时间的，都答 ineligible、原因是
没封存、不排按需比对。去掉 _just_finished 回跑，新测试失败（答的是 pending）
|
2026-10-16 22:13:52 +08:00 |
|
|
ThearchyHelios
|
a43224fd9a
|
账本接口补几样界面要画的东西：对账的入口字段、配列选项、对账卡的分组，刚跑完未封存时答 pending
账本前端（第 4 波 W4-c）照「界面层不放逻辑」只照服务端给的画，这几样以前接口不给，界面只能自己猜：
- 「看差多少」那一项（reconcile.actions_of）带上口径的入口字段 fields（名字、必填、有没有缺省值，比对工件里记的那一份）：
核对参数的表单照它画，缺的参数也写得出是哪一项
- 认不出列怎么配（409 ledger_reconcile_needs_pairs）另带 options：这次结果里是数、没遮罩的列，口径卡上的指标（id、名字、
单位）；ReconcileRefused 加 extra，api/ledger 的对账接口把它并进返回体（CodedHTTPException 的 extra，改一行）
- 对过的账（reconciled_view）带 card 和 groups：每一组对照的这次 / 口径 / 差值 / 相对差各是哪个指标、这一组怎么称呼
（从对账运行的图里读，不按命名规则拼），界面按 /evidence/metrics/{card}/{指标} 取值、三个数各自点得开
- GET /api/runs/{id}/ledger：runner 先发 run.finished、落库，再封存、再排比对，页面收到 run.finished 立刻来取时
还没封存。成功结束、要比对的运行这时答 pending（不另排按需比对），不再说成「运行还没有封存，不比对」
- 测试：对账的三样（单行、多行），刚跑完未封存答 pending、不排按需比对，失败的照旧 ineligible
|
2026-10-16 19:46:03 +08:00 |
|
|
ThearchyHelios
|
538799e70d
|
沉淀：认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证队列的转化（口径账本做法 8、10，拍板 L9）
为什么：同一类问题被反复问、Agent 反复写出同一个形状的 SQL，就该沉淀成一份口径；以前 from-run 保留 Agent，沉淀出的模板没有固定 SQL，以后永远比对不上。第 2 波的统计在 E2 反馈、E3 认证队列上照实写了「目前没有数据」，这一波补上能补的。
做了什么（新增 ledger/certify.py）：
- GET /api/ledger/certify-queue（搭建者）：确定性重复（问数据运行里被报告引用、没对上口径的查询，按数据源 + normalize_sql 文本分组，≥3 次运行且来自 ≥2 段对话；跨运行变化的字面量是参数候选，展示的形状不带取值）、问题聚类（app/chat/questions 全站唯一的那份）、被反复用的答案（导出 ≥2 次用第 2 波的 report.exported 审计、做成过应用看蓝图来源、在画布里打开或提取过看工作流 origin）。每项给代表问题、轮次、相关口径、是否已固化。
- POST /api/ledger/certify-queue/dismiss：「不是口径」写审计 ledger.certify.dismiss，之后不再进队。
- 固化成口径草稿（from-run 加 freeze、peers 后转调 certify.freeze）：报告引用的查询变成固定 SQL 的取数节点，跨轮变化的字面量换成 '{{ input.pN }}'（缺省值取代表运行的），单行结果的数值列成口径卡指标，报告核对规则按受管要求写、契约 report_from + metrics_from + required（多行加 cells）；过 validate_graph 和受管门禁。新工作流 origin.sources 记来源问题。
- 发布之后补比：api/workflows.commit_publish 提交后调 certify.after_publish，来源运行按新口径补比一次（新的 trigger=certified，界面写「按之后发布的口径回看」，时间线和账本接口同一句）。
- 统计：E2 加对过账的答案数、参数经人核对的、指标由人选的次数（反馈照实写第 4 波）；E3 认证队列的转化（固化、发布、不是口径）。
测试：tests/test_ledger_certify.py（参数推断与模板、三种信号进队、门槛、不是口径、固化草稿过受管门禁、发布后来源运行补比成等价已证明并出队、再问标等价已证明、统计）。
|
2026-10-16 17:06:41 +08:00 |
|
|
ThearchyHelios
|
906ec072ce
|
按口径正式出具与口径对账（口径账本做法 5、6，拍板 L1、L5）
为什么：问数据的答案整题等价于已发布口径时，要能按那一版发起一次完整走过门禁的正式运行（路径一、二a）；只是相关、不等价时，要能看「差多少」（路径二b）。两条路都不能让客户端冒充来源、自己传参数，也不能在 Python 里算差值。
正式出具（新增 ledger/issue.py）：
- POST /api/ledger/answers/{run_id}/issue {workflow_id, version}：参数只从比对工件的绑定取，补入口缺省值再过 apps/forms 校验；经 launch_run 发起正式运行，来源 ledger_issue，origin 记 source_run、conversation_id、turn_id、binding_hash、口径和认法、是否自动；按 expect_hash 钉 graph_hash。
- 不能出具照实写原因：整题不等价、点名别的口径、版本退役或没发布、图里有人工节点或写入（apps/backfill._side_effect 抽成共用的 graph_side_effect）、缺入口字段、超过每日上限、权限（L5：使用者只能按他有权使用的应用固定着的版本出具，复用应用授权，origin 记 granted_by_app；别的写「请搭建者出具」）。
- 自动出具（L1）：比对完（只在运行一封存就比的那一次）整题独立等价、版本受管、设置开着、当天没超上限才自动；助手选用的只给一键。不自动的原因写进 actions 的 auto_reason。
- 同一运行、同一口径、同一组参数只发起一次（input_key 去重），进程内按（运行、工作流、版本）串行。
- 设置加 ledger 一组：自动出具开关、每日上限、比对时限（ledger/match 读它）。
口径对账（新增 ledger/reconcile.py，derive 扩 reconcile_graph / ours_block / assemble 的出口契约）：
- POST /api/ledger/answers/{run_id}/reconcile：按那一版确定性派生只读图（这次的取数 ours_q1 → 口径的取数 → 口径卡 → 对账卡，出口契约 metrics_from，不加报告、不调模型），来源 reconcile 的探索运行；对账卡算这次、口径、差值、相对差。
- 参数是启发得来的、不全、含遮罩值时先让人核对（needs_check，没核对的 409）；指标式不是取数一格、差异有兜底时要人选对照哪个指标，选择记进 origin。
- 多行结果：被引用的行按维度列经合并查询 LEFT JOIN 对齐、按引用先后排，最多 10 行；维度是遮罩列、合并键不唯一照实拒绝。使用者发起带 MASK_RESULTS / READ_ONLY，搭建者也带 READ_ONLY。
- GET /api/runs/{id}/ledger 的 actions 补上出具、对账两类，issued、reconciled 列出发起过的运行。
测试：tests/test_ledger_issue.py（自动出具、只给一键的几种、拒绝原因、使用者的应用授权、并发只发一次、设置）、tests/test_ledger_reconcile.py（核对参数、派生图确定与契约、差值和相对差、出处链、要人选列、多行对齐、遮罩维度和重复键拒绝、使用者只读遮罩）；第 2 波 test_ledger_api 的 actions 断言按这一波改。
|
2026-10-16 16:55:06 +08:00 |
|
|
ThearchyHelios
|
4f4ad48ad7
|
组合式问数：问数据的助手可以 use_caliber 选用已发布口径，服务端确定性内联实例化（口径账本做法 4，拍板 L3）
为什么：问数据以前看不到口径，也没有组合机制；子图做骨架的路走不通（子图证据不交回父图、使用者用不了子工作流）。改成助手只选口径、填参数，取数节点由服务端按固定版本照抄，证据照常封存、比对照常复证。
做了什么：
- 问数据的查看对象加 caliber（look/calibers 的 compose 模式）：另给每张卡的入口字段（类型、必填、可选值、格式、缺省值）和「能不能组合」（ledger/derive.load_pinned 同一个认法），能组合的写出 use_caliber 的写法；仍不给 SQL。只给搭建者及以上：使用者的图里看得到拷进来的取数 SQL。
- 新增 ledger/compose.py：use_caliber {id, workflow_id, version, card, metrics, inputs} 经 derive.caliber_block（扩了 card_id、inputs 两项）实例化——取数节点照抄、id 加前缀、模板按参数渲染成字面 SQL，口径卡 id 就是操作 id、caliber_from 带改名映射。参数按入口字段过 apps/forms 校验，写进 SQL 引号里的不能带引号、裸写的只能是数；只能选这一轮看到的那一版、能组合的卡、卡上的指标；不合规拒收。
- GraphApplier 落地 use_caliber：节点、连线记进 seen（兜底重放照样在），入口连到第一个取数节点；转给界面的只有那一条操作带 result；拒收的原因经自查交回模型（GraphChecker.issues）。
- 提示：协议多一段 USE_CALIBER_PROMPT；LOOK_WHEN 里问数据那一条按细案改写（只在能选用口径时换）。运行时写 SQL 的 Agent 不看口径（L2）。
- 比对器认出助手选用的查询（从封存的图里读 caliber_from.nodes）：证明了的标 composed「助手选用」，没能证明的照常是相关口径并说明；标签 how=composed，指标标签记取自哪几条查询；比对算法版本升到 2。
- 前端：问数据过程里 use_caliber 照实显示一行（选用了哪一版、生成几个节点；拒收写原因），节点数算进「新增几个步骤」；文案进 LEDGER_TEXT.use；check-decode 加一节。
测试：tests/test_ledger_compose.py（实例化确定性、各种拒收、查看文字不带 SQL、提示切换、落地与接线、拒收交回模型、剧本模型走一遍生成再真跑出 composed 标签、使用者不给口径）。
|
2026-10-16 16:35:28 +08:00 |
|
|
ThearchyHelios
|
5b4bd91476
|
口径账本内核：运行封存后在后台比对已发布口径、逐个数标口径、按运行读的账本接口、来源链和导出留痕、统计 E1–E4
为什么：问数据的答案要和已治理口径接起来（next-round 02 做法 2、3、9、10；总方案 X1、X2、X3、X12，拍板 L2、L4、L8）。
- 比对（ledger/match.py）：探索运行（chat、canvas、trial、personal_app）成功结束、封存完、有查询快照时，在 runner 封存之后和
notify_run 同一个位置放到后台；候选口径是每个工作流最新的已发布未退役版本里查库的调用工具节点（受管、已发布都算），按数据源
和表预筛；逐个用 match_template 比，schema 用查询当时冻结的表结构、列名取同一份快照里冻结的数据目录。每次运行限时 8 秒、在
线程里、同时最多 2 个；超时、快照被改过或读不出、SQL 解析不了照实记 skipped。启动时（run_manager.setup，和调度循环同一个开关）
补比最近 7 天封存了却没比过的运行，只读工件和版本表。
- 记法（ledger/store.py，拍板 L8）：内容寻址工件 kind=caliber_match（agentlab.caliber_match/1）+ run_append 的 sealed 方式追加
ledger.matched（core/events.py 登记）；工件里不放时间和工作流名，同一份封存再比一次哈希一样；meta 记 calibers / related / counts。
- 标签（ledger/labels.py）：单元格按查询的比对状态；指标要每个输入都等价于同一份口径同一版、绑定一致，式子按「哪个取数节点、
第几行、哪一列」换完和口径卡上的一字不差。caliber（how：independent 等价已证明；composed 助手选用留给第 3 波）/ related /
reasoning / unknown；整题判断附还缺的入口字段。
- 读（ledger/view.py）：GET /api/runs/{id}/ledger（ledger_api.runs_router，和证据同一道门），没比对过、能比的按需排上；证据
片段接口加 ledger 键（没比对过的运行没有这个键，返回一字不差）；报告导出的面板最上面多「口径」一步并写明「封存后比对，不在
封存范围内」。遮罩按读的那一刻重滤：绑定的值是这次运行查到过的遮罩值时不给值，差异条目和逐行对照走 _Shown。
- 来源链：POST /api/runs 加 origin_ref（只在 origin=chat 时收，服务端核对对话访问权和轮次归属，写进 Run.origin 和封存的
run.origin）；WorkflowIn 加 origin（run_id、conversation_id、turn_id，核对规则同 from-run）；报告导出和可验证报告下载各记一条
审计 report.exported。可验证报告列封存后追加的事件时给 ledger.matched 一句只有条数的说明。
- 统计（ledger/stats.py）：E1–E4 从工件、运行、查询快照、审计现算，GET /api/ledger/stats（搭建者）；E3 用 app/chat/questions
的聚类加按（数据源、normalize_sql 文本）的确定性重复；评测直接调 compute_stats（可点名 run_ids）。对账反馈、认证转化、按发布
的召回在后面几波，照实写没有数据。
测试：test_ledger_match.py（真跑探索运行：等价、相关、没有相关口径、写死的码值、非探索运行、超时、快照被改、解析失败、预筛、
指标两种、级别、只认最新版、补比）、test_ledger_api.py（账本接口、按需比、遮罩、证据片段、导出、审计、统计）、
test_run_origin_ref.py（origin_ref 与画布来源的核对）。
|
2026-10-16 14:02:55 +08:00 |
|