 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
|
c8393c3c6b
|
移除仓库中的商业数据：删掉 21 个相关用例，其余标识符脱敏
这个仓库是公开的，而历史里带着一份客户 BI 仓的逐字转储：ANALYTICS（原
schema 名）下 53 张视图名、实测行数、字段结构表，外加一句写明取数方是谁
的注脚。还有一处把真人姓名和工作单位写进了检查脚本的断言里。这些都不是
化名，是能直接拿去对库的东西。
按"含敏感词的测试直接删"处理，共 21 个用例：
test_agent_tool_loop.py 整个文件（2 个，agent 工具循环的真图验收）
test_conversations.py 9 个（会话 CRUD、历史文本、上下文进 prompt）
test_datasource.py 5 个（探查失败的实情、候选 schema 提示）
test_copilot_context.py 3 个（数据源摘要的限定名）
test_review.py 1 个（干净运行无信号）
test_tool_args.py 1 个（call_tool 端到端）
辅助函数和产品源码不在"测试"之列，改为脱敏——否则删一个 _seeded 会连带
带走 8 个没被点名的用例。标识符一律换成中性名：shop→shop、
ANALYTICS→ANALYTICS、prod_shop→prod_shop、真人姓名→张三。
markdown 样本里那两条不是改标识符能解决的：行数、字段结构、业务域描述
整段都是客户的。换成同构的合成内容——领域换了，markdown 构造逐项对齐
（标题层级、有序/无序列表、三列表、带 inline code 的单元格、引用块），
渲染器的覆盖面没有变窄。check-stream 里那句"用的是真实输出"跟着改成实话。
286 → 265 passed，差值正好是删掉的 21 个。tsc 干净，decode / stream / ui
三个 check 不回归。
历史里的同一批内容另行用 git filter-repo 处理。
|
2026-09-20 22:52:28 +08:00 |
|
|
ThearchyHelios
|
71561a0133
|
探查失败不再伪装成"还没探查"：把实情和下一步交给 agent
从 run 554a0f92 查出来的。那次问「userID=2 是谁」，9 次工具调用花掉 6 次、
前 29 秒没碰到一点真数据：
+ 2.1s db_schema → "还没有探查过结构，请在设置页里执行一次"
+ 4.9s db_schema ×7 个猜的表名 → "没有 user / users / member / …"
+ 7.7s SELECT 1 → 不信任前面的结果，先探一下连通性
+12.8s information_schema.tables ┐
+18.3s information_schema.tables ├ 自己把 schema 重建一遍
+21.5s information_schema.columns ┘
+29.2s 终于开始查真数据
根因：shop 的探查**失败过**（Lost connection to MySQL server during query），
但失败被存成了一个"成功但没表"的缓存，schema_synced_at 照常盖戳：
{"tables": {}, "total": 0,
"error": "OperationalError: (2013, 'Lost connection...')",
"available_schemas": ["prod_shop", "shop_dev", "toolsdb", …10 个]}
于是三处同时说假话：界面显示"结构未探查"、工具对 agent 说"还没有探查过"、
而那 10 个候选 schema 就躺在缓存里没人交出去。**用户明明点过探查，是超时了。**
**分清"还没探查"和"探查失败了"。** introspect 的结果加 failed 标记；
失败照样把缓存存下来（候选是下一步的线索），但不盖"已同步"的戳；
界面把红字和候选列出来；探查按钮的提示也分清是超时还是 schema 填错。
**给 agent 一个它做得到的下一步。** 以前那句"请在设置页里执行一次结构探查"
——agent 进不了设置页。现在换成实情 + 候选 schema + "不要猜表名，直接查
information_schema / sqlite_master"。那条自救路线 agent 最后也走通了，
只是自己摸索了三轮才找到，直接告诉它就行。
describe_table 同样：缓存空的时候说"数据源里没有 user"是在误导，真相是我们
什么都不知道。那次一口气问了 7 个表名，收到 7 条一模一样的
"没有 X。现有的对象：（还没探查过结构）"，白花一整步。
顺带把逐表反射换成 SQLAlchemy 2.0 的 get_multi_*，但**别指望它治超时**：
实测 60 张表逐表 121 次往返、批量 122 次——反射缓存本来就把 get_columns 和
get_pk_constraint 合并了，而 MySQL 方言压根没实现 get_multi_*，落到基类还是
每表一次 SHOW CREATE TABLE。换它是因为这是 2.0 的正经接口、少三层
try/except，不是因为它快。shop 那次超时多半是偶发的，所以真正的对策
不在那儿，在"失败要如实记成失败"。
重新探查了一次 shop：153 张表、38 秒、成功。之前 agent 要花 6 次调用、
29 秒拼出来的东西，现在工具描述第一眼就给了。
验证：后端 269 passed（test_datasource.py 新增 4 条，守"失败不能被说成没探查过"
和"给 agent 的下一步它做得到"）；tsc 干净；三个 check 不回归。
|
2026-09-20 18:05:11 +08:00 |
|
|
ThearchyHelios
|
72de33c03d
|
schema 发现改成看事实，不再靠黑名单猜
起因是一个合理的质疑：这套 schema 处理是不是只对那一个 Oracle 有效。查证下来
"schema" 在四家里根本不是同一个东西——MySQL 的 schema 就是 database
（SHOW schemas），Oracle 的 schema 就是 user（all_users），PG 是库下面的
命名空间（pg_namespace），SQLite 只有 main。SQLAlchemy 抹平了调用方式，
没抹平语义。
## 黑名单方案实测不可用
原来靠一张硬编码的系统 schema 名单过滤。在真实 Oracle 上：94 个用户过滤完还剩
75 个（anonymous、C##OGGADMIN、infa96_domain、xs$null…），人在里面根本找不到
那两个业务 schema。名单再怎么补也补不完——这是在猜，而不是在看。
改成看事实：统计每个 schema 下有多少表/视图，有东西的才留下并按数量排序。
两条路径覆盖全部支持的库——information_schema 是 SQL 标准（MySQL/PG/SQL Server
都有），Oracle 不遵循这条标准，走它自己的 all_tables/all_views。不用"逐个
schema 调 get_table_names"的通用写法：94 个 schema 就是 94 次往返。
黑名单保留但降级为辅助：系统 schema 的对象数往往很大（SYS 有 1871 个），
光靠排序压不下去。
实测：94 个用户 → 2.3 秒收敛到 ANALYTICS、STAGING 两个业务 schema。
## schema 填错时给可选项，而不是抛驱动异常
大小写、拼写、或者根本不知道该填什么，都是高频事故。原来直接把
OperationalError 抛出去，等于让人自己猜。现在先看连接本身好不好：能列出候选
就说明只是 schema 不对，这种情况返回空结构 + 候选列表，摘要里直接写
"该账号名下没有对象，数据可能在这些 schema：ANALYTICS、STAGING"。
## 覆盖
SQLite 没有 information_schema，统计路径安静降级（实测）；没有 schema 概念时
qualified 不硬拼前缀，有 schema 时必须带（Oracle 上少了就是 ORA-00942）。
新增一条用例守着"加新数据库类型时别忘了补统计路径"，漏了就会退化回黑名单猜测。
MySQL / PostgreSQL 手上没有实例，走的是 information_schema 标准路径，
代码路径与 Oracle 共用，但未实测——这点在 README 里会标明。
|
2026-09-17 11:50:16 +08:00 |
|
|
ThearchyHelios
|
a127f7049c
|
真实 Oracle 生产库跑通，修掉三处只有连真库才暴露的问题
在一个企业 BI 库（SAP 物料/采购/凭证 + MES 生产 + IOT 设备）上端到端验证。
连接 3 秒握手，thin 模式，确实不需要 Instant Client。三处问题只有连真库才看得见：
## options.schema 被当成驱动参数拼进了连接串
我自己引入的：build_url 把 options 里所有剩余的 key 都拼成 query 参数，
而 schema 是探查配置不是连接参数，于是 ?service_name=BI&schema=ANALYTICS 直接
被驱动拒掉。options 里混着两类东西，现在显式区分。
## 只读账号名下一张表都没有
这是企业环境的常态而非例外：TAIKE 名下只有 2 个 SYNONYM，数据在 ANALYTICS
(51 个视图) 和 STAGING(9 张表)。默认探查当前用户 schema 得到 0 张表，而原来
只会安静地返回一个空壳——用户完全不知道下一步该干什么。
现在：options.schema 可指定探查目标；探不到任何对象时自动列出可访问的非系统
schema（排掉 MDSYS/CTXSYS/XDB 那一屏 Oracle 内部对象），摘要里直接告诉
Copilot"该账号名下没有对象，数据可能在这些 schema"。
## 表名不带 schema 前缀直接 ORA-00942
只读账号访问的是别人 schema 下的对象，SELECT * FROM V_TRIP_FACT 必然失败。
schema_cache 里为每个对象记 qualified 全名，summary / table_names /
db_query 的工具描述统一用全名——模型照着写就不会漏前缀。describe_table 则
反过来放宽：全名、裸表名、大写形态都认（Oracle 惯用大写，SQLAlchemy 返回小写）。
## 实测
探查 53 个对象 7.8 秒，摘要约 2000 token（含一个 273 字段的宽视图），在预算内。
Oracle 的中文表/列注释正确读出（"不合格数据明细表"、"工厂代码，复合主键之一"）。
agent 自主查询 8 轮：列对象 → 挑 3 个 MES 视图看结构 → 逐个 COUNT + MAX(load_time)
→ 补查业务时间字段，最后报出 v_demo_table 有 365,633 行、最新数据
2026-09-17 06:53。全程自己带对了 schema 前缀。
安全边界在生产库上复验：
- UPDATE / DELETE / DROP 全被拒，数据未变
- 19.87 亿行的 TG_ECC_MSEG 裸查 SELECT *：0.7 秒返回 200 行即断开，
流式读取没有把表拉回来
- 203 列宽表的字节上限在第 37 行触发
凭据只进加密库（Fernet 密文，已核验库中无明文），不在仓库、提交历史或任何输出里。
|
2026-09-17 11:44:22 +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 |
|