19 KiB
🟡 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 个低成本高价值改进：
- 后台自动记忆提取（最重要）
Claude Code 每轮对话结束后，fork 一个子 Agent 扫描对话，自动提炼关键信息写入持久记忆。
天工现在：对话结束 → 消息存 DB → 等下次手动调用 generate_embedding Claude Code：对话结束 → 子 Agent 读对话 → 提取事实 → 写 MEMORY.md
天工可以实现： 每次 Agent 对话完成后，异步调 LLM 做一次"对话摘要 → 提取关键事实 → 写入持久记忆"。不需要 embedding，纯 LLM 调用。
- 夜间记忆整合（Auto Dream）
每隔 24 小时 + 累计 5 次以上新会话，自动合并记忆、去重、更新过期信息。
天工可以实现： 在现有 run_scheduler_loop() 里加一个每日任务，凌晨 3 点扫描当天向量记忆，merge 相似条目、删除矛盾旧条目。
- 记忆分类体系
Claude Code 的 4 类记忆（user / feedback / project / reference）让检索更精准：
┌───────────┬──────────────────────┐ │ 类型 │ 天工对应 │ ├───────────┼──────────────────────┤ │ user │ 用户偏好、个人信息 │ ├───────────┼──────────────────────┤ │ feedback │ 用户反馈、纠错记录 │ ├───────────┼──────────────────────┤ │ project │ 项目上下文、任务进展 │ ├───────────┼──────────────────────┤ │ reference │ 外部系统链接、配置 │ └───────────┴──────────────────────┘
天工可以实现： 在 VectorEntry 的 metadata 里加 memory_type 字段，写入和检索时按类型过滤，减少噪音。
要我实现其中哪一个？推荐先做 #1 后台自动记忆提取，改动最小，效果最明显。
给天工agent的记忆能力写测试用例并验证