yilunjiang/AgentLab
1
0
Fork 0
mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 04:21:57 +00:00
Code Issues Packages Projects Releases Wiki Activity
1,101 Commits 4 Branches 0 Tags
7e95703a94dea3a5f98265c601e07aa50b8b7df7
Commit Graph

13 Commits

Author SHA1 Message Date
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 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 aee237f457 按行号取多行查询里的一格，重跑、核对时行序不定的照实标出来：sql_semantics.ordered / row_stable 认这一行重跑时还是不是同一行（最外层带 ORDER BY 的按位置认，一定只出一行的第 0 行认得住，别的行序不定）。口径账本的比对记下 ordered、one_row，指标标签按「同一行」认来自口径只在行认得住时成立，行序不定的标相关、写明原因；口径召回里两版都按行号取一格、查询又没有 ORDER BY 的指标记行序不定（changed 为空），召回待办上写「行序不定」，不按位置硬比；对账的多行对齐每一组先核对那一行的维度就是它，重跑时缺了一行、多出一行错位的记空值，不拿别的维度的数冒充 2026-10-19 10:01:05 +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 d4f1ba8dd4 给评测留一个按引用的列投影的入口（referenced_of），顺手折行、补模块说明 
- ledger/match.referenced_of(sealed)：这次运行封存的报告引用了哪条查询的哪几列，正好是 compare_queries 的 referenced。
  评测逐题比 SQL（eval/score.sql_match，另一组在改）传它，就和账本一样按引用的列投影，不必自己再拼一遍。compute 和它
  共用读指标集的那一段（_card_loader）。
- data/sql_semantics 模块说明的「几处共用这里」补上模板绑定、按引用的列投影、同一个形状三处。
- 本轮几处新代码折到 120 列以内（只换行，不改逻辑）。

测试：tests/test_ledger_projection.py 的整题等价那条另核 referenced_of 交回的就是被引用的那一列。
 2026-10-17 12:22:48 +08:00
ThearchyHelios 12439b5305 差异说明投影之后再说；日期条件写在 LEFT JOIN 的 ON 里的说清楚 
选择的列不同时，差异说明整段退回「两条 SQL 的写法不同，未能归纳成具体差异」（真实验收 E2 的兜底比例 45%）：只差在选择
列表上时一条具体说法都没有；多选的列里有 sqlglot 不认识的函数（SQLite 的 printf 这类）时整段不算简单形状，WHERE 里
真实的差别也不写。

- ledger/match：按引用的列投影过、仍没证明的候选，差在哪用投影之后那次比较的结果；答案多选了列的，在最前面写一句
  「这次多查了 N 列，不影响这个数」（aspect=projection），然后照常说条件、时间、聚合上的不同。E1 的差异类型不数这一句。
- sql_semantics 的 _Explainer._left_on_times：两边来源一样、只差在一个 LEFT JOIN 的 ON 里的时间条件时，说「这次用 LEFT
  JOIN 关联 orders 表时只关联 … 的行，口径没有这个条件」「…时对 paid_at 的条件是 …，口径是 …」「…时按 paid_at 筛时间，
  口径按 created_at」。说得准才说：差的每个条件都是只涉及可空一侧那张表的时间条件、那张表只出现在结果里（WHERE、
  HAVING、别的连接没用到，SELECT 列表用到了）、同一列的按取值算过确实不同、单边的不是恒为真；套着日期函数认不准的、
  反连接、结果里没用到可空一侧的、不是时间条件的照实兜底。aspect 写 join（说的是关联条件），双盲复算不会把它当业务日期
  写进数据目录。只改说明，判等价不变。

测试：tests/test_ledger_projection.py（没证明时先说多查了几列、再说少了 status 条件，不再兜底）、
tests/test_sql_left_on_times.py（四种说得清的、在虚构库上结果确实不同；四种说不清的照实兜底；判等价的结论不变）。
去掉这两处改动再跑，各自的用例失败（2 条、8 条）。
 2026-10-17 11:49:31 +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 7e8d3a9c49 口径比对的 drain（测试用）只等还没做完的任务，做完还留在登记里的顺手去掉 
为什么：并行跑全量测试时偶发过 drain 原地空转（faulthandler 抓到主线程一直在 drain 里，每轮 gather 都立刻返回），四次全量里挂了两次。这一波起整题等价的探索运行比完会接着自动出具，后台任务的进出更密。改成只 gather 没做完的、把做完的从登记里去掉之后，连跑两次全量都没再出现。drain 只给测试用，服务里不调它；没能在单进程里复现出根因，照实记进遗留。
 2026-10-16 17:46:20 +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 0a3c45eb97 口径账本：合并查询的格照实写为什么没比对；账本测试按用例各用一个数据源隔开 
- ledger/match.py：合并查询的快照不和口径比（它的数来自各个输入的查询），引用了它的格以前标成「没有比对记录」，现在写明
  「合并查询的格不和口径比对」；它不进工件的 queries，统计不数它。
- 测试：账本的用例以前在开头把别的用例发布的版本一律退役，好让候选口径只剩自己的——并行时会碰到同一个进程里别的测试模块的
  数据。改成每个用例一个名字不同的数据源（候选口径本来就按数据源预筛），不动别人的数据。补启动补比随调度开关起后台任务的用例。
 2026-10-16 14:23:41 +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