Replies: 1 comment
用户反馈(第 2 部分):Windows / PowerShell 兼容性 —— 附实测复现与完整时间线
1. 用户的时间线(原话转述)
这个判断在技术上是站得住的,下面是实测证据。 2. 【实测】Windows PowerShell 5.1 会让成片命令直接失败DSH 通过
也就是说:只要 PowerShell 7 没装、或 DSH 进程环境里找不到它,DSH 就静默退到 5.1。 我把 DSH 真实的 spawn 方式(含
更糟的是:5.1 的报错信息本身就是乱码DSH 给每条命令前置了 (真实内容是「所在位置 行:1 字符: 146」,GBK 字节被按 UTF-8 解码) 模型既看不懂错在哪,也不知道该把 顺带排除「因为 7 默认 UTF-8,所以升级才有效」这一解释不带前缀时,pwsh 7 和 5.1 都输出 GBK 字节,乱码程度完全一样:
所以升级 PowerShell 7 之所以治好了用户的问题,真正原因是语法兼容( 3. 【实测】DSH 静默回退,不告诉任何人在源码里核查过:
结果:用户和模型都不知道自己正跑在 5.1 上,直到命令成片失败。 这大概就是「连一个简单的 Windows 兼容问题都做不好」的根因——不是能力不足,而是没有把「降级」这件事说出来。 4. 【实测】0.1.7 → 0.2 之间,shell 路径逐字节相同为确认 0.2 是否引入回归,我 diff 了
工具描述中被删掉的一句(0.1.7 有、0.2 没有):
(同义提示在 0.2 的 结论:0.2 在 PowerShell 解析、退出码采集、标记渲染、错误配色上没有任何代码回归。 因此,如果用户在 0.2 上确实比 0.1.7 更容易踩到「命令出错」,最可能的变量不是 DSH 的 shell 代码,而是进程环境(
5. 用户的其他诉求(1)没有自动升级按钮。 仓库中未找到任何 (2)token 成本。 详见本 discussion 正文第 1 节:100 个会话累计上下文 28.3 亿 token,14 个会话超过 80M,单会话内单步成本增长 19.8×–48.2×,单次请求峰值 739,866 token。 (3)渲染质量。 用户认为同一模型下的输出不如另一个 harness(附件见正文第 3 节)。此条主观成分较大,留给维护者自行判断。 6. 用户原话
7. 可执行的改进建议(按优先级)
本节数据均由 Agent 在本机复现:shell 解析见 |
Uh oh!
There was an error while loading. Please reload this page.
0.2.0-rc.2 使用反馈:长会话上下文成本增长 20–48×、shell 错误信号噪音(附可复现数据与渲染基准文件)
环境:DSH
0.2.0-rc.2(npmlatest)· Windows · Web profile · 模型deepseek-flash(V4.1)· presetstandard· 权限danger-full-access感谢维护者。以下全部结论都附带本机实测数据与复现方法,附件的两个完整 HTML 文件也内嵌在文末,可以直接复制运行。
TL;DR
1. 长会话上下文成本(主要问题)
测量方法
逐 zstd 帧解压
~/.dsh/sessions/--E-agentcode--/*/session.v4.jsonl.zstd,提取每个assistant/message事件的data.usage,按inputTokens + cacheReadTokens + cacheWriteTokens计算该次请求的上下文长度。共 100 个会话文件。结果(按累计上下文排序,前 6)
d2c9ec23…01763e9d…b93c689d…a874f849…9589957d…418c0598…汇总
机制说明
每个 step 都会重发整个上下文(在
usage中体现为cacheReadTokens)。因此单会话累计 token ≈ Σ(上下文长度),随步数近似二次增长:会话跑到 300 步时,单步上下文成本已是开头的 20–48 倍。这不是 bug,但它是「越用越贵」感受的直接来源,且当前 UI 没有把这条曲线暴露出来。希望改进的方向(供参考,不代表必须)
compaction-*/spill-*策略能否更激进?工具结果(尤其是长 stdout、文件内容)累积速度很快。2. shell 工具的错误信号噪音
观测数据
一次普通会话(用户问「DSH 0.2 有什么新功能」)的工具调用统计:
pwsh44 /grep3 /write3 /web_fetch2 /skill1 /glob1 /read1 /job_kill1)exit 1web_fetch为真正的isError: true(域名被解析到非公网 IP)7 个非零退出的逐条归因——全部是 Agent 构造命令的问题,不是 DSH 的 shell 管道问题:
exit 1原因dsh --version,而dsh不在该 pwsh 进程的 PATH 上gh repo view --json homepage字段名不合法(应为homepageUrl)v0.2.0-rc.2,实际为dsh-v0.2.0-rc.2Get-Content指向不存在的路径npm view … 2>&1 | ConvertFrom-Json,npm 的 warning 混入 stdout 导致 JSON 解析失败git rev-listbad revisionlines[1]受控实验:DSH 的退出码是准确的
为排除「DSH 误报退出码」的可能,用父进程独立测量真实
pwsh退出码,与 DSH 上报值对照:pwsh退出码cmd /c "exit 3"[exit code: 1]✅Get-Content C:\nope.txt -ErrorAction SilentlyContinue[exit code: 1]✅Get-Content C:\nope.txt -ErrorAction SilentlyContinue; Write-Host afterWrite-Host hiGet-ChildItem C:\nope -ErrorAction SilentlyContinue[exit code: 1]✅结论:退出码采集准确,未发现 0.2 的回归。
同时核对了源码:
terminalFailed()(packages/client/ui-tool/src/client/tool/models/terminal-card-model.ts)与.errorSummary红色样式(ToolRow.module.css)在dsh-v0.1.7-rc.1中就已存在,并非 0.2 新增。因此「升级 0.2 后错误变多」更可能来自可见性/注意力,而非采样行为变化。真正值得改进的点
A; B; C链中只有 C 报错时,A、B 的有效输出已经进入模型上下文,但整张工具卡被染成错误色。分隔语句(Write-Host "===")放中间会让$?复位,放链尾就污染退出码——这是 PowerShell 语义,但 DSH 可以选择不成比例地放大它(例如仅在「链中无任何成功语句」或「退出码语义来自任务本身」时染红,其余降级为中性提示)。3. 同模型渲染基准(附件)
同一模型、同一类提示词「画一只骑自行车的鹈鹕」,分别在 DSH 与另一 harness 下产出(DSH 版经一次人工返工)。
DSH 0.2.0-rc.2 版
另一 harness 版
客观差异(仅陈述事实,不评价优劣):
@keyframes pedalNear/pedalFar,固定角度摆动solveIK()双骨骼反向运动学 +requestAnimationFrame,脚踝严格落在曲柄圆周完整文件(可直接下载运行):
4. 附件:两个版本的完整源码
DSH 0.2.0-rc.2 版 · 完整源码(24,429 字符)
另一 harness 版 · 完整源码(22,621 字符)
5. 补充说明
~/.dsh/sessions/<cwd-slug>/<session-id>/session.v4.jsonl.zstd,是多个 zstd 帧拼接而成,需逐帧解压后再按行解析 JSONL。All reactions