企业官网建设流程全解析

用过 Waku（一个面向所有 coding agent 的原生应用）的人都会有个感受：侧边栏里的每个会话都有一句言简意赅的好名字，比如 "Refactor sidebar row builder allocations"，而不是干巴巴的 "New task"。这篇文章带你揭秘 Waku 会话自动标题生成机制：11 个 Provider 各自如何命名会话、Waku 如何以最低成本把它们接进来。

一个核心原则：让 Provider 自己给自己命名

Waku 的总原则写在 docs/titles.md 里：谁干活，谁起名。

除了 Codex，所有编码 agent 本来就会用自家最便宜的小模型给自己的界面生成标题。Waku 的工作只是找到这个标题并尽快显示出来，而不是花钱请一个"第二意见"。自己生成标题是例外，只服务于那一个不自己起名的 Provider。

这也是 Waku 会话标题不花钱的秘密：标题生成费用几乎全部由 Provider 用自己的低成本模型承担。

两个标题字段：谁说了算？

每个会话（AgentSession）身上有两个标题字段：

display_title 的解析顺序是：手动title→auto_title→ 默认值 "New task"。所以 Provider 生成的标题永远覆盖不了你亲手输入的名字。

本地占位标题：前 7 个单词

在真正的标题到达之前，Waku 会先放一个占位符：set_title_from_prompt 取首条 prompt 的前 7 个单词（截断到 54 字符）写入auto_title，每个会话只执行一次。

这个占位符和真标题共用auto_title字段，这样真标题一到就能无声替换它。所以衡量好坏的标准只有一个：多快能替换掉占位符。标题拖到整轮结束才出现，等于没有标题。

三种交付形态：标题是怎么送到 Waku 手里的

所有 Provider 最终都汇入同一个事件DriverEvent::AutoTitleUpdated，在 streaming.rs 被消费一次，统一走set_auto_title（去空格、空值归一），并且落地即持久化。区别只在于标题怎么到达这个事件：

形态一：流式推送（Push）

Agent 在自己的事件流里直接发送标题事件，driver 转发即可，无需轮询、无需调度。OpenCode、Pi、Oh My Pi、Kimi、DeepSeek 走这条路。

形态二：轮询本地存储（Poll）

Agent 把标题写进磁盘文件，但不发到网络流上。Waku 用 NativeTitleRefresh 按退避时间表轮询。Claude、Amp、Grok 走这条路。

NativeTitleRefresh的设计很克制：一个AtomicU8状态机（IDLE/RUNNING/RESOLVED），起一个后台线程按Vec<Duration>逐个睡眠后查一次，命中第一个非空结果就发出事件并锁存RESOLVED，之后不再重复。如果时间表走完还没找到，就回到IDLE，下一轮可以重新武装。

时间表就是整个设计决策：要足够密，才能贴近 Provider 写标题的时机；又要足够长，才能熬过慢启动。

形态三：Waku 自己生成（Generate）

只有 Codex 一家。因为 Codex app-server 会持久化线程名但从不生成线程名——命名是客户端的责任。

逐个 Provider 的标题机制拆解

Claude Code：Haiku 4.5 顺手起名，2.9 秒落盘

Claude Code 本来就用自己的 Haiku 4.5 给会话起名，且与主模型请求并行发出，实测标题在 prompt 后约2.9 秒写入本地 transcript 文件~/.claude/projects/*/<session_id>.jsonl，是一条独立的ai-title记录：

{"type":"ai-title","aiTitle":"Refactor sidebar row builder allocations","sessionId":"…"}

Waku 有两条读取路径（claude.rs）：

• 每条 prompt 都武装轮询：在 5s、10s 各查一次磁盘，第一次查标题通常已经在了；
• 轮次结束时再读一次：负责捡起"更晚的重命名"。

两个容易踩的坑：

1. 首条 prompt 短于 10 个字符，Claude 根本不会触发标题生成。所以一个 7 字符的提问永远保持截断占位符——这是正确行为，不是 bug；
2. 文件里后出现的custom-title（你在 Claude Code 里重命名的结果）会胜出，所以手动改名不会被覆盖。

Codex：Waku 亲手生成的唯一例外

在 generate_codex_title 里，Waku 会再起一个短命的codex app-server子进程跑一次只读的一轮：

• 模型用最低档gpt-5.6-luna（codex.rs），effort 设为low——标题就是个固定的分类任务，用最便宜的层；
• 输入只有你的原始 prompt，指令要求"不超过 6 个词的纯标题"；
• 结构化输出锁定{title: string}，最多 80 字符；
• ephemeral: true，不留任何线程，60 秒超时，每个会话只跑一次，恢复会话时不跑；
• 结果先发事件更新侧边栏，再写回 Codex——即使回写失败，界面也已经更新了。

Amp 与 Grok：轮询的两种姿势

• Amp：生成标题但不放流上。amp_session.rs 直接调amp threads list --json子进程按线程 id 匹配，在500ms、2s轮询。注意它是在轮次结束时才武装——因为 Amp 要产出点东西之后才起名；
• Grok：标题写在<grok_home>/sessions/*/<session_id>/summary.json的generated_title字段（grok_session.rs），轮询时间表为0、250ms、750ms、1.5s、3s、5s、7.5s、10s，在轮次结束事件触发。

OpenCode、Pi、Oh My Pi、DeepSeek：流式推送四兄弟

• OpenCode：session.updated事件带出标题。以"New session - "开头的会被丢弃——那是 OpenCode 自己的占位符，比 Waku 的 prompt 占位符更没用；
• Pi / Oh My Pi：连接时读一次，之后靠流事件更新。两者事件名不同（session_info_changedvssession_info_update）、字段名也不同（namevstitle），pi.rs 用PiFlavor统一处理。发空值会被当成"清回占位符"；
• DeepSeek：Harness 的session/title事件，外加连接时从历史投影回放一次title——这样重连的老会话不用等新标题，直接带上名字回来。

Kimi Code：标题就是原话

Kimi 是第一个真正走通用 ACPsession_info_update处理器（acp.rs）的 Provider，无轮询、无额外进程。但要注意：它发的标题就是你首条 prompt 的原话，标记为titleKind: "replaceable"的占位。所以别把 Kimi 的标题当成"agent 做了总结"的证据——它和 Waku 自己的占位符内容一模一样。

Cursor：没有标题路径

Cursor 至今没有任何标题来源，整个会话生命周期都显示截断 prompt 占位符。

三个高频问题快答

Q：为什么我的会话一直是截断的问题原文，没有好名字？大概率是 Cursor（无标题路径），或首条 prompt 太短（Claude 少于 10 字符不生成标题），或 Kimi 的占位符还没被替换。这些都是预期行为。

Q：我手动改的名字会被自动标题覆盖吗？不会。display_title的解析顺序里用户标题永远排第一，Provider 标题只能替换占位符（model.rs）。

Q：标题生成会额外花我多少钱？几乎为零。11 个 Provider 里 10 个用的是自家便宜模型顺手生成；只有 Codex 由 Waku 调一次最低档小模型，且每会话一次、一次性进程。失败一律静默，占位符保底——标题缺失只是美观问题，绝不会阻塞你的会话。

相关资料

• 官方文档：docs/titles.md
• 标题刷新核心实现：crates/waku-core/src/driver/title_refresh.rs
• 双标题字段与解析逻辑：crates/waku-protocol/src/model.rs
• 各 Provider 驱动：crates/waku-core/src/driver/
• 事件消费点：src/app/streaming.rs