mirror of
https://github.com/ThearchyHelios/AgentLab.git
synced 2026-11-15 03:41:58 +00:00
ThearchyHelios
a6ee525148
阶段②。之前 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 项。