AI圈每隔一段时间就会出现一个热词参数规模、Scaling Law、多模态、Agent。当“范式升级”被反复用来描述每一次版本更新时这个词的分量反而被稀释了。所以当看到 Jeff Dean 谈“AI的下一次范式升级”时第一反应应该是先停下来想一个问题为什么他能谈、为什么他谈的“范式升级”值得认真听。Jeff Dean 不是普通的技术布道者。作为 Google 首席科学家、Google Research 高级研究员他同时横跨分布式系统和机器学习两个世界。早年参与构建 MapReduce、BigTable、Spanner推动了 Google Brain 的建立又深度参与过 TensorFlow、Transformer 等一系列工作的演进。这意味着他看 AI 的方式不是单一视角而是“模型 系统 工程 产品”的整体视图。他从不说“某个功能很厉害”他更在意的是“这套能力的边界在哪里、靠什么系统支撑、能沉淀成什么基础设施”。这篇文章想做的事情不是复述某次访谈的字幕而是把 Jeff Dean 近年在各类公开访谈和演讲中传递的方向性判断整理出来结合一线开发者的视角回答一个实际问题当大模型从“预测下一个 token”走向“理解世界并执行任务”应用开发者应该提前做哪些准备文章会先建立一段 AI 范式演进的时间参照系再拆解范式升级的五个技术观测点然后用一个最小 Agent 示例说明“对话到执行”的差异最后给出工程挑战、常见误区和行动建议。如果你正在做大模型应用、Agent 或 AI 原生应用这篇内容值得收藏后细读。1. 为什么 Jeff Dean 的判断值得认真对待很多人以为 Jeff Dean 在 Google 的角色就是“技术把关人”实际上他更像是一个连接器把大规模系统、机器学习研究和产品落地焊在一起。这在 AI 领域非常少见。纯算法研究者容易忽视工程的约束纯工程团队又容易对模型能力的变化不敏感。Jeff Dean 的独特之处在于他不需要在这两者之间切换因为他的判断框架天然同时考虑两者。他在公开分享中反复强调过一个观点AI 的下一次进步不只是模型规模的扩大而是模型学会更复杂的行为能力。这句话背后的含义是规模只是必要条件不是充分条件。过去几年大家熟悉的是“把模型做大、数据喂多、涌现能力”但下一步的关键在于模型如何把能力转化为可依赖的行动比如规划、调用工具、多步推理、自我纠错。这恰恰是应用开发者最关心的方向。因为模型能力再强如果无法稳定地完成任务、无法被工程体系约束、无法被评测和监控它就很难进入生产环境。Jeff Dean 关注的不是“模型还能生成什么”而是“模型在真实任务中还能不能可靠地工作”。从公开访谈来看他把这个方向视为大模型从信息工具升级为行动系统的重要转折。另一个值得关注的原因是时间节点。大模型已经走过了概念验证期行业正在进入“规模化落地前夜”。在这种阶段真正有价值的信息不是某个模型又刷了多少分而是基础设施、研究方向和产品形态会往哪里走。Jeff Dean 的公开表达往往代表了 Google 内部一个相当有分量的判断视角值得把它当作行业风向标来读。2. 先建立参照系AI 范式演进的四个阶段要理解“下次范式升级”先得知道自己站在哪一阶段。AI 领域过去七十年的演进大体可以分成四个阶段。每进入下一阶段前面阶段的思路并没有消失而是变成了新系统的子模块。第一阶段规则与专家系统。这一阶段的核心思路是“人工写规则”。人把专家的经验翻译成 if-else让计算机按照规则执行。代表性成果是上世纪七八十年代的专家系统比如医疗诊断系统 MYCIN。它的优点是行为可解释、确定性强缺点是规则覆盖不了真实世界的无穷变化一旦遇到规则之外的输入系统直接失效。第二阶段深度学习。2012 年 AlexNet 在 ImageNet 上的突破标志着深度学习时代到来。这一阶段的核心变化是“特征不再靠人设计而是由模型自动学习”。卷积神经网络、循环神经网络、注意力机制先后登场。与传统规则系统相比深度学习在图像、语音、自然语言等感知任务上取得了质的飞跃但它仍然高度依赖标注数据而且模型所能完成的任务边界仍然比较狭窄。第三阶段预训练大模型。2017 年 Transformer 架构出现后预训练加微调成为主流。先在海量无标注数据上训练基础模型再用少量数据对齐到具体任务。GPT、BERT、Gemini 等都是这一范式的产物。这个阶段最大的变化是“一个模型通过提示词就能适应多种任务”不再需要为每个任务单独训练模型。能力涌现、上下文学习、指令跟随都是在这个阶段被广泛观察到的现象。第四阶段从预测走向行动。这正是 Jeff Dean 谈到的“下一次范式升级”所在的位置。模型的职责不再局限于生成文本或回答提问而是进入真实任务流程理解用户意图、拆解步骤、调用外部工具、读取反馈、修正计划、完成任务。这就是当前行业谈论 Agent 的底层逻辑。阶段核心机制代表方向能力边界主要瓶颈规则系统人工规则推理专家系统能处理封闭场景无法泛化规则爆炸深度学习自动特征学习CNN、RNN、大型监督模型感知任务表现突出依赖标注任务单一预训练大模型海量语料预训练提示词适配GPT、BERT、Gemini通用语言理解与生成缺少规划与行动能力智能体系统模型推理工具调用任务执行Agent、多模态系统可执行多步真实任务可靠性、成本、评测与安全判断一个方向是不是“范式升级”不是看它是否换了模型架构而是看它的核心机制是否发生了改变。从这一标准看从对话到行动确实具备范式升级的典型特征模型的输入输出不再只是文本而是包含工具调用、环境反馈和任务状态系统的设计目标不再只是“生成得好”而是“任务完成得好”。3. 访谈核心信号从“预测下一个 token”走向“理解与执行”结合 Jeff Dean 近两年的多次公开访谈和演讲可以提炼出几个反复出现的关键信号。这些信号不是孤立的而是相互支撑共同描画出“下一阶段 AI 系统”的大致轮廓。信号一模型必须从模式匹配走向推理与规划。Jeff Dean 多次提出大模型不能仅仅停留在“根据前文预测下一个词”的层面而是要具备更深层的推理能力。模式匹配可以让模型在常见问题上表现优秀但面对未见过的复杂问题模型必须能够分解问题、建立中间步骤、逐步验证。这正是思维链、推理时计算这些方向受到重视的原因。信号二原生多模态是必经之路。Google 近两年推出的 Gemini 系列核心思路就是原生多模态而不是把文本、图像、音频模型简单拼接。Jeff Dean 在相关访谈中传递的观点是真实世界的信息本身就是多模态的模型如果只能处理文本就难以真正理解世界、难以处理需要跨模态理解的任务。信号三长上下文与记忆机制。对话窗口是短期记忆真正的智能系统需要长期记忆。Jeff Dean 关注的不只是“模型能读多长的文本”还包括如何让模型在长时间的任务周期内保持状态、跨会话保持一致。信号四Agent 是模型能力的放大器。跟许多访谈者一样Jeff Dean 认可 Agent 的重要性。当模型可以调用搜索、代码解释器、数据库、外部 API 时它就不再只是一个“会说话的模型”而是变成一个能处理任务的系统。这个转变的核心是把模型能力接入结构化工具让模型成为系统的大脑。信号五可靠性与评测必须同步升级。模型能力越强不可控的风险就越大。Jeff Dean 在不少公开场合强调过负责任 AI 和评测体系建设。下一阶段的评测不能只关注“单轮问答准确率”而要关注端到端任务成功率、错误恢复能力、安全边界遵守情况。综合这些信号可以看到Jeff Dean 描述的“下一次范式升级”并不是某一个单独的技术突破而是一条组合路径更强的推理能力 原生多模态理解 更长的记忆 Agent 行动能力 更可靠的评测体系。这条路径对应用开发者最大的影响是研发焦点正从“提示词工程”转向“系统设计与工程约束”。4. 范式升级的五个技术观测点如果不想把“范式升级”停留在概念层面可以从以下五个技术方向持续观察。它们既是模型研究的核心问题也是应用开发者在选型和架构设计时需要关注的关键点。4.1 推理时计算Test-Time Compute过去算力主要投入到训练阶段模型训练完就固定了。而现在一个明显的趋势是把更多算力放在推理阶段让模型在回答复杂问题前“多想一会”。思维链、自我一致性、多轮反思等方法本质上都是把推理时计算变成一种可扩展的能力。对开发者的意义延迟和成本计算方式会发生变化。以前一个请求的耗时基本固定现在则可能因为模型内部“思考”而大幅波动。做产品设计时必须为这种波动预留空间比如使用异步任务、流式输出、超时控制。4.2 函数调用与工具使用Agent 的基石不是“让模型自由发挥”而是“让模型通过结构化接口调用外部工具”。函数调用Function Calling定义了模型输出与程序执行之间的桥梁。模型输出一个结构化的 JSON包含函数名和参数代码解析后执行真实操作再把结果返回给模型。对开发者的意义工具接口的设计直接决定 Agent 的效果上限。接口粒度太粗模型无法精确控制接口粒度太细模型容易在组合时出错。这一块值得像设计 API 一样认真对待。4.3 多智能体协作单个模型处理复杂任务时上下文容易混乱、职责容易模糊。多智能体系统把不同角色拆成独立 Agent比如规划者、执行者、检查者各自维护自己的上下文通过消息协作完成任务。对开发者的意义多智能体不等于更高智能它只是在特定场景下更容易工程化。拆分得好职责清晰、可插拔、可监控拆分不好消息流转复杂排查问题会非常痛苦。4.4 持续学习与外部记忆模型参数不可能频繁更新所以持续学习更多体现在系统层面。比如用向量数据库保存历史交互用缓存保存高频问题的答案用外部知识库补充模型的实时信息。模型本身不是记忆体系统才是记忆体。对开发者的意义做 Agent 产品时不要在模型参数里硬塞知识而是要考虑“记忆放哪里、怎么写入、怎么过期、怎么评价记忆质量”。这部分是 AI 工程化最容易出彩也最容易埋坑的地方。4.5 对齐、安全与权限控制当模型可以调用工具、执行操作时对齐和安全问题从“言论层面”升级到“行动层面”。一个错误的 SQL、一次越权的 API 调用都可能造成真实损失。红队测试、沙箱环境、最小权限、人工审批这些原本属于后端工程的方法正在成为 Agent 系统的基础设施。对开发者的意义不要把安全方案放在最后再加。Agent 上线前先设计好工具权限边界、操作审计日志、异常拦截机制否则后续补安全会把架构改得很别扭。5. 从对话到 Agent落地开发者如何接住这波变化为了更具体地看到“从预测到行动”的变化这里用一个最小示例演示 Agent 的核心工作方式。假设我们要做一个“查天气并给出穿衣建议”的 Agent传统对话系统只需要调用一次大模型而 Agent 需要在多个步骤间切换。5.1 调用大模型的基础代码以 OpenAI 兼容接口为例通过 HTTP 请求完成一次对话import requests import json def chat_with_model(messages, api_key, base_urlhttps://api.openai.com/v1): url f{base_url}/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: gpt-4o-mini, # 以实际可用模型为准 messages: messages, temperature: 0.7 } resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content] # 单轮对话 messages [ {role: system, content: 你是一个贴心的生活助手。}, {role: user, content: 今天北京适合穿什么} ] print(chat_with_model(messages, api_keyYOUR_API_KEY))这个代码只能处理最简单的对话。模型没有实时天气数据只能凭训练知识回答严格说这还只是“预测下一个 token”。5.2 引入工具调用的 Agent 示例要让模型真正“执行任务”需要把天气查询封装成函数并让模型学会在合适的时候调用它。这里给出一个简化版实现只保留核心逻辑import requests import json # 1. 定义工具函数 def get_weather(city: str) - str: 模拟查询天气真实项目中替换为天气服务 API # 注意这里使用模拟数据是为了演示流程不要依赖这个结果做真实决策 mock_data { 北京: {温度: 18, 天气: 晴, 风力: 3级}, 上海: {温度: 22, 天气: 多云, 风力: 2级}, } return json.dumps(mock_data.get(city, {温度: 未知, 天气: 未知})) # 2. 定义工具描述传递给模型 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的实时天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ] def chat_with_tools(messages, api_key, base_urlhttps://api.openai.com/v1): url f{base_url}/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: gpt-4o-mini, messages: messages, tools: tools, tool_choice: auto } resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message] # 3. 用户提问 messages [ {role: system, content: 你是一个贴心的生活助手。查询天气后请给出简要穿衣建议。}, {role: user, content: 今天北京适合穿什么} ] # 4. 第一轮模型决定是否调用工具 assistant_msg chat_with_tools(messages, api_keyYOUR_API_KEY) messages.append(assistant_msg) # 5. 如果模型要求调用工具则执行工具并把结果返回给模型 if assistant_msg.get(tool_calls): for tool_call in assistant_msg[tool_calls]: if tool_call[function][name] get_weather: args json.loads(tool_call[function][arguments]) weather_result get_weather(args[city]) messages.append({ role: tool, tool_call_id: tool_call[id], content: weather_result }) # 6. 第二轮模型结合工具结果生成最终回答 final_msg chat_with_tools(messages, api_keyYOUR_API_KEY) print(final_msg[content])这个示例展示了 Agent 与传统对话的本质差异模型不再直接输出答案而是先输出“需要调用哪个函数、参数是什么”程序执行函数后把结果作为新的上下文再次交给模型由模型整合生成最终回答。整个过程是一个闭环模型开始对真实世界数据负责。5.3 一个更贴近业务的决策提示词模板工具调用解决的是“接入外部世界”但 Agent 在复杂业务中还需要学会拆解任务。下面是一个多步骤任务的系统提示词参考用于约束模型先规划、再行动、最后检查你是一个自动任务执行引擎。你的工作流程必须遵循以下顺序 1. 理解用户目标将其拆分为不超过 5 个可执行步骤。 2. 逐步执行每一步每步都必须调用对应工具。 3. 每得到一个工具结果先判断结果是否符合预期再决定是否继续下一步。 4. 如果某一步失败尝试调整参数重试一次重试仍失败则向用户说明原因。 5. 最终输出必须包含执行了哪些步骤、每个步骤的结果、最终结论。 安全规则 - 只调用任务必需的工具。 - 涉及删除、写入、高额交易等敏感操作时先请求人工确认。 - 如果工具返回的数据包含个人隐私信息不要在最终输出中完整展示。这个提示词的核心不是让模型“更聪明”而是让模型的行为更可预期。在实际生产环境中类似的约束往往还会被代码层面的权限控制、审计日志和人工审批流程进一步强化。6. 范式升级背后的工程挑战与成本模型能从“对话”走向“行动”听起来很美好但工程复杂度的提升是实打实的。很多团队在尝试 Agent 化时遇到的最大障碍不是模型能力不够而是工程体系没有跟上。挑战一推理成本从训练端转移到推理端。以前训练一个大模型非常贵但服务时一次推理的边际成本有限。Agent 系统不一样一次复杂任务可能需要模型思考多轮、调用多次工具、重新生成多次。一个任务的 token 消耗可能是普通问答的十倍甚至几十倍。如果产品是免费模式且没有预算控制很容易出现“用户越多亏得越多”的局面。挑战二延迟成为用户体验瓶颈。多步推理天然比单轮问答慢。用户问一句话背后可能需要三次模型调用、两次工具调用。如果每次模型调用需要几秒整体体验就会明显变差。优化手段包括任务并行、结果缓存、流式输出、预判用户意图等。挑战三概率系统执行真实操作可靠性风险放大。传统代码只要正确结果就是确定的。但 Agent 的每一步都由概率模型决定工具调用参数可能出错、步骤顺序可能出错、对工具结果的理解可能出错。更关键的是当这些错误发生在真实操作层面可能产生真实损失。必须为 Agent 的每一步设置可观测性和兜底方案。挑战四传统监控体系失效。常规后端监控关注的是请求量、错误率、耗时。但 Agent 的执行过程是多步骤、多分支的光有接口级监控远远不够。你需要知道模型每一步的决策依据、工具参数、中间结果才能定位“哪一步开始跑偏”。挑战五评测难度急剧上升。单轮问答可以用准确率、BLEU 等指标评估但 Agent 的任务成功与否很难用单一指标衡量。一次任务可能部分成功、部分失败可能路径不同但结果相同。需要设计任务级评测集同时关注成功率、完成质量、安全违规率、资源消耗等维度。工程维度传统应用Agent 应用成本模型每次请求成本稳定每次任务 token 消耗波动大延迟可控多步调用导致明显膨胀可靠性确定逻辑概率决策需要兜底与重试可观测性接口级日志需要步骤级链路追踪评测指标明确需要任务级多维评测安全权限由代码控制模型参与行动需额外护栏这些挑战叠加起来会给团队带来一个清醒的认知Agent 不是“模型 API”的拼装而是一个新的分布式系统问题。它涉及任务编排、状态管理、错误恢复、安全策略和成本治理这些都需要工程上的认真设计。7. 常见误区与判断框架聊完工程挑战再梳理一下行业里常见的四个误区。它们在各类 Agent 项目里反复出现值得提前避开。误区一范式升级 换一个更强的大模型。模型能力确实重要但范式升级意味着系统架构的变化。如果只是把模型从 A 换成 B提示词和应用逻辑原封不动那不是升级只是版本更新。真正的升级体现在任务拆解、工具使用、反馈闭环、状态管理和评测方式上。误区二Agent 在提示词里加一句“你可以调用工具”。工具调用需要结构化接口、参数校验、权限控制、结果解析、错误重试。如果没有这些工程组件模型即使生成了工具调用意图程序也不知道怎么执行。Agent 的效果最终取决于模型之外的工程系统是否牢固。误区三评测和监控可以上线后再补。Agent 系统的行为复杂性决定了它必须从一开始就建立评测基线。如果上线后再发现问题排查成本会成倍增加。至少要提前设计好任务成功率、平均步骤数、无意义调用率、安全违规率等基础指标。误区四追求全自动一步到位。真实业务中很多操作不适合全自动执行。更稳妥的做法是“人类审批 模型执行”比如模型生成操作建议由人工确认后再落地。从半自动到全自动跨度不应该一次完成而是随着评测数据和系统可靠性提升逐步推进。判断一个 AI 产品是否真的踩在范式升级上可以看下面几个问题模型是否参与了任务拆解和规划还是只做单轮问答系统是否能调用外部工具并使用工具结果调整下一步有没有步骤级可观测性能不能定位到“模型在哪一步开始出错”评测指标是否包含端到端任务成功率而不只是模型单独的输出质量设计上是否考虑权限边界、敏感操作确认、异常重试如果这些问题都能给出明确回答那么这个产品大概率是在做真正的“行动型 AI”。如果答不上来那可能还停留在“大模型包装层”。8. 给应用开发者的行动建议面对范式升级个人开发者和小团队不需要焦虑但需要调整工作方式。以下建议来自当前阶段的工程实践观察比较适合已经在做大模型应用、正准备切入 Agent 方向的团队。第一先选场景再选架构。不是所有场景都适合 Agent。适合的方向通常具备三个特征任务流程相对清晰、有可复用的工具接口、结果可以被验证。比如报表生成、数据查询、代码辅助、客户工单分类。先做一个低风险、可量化收益的场景跑通闭环后再扩展。第二把模型当内核把流程当外壳。不要指望模型处理一切而是让模型负责理解和规划代码负责流程控制和确定性。比如模型生成结构化操作指令代码校验后执行。这样即使模型偶尔出错外层逻辑也可以拦截。第三从只读权限开始。工具权限的开放要循序渐进。先开放查询类工具比如搜索、读数据库、读文件确认稳定后再尝试开放低风险写操作涉及删除、更新、转账等敏感操作保留人工审批环节。最小权限原则在 Agent 场景下不是安全最佳实践而是底线。第四尽早建立评测基线。哪怕先用二十个真实任务样本也要把评测跑道建起来。每次改提示词、换模型、调参数都跑一遍基准集。没有评测基线Agent 的优化就变成盲人摸象所有改动都靠感觉。第五给成本设置硬边界。在实际代码中至少要对单次任务设置 token 上限、调用次数上限和超时时间。一旦超过阈值停止执行并转入人工处理。这能避免模型在异常情况下产生失控成本。# 一个简单的成本控制示例 MAX_STEPS 5 # 单次任务最多执行 5 步 MAX_TOKENS 4000 # 单次任务最多消耗 4000 tokens TIMEOUT_SECONDS 60 # 单次任务最长执行时间这类硬编码在正式项目里应该被做成配置而不是散落在代码中。它属于 Agent 生产化的基础设施。第六选可替换的模型抽象层。模型更新速度太快应用代码不应该绑死在某一家模型上。在代码里封装统一的模型调用层保留切换模型提供方的能力。这不仅是技术策略也是商业谈判策略。9. 说在最后回到 Jeff Dean 的“范式升级”这个话题。从公开访谈和演讲传递的信息来看他真正想表达的并不是“下一个模型会更强”而是一整套系统能力的跃迁从理解语言到理解世界从生成内容到执行任务从单点能力到可依赖的系统。这对开发者来说是一个信号也是一个提醒。信号是大模型最值得投入的方向正在从“提示词技巧”转向“Agent 系统与工程化能力”。提醒是任何范式升级都要经历从 demo 到产品的距离这段距离只能靠工程来填平。模型负责想象力系统负责可靠性两者加起来才是 AI 应用真正走向生产环境的样子。如果你打算开始实践建议从第 5 章的最小 Agent 示例入手把它跑通然后加入评测、权限和成本控制。只有亲手把一个任务拆成多个步骤、让模型调用工具并完成闭环才能真正理解“从预测到行动”意味着什么。这篇文章先收藏备用等你要设计 Agent 架构或评估 AI 方案时再翻出来对照一遍应该能帮你少走不少弯路。