ttstd-infinite-canvas

Files

Wyatt_K 04bbbf642e fix(cloud-agent): skill_search 两处实机缺陷——skillId 容错与 snippet 多字节越界

两个缺陷都是实机验证时撞出来的，不是理论风险。

1) 参数容错：Agent 首次调用时按 skill_read_file 的参数习惯顺手带上 skillId
   （{"keyword": "...", "skillId": "<已启用技能ID>"}），而参数解码走
   decodeCloudAgentJSONObject（DisallowUnknownFields），直接拒绝 → tool_failed。
   结果是工具在清单里可见、却一次都没调用成功。
   - args struct 增加 SkillID（json:"skillId,omitempty"），仅接收不生效——
     检索范围恒为本轮已启用技能；
   - 工具描述补「不要传 skillId——本工具搜索全部已启用技能」，从源头减少误传；
   - 回归测试走完整的工具分发路径（cloudAgentReadTool），真正穿透解码层，
     并断言该字段不会缩小检索范围。

2) snippet 越界 panic（更严重）：cloudAgentSkillSnippet 用 strings.Index 拿
   **字节偏移**，却拿它去切 **[]rune**。中文描述里关键词越靠后、字节偏移越远
   超 rune 数，start 没有夹紧到 len(runes)，触发
   panic: runtime error: slice bounds out of range [249:233]，
   **整个后端进程被打挂**（实测复现两次）。
   - 改为 rune 级子串查找（cloudAgentSkillRuneIndex），不再混用字节与 rune 下标；
   - start/end 双向夹紧，并补 start>end 兜底；
   - 回归测试用 276 rune、命中词字节偏移 483 的长中文描述，
     在修复前稳定 panic（[443:276]），修复后通过。

3) 工具描述补充检索引导（提示文本，非行为改动）：
   - skill_search：明写「当本轮启用了多个技能、而你不确定该读哪一个时，先用本工具检索」；
   - skill_read_file：补「若本轮启用了多个技能且不确定该读哪一个，先用 skill_search 检索再读」——
     放在这里是因为模型一定会用到 read_file，提示的可达性高于只写在 search 自己的描述里。

   实测：同一 8 技能满槽任务跑 3 次（原始描述 / 只改 search 描述 / 再改 read_file 描述），
   step-5 **三次都没自发调用** skill_search，skill_read_file 次数 15 / 8 / 9（噪声内）。
   即：**仅靠工具描述不足以驱动该模型自发检索**，需要系统提示层路由或遥测来验证采纳，
   本 PR 不声称改善了采纳率。

门禁：go build ✓  go vet ✓  go test 8/8 ✓

2026-09-22 03:35:24 +08:00