Gemini 中文文档认识 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）是 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 去执行那些机械的部分。
快速上手：五分钟派第一个任务
第一步：网页版，零钱零配置
- 打开 jules.google.com，用 Google 账号登录
- 装 Jules GitHub App，授权它访问仓库
- 选仓库和分支，写一句具体的提示词
- 它会出一份计划 → 你批准 → 它干活 → 给你 PR
免费档不需要信用卡，15 个任务/天。先拿一个小 bug 试水，别一上来扔个大重构。
顺手建议在仓库里配一个 .jules/ 配置文件或 AGENTS 风格的规范文件，把项目的构建命令、测试命令、代码风格写清楚。Jules 会在 VM 里读这些，能少踩不少坑。
第二步：从 GitHub issue 直接派活
在仓库里给某个 issue 打上 jules 标签，任务就自动派过去了。
这是我认为最能改变习惯的一个入口：现在你写 bug 报告的成本，几乎等于修这个 bug 的成本。
第三步：命令行党——Jules Tools
2025 年 10 月 2 日发布，npm 装就行：
npm install -g @google/jules
# 登录认证
jules login
# 查看可用仓库和任务列表
jules list
# 直接派一个新任务
jules new "把 auth 模块的 session 校验抽成中间件，并补单元测试"
# 查看任务进度与产物
jules status <session-id>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 分永远得你来。
我的建议：这样开始最不容易放弃
第一天，别搞大项目。做这三件小事：
- 拿一个真实存在的小 bug，用网页版跑一遍，感受一下"计划 → 批准 → PR"的节奏
- 挑一个测试覆盖率最低的模块，让它补测试，顺便看看它在 VM 里跑测试时会不会自己修回去
- 给仓库挂一个每周依赖检查的 Scheduled Task，让它替你盯着
做完这三步，你基本就知道它在你的工作流里该占哪个位置了。
至于要不要付费——免费档 15 个任务/天，足够大多数个人项目用很久。先用满免费额度，再决定要不要为 Gemini 3.1 Pro 买单。
进阶
更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。