AgentLab

__init__.py

…

analysis.py

分析能力入口（七）：按 W1-a 算子库的实际接口对齐。工具参数名以算子为准：差异检验的均值是 mean / sd / n 或 sum / sumsq / n，逐行是 value，可选 pairs / reference；可比性检查另收可选的 measure、grain（不收 label）；分析卡的参数校验用同一份定义，运行当天、目录事实、下钻层数由算子自己记，分析项里写了不收。交给算子的输入是工件库里那份查询快照原样（含 SQL 检查结果 checks、「查询区间里这张表没有数据」no_data、查询当时记下的遮罩），加上出处和遮罩列（数据源设的、按 SQL 认出改了名字的、遮罩运行里查询时就遮掉的），合并查询写明 sqlite 方言；agent 的容器在分析前把每份换成完整快照（每份只取回一次）。探查器改用 analysis.make_prober(数据源名 → 按运行固定版本解析出的源，coverage.Cache 一个节点里共用)，剖析事实一律用 analysis.probe.profile_facts（查询工具的覆盖检查也改用它，原来那段同样的取法删掉）。分析次数用完交回 analysis.exhausted 的那句；口径卡的可比性写成 {工件, 判定码, 判定语, analysis.comparable_reasons 拆出的原因}，删掉自己拆原因的那段。加真算子的端到端测试：agent 变化拆解并下钻（父结论按内容哈希认）、审批恢复重放不再算、分析卡的波动基线和变化拆解（本期完整按现查的表范围判）、口径卡跑真可比性检查（可比、有条件可比带原因），每份结论都按封存的工件复算、逐字段相同

2026-10-21 13:27:12 +08:00

challenge.py

子工作流里的反方审稿按全局 id 记它审的报告：审稿记录和工件上的报告写这次运行里的 id（「sub/write」，同 report.checked、报告文档，第 1 波 B1 修过报告节点同样的问题），证据面板连子工作流里的审稿一起认（_Sealed.nodes_of nested），点开子图里那份报告的句子认得出审它的那次审稿；审批卡上的报告按全局 id 记，打开证据面板、审批质询对得上；单句面板的报告名写「子工作流 › 报告」，不写内部 id

2026-10-19 09:08:45 +08:00

control.py

…

dual_check.py

双盲复算：盲算触顶、按无法复算记时（_limit_text 那一路），把盲算交回的理由（渲染后的正文，已经过遮罩）截一段带进原因（「盲算已达每项最多查询次数（1 次）；盲算交回的理由：…」），审批卡、缺口说明上看得到它查到了什么，没有理由的照旧。原值所在的格子落在「查询区间里这张表没有数据」的列上时不派盲算、按无法复算记；盲算交回的格子落在这样的列上时不判一致、按无法复算记；原因都写「查询区间里这张表没有数据（…）」

2026-10-20 10:33:34 +08:00

human.py

子工作流里的反方审稿按全局 id 记它审的报告：审稿记录和工件上的报告写这次运行里的 id（「sub/write」，同 report.checked、报告文档，第 1 波 B1 修过报告节点同样的问题），证据面板连子工作流里的审稿一起认（_Sealed.nodes_of nested），点开子图里那份报告的句子认得出审它的那次审稿；审批卡上的报告按全局 id 记，打开证据面板、审批质询对得上；单句面板的报告名写「子工作流 › 报告」，不写内部 id

2026-10-19 09:08:45 +08:00

io.py

口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 id + 列认（cell()、按位置取的格、Agent 经 cite_fields 交来的字段，按列，同一条查询里有数的列不受影响；转抄的指标照抄），给指标标 no_data 并写明原因，清单注明「这段时间表里没有数据：不要当成 0 解读」，发一条 metric_no_data；有出具契约的成果按缺口降档（契约收来的指标，和报告直接引用的这样的格）。写作目录里这样的指标、查询格子里这样的列都写清，写作规则加一句（目录里有这样的项才加）。证据面板的指标标「区间内无数据」并写明原因，查询步骤列出这几列。复核把 query_no_data、metric_no_data 记成缺口（DEGRADED），归进新的 REBUILD：是缺口、却值得换一张有这段数据的表重建一次，should_retry 和 chat/turn.retry_after_review 都认，问数据据此给出「按复核重来」的指示

2026-10-20 10:29:01 +08:00

knowledge.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

llm.py

分析能力入口（二）：五个 agent 分析工具（analysis_decompose / baseline / trend / differ / comparable，名字取 contract.TOOL_NAMES），参数只有「算什么」（引用本节点查过的结果 Q3、列的角色、期次、总数 headline、下钻 parent、度量叫法、在验证什么），没有阈值参数；五个工具共用一份「分析方法」说明（ToolSpec 新增 guide：方法说明 + 去重用的 id，register / build_tools 透传进工具的 metadata），Agent 节点、协作成员绑了任一分析工具就接在 Skill 后面注入 system，同一份只注入一次，模型调用节点不注入。Agent 建工具时经 ToolContext.extra 交一个本节点的分析容器（app/tools/analysis.py 的 AnalysisScope），每次查询记台账时往里放一份输入快照（编号和「【证据 Qn】」同一个），分析结论落成 analysis_result 工件、台账记 contract.ledger_entry（带 call_id），交回模型「【分析 An】」加判定语、判定标准、关键数、附带说明、算不了的原因、结果表前几段；tool.end 带 analysis_artifact；下钻按 An 取本节点的结论；调用写错（contract.CallError，含这个节点的分析次数用完 max_calls）作为工具错误交回、不记台账、不占编号；算不了照样记结论并发一条 analysis_refused。编号只在记台账时放进容器，审批恢复重放时分析不再执行、编号不错位。遮罩列按证据面板同一个函数认（数据源设的、按 SQL 认出改了名字的），遮罩运行交给算子的是遮过的快照。阈值读发起时的快照，没有就现读设置；运行期依赖给运行当天、按运行目录视图读的目录、剖析事实、现查表范围的探查（W1-a 的 make_prober，还没有时不给）。协作成员同样注入方法、同样编号（协作节点不记台账）。使用者问数据的白名单加上五个分析工具和分析卡；调用工具节点调分析工具在画布上就报错（analysis.tool_node）。能力登记不把它们当查询（is_platform_query 不认）

2026-10-21 13:02:30 +08:00

merge.py

合并查询的警告带上结构化字段：键类型不一致带 keys、detail，行数放大带 rows、input、input_rows、duplicates，结果截断带 rows、max_rows，随运行日志一起发出，界面读字段，不再从中文原话里解析

2026-10-04 02:17:32 +08:00

metrics.py

分析能力入口（七）：按 W1-a 算子库的实际接口对齐。工具参数名以算子为准：差异检验的均值是 mean / sd / n 或 sum / sumsq / n，逐行是 value，可选 pairs / reference；可比性检查另收可选的 measure、grain（不收 label）；分析卡的参数校验用同一份定义，运行当天、目录事实、下钻层数由算子自己记，分析项里写了不收。交给算子的输入是工件库里那份查询快照原样（含 SQL 检查结果 checks、「查询区间里这张表没有数据」no_data、查询当时记下的遮罩），加上出处和遮罩列（数据源设的、按 SQL 认出改了名字的、遮罩运行里查询时就遮掉的），合并查询写明 sqlite 方言；agent 的容器在分析前把每份换成完整快照（每份只取回一次）。探查器改用 analysis.make_prober(数据源名 → 按运行固定版本解析出的源，coverage.Cache 一个节点里共用)，剖析事实一律用 analysis.probe.profile_facts（查询工具的覆盖检查也改用它，原来那段同样的取法删掉）。分析次数用完交回 analysis.exhausted 的那句；口径卡的可比性写成 {工件, 判定码, 判定语, analysis.comparable_reasons 拆出的原因}，删掉自己拆原因的那段。加真算子的端到端测试：agent 变化拆解并下钻（父结论按内容哈希认）、审批恢复重放不再算、分析卡的波动基线和变化拆解（本期完整按现查的表范围判）、口径卡跑真可比性检查（可比、有条件可比带原因），每份结论都按封存的工件复算、逐字段相同

2026-10-21 13:27:12 +08:00

multi.py

分析能力入口（二）：五个 agent 分析工具（analysis_decompose / baseline / trend / differ / comparable，名字取 contract.TOOL_NAMES），参数只有「算什么」（引用本节点查过的结果 Q3、列的角色、期次、总数 headline、下钻 parent、度量叫法、在验证什么），没有阈值参数；五个工具共用一份「分析方法」说明（ToolSpec 新增 guide：方法说明 + 去重用的 id，register / build_tools 透传进工具的 metadata），Agent 节点、协作成员绑了任一分析工具就接在 Skill 后面注入 system，同一份只注入一次，模型调用节点不注入。Agent 建工具时经 ToolContext.extra 交一个本节点的分析容器（app/tools/analysis.py 的 AnalysisScope），每次查询记台账时往里放一份输入快照（编号和「【证据 Qn】」同一个），分析结论落成 analysis_result 工件、台账记 contract.ledger_entry（带 call_id），交回模型「【分析 An】」加判定语、判定标准、关键数、附带说明、算不了的原因、结果表前几段；tool.end 带 analysis_artifact；下钻按 An 取本节点的结论；调用写错（contract.CallError，含这个节点的分析次数用完 max_calls）作为工具错误交回、不记台账、不占编号；算不了照样记结论并发一条 analysis_refused。编号只在记台账时放进容器，审批恢复重放时分析不再执行、编号不错位。遮罩列按证据面板同一个函数认（数据源设的、按 SQL 认出改了名字的），遮罩运行交给算子的是遮过的快照。阈值读发起时的快照，没有就现读设置；运行期依赖给运行当天、按运行目录视图读的目录、剖析事实、现查表范围的探查（W1-a 的 make_prober，还没有时不给）。协作成员同样注入方法、同样编号（协作节点不记台账）。使用者问数据的白名单加上五个分析工具和分析卡；调用工具节点调分析工具在画布上就报错（analysis.tool_node）。能力登记不把它们当查询（is_platform_query 不认）

2026-10-21 13:02:30 +08:00

report.py

口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 id + 列认（cell()、按位置取的格、Agent 经 cite_fields 交来的字段，按列，同一条查询里有数的列不受影响；转抄的指标照抄），给指标标 no_data 并写明原因，清单注明「这段时间表里没有数据：不要当成 0 解读」，发一条 metric_no_data；有出具契约的成果按缺口降档（契约收来的指标，和报告直接引用的这样的格）。写作目录里这样的指标、查询格子里这样的列都写清，写作规则加一句（目录里有这样的项才加）。证据面板的指标标「区间内无数据」并写明原因，查询步骤列出这几列。复核把 query_no_data、metric_no_data 记成缺口（DEGRADED），归进新的 REBUILD：是缺口、却值得换一张有这段数据的表重建一次，should_retry 和 chat/turn.retry_after_review 都认，问数据据此给出「按复核重来」的指示

2026-10-20 10:29:01 +08:00

tools.py

合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算）

2026-10-19 12:21:38 +08:00