Beads已死,Linear CLI长存
不到一个月前,我写了篇完整文章介绍如何在Claude Code中使用三层记忆系统:Linear负责战略、Beads负责战术、Tasks负责执行。构建了一个优雅的金字塔模型。 然而现实很骨感。 今天我正式退役Beads。这不是心血来潮,而是因为这个工具制造的麻烦已经超过了它解决的问题——它不再是工具,而是累赘。 Beads的初衷 对于没读过前文的读者,Beads是一个基于Git的issue跟踪器。作为Claude Code的插件,它将issues存储为代码库中的JSONL文件。理论上设计很精妙: Git持久化:issues保存在.beads/目录并与代码一起提交 依赖管理:支持issue间阻塞关系 离线工作:无需网络连接 LLM原生支持:直接读取文件,无需API配置 其核心价值是作为"本周计划"(Linear)和"当前任务"(Tasks)之间的战术衔接层。 故障始末 起初一切顺利,直到各种创意故障接踵而至。 恶魔守护进程 Beads依赖后台守护进程管理SQLite数据库并与Git同步。听起来合理?实际状况: 检测到数据库不匹配! 当前数据库属于其他代码库: 数据库记录库ID:d1f9ca0c 当前代码库ID:01eac8ea ⚠️ 严重警告:此错误可能导致同步时误删issues! 这个错误会在每次会话启动时出现。守护进程崩溃、同步失败,导致issues陷入量子态——既存在于本地SQLite又不存在于Git,反之亦然。 幽灵同步 bd sync本应同步Git远程仓库的issues,但经常失效: → 从远程拉取中... 错误:git pull执行失败:退出状态1 remote: 仓库不存在 fatal: 无法访问'https://git.frr.dev/frr/wuwei.git/' 当代码库配置多个remote时(这很常见),Beads可能选错远程仓库。若该仓库不存在或已更名,每次操作都会静默报错。最终issues停止同步,直到下次会话时数据全部消失才后知后觉。 认知损耗 每次Claude Code会话都这样开始: Claude读取Beads提示(通过hooks注入) 尝试启动守护进程 因数据库不匹配失败 Claude尝试bd sync 因远程仓库错误失败 你手动输入"忽略该错误" 终于可以开始工作 六个摩擦步骤消耗着上下文、时间和耐心。 局势转变 两件事让Beads从"带bug的实用工具"沦为"不必要的负担": 1. Tasks的成熟 当初设计三层架构时,Tasks功能简陋。现在已具备: 支持描述和元数据的TaskCreate 带依赖关系的TaskUpdate 查询功能TaskList/TaskGet 通过CLAUDE_CODE_TASK_LIST_ID实现跨会话持久化 简言之:Tasks现已实现Beads的所有会话内功能,且无需守护进程、SQLite或Git同步。 2. Linear CLI问世 原生的Linear管理控制台(MCP)往好了说也很糟糕——延迟高、稳定性差,总在关键时刻掉链子。 直接调用GraphQL API?理论上可行,直到你需要在issue描述中使用特殊字符: # 尝试1:使用bash字符串插值 # 结果:括号和箭头破坏JSON结构 # 尝试2:Python urllib方案 # 结果:因op read无法在Python环境执行报401错误 # 尝试3:默默流泪 # 结果:情绪宣泄但无实际产出 直到发现linear命令行工具: ...