yilunjiang/AgentLab
1
0
Fork 0
mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 05:31:59 +00:00
Code Issues Packages Projects Releases Wiki Activity
87 Commits 4 Branches 0 Tags
e10c4f23fc08daeb5673f7bf92fd1e37f810eda1
Commit Graph

8 Commits

Author SHA1 Message Date
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 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 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 7b04162540 Excel/CSV 变成能查的表、PPT 读得进来、跑挂了能接着跑、文档和工具有了地址 
四件事，其中 Excel 那条不是"多支持一种格式"，是补一个和地基冲突的缺口。

**Excel / CSV → 可以用 SQL 查的表。**

这个项目有条不可回退的决策：叙述层无算术权限，所有算术下沉到 SQL 或口径卡，
叙述只能引用（engine/issuance.py）。表格传进知识库只能被切块检索，数字就成了
模型从片段里"读"出来的——复核层拦得住凭空多出的数字，拦不住"从一堆片段里
读错了一格"。所以表格必须变成表。

不新增数据源类型：kind='sqlite' 早就支持，build_url 拿 database 当文件路径。
落成 .db 文件再建一条 DataSource 指过去，下游一行都不用改——SQL 守卫、结构
探查、db_query__<name> 工具、查询快照进工件库、Copilot 的数据源清单，全都白拿。
建表走 sqlite3 直连而不是 run_query：guard 的 _ALWAYS_DENIED 里有 create，
那是对的（模型不该能建表），而导入是我们自己发起的可信操作。

四个语义是这块的全部分量：

- **类型要推，不能全存 TEXT。** SQLite 是动态类型，但列亲和性决定排序和比较：
  整数列落成 TEXT 的话 '10' < '9'，SUM() 在混入空串时静默出错，而没有任何
  地方会报。逐列扫描推断 INTEGER/REAL/TEXT，空单元格存 NULL 不存 ""，
  日期存 ISO（字典序恰好等于时间序）。测试里那条 ORDER BY 要是 9<10 而不是
  '10'<'9'，守的就是整块的意义。
- **表头取第 1 行，但不猜。** 不做"自动找表头"的启发式：猜错的表现是列名变成
  一行数据，没有任何征兆，直到某天有人发现汇总一直少一行。改成 header_row
  可填，并把推断出的列名和类型当场回显——错了一眼看见。
- **同名重传原地替换，id 和 name 都不变。** 名字会成为工具名（db_query__sales）
  而工具名写进了保存过的图，另起一个 sales_2 等于悄悄让那些图失效。
- **中文原样保留。** 一开始把 sheet 名清洗成了 ASCII，结果「明细」「汇总」都变成
  sheet、sheet_2，模型和用户都认不出哪张是哪张——而 SQLite 的标识符本来就允许
  非 ASCII，那道清洗纯属自找麻烦。现在只替换会断句的空白和标点。

实测：两 sheet 的中文 xlsx → 两张表，金额列 INTEGER，跨表 JOIN + SUM 跑通，
Copilot 的工具清单里带着表名。CSV 按 utf-8-sig / utf-8 / gb18030 依次试——
GBK 的 CSV 是 Excel 另存为的默认行为，按 UTF-8 读会得到乱码列名，而乱码不报错。

知识库那边顺手改了指路：传 .xlsx/.csv 进去不再说"不是 UTF-8 文本"，
而是告诉你该传到数据源那边、以及为什么。

**PPT。** 文本框和表格分开取（表格的 has_text_frame 是 False），幻灯片之间
留空行当段落边界。.ppt/.doc/.xls 这些老二进制格式认出来再拒，说清楚"另存为
新格式"——以前它们会掉进"不是 UTF-8 文本"那个兜底，对着一个 .ppt 说这话，
用户根本不知道该怎么办。

**问数据页的「接着跑」。** 挂了那一轮不该只剩一行红字：断点一直在 checkpoint
里躺着。按钮挂在 approvalsFor 那个每轮插槽里（本来就托着「看执行过程」和
「跑一下」）。不带图——问数据页改不了图，这里就是"用原来的配置重试失败的
那一步"，配置本身错了要到画布上改。实测：续的是同一次运行（8→13 条事件），
只跑了 lp 往后，轨迹里有 run.resumed。

**文档 / 工具的地址。** /knowledge/kb/:docId 是新页面——文档原来连详情视图都
没有，而切块这层做了不少事（按行边界留重叠、跨块续表头），结果一处都看不见。
现在逐段列出来带字数和 token 数，还标出"这份文档里混着两个模型建的向量"
（换模型只重建了一部分时真会发生，而那会让这部分内容悄悄退回关键词检索）。
新增 GET /kb/documents/{id}。工具那边 tab key 从 tools 改成 library，
否则地址是 /tools/tools/<id>。

验证：后端 265 passed（新增 test_tabular.py 16 条）；tsc 干净；三个 check 全过，
check-ui 补了文档/工具两节；四块都在真浏览器/真后端上端到端跑过。
开发库里造的演示数据源、会话和运行已清干净。
 2026-09-20 16:19:07 +08:00
ThearchyHelios a6ee525148 Copilot 编排期看得见数据库了，附带修一个让非流式生成整体失效的 bug 
阶段②。之前 agent 是运行时才摸索表结构，每跑一次重探一遍——慢，而且同一张图
两次运行走的 SQL 可能不一样，没法钉口径。现在 Copilot 建图时就知道有哪些库、
哪些表，生成的 SQL 直接能跑。

## 先修一个更要紧的：非流式生成的 config 全是空的

GRAPH_SCHEMA 里 config 写的是 {"type": "object"}，没有 properties 也没有
additionalProperties。不少 provider 的结构化输出实现遇到这种 object 会按
"不允许额外字段"处理，于是模型填好的 config 被整个过滤成 {}——生成的图每个
节点都是空壳，一提交就挂在"工具节点还没选工具"。

config 的键随节点类型千变万化（tool 有 tool/args，code 有 language/code…），
没法枚举成 properties，只能显式声明 additionalProperties=true。流式那条路径
走操作流协议、不经过 structured output，所以这个 bug 一直藏着没露头。

## 注入什么

- 工具清单补上动态的 db_query__<源> / db_schema__<源>。all_specs() 只有静态
  注册的内置工具，不补进来 Copilot 根本不知道这些工具存在，只会退回让用户自己
  写 SQL 的代码节点——接了数据库等于白接。
- 数据源摘要（含 schema 全名），外加四条写 SQL 的硬性要求。这几条都是真实
  踩过的：漏 schema 前缀在 Oracle 上直接 ORA-00942，写惯 MySQL 的模型会顺手
  写 LIMIT，分号拼接会被守卫拒掉。

## token 预算：按对象数自适应，不是按字符数

实测一个 53 对象的库，带字段 2715 token、只给对象名 956 token（35%）。
但真正的决策点不是字符数——detail 模式每库只列 40 个对象，多出来的 Copilot
根本看不见。对 53 个对象的库，"40 张表带字段"不如"53 张表只给名字"：
找不到那张表，字段写得再全也没用。截断丢信息比省 token 更糟。

所以先按对象数判断（超过 40 就整体切紧凑），再用字符预算兜多库叠加的情况。
真实库实测：紧凑模式 1219 token，53 个对象全部可见。

## 实测

完整模式：一句话需求 → Copilot 出图 → 不改一个字直接跑通真实 Oracle。
生成的 SQL 三处细节全对——ANALYTICS. 前缀、FETCH FIRST（不是 LIMIT）、单条语句。

紧凑模式（看不到字段）：Copilot 没有硬猜字段，而是生成了一个带
db_schema + db_query 两个工具的 agent 节点，让运行时先查结构再写 SQL——
正是 prompt 里"字段拿不准就先放一个 db_schema 节点"那条。跑通，结论正确。

测试 72 项。
 2026-09-17 12:16:54 +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