|
|
d3eaff46f1
|
fix(lua): 内置适配器按内容自动更新，替代「文件已存在就跳过」
## 原机制是这次全部误判的根源
if _, err := os.Stat(dstPath); err == nil { continue }
**升级二进制永远不更新已部署的适配器文件。** 于是"改了仓库 ≠ 生产生效"，
而这个机制让同类问题可以长期潜伏：
2026-08-26 15:46 生产 openai.lua 手工补上 stream_index 透传
2026-08-26 16:10 ddef195 提交，说明里写了但代码没改这个文件
修复当天先在生产落地、32 分钟后才提交入库（漏了这个文件），此后一个月里
两端都没人发现 —— 生产不报问题（它有），仓库的判据也测不到（直接构造 Go
结构体，绕过适配器）。而"升级不覆盖"意味着即使仓库补上修复，已部署的
老实例也不会拿到。
## 新判据（按内容，不按存在）
文件不存在 ⇒ 写
有历史清单且盘上 == 上次内嵌 ⇒ 覆盖（只是没跟上新版本）
有历史清单但盘上 != 上次内嵌 ⇒ 不动 + 日志（用户改过）
无历史清单（首跑/从旧版本升级） ⇒ 不动，只补缺失文件（与旧行为一致）
"上次内嵌的版本"记在 `DataDir/adapters/.bundled`（`<name>\t<sha256>`）。
⚠️ 为什么不能无条件覆盖：adapter_path 是可配置项，用户可以把 adapter_path
指向自己维护的适配器。静默覆盖等于丢弃他们的修改，而且**没有报错**。
## 判据（两个方向都要测）
- TestWriteBundledAdaptersSkipsUserModified 用户改过的**必须保留**，
且改完仍能正常加载（fixture 必须功能完整，否则会因为缺钩子函数而失败 ——
那是 fixture 问题，不是保护逻辑问题）
- TestWriteBundledAdaptersUpdatesStale 落后于新内嵌的**必须被更新**，
且**幂等**（三跑不再改写任何文件）
★ 第二条是必要的：只测保护的话，**一个"永远不覆盖任何文件"的实现也能全绿**
—— 而那正是要修的病。
## 代价（必须知道）
**升级到本版本的这一次，已部署实例的适配器不会更新**（没有历史清单可比）。
从第二次升级起自动生效。要立刻生效就删掉 DataDir/adapters 让内核重新解包。
对本次修的 8 个适配器而言：生产此刻用不到（三个源 llmsproxy/visionllm/
justworker 全是 openai.lua），所以不影响运行；将来启用 deepseek 等源时，
自然就是修复版。
## 顺带
`bundledAdapterNames` 从 writeBundledAdapters 里提出来成包级变量 ——
writeBundledAdapters 与体检判据共用，避免两处各写一份而漏掉某个
（漏掉的后果是该适配器永远不会被更新）。
|
2026-09-27 18:46:51 +08:00 |
|
|
|
66200ff226
|
test(lua): 补适配器 stream_index 透传判据 + 全适配器体检
## 先纠正一件事：这个修复在生产上早就存在
最初我判断"`openai.lua` 缺 stream_index 透传、批内并发在生产走不通"，并据此
写了实现。**核对生产实例后，这个判断是错的**：
生产 /home/newqqagent/adapters/openai.lua 130 行 含 stream_index
仓库 950b21b^ 128 行 无 stream_index
生产那份的注释是「透传上游分片 index：并行多工具调用时内核按它区分归属桶」——
简洁，与本提交新增的长注释不同。**也就是说仓库版本落后于生产，生产一直没这个
问题。** 我修的是"仓库与生产的差距"，不是"生产正在发生的故障"。
## 真正缺的是判据
`internal/agent/core/stream_index_test.go` 的
TestAccumulateStreamParallelToolCallsByIndex 直接构造 Go 结构体
`agentAPI.StreamChunk{...}`，**不经过 Lua 适配器** —— 所以"适配器有没有把
index 透传出来"它永远测不到。生产有、仓库没有，判据也发现不了。
而提交 ddef195（2026-08-26，"流式并行 tool_call 按 JSON index 分桶"）的说明里
写着「openai.lua 输出 stream_index 字段」，Go 侧也加了
`StreamIndex int json:"stream_index,omitempty"` 并注明"lua 适配器以
stream_index 键透传" —— 但那次提交**根本没改 openai.lua**（6 个文件里没有它）。
说明与实现不符，而没有任何判据能发现。
## 本提交做的事
① 让 openai.lua 与生产一致（补 stream_index 透传），并说明为何缺它会静默失效：
多个分片全部并到槽 0 → argsRaw 混拼 → 每个工具报"参数不是合法 JSON"，
而**工具一次都没真跑过**。单工具时上游 index 恒为 0，缺省也是 0，
所以问题只在"一轮多个 tool_call"时显形。
② 新增 internal/lua/adapter_streamindex_test.go，**真正加载并执行内嵌的
openai.lua**（复用 VM 的真实路径），三条判据：
- TestOpenAIAdapterPassesThroughStreamIndex 3 个 tool_call 的
stream_index 必须是 0/1/2
- TestOpenAIAdapterKeepsContinuationFragment 续传分片（只有 arguments、
没有 name）的 stream_index 必须正确 —— 它是分桶的**唯一**依据
- TestAllBundledAdaptersStreamToolCallStatus 全 10 个适配器体检
★ 第三条刻意**不**用 t.Skip 掩盖不支持的适配器 —— 早期版本一律 Skip，结果
"完全不支持流式工具调用"也会让整体显示为绿，而绿会被误读成"都支持"。
现在分类记录：openai ✓ / kimicode+server 透传嵌套形态需另修 /
其余 7 个未产出 tool_calls。
③ 体检顺带暴露的、与本提交无关但已记录的问题：
- **仓库 vs 生产漂移无判据**：仓库适配器落后于生产时，只有靠人工对比才发现
- **部署陷阱**：vm.go writeBundledAdapters 是
`if 文件已存在 { continue }`，升级二进制**不会更新已有适配器文件**。
这可能正是"仓库缺透传却没人发现"的原因之一
|
2026-09-27 17:48:16 +08:00 |
|
