2010 年前后，Jeff Dean 在谷歌参与的很多架构讨论，核心都是“怎么让更大的模型在更多数据上跑得更稳”。十几年过去，当“AI 的下一次范式升级”再次成为访谈关键词时，大家真正想问的问题已经不是模型还能变大多少，而是：当我们手里的模型越来越聪明，人的工作方式、系统架构、评估标准，到底哪些要跟着变？
这是一次值得认真拆解的访谈。不是因为 Jeff Dean 说了什么不可辩驳的结论，而是因为这类判断背后，藏着一套关于“AI 应该往哪里走”的长期思考方式。如果你是一个正在用大模型做应用的开发者、产品经理，或者刚刚开始学习 AI 工程实践的人，理解这套思考方式，比记住几个新名词有用得多。
我更愿意把这次访谈里的核心信息，理解成一句话：下一轮 AI 升级，重点不是模型单点能力的军备竞赛，而是把模型放进真实系统里，让它能稳定、可控、可评估地解决复杂问题。这个判断看起来不刺激，但它会直接改变你接下来怎么设计 prompt、怎么选模型、怎么搭 Agent、怎么做评测。
1. 这次范式升级，真正变的是什么
很多人在讨论 AI 范式升级时，第一反应是“模型又变强了”。但从工程视角看，模型能力只是其中的一块拼图。这次升级真正变化的，是 AI 从“单次问答工具”走向“可执行复杂任务的系统组件”。
1.1 从“模型能做什么”到“系统能跑什么”
过去两年，大家评测模型的方式很直接：丢一个难题，看它能不能答对。但真实应用里，模型从来不是孤零零存在的。它要读文件、调接口、写数据库、跟其他 Agent 协作，还要在出错时给出可恢复的路径。这时候，“模型能不能答对”只是起点，“整个系统能不能稳定跑起来”才是终点。
Jeff Dean 在访谈里反复强调的“多模态”和“Agent”，其实都指向同一个趋势：模型不再是一个回答问题的东西，而是变成系统里的一个“行动者”。它可以理解图片、调用工具、规划步骤、执行动作，然后根据结果继续调整。这不是一个功能点，而是架构级别的变化。
这也是为什么市面上突然出现了那么多关于 AI Agent、AI 编程、AI 应用开发的讨论。大家发现，一旦模型要真正干活，问题就不再是“模型懂不懂”，而是“系统稳不稳”。你给 Agent 安排一个任务，它能不能拆解成步骤？调工具失败了怎么办？中间结果要不要人确认？这些问题，才是范式升级后真正避不开的部分。
1.2 从单点能力到整体协作
过去做 AI 应用，通常是“模型负责生成，代码负责拼接”。现在更像是在组织一个小团队：一个模型当规划者，另一个模型当执行者，还要有工具、有记忆、有状态管理。整体效果不取决于最强那个模型，而取决于所有环节能不能顺畅协作。
用工程里的老话讲，就是“木桶效应”。模型 A 的推理能力再强，如果工具调用不规范、上下文管理混乱、失败重试策略缺失，整个任务一样跑不通。所以你会看到，最近圈子里讨论 AI 应用开发时，重心慢慢从“哪个模型强”转移到“怎么设计 Agent 流程、怎么管理上下文、怎么做可观测性”。
这不是说模型能力不重要了。模型依然是地基，但地基之上，还需要一套完整的工程结构。范式升级的核心，是行业终于开始认真对待“模型之外的那部分”。
2. 为什么过去那套优化思路已经不太够用
既然范式在变，那过去大家熟悉的一套优化思路，也必须跟着调整。否则很容易出现“模型很强，应用却很弱”的落差感。
2.1 参数规模不再是唯一杠杆
过去几年，大家对模型升级的直觉是“参数更大、效果更好”。这在实验室里成立，但到了真实产品里，参数不再是唯一杠杆。你会发现，同样一个模型，prompt 写得好不好、上下文给得够不够、工具接口设计得顺不顺，对最终结果的影响往往比“换一个更大的模型”更明显。
Jeff Dean 的访谈里提到，很多研究开始关注“如何让模型更高效地利用已有能力”，而不是一味堆规模。这背后的信号很清楚：当模型能力到达一定水位，工程层面的优化收益，会逐渐超过继续扩大参数带来的收益。
这对普通开发者来说其实是好消息。因为它意味着，你不需要等“最强模型”才能做事情。把现有模型的边界摸清楚、把上下文策略优化好、把工具调用链路设计稳，已经能做出很有体感的应用。
2.2 推理成本、上下文和工具调用成为新瓶颈
范式升级之后，真正卡住大家的有三样东西：
- 推理成本：模型可以很聪明，但一次任务要调几十次接口，成本立刻上来了。所以大家开始研究怎么缓存、怎么缩小输入、怎么用便宜模型做初筛。
- 上下文管理：Agent 跑得越久，上下文越长，费用越高，还容易让模型“忘记”开头的内容。怎么截断、怎么摘要、怎么保留关键信息，变成了日常工程问题。
- 工具调用可靠性：模型说它要调某个工具，参数格式对不对？返回结果怎么解析？异常怎么兜底？这些过去被认为“很工程”的问题，现在直接决定了 Agent 能不能用。
换句话说，范式升级后，AI 工程实践的重心，从“怎么让模型更聪明”变成了“怎么让模型体系更可控、更便宜、更可靠”。如果你还在用“模型能力不够”来解释所有问题，可能已经错过了真正的瓶颈。
3. 给普通开发者的落地路线图
理解了范式变化，下一步就是怎么落地。我的建议很朴素：不要一上来就追求复杂 Agent，先把最小可用流程跑通，再逐步加工程化能力。
3.1 第一步：先把一条任务完整跑通
选择一个小而具体的任务，比如“从一篇文章里提取要点并生成结构化摘要”。先把这条链路跑通，不要中途想着加 Agent、加多模态、加工具调用。
具体可以按这个顺序验证：
- 准备一份格式规范的输入样本。
- 用模型接口直接生成输出。
- 人工检查输出是否符合预期。
- 记录输入、输出、耗时和成本。
这个阶段的目标不是做得完美，而是确认“模型 + 基础代码”这条路能走通。很多人在这里会犯一个错误：还没验证单次效果，就急着上批量、上并发，结果问题全被放大。
建议：第一轮只用一条样本，跑通全流程。确认输入格式、输出解析、日志记录都正常后，再逐步扩展。
3.2 第二步：做输入和输出边界测试
单次跑通之后，不要急着说“搞定”。你需要系统性地测试边界情况。
- 输入为空怎么办？
- 输入超长怎么办？
- 输入格式不规范怎么办？
- 模型返回格式不符合预期怎么办？
- 网络超时或接口报错怎么办？
这些边界情况，才是真实使用中真正消耗时间的地方。你可以把测试用例分成正常、边缘、异常三类，每类准备几条样本，然后观察系统的表现。
实际经验是，很多 AI 应用“开发一周、调试一月”，核心都在处理边界情况。模型本身的输出充满不确定性，工程上只能通过输入约束、格式校验、重试机制、降级策略来兜底。这一步不可跳过。
3.3 第三步：加上日志、重试、权限和版本管理
从“能用”到“能长期用”，中间差的是工程化能力。
- 日志：记录每一次请求的输入、输出、耗时、成本、错误信息。没有日志，出了问题就无从排查。
- 重试：接口调用失败时，要区分“可重试”和“不可重试”的错误。网络超时可以重试，参数错误不需要重试。
- 权限：如果 Agent 要操作文件、数据库或第三方服务，必须有清晰的权限边界。不能让模型生成的命令直接拥有最高权限。
- 版本管理：模型版本、prompt 版本、代码版本都要管理起来。否则你很难判断一次效果变化，到底是模型升级还是代码改动导致的。
这四件事听起来都是老生常谈，但放到 AI 应用里，因为模型行为的不可预测性，它们的重要性被放大了。一次模型输出格式变化，就可能让整个批量任务中断；一次 prompt 微调，就可能让结果质量发生明显波动。没有日志和版本管理，这些问题都只能靠猜。
3.4 第四步：从单机脚本走向服务化
当流程稳定后，可以考虑把功能封装成服务。这里会涉及几个常见决策：
- 同步还是异步：耗时长的任务，尽量走异步队列，避免接口超时。
- 单模型还是多模型：复杂任务可能需要不同模型分工，但要设计好路由逻辑。
- 要不要引入 Agent 框架：如果任务需要多步推理和工具调用，可以考虑使用成熟的 Agent 框架。但框架会带来额外的抽象和学习成本，建议先评估自己的任务复杂度。
这步没有统一答案，取决于你的场景和资源。我的建议是：能不上框架就不上框架，先把核心逻辑写清楚；等流程确实复杂到难以维护时，再考虑引入框架抽象。
4. 最容易翻车的并不是模型能力，而是工程化
接触过不少 AI 应用项目后，我发现一个规律：真正让项目翻车的，往往不是模型不够聪明，而是工程细节没做好。这些问题看起来很小，但在 AI 应用里会被放大。
4.1 排查问题，先按链路顺序来
当 AI 应用出现问题，很多人第一反应是“调 prompt”。但 prompt 只是整条链路的一个环节。我建议按这个顺序排查：
- 先看现象：是报错、卡住、无输出，还是输出质量差？不同现象对应的排查方向完全不同。
- 再看输入：输入内容是否符合预期？编码对不对？上下文是否被截断？很多“模型变笨了”的假象，其实是输入上下文被截断导致的。
- 再看环境：依赖版本是否有变化？接口地址是否配置正确？权限是否足够？环境问题经常被忽略，但影响往往很大。
- 再看参数：温度、批量数、并发数、超时时间是否合理？参数设置不合理，会直接导致结果不稳定。
- 最后看工具边界：模型能力是否支持这个任务？当前版本是否有已知限制？工具调用是否超出了模型的理解范围？
这套排查顺序，可以帮助你快速缩小问题范围。不要一上来就怀疑“模型不行”，很多时候问题出在更基础的地方。
4.2 容易踩坑的三个细节
除了排查链路，有三个细节特别容易踩坑。
第一，上下文被静默截断。当输入超过模型窗口限制时，很多框架会静默截断开头或中间部分。模型不会报错，但输出质量会明显下降。关键是：这个坑很难发现，因为它不产生报错。解决办法是在日志里记录实际发送的上下文长度，并且定期检查。
第二，批量任务没有失败隔离。一个任务失败，不应该影响整个批量任务。常见做法是加入“失败后重试”“连续失败后暂停”“失败任务单独记录”等策略。否则一次临时接口抖动，就可能让整夜运行的批量任务全部白跑。
第三，输出格式不够稳定。模型输出 JSON 时，偶尔会在 JSON 前加一段解释文字，或者用中文引号替代英文引号。解析时如果不够健壮，就会导致任务失败。建议在解析前加一层“提取 + 清洗”逻辑，同时把真实输出异常记录下来，用来持续优化 prompt。
这些坑都不难解决，问题在于它们不显眼。你只有真正跑过一次批量任务，才能体会到“单次成功”和“持续稳定”之间的巨大差距。
提醒：如果任务是批量处理，建议先跑 5 到 10 条，确认稳定后再跑全量。不要拿全量数据当测试集。
5. 范式升级之后，值得长期关注的三件事
回顾 Jeff Dean 访谈里的讨论，再结合当前 AI 工程实践的变化，我认为有三件事值得长期关注。它们不是短期热点，而是会持续影响行业走向的关键变量。
5.1 多模态不能只停留在“识别图片”
访谈里花了大量篇幅讨论多模态。很多人对多模态的理解，还停留在“模型能看懂图片”这个层面。但真正的价值，在于多模态让 Agent 能够处理更多真实世界的信息。
比如，一个 Agent 可以同时读取产品图片、说明书 PDF、用户评论文字，然后综合这些信息给出决策建议。这种能力不是简单的“图像识别”，而是跨模态的信息融合和推理。它会让很多原本需要人工参与的流程，第一次变得可以自动化。
对普通开发者来说，值得关注的是多模态输入的标准化问题。图片怎么压缩、PDF 怎么解析、视频怎么抽帧，这些工程细节会直接影响多模态应用的效果和成本。提前积累这些经验，比等待“更聪明的多模态模型”更有实际意义。
5.2 Agent 的核心不是“自动化”，而是“可控的自动化”
Agent 是这次范式升级里最热门的话题，但也是最容易被误解的概念。很多人觉得 Agent 就是“你把任务交给它，它自己搞定一切”。实际落地时，这个想法往往会碰壁。
真正可靠的 Agent 设计，通常包含三层控制：
- 目标控制：任务的目标、约束和验收标准必须清晰。
- 过程控制：关键步骤需要人确认，或者至少需要日志可回溯。
- 结果控制：输出需要校验和降级方案，避免错误结果直接对外。
换句话说，Agent 不是“无人驾驶”，更像是“自动辅助驾驶”。它可以处理大量重复环节，但遇到关键决策时，最好还有人参与。这里没有统一标准，但有一条经验值得参考：一开始，宁可让 Agent 多问人几次，也不要让它自作主张。等你对它的行为边界足够了解后，再逐步放开权限。
5.3 评测会越来越重要，但也会越来越难
范式升级之后，评测会成为最大的瓶颈之一。
过去评测模型很简单：准备一批标准题，看正确率。但现在，模型要执行复杂任务、调用工具、处理长上下文，评测维度一下就复杂了。一个 Agent 可能步骤都对，但最终结果差之毫厘；也可能结果正确，但过程绕了远路。
目前业内并没有一套公认的评测标准。很多团队还在用“看几个样例 + 主观打分”的方式。这在早期可行，但一旦任务变多、模型版本迭代变快，就必须建立更系统的评测方案。
建议从三个角度入手：
- 任务成功率：任务最终完成的比例。
- 关键步骤合规率：是否遵守了预设的规则和流程。
- 成本与耗时：完成任务消耗的 token 和时间。
只有把评测体系建立起来，你才能回答“新模型到底要不要升级”“prompt 调完到底有没有变好”这些问题。否则，所有优化都像在黑暗中摸索。
写在最后：范式升级不是等来的，是做出来的
Jeff Dean 的访谈之所以值得反复看，不是因为它预测了某个具体技术会在哪一年爆发，而是因为它提供了一种思考 AI 进化的方式：真正的升级，从来不是“某个模型突然变强了”，而是“整个系统、工具链和人协作的方式，一起发生了改变”。
这轮范式升级里，模型、Agent、多模态、应用开发都会持续演变。但有一件事不会变：把模型用好，永远需要工程能力。理解输入输出边界，设计稳定的流程，记录日志，设计评测，做好异常兜底——这些看起来不那么性感的工作，才是决定一个 AI 应用能不能真正落地的关键。
如果你刚接触这个领域，我的建议是：别追着热点跑，先挑一个真实场景，把最小的流程跑通，把工程细节补扎实。范式升级不是别人讲给你听的，是你在一遍遍调试、一轮轮改进中，自己感受出来的。
