270 lines
19 KiB
Markdown
270 lines
19 KiB
Markdown
---
|
||
🔴 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的记忆能力写测试用例并验证 |