Jeeves 为 Claude Code 自动交接长任务

Claude Code 做长任务时，上下文逐渐塞满，开发者常得暂停工作、整理交接说明，再用 /clear 开新会话。作者为此做了插件 Jeeves：默认在上下文用到 40% 时，让 Claude 写交接、核对事实，再把原始任务交给新会话继续执行。

它最有价值的地方，是把交接变成一道可检查的流程。不过，原文没有提供效率或正确率的对照数据，自动清理会话的能力也依赖可能变化的插件接口。

新会话接棒，比 /compact 多做了什么

/compact 会压缩当前对话，然后继续使用同一会话。Jeeves 则启动新会话，并逐字带上用户最初的任务，再补充经过检查的交接说明和下一步。

保留原始任务很关键。连续压缩时，需求中的约束可能被摘要省略；原始提示词重新进入上下文，能给后续执行保留一份稳定参照。但这不保证新会话一定理解正确，阶段性发现仍要靠交接说明传递。

Jeeves 试图把长任务拆成多次有记录、可核对的接力。

默认到达 40% 后，它会等 Claude 停下来、没有操作仍在运行，再索要当前进展、下一步和计划完成情况。校验通过后，保存交接及任务开始以来的提交记录，执行 /clear，继续工作。

40% 是默认交接点，不是作者通过对照实验验证的最佳值。原文只解释了设计意图：通常在自动压缩触发之前，提前准备交接。

交接说明不能只靠模型自证

作者最在意的是交接校验。模型写出「已经验证」很容易，Jeeves 会进一步检查：

• 格式、标识符和大小是否合法。
• 分支与 HEAD 是否和 git 一致。
• 被列为已验证的文件是否存在。
• 被宣称通过的命令，最近一次运行是否失败。
• 内容是否命中已识别的秘密信息模式。

失败后，Jeeves 会把原因交回 Claude 修正。总共允许三次尝试，即首次加两次重试；仍未通过就停下来询问用户，可用 /jeeves retry 重新启动。

这些检查能拦住部分虚假进展，却不能证明代码逻辑正确。文件存在，不代表实现满足需求；命令最近没失败，也不等于它覆盖了所有问题。秘密模式检查同样只覆盖它能识别的内容。

下面这条命令用于指定任务完成前必须通过的检查：

/jeeves check npm test

要看清最后的 npm test：实际执行者仍是 Claude，Jeeves 负责核对结果。它不会替用户运行命令、修改 git 或回答权限提示，也承诺不会在没有证据时把任务标为完成。

装上就能用，但自动接力有条件

原文介绍的是 public beta 0.3.1，采用 MIT 许可，支持 macOS，要求 Claude Code 2.1.319+，可在任意终端使用，包括 Cursor 和 VS Code 的内置终端。它不是 Anthropic 官方产品，也与 Anthropic 无关联。

从 shell 安装使用这条命令：

claude plugin install jeeves --marketplace nickycdk/jeeves

注意 --marketplace nickycdk/jeeves 指向第三方市场；原文也给了会话内安装方式 /plugin install jeeves --marketplace nickycdk/jeeves。第三方市场不会自行更新，新版本需要执行 claude plugin update jeeves@jeeves。

只有同时满足 git 仓库、200K+ 上下文窗口和新会话三个条件，Jeeves 才会自动启动。其他情况，包括恢复的会话，需要先输入 /jeeves on。不带目标时，它会把下一条提示词逐字保存为任务；也可以使用 /jeeves on [goal] 直接指定目标。

状态栏类似 Jeeves 12%/40%，分别表示当前使用量和交接点。/jeeves status 可以检查状态，/jeeves handover 可以查看最近的交接文件。

阈值可设为 20 到 90，默认 40。例如 /jeeves threshold 60 调整当前任务，/jeeves defaults threshold 35 设置项目默认值。原文还提供 /jeeves limit 50 和 /jeeves defaults limit 80，说明 limit 范围为 1 到 100、默认 30，却没有解释它具体限制什么，不能自行理解为 token 或费用上限。

数据保存在仓库外的本地目录，包括任务提示词、交接、git 事实，以及脱敏后的命令和编辑文件名日志，不复制完整对话或文件内容。自动启动且从未交接的任务在 7 天后删除，全部清理使用 /jeeves purge --all。

我的判断

我认可「交接前核对事实」这个方向。相比直接 /compact，它提供了可阅读的交接文件、原始任务和命令记录，出了问题更容易追查。但作者没有给出任务成功率、耗时或 token 消耗的对照，减少照看成本目前仍属于作者的经验之谈。

交接校验能提高过程可信度，不能替代测试和需求验收。

使用前还得接受两个前提。第一，每次交接会额外占用一个 Claude 回合，Jeeves 自身不调用模型，也不发网络请求；这不代表整个 Claude Code 工作过程离线。第二，插件调用 /clear 虽在 2.1.319 可用，也存在于带类型的插件 API 中，但尚未被文档列为受支持用法。

接口变化时，它会退到辅助模式：保留已验证的交接，让用户手动执行 /clear，再运行 /jeeves continue。另外，Linux 未经作者测试，Claude Team 账户使用受限的回合模式，原文没有展开具体限制。

能拿来做什么

• 对跨多个文件的前端或 Node 长任务，可以先试用默认阈值，并在第一次交接后运行 /jeeves handover，检查它是否保留了需求约束、未完成项和验证结果。
• 把项目已有的有效测试设为完成条件，例如 /jeeves check npm test，同时确认测试确实覆盖此次改动。
• 在适合切换的阶段用 /jeeves rotate 请求交接；暂时需要连续推进时用 /jeeves pause，之后再用 /jeeves resume 恢复。
• 会话崩溃或关闭后，可用 /jeeves recover 接回任务，并先核对保存的交接与当前代码状态。