 ThearchyHelios
|
76cb4d2845
|
M4：db_schema 认整个写成一个字符串的 JSON 数组的表名
验收时盲算、反方审稿的模型把 table 写成 '["orders", "stores"]'（一个字符串），工具只按逗号拆，回「中没有 ["orders"」
「中没有 "stores"]」，两张表明明都在，模型重试几轮才改成不传 table。表名参数的解析抽成 _schema_tables：元素都是
字符串的 JSON 数组（整个作为一个字符串传进来，或者数组里的一项）按数组认，其余照旧按逗号拆；不是 JSON 的
（[orders]、单引号）、元素不是字符串的照旧。只动 db_schema 这一段，查询工具不动。
|
2026-10-07 00:02:15 +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
|
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
|
c02ef189bb
|
工具调用失败能自救；agent 改成一步一个工具
起因是一条没人看得懂的报错：
工具 db_query__shop 执行失败：
_make_query_tool.<locals>._run() got an unexpected keyword argument 'query'
参数名写成了 query（它叫 sql），而 call_tool 对动态工具是裸 **args 展开的，
跳过了 args_schema —— pydantic 那句"缺少 sql 字段"漏成了只剩内部闭包名的
TypeError，既指不到是哪个工具，也说不出该填什么。同一个函数里内置工具那条
分支本来是校验的，两条路径不一致。
registry 里补上 prepare_args / describe_args，两条路径共用：
- 候选唯一时（多一个不认识的、少一个必填的）改名重试，并发一条 warn 说破
—— 配置里那个错名还在，替它跑通一次却不吭声，下次照样踩
- 有歧义就不猜，报错改成"参数不对：query 不是它的参数；缺少必填参数 sql。
它接受：sql（必填，字符串）— 要执行的 SQL…"，模型照着这句就能改对。
这才是失败之后真正能自愈的重试
- 顺带堵了一类静默失败：pydantic 默认把认不出的键悄悄丢掉，全可选 schema 上
{"tabel": "orders"} 会"成功"执行一次什么都没查的调用
agent 循环默认改成串行：一轮只调一个工具，看到结果再想下一步。并行更快，但
一批调用中间没有任何新的思考——第二个是照着"还没看到第一个结果"时的判断发出
去的。节点上留了「并行执行工具」开关。两个必须守住的点：没执行的调用绝不发
tool.start（前端靠 call_id 配对，发了没结尾的 start 会永远转圈），但必须各有
一条配对的 tool_result（少一条下次调用直接 400）。
交错思考跟着补上。4.6 起 adaptive thinking 自带交错，不需要也不该挂 beta
header（Opus 4.6 上手动模式压根没有交错）；4/4.5 那一代要手动开 thinking +
interleaved-thinking beta，光挂 header 是一条什么都不做的空设置。开了 thinking
就不能再传 temperature，这一代本来是收的，漏了就是 400。
还有两处是串行带出来的，一并治了：
- 步数用完时收尾取的是 messages[-1]，而那往往是给模型看的 ToolMessage。
真漏到用户面前当过答案（run dd9927e6）：一句"本轮只执行了第一个工具"冒充
结论。改成只取模型自己说过的话，并把"步数用完了、去调大最大步数"附在后面
- db_schema 一次能问多张表。一次调用就是一步，逐张问 6 张表就是 6 步——
实测 8 步的运行里 7 步花在这上面，最后只剩一步真查数据
|
2026-09-18 17:57:20 +08:00 |
|