目标模式，gptoss 20b 运行途中停止且不会恢复。

[oniisancr]

本轮运行失败The model produced output that does not match the expected peg-native format
PI_AI_ERROR

模型 gpt-oss-20b-MXFP4.gguf

[PerryLink]

这句话不是 DSH 生成的错误文案，是本地推理服务的错误被原样透传上来了。

peg-native 在仓库跟踪的文件里没有任何命中（我搜了 packages/，也搜了整句 does not match the expected）。它落到的是 packages/llm/llm-pi-ai/src/stream.ts:67：

  return 'PI_AI_ERROR'

那是 classifyPiAiError()（stream.ts:42-68）的兜底分支：只有当 pi-ai 传来的 errorMessage 匹配不上 401/403、额度、429、413/400、5xx、超时、流截断、传输类关键词时，才会落到这里。而 stream.ts:123-126 把这个 message 原样装进 failure：

    case 'error': {
      const text = message.errorMessage ?? 'pi-ai stream error'
      return { kind: 'error', failure: { message: text, code: classifyPiAiError(text) } }

所以你看到的那句是 pi-ai 的 errorMessage，不是 DSH 写的；pi-ai 又是从服务端错误体里取的（本 checkout 装的 pi-ai 0.85.1，node_modules/.pnpm/node_modules/@earendil-works/pi-ai/dist/api/openai-completions.js:518）。DSH 在这条链上只做分类，没有生成这句话。依赖声明见 packages/llm/llm-pi-ai/package.json:44（@earendil-works/pi-ai ^0.85.1）。

为什么不会恢复：PI_AI_ERROR 不在默认可重试码集合里。packages/llm/llm/src/retry-policy.ts:18-24 的 DEFAULT_RETRYABLE_CODES 只有 EMPTY_RESPONSE、RATE_LIMIT、SERVER、TIMEOUT、TRANSPORT。所以这一轮是终态失败 —— 这就是"运行途中停止且不会恢复"的直接原因，重试策略不会碰它。（顺带排除一个歧义：stream.ts:111-118 的 pending / deferred 也产出 PI_AI_ERROR，但那两条带的是各自的固定文案；你这条带 peg-native 文案，走的是 stream.ts:123-126 的 error 分支。）

peg-native 是 llama.cpp 的东西（这一段不是仓库可验证的，属外部信息）：gpt-oss-20b-MXFP4.gguf 通常跑在 llama.cpp 系的服务上，peg-native 是它的 PEG 工具调用解析器。llama.cpp PR #24329 标题就是 "chat: harden peg-native tool call parsing"，PR #25233 是在 peg-native 解析前做 UTF-8 清洗，而 issue #20260 的标题几乎就是你这个场景：peg-native 解析器在"思考模型先输出文本、再输出 <tool_call>"时失败。gpt-oss 是思考模型加工具调用，正好命中同一个失败面。所以修复点通常在服务侧的语法约束 / 工具调用模板 / 原生工具调用解析，而不是 DSH —— DSH 侧没有可调的解析行为，它只是把上游的失败如实报出来。

建议的下一步：先把 DSH 从等式里去掉。用 curl 直接打本地服务的 /v1/chat/completions，带同一组 tools、同一句中文指令，看服务自己是不是也报同一句话。

• 服务自己也报 → 问题确定在服务侧。具体开关名（--jinja、grammar 相关参数等）我没有在本仓库或一手文档里核实过，未验证，别照抄。
• 服务正常返回、只有经 DSH 才报 → 那才轮到查 DSH/pi-ai 这一侧，届时把两次的原始响应体贴出来对比。

我没能确认的：这句话究竟是 llama.cpp 服务端产生的，还是某个 pi-ai 版本自己产生的。本 checkout 里安装的 pi-ai 0.85.1 中我也没有搜到这句话，而 ^0.85.1 允许安装到更高的 0.85.x，我没有核实线上最新版是否包含它。要定死这一点，最省事的是抓服务端的原始 HTTP 响应体：body 里带这句话就是服务端的。另外，DSH 期望的工具调用形状见 stream.ts:174-207：pi-ai 必须先把参数解析成对象（event.toolCall.arguments），DSH 再 stringify 回字符串下发（stream.ts:202-204），所以解析这一步失败会落到你看到的那类错误 —— 这一句因果是我的推断，未验证。

如果 curl 直连的结果和经 DSH 的结果不一致，把两份原始响应体贴上来，就能直接定位到具体是哪一层改写了它。