 ThearchyHelios
|
6a7e51b81b
|
K3 复核修正（第 2 轮）：* 把遮罩列带进别的列名时按展开落到的位置遮；函数参数里的 JSON 箭头认作遮罩列；agent 查到的遮罩值和报告里的分开记，上限收满也不丢
- * 改名（复核点名的 blocker）：WITH t(a, b, …) AS (SELECT * …) 这类列名表、UNION 后一支的 *、FROM 子查询或 LATERAL
的列名表、标量子查询和 ARRAY 子查询里的 *，以前 * 本身不算取自哪一列，原值原样交给核查 agent、落库，第二道防线也
认不出。现在 * 带出遮罩列的值时，它展开落到的那几列都算（masking._star_places）：只展开一个来源、每一列都数得清的
按位置只遮取自遮罩列的那几列——子查询按选出项数，数据源里的表按查询当时冻结的表结构数（_schema_columns；工具边界
用数据源的 schema_cache，事后按快照的 schema_artifact，是同一份），几张列一样的月度表 SELECT * 连起来汇总，金额照常；
数不清的（没有表结构、列数对不上、几个来源）整段遮。表结构只用来数位置，不用来断定表里没有遮罩列。标量子查询里的 *
按 _value_columns 展开（展开数据源里的表一律算），EXISTS 里的 * 不算；递归的 CTE 不会绕不出来；带 EXCLUDE / REPLACE
的 * 不按位置数
- JSON 箭头：函数参数里没写表名的 col->'path' 被 sqlglot 解析成以 col 为参数的 lambda，_value_columns 把 lambda 的
参数名照列名收。SQLite json_each(profile->'$.tels')、Postgres jsonb_array_elements_text(profile->'tels')、MySQL
JSON_UNQUOTE(profile->'$.tel') 这几种拆开、取出来的值在工具边界就遮
- 上限：run_verify_agent 以前先把调用方交进来的报告快照值并进 seen，收满 SECRETS_MAX 之后 agent 查到的值并不进去，后面
的查询、回答时的第二道防线都认不出。现在两份分开记（masking.SeenValues：given / found），查询工具按值遮、交回调用方
（VerifyOutcome.masked_values）时合起来，agent 查到的在前；反方审稿理由的按值遮也改成 agent 查到的先收
- 已知局限写进 inquiry 模块说明：表结构过期、列数没变却换了次序或改了名时可能数错；EXCEPT 后一支照 UNION 算（多遮）
测试：新增 test_masking_star_renames（真跑 SQLite 的各种 * 改名、按表结构数位置、表结构对不上、快照记着的表结构），
工具边界（交给模型的、落库的、通用工件接口）和审批质询端到端的 * 改名、JSON 箭头、上限收满；每处实现都做过去掉之后
测试变红的验证。
|
2026-10-06 20:29:58 +08:00 |
|
|
ThearchyHelios
|
099473cd6d
|
K3 复核修正（第 1 轮）：后面的查询按此前遮掉的值遮、质询工件照回答时记下的位置重放；表值函数拆开遮罩列也认；汇总遮罩列的指标不派盲算；反方理由按值遮
复核发现质询工件接口相对基线回退：agent 自己的查询快照在工具边界遮好之后，事后取质询工件收不到它另一次查询里的号码，
没设遮罩的备注、联系方式列原样给出。另有几处模型照样看得到遮罩值、或者遮多了的地方。
- 工具边界（tools/datasource、engine/masking.mask_query_result）：此前已经认出的遮罩值（这个 agent 前面的查询遮掉的、
调用方交进来的）也用来按值遮后面的结果，数据源没设遮罩的也一样。审批质询、反方审稿在派 agent 之前把报告快照里的
遮罩值交进来（inquiry.snapshot_secrets，run_verify_agent 的 masked_values），模型从第一条查询起就看不到。已经摆在
读者眼前的值（提问人写的、报告指标、被审的结论原文）跟着并进来的值一起免遮（_Secrets.protected）；这份结果自己写
的分档标签不按前面收的值换。
- 先查备注、后查出号码的：回答时只靠内存里的值才换掉的地方按快照记成位置（不含值，masking.view_edits），写进质询
事件的 masked_cells，质询工件接口先照着重放（replay_edits）再按原来的办法遮。工具边界按值换掉的整格照样画成遮罩列。
agent 查到的值先收、报告快照的后收：上限收满时不丢 agent 自己查到的。
- _derived_hidden 认 FROM、JOIN、LATERAL 里拆开遮罩列的表值函数（json_each、json_tree、unnest、jsonb_each_text、
regexp_split_to_table、JSON_TABLE、LATERAL VALUES）：按出列名认，不认得的函数又没写列名表的整份遮。
- 汇总里的 CASE 只在条件里用到遮罩列的不算取自遮罩列（同写在 WHERE 里）。双盲复算按同一套认法认出指标取自遮罩列
（SUM(amount)、amount 设了遮罩）时，派盲算之前就记为无法复算并说清原因，不白花一次盲算（nodes/dual_check 的
_query_input，改动在文件所有权之外，只加这一处判断）。
- 反方审稿：理由正文和理由文档按值换掉遮罩值（换了写法的也认），这句结论原文里写着的不换；重新组装时引用到的格子按
遮好的快照渲染。
- 换了写法的号码另认不换行空格、窄空格、细空格、制表符、减号，最多四个分隔符；SQL 的字符串、带引号的名字、注释里
也认（不带引号的数照旧是算式），字符串里换掉的号码同一条 SQL 里写成阈值的也不留；列名同样认。
- 查询失败时报错原话里的值换掉（mask_error_text：引号里、不带引号的长数，SQL 里写着的照留）。
- 快照的 mask_columns 只记数据源设的列名，改了名字的结果列只在 masked_at_query：证据面板并各份快照的这一项从表的
字段清单里去列，混进别名会误藏同源别的表里同名的真实字段。
- * 展开数据源里的表时按冻结的表结构认它带不带同名列，没有的照常认分档标签（J2 收紧之后的多遮）。
- 格子引用指到按值换掉的格子时照实说；上万个值的合并、免遮放进线程。
测试：质询 agent 先查号码后查备注、先查备注后查号码、另一张表的号码列两种先后，质询工件、通用工件接口、事件都没有
原值；报告快照里的值在第一条查询就遮；表值函数（SQLite、Postgres、MySQL 的写法）、汇总里 CASE 的条件、* 连着的表按
表结构认标签、新的分隔符、SQL 字符串和注释和列名、报错原话、mask_columns 不混别名、遮罩列汇总的指标不派盲算、反方
理由按值遮且免遮结论原文、上限收满时 agent 的值先收。逐处去掉实现（24 处）对应的用例都会变红。
|
2026-10-06 19:11:14 +08:00 |
|
|
ThearchyHelios
|
450758185d
|
K3：核查 agent 看到的查询结果先遮、存下的快照也遮
双盲复算、反方审稿、审批质询共用的 engine/verify_agent.py 以前把查询结果原样交给模型（db_query 自己落快照，ToolMessage
里是原样的结果），遮罩全靠审批质询事后按值认，期 4 起六轮复核每轮都找到新的漏法；运行详情「工件」页签走的通用接口
GET /api/artifacts/{id} 还把核查的查询快照原样给出。根本的修法是不让模型看到遮罩值。
- tools/datasource：查询工具加遮罩开关 mask_results（缺省关，Agent 节点、调用工具节点照旧）。打开时数据源设了遮罩的，
先按 engine/masking.py 的 mask_query_result 遮好再交给模型、再落快照：列名直接对上的、按 SQL 认出取自遮罩列的
（别名、函数、子查询、WITH、SELECT *，复用 _derived_hidden；SQL 解析不了又写着遮罩列的，整份结果的列都遮）整列
换成「已遮罩」、类型记成文本；同一份结果里别的格子整格是遮罩值的换掉，文字格里夹着的那一截换掉（换了写法的号码
也认）；列名不换。结果里一列都没取自遮罩列的（数值的汇总、只数个数、只在条件里用到）原样。快照里 mask_columns
另记下查询时遮了的、改了名字的结果列（证据面板、质询工件据此画成遮罩列），masked_at_query 记下查询时就整列遮掉的列。
这一次遮掉的值并进 ToolContext.extra[MASKED_VALUES_KEY]，只在内存里。
- verify_agent：建查询工具时和 force_readonly 一样打开遮罩开关；格子引用指到查询时就遮了的列，照实说是遮罩列、不采信；
遮掉的值经 VerifyOutcome.masked_values 交回调用方（不进 as_dict、不往外交）；系统提示补一句「已遮罩」是什么。
- 审批质询：按值遮降为第二道防线。agent 自己的快照查询时就遮好了，收不到遮罩值，改由 masked_values 并进来（_plan 的
seen），回答、查询清单照旧按值遮；「已遮罩」本身不收成遮罩值。事后取质询工件时内存里的值已经不在，SQL 检查结果的
片段、说明照事件里记下的那条 SQL 换（_recorded_swaps：逐词对出回答时换掉的字面量和 LIKE 里换掉的那一截）。
- 双盲复算取盲算值、反方审稿的引用、证据面板、可验证报告（带遮罩的快照只给哈希，照旧）、推演、运行对比（不收核查的
查询）都按快照里已经是「已遮罩」照常工作，文件不用改。
测试：核查 agent 选出遮罩列（直接、别名、函数、子查询、WITH、SELECT *）时交给假模型的 ToolMessage、落库的快照、通用
工件接口、tool.end 预览、收尾交给模型的查询结果里都是「已遮罩」；没碰遮罩列的聚合查询原样、照常取值；文字格夹着的
号码换掉那一截；引用遮罩格子不采信；SQL 认不出时整份遮；开关缺省关、没设遮罩的源快照一字不差；列名不改；审批质询、
反方审稿、双盲复算各补一条端到端；质询工件的检查片段照记下的 SQL 换。逐处去掉实现（开关、并进内存的值、照记下的
SQL 换、跳过「已遮罩」、遮罩格子的说法、记下改了名字的列、文字格按子串换、不改列名）对应的用例都会变红。
|
2026-10-06 17:36:55 +08:00 |
|
|
ThearchyHelios
|
62b9361d88
|
期 4 复核修正（第 1 轮，后端）：预告组合先算个数再列、上限按每项算，核查 agent 的两个日志代码归类，未能反查的句数守住不多于无法判断
- preview_joint 以前先把每一项的全部组合列成列表才和 JOINT_LIMIT 比，二十个指标落到同一项上就是几十亿种，在服务进程里（asyncio.to_thread）能把整个服务拖死；现在先按 ∏(1+k)−1−Σk 算出个数（超过上限即停），超了整项跳过、不列。上限也改成每一项各算各的：以前几项共用一份额度，前一项用掉以后，后面没超上限的项也被悄悄跳过，和文档说的「超过的那一项不预告」对不上。补两条测试：二十个指标落到同一项上时一个组合都不多列，两项各 72 种都预告
- review.py 认得核查 agent（双盲复算、反方审稿共用）发的两条：verify_unpriced 同 judge_unpriced 只是配置提醒，不再叫复核模型、给答案加降级说明；verify_limit 记成它自己的 kind（步数上限只有它说），不再落成笼统的 warn
- 反方审稿测试补上「未能反查的句数不多于无法判断」的断言（审批卡上的两个数靠这个约定对得上），模块说明改写准：触顶没给出结论的可能查过几次，原因里也有报告未引用数据库查询
- 双盲复算夹具加一种组合 time_rejected：业务日期被驳回过的那一列由退款率采纳（被挡下，带着写到哪），销售额采纳另一列；服务端先归拢、说法不同一项都不写（夹具测试按 record_choices 真写核对），审批卡没有合并预告时的推断按它检查
|
2026-10-06 09:31:00 +08:00 |
|
|
ThearchyHelios
|
375f7165e5
|
反方审稿说清「根本没反查」和「到底降不降档」：产出和审批卡的概况加 unreviewed（模型不可用、触顶、数据源不在了等没能反查的句数，触顶但按查到的收了尾的不算）和 degrades（按降档处置、又接在带出具契约的成果节点上游时才为真，侧枝上、成果节点没带契约时为假）；升级前的产出不带这两项，审批卡照旧规则说
|
2026-10-05 18:48:35 +08:00 |
|
|
ThearchyHelios
|
64b6586ecc
|
出具缺口不再把节点类型说两遍：上游缺口的前缀在节点名就是类型叫法时只写一次（「反方审稿：」），双盲复算、反方审稿的缺口正文去掉自带的类型（「推翻了 1 句结论：…」「指标「X」两路结果不一致，审核人选择了盲算结果」）；时间线和报错里那句照旧带主语
|
2026-10-05 18:45:59 +08:00 |
|
|
ThearchyHelios
|
4d364d385b
|
反方审稿复核修正（第 2 轮）：照录的理由不露内部标记、裸数字注明无出处，只停用了部分数据源时理由和时间线写明没查哪几个，撞上每日金额上限的几句同一种说法
- 不采信时照录反方的理由改成纯文字：解析不了的引用（⟦?v:…⟧）换成「（引用无效）」，裸数字后面注明「（无出处）」。
这种句子没有理由文档，界面按文字显示，以前内部的占位标记会原样露在审批卡上，裸数字也不标
- 一句该查的数据源只停用了一部分时照常反查，理由末尾由系统注明哪几个没查（写进理由文档：界面按文档画理由，
写法和把说明写进原文再组装出来的一模一样），时间线另记一条 challenge_sources_lost。以前只写进给 agent 的任务，
审稿记录和审批卡上的「经受住」看着就像每个源都查过了。没挂依据的句子按整份报告用到的源查，任务、理由里不再说
「这句引用的」
- 当天的核查金额用完时，派出去就撞上上限、一次模型都没调用的那句，和后面不再派出的句子用同一种说法
「已达上限（…），这句未反查」，不再一句「反查未完成：…没能交结果」、一句「这句未反查」
- 判失败的报错只推翻一句时说「请核对这句结论」
没有改的：被推翻的出具缺口读成「反方审稿「反方审稿」：反方审稿推翻了…」并归在「校验不完整」下，审批卡和节点产出
分不出根本没反查，challenge_unreviewed / challenge_sources_lost 不在期 3 约定的日志代码表里——这几处要改约定或
别的包的文件（io.py、decode.ts、NodeCard.tsx、EvidencePane.tsx、ChallengeSummary），留给编排者定
|
2026-10-05 15:50:20 +08:00 |
|
|
ThearchyHelios
|
4ceac6b74c
|
反方审稿复核修正：没有出处的结论不采信，推荐接法下审批卡有报告，重试和接着跑不重审、不拿旧审稿冒充
- 出处：一条查询都没执行成功的判什么都记为无法判断，判「被推翻」的理由里还得引用到自己的查询结果——零查询的推翻能让
正式出具降档，零查询的「经受住」会给审批人假安心。系统写明原因，反方原本的结论和理由照录。这句引用的数据源都已
停用时不派 agent；核查模型本身用不了时后面的句子照同一个原因记，不再逐句去建模型
- 时间线：有句子没能反查时另记一条 challenge_unreviewed（带第一条原因），challenge_done 的说法分开写查过的和没查成的
- 审批卡：「报告 → 反方审稿 → 人工审批」时审批说明不引用正文也认得出这份报告（reviewed_report_ids 穿过直接连着的
反方审稿，reviewed_by_human 同步），审稿概况附得上
- 重试与接着跑：同一次执行里的重试沿用已经审完的结果，不再多花一份钱、也不会把「被推翻」重审掉；审稿结果带输入指纹
（报告、文档、反方模型、上限、遮罩），接着跑时只改「结论被推翻时」沿用，改了审稿本身就重审
- 处置：产出和审批卡里的 on_refuted 写实际生效的 degrade / flag；「报错并停止运行」配「出错时：记录错误并继续」画布
校验挡住，跳过校验的旧图执行时改按出具降档；反方审稿不在带出具契约的成果节点上游时画布给警告（降档不会发生）
- 摘录里指向原报告查询的写法（指标取自查询 Qn、查询 Qn 的 SQL、出现在查询 Qn）都标成「原报告 Qn」，和反查 agent
自己的 Q1 分开
- 选项叫法和检查器下拉一致：出具降档 / 只标注 / 报错并停止运行，「启用」写跟随设置；助手手册同步
- 补测试：快照里的反方模型和每日上限、裁判判成不是结论的句子不审、审批卡只给被审的那份报告挂概况
|
2026-10-05 15:08:53 +08:00 |
|
|
ThearchyHelios
|
69b40c0b43
|
反方审稿测试补两处：摘录按数据源当前的遮罩也要遮，撞上每日金额上限之后不再派 agent
去掉实现逐项验证时发现两处测不出来：遮罩只测了查询当时就设好的情况（快照里自带遮罩列，不传当前遮罩也遮得住），
改成同时测运行中途才给数据源设上遮罩；每日上限只看了结果（后面的句子反正也会被拒），补上「只派了一次」的断言。
|
2026-10-05 14:00:59 +08:00 |
|
|
ThearchyHelios
|
dc5a113e29
|
反方审稿节点（后端）：报告写完后挑几句关键结论，各派一个只读 agent 站在反方写查询找反例，被推翻的让出具降档
结论句裁判只看写作者挂的证据，可证据本身就可能挑过（只查了含退款的销售额）。反方审稿换个方向，自己查库去证伪：
- 选句照裁判的预筛（judge.candidates）：挂了依据的、带比较或因果的在前，取前「最多审几句」句，裁判判成不是结论的不审
- 每句一个核查 agent（verify_agent.run_verify_agent）：工具只给这句引用的查询所在的数据源（指标按输入取自的查询、合并查询
按它合并的源算；没挂依据的在整份报告引用的源里查）；任务给这句结论和它挂的证据摘录（judge.prepare，遮罩照旧，编号改成
「原报告 Qn」免得和 agent 自己的 Q1 混淆）；理由里的数字只能引用自己的查询格子，裸数字被标出
- 审稿记录 challenge_artifact 按约定的形状随运行封存；台账只记 kind challenge，查询不进任何报告的写作目录
- on_refuted：degrade（默认）写 issuance_gaps 让出具降档，fail 判节点失败，flag 只记录；产出带实际的 on_refuted
- 上限：句数、每句查询数、每句时长、全局每日金额，都按发起时快照的核查设置（run.options["verify"]，没有快照按设置当前值），
节点上写了的盖过它；全局关闭、报告没有可审的结论句、报告文档读不到时直通并记 challenge_skipped
- 日志按约定的 code 带结构化字段：challenge_skipped / challenge_same_model / challenge_limit / challenge_done / challenge_refuted
- 整个反查（连同存记录、发日志）放在一个 @task 里：接着跑时不重复查库、不重复记账、时间线不重发
- 审批卡：human 的 _reviewed_reports 给被审的报告附上 challenge 概况（counts、最多 10 条 items、artifact、on_refuted），
没审过就不加这个键
- 画布校验：要审的报告必须是上游的报告撰写节点（不写时取直接连着的那份或上游唯一的一份，多份要人选）；各项配置写错报中文、
执行时报同一句；反方模型和写作模型写成同一个给警告
- 占位期的直通测试只留双盲复算（反方审稿的直通行为改由 test_challenge_node.py 覆盖）
|
2026-10-05 13:57:38 +08:00 |
|