 ThearchyHelios
|
eddeded2a4
|
全栈安全加固、性能提速与架构演进：连接池与沙箱止血、双路混合检索、多版本归档及前端分包治理
- 第一批（安全加固与生命周期止血）：隔离测试宿主机密钥与 .env 泄漏；修复 SQLite 取消查询挂死、:memory: 连接池报错与 EngineCache 世代竞态；补齐运行与评测删除时的 Checkpointer 线程、Artifact 磁盘文件与无主附件回收；加固三套沙箱路径越界、进程组清理与 Seatbelt 数据目录隔离，封堵 SSRF IPv4-mapped IPv6 元数据绕过与响应体 OOM；修复推理模型多轮 reasoning_content、结构化输出 Token 漏计与缓存折扣计费
- 第二批（数据库/集群/问数提速与首屏分包）：补齐核心表索引与 SQLite WAL 调优，列表接口按需 defer 大列，收敛启动扫描并打通跨进程 slot 槽位唤醒；优化跨源全局选表、哈希桶数字绑定、流式 CSV 导入及多方言分析算子；剥离首屏静态引入的 @xyflow/react 与全局样式（首屏主包降至 461.59 kB），补充流式 rAF 攒批、Store 精细订阅与表单无障碍绑定
- 第三批（架构演进与工程自动化闭环）：记录库超挂接阈值历史版本自动增量归档至单库多表（解除 SQLite 10 库 ATTACH 硬上限）；重构知识库为词面 BM25 与全集合归一化向量矩阵真·双路独立召回并支持游标分批重建；升级多方言感知 SQL 模板词法分析（E'...' / $$...$$ / q'[...]' / # / 嵌套注释）与 Decimal / bool / NaN 参数校验，消除 ledger 层对 api 路由层的反向依赖；拆分 3101 行 CaliberDrafts 页面为 7 个领域子模块，消除检查脚本本机路径硬编码并新增 GitHub Actions CI 门禁与三批回归测试套件
|
2026-11-13 14:51:36 +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 |
|
|
ThearchyHelios
|
f43f56abb7
|
把 Copilot 的思考显示出来：模型一直在想，只是被丢掉了
用户问能不能看到"正在理解需求、规划步骤"里面发生了什么。查下来是这样：
模型确实在想，reasoning 花了实打实的 token，但一路上被丢了三次。
1. langchain 的 ChatOpenAI **故意**不保留第三方的 reasoning_content——它的
文档原话是 "Non-standard response fields added by third-party providers
are not extracted or preserved"，建议换 ChatDeepSeek 之类的专用包。可
"用哪个供应商"在这个产品里是用户在设置页配的（DeepSeek / Qianfan /
vLLM / OpenRouter 都可能），为每种装一个专用包不现实。在 factory 里
子类化捞回 additional_kwargs，只加字段，不动 langchain 对正文的处理。
2. thinking_text 只认 Anthropic 的 thinking 块。补上兼容端点那一种。
3. 前端把一段思考的标题固定成开头 60 个字。思考是流式的，开头往往是
"用户想要一个……"这类复述，之后几十秒里它一直在推进——固定显示开头
等于把一段活的叙述冻在起点上，看着就像卡住了。改成：还在想的时候显示
最新一句，想完了换回开头那句（那时它是一条历史记录）。
实测一次真实生成，60 秒里侧栏逐句变化：
3s 可用数据源 bi
9s 人工节点 approve 模式，审核
18s 我们可以用 db_query__sales 执行 SELECT COUNT(*) FROM orders 等
36s 更合理：rejected -> query_agent（重新
45s 对于 bi 有 53 个对象，靠
57s （plan 到达，思考收尾，换回开头那句）
顺带运行期的 LLM 节点也跟着有了思考——走的是同一个 thinking_text，之前
同样只有 Anthropic 系才有。已验证流式合并后思考连成完整一段，不是只剩
最后一片。
tests/test_thinking.py 守两种形态、合并、以及"不产思考的模型不硬凑"。
check-decode 补 5 条守"还在想显示最新一句、想完了换开头"。
|
2026-09-18 09:55:42 +08:00 |
|