Harness在代码编辑的各种转义方面需要做好工具的鲁棒性，特别在代码中嵌入代码的时候，特别容易出错，浪费大量token

[ipconfiger]

如下图，只是截取的一小部分。

实际的需求就是在html界面中嵌入OpenApi渲染显示的文档和示例程序

[weijiafu14]

这个痛点是真的（"代码里嵌代码"确实是最容易出错、也最烧 token 的场景）。但在提"工具要更鲁棒"之前，有一件事值得先知道，因为它决定了这个 bug 该报给哪一层——这个社区里已经有两个人独立查过同一件事，而且结论一致，而且和直觉相反。

两次独立排查都指向：write 工具本身是原样透传的

• #2373 的作者报了四项工具层缺陷，其中一项正是"write 工具写脚本时反斜杠 / 美元符被剥离"（D:\Espressif 变成 D:Espressif、$env:X 被吞）。他后来自己去查了源码并撤回了这一项：

  排查确认 content 参数在 JSON 边界原样透传（tool-fs/src/write.ts 无任何字符处理），根因是模型侧 JS 模板字符串转义

• #2414 报的一批 run_code 相关问题里，也有同源的现象。

也就是说：内容不是在写文件那一步被弄坏的，是在"模型构造那个字符串"的时候就已经坏了。

为什么这个区分很重要

因为它决定了"更鲁棒"该做在哪：

• 如果是工具在处理转义 → 那确实是工具的 bug，该修 write；
• 但如果工具原样透传、坏在模型侧的字符串字面量 → 那么把 write 改得再"鲁棒"也没用，因为它收到的就已经是坏的内容了。工具无法区分"用户真的想写一个反斜杠"和"这是模型漏转义的残骸"。

而你的场景（在 HTML 里嵌 OpenAPI 渲染的文档和示例程序）恰好是这个问题的极端形态——多层嵌套的引号和转义：HTML 里嵌 <script>，script 里是 JS 字符串，字符串里又是代码示例。每多一层，模型要正确维护的转义层级就多一层。

今天能减少这类损耗的几个做法

这些不是修复，是减少内容经过的字符串层数：

1. 别让文件内容经过 run_code 的字符串字面量。 用 write 直接写内容（那条路的 JSON 边界是原样透传的），而不是在 run_code 里拼一个 JS 模板字符串再写出去——后者多了一整层转义，正是上面两位踩的坑。
2. 分层写，别一次写完。 先写 HTML 骨架（不含内嵌代码），再用 edit 把代码块单独放进去。每次操作只跨一层引号。
3. 能外链就别内嵌。 你的场景里，把示例程序放进独立的 .js / .json 文件、HTML 里用 <script src> 引用，能一次性消掉最深的那层嵌套——顺带还让后续的修改不用再动 HTML。
4. 让模型少猜引号层级：在文件里用不冲突的引号（HTML 属性用双引号、JS 内用单引号、模板字符串留给真正需要插值的地方）。

建议怎么提这个帖子

你现在的正文是一张截图加一句"需要做好鲁棒性"。按上面的背景，我建议改成一个更能落地的形状：

贴出具体的一次失败——你发了什么指令、模型调了哪个工具、那次工具调用的 content 参数长什么样、以及文件里最后写成了什么。

关键是那个 content 参数：

• 如果 content 里已经是坏的 → 坏在模型侧，那么诉求应该是"预设/提示词层面要有防止多层转义的规则"，或者"提供一个不经过字符串字面量的写入路径"；
• 如果 content 是对的、文件里是坏的 → 那就是工具的 bug，而且是一个比 工具层进化建议：pwsh 多行命令 / 无参工具 / write 转义 / 中文 GBK 编码 4 项缺陷 #2373 更强的证据（因为那位查完撤回了）。

这一个参数就能把责任分清楚，而它现在只有你那边有。你原文说"浪费大量 token"——正是因为没分清这一层，模型在反复重试一个它无法从工具反馈里学到的错误。

（顺带说，这属于这个社区里一个很常见的形状：工具返回了一个模型无法据以纠正行为的反馈。#3568 里模型原样重发同一个坏参数 17 次、#3489 里模型对一个不会变的错误重新规划 61 次，都是同一回事。你这个"反复转义错、浪费大量 token"是它在编辑场景下的版本。）

边界与利益相关

我们不修 DSH 自家组件——write / edit / run_code 都在 DSH 里。上面第一节是转述另外两位的排查结论，我没有复现过你的场景，也没有读过 tool-fs 的源码；第三节那几条是通用的减少转义层数的做法，不是修复。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——这是 DSH 原生编辑工具与模型侧构造内容的问题，装什么插件都不改变转义层数。

[denial123789]

补一条基于当前 rc.2 源码可以直接落地的判断：write.ts 的 parseWriteArgs 原样返回 content，随后直接交给 ctx.fs.writeText；edit.ts 同样把 old_string/new_string 作为字面量交给 editText。因此最有价值的最小复现不是只保留最终损坏文件，而是同时保存 ①期望片段 ②结构化工具调用参数 ③工具返回的 after/diff ④立即窄范围回读 ⑤目标解析器错误。工具参数已经损坏就属于模型或前置字符串层；参数正确但 after 损坏才进入文件工具/provider 边界。

针对 HTML 内嵌 OpenAPI 和示例代码，稳妥路径是把 HTML、OpenAPI、JS、shell/Python 示例拆成独立源文件，各自用原生解析器验证，再通过确定性构建生成单文件产物；不要为了写文本额外经过 run_code 的 JS 字符串字面量。我们把证据链、目录结构、失败路由和边界字符验收清单整理成了英文指南：https://sandbaseai.github.io/deepseek-harness-handbook/embedded-code-escaping.html

Disclosure: I contribute to this independent community handbook.