16 Commits

Author	SHA1	Message	Date
ThearchyHelios	4c0e83bc80	目录视图接缝 data/catalog_view.py（细案 01 做法 5，总方案 X7）：读目录的四处统一经它，「开目录 / 关目录 / 只用已核实的项 / 目录快照」的对照才做得了 ... - CatalogView{mode: live | snapshot | off, statuses: all | reviewed, snapshot}：缺省 live + all，行为和以前一样；reviewed 只留已核实、已确认的项（驳回的项原样留着交给各处，照旧经 visible_notes 去掉，冻结快照和 SQL 检查靠驳回的关系编号认出不该现推的关系——为此在 catalog.py 加 restrict_notes，没给 visible_notes 加参数） - 视图从哪来：运行从 Run.options['catalog_view'] 读（catalog_view.of_run：RunContext.extra 里的发起快照，审批恢复、续跑沿用），ToolContext 多一个 catalog_view，节点（调用工具、llm/agent、多 agent）构造时带上；生成过程从参数读（下一个提交接 answer_ops） - 四处消费一律经它：运行时 db_schema / db_query（tools/datasource._catalog_of，冻结进表结构快照的也是这一份）、look 表详情（TableKind.load、copilot_context.look_service 收 catalog_view）、自查的 SQL 检查器（sqlcheck.load_checkers 收 catalog_view，改用 catalog.read_catalogs 一次读出）、双盲复算（_Sources 带视图，交给盲算的目录和比较 SQL 用的中文名都按它；核查 agent、反方审稿的 db_schema 也按这次运行的视图） - 冻结快照：不是缺省视图的在引用 meta 里记下 catalog_view（不进内容哈希，缺省视图不记，快照和以前一字不差），证据面板据此写得出「本次运行目录：关」 - snapshot 模式只定读法（kind=eval_catalog_snapshot 的工件，{sources: {源 id: {tables: {表: {version, notes}}}}}），内容由第 2 波的题集包写；快照不在了照实报错（CatalogSnapshotMissing），不悄悄退回当前目录 - 新增 tests/test_catalog_view.py：四种视图在四处给的是同一份、缺省等于当前目录、运行从 options 读且冻结 meta 记下、lint（消费模块不许直接 read_catalog / read_entry / 查 CatalogNote）；去掉 _catalog_of 里的视图回跑两项失败	2026-10-16 10:28:01 +08:00
ThearchyHelios	89a4bc8cfc	合入期 5 验收修复 M1：核查 agent 正文里的依据标记不再断句——只装着依据的括号（含【】［］〔〕[]）连同里面的停顿标点一起去掉，去掉之后按真正挨上的两个字补空格，两个数不再并成一个；核查 agent 的提示词改成依据写在句末；收尾超时照实记 timeout_s；没给理由时照实说没有给出理由	2026-10-12 13:12:20 +08:00
ThearchyHelios	c97390511e	M1 复核修正（第 1 轮）：去掉只装着依据的括号不再把两边的数字粘成另一个数；括号去掉之后外面照一个依据再收拾；换行不算句末；核查 agent 的理由按渲染后的正文判有没有给；反方审稿收尾超时按时长上限说 ... 渲染（evidence._see_cuts）： - 括号是两边唯一的分隔、去掉之后数字字母会粘成一串的（「[[v:Q1.r0.销售额]]（[[see:Q1]]）2 月」渲染成「4,919.52 月」，片段 本身没错、月份不算裸数字，哪项核对都查不出来），括号换成一个空格；半角逗号夹着依据、去掉后一个之后同理（「212,5」→ 「212, 5」）。切口可以带替换串，连成一片的按并集换 - 只装着依据的括号去掉之后，整对括号当一个依据看外面：括号前悬着的停顿标点（「华南居首，（[[see:Q1]]）。」）、到句末只隔着 的空白、夹在两个分隔标点中间的后一个，和不带括号的写法收拾得一样 - 依据后面到句末标点只隔着空白的，空白一起去掉（「华南居首 [[see:Q1]] 。」不再剩「华南居首 。」） - 换行不再算句末：列表项末尾的「；」、软换行处连着两个分句的「，」是写作者自己的，依据挂在它后面正合规矩，照旧留着（上一轮 把它们删了） - 没有依据的文档渲染、内容哈希不变（随机两万份和基线逐份比过）；流式分块输出仍等于整篇渲染 - 依据写在「依据」「见」「取自」「来源」这类引出语后面时引出语悬空，渲染时去不掉（引出语在依据前面，流式渲染得攒住每个可能 是引出语的字）：测试里改成严格的 xfail 写明已知限制，不再把验收里的缺陷钉成预期；核查 agent 遇到这种写法记一条日志 核查 agent（verify_agent）： - 有没有给理由按渲染出来的正文判：只写了依据（[[see:Q1]]、「（[[see:Q1]]）」）显示出来是空的，占位词后面挂着依据的显示出来 只剩占位词，都算没给。以前按原文判，标记里的字也算，理由文档照样交回：审批卡画出一片空白，判「被推翻」的因为引用到了 Q1 被当成有出处、出具降档；封存之后的质询回答只剩系统说明却记成回答成功 - 「无」「暂无」「none」只在理由是另一个结果的说明时（双盲复算、反方审稿）算没给；结构里只有理由一项（审批质询）时理由就是 回答，「无。」是一个回答，不再报「模型没有给出回答内容」让提问人重问、再花一次钱 - 收尾超时的原话收成常量 SETTLE_TIMEOUT，调用方据此换成自己的说法 反方审稿：交结论那次超过时长上限的句子，理由写「反查未完成：已达上限（每句时长上限 N 秒）」（收紧过的说运行时长上限将至）， 和时间线上的 challenge_limit 一致，不再把核查 agent 的内部原话摆上审批卡。 测试：补节点级用例钉住收尾超时之后两个节点对外的说法（challenge_limit 的 limit、claims_skipped、cause，双盲复算的无法复算 原因和 dual_check_limit，收紧过的两种）；理由只有依据、占位词挂依据、「无。」作为回答的各层用例。每处改动都做过去掉实现、 测试变红的验证。	2026-10-07 01:19:26 +08:00
ThearchyHelios	169c500526	K3b 复核修正（第 1 轮）：数值格按位置认、(表达式).* 带外括号也整份遮、同名 CTE 按作用域认、认不全的写法名单合一、整份遮不再把每一格收成遮罩值、证据摘录分段遮、反方最后一道关只看正文 ... - 同名列（回退）：column_types 按列名记，同名的几列只留得下后一列的类型，文字的备注被当成数值列，号码不再按值换、 原样交给模型并落库。现在只在列名唯一时按列类型认数值列（_typed_numbers），同名的按格子本身认：整数、小数才算数， 写成字符串的数按文字照换、记进 masked_cells；列名唯一、列类型是 number 的 NUMERIC / DECIMAL 字符串照原样 - (表达式).* 外面套了括号、起了别名（((p.card).*)、(p.card).* AS x，Postgres 实测照样展开）：以前只遮第一列。选出项 先去掉外括号、别名再认（_unwrapped），(s).*、(s.*) AS x 照旧当 s.* - WITH 里和数据源里的表同名的一段（WITH sales AS (SELECT * FROM sales WHERE …)）：不带 RECURSIVE 的一段看不见它自己和 排在后面的段（_scoped_cte），同名的按数据源里的表认；以前认成它自己，* 展开什么都不带出，整行引用的号码原样交出 - 认不全的写法：和可验证报告合成一份名单（masking 的 OPAQUE_SQL、INDIRECT_FUNCTIONS、INDIRECT_NAMES，bundle 引用后另加 系统 schema），补上 MySQL 会执行的注释、U&"…"、pg_stat_get_activity、逻辑解码、MySQL 的 column_statistics / general_log / PROCESSLIST / performance_schema、MariaDB 的 column_stats、Oracle 的直方图 / *_tab_columns / V$SQL 一族； 去掉注释再认一遍（函数名和括号之间夹注释）；去掉 DuckDB、SQL Server 的函数（query 误伤同名 CTE、字符串）；没有 * 的 一支选出项和结果列数对不上的、Postgres 解析不了的整份遮 - 整份遮只收确定取自遮罩列的那几列的值（_derived_masks 的 collect，报告快照收值同一规则）：以前每一格都收，区域名、 列名在同一次核查里处处被换掉，封存的 SQL 也被改写。快照另记 masked_whole，格子引用照实说写法认不全 - 证据摘录分段遮（inquiry.ExcerptMask，judge.prepare 的 mask 取代 kinds）：SQL 照封存 SQL 的办法换，范围阈值、LIMIT 照 原样，和遮罩列做等值、IN、LIKE 比较的字面量不论收没收到都换；格子逐格遮，数值格照原样；质询把被问的那句（连同表格） 当作已经摆在眼前，摘录、查询工具、回答里都不换 - 反方审稿：理由文档的目录列名照快照换（同质询的 _renamed_entry），agent 自己 SQL 里照原样留着的阈值、行数在正文里 不换（_shown），最后一道关只看正文和原文，不再把 agent 起的列名、阈值当成露了遮罩值整句改判 补测试：同名列一文一数、DECIMAL 字符串（含端到端引用取值），外括号 × 复合类型 / 记录函数 / 匿名 ROW × 最外层 / UNION 前后支 / 和 * 写在一起，同名 CTE 四种写法和 RECURSIVE 对照，十七种认不全的写法和三种不该误伤的写法，整份遮后的 收值与封存 SQL，Postgres 解析不了的整行引用，摘录的阈值、数值格、IN / NOT IN 字面量、被问那句（反方、质询各端到端）， 反方别名里的阈值（经受住、被推翻各一条）、找某个值的别名、正文里的阈值。逐项去掉实现，对应的测试都变红。 改了文件所有权以外的 bundle/build.py：_OPAQUE_SQL、_INDIRECT_READS 改为引用 masking 的同一份名单（另加系统 schema， 覆盖面不小于原来）。	2026-10-07 01:09:36 +08:00
ThearchyHelios	7de4aa1550	收尾超时一律记时长上限：循环里先查满了次数、再在交结果时超时的，limit 也是 timeout_s ... 上一个提交在模型自己停了查询时补上了 timeout_s，但循环里先撞上别的上限（查询次数、轮数）、交结果那次又超时的，仍记 先撞上的那个：质询会显示「未能回答（已达查询次数上限）：回答超过时长上限…」，自相矛盾；双盲复算会说盲算查满了次数、 反方审稿说「每句最多查询 N 次」——查满了照样能交结果，没交成是因为超时。现在交结果那次超时一律记 timeout_s，和报错 原因一致（运行时长上限将至、时长被收紧过的，双盲复算、反方审稿照旧按 timeout_s 说成运行时长上限将至）。金额被拒的 收尾不变，仍报循环里先撞上的那个（test_verify_truncation 钉着它，原因见那里）。	2026-10-07 00:09:46 +08:00
ThearchyHelios	735dc32052	核查 agent 的依据照写作者的规矩挂在句末；收尾超时照实记时长上限；占位词不当理由 ... - 交结果的提示（VERIFY_FINAL_PROMPT，双盲复算、反方审稿、审批质询共用）以前写「提到某次查询时写 [[see:Q1]]」，模型就 把它写进括号、句中；反方审稿的系统提示自己也把它写在括号里（「（[[v:Qn.rX.列名]] 或 [[see:Qn]]）」）。改成和写作者 一致：依据挂在句末（「……结果一致。[[see:Q3]]」），说明它渲染后不显示，不要放进括号、句中或「依据」「见」「取自」 后面。已经写进括号的由上一个提交的渲染收拾干净 - 模型自己停了查询、收尾那次调用超过时长上限时，limit 以前是 None：质询的报错写着「回答超过时长上限（180 秒）」， answer.limit 却是 null，界面少了「已达时长上限」；双盲复算、反方审稿把它当成别的原因，审批卡上照出内部原话。 现在记 timeout_s；循环里先撞上的上限照旧优先（同金额被拒的收尾），结构化输出、退回普通调用两条路都一样 - 交回的理由是空的、只有标点，或者只是一个占位词（验收里盲算交了字面的「placeholder」，审批卡照着显示）：当没给 理由，不组装理由文档。反方审稿的记录里理由为空，审批卡照旧写「反方没有给出理由」；质询照「模型没有给出回答内容」 报错；双盲复算的对照工件里说明为空 测试：交给模型的提示（含三处调用方的系统提示、任务）里不再示范括号里的依据；写进括号的依据在理由文档里渲染干净、 仍挂在句子上；审批质询的回答、反方审稿的理由、双盲复算的说明端到端都没有空括号；收尾超时 limit 为 timeout_s（核查 agent 和质询接口、事件里都是）；占位词的理由三处都不当理由。	2026-10-07 00:05:17 +08:00
ThearchyHelios	3ced800cde	K3b：工具边界的按值遮只换文字格，换过的格子记进快照；占位的短词不当遮罩值 ... 以前工具边界按值遮扩到没设遮罩的数值列：访问次数正好等于某一笔被遮的金额，交给模型的、落库的都成了「已遮罩」，column_types 仍是 number、快照不留记录，盲算引用到时说成「不是数值」，存下的证据被改写。现在 _masked_view 在工具边界不按值换数值格（数、列类型记成 number 的格子），只换文字格（整格就是遮罩值的、文字里夹着的那一截），换过的格子随快照存下（masked_cells：[行, 列号]，不交给模型），核查 agent 的格子引用指到它们时照实说是遮罩。回答、质询工件里的按值遮（第二道防线）照旧。遮罩列里占位的写法（未知、暂无、N/A……）不收进遮罩值，没设遮罩的区域、备注里的同一个词不再被换掉。补测试，分别去掉数值格的豁免、masked_cells 的记录、引用时的判断、占位词的过滤，对应的测试都变红。	2026-10-06 22:44:48 +08:00
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	4905de728c	核查截断的回复一律不采信，触顶原因的先后照旧，截断的建议按模型从哪来的说 ... 复核第 1 轮的发现（主要一条）：Anthropic 的工具调用写到一半到了上限时，回复照样带着 tool_use（input 是空的，有的网关给半截对象）。工具循环只在没有工具调用时才看截断，于是一轮轮执行空参数的查询，撞到步数上限，最后记成「没有按结构交结果」；收尾的强制工具调用截在半路时解析出空对象或半截对象，空对象记成没按结构交，反方审稿的半截对象（结论写完、理由写到一半）被当成「经受住」，质询把半句话当成回答。 - 工具循环：回复被截断就停，带着的工具调用不执行（半截的 SQL 查出来的数是错的），也不收尾 - 截断前查到过东西的也不再按查到的收尾：截断前查到的不一定是要的那个数，交出去的结果只在 notes 里写一句「可能不完整」，审批卡、反方结论、质询回答都看不到，残缺的结果还照常参与比对和处置。同时长到点一样算半路被掐断，原因照截断说，查过的照记；TRUNCATED_SETTLED 和日志里的 delivered 字段去掉 - 收尾：回复被截断时，解析出来的、从回复里抠出来的都不采信（结构化、普通调用都是），也不退回普通调用 - 上一轮的 give_up 把触顶原因的先后从「先 stopped」换成了「先 refused」：去掉 give_up，收尾被上限拦下时照旧报先撞上的那个（双盲复算按它写无法复算的原因，反方审稿按每日上限决定还派不派后面的句子） - 截断的原因开头只说「未能给出结果」（质询里提问人看到的就是这句，不说「核查未能完成」）；建议在节点里说「在节点上指定不带推理的模型，或在设置里更换核查模型」（节点上的模型优先于设置，和时间线上的下一步一致），质询只说设置 - 退回小额度按 budget_refused 认，按 (接入, 模型, 额度) 记在进程里 - 时间线：verify_truncated 的副标题固定说「这次核查未能给出结果」，check-decode 跟上；review.py 里 verify_truncated 的注释跟上 测试补上真实 ChatAnthropic（只有 HTTP 层是假的）的循环截断、收尾截断（空对象、半截对象），真实 ChatOpenAI 写到一半的工具调用参数，Bearer 鉴权下 SDK 在本地拒绝时退回 4096，自建服务的 max_new_tokens，跨次核查记住被嫌大，触顶原因的先后	2026-10-06 14:30:03 +08:00
ThearchyHelios	3bb06e32f1	整理：核查收尾时一条报错的续行对齐，裁判的 _TRUNCATED 挪到用它的 _ask 前面	2026-10-06 13:13:49 +08:00
ThearchyHelios	a552f4feab	核查模型的输出额度改为 16384、服务方嫌大时退回 4096，截断照实说：工具循环、收尾的每次调用都看有没有到了上限被截断 ... 额度：judge.MAX_TOKENS 从 4096 改为 16384（核查的 verify_model_spec 沿用它）。经 OpenAI 兼容接入的推理模型收不到 thinking=off，思考算在额度里，4096 常常想完就没额度发查询、交结果；16384 是常见网关接受的输出上限里偏大的一档，cite_fields 的抽取也是这个数。服务方嫌大（400/422 且报错提到 max_tokens 一类）时退回 judge.FALLBACK_MAX_TOKENS（4096）再试一次，工具循环和收尾共用一个开关，之后都用小的；小额度的模型要退回时才建。 截断：工具循环里没有工具调用、finish_reason=length（或 stop_reason=max_tokens）不再当成「模型说完了」，一条查询都没成功时不再收尾（收尾只能交「查不到」，双盲复算就会记成「盲算没有查到这个数」）；查到过东西的照常收尾，取不到要的数时同样交回截断的原因，取得到的照常交、notes 里注明。收尾被截断（Anthropic 强制工具调用写到一半、openai 结构化输出抛 LengthFinishReasonError、普通调用只有思考）时交回截断的原因，不再退回普通调用多花一次额度；截断那次的用量从异常里取，照记账。给人看的原因写明「核查模型的输出达到上限（N token）被截断，核查未能完成。通常是推理占满了输出额度，可在「设置 → 偏好设置 → 核查」中换用不带推理的模型」，经 error 交给双盲复算的无法复算原因、反方审稿的「反查未完成」、质询的报错；节点里调用时另记一条 verify_truncated，llm.end 标出 truncated 和额度。没有截断时原有说法不变。 测试：新增 test_verify_truncation（假模型返回 finish_reason=length、只有思考、LengthFinishReasonError，覆盖工具循环、收尾结构化和普通调用、退回 4096、别的 400 不重试、三条渠道）；三处钉着 4096 的断言改成 16384。	2026-10-06 12:58:37 +08:00
ThearchyHelios	132d126c6f	核查 agent 复核修正：数值字段的各种写法都换成格子引用、认不出的结构下的数不采信；退回普通调用时把结构写进消息，没交的字段不再算「查不到」；收尾的钱按最贵的样子留、留过的不再被上限拦；永远不抛 ... 数只认格子：原来只认 type: number / integer，可为 null 的数（anyOf，Pydantic 的 Optional[float] 就这么写）、$ref 引用进来的、allOf 包着的数值字段都没换成格子引用，模型写的数原样收下。现在先展开本地 $ref、并掉 allOf，anyOf / oneOf 里有一支能放数就整个算数值字段；取值时按值的形状挑分支。认不出的结构（没写类型、文本字段、没写 items 的数组、没写属性的对象）下模型写的数一律丢掉、照记下来，码值里的数照收。嵌套的引用、数组写成一段 JSON 文本的照样认，还不是数组的照实记下格式不对。数值字段引用到日期、名称这类不是数的格子，记成 unresolved，不拿去和原流程的数比。 退回普通调用：原来消息里只有「按给定结构填写」，结构却不在请求里，模型猜不到字段名，交回来对不上的字段全成了 missing，双盲复算会说盲算什么也没查到。现在把结构（JSON Schema）写进消息；没交的字段记 unresolved（模型没有交这个字段），交了 null 才是 missing；一个要求的字段都没交就是没按结构交结果，照错误交回。模型建结构化输出就报错的，直接走普通调用，不白算一次调用。 上限与金额：一条查询自己的时限到了（ToolTimeout 也是 TimeoutError）原来被当成整个核查的时长到了，现在先认 ToolTimeout，原因交回模型、核查照常往下走。收尾要把查到的结果交给模型，原来留钱按眼下的消息估，最后一条查询的大段结果一进来就不够，查完了付不起收尾、结果白查；现在按收尾最贵的样子留（查询结果按 _digest 的上限、最后的说明截到 2000 字、结构也算），留过钱的收尾不再被上限拦下，实际用量超出估算或并行的核查先用掉当天余额时，最多超出一次收尾调用的钱。每日上限缺省按设置里的「核查每日金额上限」，明确传 None 才是不限，质询接口不必各自记得去读。 永远不抛：每日账写不进去、建工具出错这类意外原来会直接抛出，节点失败、质询接口回 500；现在整段包住，按已经攒下的用量、查询照实交回。	2026-10-05 01:46:55 +08:00
ThearchyHelios	f1c068d6a9	核查工具箱收尾：连接的方面补上另一侧（关联条件里出现的别的表，CROSS JOIN 写它之前的来源），双盲复算对照数据目录里的关系时用得上；只读 agent 收尾前先拿到收尾用的模型再预留金额，模型拿不到时不在每日账上白记一次调用；收尾消息的参数改名 limit_words，说清是哪个上限的说法	2026-10-05 00:42:02 +08:00
ThearchyHelios	1efa5f7b20	核查用的只读 agent：engine/verify_agent.py 的 run_verify_agent 给双盲复算、反方审稿、审批质询共用。工具只建给定数据源的 db_schema / db_query，一律 force_readonly；自己管工具调用循环（不依赖 NodeContext / @task），查询次数、时长、金额（这一次、全局每日）任何一项到顶就停止查询、按已有结果收尾，收尾那次时长到顶另给宽限，金额每一轮都给它留出钱；模型不在价格目录里时金额上限无效，照裁判的说法记一条说明；每次调用记进核查的每日账。成功的查询按本 agent 自己的顺序编 Q1、Q2…，给了 emit 才发 llm / tool 事件（role: verify，查询的 tool.end 带 query_artifact，随运行封存、能下钻），绝不往证据台账写 kind: query，免得进了报告的写作目录。最后按调用方的结构交结果：数值字段换成格子引用 {alias, row, column}，由代码从快照取值，模型自己写的数字不采信、取不到是 None；理由里的数字写成 [[v:Qn.rX.列]]，用本 agent 自己的台账 build_catalog + compose_doc 组装，裸数字会被标出；结构化输出失败退回普通调用抠 JSON。上传表格按调用方给的数据版本查。永远不抛，模型没配好、调用失败、触顶都落在返回值里	2026-10-05 00:34:17 +08:00