Agent mode with Ollama: tool calls never fire, model output degenerates into garbled/multilingual text — reproducible across models, prompt

快速结论：在 AnythingLLM 的 Agent 模式（@agent）下配合本地 Ollama 工具调用模型时，模型始终不发出 tool call，输出反而退化为乱码、多语言混杂或重复空转；优先排查 Ollama 实际加载的 context window 是否被设得过大，以及自定义 MCP 的工具列表是否被智能工具筛选过滤掉。

适用环境：AnythingLLM Desktop v1.16.1（Windows / Electron）；本地 Ollama（http://127.0.0.1:11434）；测试模型 qwen3.8:27b、qwen2.5:32b（Ollama 标注支持 tool calling，Q4_K_M 量化）；64 GB 系统内存，32 GB 显存；自定义本地 MCP server（13 个工具，已连接且 13/13 激活）；Agent 聊天模式。

最快修复方案：暂无确认的一步修复方案。Issue 中该问题最终仍未被解决，维护者关闭后用户要求重新打开。可优先尝试的两项已验证有效的缓解措施：一是把 AnythingLLM 中设置的 context window 调回与 Ollama 实际能力匹配的值（本例从 32768 调回 8192），可改善输出乱码的严重程度；二是关闭 Intelligent Tool Selection 以强制注入全部工具，可排除工具被 reranker 过滤的可能。但两者均无法让 tool call 正常触发。

注意事项：上述两项措施只是缩小变量、降低乱码程度，并未修复根因。Issue 中的控制测试表明：同样的模型、同样的 tool schema 直接发往 Ollama 的 /api/chat 接口时响应完全正常，因此问题被定位在 AnythingLLM Agent 模式自身的请求构造（prompt + tools payload）或响应处理上，而非模型能力或显存不足。维护者认为问题出在用户自定义 MCP，但该结论未被用户测试推翻或证实，尚未有定论。

问题场景

用户在 AnythingLLM Desktop v1.16.1 中创建了一个 workspace，挂载了自定义本地 MCP server（共 13 个工具，如 hardware、tags、generate、hmi、search_knowledge_base），LLM provider 设为本地 Ollama，模型选用 Ollama 标注支持工具调用的 qwen3.8:27b 和 qwen2.5:32b，并启用 Agent 聊天模式、用 @agent 前缀显式调用。发送类似 @agent Call the hardware tool using the config file <path> 的指令后，模型从不发出真正的 tool call，Agent UI 中也看不到工具调用步骤，输出反而出现多种退化形式。

报错原文

The agent model failed to respond: no user query found in messages

Bash({"command": "ls -la", ...})

naming or numbering惯例
FortiRecyclerView
weâ€™ll

"It sounds like your text has been partially corrupted or misunderstood. I will attempt to reorganize and clarify the details..."

原因分析

用户通过六轮隔离测试排除了模型本身、prompt 内容与长度、RAG 文档、context window 设置，以及 provider adapter（原生 Ollama 与指向 Ollama OpenAI 兼容端点的 Generic OpenAI）等变量。最关键的对照是：相同的请求 payload、相同的 tool schema 直接发往 Ollama 的 /api/chat 接口（完全绕过 AnythingLLM）时，返回结果干净且连贯。

因此可能原因是 AnythingLLM 在 Agent 模式且附带 tools 数组时，自身构造的请求序列化（prompt + tools payload）或响应解析环节出现异常，导致模型实际收到的内容被破坏——这一点也由模型自述“收到的文本似乎被损坏”间接印证。

同时有几个可独立排查的叠加因素：Ollama runner 实际加载的 context window 与 AnythingLLM 中设置不一致时可能耗尽窗口，引发乱码和循环；Intelligent Tool Selection 默认开启，会按 reranker 结果每轮过滤工具，工具数量多或命名/描述特殊时可能被过滤掉；部分 Ollama 量化版本（如 Qwen3 VL 8B 的 Q4）本身存在长期输出退化问题。此外，若 workspace 已处于原生 Agent 聊天模式，则无需再写 @agent 前缀。

环境排查

AnythingLLM 版本：确认是否为 Desktop v1.16.1（Electron / Windows）。
Ollama 运行时：确认本地服务地址与版本，且模型在 Ollama 侧被标注为支持 tool calling。
Ollama 实际加载的 context window：用 ollama ps 查看 runner 真实加载的 context window，与 AnythingLLM 中 workspace / 系统设置的值比对，避免二者不一致。
显存占用：结合模型量化大小（本例 qwen2.5:32b 约 28 GB）核对 32 GB 显存下的 KV cache 是否过紧。
MCP 工具状态：确认 Agent Skills 面板中工具连接数量（本例 13/13）与命名、描述是否正确。
Intelligent Tool Selection 开关状态，以及每轮注入工具数量上限。
聊天模式：确认输入框中是否显示 @ 符号，以判断当前是否已是原生 Agent 模式。

解决步骤

先做控制测试，缩小问题边界：把同样的 prompt 与 tool schema 直接发往 Ollama 的 /api/chat，绕过 AnythingLLM。若响应正常，说明问题在 AnythingLLM 侧而非模型。
可优先尝试：用 ollama ps 检查实际加载的 context window，把 AnythingLLM 中的设置调回与 Ollama 能力匹配的值（本例从 32768 调回 8192），然后重新测试。此步骤在 Issue 中已确认能改善乱码严重程度。
可优先尝试：关闭 Intelligent Tool Selection 以强制注入全部工具，或提高每轮注入的工具数量，排除工具被 reranker 过滤的可能。关闭后用户观察到模型仍不调用工具，但可确认工具确实被完整传入。
确认聊天模式：如果输入框中已显示 @ 符号，说明当前已是原生 Agent 模式，去掉 @agent 前缀再测一次（Issue 中测试结果为无差异）。
交叉验证 MCP 本身：按维护者建议，禁用自定义 MCP，改用官方 MCP（如 GitHub MCP），或关闭 MCP 后启用一个默认工具（如 web-scraping）请求抓取网页，观察 tool call 是否能正常触发。
若以上均无效且确认已排查 context window 与工具过滤，建议抓取发往 Ollama 的实际网络请求（prompt + tools payload）作为证据，附到 Issue 中以便进一步定位请求序列化问题。

验证方法

在 Agent 模式下发送明确要求调用某个已注册工具的指令，观察两点：一是 Agent UI 中是否出现真实的工具调用步骤，二是模型输出是否连贯、不再出现多语言混杂、重复空转或 weâ€™ll 这类编码残留。同时用 ollama ps 核对 context window 已按预期加载。需要注意的是，即使输出乱码减轻，只要 tool call 仍未触发，就说明问题没有真正解决，应继续按步骤排查或补充网络请求证据。