Version: 0.9.25.dev.260417

后端：
1. AIHub 模型分级从 Worker/Strategist 两级重构为 Lite/Pro/Max 三级
- AIHub 结构体从 Worker + Strategist 改为 Lite + Pro + Max，分别对应轻量（标题生成）、标准（Chat 路由/闲聊/交付总结）、高能力（Plan 规划/Execute ReAct）三个能力层级
- config.example.yaml 新增 liteModel / proModel / maxModel 三个模型配置项，替代原 workerModel / strategistModel
- 启动层 InitEino 改为创建三个独立模型实例，抽取公共 baseURL 和 apiKey 减少重复
- pickChatModel 统一返回 Pro 模型，旧 strategist 参数不再生效；pickTitleModel 从 Worker 切到 Lite
- runNewAgentGraph 按 Plan/Execute→Max、Chat/Deliver→Pro 分级注入；Graph 出错回退也切到 Pro
- Memory 模块初始化从 Worker 改为 Pro
2. Plan 节点从"两阶段评估"简化为"单轮深度规划"，thinking 开关改为全配置化
- 移除 Phase 1（快速评估 1600 token）+ Phase 2（深度规划 3200 token）的两轮调用逻辑，改为单轮不限 token 深度规划
- PlanDecision 移除 need_thinking 字段，prompt 规则和 JSON contract 同步删除该字段
- 各节点（Plan / Execute / Deliver）thinking 开关从硬编码改为从 AgentGraphDeps 读取，由 config.yaml 的 agent.thinking 段按节点注入
- 新增 agent.thinking 配置段（plan / execute / deliver / memory 四个独立布尔开关），config.example.yaml 补齐默认值
- 新增 resolveThinkingMode 公共函数，plan / execute / deliver 和 memory 决策/抽取链路统一使用
3. Memory 模块 LLM 调用支持 thinking 开关
- Config 新增 LLMThinking 字段，config_loader 从 agent.thinking.memory 读取
- LLMDecisionOrchestrator.Compare 和 LLMWriteOrchestrator.ExtractFacts 的 thinking 模式从硬编码 Disabled 改为读取配置
前端：
1. 移除助手输入区模型选择器及全部偏好持久化逻辑
- 删除 ModelType 类型、selectedModel ref、MODEL_PREFERENCE_STORAGE_KEY 常量
- 删除 isModelType / loadModelPreferenceMap / persistModelPreferenceMap / savePreferredModel / resolvePreferredModel / applyPreferredModelForConversation 六个函数及 modelPreferenceMap ref
- 删除 selectedModel watch 监听、发送消息时的 savePreferredModel 调用、切会话时的 applyPreferredModelForConversation 调用、会话迁移时的模型偏好迁移
- fetchChatStream 的 model 参数硬编码为 'worker'
- 删除模板中"模型"下拉选择器（标准/策略）及对应的全局样式 .assistant-model-select-panel
2. 上下文窗口指示器简化为仅显示总占用
- ContextWindowMeter 移除 msg0~msg3 四段彩色分段逻辑（ContextSegment 接口、segments computed、v-for 渲染）
- 进度条改为单一蓝色条，按 total/budget 比例填充；超预算时变红
- Tooltip 简化为仅显示"总计 X / 预算 Y（Z%）"

仓库：无

backend/newAgent/prompt/plan.go

@@ -21,8 +21,7 @@ const planSystemPrompt = `
 5. plan_steps 必须使用自然语言，便于后端将完整 plan 重新注入到后续上下文顶部。
 6. 只输出 JSON，不要输出 markdown，不要输出额外解释，不要在 JSON 外再补文字。
 7. 每次输出前先评估任务复杂度：simple（简单明确，无复杂依赖）、moderate（多步操作，需要一定推理）、complex（需要深度推理、多方案比较或复杂依赖关系）。
-8. 根据复杂度判断 need_thinking：你是否需要深度思考才能生成高质量计划？当不确定时倾向于 false。
-9. 粗排识别规则：若满足以下两个条件，在 action=plan_done 时附加 needs_rough_build=true 和 task_class_ids：
+8. 粗排识别规则：若满足以下两个条件，在 action=plan_done 时附加 needs_rough_build=true 和 task_class_ids：
    条件1：用户输入中存在"任务类 ID"字段（见上下文"任务类 ID"部分）；
    条件2：用户意图明确是"批量安排/帮我排课/把任务类排进日程"等批量调度需求。
    满足时：后端会在用户确认计划后自动运行粗排算法（硬性约束已由算法保证，无需 LLM 校验）。
@@ -99,7 +98,6 @@ func BuildPlanDecisionContractText() string {
 - action：只能是 %s / %s / %s
 - reason：给后端和日志看的简短说明
 - complexity：任务复杂度，只能是 simple / moderate / complex
-- need_thinking：是否需要深度思考才能生成高质量计划，只能是 true / false
 - plan_steps：仅当 action=%s 时允许返回；返回时必须是完整计划，不是增量
 - plan_steps[].content：步骤正文，必填
 - plan_steps[].done_when：可选，建议写"什么情况下算这一步做完"
@@ -112,7 +110,6 @@ func BuildPlanDecisionContractText() string {
   "action": "%s",
   "reason": "当前信息已足够继续规划",
   "complexity": "moderate",
-  "need_thinking": false
 }
 
 {
@@ -120,7 +117,6 @@ func BuildPlanDecisionContractText() string {
   "action": "%s",
   "reason": "当前时间范围仍不明确",
   "complexity": "simple",
-  "need_thinking": false
 }
 
 {
@@ -128,7 +124,7 @@ func BuildPlanDecisionContractText() string {
   "action": "%s",
   "reason": "当前计划已具备执行条件",
   "complexity": "simple",
-  "need_thinking": false,
+  
   "plan_steps": [
     {
       "content": "先确认本周可用时间范围",