Strix 使用本地模型时工具调用被输出为纯文本导致扫描停滞怎么排查？

Strix 使用本地模型时工具调用被输出为纯文本导致扫描停滞怎么排查？

【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix

用 Strix 跑本地模型（Ollama、LM Studio、vLLM 或 llama.cpp 自建的推理服务）时，如果扫描中途卡住、代理反复请求模型却始终没有实际进展，最可能的原因不是模型能力不够，而是推理服务器把工具调用当成普通助手文本吐了出来。本文针对这个症状给出判定依据和分服务器的修复步骤，最终目标是让端点返回结构化的tool_calls，而不是把调用泄露成纯文本。

前提是你已经按本地模型方式配置好 Strix。以 Ollama 为例，配置长这样（LM Studio、vLLM 等 OpenAI 兼容端点则把LLM_API_BASE换成对应端口）：

# Ollama export STRIX_LLM="ollama/qwen3-vl" export LLM_API_BASE="http://localhost:11434" # LM Studio / OpenAI 兼容端点 export STRIX_LLM="openai/local-model" export LLM_API_BASE="http://localhost:1234/v1" # 按实际端口调整

先确认是不是"工具调用变成了纯文本"

Strix 完全由工具驱动：每个有效的轮次都必须是一次原生函数/工具调用。如果推理服务器把工具调用作为纯文本、而不是结构化的tool_calls字段返回，Strix 就看不到任何可执行的调用，代理不会真正推进——它会重新提示模型补一个工具调用，直到重试耗尽后就放弃。文档明确指出，这类问题几乎都是推理服务器的配置问题，不是模型问题，也不是 Strix 的问题。

判断方法是看模型输出的内容。出现下面这种"把调用当文字打印出来"的形态，就说明命中了这个问题：

tool_call{"name": "exec_command", "arguments": {"cmd": "nmap ..."}} exec_command(cmd="nmap ...", timeout=180) {"action": "exec_command", "params": {"cmd": "nmap ..."}}

（上面是 docs/llm-providers/local.mdx 里给出的症状示例。）正确配置的端点要么返回结构化调用、要么直接拒绝请求——绝不会把调用泄露为文本。

按推理服务器修复：让工具 token 被解析成结构化 tool_calls

修复点在推理服务器一侧：它必须被配置成把模型的 tool token 解析成结构化tool_calls。按你实际跑的服务器选对应分支。

llama.cpp（llama-server）

• 用--jinja启动，并提供与模型匹配的 tool-use 聊天模板（--chat-template/--chat-template-file）。较新的构建默认启用--jinja——如果你的没有，先升级。
• 对思考模型，对齐或关闭推理（--reasoning-format、-rea off），以免破坏工具调用解析。
• 较低的温度（如--temp 0.2）能提高工具调用的可靠性。

Ollama

• 使用较新版本的 Ollama，以及模板接了工具的模型。现代 Ollama 会在模板不支持工具时直接拒绝工具（tools param requires --jinja flag）。
• 对推理模型（如 qwen3），关闭模型的thinking模式——thinking 开着时，工具调用经常被推进文本content里，而不是结构化的tool_calls字段。在 Ollama 侧关闭：用非思考的模型变体，或在模型参数 /Modelfile里写think: false。
• 把num_ctx提到至少 16k–32k。Strix 会发送较大的系统提示加很多工具 schema；在 Ollama 默认的小上下文下，工具定义会被截断出提示，模型随后停止输出有效调用。短测试提示可能看着没问题、真实扫描却会失败，所以要显式设置，而不是靠一次快速检查去推断。

vLLM

• 用--enable-auto-tool-choice启动，配一个匹配的--tool-call-parser（hermes、qwen3_xml或llama3_json），推理模型再配一个匹配的--reasoning-parser。

三条通用建议：对开放权重模型，把采样温度降到大约 0.2–0.6（视模型家族而定），能明显减少格式错误的工具调用——在服务器端或模型参数里设置。

验证修复与模型能力限制

修完之后，核心判断点还是回到那一条：端点要么返回结构化调用、要么直接拒绝请求，绝不会把调用泄露成文本。短测试提示可能看起来正常、真实扫描却失败（原因就是上面的上下文截断），所以不要只用快速测试下结论，显式把num_ctx设到位再跑真实扫描。

最后要留意模型规模带来的硬限制：即使配置正确，小于约 30B 的小模型产生格式错误或文本形态工具调用的频率也远高于前沿模型，要获得可靠的代理行为应优先选能力足够的模型。本地模型里文档推荐 Qwen3 VL、DeepSeek V3.1、Devstral 2；对关键评估，文档更建议直接用 Claude 4.5 Sonnet 或 GPT-5 这类云模型——本地模型只应在隐私是绝对优先时才用。

【免费下载链接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.项目地址: https://gitcode.com/GitHub_Trending/strix/strix