在一次语义Shell实验中，我尝试让本地模型把自然语言指令映射到具体工具，例如“copy report.pdf to backup” →
filesystem.copy。模型只需理解意图，不生成Shell命令。最初使用 Needle2，因其体积小、专注工具调用且支持本地运行，表现还算可用。但随着工具数量从5个扩展到50个，检索阶段出现两层决策：先筛选候选工具，再在其中选出最佳。若正确工具未进入候选集，后续就无从选择。为降低风险，我尝试将工具分组（每组5个）并并行评估，但不同组的置信分数是否可比仍不明确。
此外，工具描述的细节对小模型影响极大。仅用“Moves files from one place to another.”无法区分filesystem.copy、filesystem.navigate、filesystem.rename，需要在描述中明确说明源文件会被删除等细节。
在尝试 C++ 原生运行时遇到平台兼容问题（ARM NEON 代码在 Intel Mac 上无法直接编译），我转而使用 llama.cpp 并加载 Granite‑4‑350M。结果出乎意料：模型在常规指令上能准确选出工具，在模糊或无匹配的输入上则直接返回“未找到合适工具”，避免了错误调用。Shell 可据此提示用户重新表述或手动选择。
实验表明，模型本身的完美并非关键，关键在于系统如何处理不确定性：意图解析 → 参数校验 → 缺失参数提示 → 策略确认 → 执行。只要外层逻辑能容错，模型不必完美。
结论：
- Needle2 仍适用于特定平台（如 ARM 目标），但在工具规模扩大、跨平台集成时存在隐性成本。
- llama.cpp + Granite 在本地语义工具调用上更稳健，尤其在处理无匹配或模糊输入时表现更好。
- 关注模型的失败模式、可移植性和置信度校准，比单纯追求演示效果更重要。
#开发者 #工具 #Needle2 #llama_cpp #Granite4_350M @开发者工具库频道
@DevToolboxHub