---
  🔴 P0 — 对话自动压缩 (Tiered Auto-Compaction)

  这个没做，豆包Pro 永远成不了真正好用的聊天助手。

  Claude Code 有一个三级压缩体系：

  ┌───────────────────────┬───────────────────────┬─────────────────────────────────────────────────────────────────┬────────────────────────────────┐
  │         级别          │       触发条件        │                              机制                               │              效果              │
  ├───────────────────────┼───────────────────────┼─────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ MicroCompact          │ 每次对话前            │ 把旧工具结果（read/grep/search）替换为 [Old content cleared] 桩 │ 回收 30-50% token 不丢对话质量 │
  ├───────────────────────┼───────────────────────┼─────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ SessionMemory Compact │ 距窗口上限 ~13K token │ 将旧对话总结为记忆条目注入系统提示词                            │ 进一步压缩                     │
  ├───────────────────────┼───────────────────────┼─────────────────────────────────────────────────────────────────┼────────────────────────────────┤
  │ Full Compact          │ 以上都失败            │ 分叉一个新 Agent 对整个对话做摘要，替换旧消息                   │ 最终兜底                       │
  └───────────────────────┴───────────────────────┴─────────────────────────────────────────────────────────────────┴────────────────────────────────┘

  关键设计：
  - reactiveCompact.ts — 捕捉 API 返回 413 prompt_too_long 后被动触发压缩
  - 熔断机制：连续压缩失败 3 次就停止，避免死循环
  - 分组 (grouping.ts) — 按 API 轮次找安全分割点，不切断中间的 tool call 序列

  对应豆包Pro：当前 memory_max_history=35 条消息硬截断，没有压缩机制。对话超过 35 轮就"失忆"。实现后对话可以无限延续。

  ---
  🟡 P1 — 对话分支 (Conversation Branching)

  Claude Code 支持用户在任意时刻分叉对话：

  当前对话 ──→ 分叉到新会话 ──→ 在新分支探索
      │                              │
      └── 原会话保留，随时可恢复 ←───┘

  机制：复制 transcript 文件到新 UUID，保留 forkedFrom 溯源，自动命名防冲突（"话题 (Branch)", "话题 (Branch 2)"）。

  对应豆包Pro：用户说 "你给的方案A不错，但我还想看看方案B"，可以分叉两条路同时探索，不丢失任何一边的上下文。这是真豆包都没有的能力。

  ---
  🟡 P1 — 工具结果流式美化 (Streamlined Output)

  Claude Code 不会把原始工具 JSON 输出给用户看，而是做实时转译：

  // 原始：3个 Grep 结果 + 2个 FileRead 结果（几百行 JSON）
  // 转译后："Searched 3 patterns, read 2 files, wrote 1 file."

  // 原始：{"stdout": "...", "stderr": "", "returncode": 0}
  // 转译后："Code executed successfully → result: [1, 1, 2, 3, 6, 8, 10]"

  核心文件：streamlinedTransform.ts、groupToolUses.ts、collapseReadSearch.ts

  对应豆包Pro：当前工具调用过程以 JSON steps 返回，前端需要自己做美化。实现后用户看到的是自然语言描述而不是原始数据。

  ---
  🟡 P2 — 系统提示词分层装配

  Claude Code 的系统提示词不是一整块，而是 15+ 个可组合 Section：

  ┌─────────────────────────┐
  │  Cacheable (静态前缀)    │  ← 可被 API prompt cache 命中
  │  ├─ session_guidance    │
  │  ├─ memory              │
  │  ├─ model_override      │
  │  ├─ language            │
  │  ├─ output_style        │
  ├─────────────────────────┤  ← static/dynamic boundary
  │  Volatile (动态后缀)     │  ← 每轮重新计算
  │  ├─ tool_summaries      │
  │  ├─ token_budget        │
  │  ├─ mcp_instructions    │
  │  └─ scratchpad          │
  └─────────────────────────┘

  每个 Section 用 Promise.all 并行加载，支持 feature flag 控制显隐。

  对应豆包Pro：当前 system_prompt 是一个大字符串。改为分层后：
  - 静态层（人格+能力描述）→ 缓存，不消耗每次 API 调用的 token
  - 动态层（当前记忆+上下文摘要）→ 每轮重新注入
  - 按场景切换：闲聊模式精简 tools 描述，代码模式强化工具指令

  ---
  🟢 P2 — Token 预算管理

  Claude Code 有完整的 token 追踪链路：

  当前 token 用量 / 模型窗口上限 / 剩余空间 / 预警阈值
       ↓ 接近上限
    自动触发压缩
       ↓ 还是不够
    提示用户 /compact

  用户甚至可以输入 +500k 手动调整预算上限。

  对应豆包Pro：当前完全没有 token 计数，对话可能被静默截断。加入后可以在 UI 上显示用量条，接近上限时主动提醒或自动压缩。

  ---
  🟢 P3 — Agent 蜂群 (Swarms)

  Claude Code 支持一个 Leader Agent 拉多个 Teammate 并行工作：

  用户: "帮我做旅行计划、订机票、找酒店"
           │
      Leader Agent
      ┌────┼────┐
      ▼    ▼    ▼
    规划  机票  酒店    ← 三个 Agent 并行，通过 mailbox 通信

  对应豆包Pro：复杂查询可以拆成子任务并行处理，大幅缩短响应时间。

  ---
  总结：实施路线

           P0             P1              P2              P3
        对话压缩      分支+流美化      提示词装配       Swarms
                                                          Token预算
      ───●──────────────●────────────────●────────────────●──→
      本周                                          下周

  ┌──────┬────────────────────────────────────────┬─────────────────────────┐
  │ 阶段 │                 做什么                 │       豆包Pro提升       │
  ├──────┼────────────────────────────────────────┼─────────────────────────┤
  │ 先做 │ 对话压缩 (microCompact + full compact) │        73% → 78%        │
  ├──────┼────────────────────────────────────────┼─────────────────────────┤
  │ 接着 │ 工具结果流式美化                       │      用户体验质变       │
  ├──────┼────────────────────────────────────────┼─────────────────────────┤
  │ 然后 │ 系统提示词分层装配                     │ API 成本降 30%, 灵活性↑ │
  ├──────┼────────────────────────────────────────┼─────────────────────────┤
  │ 再后 │ Token 预算 + 对话分支                  │        79% → 82%        │
  ├──────┼────────────────────────────────────────┼─────────────────────────┤
  │ 远期 │ Agent Swarms 并行                      │     复杂任务快 3 倍     │
  └──────┴────────────────────────────────────────┴─────────────────────────┘

  最紧急的是对话压缩 — 没有它，豆包 Pro 永远停留在"能聊 35 轮"。有了它，才是真正可用的聊天助手。



D:\cd\claude-code 项目拥有
向量语义记忆 (相似对话检索) │ SiliconFlow Embedding   吗？
那么D:\cd\claude-code的记忆水平怎么样？






根据之前的分析，从 Claude Code 可借鉴的功能还有这些未实现：

  ┌────────┬─────────────────────────────────────────┬──────────────────────────────────────────────┐
  │ 优先级 │                  功能                   │                     说明                     │
  ├────────┼─────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ P1     │ 对话分支 (Conversation Branching)       │ 用户可回退到任意历史点重新开始，不丢失原对话 │
  ├────────┼─────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ P1     │ 精简输出 (Streamlined Output)           │ 工具结果智能截断，避免上下文膨胀             │
  ├────────┼─────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ P2     │ 系统提示词分段 (System Prompt Sections) │ 结构化提示词，动态注入/移除特定段            │
  ├────────┼─────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ P2     │ Token 预算显示                          │ 前端实时显示 token 用量和压缩状态            │
  ├────────┼─────────────────────────────────────────┼──────────────────────────────────────────────┤
  │ P3     │ Agent 集群 (Agent Swarms)               │ 多个 Agent 并行协作，投票/分工               │
  └────────┴─────────────────────────────────────────┴──────────────────────────────────────────────┘

  另外还有一些可做的优化：
  - 安装 tiktoken：目前 cl100k_base 编码器已能加载，但未作为正式依赖写入 requirements
  - 端到端长对话压力测试：50+ 轮连续对话验证压缩不丢上下文


















取决于场景。 没有绝对的好坏。

  ---
  核心取舍

  ┌──────────┬─────────────────────────────────────┬──────────────────────────┐
  │          │       Claude Code (LLM 分类)        │     天工 (向量搜索)      │
  ├──────────┼─────────────────────────────────────┼──────────────────────────┤
  │ 检索精度 │         高（LLM 理解语义）          │ 中（余弦相似度，可能漏） │
  ├──────────┼─────────────────────────────────────┼──────────────────────────┤
  │ 检索成本 │         每次 1 次 LLM 调用          │         几乎免费         │
  ├──────────┼─────────────────────────────────────┼──────────────────────────┤
  │ 检索速度 │          慢（等 LLM 响应）          │       快（毫秒级）       │
  ├──────────┼─────────────────────────────────────┼──────────────────────────┤
  │ 规模上限 │ ~200 条记忆（受 manifest 长度限制） │          百万级          │
  ├──────────┼─────────────────────────────────────┼──────────────────────────┤
  │ 外部依赖 │                 零                  │  Embedding API（脆弱）   │
  ├──────────┼─────────────────────────────────────┼──────────────────────────┤
  │ 离线可用 │                 是                  │            否            │
  └──────────┴─────────────────────────────────────┴──────────────────────────┘

  ---
  说实话

  Claude Code 的方案更适合 Claude Code 自己 — 它是一个单用户 CLI 工具，记忆量不大，每次检索顺便调一下 Sonnet 无所谓。

  向量搜索更适合天工 — 你有 6 个飞书机器人、多个用户、记忆会持续增长。用 LLM 做分类器扛不住 1000+ 条记忆，向量搜索轻松应对。

  ---
  所以

  天工平台的方案选择是对的（向量语义记忆），问题只是 SiliconFlow 实名认证没做完。认证通过后 Embedding 服务恢复，这个架构就完整了。

  Claude Code 不依赖 embedding 这点值得借鉴 — 但不是用它替代向量搜索，而是学它的 后台记忆自动提取（Extract Memories / Auto Dream），这个天工目前没有。






SiliconFlow Embedding 已恢复

  BAAI/bge-m3 模型正常工作，1024 维向量生成成功。向量语义记忆现在可以写入新消息了。

  改动总结： .env 第 21 行，模型从 netease-youdao/bce-embedding-base_v1（已下线）→ BAAI/bge-m3（8192 token 上限，中英多语言）。

  ---
  Claude Code 还有哪些可借鉴的改进？

  从刚才的研究对比，天工可以借鉴的 3 个低成本高价值改进：

  1. 后台自动记忆提取（最重要）

  Claude Code 每轮对话结束后，fork 一个子 Agent 扫描对话，自动提炼关键信息写入持久记忆。

  天工现在：对话结束 → 消息存 DB → 等下次手动调用 generate_embedding
  Claude Code：对话结束 → 子 Agent 读对话 → 提取事实 → 写 MEMORY.md

  天工可以实现： 每次 Agent 对话完成后，异步调 LLM 做一次"对话摘要 → 提取关键事实 → 写入持久记忆"。不需要 embedding，纯 LLM 调用。

  2. 夜间记忆整合（Auto Dream）

  每隔 24 小时 + 累计 5 次以上新会话，自动合并记忆、去重、更新过期信息。

  天工可以实现： 在现有 run_scheduler_loop() 里加一个每日任务，凌晨 3 点扫描当天向量记忆，merge 相似条目、删除矛盾旧条目。

  3. 记忆分类体系

  Claude Code 的 4 类记忆（user / feedback / project / reference）让检索更精准：

  ┌───────────┬──────────────────────┐
  │   类型    │       天工对应       │
  ├───────────┼──────────────────────┤
  │ user      │ 用户偏好、个人信息   │
  ├───────────┼──────────────────────┤
  │ feedback  │ 用户反馈、纠错记录   │
  ├───────────┼──────────────────────┤
  │ project   │ 项目上下文、任务进展 │
  ├───────────┼──────────────────────┤
  │ reference │ 外部系统链接、配置   │
  └───────────┴──────────────────────┘

  天工可以实现： 在 VectorEntry 的 metadata 里加 memory_type 字段，写入和检索时按类型过滤，减少噪音。

  ---
  要我实现其中哪一个？推荐先做 #1 后台自动记忆提取，改动最小，效果最明显。


给天工agent的记忆能力写测试用例并验证