Google Jules 11月11日转只读前怎么迁移？2026

最后更新于 2026 年 11 月 5 日；截止日期、导出范围和操作说明核实自 Jules 官方迁移公告。官方给出的关键节点是 2026 年 11 月 11 日转为只读，服务计划于 2026 年 12 月 31 日结束。结论很明确：立即导出 Google Jules 的配置与历史，在只读前完成仍需交互的会话；不要把 GitHub 上已有代码等同于 Jules 配置和工作流已经迁走。

这篇适合需要保留个人设置、环境变量和未完成会话的独立开发者。
依赖定时任务或共享仓库的团队，可据此安排权限复核与替代流程验收。
负责 CI 或平台工程的人员，还应特别检查 macOS 专属构建步骤的接续方式。

先看时间线：只读日与服务结束日不是一回事

Jules 会话可继续完成至 11 月 11 日；过了这一天，服务进入只读阶段，计划在 12 月 31 日结束。公告没有给出具体截止时刻或时区，因此不宜把最后一天的某个本地时间当作可靠缓冲。迁移安排应按“11 月 11 日前完成交互、之后只读期间核对资料、服务结束前确认长期归档”的顺序推进。

迁移时最容易混淆的是代码与服务内资料：已经存入 GitHub 的代码、分支和 Pull Request 不在 Jules 导出范围内；设置、环境变量、定时任务、连接仓库、记忆、设置脚本和会话记录则需要通过导出另行保存。换句话说，GitHub 保存了代码，不代表新 Agent 已经知道项目怎么启动、怎样测试，也不代表旧会话的任务背景还在。

表格里的分工依据是官方公告列出的导出范围；最后一列是据此推导出的迁移风险，并非官方承诺导出可直接导入其他 Agent。

截止前：先交接未完成会话，再冻结变更

把需要 Jules 继续处理的任务单独列出来，优先级按截止要求和依赖程度排列：有交付日期的任务先处理；必须等待 Jules 进一步计划、修改或回答的任务，明确由谁接手；已经完成并进入 GitHub 的任务，则转为常规代码审查。对于定时任务，也要记录触发条件、目标仓库和预期结果，不能只记一个任务名称。

一个典型情况是：定时编码任务已生成修改，但还没有完成项目测试或人工审核。此时应把仓库和分支、预期产物、验证命令、当前状态、审查责任人写入交接记录；如果补丁只在会话里，先确认如何保存并验证，再决定是否提交。不要把“会话还在列表中”当成可恢复保证，也不要把会话结束误记为任务已验收。

在转只读前，至少完成这些可执行事项：

• [ ] 列出仍运行、待审核或依赖后续交互的会话，并指定接手人。
• [ ] 对照 GitHub 检查代码、分支、PR 和未提交修改。
• [ ] 为每项未完成任务记录目标、验收命令及人工审查责任。
• [ ] 暂停或重新安排依赖 Jules 的定时编码工作流。
• [ ] 为导出资料指定保管位置和访问责任人。

导出前后：Jules Tools 负责准备，导出结果要自己核验

官方流程不是简单执行一个名为“导出”的 CLI 命令。公告要求先安装并登录 Jules Tools，核对连接的 GitHub 仓库，再使用公告提供的导出提示词，让命令行编码 Agent 执行导出流程。安装与登录命令可在 Jules Tools CLI 参考文档核对；流程还会检查 jules remote list --repo，用它确认仓库连接状态。

可按下面的顺序操作：

1. 在受控的开发终端执行 npm install -g @google/jules，再运行 jules login 完成浏览器登录。安装命令和登录方式见上方官方 CLI 文档。
2. 执行 jules remote list --repo，核对需要导出的仓库是否已连接。如果返回认证错误，先处理 Jules 与 GitHub 的连接问题，再继续；没有使用过 GitHub 仓库的账户，导出中可能没有仓库资料。
3. 从官方迁移公告复制导出提示词，按其步骤让 Agent 检查登录状态并执行导出。由于公告提到部分调用使用未公开的内部接口，执行前应审阅生成的脚本和网络访问范围；不要自行猜测接口或在脚本输出中打印令牌。
4. 官方说明导出结果位于 ~/jules-export。检查 sources.json、仓库资料目录、设置和任务 JSON，以及按会话保存的摘要、活动记录和补丁；同时记录脚本报告的数量与错误信息。
5. 抽查资料是否完整，重点确认仓库连接、设置脚本、测试命令、记忆、定时任务和会话补丁都符合预期。导出文件存在，只能证明文件写出，不能证明另一款 Agent 已经能使用这些信息。

注意：官方公告指出 env-variables.json 含环境变量值。应限制导出目录的访问权限，不要把它提交进仓库，也不要把令牌或秘密值粘贴到工单、日志或公开的 Agent 提示中。团队可按已有的秘密管理规则重新存放所需凭据；GitHub Actions 秘密管理说明也介绍了仓库、环境和组织级秘密及其访问范围。

Google Jules 迁移：导出不等于替代工作流已经接通

Google Antigravity 是 Google 提及的智能编码平台，但 Jules 的迁移公告没有确认会自动导入 Jules 数据，也没有承诺设置、定时任务、记忆或会话历史逐项等价。应先把它作为一个可评估的候选方案，再按项目需要重建；Google Antigravity 官方产品介绍只能说明其产品定位，不能作为 Jules 数据自动迁移的证明。

另一项边界是执行环境。Jules 的环境文档说明任务运行在 Ubuntu 虚拟机；因此，普通跨平台代码任务可以先在替代 Agent 的实际环境中验证，而依赖 Xcode 的构建、模拟器或其他 macOS 工具链任务，需要单独安排 Mac 验收。具体的 Xcode 与 macOS 兼容关系，应按 Apple Xcode 系统要求核对，而不是从旧会话配置推断。

常见疑问：资料、自动接管与验收边界

Jules Tools 导出的资料放在哪里？
公告说明默认结果目录为 ~/jules-export，仓库索引、仓库级设置资料和会话记录分开存放。先核对导出脚本打印的路径、文件数量和错误，再抽查文件内容；不要仅凭终端显示“完成”就宣布交接成功。

GitHub 里的代码还要再从 Jules 导出吗？
已在 GitHub 的代码、分支和 PR 不属于 Jules 导出范围；应在 GitHub 侧检查它们是否齐全。会话补丁、未提交修改及任务上下文则要另外检查导出目录，并确认未完成的代码已被适当保存和审查。

Google Antigravity 会自动接管 Jules 任务吗？
截至公告内容，没有自动导入 Jules 配置或历史的确认。即使团队选择 Antigravity，也需要重新验证仓库权限、提示约束、测试执行和人工审核环节；迁移结论应以官方后续公告和真实任务验收为准。

替代流程验收：用真实仓库任务证明接续有效

从常见任务中挑一个可重复样本，例如依照明确要求补充测试并修改一个小范围代码。先写出任务输入、目标分支、依赖安装步骤、权限边界、测试命令和审查标准，再让替代 Agent 从干净工作区执行；这样才能分辨问题出在提示、环境、权限还是测试流程，而不是把所有失败归为“模型不行”。

验收不要只看 Agent 生成了代码。至少检查修改是否落在预期文件、项目测试与静态检查是否通过、日志是否暴露秘密、PR 是否由指定人员审查；如果通过自托管 Runner 执行，还要确认 Runner 主机在线并能访问 GitHub。GitHub 文档说明，自托管 Runner 由使用方部署和维护，工作流还依赖主机保持运行及网络连通，因此“任务可触发”并不等于运维责任已消失。

若验收涉及 Xcode，先确认目标 Xcode 版本对应的 macOS 系统要求，再在实际 Mac 环境运行构建和测试。不是每个编码 Agent 都必须迁到 Mac：只有任务确实依赖 macOS 工具链时，才需要把这部分加入接续方案。若团队正评估自购、远程环境或其他托管方式，可先比较不同 Mac 使用方案的取舍，并结合秘密资料的保管要求检查数据隐私与访问安排。

只读之后：归档、责任人与 Mac 环节的适用条件

进入只读阶段后，继续核对导出档案、GitHub 仓库和替代工作流是否由明确责任人维护；将自动任务、权限配置、未完成任务及尚未重建的会话背景登记在团队文档里。官方公告确认服务计划于 2026 年 12 月 31 日结束；如果 Google 后续调整日期或公布明确导入能力，应以新的官方信息复核迁移计划。

替代方案也要按任务边界选择：Linux 环境适合不依赖 macOS 的工作，但不能替代 Xcode 工具链；本地 Mac 能提供直接控制，却需要团队承担采购、维护和持续在线的安排；远程 Mac 则适合短期接续必须在 macOS 上构建或测试的任务，并非所有 Agent 迁移都需要。若迁移验收确认只在特定构建步骤需要 Mac，租用 xcoderent 的 Mac 环境可避免为了短期验证先购置实机；若负载长期稳定、要求持续重载运行或必须连接特定物理设备，应先评估自购或自有设备方案。最后的判断标准不是换了哪个 Agent，而是导出资料受控、仓库任务可复现、测试与人工审查责任都已通过实际验收。

常见问题