DeepSeek Harness 会话标题不更新：maxOutputTokens 64 被思考吃光

标题停在首条消息的截断文本上，通常不是模型不会起标题，而是标题请求的输出预算被思考吃光了。 内置标题插件复用主对话模型单独发一次请求，max_tokens 是思考与正文的共用额度；强制思考模型先把额度写满，正文为空，插件随后在 max-tokens 分支抛错并只打一条 warn，界面上什么也看不到（Discussion #10129）。

讨论中的复现环境是 0.2.1-rc.2 的桌面版，源码定位由社区核对给出。版本不同，行号可能有偏移，判断依据以配置项和 warn 文案为准，不要只认行号。

DeepSeek Harness 会话标题为什么几乎不更新：64 是思考加正文的总预算

64 这个数字不在插件源码里，而在 bundle 的补丁配置里，这决定了它属于今天就能改的配置问题。 社区核对源码给出的链路是四步：

1. packages/session/session-title-llm/src/index.ts:84 把 maxOutputTokens 声明为 z.number().step(1).min(1).required()，是 required 且没有默认值。
2. packages/experimental/session-titles-bundle/cordis.patch.yml:10-11 给了 maxInputBytes: 4096 与 maxOutputTokens: 64，插件照单全收。
3. 强制思考模型把 64 个 token 全用在 reasoning 上，finish_reason 变成 length，content 为空。
4. session-title-llm 在 :202 的 max-tokens 分支抛出 title output reached maxOutputTokens，该错误只在 catch 里 warn，不写会话事件流。

据讨论里的实测对照：max_tokens=64 时 reasoning_tokens=64、正文为空；调到 1024 时 reasoning_tokens=139、标题正常；1024 且不带思考档位时 reasoning_tokens=0、总 token 只有 9。这组数字说明 64 不是「五个词的标题够了」，而是默认了模型不思考。

DeepSeek Harness 三步确认问题在标题额度，而不是模型能力

先用可观测证据把「模型不行」排除掉，再动配置。 三步都能在本地完成：

1. 新建一个会话，只发一条消息，完成两轮对话后看侧栏标题。预期结果：标题仍是首条消息的截断文本，没有任何错误提示。
2. 打开当前 profile 的 cordis.patch.yml，搜 session-titles，确认同一段里有 maxOutputTokens: 64。预期结果：能看到 64 与 4096 两个值，说明生效的是 bundle 补丁而非插件默认值。
3. 用同一模型手动发一次带 max_tokens: 64 与思考档位的请求，记录 finish_reason 与 reasoning_tokens。预期结果：finish_reason=length、reasoning_tokens=64、content 为空，与标题插件的失败路径完全一致。

三步都对上，就不用再怀疑模型或网络，问题在额度。

DSH插件路径一：用 cordis.patch.yml 提高 maxOutputTokens

这是改动最小、见效最快的一条路，只影响标题请求，不动主对话模型。 操作步骤：

1. 找到 bundle 补丁里 session-titles 那一段，记下它的插件 id。预期结果：得到一个可被用户层 patch 命中的 id。
2. 在用户层 cordis.patch.yml 里按同一 id 增加覆盖块，把额度写大，同时重申 maxInputBytes：

#按 bundle 补丁里的同一 id 覆盖，config 整块替换
- id: <session-titles 对应的插件 id>
  config:
    maxInputBytes: 4096
    maxOutputTokens: 1024

3. 保存后重载 profile，新建一个会话并对话两轮。预期结果：侧栏出现模型生成的短标题，而不是首条消息的截断文本。
4. 回看会话事件流，确认不再出现 title output reached maxOutputTokens。预期结果：warn 消失，标题请求正常结束。

注意这条路的边界：补丁不深合并，漏写 maxInputBytes 会把 4096 变成未设置；已经写入兜底标题的存量会话不会自动重算，因为兜底标题不作为后续请求的锚点。

DeepSeek Harness 路径二：让标题请求不思考

这条路的思路是让 64 个 token 全部留给正文，但据讨论它不能只靠配置完成。 现状是标题插件复用主对话模型、思考档位写死取列表第一项，显式的关闭项会在发请求前被删掉，服务端对 off 返回 400 与错误码 11150（据讨论，报告者实测）。可行做法有两条：

1. 给标题单独配一个不强制思考的小模型。预期结果：同样的 64 额度下 reasoning_tokens=0，标题能正常返回；这需要插件侧支持标题模型与主对话模型分开配置。
2. 改插件让思考档位可配置，或允许在标题请求里保留 off。预期结果：请求不再被强制加上思考档位，content 非空。
3. 改完后用路径一里的第 3 步复测一次。预期结果：finish_reason=stop，正文非空，标题更新。

如果不想改代码，这条路走不通，直接用路径一或路径三。

DeepSeek Harness 路径三：改用本地截断标题

不调用模型就没有额度问题，代价是标题只反映首条消息。 适合标题只用来区分会话、不需要语义概括的场景：

1. 在用户层 patch 里禁用 session-titles 那一行（按当前宿主的 patch schema 写 disabled）。预期结果：重启后不再发标题请求，日志里也没有标题相关 warn。
2. 确认侧栏标题回落到首条消息的截断文本。预期结果：新会话标题稳定、可预测，但不会随对话变化。
3. 如果截断文本太长或带换行，自己写一个小插件在会话创建时生成本地标题，只做空白折叠与定长截断。预期结果：标题长度统一，且完全不消耗 token。

这条路的取舍很直接：零成本、零失败，但失去了语义标题。多会话并行、靠标题找会话的人，还是建议走路径一；要换第三方标题插件的话，先在 DSH Plugin Hub 核对兼容版本。

DeepSeek Harness 三条路怎么选，以及改完看什么

新会话优先路径一，插件开发者优先路径二，只求稳定可读选路径三。 收尾检查按顺序做：

1. 改完配置后重启一次 profile，而不是只刷新页面。预期结果：补丁重新加载，旧进程里的 64 不再生效。
2. 新建会话验证标题生成。预期结果：两轮内出现语义标题。
3. 发一条长消息把输入推过 4096 字节，再对话一轮。预期结果：如果标题停止更新，说明撞的是 maxInputBytes 而不是额度，需要按路径三或改输入策略处理。

据讨论，这三个问题（额度太小、超限直接抛、失败静默）是相互独立的缺陷，调大额度只解决第一个。想彻底稳定，输入侧要改成取最近若干条并截断，失败要能在界面上看见。

三条路的差异可以直接对照：

如果只是想让新会话马上有标题，路径一足够；如果还想让超长会话也不掉标题，必须同时处理输入裁剪，单靠调额度会在会话变长后回到原点。

不管走哪条，都建议顺手补一条可观测的验证：删掉现有标题后再触发一次标题请求，看会话事件流里有没有对应的成功记录。没有记录就说明失败仍然静默，这条链路的修复只做了一半。

来源：Discussion #10129、deepseek-ai/deepseek-harness。会话标题只是症状之一，更多排查入口见 DSH 故障排查。