 ThearchyHelios
|
277982ead3
|
普通用户建应用（后端）：
- 蓝图：bp_* 操作和逐卡白名单、蓝图检查、留痕、按蓝图判权限；五个场景模板加自由形（骨架、关节、应用骨架、定时任务），实例化与骨架比对；BlueprintApplier / TemplateApplier（只收模板声明过的关节）与自查；look 新类别口径卡；蓝图对话和填关节两个流式接口，不同组的关节并行填、出错的组串行重试；模板列表
- 试运行与发布单：四种起点（对话、模板、问数据的一轮、已发布版本）；试运行是探索运行，草稿应用按这次运行解析、印章写试运行，流程类派给自己、不触发升级；发布单九步、预检只读、每步留痕、停下后接着做、核对卡片指纹和应用管理权、启动时整理中断的单；白话层覆盖全部问题编号
- 记录表与文件：平台托管只追加的记录表、按高水位固定数据、连接上的临时视图做行级可见、写入走动作（records_append）、表版本在发布时切换、草稿不影响线上、记录列表遮敏感列；文件按哈希存、两步上传、提交时绑定运行、下载按读权限、清理、file_text、按配方导入一期（table_import_period）
- 个人应用：存成个人应用（问数据的约束）、刷新（遮罩、只读、每日上限）、只有拥有者看得见、提交审核与共享副本、开关下发到认人接口；页面编辑的候选；隐藏组件不下发；三条新检查
|
2026-10-15 12:09:29 +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
|
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
|
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
|
26ff8e1e06
|
只读数据源真的只读了：WITH … DELETE 不再从首关键字下面钻过去，连接本身也写不进去
守卫只看首关键字，而 with / pragma 都在只读白名单里。在只读的 SQLite 源上
实测：`WITH k AS (SELECT 1) DELETE FROM t` 被放行，5 行删得只剩 2 行；
`PRAGMA user_version = 7` 也写进去了。调用方只看到一个 ResourceClosedError——
pysqlite 只在 INSERT/UPDATE/DELETE 开头的语句前隐式开事务，WITH 开头的直接
自动提交，连接关闭时的回滚兜不住。Excel/CSV 上传生成的正是这种 SQLite 源。
两层一起收：
守卫：以查询开头的语句（SELECT / WITH / EXPLAIN）要把正文扫一遍，先抹掉注释
和引号里的内容，再找写关键字（DELETE、UPDATE、INTO、FOR UPDATE、EXPLAIN
ANALYZE 里的语句……），关键字后紧跟 ( 的是同名函数不算（MySQL 的 INSERT()、
TRUNCATE()）。PRAGMA 改成只读白名单，`= 值` 和 `(值)` 两种赋值写法都拦。
另收一小撮有副作用的函数，其中 set_config 必须拦：PG 真库实测，它能把连接层
的只读关掉，同一连接的下一个事务就能写。函数名加引号、dblink 另开连接这两种
绕法也补上了。is_write 与只读判定共用一份判定，免得审批那道门另有一套口径。
连接层：只读源连接时就只读（engine_args）。SQLite 以 mode=ro 打开（file: URI，
路径带空格、中文、# 都测过）；PostgreSQL 设会话默认事务只读；MySQL / MariaDB
设会话事务只读。Oracle 没有会话级开关，只剩守卫——README 写明请配只读账号。
真库验证（临时实例，已清理）：PostgreSQL 18 与 MySQL 8.0 上，DELETE、WITH … DELETE、
PG 的数据修改 CTE、nextval、EXPLAIN ANALYZE 绕过守卫直连执行，都被数据库以
只读事务拒绝；可写源不受影响。
测试：守卫新增 33 例（藏在查询里的写、会写的 PRAGMA、同名函数与引号标识符不误杀），
去掉修复重跑是 17 例失败；test_readonly_source.py 6 例（当初那条绕过、绕过守卫
直连写、中文路径、可写源不受波及、各库的会话参数）。297 → 334 passed。
顺带查到但没在这里修的：可写源上的写操作既不审批也不生效——is_dangerous_call
全仓库没人调用，而 run_query 从不 commit，写完就被回滚。两件事必须一起修
（先接审批再让写入生效，反过来就是一个无审批写库的窗口），放在审批统一那一步。
|
2026-09-25 14:44:56 +08:00 |
|
|
ThearchyHelios
|
39e7a5b014
|
数据源接入：MySQL / Oracle / PostgreSQL / SQLite
阶段①。产品原先能取数的只有 http_request 和沙箱里自己写代码——面对"分析上季度
华东区销量下滑"这类需求，用户得自己知道数据在哪张表、字段叫什么，再手写 SQL 塞进
代码节点。最难的部分留给了用户。
## 连接层（app/data/）
方言差异全收敛在 engine.py 一处：Oracle 要 service_name/sid、MySQL 要 charset、
各家默认端口不同。三个驱动都是 asyncio 原生且免装客户端——oracledb 走 thin 模式，
不需要 Instant Client。密码复用 app/core/crypto 的 Fernet，和 Provider 同一套；
build_url 默认把密码替换成星号，日志和错误信息里用这个版本。
introspect.py 产出两种粒度：summary()（表名+代表字段，几百 token，给 Copilot 的
system prompt 用）和 describe_table()（单表完整字段，按需取）。分两种是因为一个
中等业务库全量塞进 prompt 轻松几万 token，既贵又会把真正的需求淹掉。
## 守卫（app/data/guard.py）
这是唯一不能出错的地方：SQL 由模型生成，模型会写出什么事前无法穷举，防线不能
建立在"它应该不会这么干"上。三层：
- 只读判定用**白名单**而非黑名单——黑名单永远漏，MERGE/CALL/GRANT/各家私货写不完
- 多语句在到达驱动前就断掉，不赌驱动默认只跑第一条（MySQL 开了
CLIENT_MULTI_STATEMENTS 就会全跑）
- 行数/字节/超时三重上限，一条 SELECT * 不该把内存和模型上下文一起打爆
刻意不引 sqlparse：完整解析 SQL 方言是无底洞，而这里的判断很窄——"首关键字是
什么"和"有没有第二条语句"。窄问题用窄解法。难点是不能误杀：`SELECT ';'` 只是
一条语句，简单 split(";") 会把它切两半然后拒掉，那比漏杀更让人无从下手。
## 工具（app/tools/datasource.py）
每个数据源动态生成一对 db_query__<源> / db_schema__<源>，而不是一个通用工具带
datasource 参数：工具名自带语义，模型不会把查销售库的 SQL 发给财务库；description
里直接塞表清单，省掉"先问有哪些表"那一轮。接进 registry.build_tools 作为第四来源
（前三个是内置/MCP/自定义）。
查询结果落 put_json(kind="query_snapshot")，把 SQL 原文 + 结果集 + 数据源一起存，
出具体系的数字回指能下钻到"这个数是哪条 SQL 查出来的"。
## 实测
真实 SQLite 业务库（600 行订单，埋了华东 6 月断崖的信号）+ 真实模型：
agent 8 轮自主查询——列表 → 查三张表结构 → 探数据时间范围 → 查地区维度 →
按月汇总 → 按地区+月份下钻，准确定位到华东 6 月从 1187 件跌到 354 件。
只读守卫在 agent 路径上同样生效（UPDATE/DROP/多语句全被拒且数据未变）。
测试 55 项：守卫 30 项（含"字符串里的分号不能误杀"）、连接与探查 15 项、
URL 构造 6 项、Copilot 流式 4 项。
|
2026-09-17 10:39:23 +08:00 |
|