3 Commits

Author	SHA1	Message	Date
ThearchyHelios	0f32b8335e	应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）	2026-10-14 20:05:23 +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	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