AgentLab

mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 05:51:57 +00:00

Files

T

ThearchyHelios bfc0e88e9a 数字推演复核修正（第 2 轮，后端）：整个指标推演不了的不改动也照实说，完整值找不回来的数组排除行后不再报「无变化」

- 用到了遮罩列、最外层输入还原不了（容器的完整值找不回来、所在的查询快照读不出来）、卡上没记全输入的指标，以前不改动时
  报 unchanged（界面写「无变化」），输入照样可改、行照样可勾，改了、勾了才说推演不了。现在不论有没有改动都交回
  unsupported / masked 和原因，所有输入 editable 为假、不给 row_span，unsupported 里另有一条 input 为空的（界面据此只写
  原因），之后只列卡住它的输入。同一格既遮着、快照又读不出来时说遮罩
- 下游口径卡改看重算新给的 maybe_changed（改动碰到了某个指标，它又变了或说不准）：推演不了的指标 changed 一律为空，
  只看 changed 分不出「什么都没改」，一打开就会把下游标成可能受影响
- agent 数组字段的完整值找不回来（节点产出不在、被改过，另存的完整值读不出来）时，排除它行段里的行以前因为值为空被忽略，
  指标报「无变化」、报告引用处报「不受影响」。现在算碰到了它（excluded_rows 照记，输入 changed 为真、new 为空），
  完整值找不回来的输入一律不给行段
- 决定取哪一格的容器（cell(nodes.q, len(vars.res.rows) - 1, …) 里的 vars.res.rows）少了行时，以前拿卡上记的那一格算出
  「无变化」，现在说不准（unsupported）
- 补测试：四类整个推演不了的指标不改动、改动后都照实说（单元和真跑）；数组完整值找不回来时排除行段内一行（单元和真跑，
  含报告引用处）；查询当时记下、跑完又从数据源去掉的遮罩（推演和勾行接口）；写输入的节点和快照在同一条事件里交回
  （合并查询的边界）；给了新值的输入不再说不准；数组只认行段内被排除的行；同一份快照交回两次按第一次；读得出来却不是
  查询结果的快照；嵌在里面、读不出来的那一格不进代入式。逐个做过变异：复核列出的四处、第 1 轮漏掉的三处和这次新加的
  判断改掉后都变红

2026-10-05 06:49:33 +08:00

api

数字推演复核修正（第 2 轮，后端）：整个指标推演不了的不改动也照实说，完整值找不回来的数组排除行后不再报「无变化」

2026-10-05 06:49:33 +08:00

core

往停下的运行里追加事件统一走 engine/run_append.py 的 append_events(run_id, items, *, require, seal=None)：审批质询要在运行停在审批时把问答写进运行、随运行结束一起封存，探索运行封存之后还要能追加批注。事件流是封存的依据，清单按 seq 排序、run_events 的 (run_id, seq) 又不唯一，撞号会让封存核对时对时不对，所以照 _append_judged 的做法：同一运行在进程内排队，读 last_seq 后从 bus 接号（另取库里实际的最大序号兜底，last_seq 被别处写小了也不撞号），写事件和条件更新 last_seq 在同一事务里——interrupted 要求运行仍停在审批，sealed 要求仍是终态且封存没变，任一条落空就回滚、返回 None，调用方据此说明未写入运行记录；提交之后才广播。sealed 的事件带 post_seal: true；运行记录上的封存若早于最后一条结束事件（继续运行后又结束、还没重新封存的那一下），不算现在的封存，不追加，免得事件被接下来的封存收进去；调用方可传 seal 固定开始时看到的封存。事件类型加 approval.inquiry。测试用人工审批停住的运行：追加两条后批准、封存，verify 通过且改动追加的事件 verify 就对不上；恢复、继续运行、重新封存、别处写入抢在中间时都不写、last_seq 不动；连续和并发追加序号严格递增、全流无重复；恢复后前面的节点不重复执行，Agent 里批过的工具不重复执行（含升级前写下的断点）

2026-10-05 00:14:40 +08:00

data

SQL 语义复核修正（第 2 轮）：CTE、子查询起的名字不再进比较，条件里的子查询选出来的列名也不算；派生来源按位置编号，编号错开时再按不写编号的写法配一遍

2026-10-05 02:37:33 +08:00

运行记下选项快照和来源：runs 加 options（JSON，默认 {}）和 schedule_id（可空，建索引）两列。后面的核查设置要在发起时定下、整次运行沿用，审批停下期间改了设置，恢复和重放仍按发起时的（同 approval_default 的道理）；定时任务要能找回自己发起的运行。RunManager.start 收 options、schedule_id 并落库，选项先深拷一份，调用方之后改自己的 dict 不影响快照；选项非空时写进每一段的 run.started（进封存范围），为空时 run.started 和以前逐字相同；恢复、继续运行照运行记录沿用，节点从 RunContext.extra 的 run_options 读同一份拷贝。RunOut 带 schedule_id，GET /api/runs 可按 schedule_id 筛，launch_run 原样往下交。旧库走 _COLUMN_MIGRATIONS 补列，存量运行回填 {} 和 NULL；create_all 不碰已有的表，新列的索引另由 _INDEX_MIGRATIONS 补建，索引名和新库 create_all 建出来的相同

2026-10-05 00:07:07 +08:00