[Bug] 内置会话标题插件几乎从不更新：输出额度 64 个 token 被思考吃光，失败还完全静默（DSH 0.2.1-rc.2）

[bigbigyu-Blue]

环境：DSH Desktop 0.2.1-rc.2（Windows），主对话模型是强制思考模型，即使思考档位取最低，也必须先输出思考。

现象：左侧会话列表的标题长期停在「第一条用户消息被截断」的兜底文本上，多轮对话后也不更新，界面上没有任何提示。

根因：

• 内置标题插件（session-title 加 all-prompts 提供者）在每次收到用户消息后单独发一次标题请求，复用主对话模型，输出额度写死 64。
• 强制思考模型会先把这 64 个 token 写满思考，正文一个字都留不下。实测 max_tokens=64 时 finish_reason=length、reasoning_tokens=64、content 为空；max_tokens=1024 时 reasoning_tokens=139，标题正常；max_tokens=1024 且不带思考档位时 reasoning_tokens=0、总词元 9。
• 代码在 finish 为 max-tokens 时抛出 session-title-llm: title output reached maxOutputTokens，该错误只在 catch 里打成 warn，不写入会话事件流，界面也无提示，于是表现为「标题永远不更新」。

验证：把该提供者的 maxOutputTokens 从 64 调到 1024 后，同一台机器上新会话立刻正常生成标题（标题从第一条消息的截断变成模型生成的短标题）。

顺带报告的 11 条设计问题（按严重程度）

1. 失败完全静默：只有 warn，不进会话记录，界面无状态。
2. 输出额度 64 小于思考本身：思考与正文共用额度，按「标题只有 5 个词」估算忽略了思考成本。
3. 输入超过 maxInputBytes 4096 字节直接抛错，不裁剪、不改取最近若干条，长会话从此永久不更新。
4. 每次全量重发全部用户消息，不增量、不摘要，输入单调增长，必然撞上第 3 条。
5. 提示词鼓励什么都不做：旧标题仍准确就原样返回，且追问、致谢、要求继续都不构成改名理由。
6. 思考档位写死取思考档位列表的第一项，不可配置。
7. 关不掉思考：显式设成关闭也会在发请求前被删掉；服务端对 off 返回 400 与错误码 11150。
8. 标题请求复用主对话的模型与渠道，主对话换成强制思考模型后标题直接失效。
9. 收集消息时丢弃图片块，只取文本。
10. 失败不重试，同一条消息不会再有第二次请求。
11. 兜底标题（第一条消息的截断）被当作正式标题写入会话记录，且不作为后续请求的锚点。

建议

输出额度提到 512 以上，或为标题单独配一个不思考的小模型；输入超限改为取最近若干条并截断；失败在界面可见并写进会话记录；请求改增量式；思考档位可配置；标题模型与主对话模型分开配置。

[PerryLink]

现象和机制都对，但「输出额度写死 64」这个说法要改一下 —— 64 不在代码里，它是bundle 补丁的默认值，schema 那边是 required、不给默认。这个区别决定了这件事今天就能自己解决，不用等版本。

已核实

• packages/session/session-title-llm/src/index.ts:84 —— maxOutputTokens: z.number().step(1).min(1).required()。required，没有 default。
• packages/experimental/session-titles-bundle/cordis.patch.yml:10-11 —— 真正的 64 和 4096 在这里：

        maxInputBytes: 4096
        maxOutputTokens: 64

所以链路是：bundle 补丁给了 64 → 插件照单全收 → 强制思考模型先把 64 用完 → :202 的 max-tokens 分支抛错 → 只 warn。你说的"输出额度 64 小于思考本身"完全成立，只是它发生在配置层而不是源码层。

这意味着三件事

1. 你现在就能改，不用等发版。 在用户层 cordis.patch.yml 里按 id 覆盖 maxOutputTokens 即可（注意补丁是 config 整块替换、不深合并，maxInputBytes 要一起重申）。你实测 1024 就正常，那就是一个配置改动。
2. 但 maxInputBytes: 4096 才是长期的那个。 你列的第 3、4 条（超限直接抛、每次全量重发）合起来意味着：即使标题额度调大，会话一长，输入必然撞 4096 字节然后永久不更新。所以 64 → 1024 只是止血，真正要改的是"输入超限时改成取最近若干条"。
3. 静默这一条是独立缺陷，且值得单独提。 错误只在 catch 里 warn、不写会话事件、界面无状态 —— 这跟你列的第 1 条是同一件事。它和"64 太小"没有因果关系：即使额度够，任何一次失败也照样不可见。报告里把这两条拆开，维护者更容易分别受理。

关于"思考与正文共用额度"

这是判据上的关键，值得写进标题：max_tokens 是思考 + 正文的总预算，不是正文预算。你实测的 max_tokens=64 → reasoning_tokens=64 → content 空 是这条规则最干净的证明。同理，任何"标题只有 5 个词所以 64 够了"的估算都默认了不思考，这个假设在强制思考模型上不成立。

最后一点建议

你列的 11 条里，第 11 条（兜底标题被当作正式标题写入，且不作为后续请求的锚点）其实比第 2 条更值得单独立项：它意味着一旦兜底标题落盘，后续就再也没有"更新"的起点，所以即使额度修好，已经产生的会话也不会自愈。这一条决定了"修好之后存量会话能不能恢复"，比额度数值影响面更大。

[hcconquer]

补充你第 3、4 条的实测证据，这条和 token 额度是相互独立的第二个故障，建议单独修。

你写「输入超过 maxInputBytes 4096 字节直接抛错」，我按会话日志量了一下，受影响最集中的是 subagent 会话。

为什么 subagent 天然超限

subagent 的首条 user message 是完整的委派说明（含任务描述、约束、父会话 id、回复要求），本身就长。而 executeSessionTitleLlm 是在测完 maxInputBytes 之后才抛错的，且抛在 session.append('session/title-llm-request', …) 之前——所以超限会话连一条请求记录都不会留下，日志里完全看不到"试过了"。

代码路径（packages/session/session-title-llm/src/index.ts）：

const inputBytes = Buffer.byteLength(prepared.input, 'utf8')
if (inputBytes > config.maxInputBytes) {
  throw new Error(`session-title-llm: input is ${inputBytes} bytes, exceeding maxInputBytes ${config.maxInputBytes}`)
}
// …之后才 append('session/title-llm-request', …)

数据

117 个真实会话（剔除 10-09 那批 Reply with exactly: PONG 的 e2e 压测会话）。all-prompts 生效之后（首次观测到该 provider 的请求是 2026-10-10 16:19）创建、且零 session/title-llm-request 的 subagent 会话，共 5 个，按 provider 的 framing 公式重算输入字节数：

会话创建日	framed 输入	4096 上限
2026-10-15	4940 B	超
2026-10-16	5190 B	超
2026-10-16	4935 B	超
2026-10-16	4874 B	超
2026-10-18	4481 B	超

5/5 全部超限，没有例外。这些会话的标题至今是首条消息的前 5 个词，比如 You are reviewing the DeepSeek、You are auditing a user's、You are researching the third-part。

对照组：同一时期同批次的 subagent，输入 1522B / 1852B / 2172B 的全部成功生成了模型标题。

和 token 额度是两件事

我这边 bundle 阶段的 9 个失败会话里，只有 3 个是 cap=64，另外 5 个是根本没有请求（即上表）。所以把 maxOutputTokens 提到 4096 不能解决 subagent 这一半。

你第 4 条（输入单调增长）的补充

顺带确认：all-prompts 每次重发全部历史 user message。本机最长的一条请求带了 17 条消息，但只有 1612 字节——因为这几条都不长。一旦有长消息进来，字节数会很快撞线。所以你说的"必然撞上第 3 条"是对的，只是对 subagent 而言是第一条消息就已经撞上。

建议

你提的「输入超限改为取最近若干条并截断」正是对的方向。补充一点：截断策略要能保证至少有一条消息进入请求，否则会退化成同样的静默失败。另外现在这个失败路径完全不可观测，即使不改截断策略，也应该先让它写进 session/title-llm-request 或至少留一个可查的失败记录。

[lgzzzz]

• 我来补一个临时的解决办法, 插件开放了配置项, 将一下内容写入对应profile的的patch文件, 比如.dsh/profiles/web/cordis.patch.yml中, 可以临时解决问题

- id: optional-session-title-all-prompts
  config:
    targetWords: 5
    targetCjkCharacters: 10
    maxInputBytes: 4096
    maxOutputTokens: 4096
    timeoutMs: 60000