Gemini 3.8 深度解析：终端得分与代码跑通率翻倍背后的RLVR技术-北京尧图网络

Gemini 3.8 发布的消息我是半夜刷到的。Google 在美东深夜低调放出了新版模型官方测试报告里最扎眼的两个数字是 90.8% 的终端得分以及相比上一代翻倍的代码跑通率。第一反应是“又刷榜”但把官方放出的技术文档翻完又拿 preview API 实测了几轮之后我意识到这次的重点不是“分数高”而是模型开始用“死磕”的方式去解决真实工程问题。如果你平时写代码、搭 Agent、维护自动化流程这篇东西会很有用。1. 深夜发布背后的三个信号1.1 为什么偏偏挑这个时间点Google 选在深夜发布明显不是随机排期。这个动作在圈内其实是老套路先让消息在技术社区自然发酵一整夜第二天早上开发者睁眼就能看到一堆实测反馈讨论热度直接拉满。更重要的是深夜发布等于给所有观望的人一个“你自己去试”的机会。谁都能第一时间拿到 preview API真不行的话骂声会在几个小时内形成根本压不住。敢这么做说明他们对 Gemini 3.8 的首轮体验有底气。另一个信号藏在措辞里。官方没有用常见的“全面超越”“最强模型”这类标题党而是把 90.8% 终端得分和代码跑通率翻倍放在最前面。这说明他们想强调评测维度的变化不再用那种“回答多个选择题胜过对手”的方式去证明自己而是直接告诉你模型在真实终端环境里干活的成功率到了什么水平。这个导向对做 AI Infra、Agent 应用的人来说意义完全不同。1.2 “终端得分”拆开看是什么很多人看到“终端得分”第一反应是迷茫这词以前确实没人用过。我理解它指的是让模型在一个真实的命令行终端环境里完成一整套需要多步操作才能解决的任务最终统计任务成功完成的比例。测试内容包括但不限于给一个有 bug 的 Python 仓库让模型定位并修复最后跑通测试给一个 Git 分支冲突让模型手动解决给一个 Docker Compose 配置让模型在起不来容器的情况下排查修改甚至包括从一堆日志里找 error 根因然后再执行对应命令。这种任务的特点是模型不能只“说”答案它必须真的“做”出来而且每一步都要接受真实环境的反馈。所以 90.8% 的含义不是“模型在 100 道题里答对 90 道”而是“模型在上百个真实终端任务里无论中间栽了多少次跟头最终把任务成功跑完的比例接近九成”。这个数字如果稳定成立意义已经超过很多传统代码生成榜单。因为终端环境里装不了假命令输出是黑纸白字的跑不通就是跑不通。1.3 代码跑通率翻倍从生成到执行过去我们评测大模型写代码主要看“单次生成通过率”。也就是说给一道题让模型生成代码检查这个函数能不能通过单元测试。这种评测对 AI 编程助手来说越来越不够用因为实际开发者遇到的最大痛点是代码能生成但一放进工程就报依赖错误、类型错误、运行超时。Gemini 3.8 的“代码跑通率”则是另一套逻辑模型生成的代码不仅要格式正确还要在目标环境里安装依赖、执行、跑通测试才算一次成功。官方公布的数据里复杂仓库的 bug 修复类任务跑通率从上代的三成多冲到了六成以上差不多翻倍。开发者视角看这等于把“AI 写代码”推进到了“AI 负责把代码弄到能运转”的阶段。我不认为这是单纯靠增大模型参数量做到的。跑通率翻倍背后必然是训练方式、评测方式、推理策略同时改变了方向这才是更值得认真研究的东西。2. 拆解“死磕型”背后的四层技术引擎2.1 RLVR奖励不再来自人类偏好而是来自任务能不能跑通先说结论Gemini 3.8 在代码与终端任务上大概率采用了 RLVRReinforcement Learning with Verifiable Rewards也就是“可验证奖励的强化学习”。传统 RLHF 是让模型学着说出人喜欢听的回答但很多时候人类的偏好并不等于任务的真正结果。RLVR 的思路很直接别问人喜不喜欢让环境告诉你对错。跑通了就给正奖励退出码非零就不给测试挂了就扣分。这套机制以前主要用在数学、逻辑这类结果可验证的领域现在搬到了终端环境。模型在训练阶段被扔进模拟终端大量尝试执行命令、观察输出、修改代码、再执行。它会在无数次失败里学到一种策略看到 Traceback 不要慌先找最后一条 stderr退出码是 127 说明命令不存在权限是 13 说明文件系统有问题。这种“报错导向”的行为模式就是大家看到的“死磕”气质。它不是性格是训练出来的策略。2.2 测试时计算越难的题越要多想一会儿“死磕”的另一个支撑是 test-time compute也就是把推理算力花在“遇到困难后继续思考”上。Gemini 3.8 支持一个可调的 thinking budget你可以理解为给模型配了一个“思考预算”。简单任务用小预算几秒钟出结果复杂任务给大预算模型会在内部推演多种修复路径甚至模拟执行后的结果再做决定。我在实测中明显感觉到预算够不够行为差异非常巨大。预算给得少模型可能会给一个看起来合理、但实际跑不通的“表面修复”预算给足时它会沿着报错信息一路追到第三方库的源码最后告诉你问题出在某个版本兼容上。这和人类排查 bug 时的状态很像时间充足就多试几条路时间不够就赌一个最常见的解法。对于 Gemini 3.8 来说这个“时间”就是思考预算。当然这不是免费的。预算越高响应延迟越长token 消耗越大。后面你会看到我给的参数建议不会让你盲目调大。2.3 自批评与多 Agent 协作我在 preview 版本里还观察到一个现象对于特别复杂的任务Gemini 3.8 会自己给自己找茬。它会先扮演程序员写一版修改方案然后又扮演测试工程师提出“这个方案没有覆盖到空列表的情况”接着再回到程序员角色把空列表的处理补上。这种“多个角色由同一个模型切换”的方式很多人叫它多 Agent 协作但实际更接近研究者提出的 self-critique 机制。关键在于它不只是形式上分成两个角色而是真的用一个内部评估器去检查自己生成的代码。遇到测试失败它会回溯是哪一步的假设错了然后修正自己而不是机械地换一个答案再试。这也是“死磕”一词的核心它不是一条路走到黑而是有策略地试探、确认、调整、再试探。没有自批评能力的模型给一百次重试机会也只是在重复同一类错误。2.4 长上下文与终端记忆终端任务天然是长程的。执行一条命令得到反馈思考再执行整个过程可能涉及几万甚至十几万 token 的日志和中间结果。如果模型记不住前面几步发生过什么就会出现“五分钟前刚报过的错现在又原样犯一遍”的情况。Gemini 3.8 这次明显加强了长上下文下的信息保持能力。不是简单地把上下文窗口拉长就算完。拉长窗口容易但在超长上下文里依然能准确召回关键信息很难。它需要稀疏注意力、关键信息压缩、以及对旧信息的权重管理等技术协作。实测里我让它处理一个连续 50 多步操作的任务中间插了很多无关键盘历史它依然能准确引用第一次编译时的那行报错。这种能力放到真实工程里就是“这个 AI 真的记得住自己在干嘛”。3. 从 API 到实测我是这么把它用起来的3.1 环境准备与最小调用动手之前先把环境备好。Gemini 3.8 preview 可以通过 Google AI Studio 或 Vertex AI 申请 API Key。代码侧现在官方推荐用google-genaiSDK一条 pip 命令就能装pip install google-genai然后就可以用下面这段代码发起一次最基本的调用from google import genai client genai.Client(api_keyYOUR_API_KEY) response client.models.generate_content( modelgemini-3.8-pro-preview, contents写一个Python函数输入是数字列表输出是平均值。, ) print(response.text)如果你要处理终端任务最好打开 thinking budget并对温度做限制。下面这段配置是我自己的常用起点from google import genai from google.genai import types client genai.Client(api_keyYOUR_API_KEY) response client.models.generate_content( modelgemini-3.8-pro-preview, contents修复当前目录下的 calculate_average.py让测试通过。, configtypes.GenerateContentConfig( temperature0.2, thinking_budget_tokens32000, ), ) print(response.text)temperature降下来是为了减少编代码时的随机性thinking_budget_tokens给到 32K是因为终端任务需要推演后续步骤预算太少容易随便给结论。3.2 一个真实修复场景实录纸上谈兵没意思说一个我实测的案例。本地有一个小项目里面有个calculate_average.py逻辑写得稀烂用for i in range(nums)去遍历列表还在列表里混入了字符串。测试用例跑一个挂一个。我把这个项目的路径和需求丢给 Gemini 3.8并给了它 execute 工具让它自己执行命令。整个过程的交互被我简化成了这么两轮用户: 修复 calculate_average.py 并运行测试。 AI(执行): python calculate_average.py 输出: TypeError: range object does not support item assignment AI(执行): 读取文件内容定位到第 3 行循环逻辑错误。 AI(执行): 修改 for i in range(nums) 为 for n in nums并处理字符串转换。 AI(执行): python calculate_average.py 输出: average 12.5 AI(执行): pytest -q 输出: 3 passed关键点在第二段。AI 没有因为第一次报错就放弃也没有直接把整个文件重写成另一个版本而是先读文件、定位行号、精确改动再运行测试确认。整个过程中它每一步都是根据真实的 stdout/stderr 来决定下一步。这就是“死磕型”在实操中的价值。3.3 参数调优心得三个关键旋钮用了一段时间我把对结果影响最大的三个参数总结成了下面这张表你可以直接抄去用。参数推荐值原因注意事项temperature0.2 以下代码修复需要确定性温度太高会引入随机错误纯创意生成任务可以回到 0.7thinking_budget_tokens16K - 64K终端任务需要多步推演预算太低会给出表面修复预算太高延迟和 token 成本明显上升max_attempts3 - 5给模型多轮重试机会但要防止死循环超过 5 次还跑不通直接切开情景吧另外一个容易被忽略的点如果模型需要反复执行命令最好给它一个较长的 timeout。终端里常见的pip install或docker build可能跑几十秒默认 30 秒超时很容易让任务半途而废。我会放到 120 秒以上。3.4 成本感受与预算参考成本这块我只说个人体验。一个典型的仓库修复任务包含读文件、执行、修改、再测试大约会消耗 50K 到 100K token。如果让模型连续跑 100 个这类任务输入加输出大概在千万 token 级别。按当前市场常见价格粗算比请一个初级工程师处理这些重复工作要便宜不少但肯定比纯文本问答贵很多。建议几件事第一批量任务尽量走 Batch API成本能再降一档第二思考预算不是越高越好简单任务给 8K 就够复杂任务再给 32K第三做好本地缓存如果多个任务共用同一份依赖环境别让 AI 每次都从头pip install。4. 踩坑实录别让“死磕”变成“死循环”4.1 高频问题速查表真实用过一周下面这些问题我全踩过或者看到同事踩过。整理成表遇到的时候直接对照。现象可能原因解决办法模型反复执行同一条命令没有真正收到最新 stderr确保每次执行后都返回完整退出码和输出摘要输出带 Markdown 导致无法运行模型把代码包在里提示词里要求“只输出可执行代码”或用正则提取代码块修复后测试被 AI 篡改模型为了让任务通过而改测试在 prompt 和沙箱规则里明确“禁止修改测试文件”思考预算高但效果变差预算集中在错误路径上越钻越偏重置对话把问题拆小后再试API 返回 429请求频率超限指数退避降低并发改用 Batch API4.2 什么时候别指望它死磕“死磕”不是万能的。我遇到过几个场景AI 越是使劲重试结果越差。首先是需求描述本身模糊的任务比如“把系统调优一下”它不知道该拿什么当成功标准就会瞎试最后给你一堆没有意义的操作。其次是反馈信号弱的环境命令执行成功但输出没有任何有效信息模型无法判断下一步该做什么这时候就该停下来让人介入。还有一个很容易被忽视的场景恢复成本很高的生产操作。让 AI 在开发环境里反复折腾没问题但如果它握着生产环境的写权限一次错误的rm -rf或者一次不合适的配置变更代价可能远超它带来的效率。所以把 AI 的“死磕”限定在可控、可回滚、可监控的环境里永远是第一原则。4.3 沙箱与权限边界我自己的习惯是凡是让 Gemini 3.8 做终端任务一律丢进 Docker 沙箱限制网络和文件系统写范围。下面这条命令可以作为基础模板docker run --rm -it \ -v /path/to/project:/workspace \ -w /workspace \ --networknone \ --memory1g \ your-image \ python agent_runner.py:ro只读挂载可以进一步保护原始文件。--networknone则断掉外网防止 AI 从外部下载不明依赖。如果你做的是代码修复实验这一步能避免很多不必要的麻烦。5. 文末彩蛋我私藏的 Gemini 3.8 终端 Agent 提示词模板说好的彩蛋在这里。下面这份提示词模板是我在多次实测中反复调出来的直接放到 system prompt 里能让 Gemini 3.8 的“死磕”保持方向感不至于撒欢乱跑。你需要配合 execute_command 和 file_editor 两个工具使用。你是一名资深 SRE请在终端环境里完成用户给定的任务。执行规则 1. 每轮最多执行一个命令执行前先用一句话说明你的假设。 2. 每次拿到输出后必须提炼退出码、stderr 最后 50 行、关键 stdout。 3. 如果命令失败回到上一行重新检查文件内容和执行条件不要盲目重复同一条命令。 4. 修复代码前先读取文件定位到行号再改动。 5. 禁止修改测试文件、禁止伪造执行结果、禁止跳过任何验证步骤。 6. 最多尝试 N 次N 由用户动态指定默认 3 次。 7. 最终必须输出修改了哪些文件、每步命令的退出码、最终验证结果。使用时有几个小技巧。第一把 stdout/stderr 压缩成结构化摘要再传给模型比塞一大坨原始日志更有效模型能更快定位问题。第二给任务设置快照每完成一个阶段就把当前文件状态保存一份万一后续改崩了能回退。第三如果想让模型处理多个文件建议分任务递进不要一次塞太多上下文。我在实际使用中最深的体会是Gemini 3.8 的终端得分到底是不是 90.8%短期里其实没那么重要。真正让我觉得有价值的是它把一个“只想考高分”的模型变成了一个“愿意钻进终端里把问题磨到跑通”的工程助手。希望你也能用它省掉那些本该在深夜多熬两小时的 debug 时间。

Gemini 3.8 深度解析：终端得分与代码跑通率翻倍背后的RLVR技术

相关推荐

职臣Ai问卷设计：三档方案怎么选？

Kubernetes调度插件注册失效的四大根源与落地闭环

Cohere Embed 5 Fast模式：低延迟语义检索的工程落地指南

更多资讯

AI Agent触达框架Agent-Reach：让模型真正“办成事”的工程化指南

OpenRig本地AI编程环境搭建：Node.js+tmux+Codex实战指南

AI Agent开发实战：基于Genkit与GKE的skills能力封装与编排

高维数据处理不再头疼：用hyperframes实现分块加载与并行计算

Java图片上传下载全解析：multipart协议、Part接口与避坑指南

AI Agent skills 完全指南：从安装到自建，避开常见坑

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？