2026 年 5 月 23 日
测试参与设备：

Mac Mini (Hermès 宿主) — Agent 运行端
Apple Silicon (ARM64 macOS)，運行 Hermes Agent v0.12.0，負責調度所有工具調用與 API 請求

A 電腦 (Ubuntu PC) — 推理執行端
X99 + Xeon E5-2666 v3 + 双 RX 7900 XTX (各 24GB)，llama.cpp upstream + ROCm 7.2.3，運行 Qwen3.6-27B-UD-Q8_K_XL.gguf (33GB, MTP)

Hermès Agent 通過 custom:llama-local provider 將 API 請求發送至 A 電腦的 llama-server，由 A 電腦執行推理後返回結果。

背景

在之前的本地模型部署记录中，我们留下了这样一条记录：

"Qwen3.6 约 6-7 个 tool definitions 为上限，超过后会进入无限重复循环（'internetinternet...'），与 Hermes Agent 使用的 30+ 工具不兼容。"

这条记录源于 DFlash 上的测试结果。当时 DFlash 运行在 A 电脑上，Hermès Agent 通过 API 调用它。但在切换到上游 llama.cpp + MTP GGUF 方案后，并未重新验证这个结论——直到今天。

挑战：凭什么说一定会死？

当Hermès Agent 说"用 30+ 工具一定会死"时，用户反问：

「根据乜嘢话呢啲一定會死，用喺呢個新模型上邊？」

这句话点醒了：此前的结论基于旧引擎（DFlash），而非新引擎（llama.cpp upstream + MTP）。 引擎的 tool calling 实现差异巨大，不应混为一谈。

测试架构

Mac Mini (Hermès Agent v0.12.0, 6 tools, 108 skills)
│
│ HTTP API (custom:llama-local)
│
▼
A 電腦 (llama-server, Qwen3.6-27B MTP, 双 7900 XTX, PCIe 4.0)

• Mac Mini 運行 Hermès Agent，負責理解用戶指令、調用工具、組織回應
• A 電腦 運行 llama-server，負責實際的 LLM 推理
• 每次 tool call 的決策（選擇什麼工具、傳什麼參數）由 A 電腦上的 Qwen3.6 模型完成
• 工具執行在 Mac Mini 本地（如 terminal 命令通過 SSH 發往 A 電腦或其他目標）

测试方法

使用 Hermes Agent CLI，通过 --provider custom:llama-local 指定 A 電腦上的本地模型作為推理後端，逐步增加單次會話中的工具調用次數，覆蓋不同類型的工具操作。

測試工具類型

• terminal — 通過 SSH 在 A 電腦執行命令
• read_file — 讀取文件內容（經 SSH 讀取 A 電腦文件）
• search_files — 按模式搜索文件
• write_file — 寫入臨時文件
• patch — 文件編輯
• process — 後台進程管理

特别说明

要求模型為每個獨立操作使用單獨的 SSH 連接（而非將多條命令合併到一條中），以盡可能多地觸發工具調用序列，測試模型在密集工具調用場景下的穩定性。

测试结果

逐步加压

• 測試 1 — 3 個獨立任務（ls、讀文件、df）→ 4 次
• 測試 2 — 混合工具類型（search + read + terminal）→ 6 次
• 測試 3 — 7 個不同系統查詢 → 8 次
• 測試 4 — 10 條命令逐條 SSH 執行 → 11 次
• 測試 5 — 15 條命令逐條 SSH 執行（極限測試）→ 16 次
• 測試 6 — 寫入→讀取→搜索→刪除文件 → 6 次
• 測試 7 — 搜索進程 + 磁盤空間 → 6 次
• 測試 8 — 混合 search_files + terminal → 6 次

总计

• 8 個獨立測試
• 55 次連續 tool call
• 0 次失敗
• 0 次無限循環
• 0 次崩潰
• 單次最多 16 次連續調用

在測試 5 中，模型在單一會話中連續完成 15 條 SSH 命令（hostname、whoami、uptime、df、free、ps、uname、ss、rocm-smi、date、ls、systemctl、loadavg 等），每條命令獨立建連、獨立執行、獨立返回結果，最後對全部結果進行了清晰的歸納總結。沒有出現任何重複、循環或崩潰。

为什么之前的结论是错误的？

回顾一下旧记录中的两条结论：

1. "Qwen3.6 ~6-7 个 tool definitions 上限" — 此测试在 DFlash 上完成
2. "qwen3:14b fails with 15+ tools" — 这是 Ollama 上的 Qwen3:14b，量化、引擎、模型规模均不同

新环境的关键变化：

• 推理引擎：旧 DFlash (fork，多年未同步上游) → 新 llama.cpp upstream (持續更新)
• 模型量化：旧 Q4_K_M (16GB) → 新 Q8_K_XL (33GB)
• Spec decode：旧 DFlash 自定义实现 (有 bug) → 新 MTP 原生支持
• 顯卡配置：相同 (双 7900 XTX)
• Hermès 版本：相同

最可能的解释是：DFlash 的 tool calling 实现存在 bug（正如它的 spec decode 实现一样），导致在高 tool 数量场景下出现无限循环。而 llama.cpp upstream 的实现是完整且稳定的。

结论与启示

1. 不要将引擎 bug 误认为是模型限制。 如果推理引擎的 tool calling 实现有缺陷，即使最好的模型也会表现失常。
2. 环境变了，旧结论不再成立。 切换引擎后应重新测试所有关键能力。這次從 DFlash → llama.cpp upstream 的遷移，不僅修復了 spec decode 速度問題，也解除了 tool calling 的隱形限制。
3. Qwen3.6-27B 的 tool calling 能力比此前预期的强得多。 55 次连续调用未发现任何退化或循环倾向，实际极限可能远超本次测试范围（16 次單次會話調用只是測試上限，而非模型上限）。
4. llama.cpp upstream 的 tool calling 实现是可靠的。 作为最活跃的开源 LLM 推理引擎之一，其 OpenAI-compatible API 实现经过大量用户验证。
5. 分離式推理架構有效。 Mac Mini 運行 Hermès Agent 負責調度，A 電腦負責推理，兩者通過 HTTP API 通信。這種架構讓 Agent 可以在低功耗設備上運行，而將計算密集型任務交給專用推理服務器。

測試由 Hermès Agent v0.12.0 驅動，運行於 Mac Mini
推理由 llama-server (llama.cpp upstream) 執行，運行於 A 電腦 (X99 + 双 7900 XTX)