Google Jules 停服指南：导出工作记录，迁移后台任务

Google Jules 停服时间表：哪些日期会影响工作？

Google 的后台编程智能体 Google Jules 将在 11 月 11 日之后转为只读，随后彻底停止服务。Google 发布的 Jules 停服公告日期为 2026 年 10 月 29 日。

公告没有说明具体截止时刻、时区、单独的 API 停用期限、许可到期时间、计费或退款日期，也没有公布服务关闭后的数据保留安排。这些问题仍待解答，不能从上表自行推断。

如果开发者手上还有没完成的修复，眼下要决定的是：继续在 Jules 中做完，还是把补丁和剩余需求带到新任务里。工程负责人则需要找出常规代码审查中容易被忽略的依赖：周期性提示词、环境配置步骤、仓库权限和凭据。

只要 Jules 还在替你执行任务，就该立即行动。 如果团队已将完成的修改全部合并，也不需要保留 Jules 中的记录，迁移负担就会小得多。如果只是评估编程智能体，没有现成的 Jules 任务，可以跳过导出，直接阅读下文的执行环境选型。长期选哪家供应商可以再考虑，保全现有工作不能等。

Jules 数据导出：保住 Git 仓库之外的工作上下文

已经存入 GitHub 的代码、分支和拉取请求会继续留在那里。Google 的导出范围则包括 Jules 保存的设置、环境变量、定时任务、仓库连接、记忆、配置脚本，以及会话中的提示词、计划、日志和补丁。具体见官方导出说明。

拉取请求（PR）是一项待审查的代码修改。它能保留补丁，却未必能保留智能体为何选择这样修改的原因。配置脚本里可能有让测试通过的关键依赖安装步骤；某条记忆可能解释了为什么没有采用一个看似不错的重构方案。在把这些材料交给另一个智能体之前，先审阅一遍。

把导出结果作为归档保留，再为每项未完成的任务整理一份更精简的交接材料。写清仓库和分支、预期修改、已完成部分、剩余验收条件，以及用于验证成功的命令。辅助记录用链接引用，不要把整段对话塞进新提示词。

例如，依赖升级任务不能只留下一句“完成升级”。还应保留尚未解决的兼容性问题、已经修改的文件，以及能复现故障的测试。这样，下一个智能体拿到的是边界明确的任务，审查者也有依据退回不完整的结果。

按 Google 公布的流程导出

Google 提供的方法是配合使用 Jules Tools 和指定的导出提示词。先安装并登录：

npm install -g @google/jules
jules login

在用户主目录中启动命令行编程智能体，粘贴公告中展开后的完整提示词。要获取仓库数据，需先连接 GitHub。结果会写入 ~/jules-export；请将其私密保存，因为 env-variables.json 包含凭据的实际值。各会话的记录包括 summary.md、活动日志和差异文件。

显示完成，不代表导出完整。 阅读 Google 公布的导出脚本可以发现：它统计的是已列出的会话数，即使某个会话的详情获取失败，也会计入其中；错误会另行报告。脚本还会从会话输出中提取配置命令，因此在认定仓库已具备迁移条件前，要检查实际写出了什么。这一发现来自对已公布脚本的阅读；本文没有实际执行导出。

负责验收迁移的工程负责人尤其需要分清这两件事。“命令执行完了”远不如“所需补丁、配置和任务上下文都在”有说服力。如果重要记录缺失，应在仍有访问权限时补齐，而不是让下一个智能体重新推演。

历史记录和 Jules API 怎么处理？

将历史记录保存在本地，并逐步移除自动化流程对 Jules 的依赖。停服公告没有承诺把历史记录自动导入其他智能体，也没有承诺服务关闭后 API 仍会继续运行。

Google 的 Jules API 公开文档介绍了会话及其活动，包括创建任务、批准计划和发送消息。这些都是执行链路上的依赖：即使团队里没人打开 Jules 网站，只要处理 issue 的机器人还会创建 Jules 会话，它就需要替代方案。

盘点调用 Jules 的脚本、工作流文件和集成，记录各自的输入、等待的成功信号，以及结果写到哪里。仅仅换掉提示词，迁移仍可能失败，因为旧集成可能还在等待 Jules 会话标识符，或轮询 Jules 活动来判断任务是否完成。

API 快速入门文档仍然在线，不代表服务期限得到延长。没有单独的端点停用时间表时，应按服务整体时间表规划，并在进入只读阶段前迁走任务创建流程。这是操作层面的建议，不是 Google 另行公布的 API 停用日期。

对于历史记录，要区分“保存下来”和“可以接着运行”。保存的计划能帮助另一个智能体理解任务，却不能还原原智能体当时的运行环境。应完成现有工作，或留下可接续的阶段成果，让其他开发者无需打开 Jules，也能复现下一步。

Antigravity 会承接什么？现在已经能做什么？

Google 表示，将把 Jules 积累的经验带入其智能体开发平台 Google Antigravity。Google 的 Jules 官方公告称，正在将远程自主后台执行能力与 Antigravity 的开发环境结合，但没有给出交付日期。

现有产品已经支持一些实用的后台工作方式。Antigravity App可以管理并行智能体，通过 Projects 组织工作，并运行定时任务。Google 的 Remote Control 文档介绍了如何通过浏览器访问运行在笔记本、台式机或服务器上的会话。

关键区别在于谁来提供运行任务的计算机。Remote Control 是访问现有机器的窗口；单凭这项功能，不能认定 Google 已提供托管式 Jules 替代方案。想让维护任务整夜运行的团队，必须明确哪台机器持续开机、谁维护它的依赖，以及机器不可用时如何处理。

**迁移路径：**在 Antigravity 中打开仓库，重建必要的环境配置和说明，然后执行一项有明确测试的小任务。如果方案依赖远程访问，先核实目标机器及其可用性。工作流通过审查后，再加入周期性调度。

如果你需要 Antigravity 的开发环境，也能负责运行主机，它就是合适的选择。如果要求是“开发者合上笔记本，也不用有人维护另一台机器”，就应立即评估托管方案，不要让迁移切换依赖一个尚无发布日期的功能。

访问资格和配额方面可参考 Antigravity 价格指南；至于哪种日常开发环境更适合自己的工作，则可阅读 Google Antigravity 与 Cursor 对比。

Jules 替代方案：先选好能持续运转的执行环境

先选运行环境，再看智能体的代码风格。运行环境就是执行任务所需的计算机和软件环境。对这次迁移而言，最有用的区分是：由你自行维护环境、由供应商托管，还是通过 GitHub Actions 执行自动化任务。

以下路径依据各供应商当前的文档整理，供迁移起步时参考；这不意味着它们的功能完全相同，也不意味着它们与 Jules 共用某种导入格式。

OpenAI Codex Cloud：托管任务，复用项目环境

OpenAI Codex Cloud是托管式编程智能体，计算机进入休眠后，它仍可继续工作。每个任务都有独立工作区，你可以先检查修改和测试结果，再提交代码或创建 PR。Codex Cloud 官方指南介绍了当前的配置流程。

**迁移路径：**在 ChatGPT 中选择 Work in > Cloud，然后创建或选择一个环境。连接 GitHub 仓库，让 Codex准备项目，核对配置检查结果，再发布该环境。使用整理好的 Jules 交接材料启动一项边界明确的任务，随后审查修改和测试结果。

主要障碍在于环境能否访问所需资源。本地测试成功，并不能说明一个无法访问包注册表或所需服务的云端任务也能成功。在环境设置中配置必要的网络访问目标和凭据，然后在该环境里验证同一项测试。

如果核心需求是托管任务队列，以及可重复使用的项目配置，可以选择 Codex。第一次试用应选一项能快速判断结果对错的任务，而不是范围不明的重写。更广泛的 Codex 与 Claude Code 对比讨论了不局限于此次停服的工作流选择。

Claude Code：云端会话与仓库自动化两条路径

Anthropic 的 Claude Code既提供合上笔记本后仍可继续运行的云端会话，也提供独立的 GitHub Actions 集成，用于仓库工作流。该选哪条迁移路径，取决于要替换的是交互式任务交接，还是自动触发流程。

**云端会话路径：**连接仓库，配置云端环境的初始化步骤、网络访问和变量，再启动一项范围明确的任务。在已完成身份验证的 Claude Code终端中，运行 claude --cloud 即可启动云端工作。如果采用常规的 GitHub 克隆方式，应先推送分支，确保会话拿到预期的提交。详见 Claude 云端会话指南。

主要障碍是共享额度和访问权限：云端会话会消耗账户的 Claude 使用额度，也可能受到组织权限限制。工程师的个人配置能运行，不代表公司账户也能执行相同的工作负载。

**GitHub Actions 路径：**仓库管理员可在 Claude Code 中运行 /install-github-app，按流程完成身份验证配置，并审查生成的工作流 PR。先通过明确的 @claude 请求试运行，再接入需要替换的定期任务或事件触发任务。Anthropic 的 GitHub Actions 指南说明了应用、凭据和工作流的要求。

这条路径的主要障碍是工作流需要有人负责。必须有人维护触发器、凭据和权限，并能区分环境配置失败与编程任务失败。如果任务本来就应由仓库事件触发，Actions 会更合适。本站的 Claude Code GitHub Actions 指南详细介绍了这种运作方式。

GitHub Copilot 编程智能体：在 GitHub 内完成交接

GitHub Copilot 的编程智能体可以在 GitHub 工作流中完成后台开发和测试。其当前文档区分了云端沙箱与 GitHub Actions 环境，因此要确认任务实际选择了哪种环境。详见 GitHub 上的 Copilot。

**迁移路径：**确认订阅方案的访问资格和组织策略，选择仓库及分支，然后给 Copilot 一项带有验收条件的任务，并要求它创建 PR。合并前检查其提出的修改和测试依据。沿用 Jules 清单中的同一份问题描述，才能判断替代工具是否完成了原任务。

限制取决于执行环境：GitHub Actions 会话只能修改单个仓库，云端沙箱会话则可以跨仓库操作。两者每项任务都只在单个分支上工作，并创建单个 PR。如果迁移需要跨分支协调修改，应拆成可以分别审查的任务。

如果任务归属和待审查队列本来就在 GitHub 中，可以选择 Copilot。这样交接能紧贴 issue 和 PR，但仍需重建此前保存在 Jules 中的环境与说明。

别把导出当成自动迁移

把“Jules 将融入 Antigravity”理解成账户迁移方案，是一种误导性的捷径。Google 的表态描述的是产品方向和数据导出，并未承诺当前会话、定时任务或记忆会自动出现在替代工具中，且立即可用。

另一种误区是把浏览器访问当作云端执行的证明。浏览器既可以控制你维护的机器，也可以控制供应商托管的机器。界面可能很像，但保障任务持续运行的责任归属并不相同。

采用一条实用的验收标准：替代方案必须能复现所需环境配置、完成一项边界明确的任务、展示检查结果，并交付可供审查的修改。 不要仅仅因为它认得同一个仓库，或能写出一份看似合理的计划，就决定采用它。计划可以说明它理解了任务；工作流真正跑通，才能证明迁移有效。

对工程负责人来说，这样反而能缩小决策范围。停服前不必敲定未来所有编程工具的选择，只需为那些原本会中断的任务找到一条经过验证的执行路径，并落实能够排查故障的负责人。

本周迁移清单

优先跑通第一个替代方案，再逐步覆盖其余待办任务。

• **盘点：**列出 Jules 仓库、未完成会话、定期任务和 API 调用方。为每项需要继续的作业指定负责人和迁移去向。
• **保存：**按 Google 的流程导出，检查错误和重要文件，并将原始归档私密保存。
• **收尾或保留阶段成果：**审查尚未处理的补丁，为每项需要继续的任务留下清晰可理解的分支、需求和测试。
• **重建：**配置所选运行环境的依赖、说明、网络访问和凭据。不要把密钥值写进普通任务笔记。
• **验证：**让一项小任务完整经历环境配置、开发、测试和人工审查。除了成功创建 PR，也要检查失败时的处理路径。
• **切换：**替代方案跑通后，再迁移周期性触发器。关闭重复提交机制，不再需要的旧访问权限应及时撤除。

周一就可以选一个正在使用的仓库，导出其 Jules 上下文，再用替代工具完成一项小任务并通过审查。这样就能形成一套可复用的迁移方法，在服务停止接受任务之前逐项推广。

订阅邮件通讯，获取开发工具变化的实用指南。