PTC 呈现下，工具描述中的字面量 {{...}} 被当作提示词变量，导致每轮请求组装失败

[Ghost-Silver]

Summary

在 PTC 呈现（run_code）下，只要任意一个可见工具的描述文本里含有字面量 {{name}} 形式的花括号序列，系统提示词组装就会在每一轮直接抛错，该 agent 完全无法发出请求。

报错：

unknown prompt variable "{{hexagon}}" in section "tools:sdk"; registered variables: provider, model, cwd

触发源可以是任意第三方 MCP server —— 例如 draw.io 官方 MCP（https://mcp.draw.io/mcp）的 create_diagram，其工具描述里包含 Mermaid 形状语法原文 `{{hexagon}}`。

结果是：内置 ptc preset（以及任何会切到 code 呈现的 preset）在连接了这类 MCP server 后完全不可用。

Reproduction

1. 连接一个工具描述中含字面量 {{...}} 的 MCP server。以 draw.io 官方 MCP 为例：

   dsh mcp add drawio --url https://mcp.draw.io/mcp
   

   其 create_diagram 描述中确实存在这样一行（原文照抄）：

   - Root shape: `((circle))`, `[rect]`, `(rounded)`, `))cloud((`, `)hexagon(`, `{{hexagon}}`.
   

2. 用 PTC 呈现启动一个 agent：内置 ptc preset（@deepseek-ai/dsh-agent-tool-presentation 配置 mode: ptc），或任意在提升后调用 ctx.tools.presentAs('code') 的 preset。

3. 发送任意一条消息。

Current behavior

每一轮都在 prompt 组装阶段失败，请求不会发出：

unknown prompt variable "{{hexagon}}" in section "tools:sdk"; registered variables: provider, model, cwd

观测到的现象：

• 该轮 turn/end 的 reason 为 {"kind":"error", ...}，与 turn/start 几乎同一时刻发生；
• 该轮没有 request/header 事件 —— 失败发生在请求构造之前，而不是模型侧返回错误；
• 在一次真实会话中，切换呈现方式前后紧邻的两轮形成对照：切到 PTC 之前的那一轮正常（完整目录、native 呈现），切到 PTC 之后立刻开始每轮报错。

补充说明其触发条件：该问题与具体是哪个 MCP server 无关，只取决于「PTC 呈现生效」+「存在含 {{...}} 的工具描述」两个条件的交集。同一个 MCP server 在 native 呈现下没有任何问题。

Expected behavior

第三方工具描述是任意文本，不应被当作提示词模板参与插值。tools:sdk 段应当原样呈现工具描述（或对其中的 {{ 做转义）；PTC 呈现不应因为某个 MCP 工具描述里出现 {{...}} 而整体不可用。

Environment

• @deepseek-ai/dsh 0.1.5-rc.1；@deepseek-ai/dsh-tools 0.1.5-rc.2
• macOS（darwin arm64），Node v24.20.0
• 触发源 MCP server：https://mcp.draw.io/mcp（工具 create_diagram）

定位线索（可选）

• packages/core/tools：sdkSection() 注册名为 tools:sdk 的段，在呈现模式不是 native 时，把每个可见工具的 name / description / parameters 原文交给 SDK renderer：

  return render(this.sdkSchemas(context.scope));

• packages/core/system-prompt：interpolate() 会扫描段文本中的所有 {{...}}，变量名未注册即抛错：

  throw new Error(`unknown prompt variable "{{${name}}}" in ${kind} "${input.name}"; ...`);

• 两者叠加，使「工具描述」事实上成为了提示词模板的一部分，而工具描述（尤其来自 MCP）是部署方无法控制的任意文本。

一个可能的修法：由工具 schema 生成的段（如 tools:sdk）不参与模板插值，或在生成 SDK 文本时转义 {{。

[PerryLink]

机制核实（master c291e79，2026-09-13）：属实。

1. PTC 下工具走系统提示 section 渲染：packages/core/tools/src/index.ts:825-829
   —— 非 native 模式注册 tools:ptc-only 与 tools:sdk 两个 section
   （:847-874，正文按调用 scope 的可见工具重生成）；每个工具还有各自的
   guidance section。这些 section 的文本最终进入 renderPrompt。
2. 渲染即严格插值：packages/core/agent-loop/src/agent.ts:359
   renderPrompt(assembly) → packages/core/system-prompt/src/index.ts:273-278
   对每个 section 做 interpolate；规则在 :327-356：{{name}} 必须是已注册
   变量，未注册直接 throw
   unknown prompt variable "{{name}}" in section ...。所以工具描述里任何
   成对的 {{...}} 字面量都会让本轮提示组装失败——与你观察的「每轮请求
   组装失败」一致。
3. 唯一例外（:329-337，system-prompt.spec.ts:625-632）：单个 {{ 且其后
   全文再无 }} 时按字面保留。

插件作者的规避：工具描述里避免成对 {{...}} —— 改用 ${name}、
{ {name} }（中间加空格）或 Unicode 花括号；若必须保留 {{，确保其后
不再出现 }}。

给维护者的建议：工具描述来自第三方插件，插值失败理应降级为字面文本（或
标注 section 来源），而不是让整轮组装失败——这是产品决策，需要官方拍板。
你的定位准确，可以直接附上这两处源码引用（tools/src/index.ts:825-829 与
system-prompt/src/index.ts:327-356）。