DeepSeek Harness 会话标题怎么生成？fallback、provider 与用户重命名

DeepSeek Harness 的会话标题不是“界面上随手写的一行字”，而是一条持久的 session/title 事件：它记录标题、生成时用了哪些用户消息、以及来源是 fallback、provider 还是用户。 这条事件决定后续还会不会自动更新。理解三种来源，就能解释“为什么手动改名后模型不再改标题”和“为什么标题偶尔停在第一句”。

DeepSeek Harness：三种来源

标题只有三种来源，优先级与行为各不相同。 对照：（来源）

session/title 事件里还会记录 messageSeqs：生成这个标题时用了哪些用户消息。用户重命名时这个列表为空，因为标题不是从消息推导出来的。

标题投影只保留字符串或 null，所以旧缓存行仍可读取；客户端不需要理解完整事件结构。

DeepSeek Harness：生成节奏

provider 注册时声明 first-prompt 或 all-prompts，决定它什么时候被调用。 两种：（来源）

1. first-prompt — 只在新会话的首条人类提示后生成一次。预期：标题稳定，但后续长对话不会改名。
2. all-prompts — 每次新的人类提示都可能生成修订。预期：标题更贴近当前主题，但调用次数更多。

服务会在调用 provider 前确保 fallback 与最新已接纳标题快照，并把它作为 currentTitle 传入。provider 可以决定是否利用旧标题。

provider 返回的 messageSeqs 必须来自本次请求的消息列表；服务会校验顺序，不会接受凭空构造的 seq。

DeepSeek Harness：重命名与 refresh

重命名不是“覆盖一个显示字段”，而是写入一条 source 为 user 的标题，并把自动生成钉住。 行为：（来源）

1. rename(session, title) — 规范化后写入 session/title。预期：标题立即更新，后续用户消息不再调度自动生成。
2. 进行中的生成被取代 — 在途 provider 结果不会覆盖用户改名。预期：不会出现“刚改完又被模型改回去”。
3. refresh(session) — 显式重试 provider，或在没有 provider 时物化 fallback。预期：这是解除钉住、重新生成标题的刻意动作。

如果 rename 传入的标题规范化后为空，会抛出 SessionTitleInvalidError；会话不在运行或服务已释放时也会失败。

DeepSeek Harness：标题请求记录与字节上限

标题生成是一次真实的辅助模型请求，服务会记录它可见的输入与路由。 记录包括：（来源）

• titleProvider — 哪个 provider 负责。
• messageSeqs — 请求里包含的用户消息 seq。
• route — provider 与 model。
• system 与 messages — 模型实际看到的系统提示与消息。
• maxTokens — 输出上限。
• reasoningEffort — 解析后的推理强度，旧请求可能没有。

这些记录在调用前写入，即使后续生成失败也能复现模型看到的输入。标题写入前还会执行规范化与字节上限；超限不会原样保存。

DeepSeek Harness：三种策略怎么选

内置 fallback、注册 provider、用户重命名，各自解决不同问题。 三种：（来源）

1. 只用 fallback — 不注册 provider，标题来自首条消息或内置规则。预期：零成本，但标题可能不够贴切。
2. 注册 provider — 用模型生成更可读的标题，按 first-prompt 或 all-prompts 更新。预期：需要额外的辅助请求与失败处理。
3. 用户重命名 — 手动钉住一个稳定标题。预期：适合重要会话，之后不再自动改。

如果标题长期停在首条消息的截断文本，先查 provider 是否真的注册、输出预算是否被思考吃光；这类问题与“三种来源”是两层，不要混在一起。

DeepSeek Harness：标题状态怎么查

不要只看界面标题，回到事件与快照才能知道它来自谁、还会不会变。 步骤：（来源）

1. 看 session/title 事件 — 确认 source 是 fallback、provider 还是 user。预期：知道后续是否还会自动生成。
2. 看 messageSeqs — 确认标题基于哪些用户消息。预期：能解释标题为什么停在某一句。
3. 看 eventSeq 与 updatedAt — 确认最近一次标题更新的位置与时间。预期：判断是否长期没更新。
4. 看辅助请求记录 — 确认 provider 调用是否真的发生、输出上限是多少。预期：区分“没调用”与“调用了但失败”。

界面只显示字符串或 null，排查时必须看事件层。

如果事件里有 provider 调用记录但标题没变，重点看返回的 messageSeqs 是否来自本次请求；服务不会接受越界的 seq。

provider 的请求与结果字段

标题 provider 的契约很窄：读快照，返回标题与归因。 对照：

服务会校验顺序、规范化标题、强制字节上限，再写入 session/title。provider 不应自己写事件。

DeepSeek Harness 常见问题

Q：删除 provider 后标题会回到 fallback 吗？ 已有标题是持久事件，不会因为 provider 卸载自动重写；新的生成会按当前可用能力走 fallback 或新 provider。

Q：能不能给不同会话用不同 provider？ 服务在每个上下文只允许一个可选 provider；不同 profile 或不同 home 可以装不同实现。

Q：标题生成会消耗模型额度吗？ 会。它是辅助模型请求，有独立的 maxTokens 与路由记录；不要把它当成纯本地字符串操作。

一句话收束： 会话标题的关键不是“生成得多漂亮”，而是“这条持久事件来自谁”；来源决定它还会不会变。