[缺陷] Harness 存在缺陷极可能诱导 PTC 模式(Code Mode)下工具调用频繁失败

[lithium-chamber]

Harness 存在缺陷极可能诱导 PTC 模式(Code Mode)下工具调用频繁失败

环境信息

• 仓库 commit:47f943859bef60e4160492346772ded9b24f765a
• 运行时:Node v25.3.0(process.features.typescript === 'strip',即 stripTypeScriptTypes 可用)
• 复现采用路径: host 侧 stripTypeScriptTypes 包裹壳(packages/code-runtime/code-runtime-worker-thread/src/index.ts:84, 302-303)+ 真实 worker 源码(worker.ts/bootstrap.ts/protocol.ts/worker-json.ts/output-json.ts)

---

总览(TL;DR)

PTC 模式(即 apps/cli/config/agent-presets/code/preset.yml 对应的 Code Mode)下经常观察到几种工具调用报错：

第一类错误

在个人的使用过程中，此类错误的Payload大概都遵循类似的风格：

{
  "code": "*一行超级超级长的TypeScript代码",
  "description": "...blablabla..."
}

是模型写的TypeScript代码本身出现了问题，返回一行极为简短的报错:

• Error: code run failed (exception): Expected ',', got 'inf'
• Error: code run failed (exception): Expected ',', got ')'
• Error: code run failed (exception): Expected ',', got 'hash'

Result报错非常简短，此时模型只能猜哪里出错了。

第二类错误

• Error: code run failed (exception): TypeError: "Some string...".result is not a function

这种报错的Payload大致与第一类那种差不多，都是有一段很长的TS代码，然后出现了"一段String".result这样的片段，而.result这个方法不存在，报错。

第三类错误

模型会尝试调用不存在的工具。典型例子是PTC模式下询问用户问题的时候，模型理应使用TS脚本中的tools.ask_user_question方法，但是却直接尝试调用一个不存在的工具ask_user_question：

Payload:
{
questions:[{id: "proceed", header: "Start fixing now?", question: "How should we proceed with the fixes?", options: […], …}]
}
Result:
Error: unknown tool "ask_user_question": only `run_code` is callable directly — call `ask_user_question` from inside a `run_code` program instead

经逐段审计和重放，大致可以归因为：

1. 模型层:Expected ',', got 'inf' / Expected ',', got ')' 是模型生成的 TypeScript 本身有语法错误(在期望逗号的位置写了裸标识符——如 inf(应为 Infinity)、hash——或漏逗号、多右括号);"...".result is not a function 是模型对工具结果套用了 .result() 包装器习惯。由于执行管线中不存在任何字符串转义规则异常或重格式化，也即 code 字符串从模型输出到 worker 执行全程零变换(见 Issue 0)，所以可以确认为模型本身不适应PTC模式下这种用TS调用一切工具的形式——这点要麻烦DeepSeek团队加强一下模型对自家工具的适配后训练了。

   一点私心：我个人其实非常看好这种基于TS脚本执行一切工具的方式。在我看来，使用成熟的脚本语言可以同时做到保留Tool Calling灵活性、简化和统一工具开发流程以及降低Tool Calling异常捕获和错误信息生成与传递过程复杂度。然而，显然DeepSeek V4 Pro尚未完全熟悉这种“更加先进”的调用方式。还望DS团队继续努力，我很看好DSH！

2. Harness 的设计缺陷:语法错误和运行时错误的行列定位信息明明存在,却被丢弃或从不映射回模型源码,导致模型只能靠猜重写,一轮失败有可能被放大为多轮失败，特别是在TS脚本内容很复杂涉及到很多转义字符的时候。
3. 提示工程层(同样也是Harness默认模式的缺陷): run_code-only 规则只有一句话，而系统提示里存在多条与其矛盾的指令(plan-mode、skill 目录提醒、各工具 guidance 段等等)，这些多为基于常规tool calling方式的指令使得模型会在上下文已经被注入 run_code-only 规则的情况下依旧偏向于调用执行代码以外的工具，从而导致上面提到的模型调用不存在的工具的情况。

---

Observation：执行管线中 code 字符串全程零变换

通过AI Agent辅助，我们排除了"code字符串可能经过了提示词没有强调的转义/重格式化"的想法。

每一段都是 verbatim 传递。

段	源码位置	行为
DeepSeek SSE 工具参数流	packages/llm/llm-deepseek/src/translate.ts:152-170	逐 delta 纯字符串拼接(block.text += fragment),无任何处理
参数解析	JSON.parse(标准)	无 repair/unescape 逻辑(全仓库 grep 验证)
注册表物化	snapshotJsonValue(lossless JSON)	深拷贝,不改字符串内容
run_code 传输	packages/core/tools/src/code-mode.ts:611-622	program: args.code 原样交给 runtime
host 侧类型擦除	packages/code-runtime/code-runtime-worker-thread/src/index.ts:300-303	stripTypeScriptTypes(STRIP_WRAP.prefix + request.program + STRIP_WRAP.suffix),包裹壳仅用于解析后按前缀/后缀长度切回
worker 传输	workerData(结构化克隆)	无变换
执行	packages/code-runtime/code-runtime-worker-thread/src/bootstrap.ts:405-412	'use strict';\n${data.code} 直接进 AsyncFunction

因此后文所有报错均可归因于"模型写出的代码本身"+"Harness 如何报告这个错误",而不是任何中间层对字符串的改动。

---

Issue 1:Error: code run failed (exception): Expected ',', got 'inf' / Expected ',', got ')'

症状

模型执行 TS 脚本时收到:

Error: code run failed (exception): Expected ',', got 'inf'
Error: code run failed (exception): Expected ',', got ')'
Error: code run failed (exception): Expected ',', got 'hash'

等问题

基于当前管线的复现

按 index.ts:84, 302-303 的包裹方式复现:

import { stripTypeScriptTypes } from 'node:module'
const PREFIX = 'async function __dsh_program__() {\n'
const SUFFIX = '\n}'

// 案例 1
stripTypeScriptTypes(PREFIX + `const opts = { timeout: 5000 inf: 2 };\nconsole.log(opts)` + SUFFIX)
// → SyntaxError, .message = "Expected ',', got 'inf'"

// 案例 2
stripTypeScriptTypes(PREFIX + `const o = { a: 1 ) };\nconsole.log(o)` + SUFFIX)
// → SyntaxError, .message = "Expected ',', got ')'"

两个异常对象的完整属性:

.code    = "ERR_INVALID_TYPESCRIPT_SYNTAX"
.message = "Expected ',', got 'inf'"        ← harness 上报给模型的只有这一行
.stack   =
    :2
    async function __dsh_program__() {
    const opts = { timeout: 5000 inf: 2 };
                                 ^^^
    console.log(opts)

原因分析

1. 直接原因：模型生成的代码在期望逗号的位置写了裸标识符(如 inf——应为 Infinity;hash 等)，或漏了逗号、多了右括号。这是模型输出错误,不是 harness 改坏了字符串(见 Issue 0)。

2. 但是，Harness 存在放大此问题的设计缺陷：stripTypeScriptTypes(Node 内置,amaro/SWC 实现)抛出的 SyntaxError 的 .stack 属性里原本带有完整定位信息——行号(:2)、代码框、^^^ 光标、错误码 ERR_INVALID_TYPESCRIPT_SYNTAX——但 runtime 的 catch 分支只取了 .message:

   // packages/code-runtime/code-runtime-worker-thread/src/index.ts:300-309
   } catch (error: unknown) {
     return this.failureBeforeWorker({ kind: 'exception', message: messageOf(error) })
   }
   // messageOf() (同文件 :109-111) = error.message,只保留第一行

   于是模型只收到一句话 Expected ',', got 'inf',没有行号、没有代码框、没有光标定位。程序越长,模型越无法定位自己哪里写错了,只能尝试整段重写再撞一遍，这是 PTC 下"同类报错反复出现"的主要放大器。或者模型只会花更多精力在思考过程中检查TS代码中的问题，污染上下文，消耗更多token，这有可能使得PTC模式下的编程性能明显下降。

3. 附带事实:.stack 里的行号相对包裹后的源码(第 1 行是 async function __dsh_program__() {),修复时减去 1 行即模型源码行号;代码框里那行 wrapper 也应剔除。

源码位置

• 擦除调用与失败上报:packages/code-runtime/code-runtime-worker-thread/src/index.ts:300-309
• messageOf():packages/code-runtime/code-runtime-worker-thread/src/index.ts:109-111
• 包裹壳常量:packages/code-runtime/code-runtime-worker-thread/src/index.ts:84
• 最终模型可见文本格式:packages/core/tools/src/code-mode.ts:631-634(code run failed (${kind}): ${message})

---

Issue 2:Error: code run failed (exception): TypeError: "Some string...".result is not a function

症状

程序能跑起来,但运行时抛:

Error: code run failed (exception): TypeError: "Some string...".result is not a function
    at eval (eval at runWorkerMain (...bootstrap.ts:406:16), <anonymous>:5:12)
    at async runWorkerMain (...bootstrap.ts:412:19)

复现

worker 重放(host 回复一个字符串工具结果,程序对其调用 .result()):

程序: const res = await tools.read({ file_path: '/x' });\nreturn res.result();
worker 报错:
TypeError: res.result is not a function
    at eval (eval at runWorkerMain (.../bootstrap.ts:406:16), <anonymous>:5:12)
    at async runWorkerMain (.../bootstrap.ts:412:19)

我观察到的第二类错误中的 "Some string..." 只是"模型在代码里内联了字符串字面量"的变体，本质是同一类错误。

原因分析

1. 直接原因：模型把 .result() 之类的包装器 API 套在工具结果上。经过全仓库的文件的检索，提示文本、工具描述、SDK 说明中没有任何地方教 .result()(找到的唯一相近的是 workflow/ralph 输出 schema 里的 result 字段,见下)。

   我个人认为这疑似是 DeepSeek 模型训练带来的习惯(Python Future.result() 一类的 idiom)，这种习惯不知怎么地泄漏进了它写的 TS。

2. SDK 类型是准确的，但模型没有利用：tools:sdk 段(packages/core/tools/src/ts-types.ts:250-292)给每个工具声明了精确输出类型(例如 read 返回 { path; offset; lines: {...}[]; totalLines }，见官方快照 examples/acp-agent/tests/snapshots/code-mode-turn/system-prompt.expected.md:343-351),.result() 与任何声明都不符。但类型标注"advisory only"(擦除执行,无类型检查)，且 SDK 说明没有任何否定性表述：没有一句话说"结果是裸 JSON 值,不存在 .result()/.json() 之类的包装方法"。以目前的 DeepSeek 模型性能来看，Prompt中显然需要这种显式否定。
3. 疑似存在错误的模式强化：workflow 与 ralph 的输出 schema 恰好声明了 result: { type: 'json' } 字段(packages/workflow/tool-workflow/src/index.ts:257-271、packages/workflow/tool-ralph/src/index.ts:380-383)，SDK 里就长这样:workflow: {...; result: JsonValue}。这有可能让模型强化"工具结果都有 .result"的印象。
4. 个人认为存在的 Harness 缺陷:
   • 上报的堆栈(prepareException 取 error.stack ?? error.message,bootstrap.ts:216-229)里，真正有用的只有第一帧 eval ... <anonymous>:N:C,其余全是 harness 内部噪音帧(绝对路径指向 bootstrap.ts/worker.ts/module_job)，这有可能干扰模型。
   • AI Agent实测 <anonymous>:N 的 N = 模型源码行号 + 3,是恒定偏移：程序第 1/2/5 行抛错分别报 :4/:5/:8；多行类型注解不破坏行计数(擦除用等长空格保留换行)，列号保持。偏移来源 = 'use strict'; 指令 +1 行 + V8 对 AsyncFunction 构造器源码的 +2 偏移。Harness 从未做任何重映射，也没有把内部帧裁剪掉。
   • 与之矛盾的是设计文档的既有断言：.agents/notes/implemented/feature/2026-06-15-code-mode.md:75 声称 "position-preserving, so runtime error line numbers match the model's source"。我的AI Agent实测不符，也即上面提到的行号相差 +3偏移，且这段断言并未被任何测试覆盖(该文件相关测试只断言 /enum|strip/i,packages/code-runtime/code-runtime-worker-thread/tests/runtime.spec.ts:128-133;全仓库也仅有 src/index.ts 一处引用 stripTypeScriptTypes,设计文档声称的位置保持单测在当前测试套件中并不存在)。

源码位置

• 异常上报:packages/code-runtime/code-runtime-worker-thread/src/bootstrap.ts:216-229
• AsyncFunction 构造与 'use strict' 前缀:packages/code-runtime/code-runtime-worker-thread/src/bootstrap.ts:405-412
• SDK 使用说明(应补充否定性规则的文本):packages/core/tools/src/ts-types.ts:250-259
• workflow/ralph 输出 schema 中的 result 字段:packages/workflow/tool-workflow/src/index.ts:257-271、packages/workflow/tool-ralph/src/index.ts:380-383
• 与实测不符的文档断言:.agents/notes/implemented/feature/2026-06-15-code-mode.md:75

---

Issue 3:PTC 下模型直接调用 ask_user_question 等原生工具被拒

症状

模型想向用户提问时，不写 TS 程序、不通过 tools.ask_user_question(...)，而是直接发出原生工具调用，比如 ask_user_question，PTC模式下，Harness 拒绝并返回:

Error: unknown tool "ask_user_question": only `run_code` is callable directly — call `ask_user_question` from inside a `run_code` program instead

复现大致流程

PTC模式（code 模式）下:

1. wire 工具列表只有 run_code——wireSchemas() 把可见 schema 过滤为仅保留 RUN_CODE_NAME(packages/core/tools/src/index.ts:980-1001),因此发给 DeepSeek API 的 function 列表只有 run_code 一个。
2. 模型仍发出 ask_user_question 原生调用(即它凭空"脑补"了一个 wire 上不存在的工具名，这可以被认为是 DeepSeek 模型对原生工具调用的强先验)。
3. 执行边界拒绝:collapses() 判定"非嵌套调用 + code 模式 + 名字不是 run_code"即拒绝(packages/core/tools/src/index.ts:1324-1326),拒绝文本即上面的引导语(:1436-1443),渲染为 Error: <msg>(toolErrorResult,:1870-1878)。

这个拒绝本身是设计好的、错误文本也有指导性(值得保留)。 这个 Issue 想要说明的是可能诱导或者加强此错误的提示词工程问题。

系统提示词与 run_code-only 规则兼容性似乎并不好

a. plan-mode 段。计划模式段(packages/plan/plan-mode/src/index.ts:225-233,order 50)在 collapse 规则(order 99,packages/core/tools/src/index.ts:51, 58)之前渲染,且原文要求:

"When ready, call exit_plan_mode with the complete plan markdown ... Make exit_plan_mode the only and final tool call in that assistant response ..."

(PTC 预设挂载的配置原文:apps/cli/config/agent-presets/code/agent.cordis.yml:120-131。)

在 PTC 下这条指令无法被字面执行：唯一的 wire tool 是 run_code,exit_plan_mode 只能作为 run_code 程序内的子分发调用(tools.exit_plan_mode(...))。模型照字面执行 → 被拒 → 得到上面的报错。这有可能直接诱导"模型尝试直接调工具"。

我用DeepSeek Harness去分析这个问题时，它确实是这么觉着的。以下问题同样。

b. skill 目录提醒是模式无关的。<system-reminder> 用户消息(packages/skill/tool-skill/src/index.ts:264-268)原文:"call the skill tool with the exact skill name before taking task actions"。PTC 下同样只能 tools.skill(...) 进程序调用。

我个人认为，PTC 模式下用TS执行一切工具可以被看作是对一般的工具调用的一种包装，但DSH中“执行TS脚本”还是基于tool call的，这时候如果你反过来“不让模型用一般的tool call执行除了TS脚本执行以外的所有tool”，那么在模型并没有针对性后训练的情况下，这是不是应该被视为一种需要在提示词工程中着重强调的不兼容性呢？

c. 十余条工具 guidance 段全部以"直接调用"口吻写成，且全部排在 SDK 段(order 150,packages/core/tools/src/code-mode.ts:23)之前:tool:read(100) "Use the read tool — not shell commands like cat…"、tool:write(101)、tool:edit(102)、tool:glob(103)、tool:grep(104)、tool:bash(105)、tool:jobs(106)、tool:web_search(110)、tool:web_fetch(111)、tool:lsp(112)、tool:goal(114)、tool:workflow(115)、tool:ralph(116)、tool:subagent(116.5)。它们不提"必须通过 run_code 程序调用",持续强化"工具可以直接调用"的心理模型。

d. run_code-only 规则本身只有一句话(packages/core/tools/src/index.ts:58):"run_code is the only tool you can call directly — a tool call naming any other tool fails." 它确实排在最前面(官方快照 examples/acp-agent/tests/snapshots/code-mode-turn/system-prompt.expected.md:8)，但对一个预训练强烈偏向原生工具调用的模型,单句规则 + 后面十几段"Use the X tool…"的混合信号，可能不足以压过习惯，这与我观察到直调 ask_user_question 一致。

拜托DS团队要么调整下Harness的几种不同模式的提示词工程的兼容性，要么继续后训练增强DeepSeek模型呀！

源码位置

• wire 过滤:packages/core/tools/src/index.ts:980-1001
• 拒绝判定:packages/core/tools/src/index.ts:1324-1326;拒绝文本::1436-1443;错误渲染::1870-1878
• collapse 规则文本与顺序:packages/core/tools/src/index.ts:51, 58
• plan-mode 段:packages/plan/plan-mode/src/index.ts:225-233;PTC 预设文本:apps/cli/config/agent-presets/code/agent.cordis.yml:120-131
• skill 提醒:packages/skill/tool-skill/src/index.ts:264-268
• SDK 段顺序:packages/core/tools/src/code-mode.ts:23

---

附加发现

以下是我的DeepSeek Harness Agent在探索过程中发现的一些其他问题，在此一并上报。

1. invalid-output 不指明违规值。实测 return Infinity(或返回值含 undefined/BigInt/循环引用):

   Error: code run failed (invalid-output): program completion must be lossless JSON
   

   模型无法得知哪个值违规。相关:packages/code-runtime/code-runtime-worker-thread/src/bootstrap.ts:166-190(prepareCompletion)+ worker-json.ts:150-233(snapshotCodeJsonValue)。

2. "erasable syntax only" 是黑话，无清单、无一次性预警。SDK 说明只有 "no enum or namespaces"(ts-types.ts:252)。实测会在擦除阶段硬失败的构造(每轮只暴露一种,各耗一次往返):

   构造	报错(实测)	质量
   enum	TypeScript enum is not supported in strip-only mode	好
   构造器参数属性	TypeScript parameter property is not supported in strip-only mode	好
   <T>x 尖括号断言	The angle-bracket syntax for type assertions ... use the 'as' syntax	好(自带修法)
   import/export	'import', and 'export' cannot be used outside of module code	尚可
   JSX <div>hi</div>	Expression expected	误导(没说原因)
   遗留八进制 0644	Legacy octal literals are not available when targeting ECMAScript 5 and higher	好
   with	The 'with' statement is not supported...	好
   重复 let 声明	擦除不报，worker 内 V8 报 SyntaxError: Identifier 'x' has already been declared + 噪音堆栈	无位置

3. 程序体在 strict mode 下执行，这一点提示词从未声明(bootstrap.ts:410 的 'use strict';)。

4. console 是 5 方法 shim(log/info/warn/error/debug,bootstrap.ts:100-120),console.table/console.dir 会得到 TypeError: console.table is not a function 这类毫无指引的报错。

---

最后，感谢DS团队带来这么有趣的Harness，希望DS的模型和Harness都变得越来越好，辛苦了！

本人并非专业Harness工程师，以上分析大部分也是在AI Agent辅助下完成的。如果有任何错误的结论和矛盾的建议，还请不吝赐教。

[argszero]

逐条对着 master（47f943859b）核实 + 本地实测复现了两个偏移量——你的审计全部成立，补上实测数据和一个实现层面的精确性提醒。

实测确认

① strip 包裹失败：message 丢诊断确凿。 按 index.ts:84 的 STRIP_WRAP 复现：

CODE:    ERR_INVALID_TYPESCRIPT_SYNTAX
MESSAGE: Expected ',', got 'ident'        ← 模型只收到这一行
STACK:   :2
         async function __dsh_program__() {
         const opts = { timeout: 5000 inf: 2 };
                                      ^^^        ← 光标定位在这里
         console.log(opts)
         SyntaxError [...] at parseTypeScript (node:internal/...)

messageOf（index.ts:109-111）= error.message 只取第一行，catch（:300-309）直接丢 stack——完整诊断（行号 :2、代码框、^^^ 光标）全在 .stack 里，就是没被上报。确认无误。

② 运行时异常 +3 恒定偏移：实测复现。 模型第 3 行抛 throw new TypeError("boom")（第 2 行留空），new AsyncFunction('console', "'use strict';\n" + code)（bootstrap.ts:405-412）：

TypeError: boom
    at eval (eval at <anonymous> ([eval]:8:12), <anonymous>:6:7)   ← 模型第 3 行 → :6

6 = 3 + 3，恒定偏移确认：'use strict'; +1 行 + V8 AsyncFunction 构造器 +2。列号保持（err 构造位）。文档断言（.agents/notes/implemented/feature/2026-06-15-code-mode.md:75 "position-preserving, so runtime error line numbers match the model's source"）确实与实现不符，且 runtime.spec.ts:128-133 只断言 /enum|strip/i 与 message 包含——位置保持无测试覆盖，全仓库也仅 index.ts:302 一处 stripTypeScriptTypes。三条全中。

实现层面的精确性提醒：不要硬编码 +3

+3 里的 +2 是 V8 引擎对 AsyncFunction 构造器源码的偏移，不是 harness 可控的——硬编码 3 在 Node 版本升级后可能漂移（V8 内部表示变化）。更稳的两种做法：

1. 模块加载时自校准：构造一次已知 throw（如 throw new Error() 于首行），读回 <anonymous>:N，偏移 = N - 1，存常量——引擎怎么变都对；
2. 或者不重映射、改为对齐：把 'use strict'; 前缀换成 'use strict';\n\n\n 把程序首行推到固定位置，仍然脆弱（+2 不可控）。推荐 1。

修复设计（模型可见文本应长这样）

• strip 失败（index.ts catch 分支）：用 .stack 的诊断段（: 行号 + 代码框 + 光标）构造消息，行号 -1（STRIP_WRAP.prefix 占 1 行），丢弃尾部 SyntaxError [...] at parseTypeScript... 内部帧；
• 运行时异常（bootstrap.ts:216-229 prepareException）：过滤到首个 <anonymous>:N:C 帧，N - 偏移 重映射；后续 harness 内部噪声帧（绝对路径指向 bootstrap/worker/module_job）对模型是纯干扰，裁剪或折叠成一行；
• 回归测试：补一条"程序第 N 行抛错 → 模型可见错误含 remap 后的行号"测试（当前文档断言无测试，正是它漂移的原因）；
• 文档：:75 的断言按实现修正（或让实现对齐断言，推荐后者）。

修复点集中（index.ts messageOf / bootstrap.ts prepareException / 渲染在 core/tools/src/code-mode.ts:631-634），不需要动执行管线——这符合你"零变换"审计的结论：管线干净，只是错误报告层把定位信息扔了。

[wxletter]

现象

两个独立 session（同模型 GLM-5.2、同 preset PTC、0.1.0-rc.7），用户问"你知道你有哪些工具可用吗"，模型均回答"只有 run_code"，不知道还有 58 个可通过 tools.name(args) 调用的工具。

第一个 session：模型不知道处于 code-only 模式，不知道 SDK section 存在。用户追问"你 system prompt 读全了吗"，模型回答"无法逐字导出自己的完整 system prompt"，回避了问题。用户多次追问后，模型仍坚称 system prompt 中没有工具清单。最终通过解压 session 日志才证实 SDK section 一直存在。

第二个 session：AGENTS.md 中添加"code 模式下，所有的工具调用都必须通过 run_code，仔细通读全部 system prompt"。结果：模型在 reasoning 中引用了"仔细通读"指令，但仍然只列出 run_code，没有去读 SDK section。用户明确指出"system prompt 里有 SDK section，完整定义了你所有可用的工具"，模型没有去读自己的 system prompt，而是花 15 个 step 读 DSH 源码、检查 Object.keys(tools)，从源码和运行时探索中"发现"了 63 个工具方法。

"发现"后参数名仍然是错的：第二个 session 中，模型最终列出了完整工具清单并给出调用示例，但示例中的参数名与 SDK section 中的声明不一致：

模型写的	SDK section 中的实际声明
tools.read({ path: "/some/file" })	read: { file_path: string }
tools.skill({ skill: "brainstorming" })	skill: { name: string }
tools.subagent({ task: "..." })	subagent: { description: string, prompt: string }

这证明模型即使"发现"了工具，也没有读取 SDK section 中的 TypeScript 类型声明——工具名是从 Object.keys(tools) 得到的，参数名是自行拼凑的。

证据

通过解压 session 日志（session.jsonl.zstd，zstd 多帧 JSONL）并提取实际发送给模型的 system prompt，确认以下内容确实存在于 system prompt 中：

1. Code-only rule（tools:code-only section, order 99）："run_code is the only tool you can call directly — a tool call naming any other tool fails. Reach every tool the SDK declares below from inside the program."
2. SDK section（tools:sdk section, order 150）：完整的 declare const tools: { [K in ToolName]: (args: ToolArgsMap[K]) => Promise<ToolOutputMap[K]> } TypeScript 类型声明，包含全部 58 个工具的 ToolArgsMap 和 ToolOutputMap，约 64KB。
3. "Writing code for run_code" 段落：散文格式的使用说明，介绍 tools.name(args) 调用方式、ToolCallError、Promise.all 并发等。

三者都在 system message（system role）中。模型在两个独立 session 中均未处理 #1 和 #2。模型处理了同 message 中的散文段落（persona、tool guidance 段、run_code 编写说明），但跳过了 code-only rule（1 句话，夹在 persona 和 tool guidance 之间）和 SDK section（64KB TypeScript 代码块）。

AGENTS.md（user role，~14KB 散文）被处理了——模型遵循了其中的规则、引用了其中的内容。但 AGENTS.md 中的 DSH Tool Mapping 表对 code mode 是错误的（把工具描述为可直接调用）。结果：错误信息被处理了，正确信息未被处理。

失败链总结

以第二个 session 为例，完整的失败链：

1. AGENTS.md 指示"仔细通读全部 system prompt" → 模型在 reasoning 中引用了此指令 → 但没有执行
2. 用户问"你有哪些工具" → 模型只列出 run_code → 没有去读 SDK section
3. 用户指出"SDK section 就在 system prompt 里" → 模型不回去读 system prompt → 花几分钟读 DSH 源码和 Object.keys(tools)
4. 模型"发现"了 63 个工具 → 给出调用示例 → 参数名是错的（path 而非 file_path，skill 而非 name，task 而非 description/prompt）
5. 模型的"教训"是"下次收到 system prompt 时，必须逐段通读" → 但这个指令已经在 AGENTS.md 里了，而且没被遵守

这表明问题不在指令层面——无论怎么指示模型"读 system prompt"，模型都不 reliably 处理 64KB TypeScript 代码块。

分析

@lithium-chamber 在 Issue 3 中将问题归因为"run_code-only 规则只有一句话 + 后面十几段 'Use the X tool…' 的混合信号"。我的发现表明原因可能更深：

模型没有读到 code-only rule 和 SDK section，不是因为矛盾信号干扰，而是因为注意力没有处理这两段内容。 消除矛盾信号（删除 AGENTS.md 工具映射表）和添加显式读取指令（"仔细通读 system prompt"）均未能改变这一行为。两个独立 session 重复了同样的失败模式，表明这是系统性的，不是偶然。

code-only rule 是 1 句话，淹没在约 96KB 的 system message 中；SDK section 是约 64KB 的 TypeScript 代码块，占 system message 的 66%。模型处理了 system message 中的散文段落，但没有处理这 1 句话和这 64KB 代码块。

这意味着 @lithium-chamber 提出的修复方向——"调整提示词工程的兼容性"——可能不足以解决问题。矛盾指令确实是问题的一部分，但更根本的问题是：模型不 reliably 处理 system prompt 中的大段代码块，无论周围有多少指引。

验证方式

如有其他人想验证：

1. 找到 session 日志：~/.dsh/sessions/<project-dir>/session-<id>/session.jsonl.zstd
2. 用 Node.js zlib.zstdDecompressSync 逐帧解压（文件是多帧 zstd，单次解压只出第一帧；需要扫描所有 28 b5 2f fd magic 位置逐帧解压）
3. 搜索 is the only tool you can call directly（code-only rule）和 declare const tools（SDK section）——确认两者都在 system prompt 中
4. 在同模型的 session 中问"你有哪些工具"——如果回答只有 run_code，说明没读到
5. 追问后检查模型给出的工具参数名是否与 SDK section 中的 ToolArgsMap 声明一致——如果不一致，说明模型即使"发现"了工具也没有读 SDK section

补充：@argszero 回复中未覆盖的部分

@argszero 的回复逐条确认了 Issue 1（strip 错误信息丢失）和 Issue 2（行号偏移），但未回应 Issue 3（提示工程层的 run_code-only 规则兼容性问题）。本回复补充的是 Issue 3 的根因分析，而非 Issue 1/2。

---

吐槽

这个问题就像是，考试题不会做，题边上写着答案在某本书的第三页，不读；边上人提醒，不读；自己跑去图书馆翻了一圈，终于发现答案是在某本书的第三页，但仍然没有细看，题还是答错了。这种情况下，PTC（code mode）以及所有基于code-mode创建的自定义 preset，都是完全不可用的。不要把这个问题推给 GLM-5.2，这个模型在 Claude Code 中表现完美。AGENTS.MD 和用户级别的 prompt 都无法让它去通读 system prompt，这只能是 Harness 的问题。我从未见过任何一个哪怕很小的模型，在其他 Harness 环境下连读个 system prompt 都这么费劲。