|
|
a02d8b00a5
|
feat(multimodal): 多模态工具移出内核为内置插件 + get_plugin_tools 收编为内核服务
## 背景
README 第一原则：「内核职责限定在 LLM 编排、记忆管理与知识检索；
所有 IO 能力由插件实现」，而「文件读取」正在 IO 列表里。
describe_image / ocr_image / transcribe_audio 读本地文件却住在内核进程内
——无沙箱、无能力面、无审计，正是 capability.go 那套权限梯度要防的事。
## 本次改动
### 1. 多模态工具移出内核（internal/plugins/multimodal）
- 新增内置插件，注册 describe_image / transcribe_audio / ocr_image
- 媒体来源支持 path（设备/工具回传，如 screensee 的 file）与 digest（CAS）
- 失败一律以 error 上抛，不渲染成普通文本（延续 screensee 的失败传播纪律）
- ocr_image 的描述明说「不是专用 OCR 引擎」：它只是用视觉模型读字，
真 OCR 在 internal/nlp 的 ONNX 未接入。名字承诺大于实现会让模型误判精度。
内核侧：删除 media.go 整文件（9 函数，全部零引用）、3 个 dispatch case、
3 个工具定义。
**留在内核**：input 通路（用户直传媒体直接拼进本轮 LLM 请求）——
那是「输入即上下文」，不是工具调用。
### 2. get_plugin_tools 收编为内核完整服务
原先它只收 StageHost + IOManager 两处，而三个媒体工具、memory_*、
knowledge_*、spawn_child 等全是内核 buildToolDefs 里直接 append 的
——一条都数不到。agent 能调这些工具，却调 get_plugin_tools 看不见它们。
- 以 buildToolDefs()（发给模型的那份工具表）为单一真相源
- 新增 builtinToolOwner 显式归属表：内置工具恒为 core
- resolveToolPlugin 的下划线前缀猜测限定在「该前缀是已注册插件」时才采纳，
避免 ocr_image→"ocr"、memory_commit→"memory" 这类幽灵归属（7 处调用点依赖它）
## 判据
新增 plugin_tools_service_test.go、multimodal_departed_test.go、
multimodal/plugin_test.go。三个结构判据经变异自证会红：
1. 提示词改回「请使用 describe_image 工具」→ 仍出现该名 ⇒ 红
★ 这条抓到了真问题：eventloop.go 的媒体提示词仍在叫模型调旧工具名，
而媒体 block 其实已内联给模型，且新工具需要 path/digest（用户直传都没有）
⇒ 模型照做必然失败。已修：改为「已随本消息附上，请直接查看」。
2. 内核为多模态加一个 os.ReadFile → 红（比「名字没出现」更强）
3. core 反向 import 插件 → 红（迁移而非删除，且守住分层）
## 验证
- go build ./... / go vet / go test ./internal/... 全绿
- go test -race ./internal/agent/core/ ./internal/plugins/multimodal/ 无数据竞争
- 部署后：39 插件加载、0 panic/fatal、0 非空 error
- 三个工具注册归属为 plugin=multimodal（不是 inferToolPlugin 猜的 describe）
- graph.db integrity ok，blocks 2787 / relations 980 未动
- 快照 /home/newqqagent/memory/pre-multimodal-plugin-20261006-090541/
- 二进制备份 /tmp/homed.bak-mmplugin
一并包含此前已验证未提交的三处静默失效修复：
- MCP MCPCallResult.IsError 丢失（空结果伪装成功）
- DeleteEntity 谎报删除
- screensee 谎报成功 + 截图诊断（尺寸/magic/sha）
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-10-06 09:07:18 +08:00 |
|
|
|
b90659f212
|
fix(multimodal): 修多模态假成功 + 落地视觉回退链 + see_video 帧数语义
## 起因
生产盲测：模型调 multimodal_see_picture 后声称看到了图，实际一个字
都没收到。工具却返回「[已将图片注入后续对话]」。
链路：core.llm.model=AUTO → llmsproxy 按优先级选 big-pickle(prio=100)
→ 转 opencode zen。llmsproxy 的 opencode.lua 明写着：
-- zen 上游 schema 只接受 text content part（无视觉/音频能力）
if part.type ~= nil and part.type ~= "text" then -- 丢弃
判据：256x256 纯红 PNG，带图与不带图的 prompt_tokens 都是 256。
图片贡献零 token，即根本没进上游。
内核序列化与注入链本身是对的（Message.MarshalJSON 正确产出 content
数组，SetToolBlocks → IOManager → ConsumeToolBlocks → toolMsg.Blocks
全通）。缺的是「主模型能否消费这些块」这一判断——内核此前完全没有
多模态能力的概念（grep supportsVision|multimodal 在 agent/ 零命中）。
这与 v1.0.0 修的 output_send 假成功同类：告诉调用方成功而实际未送达。
## 1. 能力声明
新增 core.llm.sources.<name>.vision / .audio（走既有 sourceFieldDefs，
WebUI 配置页自动出现），types.LLMSource 与 api.BaseConfig 同步加字段。
新增 agentAPI.ModalProvider 接口 + ProviderSupportsVision/Audio 判定：
未实现该接口的 provider 一律按不支持处理。保守侧是刻意的——宁可多走
一次文字回退，也不能把图默默扔给会剥掉它的上游。
为何是声明而非探测：探测需额外真实调用且结果不稳定（取决于 AUTO 当次
路由到哪）；而 200 响应 + 相同 token 数从响应侧无法区分「看到了但没
内容」和「被剥掉了」。
## 2. 回退链（modalfallback.go）
实现了 config/registry.go 里注册但从未被读取的 image/audio
fallback_provider + fallback_model（此前 0 处读取点）。
prepareToolBlocks 在 process.go 注入前判定：能直视就原样透传；不能就
调声明了该能力的源转写成文字，带 [由 X 转写，非当前模型直接感知] 标注。
几处刻意的设计：
- 逐模态判定，不一刀切。很多视觉模型能看图但听不到音频，全部降级会
白白把可直视的图变成二手描述
- 混合场景下转写文字作为 text 块并入 native，两部分同时到达模型
- 配置指向未声明能力的源时拒绝并继续找——照用只会重演静默剥离
- 未配 fallback_provider 但某源声明了 vision 时自动扫出来用；静默失败
比多找一个能用的源更糟
- 空回复算失败。上游剥掉媒体后模型往往回「我没看到图片」或空串，两种
都说明回退链也没真看到
- 多媒体块按模态合包为一次请求（见下）
## 3. 批量合包（生产实测驱动的返工）
首版逐块调用，生产 see_video 6 帧实测：4 帧里 3 帧超时，整轮 363 秒。
改为按模态合包一次请求后同一用例 131 秒、6/6 成功。
顺带把 modalFallbackTimeout 从 90s 提到 180s：生产经网关转
claude-opus-5 看一张 400x400 图要 ~81s，90s 贴着上限。
多张时 detail 默认 low 控体积，单张用 high 看细节；插件显式给了
detail 则尊重它。
## 4. see_video 帧数语义
fps=1/N 是频率（每 N 秒一帧）不是数量。20s 视频实测：
frames=4 → 5 帧、frames=10 → 2 帧、frames=1 → 20 帧，要得越多拿得越少；
长视频下 frames=4 会产出 时长/4 帧，靠 i>=9 的 break 兜着才没炸上下文，
而那个 break 用的是 ReadDir 索引，跳过条目后与实际帧数错位。
改为 ffprobe 取时长 → fps=N/时长 + -frames:v N 硬封顶。
0.4s/3s/20s/120s × frames=1/2/4/7/10 全部精确。
极短视频的坑：fps=1 在 0.4s 素材上产出 0 帧（不足一秒抽不出），所以
时长探测失败时不能退化成 fps=1，改为不传 -vf 只靠 -frames:v。
## 验证
- modalfallback_test.go 14 例：直视透传 / 回退转写 / 无源如实报告 /
未实现接口按不支持 / 混合模态拆分 / 空回复算失败 / 块数上限 /
多图合一次调用 / detail 策略 / 拒绝未声明能力的源 / 未配置时自动扫源
- go test ./... 全绿，go vet 无警告
- 生产盲测（答案预先封存、生成时不读）：随机三色带 → 模型答
「紫、蓝、红」，与封存答案完全一致
- 负向验证：拿掉回退源后模型如实回答「没看到图片内容」并引用工具返回
的配置提示，且主动纠正了上一轮的答案
- 生产 see_video 6 帧：单次转写，模型正确描述测试图卡的计数器递增与
彩虹带滚动
|
2026-09-04 06:25:51 +08:00 |
|
|
|
8207ad3385
|
feat(multimodal): 内置多模态感知插件 + process.go 原生支持 tool message 多模态块
【新插件 internal/plugins/multimodal】
- see_picture(path): 读取本地图片/URL，base64 注入 image_url block，
模型在下一轮 LLM 请求的 tool message 里直接看到图（1024×1024 图约 8500 token）。
自动识别 MIME，限 3MB 防爆 context。
- see_video(path, frames): ffmpeg 提取关键帧，多帧作为 image_url block 注入。
默认 4 帧，最大 10 帧，每帧限 2MB。
- listen(path): 读取音频文件，转为 audio_url block 注入，支持 mp3/wav/ogg/m4a。
限 5MB。
【内核多模态 tool message 支持】
- agent/api 新增 ToolOutput 类型（为后续 handler 直接返回 blocks 预留）
- SDK 公共层新增 ContentBlock/ImageURL/AudioURL（OpenAI 多模态格式）
- IOManager 新增 SetToolBlocks/ConsumeToolBlocks（interface{} 避免循环依赖）
- PluginSDK.SetToolBlocks(blocks) 插件工具调用后注入 blocks
- ioAdapter 桥接 IOInjector.SetToolBlocks
- process.go 工具执行后消费 pending blocks → 追加到 tool message 的 Blocks 字段
→ MarshalJSON 输出 content 数组格式 → LLM 看到图/音频
【验证】
multimodal_see_picture 注入 1024×1024 PNG 后 llmsproxy 统计：
prompt_tokens=44407（含 ~8500 image token），模型正确描述了图片内容。
|
2026-08-27 08:39:21 +08:00 |
|
