来源：市场资讯
（来源：姜篇51CTO技术栈）
“pretty spot-on.”
Jeff Dean：如果按照Agent处理长时间编程任务的能力来衡量，AI已经接近初级工程师，这个判断基本准确。
一年前，Jeff Dean公开预测，AI的编程能力已经达到初级工程师水平。
在最近的一场访谈，主持人又把这个问题递到他面前：一年过去，这句话还成立吗？
Jeff Dean没有收回这个判断。
他觉得模型处理复杂任务的速度，甚至比自己预想得更快。
备注：Jeff Dean，他在Google工作超过25年，参与过MapReduce、Bigtable、TensorFlow和TPU等项目，如今担任Google首席科学家，共同领导Gemini相关工作。
代码越来越容易生成之后，Jeff Dean问出一个关键问题：工程师能否看见系统里那个最值得动手的地方？
以下为访谈内容，我们进行了翻译与整理。
Jeff Dean回应AI是否已经达到初级工程师水平
AI已经追上初级工程师，复杂任务进步得更快
2025年，Jeff Dean曾把AI的编程能力放在“初级工程师”这个位置。
一年后，他发现模型在Agent任务上的进展比预想更快。
Agent可以读取代码库，寻找相关文件，修改实现，再根据编译错误和测试结果继续调整。
任务边界足够清楚时，它能够离开开发者的键盘独立运行一段时间。
Jeff Dean：有些Agent任务已经可以持续几天甚至几周。它们能够尝试用另一种语言重写软件，追求更好的性能或安全属性。
把这些能力放进团队，最先变化的是执行速度。
过去要交给初级工程师几天的依赖升级、接口迁移和测试补齐，现在可以先让Agent跑一遍。工程师回来后面对的不再是空白文件，而是一份已经改过、测试过，也可能在某一步走偏的结果。
写出第一版dome越来越容易。能否判断这版代码碰对了问题，开始拉开新的差距。
Jeff Dean谈Agent未来可以连续运行数天甚至数周
Google搜索的一次提速，只改对了一个地方
主持人把时间拉回到2001年。
当时，Google搜索索引主要放在硬盘上。Jeff Dean和同事重新算了一遍硬件资源，发现一个此前并不成立的条件已经成为现实：所有搜索索引可以装进Google服务器的内存。
他们很快上线了一个在内存中工作的搜索版本。
磁盘读取不再挡在查询链路上，Google搜索由此获得了明显的速度提升。
他们没有继续堆代码优化硬盘读取。旧架构依赖的前提已经过时，换掉前提比修补局部更有效。
类似情况在今天的项目里并不少见。
一个接口越来越慢，团队可能连续优化业务函数，最后才发现大部分时间耗在跨区域网络请求上。一个Coding Agent消耗大量Token，原因也可能不在模型，而在每一轮都重复传入整份日志和无关文件。
代码需要改。动手之前，先确认系统究竟卡在哪里。
Diana回顾Google把搜索索引从硬盘搬进内存的经历
每人每天3分钟语音，逼出了TPU
2013年前后，Google的深度学习语音识别已经取得不错的效果，计算成本却高得惊人。
Jeff Dean做了一次估算：如果每位Google用户每天只使用3分钟语音识别，处理这些请求就需要把Google的服务器规模扩大一倍。
继续堆通用服务器，产品也能上线，代价很难长期承受。Google后来转向专用硬件，这成为第一代TPU的起点。
开发者可以照着做一遍：架构讨论开始之前，先把账算出来。
一次Agent任务会调用多少轮模型？每轮重复发送多少上下文？并发扩大100倍后，瓶颈会落在GPU、数据库连接、网络带宽，还是第三方API限额？
这些数字不用等到系统上线后再从账单里找答案。简单的估算，往往能提前否掉一条昂贵的路线。
3分钟语音识别将迫使Google把服务器规模翻倍
高手寻找10倍、100倍的改进机会
主持人问Jeff Dean，年轻开发者怎样找到下一个像TPU一样重要的问题。
Jeff Dean给出的回答里有一句很短的话：
“one or two orders of magnitude better.”
Jeff Dean：观察正在解决的问题和遇到的瓶颈，换一种思路，有机会获得一个甚至两个数量级的提升。
一个数量级约等于10倍，两个数量级约等于100倍。
这类收益很少来自把同一段代码再写一遍。它通常要求工程师重新检查数据流、存储位置、通信成本和计算方式。
例如，一个查询接口的P95延迟达到2秒。继续压榨某个函数，也许只能省下20毫秒。
链路追踪却可能显示，70%的时间都在等待一个跨区域服务。把数据放回同一区域，或者在正确的位置增加缓存，延迟才可能大幅下降。
AI让局部实现变快后，这种判断更加值钱。
Agent可以同时给出几个优化版本，开发者仍要决定，当前需要的是重写函数、调整数据路径，还是删掉整层调用。
Jeff Dean建议开发者寻找能够带来数量级提升的瓶颈
一套Agent系统，模型只占其中一块
访谈聊到Context Engineering时，Jeff Dean把模型放回了整个系统。
“the model is really only one piece.”
Jeff Dean：模型只是整体系统的一部分。系统还要让它检索信息、使用工具、保留相关记忆，并把任务拆成可以执行的步骤。
放到开发现场，任务链会立刻变长。
让Agent修复一次重复扣款，它首先需要找到相关服务，读取调用日志，确认数据库约束，再进入能够复现问题的测试环境。
它还需要知道哪些文件允许修改，哪些数据只能读取，执行到哪一步必须等待人工确认。
其中任何一环缺失，模型都会表现得像“突然变笨”。
问题可能来自上下文里混入了旧文档，也可能来自工具没有返回完整日志，或者测试根本没有覆盖那条异常路径。
训练基础模型需要庞大的算力。Context Engineering的门槛低得多。普通团队拿到模型API，就能改进检索、工具、记忆和验证流程。
模型排名由实验室决定。Agent进入自己的代码库以后能走多远，很大一部分取决于这些工程工作。
Jeff Dean谈模型、检索、工具与上下文的关系
Agent跑到第40步，为什么开始偏航
主持人提到一个开发者很熟悉的现象：
Agent前十步表现不错，运行到第30步、第40步，结果开始变得不稳定。
Jeff Dean：我长任务会把模型逐渐带到训练经验较少的区域。它离熟悉的任务分布越远，出错概率越高。前面一次看似很小的误判，也可能在后续工具调用中不断放大。
他的办法包括给模型补充Skills和提示，让多个Agent尝试不同方案，再安排一个模型评估中间结果。已经偏离目标的路线要尽早停掉。
开发团队还可以把长任务切成几个检查点。
完成代码检索后，先提交修改计划；改完核心逻辑后，先跑最小测试；涉及数据库和外部接口时，停下来等待确认。每一段都留下输入、工具调用和结果，失败后才能从最近的检查点继续。
一句更长的Prompt撑不起长任务。Agent还需要反馈、验收和停止条件。
Jeff Dean分析长时间运行的Agent为何逐渐偏航
Jeff Dean建议：去做AI成功率只有1%的难题
访谈后半段，主持人问创业团队怎样找到基础模型暂时覆盖不到的机会。
Jeff Dean给出了“1%法则”：
“0% or 1% of the time, not 20%.”
Jeff Dean：寻找模型目前只有0%或1%成功率的问题，不要把壁垒押在模型已经能完成20%的事情上。
如果模型已经偶尔能够完成一项任务，增加训练数据、扩大模型规模或改进工具后，这项能力很可能迅速提高。
只在模型外面包一层简单界面，下一次升级就可能抹掉产品的差异。
成功率只有1%的问题通常更麻烦。
它可能依赖企业内部数据，需要跨多个系统执行，结果还要经过真实业务反馈才能判断。
通用模型可以总结一份公开代码。让它根据公司历史事故、内部日志和服务依赖，找到一次线上抖动的根因，再提交可以安全灰度的修复方案，难度完全不同。
这类任务不会因为换一个更大的模型立即解决。开发者要补齐数据接口、工具权限、评测集和反馈闭环，产品壁垒也会落在这些地方。
Jeff Dean建议开发者寻找模型当前成功率只有0%或1%的问题
Jeff Dean在Google做过的几件大事，有一条相似的路径。
先算清楚系统正在付出什么代价，再找到限制规模和性能的那个环节。搜索索引放进内存如此，TPU的起点也是如此。
AI把代码实现的成本继续压低，工程师可以把更多时间放在问题选择上：哪一处改动能让系统产生数量级提升，哪些信息应该进入模型上下文，长任务怎样获得反馈，失败以后如何停止和恢复。
打开一个项目，与其再收藏十条Prompt，不如先挑出一条最慢、最贵或者最不稳定的链路。把耗时、调用次数、Token和失败位置算明白，再决定让Agent改哪一层。
代码会越写越快。能在一堆局部问题中找到那个值得解决的瓶颈，仍然需要工程师。
热门跟贴