--- url: /jules/what_is_jules.md description: >- Google Jules 是谷歌官方的异步 AI 编程智能体，由 Gemini 3.1 Pro 驱动，克隆 GitHub 仓库到隔离云虚拟机里改代码、跑测试、直接提交 PR。免费档每天 15 个任务。本文讲清它是什么、和 Gemini CLI/Antigravity 怎么分工、以及如何五分钟上手（含 CLI 与 REST API）。 --- # 认识 Google Jules：把最不想干的活，丢给云端的异步编程 Agent 先承认一件事：你今天提交的代码里，有多少是你真的想写的？ 我猜不多。 剩下的时间都去哪了？升级一个 dependencies、修 12 个 breaking change、补某个两年前就该写的测试、把「TODO: refactor this」从三个文件里清掉——这些活儿没人愿意干，但又不能不做，于是它们永远排在待办列表最下面，越积越厚。 Google Jules 瞄的就是这块地方。 它是谷歌官方的**异步编程智能体**：你丢一句话给它，它自己去把活干完，完事给你一个 PR。过程中你该开会开会，该睡觉睡觉。 > 一句话区分：Gemini CLI 和 Antigravity 是「你坐着，AI 陪你写」；Jules 是「你说完就走，AI 写完叫你」。 ## 什么是 Google Jules **Jules**（读作 /dʒuːlz/，官网 [jules.google.com](https://jules.google.com)）是 Google Labs 推出的 AI 编程 Agent，2025 年 5 月公开 beta，2025 年 8 月 6 日正式 GA。 它的官方自我介绍挺实在：*Jules does coding tasks you don't want to do*——干你不想干的编程任务。 具体地说：**改 bug、升依赖版本、写测试、重构、批量改多处文件**。 ### 它不是聊天机器人，是一台「临时云电脑」 这是 Jules 最核心、也最容易被忽略的架构特点： **你的任务不是丢给一个大模型去"想象"代码，而是丢给一台真实的 Google Cloud 虚拟机去"跑"代码。** 完整流程是这样的： ``` 你指定仓库和分支 → Jules 把整个仓库 clone 进一台全新的云 VM → 基于 Gemini 生成计划 → 你审阅/批准计划 → Jules 在 VM 里装依赖、改文件、跑测试 → 挂了就自己改，直到测试通过 → 开一个 PR 给你 → 你 review 合并 ``` VM 是隔离的、任务跑完就销毁。谷歌明确说明 **不拿你的私有代码训练模型**。 这个区别比听起来重要得多。一个只会生成代码的模型，永远不知道自己改得对不对；一个能真的 `npm install && npm test` 的 Agent，会在测试挂掉之后自己回去改。 > 我的立场：这就是判断一个 AI 编程工具是玩具还是生产力的分水岭——**它有没有一台能真跑起来的电脑**。 ### 三个核心概念（用 API 前必须懂） 官方 REST API 是围绕这三个原语设计的，理解了它们，后面的 CLI 和自动化才顺： * **Source**：输入仓库，目前主要是 GitHub 仓库，通过 Jules GitHub App 授权 * **Session**：一个连续的工作单元，可以理解成一次任务会话 * **Activity**：会话里的单个事件——生成计划、一条消息、一次进度更新、一个完成的产物 ## 它凭啥值得你花时间 按"实际干活时谁最救命"排个序： * **计划先给你看（Plan before execution）**：Jules 不会闷头就改。它先出一份计划，你可以**在它写第一行代码之前**把它掰回来。这个设计我特别认同——复杂功能里，方向错了比代码写错贵十倍 * **异步到不用管（Fire and forget）**：派完任务关页面，它在云端跑。官方原话是这些活 runs while you sleep * **整个仓库级别的改动**：因为整个仓库都 clone 进 VM 了，它可以做跨几十个文件的协同重构，不受 IDE 里"当前打开几个文件"的限制 * **自己跑测试、自己写测试**：已有测试套件它会跑，没有它会给你补。补测试这种最招人烦的活儿，交给它最合适 * **只到 PR 为止，不合并**：这条是刻意的护栏。Jules **不能**自己合 PR、不会推你的生产分支。人始终是最后一道闸 * **无处不在的入口**：网页、CLI、REST API、GitHub Actions 四种触发方式 * **能上网查资料**：任务过程中它可以主动搜文档和代码示例，不用你把 API 文档粘进去 ### 进阶一点的几个自动化 这几个功能上线后，Jules 从"你叫它才动"变成了"它自己盯着"： | 功能 | 上线时间 | 干什么 | | --- | --- | --- | | **Scheduled Tasks** | 2025-12-10 | 定时任务，比如每周依赖检查、每晚 lint 修复，结果以 PR 交付。2026-01-26 起可编辑、暂停、恢复 | | **Suggested Tasks** | 2025-12-10 | Jules 主动扫你的仓库找活干（起初是找 TODO 注释），提改进方案给你批。初期仅 Pro/Ultra，每人最多监控 **5 个仓库** | | **Planning Critic** | 2026-01-26 | 执行前先让一个"评审 Agent"挑计划的毛病：逻辑漏洞、漏掉的边界情况、范围失控。官方称上线时**任务失败率降了 9.5%** | | **CI Fixer** | 2026-02-19 | 自己开的 PR 上 GitHub Actions 挂了，它会自动诊断、改、重新推 | | **MCP Server 支持** | 2026-02-02 | 任务中直接连第三方平台：Linear、Stitch、Neon、Tinybird、Context7、Supabase 等 | | **Environment Snapshot** | 2025-08-06 (GA) | 依赖安装、环境变量的配置包，可复用，省掉每次重建环境的几分钟 | | **提交署名配置** | 2026-02-19 | 可选择署名给 Jules、与指派者共同署名、或归属你自己 | > Planning Critic 那个 "-9.5% 失败率"我愿意多信一分：让另一个 Agent 专门挑刺，是当下最朴素也最有效的提质手段，比堆参数省钱多了。 ## 一个真实的时间线，比参数更能说明它成熟得有多快 从公开 beta 到现在，Jules 基本保持了每月一次的节奏： | 时间 | 事件 | | --- | --- | | 2025-05-19 | Google I/O 2025 公开 beta | | 2025-08-06 | **GA**，推出 Free / Pro / Ultra 三档；GitHub Issues 集成、Environment Snapshots、Gemini 2.5 thinking | | 2025-10-02 | **Jules Tools CLI** 发布；**REST API** 开放 alpha；Jules GitHub Action 上线 | | 2025-11-19 | 接入 **Gemini 3 Pro**（先 Ultra，随后 Pro） | | 2025-12-10 | Scheduled Tasks、Suggested Tasks、Render 部署失败自动修复 | | 2026-01-26 | Planning Critic、性能瓶颈建议、REST API 三件套升级 | | 2026-01-30 | **Gemini 3 Flash 成为所有用户（含免费档）默认基础模型** | | 2026-02-02 | MCP Server 支持 | | 2026-02-19 | CI Fixer、可配置提交署名 | | 2026-03-09 | **Gemini 3.1 Pro 成为付费档默认模型**（取代 Gemini 3 Pro） | beta 阶段结束时，谷歌公布过一组数字：**228 万次站点访问（其中 45% 来自移动端）**，开发者提交了数以万计的任务，公开分享的代码改进超过 **14 万条**。 > 45% 移动访问这个数字很有意思：说明大量用户是在通勤、开会间隙拿手机给它派活的。这恰恰就是异步 Agent 的形态——你不需要坐在编辑器前才能用它。 ## 到底该 Jules 干哪些活 说点务实的。Jules 适合的是**边界清晰、结果可验证、可事后 review** 的任务： * **依赖升级**：「把 next.js 升到 v15，并把项目迁到 app directory」——这是官方首页的示例。 * **补测试**：指向一个覆盖率稀烂的模块，让它写测试并在 VM 里跑通 * **批量小修**：一堆 issue 标着 `jules` 标签，第二天早上收一堆 PR * **定期体检**：依赖周检、lint 夜修，用 Scheduled Tasks 挂上去 * **CI 红灯**：人还没打开 IDE，CI Fixer 已经把补丁推上去了 不太适合的：需要实时来回讨论的架构决策、含糊到你自己都说不清的需求、以及你指望它一次改对 3 万行历史包袱。 > 选任务的土办法：**如果这个任务你能写成一个清楚的 issue，它就能交给 Jules。** ## 和本站其他工具怎么分工 这是我最常被问到的问题，索性一次说清： | 工具 | 形态 | 什么时候用 | | --- | --- | --- | | **Jules** | 异步、云端 VM、PR 交付 | 后台批量脏活：升依赖、补测试、修 bug、定时任务 | | **Gemini CLI** | 交互式终端 Agent | 你要一边聊一边改，需要实时来回 | | **Google Antigravity** | Agent 优先的 AI IDE | 你在 IDE 里干活，想要 Agent 接管整个实现流程 | | **Claude Code / Cursor** | 交互式编辑器内 | 需要逐手势微调时 | 它们不是替代关系，更像一个团队里的不同工位：**交互式工具负责"想清楚"，Jules 负责"干完"**。真要偷懒，最爽的组合是在 IDE 里用 Antigravity 把方案敲定，再让 Jules 去执行那些机械的部分。 ## 快速上手：五分钟派第一个任务 ### 第一步：网页版，零钱零配置 1. 打开 [jules.google.com](https://jules.google.com)，用 Google 账号登录 2. 装 **Jules GitHub App**，授权它访问仓库 3. 选仓库和分支，写一句具体的提示词 4. 它会出一份计划 → 你批准 → 它干活 → 给你 PR 免费档**不需要信用卡**，15 个任务/天。先拿一个小 bug 试水，别一上来扔个大重构。 顺手建议在仓库里配一个 **`.jules/` 配置文件**或 AGENTS 风格的规范文件，把项目的构建命令、测试命令、代码风格写清楚。Jules 会在 VM 里读这些，能少踩不少坑。 ### 第二步：从 GitHub issue 直接派活 在仓库里给某个 issue 打上 **`jules` 标签**，任务就自动派过去了。 这是我认为最能改变习惯的一个入口：**现在你写 bug 报告的成本，几乎等于修这个 bug 的成本。** ### 第三步：命令行党——Jules Tools 2025 年 10 月 2 日发布，npm 装就行： ```bash npm install -g @google/jules # 登录认证 jules login # 查看可用仓库和任务列表 jules list # 直接派一个新任务 jules new "把 auth 模块的 session 校验抽成中间件，并补单元测试" # 查看任务进度与产物 jules status ``` CLI 适合塞进 shell 脚本和 CI 流水线里，也支持把改动以补丁形式拉到本地再Review。 ### 第四步：想做自动化——REST API REST API 目前仍是 **alpha**（`https://jules.googleapis.com/v1alpha`），三点核心能力： * **Repoless sessions**（2026-01-26 上线）：不用连仓库，直接起一个预装 Node/Python/Rust/Bun 等运行时的临时云环境。拿它跑一次性脚本特别顺手 * **File outputs**：变更以 git patch 格式返回，方便你自己落盘处理 * **Activity filters**：按时间戳增量轮询新事件，做自己的监控面板 配合官方的 **`google-labs-code/jules-action`**，还能直接从 GitHub Actions 里触发 Jules。 ### 第五步：接你的工具链 2026 年 2 月起支持 **MCP**，任务执行中可以直连：Linear（工单）、Stitch（设计稿）、Neon / Supabase（数据库）、Tinybird（分析）、Context7（文档）。 另外还有 **Render** 集成：部署失败自动读日志、改代码、推 PR。 ## 价格：先把账算清楚 Jules 不是独立售卖的产品，**额度挂在 Google AI 订阅里**： | 档位 | 每日任务数 | 并发任务 | 模型 | 价格 | | --- | --- | --- | --- | --- | | **Jules Free** | 15 | 3 | Gemini 3 Flash | ¥0，无需信用卡 | | **Jules in Pro** | 100 | 15 | Gemini 3.1 Pro | Google AI Pro，$19.99/月 | | **Jules in Ultra** | 300 | 60 | Gemini 3.1 Pro，优先接入 | Google AI Ultra，约 $125/月 | 三个必须知道的坑： * **付费档目前只对个人 Gmail 账号开放**。Google Workspace 企业账号还买不了，企业用户得联系 Google Cloud 销售走 AI Ultra Access / Expanded Access * **按任务算，不按人算**，额度不池化给团队 * **硬上限，没有超额计费**。60 并发跑满了就排队，账单不会爆 > 关于模型有个口径分歧要提醒你：Jules 官网落地页至今还写着免费档 "Powered by Gemini 2.5 Pro"，但 2026-01-30 的官方 changelog 明确 Gemini 3 Flash 已成为所有档位的默认基础模型。**以你控制台里实际显示的为准**，别照着任何一个第三方表格下结论。 ## 冷静两句：它的边界在哪 我踩过、也听人踩过的几个地方： * **异步是它的优势也是局限**。它没有实时陪聊模式，你想揪着它逐步调就别用它 * **锁 GitHub**。目前没有 GitLab / Bitbucket / 自建 Git 的官方路径。自建托管需求的团队，先想清楚这个能不能接受 * **数据在别人的 VM 上**。有严格数据驻留要求的团队，这一步基本就劝退了。涉及敏感仓库，务必把 secrets 管理好，别把密钥提交进代码 * **速度不确定**。社区反馈小任务可能几分钟，复杂任务也有拖到几十分钟的情况。别把它放进"必须五分钟内出结果"的链路 * **安全问题不是空穴来风**。2025 年曾有第三方研究指出，Jules 具备读取外部网页的工具能力，存在被 GitHub issue 内容 prompt injection 诱导、将数据外带的风险，谷歌当时的回应是将此定性为 "abuse risk"。**把 issue 正文和它抓取的网页当成不可信输入对待**，这一点到现在也不过时 * **免费档的实际成功率别期待太高**。复杂多文件任务的输出仍然需要你仔细 review——它是 PR，不是终稿 > 一句大实话：Jules 的产出质量大概等于"一个写好 Detailed issue 的中级工程师"。它会给你一份 80 分的东西，最后 20 分永远得你来。 ## 我的建议：这样开始最不容易放弃 第一天，别搞大项目。做这三件小事： 1. 拿一个真实存在的小 bug，用网页版跑一遍，感受一下"计划 → 批准 → PR"的节奏 2. 挑一个测试覆盖率最低的模块，让它补测试，顺便看看它在 VM 里跑测试时会不会自己修回去 3. 给仓库挂一个每周依赖检查的 Scheduled Task，让它替你盯着 做完这三步，你基本就知道它在你的工作流里该占哪个位置了。 至于要不要付费——**免费档 15 个任务/天，足够大多数个人项目用很久**。先用满免费额度，再决定要不要为 Gemini 3.1 Pro 买单。 ## 进阶 更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。