You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
~/.dsh/.agent-presets/code/agent.cordis.yml # 以内置 standard 为蓝本(SHA256 与内置 standard 逐字节相同)
~/.dsh/.agent-presets/code/preset.yml # name / description / order
生效条件(源码确认):
id 需匹配 PRESET_ID = /^[a-z0-9][a-z0-9-]*$/
预设目录必须是用户根下的一级子目录,且直接含 agent.cordis.yml(不要多套一层)
用户根由 includeUserRoot(默认 true)自动加入,无需额外配置
list() 无缓存 + settings 热重载 → 无需重启即可对新建会话生效
给遇到同现象的人:先查默认值
出现「新建会话没反应 / 历史会话无响应」时,先查 settings.yaml 的 agent-presets.default 是否指向一个真实存在的预设——这比 persona 字段更常见,也更容易被忽略。逐项确认:
settings.yaml 中 agent-presets.default 的值
该 id 是否存在:~/.dsh/.agent-presets/<id>/,或属于内置的 cordis / minimal / ptc / standard
Activity
Reuse persona text as prefix anchor
xrk-hhh commentedon Sep 9, 2026
补充一条同根因、但现象更严重的实测记录(dsh
0.1.5-alpha.1,Windows 11,源码构建),供一并排查。除「无响应」外,还会把 CPU 打满
用户侧感受是「dsh 卡顿,设置里的功能也卡」:
node进程持续占用 ~100% 单核(实测 10 秒墙钟消耗 9.5 秒 CPU),而界面并不报错。机制(插桩实测)
打开的会话页会对该会话持续重试 resume(约 25 次/秒)。每次重试都走完整链路:
session-controller.resumeObserved→composeAgent→preset.resolve()→list()→discoverPresets()而
discoverPresets()无缓存:每次都重新读取并对所有预设的每一行做一次existsSync体检。CPU profile 中existsSync占 37%、unresolvableRows占 35%。插桩日志(
resumeObserved内捕获):即:装配失败 → 客户端重试 → 每次重试触发全量预设体检 → CPU 打满 → 整个 UI(含设置页)卡顿。失败与重试之间没有任何退避。
受影响范围
本机
0.1.5-alpha.1实测:router-standard/router-spec/router-react三个预设的 persona 行均为text:,全部无法装配;仓库内preset/router-*/agent.cordis.yml同步确认(截至e3f00b2)。临时修复与效果
persona 行
text:→prefix:(已装目录 + 仓库副本各一处),改完:另
harness 侧的「体检无缓存 + 失败无退避」已在官方 Discussions 单独反馈(含 profile 数据):
deepseek-ai/deepseek-harness#6012
limpidautumn commentedon Sep 10, 2026
遇到了相同问题,今天还没修。
临时补丁脚本:
Windows
Linux
zhou-dingkun commentedon Sep 12, 2026
补充:同现象的另一根因——
agent-presets.default悬空(不是 persona 字段问题)本机在
dsh 0.1.5-rc.1(Windows 11)出现与主帖完全相同的现象,但排查后确认根因不同,记录在此供对照。现象
先排除主帖的根因
~/.dsh/profiles/node_modules/@deepseek-ai/dsh-agent-presets/presets/*/agent.cordis.yml:内置预设用的都是新字段prefix:,不存在text:router-*预设)→ 主帖的 persona 字段改名机制在本机不成立。
定位过程
~/.dsh/sessions/<workspace>/<session>/session.jsonl.zstd,用 Node 内置 zstd 解压统计:结果:20 / 20 个会话的
agentPreset都是"code"。读
@deepseek-ai/dsh-agent-presets/lib/index.js:SETTINGS_NAMESPACE = "agent-presets";get defaultId()每次现取settings.get().default ?? config.defaultresolve(id):roster 里找不到即抛agent-preset/not-found(错误里带available: …)list()→discoverPresets(),无缓存,每次调用重新扫描SHIPPED_PRESET_ROOT只有cordis / minimal / ptc / standard<dshHome>/.agent-presets(includeUserRoot默认 true)dsh-web-app/cordis.patch.yml中部署默认是default: standard本机
~/.dsh/settings.yaml:而
~/.dsh/.agent-presets整个目录不存在 → 新建会话装配默认预设时resolve("code")必然not-found。根因
settings.yaml里的默认预设code是一个悬空引用(指向已不存在的预设)。新建会话必须装配默认预设,于是被agent-preset/not-found拒绝;而该错误只存在于 RPC 响应体里,UI 不展示,故表现为「点了没反应」。一个关键佐证(也解释了为什么只有"新会话"坏)
源码中
remove(id)删除本地预设时,若用户默认值恰好指向它,会一并清除该默认值,注释写得很明确:"留着会让所有未显式指定的新会话无法启动"。本机的默认值仍然指向
code,说明.agent-presets是在 DSH 之外被删除的(手工删除 / 覆盖安装 / 清理脚本),绕过了这层兜底。这也印证了设计语义:"运行中的会话停留在它当初据以组装的 preset 上",所以已开会话照常工作,只有此后新建的会话受影响。
修复(本机已验证)
按预设发现规则补回用户预设(目录名即预设 id):
生效条件(源码确认):
PRESET_ID = /^[a-z0-9][a-z0-9-]*$/agent.cordis.yml(不要多套一层)includeUserRoot(默认 true)自动加入,无需额外配置list()无缓存 + settings 热重载 → 无需重启即可对新建会话生效给遇到同现象的人:先查默认值
出现「新建会话没反应 / 历史会话无响应」时,先查
settings.yaml的agent-presets.default是否指向一个真实存在的预设——这比 persona 字段更常见,也更容易被忽略。逐项确认:settings.yaml中agent-presets.default的值~/.dsh/.agent-presets/<id>/,或属于内置的cordis / minimal / ptc / standardagent.cordis.yml另:不要把手工删除
~/.dsh/.agent-presets/<id>当作常规手段。请用 GUI 的删除(会同步清掉悬空默认值),或删完手动把default改回内置值(如standard)。顺带:harness 侧可改进项(与主帖评论方向一致)
discoverPresets()无缓存 + 失败无退避 → 打开会话页会高频重试(主帖评论实测 ~25 次/秒、单核打满)resolve()才失败 → 建议写入时校验,或解析失败时把available列表透出到 UIzhangweijian97 commentedon Sep 12, 2026
确认:该问题在 dsh 0.1.5-rc.1 上仍会复现。
现象与本 issue 一致——选工作区后闪回、无法新建会话;浏览器控制台可见:
本地把
router-standard/router-spec/router-react的 persona 行text:改成prefix:后,预设挂载与session.create均恢复正常。已有修复 PR:
text→prefix+ 契约测试session.events→snapshotEvents(对 0.1.5 更完整)建议优先合 #110(或先合 #109 止血)。本条评论仅作版本复现确认,不另开重复 PR。