1. qwen3.5 27B 跑 swe-agent 输出中断先别急着怀疑 Dockerqwen3.5 27B 在 swe-agent 里跑到 assistant 轮次只要一出现json包裹的指令块output 就自动中断——这个现象我见过太多次它大概率不是 Docker 环境的问题也不是单纯没强制加 run bash造成的。真正的原因通常藏在三层协议对齐里swe-agent 的 action parser 期望什么格式、qwen3.5 27B 实际吐出了什么格式、以及中间那层 OpenAI-compatible 服务有没有把 stop 序列和 tool_calls 处理干净。swe-agent 的工作方式是每一轮把模型输出解析成 thought 和 action再把 action 交给环境执行。解析这一步由parse_function.type决定常见取值有function_calling、thought_action、json、single_bash_code_block、all_bash_code_blocks。如果你用的是默认的function_calling而本地 qwen3.5 27B 只是把 JSON 当普通文本写在message.content里、没有返回结构化的tool_callsparser 就会判定没有合法 action触发格式错误、重试甚至直接中断。你看到的json ... 恰好踩中三个雷用的是三单引号而不是三反引号、语言标记是 json 不是 bash、内容是被围栏包住的 Markdown 而非纯 JSON 对象。这篇就按config.toml 与 settings.json 骨架 TaoToken 统一 Key/API 通道这条线给你一套可复制的配置和逐步验证动作帮你判断中断到底发生在模型侧、parser 侧还是执行侧。适合正在本地或内网跑 qwen3.5 27B、被 swe-agent 输出截断卡住的开发者。2. 用 TaoToken 统一 Key 与 API 通道先把变量收敛排查这类问题最怕变量太多模型服务一个地址、swe-agent 一个配置、Key 散落在各处一旦中断你根本分不清是哪一层断的。我的做法是先用 TaoToken 把模型调用收敛成一条统一的 OpenAI-compatible 通道这样 swe-agent 侧只需要认一个api_base和一个 Key后面所有排查都围绕这一条链路做。TaoToken 在这里扮演的是统一入口你可以在控制台生成一把 Key然后让 swe-agent 通过https://taotoken.net/api这个 OpenAI-compatible 端点去请求模型。这样做的好处是——当 output 中断时你可以先用同一把 Key、同一个端点单独发一次curl看原始响应里的finish_reason、content、tool_calls到底是什么从而把模型侧问题和swe-agent parser 问题彻底分开。具体动作分三步。第一步去控制台创建 API Key地址是https://taotoken.net/console生成后先复制保存。第二步如果你要验证模型本身能不能正常对话用模型对话页面直接测一轮地址https://taotoken.net/model-chat确认模型在无工具约束下输出是完整的、不会中途断。第三步把 Key 填进 swe-agent 的配置里让所有请求都走https://taotoken.net/api。这里有个关键点swe-agent 通过 LiteLLM 调用时模型名要带 provider 前缀比如openai/qwen3.5-27bapi_base指向 TaoToken 的 API 地址api_key填你刚生成的 Key。这样配置之后你后面看到的每一个报错都能对应到这条统一链路上而不是在多个本地端口之间来回猜。提示接入文档在https://taotoken.net/doc里面有 OpenAI-compatible 调用的完整参数说明配之前扫一眼能省不少试错。3. config.toml 与 settings.json 骨架直接复制改swe-agent 的配置分两块一块是 agent 行为模型、parser、prompt通常写在config.toml或通过命令行覆盖另一块是运行环境容器、实例、超时常在settings.json或对应的 yaml 里。下面给你一份最小可用骨架重点是先把 parser 从function_calling切到thought_action这是本地模型最稳的选择。先看config.toml骨架# config.toml —— swe-agent 本地 qwen3.5 27B 最小稳定配置 [agent] # 关键本地模型优先用 thought_action避免 function_calling 拿不到 tool_calls type default [agent.model] name openai/qwen3.5-27b api_base https://taotoken.net/api api_key sk-你的TaoToken密钥 per_instance_cost_limit 0 total_cost_limit 0 per_instance_call_limit 100 max_input_tokens 0 temperature 0.1 top_p 0.8 [agent.tools] # 从 function_calling 改成 thought_action parse_function.type thought_action [agent.tools.parse_function] # thought_action 会从最后一个三反引号代码块里抽取 action type thought_action再看settings.json骨架主要管执行环境和超时{ env: { deployment: { type: docker, container_timeout: 1800, pull_timeout: 300 } }, instance: { type: swe_bench, timeout: 900 }, agent: { max_requeries: 3, output_dir: ./trajectories } }如果你更想让模型自然输出 Markdown 代码块可以把 parser 换成single_bash_code_block对应改一行[agent.tools.parse_function] type single_bash_code_block但我不建议一上来就用all_bash_code_blocks因为它会把模型一轮里输出的多个 bash 块全部执行风险不可控。先用single_bash_code_block确认稳定后再考虑放宽。配套的 prompt 约束必须写死否则 qwen3.5 27B 很容易继续模仿历史里的json格式。在 system prompt 里加上你是 swe-agent 中的命令生成器。 每一轮必须只在最后输出一个可执行的 shell 命令。 禁止输出 JSON。 禁止使用三单引号作为代码块。 禁止使用 json。 禁止输出多个代码块。 禁止在 action 代码块后追加任何文字。 正确格式 Thought: 简短说明下一步要做什么。 Action: bash ls -la注意最后那个正确示例一定要放在 prompt 末尾模型对最近的示例模仿倾向最强。如果你历史轨迹里已经积累了大量 json 片段建议清空 ./trajectories 再跑否则模型会继续被污染。 ## 4. 验证请求链路从 curl 到 swe-agent 单实例 配置改完别急着跑全量先用最小动作验证链路。第一步直接用 curl 打 TaoToken 的 API确认模型在带工具定义时返回什么结构 bash curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -d { model: qwen3.5-27b, messages: [ {role: system, content: Only output one bash command in triple backticks.}, {role: user, content: List files in current directory.} ], temperature: 0.1, max_tokens: 512 }重点看返回里的四个字段choices[0].finish_reason、choices[0].message.content、choices[0].message.tool_calls、usage.completion_tokens。如果finish_reason是stop且completion_tokens很小、内容刚好停在代码块起始符附近那基本就是 stop 序列或模板问题如果content里是完整的json ... 而tool_calls是null那就印证了模型输出文本 JSON、parser 要结构化 tool call的错配。第二步用 Python 打印完整响应别只看控制台可见文本from openai import OpenAI import json client OpenAI( base_urlhttps://taotoken.net/api/v1, api_keysk-你的TaoToken密钥, ) resp client.chat.completions.create( modelqwen3.5-27b, messages[ {role: system, content: Only output one bash command in triple backticks.}, {role: user, content: List files.}, ], temperature0.1, max_tokens512, ) print(json.dumps(resp.model_dump(), ensure_asciiFalse, indent2))第三步跑 swe-agent 单实例只跑一个 case观察日志里parse_function的报错类型。如果日志出现FormatError、No tool call found、Invalid action invocation说明还是 parser 与输出格式不匹配如果日志出现bash syntax error说明 action 被抽出来了但内容不是合法 shell如果日志出现container exited、OOMKilled、permission denied那才轮到查 Docker。实测下来把 parser 切到thought_action并加上硬约束 prompt 后json中断基本就消失了。如果还在断继续往下看排查清单。5. 本篇常见错排查清单错误一json三单引号不被识别为 action block。thought_action parser 通常从最后一个三反引号代码块抽取 action三单引号很可能不被识别。解决prompt 里明确禁止三单引号或在网关层做字符串替换把bash转成bash。错误二语言标记是 json 不是 bash。如果你用single_bash_code_blockparser 只认 bash 代码块json会被忽略或解析失败。解决prompt 强制只输出bash并在网关层检测到json时直接抛格式错误让模型重试而不是把 JSON 当 shell 执行。错误三stop 序列里包含代码块分隔符。如果服务端配了stop [, ]模型一输出代码块开头就会停表现就是刚开始就断。解决检查推理服务的 stop 配置移除会撞代码块的分隔符如果用的是 thinking 模式还要注意 reasoning 内容里可能提前命中 stopword。错误四function_calling 拿不到结构化 tool_calls。默认 parser 是 function_calling但本地服务只返回文本 JSONtool_calls为 null。解决要么在服务层开启 tool-call parser如 vLLM 的--enable-auto-tool-choice --tool-call-parser hermes要么直接切到 thought_action。错误五thinking 内容与 action 内容混杂。qwen3.5 的 thinking 模式会先生成思考再生成工具调用如果服务层没正确分离reasoning_content和contentswe-agent 只读content就会看到空输出。解决关闭 thinkingenable_thinkingFalse或确保服务层正确返回 reasoning 与 tool_calls 字段。错误六Docker 背锅。Docker 只在 action 成功解析后才参与执行它不理解 JSON。判断方法很简单assistant 还没形成合法 action 就中断是 parser/stop/格式问题日志出现bash syntax error或command not found才是 action 内容或环境问题出现OOMKilled、container exited才查容器资源。排查顺序建议固定成先看parse_function.type→ 再看原始响应finish_reason和tool_calls→ 再查 stop 序列 → 最后才查 Docker。按这个顺序走基本不会绕远路。6. 长期跑编码 Agent把 Key 和通道固定下来如果你只是偶尔跑一个 case上面这套配置够用了。但如果你要长期用 qwen3.5 27B 跑 swe-agent 做批量编码任务建议把 Key 管理和通道固定成一套稳定方案避免每次排查都从零开始。TaoToken 的 Coding Plan 就是为这种长期编码/Agent 场景准备的地址https://taotoken.net/coding-plan适合需要持续调用、多实例并发的场景。配合前面那份config.toml骨架你只需要维护一把 Key 和一个api_base模型侧、parser 侧、执行侧的问题就能分层定位。接入相关的完整参数和示例看接入文档https://taotoken.net/docKey 的创建和管理在控制台https://taotoken.net/console如果你还想单独验证模型在无工具约束下的输出是否稳定用模型对话页面https://taotoken.net/model-chat快速测一轮。把这几步串起来json中断这类问题基本就能在一次排查里定位到根因而不是反复在 Docker 和 prompt 之间来回试。 qwen3.5 27B 跑 swe-agent 输出中断：config.toml 与 settings.json 骨架配 TaoToken 排查
1. qwen3.5 27B 跑 swe-agent 输出中断先别急着怀疑 Dockerqwen3.5 27B 在 swe-agent 里跑到 assistant 轮次只要一出现json包裹的指令块output 就自动中断——这个现象我见过太多次它大概率不是 Docker 环境的问题也不是单纯没强制加 run bash造成的。真正的原因通常藏在三层协议对齐里swe-agent 的 action parser 期望什么格式、qwen3.5 27B 实际吐出了什么格式、以及中间那层 OpenAI-compatible 服务有没有把 stop 序列和 tool_calls 处理干净。swe-agent 的工作方式是每一轮把模型输出解析成 thought 和 action再把 action 交给环境执行。解析这一步由parse_function.type决定常见取值有function_calling、thought_action、json、single_bash_code_block、all_bash_code_blocks。如果你用的是默认的function_calling而本地 qwen3.5 27B 只是把 JSON 当普通文本写在message.content里、没有返回结构化的tool_callsparser 就会判定没有合法 action触发格式错误、重试甚至直接中断。你看到的json ... 恰好踩中三个雷用的是三单引号而不是三反引号、语言标记是 json 不是 bash、内容是被围栏包住的 Markdown 而非纯 JSON 对象。这篇就按config.toml 与 settings.json 骨架 TaoToken 统一 Key/API 通道这条线给你一套可复制的配置和逐步验证动作帮你判断中断到底发生在模型侧、parser 侧还是执行侧。适合正在本地或内网跑 qwen3.5 27B、被 swe-agent 输出截断卡住的开发者。2. 用 TaoToken 统一 Key 与 API 通道先把变量收敛排查这类问题最怕变量太多模型服务一个地址、swe-agent 一个配置、Key 散落在各处一旦中断你根本分不清是哪一层断的。我的做法是先用 TaoToken 把模型调用收敛成一条统一的 OpenAI-compatible 通道这样 swe-agent 侧只需要认一个api_base和一个 Key后面所有排查都围绕这一条链路做。TaoToken 在这里扮演的是统一入口你可以在控制台生成一把 Key然后让 swe-agent 通过https://taotoken.net/api这个 OpenAI-compatible 端点去请求模型。这样做的好处是——当 output 中断时你可以先用同一把 Key、同一个端点单独发一次curl看原始响应里的finish_reason、content、tool_calls到底是什么从而把模型侧问题和swe-agent parser 问题彻底分开。具体动作分三步。第一步去控制台创建 API Key地址是https://taotoken.net/console生成后先复制保存。第二步如果你要验证模型本身能不能正常对话用模型对话页面直接测一轮地址https://taotoken.net/model-chat确认模型在无工具约束下输出是完整的、不会中途断。第三步把 Key 填进 swe-agent 的配置里让所有请求都走https://taotoken.net/api。这里有个关键点swe-agent 通过 LiteLLM 调用时模型名要带 provider 前缀比如openai/qwen3.5-27bapi_base指向 TaoToken 的 API 地址api_key填你刚生成的 Key。这样配置之后你后面看到的每一个报错都能对应到这条统一链路上而不是在多个本地端口之间来回猜。提示接入文档在https://taotoken.net/doc里面有 OpenAI-compatible 调用的完整参数说明配之前扫一眼能省不少试错。3. config.toml 与 settings.json 骨架直接复制改swe-agent 的配置分两块一块是 agent 行为模型、parser、prompt通常写在config.toml或通过命令行覆盖另一块是运行环境容器、实例、超时常在settings.json或对应的 yaml 里。下面给你一份最小可用骨架重点是先把 parser 从function_calling切到thought_action这是本地模型最稳的选择。先看config.toml骨架# config.toml —— swe-agent 本地 qwen3.5 27B 最小稳定配置 [agent] # 关键本地模型优先用 thought_action避免 function_calling 拿不到 tool_calls type default [agent.model] name openai/qwen3.5-27b api_base https://taotoken.net/api api_key sk-你的TaoToken密钥 per_instance_cost_limit 0 total_cost_limit 0 per_instance_call_limit 100 max_input_tokens 0 temperature 0.1 top_p 0.8 [agent.tools] # 从 function_calling 改成 thought_action parse_function.type thought_action [agent.tools.parse_function] # thought_action 会从最后一个三反引号代码块里抽取 action type thought_action再看settings.json骨架主要管执行环境和超时{ env: { deployment: { type: docker, container_timeout: 1800, pull_timeout: 300 } }, instance: { type: swe_bench, timeout: 900 }, agent: { max_requeries: 3, output_dir: ./trajectories } }如果你更想让模型自然输出 Markdown 代码块可以把 parser 换成single_bash_code_block对应改一行[agent.tools.parse_function] type single_bash_code_block但我不建议一上来就用all_bash_code_blocks因为它会把模型一轮里输出的多个 bash 块全部执行风险不可控。先用single_bash_code_block确认稳定后再考虑放宽。配套的 prompt 约束必须写死否则 qwen3.5 27B 很容易继续模仿历史里的json格式。在 system prompt 里加上你是 swe-agent 中的命令生成器。 每一轮必须只在最后输出一个可执行的 shell 命令。 禁止输出 JSON。 禁止使用三单引号作为代码块。 禁止使用 json。 禁止输出多个代码块。 禁止在 action 代码块后追加任何文字。 正确格式 Thought: 简短说明下一步要做什么。 Action: bash ls -la注意最后那个正确示例一定要放在 prompt 末尾模型对最近的示例模仿倾向最强。如果你历史轨迹里已经积累了大量 json 片段建议清空 ./trajectories 再跑否则模型会继续被污染。 ## 4. 验证请求链路从 curl 到 swe-agent 单实例 配置改完别急着跑全量先用最小动作验证链路。第一步直接用 curl 打 TaoToken 的 API确认模型在带工具定义时返回什么结构 bash curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -d { model: qwen3.5-27b, messages: [ {role: system, content: Only output one bash command in triple backticks.}, {role: user, content: List files in current directory.} ], temperature: 0.1, max_tokens: 512 }重点看返回里的四个字段choices[0].finish_reason、choices[0].message.content、choices[0].message.tool_calls、usage.completion_tokens。如果finish_reason是stop且completion_tokens很小、内容刚好停在代码块起始符附近那基本就是 stop 序列或模板问题如果content里是完整的json ... 而tool_calls是null那就印证了模型输出文本 JSON、parser 要结构化 tool call的错配。第二步用 Python 打印完整响应别只看控制台可见文本from openai import OpenAI import json client OpenAI( base_urlhttps://taotoken.net/api/v1, api_keysk-你的TaoToken密钥, ) resp client.chat.completions.create( modelqwen3.5-27b, messages[ {role: system, content: Only output one bash command in triple backticks.}, {role: user, content: List files.}, ], temperature0.1, max_tokens512, ) print(json.dumps(resp.model_dump(), ensure_asciiFalse, indent2))第三步跑 swe-agent 单实例只跑一个 case观察日志里parse_function的报错类型。如果日志出现FormatError、No tool call found、Invalid action invocation说明还是 parser 与输出格式不匹配如果日志出现bash syntax error说明 action 被抽出来了但内容不是合法 shell如果日志出现container exited、OOMKilled、permission denied那才轮到查 Docker。实测下来把 parser 切到thought_action并加上硬约束 prompt 后json中断基本就消失了。如果还在断继续往下看排查清单。5. 本篇常见错排查清单错误一json三单引号不被识别为 action block。thought_action parser 通常从最后一个三反引号代码块抽取 action三单引号很可能不被识别。解决prompt 里明确禁止三单引号或在网关层做字符串替换把bash转成bash。错误二语言标记是 json 不是 bash。如果你用single_bash_code_blockparser 只认 bash 代码块json会被忽略或解析失败。解决prompt 强制只输出bash并在网关层检测到json时直接抛格式错误让模型重试而不是把 JSON 当 shell 执行。错误三stop 序列里包含代码块分隔符。如果服务端配了stop [, ]模型一输出代码块开头就会停表现就是刚开始就断。解决检查推理服务的 stop 配置移除会撞代码块的分隔符如果用的是 thinking 模式还要注意 reasoning 内容里可能提前命中 stopword。错误四function_calling 拿不到结构化 tool_calls。默认 parser 是 function_calling但本地服务只返回文本 JSONtool_calls为 null。解决要么在服务层开启 tool-call parser如 vLLM 的--enable-auto-tool-choice --tool-call-parser hermes要么直接切到 thought_action。错误五thinking 内容与 action 内容混杂。qwen3.5 的 thinking 模式会先生成思考再生成工具调用如果服务层没正确分离reasoning_content和contentswe-agent 只读content就会看到空输出。解决关闭 thinkingenable_thinkingFalse或确保服务层正确返回 reasoning 与 tool_calls 字段。错误六Docker 背锅。Docker 只在 action 成功解析后才参与执行它不理解 JSON。判断方法很简单assistant 还没形成合法 action 就中断是 parser/stop/格式问题日志出现bash syntax error或command not found才是 action 内容或环境问题出现OOMKilled、container exited才查容器资源。排查顺序建议固定成先看parse_function.type→ 再看原始响应finish_reason和tool_calls→ 再查 stop 序列 → 最后才查 Docker。按这个顺序走基本不会绕远路。6. 长期跑编码 Agent把 Key 和通道固定下来如果你只是偶尔跑一个 case上面这套配置够用了。但如果你要长期用 qwen3.5 27B 跑 swe-agent 做批量编码任务建议把 Key 管理和通道固定成一套稳定方案避免每次排查都从零开始。TaoToken 的 Coding Plan 就是为这种长期编码/Agent 场景准备的地址https://taotoken.net/coding-plan适合需要持续调用、多实例并发的场景。配合前面那份config.toml骨架你只需要维护一把 Key 和一个api_base模型侧、parser 侧、执行侧的问题就能分层定位。接入相关的完整参数和示例看接入文档https://taotoken.net/docKey 的创建和管理在控制台https://taotoken.net/console如果你还想单独验证模型在无工具约束下的输出是否稳定用模型对话页面https://taotoken.net/model-chat快速测一轮。把这几步串起来json中断这类问题基本就能在一次排查里定位到根因而不是反复在 Docker 和 prompt 之间来回试。