我把DSH当工位用了64天

我把 DSH 当工位用了 64 天，然后回头翻了翻它的使用记录

1093 个会话、33.8 万次工具调用之后，一个重度用户的诚实复盘

两年多以前，大家还在比谁的提示词写得漂亮。现在真正拉开差距的，是你的 AI 工位是怎么搭的——它能不能读文件、能不能跑命令、能不能开十个分身同时干活、出错的时候你能不能看出错在哪。

这篇文章不谈愿景，只汇报一台真实机器上的使用数据：64 天、1093 个会话、117 681 个步骤、338 207 次工具调用、22.62B Token。把它当日志读完，DSH 这套东西好在哪、坑在哪，基本就清楚了。

01　一个偶然的念头

起因很土：某天我发现自己的 DSH 会话目录已经 1 GB 了。1 GB 的对话记录，这不太正常——正常聊天工具一年也存不到这么多。于是我干了一件当时觉得有点无聊、事后觉得非常值的事：把这一千多个会话的存档全部解开，逐条读里面的运行记录。

读完之后有两类发现。一类是意料之中的：工具确实被高频使用，长任务确实很长。另一类是意料之外的：比如三分之二的会话根本不是我发起的，是我派出去的代理；比如真正拖慢效率的东西几乎都和模型聪明不聪明无关，而是文件路径找不到、命令跑超时、要替换的文本已经过期。

这篇分享就是把这些发现摊开来讲。如果你正在评估要不要把 DSH 这类“可组装的 AI 工位”引进团队，或者已经用了一阵但总觉得自己只用了它三成能力，下面这些数字应该能帮你省不少试错时间。

先说清楚数据是怎么来的

DSH 把每个会话存成一个会话目录，里面是一个多帧追加的 zstd 文件：每写一次追加一个独立压缩帧。这一点很关键——直接用常规的流式解压器只能解出第一帧，你会以为文件坏了。正确姿势是按帧魔数切开、逐帧解压、再按行拼回去。

解开之后，每一行都是一条带类型的事件记录：步的开始、模型的输出、工具的调用与返回、作业的登记与结算、重试、轮次的结束。这套记录本身就是一份完整的运行台账，我后面所有数字都是从这里算出来的，不是猜的，也不是产品面板上的展示数字。

顺便说一个统计陷阱：磁盘上有 1099 个存档文件，但其中 6 个是同一会话的重复目录（最大一组一份 413 字节、一份 3.48 MB）。去重之后是 1093 个唯一会话。这篇文章所有口径都用 1093，凡是引用文件级总数的，我都会标明。

02　先看总账：这台机器到底有多“忙”

先给结论：这不是“偶尔问问 AI”的用法，而是把它当成了执行引擎。64 天里，它执行了 117 681 个步骤、调用了 338 207 次工具、登记了 39 955 个后台作业。

表 1　这台机器 64 天的运行总账

指标	本机实测
时间跨度	2026-09-07 → 2026-11-10（64 天，按月 128 / 592 / 379 个会话）
会话	1093 个唯一会话，其中主会话 347 个、子代理会话 746 个
执行量	117 681 步 / 3 005 轮 / 338 207 次工具调用 / 82 种不同工具
后台作业	39 955 个（bash 28 767 个、PowerShell 11 252 个），失败 1 286 个
Token	输入 432.7M + 输出 121.7M，含缓存读合计 22.62B
存档体积	1.07 GB（压缩态），中位单会话 0.72 MB、最大 21.9 MB

一张表看不出来的东西，用月曲线更直观。9 月是试水，128 个会话；10 月直接跳到 592 个；11 月前 10 天就 379 个。真正的变化发生在 10 月中旬以后：会话数量上去的同时，单个会话的长度也在变长。

图 1　按周统计的会话创建量（深色为主会话，浅色为子代理会话）

数据来源：本机会话存档逐文件解析，按会话 id 去重。

这张图里最值得看的是那条浅色带子——代理会话的增长速度快于主会话。11 月的增长主要不是我变勤快了，而是每个任务派出去的分身变多了。这件事我在第 03 节展开。

单会话的体量分布：短任务为主，长尾极长

中位会话只有 31 分钟、72 步；但 P90 是 209.6 步，P99 是 683.6 步，最长的一个会话跑了 2 147 步。这就是典型的右偏分布：大量任务十分钟内收工，少数任务能连着跑几十小时。

表 2　单会话执行步数分布（全部 1093 会话 vs 347 个主会话）

步数区间	全部会话	占比	主会话	占比
0 步	19	1.7%	18	5.2%
1–4 步	24	2.2%	22	6.3%
5–19 步	48	4.4%	14	4.0%
20–59 步	367	33.6%	41	11.8%
60–199 步	517	47.3%	161	46.4%
≥200 步	118	10.8%	91	26.2%

注：步数以 step/start 记录计数；主会话的规模分布明显右移。

注意主会话那一列：超过 200 步的主会话占 26.2%，是全部会话的两倍多。原因不复杂——主会话是“发起 + 收尾 + 整合”的那一层，它天然比任何一个执行分身长。

如果你只记一个数字：这台机器有 1% 的会话吃掉了 11.2% 的执行步数。优化长尾比优化平均值划算得多。

03　它其实不是一个聊天框，是一个可组装的运行时

用了两个月我才真正理解 DSH 的设计取向：它的能力边界不是由产品经理画的，而是由你的装配清单决定的。内核提供 agent 循环、工具执行、会话存档、权限沙箱；具体能力（开哪些工具、用哪个模型、要不要子代理、能不能控制桌面）全在 profile 的 bundle 列表和 patch 层里。

本机装了 22 个装配单元（11 个官方内置、11 个第三方），加上随包分发的 321 个内置能力包。这些包按领域分布得很有意思：客户端 UI 60 个、工具执行与沙箱 53 个、Agent 循环 45 个、运行时基础 41 个、实验特性 32 个……也就是说，它把“一个 AI 应用”拆成了三百多块可以单换的零件。

图 2　DSH 插件生态的四层结构：装配层 → 第三方插件 → 内置能力包 → 补丁层

数据来源：应用包元数据、profile 装配清单与运行时配置。

这个设计带来两个直接后果，一好一坏。

• 好处是故障被局部化。我这次就遇到一次：原生 Bash 执行器因为缓存损坏彻底不可用了（后文详述），但同一会话里 PowerShell 通道照常工作，任务没有中断。单体工具在这种情况下就是全站不可用。

• 坏处是默认值不等于最优值。22 个 bundle 默认全开，包括 8 个 experimental 系列。你只写代码的话，语音输入、个性化推荐、动作卡片这些就是纯负担：启动更慢、上下文更多、故障面更大。DSH 的默认配置是“全都给你”，不是“帮你选好”。

所以我对它的定位是：这不是一个开箱即用的产品，是一个需要你像维护 CI 流水线一样维护它的工位。愿不愿意付这份运维成本，基本决定了你会觉得它“效率神器”还是“复杂难用”。

04　最意外的发现：三分之二的会话不是我发起的

打开数据前我以为自己会看到 1093 个“我问它答”的会话。实际是：主会话 347 个，子代理会话 746 个，比例 2.15:1。也就是说，每发起一个主任务，平均会派生两个以上的分身。

表 3　主会话与子代理会话的对照

维度	主会话	子代理会话
数量	347	746
步骤中位	130	61.5
工具调用中位	—	约为主会话的一半
Token 中位	19.55M	6.26M
步数总量占比	51.4%	48.6%
Token 总量占比	63.0%	37.0%
归档率	95.1%（330/347）	0%（0/746）

这张表里有两件事值得单独说。

第一，子代理不是“免费的并行”。它们贡献了 48.6% 的步数和 37% 的 Token。很多人以为多开分身就是白捡的吞吐量，其实账单上写得清清楚楚：分身越多，总消耗越高。分身真正省的是主会话的上下文——读一个大仓库这种活，让分身干，主会话只收结论，上下文不会被撑爆。

第二，归档其实是“收尾动作”。330 个归档会话全部是主会话，子代理会话一个都没归档。我一开始以为归档是清理垃圾，看完数据才明白：归档是我在任务结束后主动做的收尾，而分身随着会话树一起沉下去，不会被逐个归档。所以“归档率 30.2%”这个数字，本质上是“主会话完成率 95.1%”的另一种写法。

分身的分布：少数任务铺开十几个代理

746 个子代理会话由 191 个父会话派生，平均扇出 3.9 个。更细地看：只派生 1 个的父会话 23 个、派生 2–4 个的 108 个、派生 5 个及以上的 60 个，最大扇出 21 个。

这个分布很符合真实工作：大部分任务其实一两个分身就够了（“去查一下这个接口怎么用”“把这段代码改对”），只有少数需要大范围铺开的活——比如“把这个目录下 30 个文件全部按新规范重构”——才会一次开十几个。扇出不是越大越好，它应该由任务的“可并行边界”决定，而不是由并发上限决定。

图 3　按工作区类别看会话数与 Token 的分布（匿名化分类）

注：工作区按目录名关键词 + 内容集中度人工校正为 7 类，属粗分类。

顺便暴露一个我自己的使用习惯问题：ptc 预设使用率 97.1%（1061/1093），模型高度集中在单一模型（81.2%）。这说明我基本接受了开箱配置，没有在预设层做细分调优。这既是“默认值足够好用”的证据，也是“我没把工具用透”的证据。

05　工具很多，但只用得动五把

338 207 次工具调用，覆盖 82 种工具。听起来很丰富，但排前五的工具吃掉了 78% 的调用量。

表 4　工具调用 Top 10（去重口径，合计 338 207 次）

#	工具	调用次数	占比	干什么用的
1	run_code	114 623	33.9%	在 TypeScript 沙箱里编排工具调用
2	read	54 364	16.1%	带行号的范围读取
3	edit	36 212	10.7%	字面量精确替换 + 版本守卫
4	ops_bash	30 893	9.1%	dsh-ops 提供的原生 Bash 通道
5	pwsh	27 857	8.2%	Windows PowerShell 7 通道
6	grep	19 476	5.8%	ripgrep 内容检索
7	write	16 779	5.0%	整文件写入
8	read_image	8 178	2.4%	直接读图（截图/图表/UI 验证）
9	job_output	5 156	1.5%	后台作业输出回收
10	glob	4 075	1.2%	路径模式发现

图 4　工具调用 Top 15：单一 PTC 入口 + 高频文件/命令工具的双层结构

数据来源：1093 个唯一会话的事件流，按会话 id 去重。

这张图有个非常明显的“双层结构”，值得解释一下。

PTC：为什么 82 种工具没把上下文撑爆

run_code 一个工具就占了 33.9%，原因在于 DSH 的 PTC（程序化工具调用）模式：模型不是一条一条地调工具，而是写一段 TypeScript 程序，程序内部再调用 read / edit / ops_bash / grep。日志里能直接看到这个比例：直接调用 115 694 条，其中 run_code 占 99.2%；程序内部分发 222 873 条，两者约 1:1.94。

这件事的价值不是“少调几次工具”，而是把最占上下文的两样东西移出了对话：工具的定义、工具的原始返回。82 种工具的调用记录堆到 33.8 万条，但模型的上下文里始终只有一份工具清单和每次程序执行的最终输出。执行结果先在程序里过滤、聚合，生成一小段摘要才回到对话。

如果没有 PTC，这套使用强度下上下文会被工具返回撑爆。这是我眼中 DSH 最被低估的设计。

双 Shell：一条挂了一条还能干活

排在第四第五的 ops_bash 与 pwsh 都是 3 万次上下，分别对应 dsh-ops 的执行器和 Windows 原生 PowerShell。这台机器上两类任务都有：Unix 风格的脚本处理、Windows 原生的系统操作。两条通道并存的直接好处，就是我第 03 节说的——其中一条挂了，另一条顶上。

主会话干活、分身读查

把工具按“族”归并，再拆开看主/子代理，会发现一个很清晰的分工：子代理的文件与检索类占 45.6%、主会话 36.8%；子代理的网络检索占 3.3%，是主会话（0.7%）的四倍多；反过来主会话把 21.1% 的调用给了命令执行，子代理只有 13.5%。

换成白话：分身负责看和查，主会话负责改和跑。这个分工不是我刻意设计的，是任务结构自然形成的——因为改代码、跑构建这类动作需要连续上下文，交给分身反而要来回传话。

06　Token 账单：缓存是生命线，长尾是成本黑洞

这是我最不想面对、但最需要分享的一节。64 天累计消耗 22.62B Token（输入 432.7M、输出 121.7M，其余都是缓存读取）。单会话中位 8.32M，P90 是 45.2M，极值 560.1M。

表 5　单会话 Token 分布

口径	Token 量	说明
全量会话中位	8.32M	一次“典型任务”的量级
P90	45.20M	每十个会话有一个接近 5000 万
P95	75.25M	长任务的常态
P99	214.97M	重负载会话
最大值	560.1M	单个会话吃掉全量约 2.5%
仅统计有消耗的 982 个会话	中位 10.06M	排掉空会话后的口径

比分布更刺激的是集中度：前 1% 的会话（11 个）占全部上下文重放量的 16.5%，前 5% 占 40.8%，前 10% 占 54.9%。换句话说，一成会话承担了一半以上的成本。

图 5　单会话 Token 分布与集中度曲线

注：分布明显右偏，平均值远高于中位数，说明少数长任务主导成本。

缓存：98.29% 命中率是怎么来的

如果把 22.62B 全部按未缓存输入算，这个用法在经济上根本不可能持续。实际情况是：未缓存输入 446.4M，缓存读是它的 57.5 倍，缓存命中率 98.29%。9 月 99.16%、10 月 97.87%、11 月 98.44%——非常稳定。

这件事给出两条实操结论，我自己都在用：

• 别动前缀。缓存命中依赖上下文前缀稳定。频繁改系统提示、在会话开头塞一整个大文件，都是在主动放弃缓存。

• 把“稳定规则”和“变化任务”分开。长期有效的规则放系统提示，一次性任务放对话。混在一起，每次都要重算。

时间账：模型推理占 65%

除了 Token，我还算了时间。50 天里 LLM 侧累计 572.3 小时、工具侧 304.4 小时，占比 65.3% 与 34.7%。折合每步平均 19.18 秒在等模型、10.2 秒在跑工具。

这个比例说明什么？说明瓶颈主要在等模型，而不是等命令执行。所以“把长命令改后台”能省的是那 34.7% 里的时间，真正要抠效率，得从“减少步数”入手——让每一步的信息量更大，而不是让每一步跑得更快。

07　稳定性：问题几乎都不在“模型笨”

这一节是我认为最有价值的部分。因为我原本以为，AI 干活的失败大多是“它没理解对”。数据把这个假设完全推翻了。

失败模式：路径、超时、过期文本

我把全部 9 437 条错误工具结果按错误信息做了模式归类，结果非常集中：

表 6　9 437 条错误工具结果的模式分解

失败模式	条数	占比	根因判断
文件/路径不存在	2 125	22.5%	代理对目录结构的假设与实际不符
工具调用超时	1 563	16.6%	长命令没走后台作业，超时默认值偏短
替换文本未找到	1 141	12.1%	edit 前没重读文件，文本已过期
限流 / URL 主机限制	195	2.1%	外部接口约束（web_fetch 错误率高达 25.3%）
版本冲突 FS_STALE_VERSION	289	3.1%	并发编辑同一文件，被版本守卫拦住
沙箱拒绝	5	0.05%	权限策略几乎从不是瓶颈

两个结论。第一，权限不是瓶颈。整个 64 天里“沙箱拒绝”只有 5 次——把权限设得很严很难带来效率提升，反而会制造大量无效往返。第二，真正的问题是“认知偏差”：它以为文件在那儿、以为文本是那样、以为命令 30 秒能跑完。这些都是工程问题，可以通过规则和习惯修掉，不需要更强的模型。

最坑的一次：Bash 通道整体挂掉

写这份分析的过程中，我遇到了一次很有意思的故障：dsh-ops 的原生 Bash 执行器在准备阶段失败，报 EXECUTOR_UNAVAILABLE，根因是执行载荷缓存树的硬链接计数不匹配。

这个故障的特殊之处在于它是通道级的：一旦触发，本会话内所有 Bash 调用全部失败，而且重试无效——错误信息里明确写了重试和清缓存都修不好这个并发缺陷。恢复要人工三步：停掉所有 OPS host 与 Bash 作业、预览执行树状态、按类型回收缓存。

顺带一提：本机 dsh-ops 已经从 0.5.1 升到 0.5.2（这个版本就是为修这个并发缺陷发的），故障仍然复现。这说明“升级即解决”在这类问题上不成立，必须配合一次主动的缓存回收。

重试：67.5% 是传输问题

64 天里 2 281 次模型请求重试，涉及 451 个会话（41.3%）。按错误码分：传输类（TRANSPORT）1 540 次占 67.5%，限流 321 次、服务端 211 次、超时 209 次。

这个分布很有信息量：绝大多数重试不是模型拒绝服务，而是请求没送到/没回来。所以遇到“频繁重试”，第一反应应该是查网络与代理，而不是换模型。另一组数据也印证了“大部分任务其实是正常完成的”——3 000 个轮次里正常完成 2 584 个（86.1%），异常终止 416 个（13.9%）。

08　插件的真实生态：五千个可发现，十一个在用

DSH 的市场里能发现约 5 000 条 npm 插件、4 738 条 GitHub 项目。我实际装了 11 个第三方插件。这个反差不是因为我保守，而是因为装上不等于用得上——插件不是装了就有用，要靠 patch 层把它们接进主流程。

还有个数据挺能说明生态的成熟度：5 000 条 npm 条目里，声明了兼容范围（enginesDsh）的只有 1 871 条，未声明的高达 3 129 条（62.6%）。换句话说，你随机挑一个插件，六成概率它没有告诉你它兼容哪个内核版本。

表 7　本机装着的第三方插件（节选）

插件	它干的事	我的真实评价
dsh-ops	原生文件工具 + PTC Bash 通道	好用但脆：执行器缓存损坏过，整条 Bash 通道失效
dsh-windows-mcp	桌面自动化（截图/点击/输入/进程）	能力极强、权限极大；依赖独立 Python 工具链，环境隔离要小心
dsh-context	上下文看板与上下文命令	长会话必备，能看见自己还剩多少余量
dsh-config-manager	配置备份/快照/导入导出/同步	省心；但“导出”可能带凭据，必须显式排除
dsh-opencode-go	多账号模型提供商 + 自动切换	多账号场景实用；密钥管理要可控
dshmarket	可视化插件市场	入口类插件；索引依赖外部 CDN，离线不可用
dsh-mobile-plugin	移动端 API 与中继接入	把桌面端能力暴露到网络侧，攻击面明显变大
dsh-win-pwsh7	PowerShell 7 检测与安装	Windows 场景价值高；安装走应用商店，要联网

图 6　插件市场的可发现规模与元数据完备度

注：基于市场索引缓存的静态统计，非实时。

我的两条插件观

• 装得越少越好。插件运行在主进程内，权限等于主程序。每多装一个，就多一份信任。8 个 experimental bundle 里没用的，我建议直接关掉。

• 市场热度不等于适配我的机器。看插件的兼容声明、看它要什么权限、看它最近一次更新时间，比看下载量有用得多。

09　优点和缺点，都用一句话说清楚

我愿意继续用的四个理由

1. 它真的能干活。78% 的工具调用集中在“跑代码 + 读写文件 + 双 Shell”上，39 955 个后台作业在真实并行执行。这不是演示，是日常。

2. PTC 让长任务成为可能。把工具定义和工具返回移出对话，是这套系统能跑到 2 147 步还不崩的关键设计。

3. 多代理协作是差异化能力，不是 PPT。2 153 次 send_message、1 454 次 wait_agent、578 次 spawn_teammate——这套机制被高频使用，而且有共享任务板和写作用域约束着，不至于乱套。

4. 全过程可审计。每一次工具调用的参数与结果都落在存档里。这份报告能写出来，本身就是审计能力的证明。

我会继续吐槽的五个问题

1. 默认配置是“无护栏”档。默认 danger-full-access + 审批 never，意味着它可以不确认就执行任意命令。这是有意设计，但它是默认值。

2. 执行层会出“通道级”故障。Bash 执行器缓存一坏，整条通道停摆，重试无效，只能人工回收。

3. 成本集中在长尾。前 10% 会话吃掉 54.9% 的上下文量。这个风险不在平均值里，在你的少数几个巨型会话里。

4. 复杂度的门槛是真的。装配层、执行形态、权限、代理、运维，五道坎，每一道都能让人卡半天。我的 profile 目录里躺着 11 份 patch 备份，这就是证据。

5. 生态偏年轻。六成插件不声明兼容范围，命名高度同质，质量分化明显。

一句话总结：它把“AI 能不能替我干活”变成了“我的工位该怎么搭”，然后把答案交给了你。

10　如果你也想这么用，这是我的配置清单

最后落点实操。下面这几条不是理论，是我踩坑之后真正改掉的习惯。

权限：从“全信”改到“分级”

表 8　我建议的权限分档

场景	沙箱	审批
日常问答、只读分析	read-only	ask
常规编码、文档修改	workspace-write	ask
批量重构、环境搭建	danger-full-access	ask
无人值守长任务	danger-full-access	never（仅限容器/虚拟机）

任务编排：三条硬规则

• 大任务切成 50–100 步的小闭环。本机主会话中位 130 步、子代理中位 61.5 步——能跑完的长任务都是被正确切碎的。切法：一个分身负责一个模块/一份文档/一个数据源。

• 派活前先声明写哪些文件。共享任务里写清路径范围，让分身只碰自己的文件。跨文件的接口改动交给自己串行处理。本机的 FS_STALE_VERSION 出现 289 次，不少是并发改同一文件导致的。

• 超过 60 秒的命令一律走后台。本机 1 563 次超时里绝大多数是前台跑长命令。启动后台作业 → 继续做别的事 → 用 job_output 取回结果，这才是正确姿势。

成本控制：四件事

• 给单会话设软上限（比如 300 步 / 50M Token），到点收尾、成果落文件、另起会话。

• 保持上下文前缀稳定，别在开头塞大文件，把缓存命中率当成成本指标看。

• 用分身隔离上下文，而不是共享上下文：读大仓库给结论这类活，分身干完只回结论。

• 按任务类型记录 Token，才能知道钱到底花在哪儿。我的结论是：花在重复读大文件和超长会话的上下文重发上，不是花在模型输出上（输出只占全量约 0.5%）。

故障速查：我贴在工位旁边的表

表 9　常见故障速查表

现象	处置	要点
Bash 通道全挂（EXECUTOR_UNAVAILABLE）	停掉所有 Bash 作业 → 预览执行树 → 按类型回收 → 重启	别反复重试，错误信息已说明重试无效
工具调用超时	改后台作业 + job_output，或拆分命令	多为前台跑长命令
edit 报“文本未找到”	重新 read 当前文件，用最新文本重试	文件已被改动
写文件报 FS_STALE_VERSION	重新 read 后基于新版本重写	版本守卫在保护你，不是故障
web_fetch 返回 403 / URL 受限	换来源，或让人提供文本	端点策略限制，非工具缺陷
模型请求频繁重试	看错误码：传输类为主就查网络	本机传输类占 67.5%

最后：这份复盘本身的局限

必须诚实交代三件事，否则上面的数字会被误读。

第一，这是单机样本。我的使用高度集中在编码、GIS 数据处理、长文档与视频生产上，这个分布会显著影响统计结果，不能直接外推到一般用户。

第二，没有对照组。我不知道同样这些任务用别的工具要花多少时间。所以我说“效率优势”，依据的是结构性证据（PTC 结构、后台作业规模、子代理切分），不是受控实验。

第三，评价带主观判断。第 09 节的优点缺点是我的工程经验总结，不是权威结论。其中一个具体缺陷（执行器缓存损坏）在我的机器上可复现，不代表你那儿一定会遇到；反过来，我没有遇到的问题也不代表不存在。