⚡ Google Labs 内部：打造 Gemini Coding Agent——Jed Borovik、Jules 与 AIE CODE Preview

摘要

• Jules 为这样一个未来而打造：代码代理在专属云电脑上运行数小时甚至数天，而不只是待在 IDE 里提供辅助。 Borovik 最具代表性的表述是：「所谓自主，就是它有自己的电脑」（“autonomous means, like, it has its own computer”）；Google 正在为可批量复制、远程触发并最终成为环境基础设施的代理设计产品。

• Borovik 描述了 Labs 产品团队、DeepMind 模型、内部开发工具与使用数据之间反馈闭环所形成的优势。 他所说的是一套贯穿端到端的系统，从“页面上的像素”一路延伸到基础设施、模型和训练；同时，编码的价值既在于“AGI 视角”，也在于“美元视角”。

• 基础模型持续进步，正逐步降低对复杂代理脚手架的需求。 早期 Gemini 版本需要复杂的子代理和编排，如今 Borovik 的结论是“少即是多”，脚手架越来越像是弥补模型能力缺口的拐杖。谈到 RAG，主持人认为语义搜索应只是工具之一，不应成为系统唯一的组织原则；Borovik 认同基于 embedding 的 RAG 并非唯一方案，并表示 Google 正在积极研究这一领域。

• Jules 正在成为一款长期产品，而一则关于30天会话的轶事，则揭示了用户可能持续多久使用同一条代码代理工作流。 Jules 在 I/O 后的5月发布公告获得市场反馈，成为其产品化的转折点；它出现在 GitHub 主题演讲中，也强化了 Borovik“它当然会长期存在”（“certainly here to stay”）的判断。另一个案例中，主持人团队原以为没人会让单个会话持续30天，直到第一位用户触达会话数据上限、会话被锁定后情绪激烈。

• 分发路径覆盖 API、CLI、GitHub 工作流，最终还会延伸到更广泛的 Gemini 产品面。 一位用户触发 Jules 更新网站，再通过 GitHub Action 自动合并其 pull request，说明代理可以完全嵌入工作流基础设施。Borovik 表示，刚刚发布的 Jules CLI 到节目上线时就会与 Gemini CLI 集成。

• 主持人认为，垂直代理业务在经济上比通用代理基础设施更容易跑通；Borovik 则认为软件需求会扩张，而不是就业简单坍塌。 主持人称代理公司似乎在“桶里捞鱼”（“shooting fish in a barrel”），ARR 增长更快、利润率更高，但也明确承认，出色的基础设施公司依然可能胜出。Borovik 对劳动力悲观论的反驳是需求弹性：如果工程师的生产力提升50%、100%甚至10x，更多软件项目就可能值得投入。

• 当代理连续工作数周、吞入文件和海量命令输出时，关键不再是原始上下文窗口有多大，而是如何管理上下文。 即使上下文窗口达到200万 tokens，也可能仍然不够；摘要、外部笔记和子代理交接都会带来信息传递难题。主持人对本地到云端连续性的初步答案，不是转移脑状态，而是转移产物：「我不会把脑状态转给你，我只告诉你我做了什么。」

• 粗放式 vibe coding 的继任者，必须同时解决规格定义和结果验证。 主持人将问题拆成两部分：明确想要什么，以及验证结果是否符合预期。规范驱动开发可以改善提示词，但也可能变成一场50页的瀑布式工程；交互式规划则承认，用户往往要在反馈中才发现自己真正想要什么。Borovik 将图像描述为另一种输入模式，主持人希望加入视频来处理具有时间维度的 UI bug；双方还讨论了把 computer use 作为超越聊天界面的下一层交互。

精读

1. Stable Diffusion 让一位资深 Googler 转向代码代理

• 在 Google 工作9年、其中大部分时间负责 Search 的新鲜度与新闻业务后，Borovik 将自己的 AI 转向归因于 Stable Diffusion，而不是 ChatGPT。艺术家在“这在偷我的作品”和把它当作“创作更好艺术的工具”之间分化；他很快意识到，编程也面临同样的选择。

• 当人们开始劝大学生不要学计算机科学时，Borovik 的反应带有强烈个人色彩：“这是我的 Stable Diffusion 时刻。”AI 可以拿走“我的艺术、我的手艺”，也可以成为制作更好软件的工具；他有意选择了后者，最终加入 Jules。

• Google Labs 的使命，是打造“Google 其他部门不适合做的新型、创新产品”。它本质上是产品组织，但与 DeepMind 紧密协作，覆盖从界面像素、基础设施到模型训练的完整闭环。

• Google 早已发表过关于编码辅助的研究，并围绕内部 IDE Cider 建立了内部能力。Borovik 强调，将自研模型与异常丰富的使用数据结合，能够把过去只能留在内部的复杂系统推向更广泛的产品。

2. Jules 假定自主代理终将离开 IDE

• 核心问题不是复制现有编码助手，而是模型能力提升后代理将走向哪里：“那就为那个未来打造。”如果代理能够连续数小时甚至数天处理复杂工作，Borovik 认为它应该拥有自己的环境，而不是占据开发者的本地工作区。

• 自主只是第一层；团队还希望 Jules 变得“无处不在”。它的 API 可以让事件在开发者无需打开聊天窗口的情况下发起任务，其中一个工作流就是由 Jules 更新网站，再由 GitHub Action 自动合并生成的 pull request。

• 产品正在开发者已有的工作界面之间扩散。录制前几周，Jules 已发布专用 CLI；Borovik 表示，到节目上线时它将与 Gemini CLI 集成。API 负责远程触发，CLI 则服务于已经在本地工作的开发者。

3. 更强的模型让更薄的代理框架成为可能

• Borovik 最明确的工程经验是：模型质量会改变能构建什么，也会改变系统需要多少编排。早期 Gemini 模型需要“极其复杂”的脚手架；随着模型进步，架构开始简化，因为“脚手架几乎就是拐杖”，用来弥补模型本身缺失的能力。

• 团队曾为编辑、子问题、集成、审查等不同角色分别配置代理。Borovik 并未声称如今的 harness 已经不复杂，但他发现，更少的刚性组件更容易维护和改进，既能靠常规工程，也能靠机器学习：“少即是多”（“Less is more”）。

• 基于 embedding 的 RAG 也引发了类似反思。主持人的反驳异常明确：任意切分的 chunk 意味着检索作为唯一机制“永远不会好”，因为捕捉到一种语义关系的 chunk 可能遗漏另一种关系；大上下文注意力则可以避免把这一瓶颈硬编码进系统。

• 两人都没有彻底否定语义检索。主持人仍然主张把它与文件访问、grep 和网络结合使用，而不是“做事的唯一方式”；Borovik 表示认同，并称 Google 仍在持续研究这一领域。主持人还说，在向他人推荐过几种代码 embedding 模型后，他所在团队发现自己并不需要它们。

4. 随着采用率和曝光度上升，Jules 从实验走向产品

• Borovik 表示，Jules 从一开始就计划做成真正的产品，但 I/O 后5月的公告才是决定性节点：积极反馈推动团队将其打造为长期产品。它在 GitHub 主题演讲中被提及，也强化了内部判断——“它当然会长期存在”。

• 主持人给出了另一种市场判断：太多有能力的开发者在构建框架，因为开发者工具让人感到熟悉，却没有真正想清楚客户或垂直场景。他认为，垂直代理的 ARR 增长更快、利润率更高，像是“桶里捞鱼”；但他也承认，杰出的基础设施公司依然能够成功。

• 两人谈到 AI Engineer Code 时，将会议描述为行业转型期间的中立集合点：行业正从学术论文和开放研究，转向产品、创业公司和闭源模型。主持人估计，即将举行的峰会大约每23名申请者录取1人，并表示最重要的是“走廊轨道”，因为演讲内容会免费发布。

• 这种“走廊轨道”也延伸到正式议程之外：上一场纽约活动促成了约15场参与者自发组织的晚餐和聚会。主持人的建议是，带上一张简洁的名片，说明你在做什么、能提供什么帮助、需要什么帮助，然后围绕语音、代码审查代理、金融或生物学等细分主题组织聚会。

5. 30天会话上限将上下文变成研究前沿

• 主持人分享了一则代码代理轶事：他的团队只保存30天的会话数据。他们当时认定：“不可能有人会使用同一个会话30天”；但第一位触达这一上限的用户在会话被锁定后非常不满，说明一条连贯的代理工作流可以持续很久。

• 代码代理在上下文方面承受的压力尤其大，因为它们会在持续数周运行时吸收文件、命令输出和大量对话轮次。即使拥有最高200万 tokens 的上下文窗口，问题也不会消失，这使编码既成为影响巨大的产品类别，也成为要求极高的研究环境。

• 可用手段包括摘要、把状态外置到笔记中，以及将边界清晰的工作交给不必携带父线程全部上下文的子代理。每种方法都会制造保真度问题——“如何确保足够的信息来回传递？”——而两人也指出，最佳方案可能会随着模型变化而变化。

• 主持人没有读过比较各种方法效果的论文，Borovik 则称这是一个正在进行中的研究主题，无法展开细节。实践尚未定型之所以重要，是因为长期运行的代码代理会话已经开始挑战它们最初的设计假设。

6. 持久化交接可能是 pull request，而不是对话

• 新的产品界面正在变得清晰：IDE、VS Code 扩展、CLI 和云端代理。尚未解决的问题是，这些模式在开发者从本地开始、异步委派任务、之后又需要恢复深度工作时如何互通，而不必重放整段代理历史。

• 主持人最初设想在不同工具之间“传送”对话，随后改变了自己的答案。可转移的单元可能是 Linear ticket、GitHub pull request 或简洁的状态更新：“我不会把脑状态转给你，我只告诉你我做了什么”；遗漏的信息则像人类协作一样，在后续过程中才会暴露。

• Borovik 希望行业先说清楚自己正在创造怎样的体验，而不是把代码代理当成零和竞赛。他向同行提出的问题是：“我们正在创造的这个美好未来是什么？”其中包括本地与云端工作如何衔接，以及软件工程如何变成一种更好的手艺，而不只是更快的生产线。

7. 软件需求可能扩张，但粗放式 vibe coding 已到极限

• Borovik 提醒，AI 工具在各家公司之间的渗透程度仍低于他有时的预期；但就个人而言，他已经无法想象回到没有辅助的编码状态：“那听起来太糟糕了。”他反对“代理能力提升必然意味着公司停止招聘软件工程师”这一简单判断。

• 他的解释机制是需求弹性。农业就业之所以崩塌，是因为食品消费存在上限；而更便宜的电力却会带来更多消费。他认为，软件需求具有很高的弹性。

• 如果一名工程师能够交付原来的50%、100%或10x，过去无法证明投入合理性的项目就可能变得可行。主持人的补充判断是，代理可以吸收商品化工作，理想情况下让工程师有更多空间处理战略性、全新的、高风险和需要深度专注的工作。

• 主持人认为，“vibe coding”已经变成了随便 YOLO 提示词、产出“能想象到的最糟糕代码”，再把清理工作留给别人的许可。“Agentic coding”是最主要的替代说法，但缺少 vibe coding 的乐趣；理想实践必须重新找回认真、手艺和可靠性。

• 规范驱动开发提供了一种答案，因为“提示词写得马虎，得到的就会是马虎的结果”；但一份耗时3天、长达50页的规格文档，只是在重演瀑布式开发。主持人更偏好交互式规划：用户往往要等代理做出某个东西、自己进行修正后，才知道真正想要什么。

• 主持人将可信赖的代理工作概括为两个成对的问题：明确预期结果，以及验证结果是否符合预期。Jules 会在仓库已有测试时运行这些测试，但主持人指出，它不会强制每项改动都新增测试；是否产出测试，应由工程师控制。

• 规格定义也应超越聊天界面。Jules 已经接受图像输入，主持人希望加入视频来处理具有时间维度的 UI bug；两人都把 computer use 视为下一层能力——让代理渲染并操作 VM 或浏览器，前提是系统能够达到足够的精度、速度和可负担成本。

• Borovik 邀请热情用户和怀疑者分享自己的工作流、失败经历，以及不使用这些工具的原因。他同时也在招聘，并表示很乐意与有兴趣从事代码代理工作的人交流。