将 Claude-Mem 集成到 Trae：我失败了但总结了这些坑

将 Claude-Mem 集成到 Trae我失败了但总结了这些坑背景我在 Claude CLI 中使用 claude-mem 体验非常好希望能在 Trae 中实现同样的长期记忆功能。这个目标驱使我深入研究了 Claude-Mem 源码和 Trae 的扩展机制最终发现两者之间存在一个根本性的架构差异。一、目标像 Cursor/Codex 一样集成 TraeClaude-Mem 已经在官方支持 Claude CLI 的基础上额外支持了 Cursor 和 Codex 两个平台。我的目标很明确让 claude-mem 也能认识Trae将其处理范围扩大到 Trae IDE。初步方案是做一个 MCP 桥接器Trae ↔ MCP Bridge ↔ Claude-Mem Worker让 Trae 的生命周期事件自动流入 claude-mem数据存储和查询复用 claude-mem 原生能力二、Claude-Mem 的架构解析为了搞清楚集成方式我深度阅读了 claude-mem v12.1.0 的全部核心源码包括2.1 三层架构┌─────────────────────────────────────────┐ │ hooks.json (Claude CLI 调用层) │ ← 每次事件触发一次 │ ↓ node bun-runner.js │ │ bun-runner.js (Bun 启动器) │ ← 找 Bun、缓冲 stdin │ ↓ spawn(inner worker) │ │ worker-wrapper.cjs (生命周期包装器) │ ← IPC 消息、进程树管理 │ ↓ spawn │ │ worker-service.cjs (实际服务) │ ← HTTP 服务器 :37777 └─────────────────────────────────────────┘2.2 Hooks 完整生命周期从 hooks.json 看Claude CLI 的每个操作都会触发对应 hooks顺序事件动作超时1Setup安装/检查依赖300s2SessionStart启动 Worker → 注入上下文60s3UserPromptSubmit初始化会话记录60s4PostToolUse记录工具执行观察120s5Stop生成会话摘要120s6SessionEnd标记会话完成30s2.3 窗口关闭时的行为关键发现当 Claude CLI 窗口关闭时Worker 进程不会关闭继续作为守护进程运行。Stop hook → 生成摘要SessionEnd hook → 标记完成Worker 继续监听 :37777 端口这就是为什么 claude-mem 可以即开即用——Worker 是全局常驻的。三、MCP 协议的硬性限制3.1 MCP 协议规范MCP (Model Context Protocol) 协议本身不定义任何 session-level lifecycle event。其生命周期只有三层Initialization → Operation → Shutdown仅支持的能力initialize/notifications/initializedtools/list/tools/calllogging/ping3.2 Trae 的 MCP 实现根据 Trae 官方文档Trae 支持的 MCP 功能同样只有Tools工具调用Resources资源Prompts提示模板Logging日志没有任何生命周期事件的自动触发机制。四、Trae vs Claude CLI关键差异能力TraeClaude CodeHooks确定性自动化❌ 没有✅ 有project_rules.md提示词级规则✅ 有✅ 有Agent 自定义 system prompt✅ 有✅ 有MCP Tools✅ 原生支持✅ 原生支持Trae 官方文档明确指出hooks 是 Claude Code 独有的模型循环之外的确定性自动化。Trae 没有等价物。五、我们做的桥接器尽管如此我们还是实现了一个功能性的 MCP 桥接器5.1 架构Trae IDE ↓ (手动/MCP tool 调用) trae_claude_mem_bridge (Python MCP Server) ↓ (HTTP API / subprocess hook) Claude-Mem Worker (:37777) ↓ SQLite 数据库 ChromaDB5.2 实现的功能✅trae_mem_hook_event— 接收事件并转发✅ 内部消息过滤过滤task-notification等✅ SKIP_TOOLS 客户端过滤✅summarize/session-complete走 HTTP API✅ 平台标识platformtrae✅ Worker 自动检测与启动5.3 日志中的证据桥接器确实被调用过2026-04-16 17:49:40 | ERROR | Hook error (UserPromptSubmit/session-init): Worker hook timeout after 30s这说明事件确实流入了桥接器但当时 Worker 没有启动Trae 的 AI 确实自发调用了我们的 MCP tool六、替代方案的探索6.1 方案 Aproject_rules.md 注入# .trae/rules/project_rules.md ## Claude-Mem 记忆集成 你已集成 claude-mem 长期记忆系统。你必须在以下时机调用 trae_mem_hook_event 工具 1. 收到用户消息时 → event: UserPromptSubmit 2. 使用任何工具后 → event: PostToolUse 3. 会话结束时 → event: Stop SessionEnd 这是硬性要求不是可选操作。优点对项目内所有对话生效缺点“提示词层面期望”非 100% 可靠估计约 80%6.2 方案 B专用 Agent# .trae/agents/claude-mem-coder.md --- name: claude-mem-coder tools: trae-mem-bridge --- 你是带 claude-mem 记忆增强的开发者。每个操作周期必须 1. 接收用户输入 → 调用 trae_mem_hook_event(UserPromptSubmit) 2. 执行工具 → 调用 trae_mem_hook_event(PostToolUse) 3. 完成任务前 → 调用 trae_mem_hook_event(Stop) (SessionEnd)优点更强的约束独立 system prompt缺点需要用户手动切换 Agent七、最终结论7.1 为什么无法实现 100% 自动化Claude CLI hooks: 确定性调用 (hooks 运行在模型循环之外) Trae Rules: 概率性遵守 (Rules 只是提示词AI 可能忽略)这是架构层面的本质差异不是实现细节问题。7.2 现在的状态如果接受约 80% 的可靠性 → 可以通过project_rules.md实现如果要求 100% 确定性 → 目前无法实现需要等待 Trae 提供 hooks 或等价机制7.3 这个探索的价值虽然最终未能实现最初的目标但这个过程非常有价值深度理解了 Claude-Mem 的架构三层设计、Worker 守护进程、hooks 生命周期完整掌握了 Trae 的扩展体系Rules、Agents、MCP、Skills 的完整生态明确了 MCP 协议的边界它只是工具调用协议不是应用生命周期协议八、写给同样想尝试的人如果你也有类似的想法希望你能从我的探索中受益先读源码再动手— Claude-Mem 的源码其实很清晰花一天读完能省很多弯路区分协议层和实现层— MCP 协议不支持的东西任何 MCP Server 都无法实现Trae 的 Rules 不是 Hooks— 提示词层面的规则AI 可能遵守也可能不遵守关注 Trae 的更新— 他们可能在未来加入 hooks 或等价机制相关项目: Trae-Claude-Mem-Bridge — 桥接器源码如果你最终选择了 project_rules.md 方案并成功实践欢迎分享经验。这个方向目前还没有人探索过。写于 2026-04-16基于 TraeClaudeMemBridge v6 探索项目