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 应用能不能真正落地的关键。如果你刚接触这个领域我的建议是别追着热点跑先挑一个真实场景把最小的流程跑通把工程细节补扎实。范式升级不是别人讲给你听的是你在一遍遍调试、一轮轮改进中自己感受出来的。