11 月 11 日才是真截止日：Google Jules 年底关停，代码留在 GitHub，记忆和定时任务必须自己导出

有些产品死于没人用，有些产品死于路线合并。Google 的异步编程 agent Jules 属于后者，而且它给用户留的时间非常短。2026 年 10 月 29 日，Jules 官方 Changelog 贴出《Jules Turndown》：作为统一 agent 编程工作的努力的一部分，Jules 将在 2026 年 12 月 31 日关停；用户可以在 11 月 11 日之前继续完成手头的会话，之后 Jules 转为只读，直到年底。

如果你只记住 12 月 31 日这个日期，这篇文章就是来纠正你的。真正控制你计划的日期是 11 月 11 日。那之后你只能看，不能干活。更重要的是，Google 没有承诺把 Jules 里的一切平移到新产品里。它承诺的是导出，不是迁移。代码本来就在 GitHub 上，不用担心；但 Jules 记住的配置、定时任务、记忆和会话历史，如果不在只读之前导出来，就只能留在那个即将关闭的产品里。

先把两个日期分清楚

Jules 的关停时间表只有三行，但每一行都不能读错。第一行是 10 月 29 日，公告日，从这一天起倒计时就开始了。第二行是 11 月 11 日，最后一批可以继续干活的日子，公告的原话是你可以一直完成会话到这一天。第三行是 12 月 31 日，彻底关停的日子，中间 11 月 11 日之后到年底这一段，Jules 是只读的。

只读是什么意思，公告没有展开写，但按字面理解就是：你可以查看，不能再推进会话。这对正在跑的长任务是致命的。假如你的 Jules 会话在 11 月 12 日还没收尾，你不能指望它在只读期里继续改代码、继续提 PR。你能做的只是把它看完，然后在别处重做。把 12 月 31 日当成截止日期的人，会在 11 月 11 日之后突然发现自己已经没有动手的机会了。

公告也没有给出两个截止点的具体时刻。是 11 月 11 日零点，还是当天结束？是按哪个时区算？这些都没有写。稳妥的做法是把 11 月 10 日当成你自己的最后工作日，把 11 月 11 日留作缓冲，而不是留作冲刺。导出也一样，不要拖到 12 月：只读期虽然还能看，但你真正需要的是在还能干活的时候就把东西拿出来，并且验证导出的文件确实能用。

还有一个容易被忽略的点：公告里没有提到退款，也没有提到 Jules 在 Google AI Pro 和 Ultra 套餐里的任务额度会怎么处理。如果你是因为套餐额度才用 Jules，这些问题现在都没有答案，不要自己脑补。把它们记下来，去问官方渠道，或者在做迁移预算时按没有补偿来算。

Jules 到底是什么，为什么值得写一篇讣告

按 Google 自己的说法，Jules 最初是一个实验，目的是搞清楚异步编程 agent 能不能帮开发者清掉积压任务、更快交付。它的工作方式和在编辑器里实时陪你写代码的 agent 不一样：你给它一个提示词，或者在 GitHub 上指派一个 issue，它会在云端虚拟机里自己干活，最后把结果以分支和 PR 的形式交回来。中间你不需要盯着它，适合那些你不想做、但又不得不做的活：修 bug、升依赖、补测试、处理小功能请求。

这种异步模式的价值，恰恰在于它不占用你的注意力。实时 agent 要求你坐在屏幕前，一步步看它改；Jules 要求你把任务交出去，过一会儿回来验收。对积压任务多的团队和个人开发者来说，这个区别很大。也正因为如此，Jules 的关停不是一个无关痛痒的产品调整：它关掉的是一种工作方式，而不只是一个入口。

Google 在公告里说，Jules 教会了他们 agent 开发往哪里走，这些经验正在影响 Google 内部的多个产品，包括 agent 优先的平台 Antigravity。这句话要拆开读。前半句是事实陈述：一个实验产品完成了它的学习使命。后半句是方向，不是承诺。它没有说 Antigravity 现在已经有了 Jules 的全部能力，也没有给出远程后台任务什么时候在 Antigravity 里可用。把学习经验和产品替代画等号，是这篇公告最容易让人误读的地方。

什么能留下来，什么必须自己搬走

先说不用慌的部分。公告写得很清楚：你的代码、分支和 PR 本来就存在 GitHub 上，所以它们会留在原地。Jules 关停不会把你的仓库带走，也不会撤销已经合并的 PR。这部分资产是安全的，不需要导出，也不需要抢救。

再说必须动手的部分。公告列了一张清单，说你可以把 Jules 了解到的关于你工作的一切导出到本地文件夹：账号设置、环境变量、定时任务、已连接的仓库、记忆、安装脚本，以及每一个会话，包括它的提示词、计划、完整活动日志和代码补丁。这些东西都只存在 Jules 内部，GitHub 上没有。定时任务尤其值得注意：它不是代码，是你让 Jules 定期去做的安排；记忆也不是代码，是 Jules 在长期使用中积累的关于你的项目和偏好的记录。丢了它们，等于丢了你调教这个 agent 的全部上下文。

导出的方法也写在公告里：先安装 Jules Tools，用 npm install -g @google/jules 装好，再运行 jules login 登录；然后从家目录打开一个命令行编程 agent，比如 Claude Code，把公告里给出的导出提示词粘贴进去。这个 agent 会检查你的配置、执行导出，并且告诉你保存了什么和保存在哪里。导出结果落在 ~/jules-export 下面：每个仓库一个文件夹，里面有安装脚本、测试命令和记忆；每个会话一个文件夹，里面有可读的 summary.md、完整活动日志和 diff 文件。

这里有一个值得玩味的细节：Google 自己的导出指南，举例用的命令行 agent 是 Claude Code，也就是竞争对手 Anthropic 的产品。公告的措辞是比如 Claude Code，不是只限 Claude Code，但它是唯一被点名的例子。一个 Google 产品在告别信里让用户去请竞争对手的 agent 来帮忙搬家，这件事本身就说明了当时的现实：导出这件事没有做成一键按钮，它需要一个能读提示词、能跑脚本的 agent 在旁边帮忙。对用户来说，这不是八卦，而是提醒：导出过程本身也需要测试，不要假设粘贴一次就万事大吉。

导出时最容易踩的三个坑

第一个坑是密钥。导出文件夹里有一个 env-variables.json，里面装的是你的环境变量的值。公告在最后专门提醒：这个文件包含真实的密钥，一定要把导出文件夹妥善保管，不要放进仓库。很多人导出之后的第一反应是把整个文件夹提交到 Git 做备份，这恰恰是最危险的做法。正确的做法是把它放在本地加密位置，或者只备份到你信任的私人存储里，并且在导出之后检查一遍，确认没有把密钥贴到聊天记录、工单或者公开仓库里。

第二个坑是 GitHub 连接。公告提醒，如果你用 Jules 对接 GitHub，要先确认 GitHub 账号已经连接，否则导出里不会包含仓库数据。导出脚本自己也会检查这一点，但它只能告诉你缺了什么，不能替你补上。正确顺序是：先确认连接，再跑导出，跑完之后数一下导出的仓库数和会话数，和你在 Jules 里看到的数量对得上，再算完成。

第三个坑是登录凭证的有效期。公告附带的导出脚本里写着提醒：Jules CLI 的登录凭证大约一小时后过期，如果频繁遇到 401 报错，就重新运行一次登录命令，或者随便跑一条 Jules 命令刷新凭证。导出会话多的人，很可能跑到一半就过期。这不是你的操作失误，是已知行为。遇到 401 先重登录，再继续，不要反复粘贴同一段提示词，也不要把报错信息里的 token 贴到公开渠道。

还有一个更隐蔽的坑：导出脚本用到的部分接口并没有公开文档。公告的脚本注释里自己承认，如果某个调用开始返回 404 或者 400，要告诉用户是哪个调用出了问题，而不是猜测修复方法。这意味着导出过程有一定的脆弱性，越晚跑，风险越大。趁着产品还在正常运行、接口还没变的时候跑完，是最稳妥的选择。

Antigravity 到底接不接得住

Google 给 Jules 用户指的方向是 Antigravity，一个 agent 优先的开发环境。公告里对它的描述是：把自主的远程后台任务执行和 agent 优先的开发环境结合起来，让你同时得到两者的好处。这个愿景听起来很像 Jules 加编辑器的合体，但愿景不是现状。公告没有给出远程后台任务在 Antigravity 里上线的时间，也没有给出从 Jules 导入数据的方法。导出到本地文件夹，和导入到 Antigravity，是两件完全不同的事，前者已经有了，后者还没有。

同一天，Antigravity 还推出了插件市场，一个可以一键安装 Google 自家和第三方插件的目录，覆盖技能、MCP 服务器、规则、钩子和自定义 agent，首批包括 Stripe、Vercel、Notion、Linear、Supabase、Zapier 以及 Google 自家的文档、表格、云端硬盘和 Firebase 插件。这条消息要和 Jules 关停分开看：插件市场让 Antigravity 更像一个可扩展的工作台，但它并不回答 Jules 用户最关心的问题，也就是那些已经在云端跑起来的异步任务，以后在哪里跑、怎么跑。把插件市场当成 Jules 的替代品，是偷换概念。

对正在选迁移目的地的人来说，诚实的结论是：现在还没有一个官方指定的平替。Antigravity 是 Google 指出的方向，但它的远程后台能力还没有时间表；其他厂商的异步 agent 各有各的接入方式和定价，没有一个能直接吃掉 Jules 的导出文件夹。迁移的第一步应该是保住资产：代码在 GitHub 上已经安全，配置、记忆和会话历史导出到本地并验证可用；第二步才是评估：你的任务到底需要异步后台，还是其实可以在编辑器里的 agent 完成；第三步再决定要不要等 Antigravity，还是先用别的工具顶上。顺序不能反。

划界：这不是 Gemini Code Assist 停售那篇

本站此前已经发过一篇 Google 收编路线的资讯，讲的是 Gemini Code Assist 停售、全面收编 Antigravity。那篇和这篇很容易混淆，但它们是两件不同的事。Code Assist 是一项订阅制的编程助手服务，停售说的是不再卖新的订阅；Jules 是一个独立的异步 agent 产品，关停说的是服务本身在 12 月 31 日结束。共同点是它们都指向同一个方向，也就是 Google 正在把分散的 agent 编程能力收进 Antigravity；不同点是影响面和时间表完全不同，不能互相替代。

把两篇放在一起看，Google 的路线就更清楚了：不再是每个场景各养一个产品，而是把能力集中到一个 agent 优先的平台上。集中有好处，维护成本更低，体验更统一；也有代价，用户被迫迁移，实验产品的用户尤其容易成为代价的一部分。Jules 的用户就是这一轮代价的承担者。理解这一点，比单纯记住两个日期更重要，因为它预示着以后还可能有类似的合并。

定时任务和记忆，是最容易丢的两样东西

代码丢不了，定时任务和记忆却很容易丢，因为它们看起来不像资产。定时任务是你让 Jules 定期去做的事情，比如每天早上检查依赖更新、每周清理一次过期分支、每个月跑一次测试覆盖率报告。这些安排一旦停掉，不会立刻报错，只会悄悄地不再发生。等到几个月后才发现某个例行检查已经停了很久，损失往往已经造成。所以导出之后的第一件事，不是把文件存起来，而是把定时任务清单单独抄出来，一条一条决定：这条还要不要继续跑，如果要，在哪里跑，用什么工具跑。

记忆也是同样的道理。Jules 的记忆里可能包括你的项目结构偏好、你不喜欢的写法、你要求它每次都检查的事项、某个仓库特有的部署注意事项。这些内容不会出现在代码里，却决定了 agent 干活的质量。导出的 memories.json 和 memories.md 值得逐条读一遍，把真正重要的几条写进下一个工具的规则文件里，比如项目的 AGENTS.md 或者自定义指令里。直接把整个记忆文件原样丢给新工具，效果往往不好，因为新工具的提示词结构和 Jules 不一样；挑出最重要的规则，人工改写成新工具能理解的指令，才是有效的迁移。

会话历史的价值则要分情况看。已经合并的 PR 对应的会话，历史价值有限，留作记录就够了；还没有合并、还在讨论中的会话，历史价值很高，因为里面有你和 agent 来回修改的理由。导出时要优先确认这部分会话的 summary.md 和 diff 文件完整无缺，并且把它们的提示词和计划单独保存一份。只读期之后，这些讨论过程就只能靠导出文件还原了，文件不完整，等于讨论过程丢失。

判断：关停不可怕，可怕的是把导出当成迁移

Jules 的关停本身并不意外。实验产品本来就是用来验证方向的，方向验证完了，产品被收编是正常结局。真正值得警惕的，是把官方提供的导出当成已经完成了迁移。导出只是把东西从 Jules 的数据库里拿出来，放到你的硬盘上；迁移是让这些东西在下一个工具里重新发挥作用。中间还差一步，而且这一步目前没有官方工具帮你走完。

给 Jules 用户的清单可以写得很短。第一，在 11 月 10 日之前，把所有还想继续的会话收尾或者明确放弃，不要留到只读期。第二，确认 GitHub 连接，跑导出，数仓库数和会话数，验证 summary.md 和 diff 文件能打开。第三，把导出文件夹里的密钥当成生产密钥来保管，不要提交到仓库。第四，重新评估你的任务类型：哪些真的需要异步后台，哪些其实可以在编辑器里完成。第五，再决定要不要等 Antigravity 的远程后台能力，还是先用别的工具过渡，并且把这个决定写下来，而不是凭感觉拖着。

对没有用过 Jules 的开发者来说，这篇也有一个通用的教训：任何把你的工作记忆、定时任务和配置锁在产品内部的 agent，都值得你在开始重度使用之前先问一句，导出来是什么样子。Jules 这次至少给了导出工具和两个月时间，很多产品连这个都没有。选择工具的时候，导出能力不是加分项，而是底线。等到关停公告来了才发现自己的记忆和任务搬不出来，那就太晚了。