Version: 0.9.54.dev.260429

后端：
1. reasoning 摘要提示词升级为“增量阶段摘要”口径——`reasoning_summary` 明确区分 `previous_summary` / `delta_reasoning` / `recent_reasoning` 语义，要求摘要优先表达本轮新增推进、修正、卡点与下一步动作，避免重复改写整段思考上下文；`short_summary` / `detail_summary` 的长度、句式和完成态约束同步收紧

前端：
2. AssistantPanel 正式切到 `thinking_summary` 协议——SSE extra 新增 `thinking_summary` 接入，按 `messageId + block_id/stage` 维度去重，同一条消息只保留一个 reasoning block；长摘要改为逐字流式追加，历史 timeline 恢复时一次性回放 detail_summary，不再依赖旧 `reasoning_content` 主链
3. 深度思考展示与自动跟随重构——新增 thinking stream 队列/定时器清理、首条消息 follow line 对齐、首发空态过渡抑制、message list 隐身对齐期与 follow spacer 补偿，解决新会话首条消息、长 reasoning、展开收起工具卡/思考框时的“先上屏再瞬移”与底部跟随线漂移问题
4. 助手消息块渲染继续收敛——仅展示真正有可见输出的 assistant source，活跃空 assistant 保留稳定 answering indicator；移除旧 `quickActions` 建议 chips，工具卡/状态块/业务卡片/排程卡片与 thinking block 的时序整合更稳定
5. timeline 类型补注释——`reasoning_content` 标记为仅供 Debug mock 和 legacy 后端兼容，生产页已切换到 `thinking_summary` 协议

backend/newAgent/prompt/reasoning_summary.go

@@ -67,7 +67,7 @@ func BuildReasoningSummaryMessages(input ReasoningSummaryPromptInput) []*schema.
 
 	return []*schema.Message{
 		schema.SystemMessage(buildReasoningSummarySystemPrompt()),
-		schema.UserMessage("请把下面的模型思考内容整理成用户可见的进度摘要。\n输入：\n" + string(raw)),
+		schema.UserMessage("请基于 delta_reasoning 生成本轮新增的用户可见阶段摘要；recent_reasoning 仅作上下文，previous_summary 仅作去重参考。\n输入：\n" + string(raw)),
 	}
 }
 
@@ -80,14 +80,22 @@ func buildReasoningSummarySystemPrompt() string {
   "detail_summary": "不超过 max_detail_summary_runes 个字的展开摘要"
 }
 
+字段语义：
+- previous_summary：上一条已经展示给用户的摘要，只用于判断哪些内容已经说过。
+- delta_reasoning：本轮新增 reasoning，是生成 detail_summary 的主要依据。
+- recent_reasoning：全量尾部上下文，只用于补齐题目、变量名、阶段背景，不要按它重写一遍完整摘要。
+
 规则：
-1. 只描述“正在做什么”和“目前推进到哪一步”，不要复述、引用或暴露原始思考链。
+1. 不输出 markdown，不输出代码块，不解释 JSON 以外的内容。
-2. 不输出 markdown，不输出代码块，不解释 JSON 以外的内容。
+2. 摘要要像“阶段更新”，不是流水账；优先写新增结论、阶段变化、卡点、修正、下一步动作。
-3. short_summary 要短、稳定、适合前端几秒刷新一次。
+3. detail_summary 以 delta_reasoning 为主；previous_summary 已覆盖的信息不要大段重复，除非本轮对它有修正或推进。
-4. detail_summary 不按固定句数限制，而按输入长度控制：字数必须小于等于 max_detail_summary_runes；不需要凑满上限，信息密度优先。
+4. short_summary 用 8 到 18 个汉字，偏结果或动作短语，例如“补齐边界条件”“转入代码实现”“优化滚动数组”。
-5. detail_summary 仍然面向用户，不写内部推理细节、隐含假设链、逐步演算。
+5. detail_summary 用自然的一到两句话表达，优先以具体对象、动作或结果开头，不要把“正在”“当前”“已确定”“已完成”作为默认句首模板；若 previous_summary 已使用类似开头，本轮必须换一种表达。
-6. 若输入为空或噪声较多，用保守摘要，例如“正在整理思路”“正在核对可用信息”。
+6. final=false 时不要用“已完成”概括整体任务；只有 delta_reasoning 明确完成某个局部步骤时，才可描述该局部已经完成。
-7. final=true 时，detail_summary 用完成态语气，说明思考已收拢到下一步答复或动作。`)
+7. detail_summary 字数必须小于等于 max_detail_summary_runes；不需要凑满上限，信息密度优先。
+8. 不暴露原始思考链、隐含假设链、逐步演算，只保留用户可见的进展。
+9. 若本轮没有实质新增信息，输出保守但不重复的摘要，例如“沿用上一轮判断，暂无新的可展示进展。”
+10. final=true 时，用完成态语气，说明思考已经收拢到下一步答复或动作。`)
 }
 
 // ReasoningSummaryDetailRuneLimit 返回 detail_summary 的最大字数。

frontend/src/api/schedule_agent.ts

@@ -106,6 +106,7 @@ export interface TimelineEvent {
   role?: 'user' | 'assistant'
   content?: string
   payload?: {
+    /** @deprecated 仅供 Debug 页 mock 路径与 legacy 后端兼容；生产页已切换至 thinking_summary 协议。 */
     reasoning_content?: string
     stage?: string
     block_id?: string