46 Commits

Author	SHA1	Message	Date
ThearchyHelios	6263725c2a	降档时报告页顶部写明出具档位和原因（B5）：出具声明和 issuance 事件另带结构化的 sql_checks（哪次查询、问题、受影响的引用、对应的缺口），证据页签在报告上方放出具横幅，SQL 检查导致的降档单列一块写在显眼处、不在其余缺口里重复；不是完整出具时「N 个数字都有出处」不再画成绿色	2026-10-04 02:33:15 +08:00
ThearchyHelios	31531925a9	写作指引说清 [[see:]] 只放句末、码值写含义（A4、B4）：写作规则后面加两条，依据标记渲染后不显示，写进句子中间会留下「以 为依据」这样的断句；涉及码值时写含义（「作废记录」），不写码值本身，数字核对不放宽。组装报告时认出拿得准的句中写法（「以 [[see:…]] 为」「根据、按照、基于、参见、详见 [[see:…]]」）记 inline_see，交回写作者重写，重写不好也不判失败；助手写报告节点的指引同样写明这两条	2026-10-04 02:24:49 +08:00
ThearchyHelios	9c8bed2f1b	合并查询的警告带上结构化字段：键类型不一致带 keys、detail，行数放大带 rows、input、input_rows、duplicates，结果截断带 rows、max_rows，随运行日志一起发出，界面读字段，不再从中文原话里解析	2026-10-04 02:17:32 +08:00
ThearchyHelios	2c160f0ac9	运行时间线看得到单条查询的 SQL 检查：调用工具节点、Agent 和协作团队里的查库调用，tool.end 事件单独带上这次查询的检查结果（只留给人看的字段）；preview 只有结果的前一截，检查结果以前通常被截掉	2026-10-04 02:17:32 +08:00
ThearchyHelios	f1d4582d4f	报告直接引用没通过 SQL 检查的查询时出具降档：报告里引用的查询格子、表格和依据（含合并查询的输入）有错误级检查就记缺口；按出问题的那条查询归并，同一条查询算出几个指标、又被引用时只记一句并列出受影响的引用；运行日志也按查询归并成一行，带上受影响的指标、问题、检查结果、来源节点和要改的栏；写作目录里给这些查询标「存疑」	2026-10-04 01:52:24 +08:00
ThearchyHelios	787b2304dc	指标经过合并查询也认得出来源查询的 SQL 检查问题：合并快照没有自己的 checks，顺着 inputs 往下找，源库一对多重复计算的数不再经一次合并就完整出具	2026-10-03 10:40:47 +08:00
ThearchyHelios	84bf484c08	合入数据目录阶段 2B：基于数据目录的 SQL 检查——七条规则按依据状态定级，接入助手自查、发布门禁和运行时，出错的来源查询使指标降档 ... # Conflicts: # backend/app/api/evidence.py	2026-10-03 10:37:31 +08:00
ThearchyHelios	7f07fc370a	数据目录阶段 2B：运行时接上 SQL 检查——查询结果和快照带 checks、证据接口的查询步骤带上，契约指标的来源查询有 error 时出具降档	2026-10-03 10:32:54 +08:00
ThearchyHelios	98ebba384f	合入数据目录阶段 3：合并查询节点——跨库按键合并，截断输入拒绝，类型不一致与行数放大告警，证据可下钻到两边原始查询	2026-10-03 10:27:16 +08:00
ThearchyHelios	1f8c180703	合并查询节点（一）：新增 merge 节点和执行器——几次查询的完整快照落进内存 SQLite 按键合并，结果存成同形的查询快照，截断的输入拒绝、键类型不一致和行数放大给警告，并记下逐格来历	2026-10-03 09:27:48 +08:00
ThearchyHelios	3e1f8b2591	数据目录阶段 0：截断的查询结果整组拿来算的指标标为不完整、出具降档，报告整表带截断说明，恰好取满不再误报截断	2026-10-03 09:26:22 +08:00
ThearchyHelios	8059cd5147	Excel 导入改造期 1：止血与版本底座——写错的列名不再静默得 0，导入不再悄悄读错，每次上传生成不可变的版本，运行固定发起时的数据版本 ... 连接层 - 所有 SQLite 数据源关闭双引号字符串兼容（DQS），写错的双引号列名直接报错；设置失败就拒绝连接，启动时自检 - 连接缓存按数据源加版本快照分键、按源整体失效、最多 32 个；版本快照以 immutable 只读打开，建连接前核对文件哈希，并在借出连接时核对文件指纹，被改过就拒绝查询 - 结构探查遇到取不了列的视图时逐个对象重取，只跳过坏的那个并注明原因 解析（新 xlsx_scan + tabular） - 先流式扫描真实边界和版式（不信 dimension），再按边界读值，不整表进内存；按 Excel 自身上限设硬上限，并发解析最多两个 - 隐藏和深度隐藏的工作表不导入；稀疏区域、无缓存值的公式、同名工作表、DTD 拒收 - 去掉空行和两侧空列；列名表名统一规范化（新 names 模块）并保留原表头，撞名不再互相覆盖 - 前导零、超长数字按文本；千分位按数字；日期不带 T；带单位的数字文本写进回执 - 数字列混入非数字、交叉表和多块结构必须由用户决定（422），可选存空值或按原样导入（未规整）；STRICT 建表，整份在一个事务里写完 版本底座（新 table_versions、raw_store） - 每次上传写新库文件、落盘、0444，事务里写构建、导入记录、快照后才切指针；失败时旧版完整可查 - 原件按哈希存档，不提供下载，可以清除；上传源不许改连接字段、不再重新探查；手工 SQLite 源不许指向上传目录和应用自己的数据文件（按文件身份判断） - 启动时清理半成品与孤儿文件、给老上传补初始版本；被运行引用的版本不回收，发起运行与回收互斥 - 上传接口的解析移到线程池 运行固定数据版本 - 发起时把图里（含子工作流）用到的上传源的当前快照记进运行记录和 run.started，续跑、审批恢复沿用；数据源工具按固定的快照生成描述、表结构并查询 - 固定的版本没了、源被删除后同名重建，都明确报错，不改用当前版本或同名的新源；查询快照记 data_version 证据层 - 新报告记 entity_syntax: 2，[[t:明细]]、[[c:明细.金额]] 和 SQL 里不加引号的中文表名都认得，名字按 SQLite 的口径查找；老报告按原规则复核，结果不变 - 写作规则改为中文表名、字段名一律用 [[t:]] / [[c:]]；未规整的表在工具描述、写作目录和裁判摘录里标出 前端 - 上传弹窗接上导入前的决定（混合列、交叉表）和导入回执（跳过的隐藏表、类型转换、警告、原表头对照、未规整标记），上传前告知原件会保存 - 数据源卡片按 origin 认上传的表格，显示当前版本；上传的表格不再给「探查结构」	2026-10-01 13:42:04 +08:00
ThearchyHelios	bd8306bf95	结论句裁判改造：「不支持」拆成「证据相矛盾」和「证据不足」，补全交给裁判的证据，旧判定可按新规则重判 ... - 判定取值改为：支持 / 部分支持 / 证据相矛盾 / 证据不足 / 不是结论。只有证据和句子冲突才判相矛盾； 证据里没有相关信息判证据不足，并写明缺什么（比如 SQL、字段清单） - 出具判档不变松：证据相矛盾按 on_unsupported 降档或不予出具；证据不足记一条缺口，最多降档、不能判完整出具； 改造前的「证据不支持」照旧当相矛盾处理 - 补全证据摘录：表名附字段清单和类型（最多 60 个，快照不全时注明，遮罩列不列）；口径卡指标附上每个输入 取自哪次查询、哪一格，以及那次查询的 SQL；一律只读封存范围内的工件 - 理由上限从 60 字放宽到 120 字，在句子边界截断，不再截在半句中间 - 裁判模型：按需裁判也判断是否和写作模型相同、是否在价格表里，证据面板里醒目提示； 设置页没配裁判模型时写明「未单独配置，将使用助手的模型」 - 新判定带规则版本：改造前的判定在界面上标「按旧规则判定」，可以请模型按当前规则重新判断 - 界面：证据相矛盾用红色；证据不足用中性色和 ○，写明缺什么；讲方法、讲结构的句子在证据面板里直接列出 对应的 SQL 和字段清单；出具横幅、审计表、报告节点印章的计数都分开这两档 - 顺带写稳 check-publish 里一条等按钮状态的断言（并行时偶发）	2026-09-30 10:04:52 +08:00
ThearchyHelios	03c18c4d78	界面文案整改：口语改书面、术语统一、不再露出实现细节；修掉几处说错的提示；新增文案检查防回潮 ... 一、文案（前端约 1600 处，后端传到界面的约 880 处） - 术语统一：工作流层面用「运行」（继续运行、重新运行、试运行），节点和工具层面用「执行」，不再用「跑」； 总时长 / 执行时长 / 等待审批；服务端；助手；Agent；token；工作流；固定版本；模型接入；系统提示；批准 / 驳回；受管级别 - 口语改书面：取不到、没取回来、读不懂、连不上、多半、照样、兜底、揉成这类说法改成「无法 / 未能 / 失败 / 请」；去掉拟人写法 - 不再露出实现细节：界面上不写 checkpoint、同一拍、哈希（凭证处除外），不写改版历史（「以前…」「老数据」）； 报错、校验、门禁、自动修复里裸写的配置键名和枚举值换成界面上的中文标签，由新的 backend/app/engine/labels.py 统一提供； 发布弹窗里结论句的选项不再是 off / require_citation - 同一件事只留一种说法：生成阶段文案、出具档位说明、画布锁定提示各合成一份 - 去掉界面上的工业场景示例（MES、ERP、「张工」「王工」）和真实产品名，换成通用示例 二、说错的提示（都有测试证明） - 数据库测连接失败时的专用提示以前从不出现（按报错文字全等比较，永远比不上）：改为按错误类型判断，不再拼出重复的前缀 - 「设置 → 供应商」改指「设置 → 模型接入」；「在设置里建数据源」改指「数据」页 - 缺少 API Key、模型接入已停用的报错不再夹英文，写明去哪里填 - 两处原因说错（「这种引用在后续版本支持」「这一版还不支持」）改成真实原因 - 节点说明里不准确的说法改正：代码节点在 microVM 或系统沙箱中执行；报告撰写、口径卡的说明不再说过头 - 导出的证据 CSV 里两列同名，第三列改为「片段编号」 三、前后端对齐 - 前端按后端原文识别日志、报错的地方，新旧两种写法都认得（历史运行里存的是旧文字），逐条补了新旧原文的核对 - 后端交回模型的原指令放进单独的 for_model 字段，前端在解析响应时去掉，不会显示到界面上 四、检查 - 检查脚本里按原文匹配的断言改成新文案；改完会变成永远成立的反向断言逐条修正，并做了变异验证 - 新增 check-copy（静态扫描前端界面字符串和后端上界面的文案）：再出现「跑」「后端」「多半」「令牌」、 界面上的 Copilot、裸写的配置键名、半角标点等就报错；确需保留的写进 scripts/copy-allow.json 并注明理由	2026-09-30 08:05:15 +08:00
ThearchyHelios	9727c21d8d	可点击证据第四期：结论句由模型裁判；只引单元格的问数据图能发成受管 ... 一、结论句裁判 - 报告节点新增 claims: judge：写完、核对完之后，把结论句和它引用的证据摘录交给裁判模型， 判为支持 / 部分支持 / 不支持 / 不是结论，附一句理由；判定只标注，不改写正文 - 送裁判的句子按固定规则预筛：带引用的、含方向词或因果词的送去判，短句、过渡句不送 - 证据摘录：指标写名称、值和原式；查询给 SQL 前 300 字和被引用的行，被引用的列一定给到；遮罩列一律不给； 规则里写明「数字已经由系统核对过，不要复算」 - 一份报告合并成一次调用，超出句数就分批；结构化输出失败时退回 JSON 解析，再失败记为未裁判 - 裁判模型的优先级：节点上写的 > 设置里的「证据裁判模型」> Copilot 的模型；思考关闭； 和写作模型相同时给警告（等于自己审自己） - rewrite_once（默认关）：把不支持的句子和理由交回写作者只改这几句，再裁一次； 改写稿冒出原稿没有的问题就不采用，保留原稿和原来的判定 二、成本上限 - 每份报告的句数、金额、时长，探索运行每次点击的金额，全局每日金额，每一项都可以自定义，也都可以设成不限； 默认 40 句、$0.05、30 秒，每次点击 $0.01，每天 $2 - 调用前先估算，超出上限按优先级截断：先判带引用的，再判含方向词、因果词的，其余记为未裁判并写明「已到上限」； 不报错，也不让报告失败 - 每日花费按本地日期计数，持久化在设置表里；重跑同一次运行不重复计费；价格目录里没有的模型只计次数，并写明估不出金额 三、正式运行与探索运行 - 正式运行在报告节点内裁判，判定写进报告文档、随文档封存；不支持的按 on_unsupported（degrade / withhold）降档或不予出具， 裁判没跑成记缺口，不能判完整出具 - 探索运行按需裁判：POST /api/runs/{id}/evidence/judge，点开哪句判哪句；判定作为 evidence.judged 事件追加在封存之后， 标「封存后追加」，封存核对仍然一致；只读封存范围内的工件；同一句不重复判；运行在裁判期间被接着跑时不记录 - 正式运行调这个接口返回 409，写明「正式运行的裁判在节点内完成」 四、治理与自动修复 - G3 放开 judge：受管级别写 judge 必须写预算（judge.max_cost_usd，或显式写 null 表示不限） - 发布前自动修复：缺预算时给选项（默认金额 / 不限），不替人选； 从 require_citation 改成 judge 不算降低要求，judge 改回 off、withhold 放宽成 degrade 算降低要求 - Copilot 手册：受管模板可以写 judge 并带预算；问数据按需裁判，不替人打开结论句策略 五、界面 - 结论句句末放徽标：支持 ◆、部分支持 ◇、不支持 ! 整句浅底、未裁判 ?；不用表示「已核对」的绿色；n / N 也跳到不支持的句子 - 证据面板里「模型的解释」：带「模型判断 · 模型名 · 非确定」，封存后追加的另外标出； 「请模型判断这句」只在探索运行、还没判过时出现，触顶时写明已到上限和怎么调 - 出具横幅多一段结论句计数；设置页新增「证据裁判」一组（裁判模型、各项上限、今日花费），设成不限时写明费用受什么约束； 报告节点可以配 judge；运行轨迹里裁判相关的事件都有中文标题 六、门禁修正 - 引用模式下，图里没有口径卡（只引查询单元格）的，出具契约不再要求 metrics_from，受管门禁也不再要求 required： strict 加 cells 已经保证每个数都点得开、对不上就不予出具；有口径卡的照旧要求。 以前问数据的图怎么都发不成受管，Copilot 补上契约也会被判「冒出新的问题」作废	2026-09-29 11:10:53 +08:00
ThearchyHelios	d071bf119f	可点击证据第三期：表名字段名和引文也点得开、可疑实体与结论句、受管门禁 G1–G5、证据审计导出 ... 一、表结构、实体与引文 - 数据源工具查库时顺带存一份表结构快照（schema_snapshot），和查询快照一起进台账、进封存； 台账里的查询记下 SQL 用到的表 - 报告里的表名、字段名可以点：反引号里的名字一律核对，正文里的裸名字只在明显是标识符时才自动链接， 常见英文单词不链接；点开看到它出现在哪次查询、类型、所属的表，快照被截断时写明 - 找不到的名字标成可疑实体：在快照、SQL、结果列里都没有的记「可能是编造的名字」并给出最接近的 3 个； 快照被截断、核对不了的记「核对不了」，不冤枉成编造 - 检索引文 [[q:K1|原文]]：原文在检索快照的命中片段里逐字出现（空白归一化后）才算有出处，点开高亮原文位置 - 自动链接的名字不算句子的引用，只有写作者写的引用才算 二、结论句与出具 - 报告节点新增 claims：off（默认，保持原样）或 require_citation（没有引用的结论句计入缺口） - 受管级别的正式运行里，可疑实体和没有引用的结论句按「有缺口」降档，不拦截；探索运行和已发布级别只标注 - 契约的 claims 和报告节点的设置取更严的那个；受管正式运行里写 ignore 也按降档处理，并给出警告 - 出具横幅除了数字，也写出可疑实体和没有引用的结论句 三、受管门禁 G1–G5（只看图和配置） - G1 带契约的出口，成果字段的文字只能来自报告撰写节点 - G2 模型写的文字不绕过报告撰写节点直接流进出口 - G3 报告撰写节点写明 numbers: strict、on_violation: fail、claims: require_citation - G4 口径卡的输入不来自计算角色的沙箱代码 - G5 给口径卡供数的 agent 配 output_schema 并开 cite_fields - 受管级别是错误、挡住发布；已发布级别只给警告；已经发布的版本照常运行，下次发布时按新规则检查 - 每条规则都接进发布前自动修复（一键修复 / 给选项 / 交给 Copilot）；禁止的改动补上关 cite_fields、 删 output_schema、放宽契约 claims；Copilot 兜底不许自己把代码节点标成 source、不许放宽报告节点 - 发布弹窗里选「交给 Copilot」时明确写「正在交给 Copilot」 四、旧运行与审计 - 没有契约的旧答案：数字和已封存的查询单元格、口径卡值按数值比对，每个数最多 3 个候选， 默认折叠，写明「猜测的来源，不能当证据」 - 有契约的旧运行：候选只从已封存的口径卡里找，人为插进工件表的行不当证据 - 证据审计：GET /api/runs/{id}/evidence/audit 按「无证据 / 可疑实体 / 有出处 / 旧运行猜测」分组， 可导出 JSON 和 CSV（带封存状态）；记录页和画布上的报告节点显示「有出处 N · 无证据 M」 五、SQL 守卫修正（安全） - 去注释改成单遍扫描，认得字符串和各方言的引号（单引号转义、MySQL 反斜杠与 #、PostgreSQL 的 $$ 与嵌套注释、 Oracle 的 q'[…]'、SQLite 的方括号）；以前字符串里的 -- 会被当成注释，SELECT '--'; DROP … 这类写法能骗过多语句拦截 - 看不到服务器设置时每种读法都扫一遍，读法之间切分不一致就拒绝，任何一种读法是写操作就按写操作处理 - 执行查询和工具危险判定都按数据源的方言检查 六、其他 - 修掉检查脚本里画布检查的一处竞态，并行估时按实测更新	2026-09-29 05:26:34 +08:00
ThearchyHelios	fcdcc30d4e	可点击证据第二期：取数链路打通、问数据的答案逐段可点；发布前自动修复 ... 一、可点击证据第二期 取数链路 - 智能体、工具节点、代码节点、知识检索取数时都记进证据台账；报告目录按台账编出 Q1… / K1… - 报告可以引用快照里的一格（[[v:Q1.r0.gmv]]），也可以由系统从快照生成整张表（[[table:Q1 cols=… rows=0-4]]）， 表里每一格都是可点的片段；取值一律以快照为准，取回快照时复验哈希 - 口径卡表达式新增 cell(x, row, column)，lineage 精确到单元格 - 智能体开 cite_fields（配合 output_schema）后，循环结束做一次结构化抽取，每个字段标出取自哪次查询的哪一格， 再到快照里核对：一致记 verified；不一致以快照为准并告警；查不到的记为空值，永远不兜底成 0 - 代码节点新增 evidence_role（source / compute）和 code_sha；沙箱算出来的数不能被报告直接引用，要进口径卡 - 查询快照记下列类型，文本列按文本渲染（年份 "2026" 不再显示成「2,026」） - 升级前发起的运行（停在审批上的）一律走旧逻辑：新的 task 只追加在循环之后，恢复时不会错号 证据接口与面板 - 片段链接上查询步骤：SQL、被引用的行加前后各 2 行、高亮到格；数据源可设 mask_columns 遮罩列， 遮罩在查询时记进快照，数据源事后改名或删除也照样遮罩（在有身份体系之前，遮罩只减少暴露，不是安全边界） - 输入来源写明核对结果（与快照一致 / 模型报的值和快照不一致 / 没查到记为空）；口径卡缺输入时也给出完整的链 - 受管出具要在契约里声明 cells 才能引用单元格；受管与否记在所钉版本上，改画布不再让受管版本的正式运行降级 - 口径卡可以用 caliber_from 钉住另一个已发布工作流里的口径卡，上游有新版本时按 upgrade_policy 处置， 和子工作流同一套规则；子工作流节点也补上了升版处置的配置项 Copilot、校验与报错 - 问数据的答案里有数字时，搭 input → 智能体 → 报告 → 出口，报告直接引用查过的单元格 - 写 SQL 前核对数据源的表结构，SQL 里出现表结构里没有的列会被打回 - 不再搭「智能体文字 → 转换节点解析 JSON」这种图；转换节点的 JSON 报错分清是上游模型写坏了、 模板里裸插了模型文字（给出 | json 的改法），还是模板本身写错了 - 工具节点遇到「查询失败」「SQL 被拒绝」判为失败；发起运行前检查绑定的工具是否存在，不存在时直接拒绝并给出入口 二、发布前自动修复 - 问题带上机器编号（code）和修复 id；新增只读接口 POST /api/workflows/{id}/publish-check 和 /autofix - 修复分三类：答案唯一、不降低要求的一键修复；要人拿主意的给选项（不替人选）；结构性问题交给 Copilot - 一律先预览，不自动保存、不自动发布；删节点、删契约、放宽审批、关掉 strict、改级别等降低要求的改动一律拒绝， Copilot 的方案也要过这一关；应用后重跑检查，错误必须变少且不能冒出新的 - 发布弹窗打开就先检查；问题面板新增「发布前检查」，平时就能看到、就地修掉 - 门禁修正：契约有 report_from 时不再要求 narrative（模板⑨可以发成受管）；全图默认审批为「全部放行」时同样拦下 - 修掉画布保存会抹掉全图默认（defaults）的老问题：以前任何一次保存都会把它清空，审批 always 因此被悄悄放宽 验证（沙箱）：tsc 干净，生产构建通过，pytest 2268 passed（两遍），check-all 17 项检查、3915 项全过 （新增 check-publish）；关键行为做了变异验证、全部抓到。	2026-09-28 21:20:04 +08:00
ThearchyHelios	62aac187d8	工具审批三档、智能体护栏取代固定 12 步、检查脚本分道并行 ... MCP / 自定义工具的审批三档（tools/trust.py） - 平台看不出这两类工具做什么，以前审批关卡一律当它们安全、照跑不误。现在默认每次调用都等审批； 工具页可以逐个改成「始终允许 · 门控把关」或「始终允许」，审批卡上的「始终允许」等于前者 - 门控把关：每次调用先由门控模型审一遍工具说明、参数和节点任务；判可疑、出错、超时、答不成格式， 一律交还给人，不会变成放行。判定包进 checkpoint，审批恢复重放时不再问一遍 - agent 节点、工具节点、协作团队三处关卡都接上；团队成员停不下来等人，门控没放行的调用不执行 - 每次运行在发起时快照档位（runs.tool_trust），恢复和接着跑沿用同一份；正式运行不看档位，一律等审批； 升级前发起的运行照旧不问——它们可能正停在某个审批上，多问一次答复就会对错号 - 接口：GET /api/tools 带 trust / trust_key，PUT /api/tools/trust；设置新增门控模型；新事件 tool.gated - 界面：工具页三选一、审批卡「始终允许」、设置页门控模型、运行记录解码 tool.gated； 顺手修了 MCP 工具详情 404、工具审批被驳回却显示成放行 智能体护栏（engine/guards.py），取代固定的「最多 12 步」 - 步数只留兜底：默认 100，设置里可改；以前画布自动写进节点的 12 按「没填」处理 - 同一个工具、同样的参数第二次不再执行，把上次的结果交还给它；连续 3 步拿不到新信息就收尾 - 每个节点的令牌预算（默认 200 万）和金额预算（默认不限），都可以在设置里改成不限 - 上下文用到窗口的 60% 先压缩早期的工具结果，到 85% 就收尾；临近任何一个上限先提醒模型一次 - 下游结构化校验失败时写明是上游哪个 agent 提前收了尾；复核信号带上收尾原因， 问数据页只在真是步数用满时才给「放宽步数重跑」 - 上限在发起时快照（runs.agent_limits）；升级前发起的运行一字不改走旧逻辑 检查脚本 - check-all 默认 4 道并行：量时间最多的两项互不重叠；并行时没过的最后单独重跑一遍，重跑才过的 单列成「偶发」。16 项全量从约 21 分钟降到约 7 分钟（加上一次重跑约 10 分钟）；--lanes 1 回到串行 顺带修的 - 设置接口里的 limits 改为只读：库里存着旧版设置页写进去的一份（max_agent_steps: 25），从不生效， 却盖住了真实上限，问数据页照着错的数许诺 - test_kb 里嵌入模型那条测试不再真连 api.openai.com（代理慢时一条要等近 4 分钟） - check-stream 读滚动容器前先等它挂上，并行跑时不再偶发 验证（沙箱）：tsc 干净，生产构建通过，pytest 1655 passed（两遍），check-all 16 项检查、3562 项全过； 新增后端测试 53 条，关键逻辑做了 22 处变异验证、全部抓到。	2026-09-28 11:47:45 +08:00
ThearchyHelios	e4f2693918	可点击证据第一期：报告里的每个数字都点得开出处 ... 「引用即渲染」：写报告的模型只写引用标记（[[m:指标id]]、[[i:输入字段]]、[[see:…]]），数值由系统按口径卡 填进去，每个数字都挂着一条能复算的证据链。本期是数字层闭环；实体、结论句的概率性证据放在后续几期。 内核（engine/evidence.py，口径卡、出具契约、表达式等） - 口径卡记录每个指标的来源：原式、代入式（每个输入写成「值 ← 路径」）、复算结果、口径与版本 - 出具契约的数值匹配改为按位置标注；同一个值有几个出处时记为「出处不唯一」并列出候选，不再随便挑一个 - 证据 id 由内容派生，事后对不上就是被改过；零值、结构性数字（列表序号、代码块标签）单独处理 - 口径卡新增 on_missing：缺输入时默认仍是整个节点失败，可以改成记为空值、交给契约判档 报告撰写节点（report）与引用模式的出具契约 - 流式生成时 token 里就是真实数字，不会漏出原始标记；裸数字、不存在的引用当场判违规，交回去重写 （max_repairs，默认 1 次）；仍不过时按 on_violation 失败（正式运行默认）或把违规标在报告里（探索运行默认） - report.checked 事件记下核对结果，落在封存范围内；fail 模式下仍不过时带 failed，运行记录里画成失败 - 出具契约写了 report_from 就按引用核对：取回文档时复验哈希，独立重算一遍，全部带引用才判完整出具 - 成果字段逐字等于报告正文时标注 _evidence；复核只能加说明，不能改写带证据的答案（前后端各拦一道） 证据接口 - GET /api/runs/{id}/evidence 返回证据图；GET …/evidence/segments/{id} 返回一个片段的证据链 - 只认封存范围内的事件能追到的工件，不读 artifacts 表；封存被改过时不把任何一项标成已封存 - 没有报告的旧运行降级为 none 或 legacy_contract 界面 - EvidenceDoc 按块、句、片段渲染报告，片段是和正文一样的按钮；整份报告只占一个 Tab 位， ←/→ 在片段间移动、↑/↓ 按句、n/N 跳到下一处「无证据」、Enter 打开面板、Esc 关闭并把焦点还回去 - EvidencePanel：宽屏侧边、窄屏底部抽屉、360px 画布右栏里栏内展开；显示指标步骤、代入式、复算结果、 封存状态。正文不是封存的那份报告时明确说出来，不拿别的报告的封存画绿 - 出具横幅多一行「N/N 数字有出处 · 无证据 M」和「定位下一处」；没有 _evidence 的旧回答渲染一字不差 - 画布认得报告撰写节点；Copilot 手册补上口径卡、报告节点、出具契约的写法；新增模板「⑨ 可追溯周报」 验证（沙箱）：tsc 干净，生产构建通过，pytest 1601 passed，check-all 16 项检查全绿（新增 check-evidence）。	2026-09-28 11:47:23 +08:00
ThearchyHelios	b418c0d951	最终验收：148 项逐条复核（原审查 142 条 + 平台问题 6 条），返工后 145 项解决 ... 四组验收员拿审查原文在沙箱里逐条复现：133 项已解决、15 项部分解决、没有未解决或回退的； 另发现 10 个新问题。按归属返工后，剩 3 项低严重度：MCP / 自定义工具的危险标记（待用户拍板）、 选中环与运行态同色（需跨三处协调改）、「接着跑」这个说法是否更换（多处引用原文，暂留）。 这次返工改了 - 右栏：老运行没有 active_ms 时执行时长改按航迹算，不再显示最后一段的「22 ms」；循环出口行不再差一； 取消在一轮中途时泳道脚注不写「0 ms」；分支、循环出口显示 case 的说明而不是 key； 展开已完成轮次不再误报「N 条新进展」；旧数据里已完成的模型调用不再一律标成「已取消」 - 后端：跳过事件带节点名和类型；restore 版本时把已发布 / 受管退回草稿；只是打开旧会话不再把它顶到最前、 标成「刚刚」；协作团队全程没有成员交付成果、调度者却判完成时按失败或降档处理，不再当成功交付 - 画布：循环体有「循环体 · 最多 N 轮」的底框，出口标签不再被自己的走线穿过；运行中校验角标退让； 768 宽下工具栏不溢出；运行被拦时点名是哪个节点；正式运行弹层写明以谁的名义发起 - 问数据：离线时能力条不把「没取回来」说成 0；窄屏下会话列表收起；check-chat 在零点前后不再误报 - 公共层：FastAPI 422 校验错误翻成中文，不再把英文原文透给用户 验证（沙箱）：tsc 干净，pytest 878 passed（两遍），check-all 15 项检查全绿。	2026-09-28 02:42:40 +08:00
ThearchyHelios	587bf7e27c	第三波前两批：六个「看着成功其实没干活」的平台漏洞堵上，记录页能回放，管理页与画布收尾 ... 起因是一次探索运行：Copilot 改节点时把工具绑定整份抹掉，agent 没有工具只能写「假设调用」， 校验节点的自动修复编出 total_count=0 让 schema 通过，协作成员把工具调用标记当文字输出了四轮， 轮数用完后节点把原话当成功结果交出去——运行标成已完成，数据库一次都没查。 平台可信度（先写失败测试） - Copilot 修改节点改为合并：没写的字段保留，null 才删除；协作成员按名字合并。前后端同一套规则， 工具集合变小时自查报警、改图回执列出变化 - 新校验规则：提示词点名了某个工具而节点没有绑定它，判错误，Copilot 自查会交回去修 - 校验修复只许改格式：冒出原文没有的值就判修复无效；修复这次模型调用计入用量 - 识别模型把工具调用写成文字的情况（DSML、<tool_call> 等标记）：纠正一次，仍然如此就判失败并说明原因 - 协作团队用完轮数不再按成功交付：默认失败，可选降档，点出一次都没派到的成员 - 审批恢复后，同一节点里已经执行过的工具调用复用结果，不再重复执行 后端 - 查询时限交给数据库执行（Oracle call_timeout、PG statement_timeout、MySQL max_execution_time、 SQLite progress handler），可按数据源配置；超时报错与实际耗时一致 - 等审批的运行可以真正取消；会话列表带最后一轮状态；测连接结果持久化；探查结构可只看不存； 自定义工具可草稿试跑、写坏的参数定义保存时拒绝；MCP 服务改动后作废旧工具缓存； 检索命中带贡献分解；重建索引在后台跑并报进度；报错统一收进 core/errors 前端 - 公共层：管理页共用件、失败说明（lib/explain）、健康状态进公共库；目录按表各自加载并有超时， 一张表卡住不再拖垮整站；上传显示真实字节进度；离线横幅只播报不变的句子 - 画布：卡片只说游标所在的那一次执行；等审批时可放弃运行；团队收尾判定与未完成说清楚； 回放用量取那一刻的值 - 编排页：Copilot 合并语义与工具变化回执；「用完轮数时」选项；正式运行期间锁住所有改图入口 - 回答流 / 问数据：新失败类型说人话并给下一步；画布与右栏互相定位；数据源范围、回收站、重新核对 - 记录页：「航迹」页签复用画布时间轴，可拖动回放、列出关键时刻；列表行带执行 / 等人 / 失败缩略条 - 外壳：统一的离开前确认（data router），导航、⌘K、快捷键、后退都会先问 验证（沙箱）：tsc 干净，pytest 838 passed（两遍），14 个检查脚本中 13 个全绿； check-ui 余 1 项旧断言（按旧日期格式找运行行），3c 更新。	2026-09-27 10:16:32 +08:00
ThearchyHelios	e10c4f23fc	界面与交互全面翻修（前两波）：运行态有了 HUD 和时间轴，终态会收尾，全站令牌、组件、文案统一 ... 来自 2026-09 的 UI/UX 审查（142 条）。本提交是前两波，第三波（记录页接入时间轴、跨页互链、check-ui 更新、全站扫尾）另行提交。 地基 - 设计令牌：全局规则和 .btn/.field/.chip 放进 CSS 层，Tailwind 工具类重新生效，选中态、开启态不再被吞掉；字号阶梯； 辅助文字在所有底色上 >= 4.5:1；状态色专用，节点类型色与之拉开色相；「跟随系统」真的跟随，首帧不闪深色；新字标与 favicon - 基础组件：confirmDialog / promptDialog 取代原生对话框；toast 出错不自动消失、可复制、读屏可播报；离线横幅与断线恢复； 九种剪影的状态徽标；唯一一份状态文案（lib/status）、格式化（lib/format）、术语（lib/terms）、报错人话（lib/errors） - 运行态内核：事件折成航迹（run/trace.ts），可投影到任意时刻；取消 / 失败 / 服务重启后统一收尾，不再永远转圈； run.status 随事件回写；token 事件不再堆进 events - 后端：协作成员逐个完成即发事件，调度者决策有事件；时长分执行 / 墙钟 / 等人；API 时间带时区； 中断的运行也发 stream.end；运行列表可筛选翻页；删除运行 / 工作流有保护；运行默认值接通；可测未保存的配置； 报错说清发生了什么、为什么、怎么办 功能 - 画布：状态四重编码、固定高度遥测槽、按缩放三档、运行胶囊与 HUD、航迹时间轴与回放、执行轨迹边、 等待闸门、跟随执行、正式运行只读、一次性时刻（开场点亮、回扫、阻断级联、出具印章） - 编辑：撤销重做、版本历史、问题面板可定位、三栏可收起、模板与表达式字段区分、变量血缘、快捷键、带搜索的选择器 - 回答流 / 问数据：贴底才跟随滚动、工件下钻、出具横幅列出缺口、答案可复制导出、按会话的忙闲、 答案不再在 2000 字处截断、重启后这一轮会收尾 - 记录页：待审批 / 运行中 / 失败页签、筛选翻页、实时接流、排错路径指到节点、封存凭证常驻 - 管理页：新的「数据」页、写操作失败都有反馈、弹窗里先测连接、统一持久的连接状态 - 外壳：导航改版、⌘K 命令面板、? 快捷键帮助、404、页面标题与 favicon 状态点、后台提醒 验证（沙箱）：tsc 干净，pytest 579 passed，14 个检查脚本中 13 个全绿；check-ui 剩 1 项旧断言（按旧日期格式找运行行），第三波更新。	2026-09-26 23:11:31 +08:00
ThearchyHelios	e46a3f0d62	嵌套循环的内层每轮都从头数：max_iterations 是"每进来一次"的上限，不是整次运行合计 ... 运行 87daca70：一个计时器，外层每一拍里内层跑两个 50ms 的子拍。5 秒该推进 50 拍， 结果推进了 138 拍。循环节点走 done 出口时计数原样留着，外层下一轮再把它带进来，就从 上次停下的地方接着往上数：内层 max_iterations 是 5，第一、二拍各跑 2 个子拍，第三拍 1 个，从第四拍起一进来就撞上限直接退出，子拍一次都不跑（撞上限的 warn 136 条）。 嵌套的 foreach 更糟：外层第二轮时内层游标已经在末尾，内层一项都不再跑，也不报错， 结果只是悄悄少了一大截。 改法：走 done 时记 finished，再被带进来时从 0 数。index 仍停在最后一轮，结束后读 loops.x.index 的照旧拿到轮数；画布上内层的"第 N/上限 轮"也随之每轮重新数起。 测试：test_nested_loops 两条——嵌套 while 合计 6 次（修复前 3 次）、嵌套 foreach 走完 3×2 项（修复前只有 1a、1b）。用 87daca70 的原图在临时库里真沙箱重跑：内层每拍都是 "跑、跑、结束"，撞上限 0 次。后端 473 passed ×2。	2026-09-25 23:14:50 +08:00
ThearchyHelios	9d375f8f1c	循环跑满自己声明的轮数，不再被全局步数上限半路掐断 ... 「测试 1」按校验提示改好之后仍然跑不完：while 循环配了 1005 轮，每轮是"循环节点 + 循环体"两步，而整次运行的步数上限（max_graph_steps）是 200——跑到 100 轮上下 LangGraph 抛 GraphRecursionError，报错是一段英文，叫人去调一个界面上碰不到的 recursion_limit。 图没写错，是平台自己的两个上限在打架：校验通过，跑到一半才死。 全局上限防的是没人把关的环；loop 节点的 max_iterations 是作者明说的轮数上限。现在循环 按自己的轮数另记一份预算（schema.loop_steps），加在全局上限之上，子图同理。取上界： 一个节点最多跑 Π(包住它的各层循环 max_iterations + 1) 次，嵌套相乘；done 出口之后的 节点只跑一次，不按轮数记账，否则预算虚高、等于没有上限。 没有 loop 节点把关的环（分支连回上游）照旧由全局上限拦住，报错改成中文、说清预算怎么 来的、该怎么改；子图里撞上限报子图自己的名字和步数——以前那段英文会被外层包进 NodeError 原样带出来。 实测：「测试 1」照提示改完，在真沙箱里 1000 轮跑满，25 秒，结果 501500（= 2+3+…+1001）。 测试：test_step_budget 8 条——预算的上界、嵌套相乘、done 之后不记账；全局上限压到 20 步 时循环照样跑满 30 轮；空转的环中文报错；子图里的循环有自己的预算、空转的子图报它自己的 名字。把 runner / 子图的预算换成 0，对应用例确实失败。README 补了常见问题，测试数更新为 470。	2026-09-25 17:04:49 +08:00
ThearchyHelios	a819f92903	审批只认明确的"同意"，而且每个会执行危险操作的地方都得过这道门 ... 三个口子，都实测复现过： 1. 回复"拒绝"，工具照样执行。四个节点四套审批解析：工具节点和代码节点对 回复一律 bool()，"拒绝"、"no" 都是真；{"decision": "approve"} 反被当成 拒绝；{"approved": "false"} 也是批准。现在收成一份 engine/approval.py： 只认明确的批准，看不懂的一律按拒绝。填内容的 human input/edit 模式另算—— 裸字符串是交稿，只有结构体里明说"不"才驳回。 2. 可写数据源上的 DELETE 从来不问人。数据源工具是动态生成的，查不到 ToolSpec，任何审批模式下都被当成安全；is_dangerous_call 写好了但全仓库 没人调用。现在危险与否逐次判定：registry.call_is_dangerous 统一问，数据源 工具把判定挂在 metadata["dangerous_if"] 上——同一个 db_query，查询直接 跑，可写源上的写要先确认。工具节点、agent 节点、协作成员都走它。 这一步以前没出事，只因为写入从不提交：run_query 走 stream，拿不到结果集就 抛 ResourceClosedError，连接关闭时再回滚——审批通过的写也没落过库。审批接 好之后才让写真正提交（先后不能反，反过来就是一个无审批写库的窗口）； RETURNING 这类带结果集的写照样返回行。工具页的"试一下"是人自己在执行， 不设审批。 3. 协作团队的成员调工具完全不经审批。成员们并行跑在一个节点里、停不下来等 人（恢复时节点整个重放，几个人的 interrupt 对不上号），所以需要确认的调用 不执行，把原因交还给成员让它换做法；节点上显式设成"全部自动放行"才跑。 前端补了这个选项。顺带修了同一处的两个老问题：成员步数不受 max_agent_steps 约束；步数用完时把工具的原始返回当结论交上去（agent 节点在 4057cdc 修过 同一个问题，这里没跟上）——现在补一轮不带工具的收尾。 连带修的：多条审批并存时，交给引擎的是库里存的那份回复，而它存之前被 _safe 截到了 2000 字，解包时又只留 value——人工改过的长稿被砍一截，带了内容的驳回 被当成交稿。现在存全文、只拆自己包的那层 {"value": x}。 test_approval.py 36 例；去掉修复重跑，引擎层 10 例全部失败，各对应一个真问题。 并行驳回那例翻出了一个运行卡死的老 bug，已在上一个提交单独修掉。 338 → 374 passed，连跑三次全绿。	2026-09-25 15:21:20 +08:00
ThearchyHelios	7fb2976f29	代码节点的变量不再带着 print 的换行：一个变量不该有两种判定 ... 运行 d47bfcb03dc747658c2d63f8755992b9 交出来的是自相矛盾的结果—— "已重试 2 次仍未成功，流程终止"，而最后输出是 {"ok": true, "result": "1+1 = 2"}。看着像运行失败了，其实 status=succeeded。"已重试 2 次"是图里 写死的文案，跟实际跑了几轮、跟成败都无关。 真正的毛病在事件流里：judge 节点（code）的 vars 是 {"ok": "ok\n"}。 assign_to 拿的是**原始 stdout**，而 print() 一定补一个换行，于是 `print('ok')` 写进变量的是 "ok\n"。后果是同一个变量、同一个表达式被两个 控制节点判出相反结论： loop retry vars.ok == 'fail' → False 循环正常退出（看着像成功） branch check_outcome vars.ok == 'ok' → False 所有条件都不满足 → default → 失败 这不是个例，是代码节点的默认用法：print 是它唯一的产出通道，写完再比字符串 是标准套路，所以只要这么写就必然踩上，而且**静默**——没有一个地方会说 "这个值多了个换行"。 同一个函数里本来就为了"stdout 是不是 JSON"算过一次 strip()，只是没拿它当值 用。现在统一成一份： - payload["text"] 和 assign_to 都用去掉尾部空白的文本。只削尾不削头：首行的 缩进是内容（逐行打印一段缩进文本时削掉就毁了），而尾部换行是 print 的产物 - payload["stdout"] 保留原始输出——审计"到底跑了什么"只能看它 - stdout 是 JSON 时仍解析成对象，既有约定不变 - {{ vars.x }} 和 {{ nodes.x.text }} 必须是同一个值，两种写法给不同的值比 原来的毛病更难查，所以一起改 顺带在 Copilot 的 NODE_REFERENCE 里写明代码节点的输出契约（尾换行已去掉； stdout 是 JSON 就变对象，那时要用字段引用而不是比字符串），否则模型会继续 生成下一个变种。 新增 tests/test_code_output.py：五条，覆盖尾换行、多行内容不被削坏、JSON 仍解析成对象、text 与 vars 一致、纯空白输出归一成空串。修之前红四条。 验证做过变异：把改动还原，同一张图回到"走了失败分支"，而 print('ok', end='') 仍是成功分支——换行就是原因。把用户那张图原样重跑，judge 的 vars 是 {"ok": "ok"}，check_outcome 命中 "vars.ok == 'ok'" 走成功出口。 290 passed。	2026-09-24 23:15:19 +08:00
ThearchyHelios	4057cdc35f	步数用尽时先收个尾，别把半截过程当答案交出去 ... 走到步数上限一定意味着最后那步**要求了工具**（不要工具的话循环早 break 了）， 也就是说模型从来没拿到过"说结论"的那一轮——它只是被掐断在半路。交出去的 是它上一句中间过程的话，末尾补一句"步数不够，请调大"。 实测这条线是绷紧的：库里 116 个 agent 节点，87% 在 10 步内收口，11 步只有 1 个，**正好 12 步的有 11 个**。1 跳到 11 是被截断的特征，不是自然分布。 所以补上那一轮：不给工具，让它基于已经查到的收口，并说清哪些没查到、 结论因此有什么局限。用 base_model 而不是绑过工具的 model——收尾轮必须在 结构上发不出 tool_call，靠提示词请它别调是约束不住的。 两种收场发不同的 code：收上来了是 step_limit_settled（DEGRADED）， 收不上来仍是 step_limit（BROKEN）。不复用同一个 code：库里那 8 条老事件 的含义确实是硬截断，改语义等于把历史运行重新解释成另一回事。 顺带修掉一个一直在白烧钱的 bug：chat.ts:440 的注释说自动重试能"调大最大 步数"，而 copilot.py 明确禁止模型写 max_steps。两边对不上，于是 step_limit 的重试是用同一个默认 12 再跑一遍，必然撞同一堵墙。现在那条禁令改成有条件 的——只有上一次死于步数不够时才准显式写大值。改完两条路各自成立：收尾 成功走 DEGRADED，闸门不开、不重试（对的，同配置再跑还是撞墙）；收尾失败 仍是 BROKEN，而这次 Copilot 真能把步数调大。 硬顶 25 → 100，画布滑块跟着放开，**节点默认仍是 12**：要更多的人调得动， 不知情的人不会突然多花十倍。 新增 tests/test_agent_steps.py，顺带补回 agent 循环的集成测试（原来那个 文件在脱敏那轮被整个删掉了）。两条反向断言是重点：正常收口的 agent 一次 调用都不该多花，以及收尾轮发不出工具调用。两者都做过变异验证——把收尾 结果丢弃、把收尾轮换成绑工具的 model，各自都能让对应的断言变红。 273 passed（去掉一个会真连 api.openai.com 的既有慢测试是 238 passed / 9.4s）。	2026-09-24 16:38:26 +08:00
ThearchyHelios	c3f7d6ffcd	协作团队真的能并行了，界面上也看得出来 ... 先说一个和名字不符的事实：这个节点叫「多 Agent 协作」，但在此之前它是一条 严格的串行流水线。调度协议写死成 `next: string`——"一次只能派一个"被编进了 协议本身，模型再想并行也表达不出来。三个专家各花 10 秒，总是 30 秒。 （真并行一直在图级 fan-out：实测 3 个各 sleep 2 秒的节点连在同一个上游， 全部 +0.00s 开始、+2.37s 结束，墙钟 2.6 秒。只是协作团队走不到那条路。） **协议改成 assignments 数组**，一轮可以派多个互不依赖的专家，asyncio.gather 并发执行，总耗时按最慢的那个算。max_parallel 可配，设成 1 即退回严格串行。 **并发只在任务真的互不依赖时才成立**，这件事的成本必须说清楚：同一轮发出去的 专家拿到的是**同一份进展快照**，谁也看不见谁这一轮干了什么。派错了不报错， 只会让两个人基于一样的旧信息重复劳动，而这在结果里很难看出来。所以判断责任 压在调度者身上，提示词里把反例写出来： 可以同时派：「查 A 的资料」和「查 B 的资料」 不能同时派：「查资料」和「根据资料写报告」 不能同时派：「写初稿」和「校对初稿」 并明确告诉它拿不准就分两轮——代价只是慢一点。 **每个人单独计时**，而不是事后拿整轮墙钟去摊。界面要显示"并行省下多少"， 那个数必须是量出来的：按 N×墙钟 推算等于假设每个人都跑满了最慢那条， 而实际上快的那个可能只花了三分之一。测试里专门有个快慢不对称的用例守这条。 **调度日志改成结构化字段**（agents / done / reason / parallel）。以前只有一句 中文消息串，解码层得拿正则去拆「调度 → X（理由）」——后端文案一改就散架， 而这次正是改了文案。老运行的事件没有这些字段，正则那条路留着兜底。 **界面加泳道。** 每个成员一行、每轮一格，条形宽度按耗时归一化，所以一眼看得出 谁和谁是同时干的、谁是这一轮的瓶颈。顶上一行汇总"3 名成员 · 3 轮 · 2 轮并行， 省下 11.8s"；点任意一格展开那个人这一轮的任务和回复。全程串行时不装作有并行， 而是说"本次任务互相依赖，逐轮进行"。 泳道排在子步骤**前面**：先给一眼看清的形状，再往下是每一步的内容。反过来的话， 得把十几行步骤读完才知道这个团队是怎么分工的。窄栏（画布右栏 360px）下隐去 "N 人同时"的文字——并行与否看条形本来就一目了然，而缩写成"并2"没人看得懂。 验证：后端 276 passed（新增 test_supervisor.py 7 条，核心那条用**墙钟**判定 并发而不是看事件顺序——顺序只能说明"发出去了"，说明不了"同时跑"）； check-stream 新增 10 条泳道断言，含"同一轮里慢的那个条更长"和两种栏宽不溢出； tsc 干净，三个 check 不回归。	2026-09-20 20:57:03 +08:00
ThearchyHelios	cc608f56ec	跑完先过一道复核再交给你：异常说破、数字不许现编、出错自动改一次 ... 「跑完了」和「答得对」之间一直没有任何一层。库里 264 条 succeeded 里， 14 条带着 warn、4 条 agent 步数用满，而交到用户手上的答案对此只字不提。 最糟的一次（run dd9927e6）交出去的干脆是「本轮只执行了第一个工具」—— 一句内部管道文案冒充结论。 出具体系（issuance.py）本来就是干这个的，但它挂在输出节点的可选契约上， 还要配口径卡提供受控指标集；问数据页生成的图基本都是 input → agent → output， 走不到那条路。所以补一层轻的。 **干净的运行一次模型都不调。** 先用规则扫一遍事件流（engine/review.py:scan）， 没扫出东西就到此为止。实测 15ms 返回。这是整层设计的前提，测试里用 「monkeypatch 一个会抛异常的模型，断言它没被碰过」来守。 **分类挂在 code 上，不是中文消息串。** 12 处 warn 发射点都带上 code。 这样「流式失败，回退非流式」能归成 benign 直接跳过——它对答案内容零影响， 为它叫一次模型等于每次网络抖一下就多花一笔；而「步数用满」归 broken。 原来这两者在事件流里长得一模一样。工具报错之后同一个工具又跑成了， 算 degraded 不算 broken——否则参数自愈每修一次就报一次「答案不可信」。 **复核不许现编数字。** 它手上只有原答案和一份异常清单，没有任何原始数据， 写出来的新数字只能是凭空来的。直接复用 issuance.trace_numbers，把原答案的 数字当受控指标集，对不上就整条退回原答案、只留说明。硬拦截，不是提示。 **规则管重试资格，模型只有否决权。** 一开始写成两边取并，实测 loop_limit 时模型判 retry=true——而重跑一遍循环还是会撞上限，白烧一次建图加一次跑图。 反过来之后，「检索什么都没查到」这类也不会被模型强推重跑。 **重试带着失败的那张图，不是推倒重来。** 原来传 base_graph=null，模型只看到 「原问题 + 一句失败原因」，很可能原样再建出同一张坏图。而且它连自己上次建了 什么都看不到——会话历史按 status != running 过滤，正在重试的这一轮恰好被 排除在外。现在交回去走后端的改图分支，调大步数、改正参数就是改一个字段。 上限一次。 **答案等复核完成再显示。** 端到端抓到的：答案先摆出来，十秒后说明才追上去—— 这十秒里用户读的是一个没人核对过的结论，正是要修的那件事本身。改成落库立刻 （防关标签页丢结果）、显示等复核，并给复核加 25s 上限。说明排在成果上方， broken 用报警色、degraded 用普通边框——混成一个样子用户就学会了一概忽略。 复核结论跟着轮次落库，刷新后还在；也进下一轮的对话历史，否则模型会拿一个 已知不可信的结论当事实继续往下推。 验证：后端 242 passed（新增 test_review.py 25 条）；tsc 干净； check-decode / check-stream / check-ui 全过，check-stream 新增 9 条渲染断言。 两条端到端都在真浏览器 + 真模型上跑通：检索降级那次说明正确排在答案上方； 重试那次建图请求 2 次、第二次 base_graph 带着失败的 3 个节点、第一版没漏出去。 复核结果不是事件流，decode.ts 翻译不到它，所以渲染测试放在 check-stream。	2026-09-20 11:18:53 +08:00
ThearchyHelios	a027261701	Copilot 会自己记该记的了；顺带让写记忆这件事看得见 ... 以前只有用户明说「记住」才会写：17 轮有图的对话里只有 4 轮带记忆节点，全在 那个用户主动谈记忆的会话里。于是他说过一次「我叫张三」，换个话题再问就 谁也不知道了。 现在 answer 路径多一步判断：这句话里有没有值得长期记住的东西，有就在主链路 前面加一个 memory(write) 节点。边界比指令本身要紧，所以写死了四类不该记的： 这一轮的问题本身、查出来的数（会过期且能重查）、一次性指令、以及**用户没说过 而你推测出来的**。另外两条是从召回的实际情况倒推的——content 要脱离上下文也 成立（召回时没有这轮对话，「他说他叫张三」读起来不知道「他」是谁），以及 拿不准就不记：记错了污染以后每一次对话，漏记一条用户再说一遍就是了。 **动手前先修了一个前提**：写记忆在界面上是隐形的。memory 节点发的是 info 级 日志，而解码层明确丢弃所有 info（decode.ts），也就是说自动记忆 = 系统背着 用户往一个跨会话、长期有效的地方存关于他的信息，而他看不见。 新增 memory.end 事件，解码层按动作分开渲染：写入把**记了什么**原样显示 （只报「写入 1 条」等于没说，用户没法判断它记的是不是他想让它记的）、召回说 「想起 N 条」、清空标成警告。 真模型验过（deepseek-v4-pro）： 「我平时叫小蒋，以后报表金额用万元」 → content='用户平时叫小蒋，他要求以后报表里的金额统一用万元作单位' scope 未写、跑完落库、事件里带着内容 → 换个说法召回得到：「该怎么称呼我」「金额用什么单位」都命中 三条对照确认不滥记： shop 里有几家店 → 没记 重来 → 走 reply，连图都没建 把上一轮的结果按月份排一下 → 没记	2026-09-19 22:41:27 +08:00
ThearchyHelios	2a1040bbfc	重排给足输出预算；失败提示分清是哪种失败 ... 拿真 provider（deepseek-v4-pro，千帆网关）跑了一遍评测集，重排确实有用： hit@1 hit@5 初筛 88% 100% 重排后 100% 100% 变动的两题都是语义类的，正好是本地哈希向量的短板——BM25 把「权限」的字面 命中排给了「数据导出」（那篇里有「export 权限」），模型读懂了问的是「谁有权 改」。字面类原本就 100%，没有被重排搞坏。 但 16 次里有 2 次退回了初筛顺序。查下来模型回的是**空字符串**，而失败那次的 out_tokens 正好等于 max_tokens——重排的输出只有一行几十字的 JSON，但模型为了 读完 20 条候选要花 800~1600 个输出 token，顶到上限后正文什么都不剩。llm.py 里对同一个现象早有记录：「思考型模型把额度全花在推理上了，正文是空的」。 所以重排改成有自己的预算（至少 4096），不跟节点上那个走。补跑 16/16 全部成功。 顺带纠正一处判断：thinking=off 救不了这个 provider。实测关思考那组照样在 out_tokens=2048 时空手——factory.py 只在 anthropic 分支里读 thinking 字段， openai_compatible 整条路径不碰它。仍然传 off，因为对 Anthropic 有效、而且打分 任务本来不需要思考模式，但它不是这次的解药，注释里写明了。 失败提示原来四种坏法统一报「解析不出来」，会把人引去查 JSON 格式，而该调的是 token。现在分开说：空回复 → 「把最大输出 token 调大」；找不到 scores → 带上 原文前 80 字；个数不符 → 说明给了几个、候选几个；混了非数字 → 指出是哪个值。 测试里有一条专门断言空回复的提示中不出现「解析」二字。	2026-09-19 11:09:04 +08:00
ThearchyHelios	e8ef6ff9a8	检索质量有数了：评测集 + 重排，alpha 不再写死 ... 先做评测再做重排——否则重排的收益只能靠"搜两下感觉准了"。 **评测集**（test_retrieval_quality.py）：24 篇语料 + 16 个问题，问题分成字面 重叠和纯语义两类。第一版是 8 篇、主指标 hit@3，结果各档 alpha 全是 100%， 等于什么都没量——8 选 3 瞎猜都有 37%。扩语料、加干扰、主指标换成 hit@1 之后才开始能分辨。 量出来的第一个结论就推翻了我原来的猜测： alpha hit@1 hit@5 MRR 字面 语义 0.0 88% 100% 0.911 100% 75% 0.2 81% 100% 0.880 88% 75% 0.5 81% 100% 0.880 88% 75% 1.0 81% 100% 0.880 88% 75% 本地哈希向量那一路不是"弱一点"，是**纯噪音**：给它任何权重，hit@1 都从 88% 掉到 81%。而 alpha 的默认值一直写死 0.5，等于主动把检索做差。改成跟着 embedder 能力走（default_alpha：有语义泛化才给 0.5，否则 0），节点上的 alpha 也不再写死默认值。 **重排**（memory/rerank.py）：初筛多捞一些（20 条），让模型按"对回答这个问题 有多大帮助"重排，再取 top_n。只捞 5 条的话重排最多把这 5 条换个顺序，第 6 条是对的也救不回来。 用已配置的对话模型做，不引入本地 cross-encoder——后者要下模型权重，和"零配置 能跑起来"的基线冲突。代价是每次检索多一次调用，所以默认关闭。 失败一律退回初筛顺序并说一声：解析不出分数、个数对不上、模型抛异常、没配 provider，四条路径都有测试。重排是增强，不该因为模型抽风就让整个检索挂掉。	2026-09-19 09:33:09 +08:00
ThearchyHelios	df935599f2	知识库：换 embedding 模型不再 500，检索能回指了 ... 三件事，都是"这三个模块一条测试都没有"的后果。 **换 embedder 会让检索整体 500。** 库里是 512 维的本地向量、查询是 1536 维的 远端向量时，cosine 直接 `shapes (1536,) and (512,) not aligned`。from_blob 有 dim 参数，但 kb.py 和 memory/store.py 调用时都没传；而且存量向量属于哪个模型 代码里没有任何地方记着，所以也无从降级。 Chunk / MemoryItem 各加 embed_model + embed_dim（走现成的 _COLUMN_MIGRATIONS， 存量回填空值，正好表示"不知道是谁建的"）。检索遇到对不上的向量整体退回纯 关键词并说破，不是把它们当 0 分静默沉底——那样用户看到的是结果莫名其妙变差， 而不是"这里有一批索引该重建了"。配套 kb.reindex + POST /api/kb/reindex。 长期记忆那份一起修了。判重那条更危险：维度碰巧相同但模型不同时 cosine 算出来 是随机数，会把不相关的旧记忆认成"重复"，然后把新内容丢掉。 **默认 embedder 没有语义能力，而开关藏在一个环境变量里。** LocalEmbedder 是 特征哈希 + TF，和 BM25 吃同一批词；alpha 默认 0.5 等于给了它一半权重，同义 改写一条都召不回。开启真模型的唯一开关是 AGENTLAB_USE_OPENAI_EMBEDDINGS—— 没界面、没人会发现。改成设置项（照 COPILOT_SETTING_KEY 的路子），知识库页顶部 能选能看能重建。 配置失败必须响：第一版写成静默退回本地，但选了 OpenAI 却拿到哈希向量的人， 在搜不出同义表达时完全无从怀疑到这里。现在抛 EmbedderUnavailable，API 400 原样交回"检查 OPENAI_API_KEY 是否配了"，且不会把配置改掉。 **检索结果不进工件库。** db_query、工具节点、agent 工具调用都落 put_json 快照， run_retrieve 什么都不落——于是结论只要来自知识库，"这个数是哪来的"就断在这儿， 而数字回指正是这个项目的签名能力。现在落 kind="retrieval_snapshot"，并发一条 retrieve.end 带 artifact id。解码层补了正式映射（原来会掉进"未知事件"兜底， 画成一坨原始 JSON）。 新增 test_kb.py 11 条，补上这三个模块此前的零覆盖，包括 embeddings.py 里 注释记着、但一直没有测试守的那个归一化边界（单条候选被 min_score 误杀）。 端到端在真实服务上验过：撞上存量向量返回 200 + 降级说明（以前 500）、 重建后 stale 归零、配不起来的远端模型 400 且配置不变。	2026-09-19 09:27:07 +08:00
ThearchyHelios	c02ef189bb	工具调用失败能自救；agent 改成一步一个工具 ... 起因是一条没人看得懂的报错： 工具 db_query__shop 执行失败： _make_query_tool.<locals>._run() got an unexpected keyword argument 'query' 参数名写成了 query（它叫 sql），而 call_tool 对动态工具是裸 **args 展开的， 跳过了 args_schema —— pydantic 那句"缺少 sql 字段"漏成了只剩内部闭包名的 TypeError，既指不到是哪个工具，也说不出该填什么。同一个函数里内置工具那条 分支本来是校验的，两条路径不一致。 registry 里补上 prepare_args / describe_args，两条路径共用： - 候选唯一时（多一个不认识的、少一个必填的）改名重试，并发一条 warn 说破 —— 配置里那个错名还在，替它跑通一次却不吭声，下次照样踩 - 有歧义就不猜，报错改成"参数不对：query 不是它的参数；缺少必填参数 sql。 它接受：sql（必填，字符串）— 要执行的 SQL…"，模型照着这句就能改对。 这才是失败之后真正能自愈的重试 - 顺带堵了一类静默失败：pydantic 默认把认不出的键悄悄丢掉，全可选 schema 上 {"tabel": "orders"} 会"成功"执行一次什么都没查的调用 agent 循环默认改成串行：一轮只调一个工具，看到结果再想下一步。并行更快，但 一批调用中间没有任何新的思考——第二个是照着"还没看到第一个结果"时的判断发出 去的。节点上留了「并行执行工具」开关。两个必须守住的点：没执行的调用绝不发 tool.start（前端靠 call_id 配对，发了没结尾的 start 会永远转圈），但必须各有 一条配对的 tool_result（少一条下次调用直接 400）。 交错思考跟着补上。4.6 起 adaptive thinking 自带交错，不需要也不该挂 beta header（Opus 4.6 上手动模式压根没有交错）；4/4.5 那一代要手动开 thinking + interleaved-thinking beta，光挂 header 是一条什么都不做的空设置。开了 thinking 就不能再传 temperature，这一代本来是收的，漏了就是 400。 还有两处是串行带出来的，一并治了： - 步数用完时收尾取的是 messages[-1]，而那往往是给模型看的 ToolMessage。 真漏到用户面前当过答案（run dd9927e6）：一句"本轮只执行了第一个工具"冒充 结论。改成只取模型自己说过的话，并把"步数用完了、去调大最大步数"附在后面 - db_schema 一次能问多张表。一次调用就是一步，逐张问 6 张表就是 6 步—— 实测 8 步的运行里 7 步花在这上面，最后只剩一步真查数据	2026-09-18 17:57:20 +08:00
ThearchyHelios	0895a01b41	变量表抽屉；顺便治了一个每敲一键发一次全图请求的老毛病 ... 先说顺带修的那个，因为它是前提：validate() **零防抖**，从七个 mutation 点 直接调，其中包括 updateNode——也就是 Inspector 里每敲一个字都发一次带全图 的 POST。实测敲 15 个字 = 15 次请求。再挂一个变量分析就是翻倍，所以必须先 治：一次防抖（300ms）、两个请求并发、epoch 丢弃过期响应（图在飞行期间又改 了的话，旧答案不能覆盖新答案——校验结果闪回是最难查的那种 UI bug）。 现在敲 15 个字 = 1 次请求。 变量表另有一层跳过：**"有哪些变量"只取决于结构，不取决于文案**。节点 id、 类型、assign_to、入口字段名组成签名，改 prompt 里一个字不会触发变量分析。 抽屉本身做成挤压式而不是浮层——React Flow 的 Controls 和 MiniMap 是绝对 定位在画布容器里的，浮层会把它俩埋掉，挤压会把它俩顶上去。限高并给画布 留底（React Flow 容器高度归零会直接报 error 004），可拖拽改高，两端都夹住。 表里四列：变量 / 来自哪个节点 / 被引用几处 / 最近一次运行的值。点开右侧 详情能看到谁产出、每一处引用在哪个节点的哪个字段，点一下定位到画布。 实跑验证： {{ input.question }} 输入 — 变量表要显示这个值 {{ vars.question }} 输入 — 变量表要显示这个值 {{ nodes.start }} 输入 — { "question": "变量表要显示这个值" } {{ last_message }} 内置 1 处 — 另外让用户看得见**真正跑的那份代码**：代码节点送进沙箱的是 {{ }} 渲染后的 字符串，和编辑器里那份可能差很远（一个带引号或换行的值插进字符串字面量里 就把程序写坏了），而报错指的是渲染后的行号，对着自己那份怎么也数不对。 sandbox.start 现在带上渲染结果，只在真插过值时才显示（没插值的两份一模一样， 显示等于噪音）。沙箱步骤的 detail/result 也分开了：detail 是跑的什么， result 是跑出了什么——塞一个字段里的话，报错时最需要的两样东西只能看见一样。	2026-09-18 10:48:22 +08:00
ThearchyHelios	3a1e4aa816	模型报错说人话，并堵住 Copilot 猜 model id ... 用户拿到的是这么一段： OpenAIAuthenticationError: Error code: 401 - {'error': {'code': 'invalid_model', 'message': 'The model does not exist or you do not have access to it.'}} 流式失败，回退非流式：（同一段，再来一遍） 401 + Authentication 看着像 key 过期，实际上 key 好好的——是 model id 在这个 端点上不存在。照着原文去换 key 是白费功夫。而且整条轨迹里**没有任何地方** 记着试的是哪个模型：llm.start 只带了 message_count。 三处： 1. llm.start 带上 model。调用失败时至少知道试的是什么。 2. explain_model_error()：invalid_model 译成"模型「x」在这个供应商上不存在… 去设置→供应商改模型列表"；额度耗尽单独认；不认识的错误照抄原文（猜错了 比不猜更糟）。流式回退再失败时不再把同一段原文吐两遍，而是抛一条 NodeError。结构化输出那条路径也走同一个翻译——模型不存在不叫"结构化 输出失败"。 3. Copilot 提示里补上"model 字段不要填"。它原先只被告知 llm 节点有个 model 字段，却从不知道有哪些 model id，于是按供应商名字猜（看到 DeepSeek 就写 deepseek-chat）——猜出来的那个正好不存在。这是这次报错的真正来源，不修 的话每次生成都会再踩一遍。 顺带把那个供应商的模型列表改对了：列着的 deepseek-chat / deepseek-reasoner 两个都返回 invalid_model，而真正能用的 deepseek-v4-pro 反倒不在列表里（它是 default_model，所以"跟随默认"的节点一直是好的，手动选模型的节点必挂）。 逐个实测后换成 deepseek-v4-pro / deepseek-v3.2 / ernie-4.5-turbo-128k。 已确认没有已保存的工作流节点写死了那两个失效 id。	2026-09-17 18:41:14 +08:00
ThearchyHelios	b634c89be4	人工介入的驳回按钮不再是摆设，画布脏边与待办入口 ... ## 点"驳回"实际等于放行 ApprovalCard 无条件渲染"通过/驳回"两个按钮，而后端 human 节点只在 approve 模式下读 approved：edit 和 input 分支直接取 value，__decision__ 硬编码成 "approved"，approved 字段看都不看。按钮在、文案在、toast 说"已驳回"，运行却 照常往下跑——比没有这个按钮更糟。 这两种模式在图上只有一个 out 出口（没有 rejected 那条边），所以驳回的正确 语义是终止运行。缺省仍是通过，只传 value 不带 approved 的老调用方行为不变。 前端按钮文案改成"驳回并终止"，toast 也说清楚。 顺带：run 级的错误消息不再给 NodeError 套类型名前缀，界面上从 "NodeError: 人工驳回：内容不合格" 变成 "人工驳回：内容不合格"。 ## 改分支 case key 会留下看不见、删不掉的脏边 出口 handle 是从 config 算出来的（分支的 case key、human 的 mode），而 Inspector 的输入框逐字符 setConfig。key 从 yes 改成 yesno 的过程中 handle id 会依次变成 y/ye/yes…，已有边的 sourceHandle 仍是 yes。React Flow 对这种边只在 console 打一条 008 警告然后不渲染——看不见、点不到、删不掉，却照样被 toGraph 序列化存盘，后端校验也不管。 updateNode 现在同步处理：出口数量没变就按位置重映射（改名时连好的线跟着走）， 出口真的没了就把边一并清掉。 ## 未保存的编辑会被静默丢弃 切换工作流直接 load() 覆盖画布，没有 dirty 检查；全局也没有撤销和 beforeunload。加了切换确认与关页面拦截。撤销栈是更该补的，但那是另一件事。 ## 刷新后"等待人工"的运行没有任何入口 审批卡片挂在 studio store 的当前 run 上，而那是纯内存的，刷新后为 null，卡片 就不渲染了。更糟的是导航把待办徽标挂在"运行"页上，用户点进去——而 RunsPage 从头到尾没有审批 UI，只有只读事件列表。现在 RunsPage 为选中的运行渲染 ApprovalCard，徽标指向的地方终于能处理待办。 回归：input/edit 两种模式的通过与驳回、approve 模式、代码节点 strict 档、 分支、口径卡出具 formal、工具节点、SSRF 拦截、记忆工具，全部通过。	2026-09-14 15:46:45 +08:00
ThearchyHelios	761117344b	沙箱会话生命周期与记忆检索 ... ## 每跑一次图就多一台常驻 VM，没有任何自动回收路径 _reap_idle 只在 run() 里调，也就是说没人再跑代码时闲置 VM 永远收不掉， microvm_idle_seconds 形同虚设；而 thread_id 每个 run 都是新的，runner 的 finally 又从不调 cleanup，于是每跑一次带代码节点的图就多一台几百 MB 的常驻 microVM（seatbelt 那边同样积了几十个历史会话目录）。 两处一起补：run 到终态就 cleanup(run_id)（interrupted 除外，人回来还要接着跑）， 外加 lifespan 里起一个后台回收任务定期 _reap_idle——回收本来也不该占着请求 路径的时间。实测连跑三次 live_vms 稳定回到 0。 ## 超时会连人带文件销毁整台 VM 会话契约是"同 session_id 共享文件系统，可以先写文件下一步再读回来"，而 microVM 超时直接 _destroy，工作区连同用户数据一起没了，返回结果里没有任何 提示。另外三个后端超时只 killpg、工作目录照留——换到 microVM 之后同一张图的 行为就变了。现在超时先在 VM 内 pkill 掉跑飞的进程（入口名带唯一后缀，不会 误伤同会话的并发执行），确认 VM 还活着就保住工作区；收拾不动才销毁。 限额变更那条没法避免重建（VM 内存是启动时定死的），但不能不吭声：同一个 run 里两个代码节点填了不同的 memory_mb 就会触发。ExecResult 新增 session_reset， 代码节点在时间线上明确告警，否则下游只会看到一个无从追查的 FileNotFoundError。 ## 新建 scope 写入第一条后永远搜不到 hybrid_rank 的 _norm 在 hi==lo 时把所有分数抹成 0，而候选只有一条时 hi 恒等于 lo，合并分 0.0 会被 min_score 过滤掉。"先写一条、下一轮再 recall"恰恰是 agent 最常见的用法。全都一样分是"都一样好"，不是"都一样差"，改成返回 1.0。 ## 记忆去重误判，写入被静默丢弃且返回不相关的旧记忆 remember 拿 recall 的分数判重，但那是 min-max 排名归一化的结果——排第一的那条 在两路信号上都会被归成 1.0，与它和查询像不像毫无关系。于是 scope 里只要已有 两条记忆，新内容随便撞一个字排到第一就被判成重复丢掉，接口还返回 201 并把那条 不相关的旧记忆当成"刚保存的"交回去。改成直接比未归一化的余弦相似度。 验证：三条互不相关的记忆都能写进去、完全相同的仍被去重、单条 scope 可检索。	2026-09-14 15:41:05 +08:00
ThearchyHelios	2207269e07	修 critical：中文叙述里的数字校验一直是空转的 ... _NUM_RE 的后瞻写的是 (?<![\w.])，而 Python 的 \w 按 Unicode 判定，汉字也算 词字符。中文写作数字紧贴汉字不加空格是常态，于是整个 token 抽不出来： extract_numbers('本周营收9999元，订单7777单。') → [] 全部漏检 extract_numbers('本周营收 9999 元，订单 7777 单。') → ['9999','7777'] 等于说"叙述层无算术权限 + 数字回指校验"这套机制只对西式排版生效，中文叙述 完全不设防，而出具物照样盖 formal 章、印 matched_numbers: 0——读的人无法 分辨是"查过都对"还是"根本没查"。改成只排 ASCII 词字符，版本号 v1.2.3、 标识符 sha1 这些仍然豁免。 顺带修同一文件里的两条 high： ## 跳过规则只看形态不看语境 年份规则的"年"字是可选的，等于把 1900–2099 的任何独立整数都免检了——而 客户数、门店数、万元金额大量落在这个区间。日期规则不限年份范围，"9600/12" 这种比值写法会被整段当日期吞掉。引用标记 \[\d+\] 不限位数，[98765] 也放行。 '本周新增客户 2050 家，流失 1987 家。' → [] 两个数字都免检 '全年目标 9600/12 个月' → [] 斜杠两边都免检 年份改成必须带"年"字，日期的年份限 19xx/20xx、月份限 1-12，引用标记限三位。 宁可误杀（要求它回指指标集）也不放过——这是校验不是排版。 ## 校验没发生被当成校验通过 decide_tier 只看 missing/unmatched，而这些列表全空既可能是"查过了都对"， 也可能是"根本没查"：叙述模板里一个笔误让 narrative 渲染成空串、metrics_from 指向不存在的节点，都会得到一模一样的空列表，然后盖 formal 章。 contract.narrative = "{{ vars.does_not_exist }}" → tier=formal, matched=0 contract.metrics_from = "压根没这个节点" → tier=formal, metrics=0 新增 gaps 承载"校验为什么不完整"（叙述渲染为空、指标源未解析、指标集为空）， 非空就不允许 formal，并把原因印进 issuance。校验没发生却盖 formal，比漏检 某个数字更糟：它让整套机制看起来在工作。 端到端四例验证：编造数字→withheld、真实数字→formal、模板写错→degraded （带 gaps）、指标源不存在→withheld（带 gaps）。	2026-09-14 15:27:33 +08:00
ThearchyHelios	7d00c24ab1	microVM 沙箱后端：内存限额终于真限得住，但网络关不干净 ... Seatbelt 在 macOS 上最难受的缺口是 RLIMIT_AS 不被强制——设 256MB 仍能分配 900MB。microVM 不是"更严格的访问控制"，是换了一类边界：宿主 Darwin 27.0.0， VM 里 Linux 6.12.99（libkrunfw），PID 1 是 init.krun，/Users 根本不存在， free 只看得见 512MB。申请 900MB 会被 OOM killer 杀掉而 VM 照常存活。 实现按实测契约写，不按别的 SDK 的惯例推断：create() 直接返回已启动的 Sandbox，没有 handle/connect 两层；cwd/env/timeout 都是 exec 的原生参数； 超时抛 ExecTimeoutError 而不是返回非零码。 必须写明的缺口：network=false 时 HTTP/HTTPS 与域名解析都断得掉，但 UDP/53 拦不住，手写 DNS 包仍能拿到真实响应。default_egress=DENY、Rule.deny_dns()、 显式 deny UDP、max_connections=0 全试过都堵不上——deny_dns 生成的规则只针对 宿主，DNS 出口在 microsandbox 网络栈里是硬编码放行的。所以 health 里 network 标成 partial 而不是 true，设置页对应显示黄色「部分生效」：拦了一半要是显示成 全绿，比显示成全红更危险。 成本也照实说：首次拉 OCI 镜像实测 54.5s，之后热启动 0.19s、执行 7~30ms。 贵的只是第一次，所以 auto 在镜像没缓存时先用 Seatbelt，不让人干等一分钟； 显式选 strict 档不受此限——那是使用者自己要的硬隔离。 端到端 17 项验证通过：隔离、内存拦截、超时 124、退出码透传、多文件与 env、 会话间互不可见、VM 回收。Seatbelt 那档回归未受影响。	2026-09-14 14:10:10 +08:00
ThearchyHelios	1b595f699c	Copilot 流式生成：图在画布上实时长出来 ... 此前点击生成后是 20-30 秒黑盒等待，模态框关着，用户看不到任何过程。 改成操作流协议：模型按 NDJSON 逐行输出 add_node / add_edge / update_node / remove_node / done，后端边流边经 SSE 转发，前端每收 一个操作就应用到画布——节点带紫色描边逐个出现（临时摆位跟着入边源）， 左下角浮条显示当前动作并可随时取消；done 后后端统一排版+校验， 以 final 事件整体落位，高亮几秒后淡出。修改现有图的场景只输出改动 操作，用户能看到 Copilot 具体动了哪里。 行解析对模型犯规免疫：markdown 围栏、夹杂的解释文字、done 之后的 多余输出都被跳过或截断（单测覆盖跨块行缓冲）。 顺手修结构化输出必失败的 bug：langchain 靠 title 字段识别裸 JSON Schema dict，四处 with_structured_output 的 schema 都缺它，抛 ValueError: Unsupported function 后靠 fallback 文本解析兜底—— 每次都白调一次模型。补上 title（llm 节点 output_schema、branch 语义分类、supervisor 路由、旧版 copilot generate）。 实测：首节点 7.2s 上画布（原先干等 27s），浏览器采样节点数 0→2→3→4→5→6 逐步生长，6 个新节点全部高亮，零页面错误。	2026-09-14 10:54:31 +08:00
ThearchyHelios	dcba9a63e0	一次思考在轨迹里只落一条事件 ... 思考流上线时漏了把它登记进 ephemeral 集合，导致每个流式增量都 落库——一条思考链在执行轨迹里被拆成几十条 llm.thinking 事件。 拆成两种事件：llm.thinking.delta 是流式增量，只推给画布做实时 滚动、不落库（与 llm.token 同类）；llm.thinking 是调用收尾时落的 单条汇总，携带完整思考内容（截断 6000 字符，完整版在节点输出 工件里）。顺带修好刷新回放：此前回放重现不了思考（增量被隐藏、 汇总不存在），现在一条汇总事件直接恢复全文，时间线上也可展开查看。 验证：确定性假思考模型过完整管道（3 条增量实时推、汇总恰一条且 内容完整）；真模型跑模板⑤，轨迹 29 条降到 18 条，llm.thinking 恰好 1 条。adaptive thinking 对简单任务自主跳过思考时两类事件 都不产生，已从工件核实是模型行为而非管道丢失。	2026-09-14 10:40:20 +08:00
ThearchyHelios	46eb674bc2	指标集与出具契约：口径卡节点、叙述数字回指、三档出具、周报模板 ... 派生边界收死在固定层：新增 metrics 节点（口径卡），指标由 AST 白名单 求值器确定性计算，产出受控指标集（含口径名与版本）。叙述层没有算术 权限——不是求模型别编数，而是它编了也过不了校验。 output 节点配 contract 即升级为出具契约：核对必需/期望指标是否齐、 从叙述中抽取所有数字逐个回指指标集（支持千分位、百分数↔比率、 万/亿后缀、按书写精度给舍入容差；日期、ISO 周、枚举序号、引用标记 不参与回指），三档判定 formal / degraded / withheld，缺口清单和 口径版本一起印在成果上，另发 issuance 事件入流水。白名单（allow_numbers） 是模板配置的一部分，进版本、被审查。 新增模板⑧周报：取数固定 → 口径卡算数 → LLM 只许引用清单 → 出具 逐数回指，是'模板定骨架、agent 填关节'的完整示范。 回指校验器 10 用例 + 三档判定 + 端到端五场景全部通过。	2026-09-14 10:17:45 +08:00
ThearchyHelios	4fdd58e3be	运行分级与版本钉死：formal/exploratory、方法卡钉版、口径升版被迫处置 ... formal 运行的全部语义就一条规则：必须引用一个不可变的已发布 WorkflowVersion（按 graph_hash 钉住）；传裸 graph 的运行自动是 exploratory。发布后改图不影响已发布版本——formal 永远执行快照。 子图节点支持 workflow_version 钉版，这就是方法卡的机制核心： 钉住后上游改方法卡不会让口径悄悄漂移。钉住的方法卡出现新版本时， formal 启动被拒，除非节点已声明 upgrade_policy（recompute 回算 / dual 双印 / incomparable 标注不可比，无默认值）；已声明的升版 以 caliber.upgrade 事件记入流水。 发布端点带两级门禁：published 只拦基础错误，governed 额外过治理 lint（禁 supervisor、方法卡必须钉版、agent 不得关闭全部审批、 output 必须声明出具契约）。X-Actor 记录发布人与运行发起人。	2026-09-14 10:14:37 +08:00
ThearchyHelios	2df591d05f	工件库：内容寻址存储、节点输出与工具快照落盘、运行清单哈希 ... 事件流里的输出是给画布看的截断预览，出具溯源需要完整证据。 新增 data/artifacts/ 内容寻址工件库（sha256 即地址，取回时复验哈希， 篡改即报错）；节点完整输出与工具调用快照（query+结果集）自动落盘， 事件只携带工件 id。运行终态对全部事件计算清单哈希存入 Run， 事后对事件流的增删改会与它对不上。 graph_hash 剔除 viewport 后计算——挪画布不改变图的身份。 Run/Workflow/WorkflowVersion/Approval 预置分级与治理列， init_db 附带 SQLite 轻量列迁移。	2026-09-14 10:10:20 +08:00
ThearchyHelios	964eeaa829	AgentLab：可视化 Agent 编排实验台 ... 在画布上拖拽编排 agent 工作流，并实时看着它执行。 后端 FastAPI + LangGraph：把画布 JSON 编译成 StateGraph，15 种节点 （模型/Agent/多Agent、工具/沙箱、分支/循环/子图、记忆/检索/整形、 人工介入/结构校验）。选 LangGraph 是因为可视化编排真正难的是暂停、 恢复和回放，而 checkpointer + interrupt() 正好把这几件事做在了底层。 前端 React + React Flow：节点元数据驱动属性面板与连接桩，运行时 节点高亮、边流动画、卡片内流式 token 全部由同一份事件流驱动。 关键实现： - Agent 内工具审批用 @task 缓存模型调用，interrupt 重放时不重复计费 - 沙箱保持只读根文件系统，代码经 exec+base64 写入（put_archive 会被 只读容器拒绝），断网、非 root、内存/CPU/超时限额 - 检索为向量与 BM25 混合，本地哈希 embedding 零配置可用 - 分支条件走 AST 白名单求值器；HTTP 工具逐 IP 拦截内网与元数据地址 - Mock provider 让无 API Key 也能跑通完整链路 7 个内置模板全部冒烟通过，含真实模型端到端验证。	2026-09-13 17:27:00 +08:00