[Bug] 长会话中工具调用标签畸形与写入静默失败：动作不执行且无错误提示

[flyboat403]

DSH 问题报告：工具调用标签畸形与静默失败

• 提交对象：DeepSeek Harness（DSH）
• 日期：2026-10-30
• 会话形态：单会话长任务（校园 MCP 服务改造），累计 100+ 轮工具调用
• 客户端：DSH Web GUI（http://127.0.0.1:3080）
• 运行环境：Windows；工作目录 E:\opencode\CampusAPI

---

0. 摘要

本次长会话中，工具调用出现两类故障。两类都会在无用户可见错误的情况下破坏动作，
表现为「助手说到一半停住」，用户必须手动输入「继续」才能推进：

类别	现象	后果	本会话频次
A. 标签畸形	助手输出的 invoke / parameter 闭合标签错位或多出	该调用不执行；回复就此结束	约 6~8 次
B. 静默不写入	write / edit 回 updated successfully，文件内容未变	静默错误状态，不回读就会上报假成功	约 5 次（跨 4 个文件）

核心诉求

1. A 类：解析失败时返回显式解析错误，而不是静默结束回合；
   建议解析后、执行前做标签配对校验，并把失败原文片段回显给助手。
2. B 类：写类工具返回前回读自校验，未生效则返回错误而非 success。
3. 可选：确认「一条消息多个工具调用」是否与 A 类相关（本会话中更易畸形）。

---

1. A 类复现样本（标签畸形）

A-1 消息开头出现孤立闭合标签

助手输出形态（原文，出现在回复最开头）：

</parameter>
</invoke>
</parameter>
</invoke>

• 预期：被拒绝，或视为空调用并提示格式错误。
• 实际：该回合无任何工具执行；用户看到的是「回复凭空结束」。
• 用户侧证据：用户在该轮直接复述了这串标签，并追问
  「你为啥老是输出这些内容，且会话也停下来」。

A-2 parameter / invoke 闭合错位（多一个 </parameter>）

助手输出形态：

<invoke name="pwsh">
<parameter name="command">cd E:\opencode\CampusAPI; git push origin main 2>&1 | Select-Object -Last 2</parameter></invoke></parameter>
</invoke>

• 预期：正常解析执行，或报语法错误。
• 实际：git push 未执行。随后 git rev-list --left-right --count origin/main...HEAD
  仍显示未推送，证明动作确实没发生（重发后才成功：47ced32..98ca983）。
• 影响：部署流程中断一轮，需人工补发。

A-3 invoke 名称被写成属性片段

助手输出形态：<name">…

• 实际返回：Error: unknown tool "name" string="true"
• 影响：返回一个与真实意图无关的错误名（name），定位帮助有限。
  期望错误应指出「工具调用结构不合法」，并回显片段。

A-4 git bundle create 因同类畸形未执行

• 助手输出形态同 A-2（多余闭合标签）。
• 实际：命令未执行；随后 Get-Item 得到
  找不到路径"C:\Users\fly04\AppData\Local\Temp\ynedut_docs2.bundle"。
• 影响：部署步骤整步作废（依赖该产物）。

A-5 观察到的规律（样本量小，非统计结论）

调用形态	观感成功率
单一、短、纯 ASCII 目的（如 git status）	基本都成功
单一、长（数十行 heredoc，含中文/引号/正则）	明显更易失败
一条消息内含多个工具调用	更易出现闭合错位

推测：畸形与输出长度、特殊字符密度、单回合多调用结构相关。
若可获取原始补全文本，建议核对长参数块之后是否出现标签闭合的重复或截断。

---

2. B 类复现样本（静默不写入）

这一类标签完全合法、工具返回成功，但文件未变。全部由写入后回读才发现。

#	目标文件	工具	返回	回读证据
B-1	server/src/campus_mcp/setup.py（/setup 页脚）	edit	updated successfully	grep '服务版本' 无输出 → 未写入
B-2	deploy/README.md	write	File created	随后 Test-Path 为 False
B-3	deploy/maintenance.sh	write	File created	SFTP put 报 No such file
B-4	docs/agent-接入指引.md（登录章节重排）	edit	updated successfully	findstr /C:"首选：门户三步" → 无输出（exit 1）
B-5	AGENTS.md（新增条目）	PowerShell 写文件	打印 done	回读发现内容未变
B-6	docs/dsh-问题报告-工具调用标签与静默失败.md（本报告首次尝试）	write	File created	dir docs\*.md 中不存在该文件
B-7	docs/dsh-bug-report.md（同样的内容、ASCII 文件名）	write	File created	成功（6850 字节）

B-6 / B-7 是一条重要线索：内容相同、仅文件名不同（中文 vs ASCII），
中文文件名那次未创建、ASCII 那次成功。因此建议排查文件路径/文件名中的
非 ASCII 字符是否触发了写入失败（或写入到了其他位置、编码转换失败却仍返回成功）。

• 影响：不做回读校验时，助手会据此向上报告「已完成」，而交付物缺失。
  这比「报错」更危险——用户无法察觉。
• 建议：写类工具在返回前做 stat + 关键内容比对；不一致时返回
  write_not_applied 之类的显式错误。

---

3. 另一类：命令永久阻塞导致回合终止

虽非标签问题，但同样表现为「回复中断」，一并报告。

• 形态：git commit（-m 未被干净消费时）依据系统级配置
  core.editor = notepad 启动记事本并等待输入。
• 实际：命令永不返回；约半分钟后回合被判定超时并转入后台，
  用户侧表现为「又一次停住」，且提交并未发生。
• 规避：改用 git -c core.editor=true commit -m "…" 后立即成功。
• 建议：命令转后台时，向助手明确回报「已转后台，仍在运行」，
  便于区分「还在跑」与「已结束但无输出」。

---

4. 逐条诉求（便于跟踪）

1. 解析校验：解析失败 → 返回显式错误（含失败原文片段），不静默结束回合。
2. 写操作自校验：write / edit 返回前回读比对，未生效则报错。
3. 后台化通知：命令转后台时给助手一条明确状态，而非「无输出」。
4. 单回合多调用：确认是否为已知脆弱点；若允许，建议在文档中提示风险。
5. 复现方法：样本 A-2、B-4、B-6 均具备可重复判定方式
   （动作后立即用只读命令验证状态）。

---

5. 附：该问题在本会话造成的实际损失

序号	事件	损失
1	git commit 被 notepad 阻塞，连续 3 次未产生提交	3 轮重试
2	git push 标签畸形未执行	1 轮
3	git bundle create 未执行 → 部署中断	1 轮
4	4 个文件的写入「报成功但未生效」	每处 ≥1 轮回读 + 1 轮重写
5	孤立 </parameter> 导致回合提前结束	用户侧 ≥5 次输入「继续」

合计约 15 轮以上往返成本，全部源于「失败不可见」，而非能力不足。

---

DSH 问题报告 · 追加样本（同会话后续观察）

本文件是 dsh-bug-report.md 的追加证据，提交时一并粘贴或接在正文末尾。

---

A-6 同一回合内连续 3 次标签畸形（git push / present）

形态：需连续执行 git push 与 present 的回合里，连续三次输出畸形：

1. </parameter></invoke> 多闭合；
2. </parameter></invoke></parameter></invoke> 重复整组；
3. 完全漏写外层 invoke 名 —— 只写了 <parameter name="command">，缺少 <invoke name="…">。

实际：三次均未执行；第四次按 <invoke name="…"> + 两个 </parameter> + </invoke> 书写才成功。

证据：成功那次输出 To ssh://...4b7a185..51ab938 main -> main；失败那几次毫无输出，
随后 git rev-list --left-right --count origin/main...HEAD 仍显示本地领先，证明未推送。

观察：畸形与「想在同一回合里连做两件事」高度相关，支持 A-5「单回合多调用更易畸形」。

---

B-8 edit 对同一处改动连续两次静默失败

目标：server/tests/test_login.py 中的一行断言。

1. 第一次 edit 返回 updated successfully，但 pytest 堆栈里仍是旧断言原文 —— 未生效；
2. 第二次 edit（更小 old_string）同样返回成功，pytest 仍失败于同一行 —— 仍未生效；
3. 改用 Python 按行删除（命令纯 ASCII）立即生效，257 passed。

影响：不做「跑测试 / 回读」校验就会连续两次误报「已修复」。

重要附加观察：未生效与内容是否含中文无稳定关联（同一行含中文与不含中文的替换都失败），
因此不要把 B 类归因于编码，应按「写入未落地」独立排查。

---

B-9 本报告自身的两次写入尝试（B-6/B-7 重复验证）

1. 文件名 docs/dsh-问题报告-工具调用标签与静默失败.md（中文）+ 完整内容 → 返回 File created；
   随后 dir docs\*.md 中不存在该文件。
2. 文件名 docs/dsh-bug-report.md（ASCII）+ 完全相同内容 → 成功（7335 字节）。

两次独立尝试中稳定复现，是全篇最可能直接指向根因的线索。

---

B-10 「新建文件」也会静默失败（本轮新增）

1. 用 edit 把新章节插入 dsh-bug-report.md（old_string 为纯 ASCII 锚点）→ 返回 updated successfully；
   随后 Select-String "^## " 列标题未出现新增章节 —— 未生效。
2. 用 write 新建本文件（ASCII 文件名、中文内容）→ 返回 File created；
   随后 Get-ChildItem docs\dsh* 只有 2 个文件，没有它 —— 未生效；重试一次仍失败。

说明：纯 ASCII 锚点与文件名同样失败，进一步排除「仅编码问题」的解释。

---

损失更新

本轮新增 A 类畸形 ≥5 次、B 类静默失败 ≥4 次；累计往返成本由约 15 轮升至约 20 轮以上。

代价特征：不是做不到，而是失败不可见 —— 助手以为完成了，用户也看不出没完成。

[argszero]

Thank you for the detail — the B-class table is the most useful part of this report, and it is reproducible without the session: the write tool answers from the value its filesystem backend returned, and nothing re-opens the file.

What I measured

I mounted the shipped tools (@deepseek-ai/dsh-tool-fs 0.2.1-rc.3: write, edit) on a real @deepseek-ai/dsh-tools registry and dispatched through the real tools/execute pipeline, over a filesystem that accepts the call and keeps nothing — which is what a refused ACL, a lost round-trip or a full disk looks like from the tool's side:

write(file_path=/w/note.md, content=hello)
  → isError: false
  → model sees: <path>/w/note.md</path><type>file</type><content>Created file</content>
  → files on disk: (none)

edit is the same shape: "The file … has been updated successfully." with the old text still in place.

Why the loop cannot catch it

write renders its confirmation from outcome.operation (packages/fs/tool-fs/src/write.ts), edit from its own success path (edit.ts) — neither re-opens the file. A failed write and a succeeded write therefore produce the same successful tool/result, and the failure is invisible to both the model and the user. That is exactly the cost you describe: not "it could not do it", but "it could not see that it did not".

It also explains why your encoding theory did not hold (B-10, and your own follow-up): the defect is not in the path, it is in the confirmation being written from an assumption instead of an observation. Whatever the cause of a given miss, the tool's answer is the same either way, and that is what makes it unfalsifiable at the call.

What exists now

@argszero/dsh-write-readback-guard 0.1.0 — https://github.com/argszero/dsh-write-readback-guard

dsh plugin --profile <name> add "github:argszero/dsh-write-readback-guard#v0.1.0"

It listens on tools/post-execute, the seam where a successful result is still a proposal. Both tools declare an output carrying path and after (the file's content following the mutation); the plugin resolves that path through the same ctx.fs the tool wrote through, reads it, and compares:

the disk	the result
holds what the tool claimed	passed through byte for byte, nothing added
holds different content	isError, with both lengths and the first differing character
holds no file at that path	isError: "No file exists at that path, so the write did not land"

Then, addressed to the model, because the model is the one that would otherwise report the work as done: Do not report this change as done. Write it again, then read the path before continuing.

Measured on the installed copy (installed through the tag with dsh plugin add, imported from the profile), four arms:

• control, plugin absent: the false success reaches the model, exactly as reported here;
• treatment: the same call becomes a failure, for both write and edit;
• fail-open: a binary/unreadable/oversized file, or a path the backend refuses, is passed through and counted — an unread witness is not evidence;
• must-not-fix: a genuine tool error is never touched, and a healthy write is byte-identical to the control's result.

The boundary

This catches one tool's own false report at that call; it is not a filesystem guarantee, and a second reader of the file can disagree with a disk that moved underneath it. It cannot see a write that lands and is later reverted, it does not detect a file changed by another process after the read-back, and it cannot help with B-5 (a PowerShell write that prints "done") because that never went through a tool whose result could be checked.

I am also not claiming your A-class (malformed invoke/parameter tags) or the core.editor=notepad block — those are parser and shell matters, upstream of anything a tool result can be corrected for.

Versions

Your sessions run 0.2.1-rc.2/rc.3; npm latest is now 0.2.1-rc.5. The seam is identical on both — tools/post-execute may replace the content of a successful result and may turn it into an error, while only replacing the value of a failed result is refused, and a successful-but-lying result is that permitted case. I verified dsh plugin add rc=0 and the composed row on both rc.3 and rc.5.

The durable fix belongs in the tools: they could re-read before answering. This project's issue and pull-request channels are closed, so I cannot offer that as a patch; the plugin is what a deployment can add today.

On your other report

The destructive-delete veto (#11534, a session and its plugins wiped out) is a different shape and I did not build it: a veto is a policy, and a policy that guesses what counts as catastrophic stops legitimate work. It has to be told what to refuse — machine roots, drive roots, a bare drive letter, a path that normalizes back to where it started, an empty target — and that list is the user's to name, not mine to assume. I will follow that thread separately.