Jeff Dean 在 AI 圈里的地位不需要过多介绍。作为 Google 大脑最早的推动者、TensorFlow 的核心作者之一也是 Google 深度学习项目的长期技术负责人他的每一次公开分享都值得认真看。近期他关于“AI 下一次范式升级”的访谈内容流传很广但大多被截成了短句和碎片化观点。这篇文章不打算只做访谈复述而是结合 Jeff Dean 的核心观点、AI 技术演进脉络以及一线工程实践聊几个大家真正关心的问题大模型下一步会怎么走AI 开发范式会不会变Agent 和推理模型会不会取代传统应用以及作为普通开发者我们该往哪个方向积累技术。1. 1 从访谈聊起为什么这次范式升级值得关注先说一个背景。过去两年AI 领域看起来热闹但核心逻辑相对清晰把 Transformer 做得更大把数据喂得更多把算力堆得更猛。这套逻辑被统称为 Scaling Law它确实带来了 ChatGPT、GPT-4、Gemini 一代又一代模型的能力跃升。但 Jeff Dean 和许多 AI 一线研究者都意识到单纯扩大参数规模并不等于模型真正理解世界也不等于系统能可靠地解决复杂工程问题。真正的下一阶段应该是让模型具备更强的长期推理能力、自我反思能力和与环境交互的能力而不是仅仅做一个更好的“填空机器”。Jeff Dean 在访谈中提到了几个关键词合成数据、推理能力、Agent 系统、多模态理解、更小但更高效的模型。这些方向并不新鲜但有趣的是他把它们串成了一条逻辑链模型需要更多高质量训练数据而人工标注数据增长有限因此需要用模型生成合成数据模型需要能够分解复杂任务因此需要强化推理模型不能只停留在对话层需要和工具、数据库、代码环境交互因此需要 Agent 架构。这个逻辑链其实是未来 3 到 5 年 AI 技术发展方向的一个很好框架。1.2 谁适合读这篇文章这篇文章适合作三类读者使用大模型 API 做应用的开发者想了解模型能力和应用形态的变化。做 AI 工程化和平台建设的同学需要判断技术选型与架构方向。刚入门 AI 领域想建立宏观视野的新手。在后面章节里我会从概念、技术趋势、Agent 开发、实际代码示例、FAQ 和最佳实践几个角度展开。涉及代码的部分不会依赖特定公司闭源接口尽量用通用思路和常见开源工具演示。1.3 先厘清几个概念为避免后文产生歧义先定义几个术语。Scaling Law扩展定律指的是模型性能随着参数规模、数据规模和算力规模增大而持续提升的现象。但这不意味着“无限扩展永远有效”数据效率和架构效率正在成为新瓶颈。合成数据Synthetic Data由模型生成、而不是由人工标注产生的训练数据。它可以用来补充真实数据数量不足、覆盖长尾场景但也存在偏差放大、重复乏味等风险。Agent智能体以大模型为核心通过规划、推理、调用工具、执行动作来完成复杂任务的系统。Agent 和普通对话机器人的区别在于它具备“行动闭环”。推理模型Reasoning Model在回答问题前会进行内部推理、自我验证的模型。OpenAI 的 o1、DeepSeek 的 R1 等都属于推理模型它们不是简单生成下一个 token而是学会在回答前“思考”。有了这些基础我们再来看 Jeff Dean 提出的范式升级具体指什么。2. 范式升级的方向从“大而全”到“强推理 行动”Jeff Dean 访谈中最核心的判断是下一代 AI 系统不会是单一巨型模型的无限扩张而是多个模型、多种能力相互协作的复杂系统。2.1 数据策略从“堆数据”变为“数据质量工程”过去训练大模型主流做法是尽可能多地收集文本、图片、代码。但研究机构逐渐发现数据数量并不是唯一指标模型在低质量重复数据上训练会学到噪声和偏差标注不准确的数据更会直接影响模型在专业任务上的性能。Jeff Dean 强调未来数据工程的优先级会比模型结构设计更高尤其是合成数据的有效利用。现在很多团队已经在用大模型自动生成指令数据、改写代码注释、扩充测试用例。这种做法可以用更低的成本获得大规模数据但必须注意质量筛选和多样性控制。简单来说数据工作的重心正在从“收集更多”转向“怎么组合、怎么清洗、怎么验证”。2.2 推理能力不再只是附属功能传统的 GPT 式模型输入问题后直接根据概率分布生成答案这种方式对简单问题有效但面对数学推理、逻辑判断、多步骤规划时直接生成的结果经常出错。推理模型的思路是在生成最终答案之前模型先生成思维链自己推导、验证、纠正。Jeff Dean 认为未来几乎所有重要任务都会要求模型具备“受控推理”能力而不是只靠记忆复现。这不是说基础生成能力不再重要而是说模型需要学会在关键任务上投入额外计算把答案的可靠性和可验证性提上去。对开发者的影响很直接选模型时要考虑它是否有 reasoning mode微调数据时要设计带推理过程的样本。2.3 Agent 是 AI 落地的主要形态单模型对话能解决的问题有限。真正要落地到业务中AI 需要能查数据库、调用 API、操作网页、执行代码、读取文件并且在出错后能自我纠正。这就是 Agent 的用武之地。Jeff Dean 在访谈中明确提到Google 内部非常重视 Agent 相关研究Gemini 系列的强化方向之一就是“工具使用”。他认为未来应用不再是简单的“输入框对话”而是一群协作的 Agent 在后台调度每个 Agent 负责一个子任务比如检索、规划、执行、校验。这也是为什么近期“AI Agent 开发”会成为热搜词背后的技术原因。3. 从研究者视角看未来多模态与系统协同3.1 多模态不是“能看图”那么简单Gemini 系列从一开始就是原生多模态而不是把图像识别和文本模型拼在一起。Jeff Dean 强调的关键点是多模态模型如果在训练阶段就把文本、图像、音频、视频统一建模模型可以学习到不同模态之间的对齐关系从而理解更复杂的上下文。举个例子以前我们做一个“图片问答”任务需要先接 OCR 识别文字再用 NER 抽取实体然后交给问答模型。原生多模态模型可以一步到位直接输入一张发票图片让它理解里面的金额、公司名、日期等结构化信息并且回答相关问题。这背后不是多个模型串行工作而是同一个模型在不同模态上共享语义空间。对应用开发者来说多模态能力会让“AI 看懂屏幕”的一类应用比如 UI 自动化测试、客服截图理解、视频内容审核变得更简单。3.2 系统级设计模型不只是 API而是一个运行时环境另一个值得关注的变化是AI 正在从单点模型调用走向系统化部署。Jeff Dean 把这种系统化称为“AI Infra 的下一次演进”。在以前开发者的任务是把模型 API 接入业务在未来开发者需要管理多个模型的生命周期路由到不同大小的模型、控制推理成本、处理降级、调度 Agent 任务、监控模型漂移。这就带来一个新岗位方向AI 平台工程师或大模型工程化开发。核心工作包括模型推理优化、缓存设计、流程编排、评估体系搭建和故障恢复。当前一些成熟的开发框架也已经开始支持这种模式比如 LangGraph、LlamaIndex、Spring AI 以及各种 Agent 编排框架。可以说AI 开发正在从“写提示词”走向“写系统”。3.3 小模型与大模型的分工协作关于“模型越大越好”这个观点Jeff Dean 并没有全盘否定但他强调大小模型分工会更清晰。超大模型适合做复杂推理、数据生成和困难任务的最终决策小模型经过蒸馏和微调后可以在特定场景下以更低延迟、更低成本完成任务。实践中已经在发生很多公司用 GPT-4 级别的模型生成高质量数据再用这些数据微调一个 7B 或 13B 的开源模型部署在自己的私有化环境中。这样既照顾了数据安全也控制了推理成本。这种“大模型蒸馏小模型 小模型承担高并发任务”的模式未来会越来越普及。4. 实战搭建一个具备基础 Agent 能力的系统理论聊完接下来进代码环节。这一节我会演示一个轻量级 Agent 原型它能够接收自然语言任务调用外部工具完成计算和搜索并带基本的结果校验逻辑。为了方便演示这里使用 Python 编写不依赖重量级框架重点让大家理解 Agent 的核心循环任务解析、工具调用、结果反馈、再规划。4.1 创建项目结构先创建一个项目目录结构如下agent-demo/ ├── main.py ├── tools.py ├── llm_client.py └── requirements.txt其中tools.py定义可供 Agent 调用的外部工具llm_client.py封装大模型 API 调用逻辑main.py是 Agent 主循环。4.2 配置依赖requirements.txt内容如下openai1.0.0 python-dotenv1.0.0 requests2.31.0这里不限制必须使用 OpenAI 接口你可以根据实际模型服务商调整。很多国内模型厂商也提供兼容接口只需要修改base_url和api_key即可。4.3 定义工具层Agent 的全部意义在于“能干事情”而能干事情的前提是定义好工具。先写一个简单的计算工具和一个模拟的信息查询工具。# 文件路径agent-demo/tools.py import datetime import math def calculate(expression: str) - str: 计算数学表达式例如 2 * (3 4)。 try: # 注意eval 存在风险示例中用解析实现更安全 result eval(expression, {__builtins__: {}}, {math: math}) return f计算结果: {result} except Exception as e: return f计算失败: {str(e)} def get_current_time(timezone: str UTC) - str: 获取当前时间示例只返回 UTC。 now datetime.datetime.utcnow() return f当前 UTC 时间是: {now.isoformat()} def get_weather(city: str) - str: 模拟查询天气真实项目中可接入第三方天气 API。 weather_map { 北京: 晴25 摄氏度, 上海: 小雨28 摄氏度, 深圳: 多云30 摄氏度, } return weather_map.get(city, f暂无 {city} 的天气信息) AVAILABLE_TOOLS { calculate: { description: 计算数学表达式适合算术、稍微复杂的数学公式, parameters: {type: object, properties: {expression: {type: string}}, required: [expression]}, function: calculate, }, get_current_time: { description: 获取当前时间无参数, parameters: {type: object, properties: {}}, function: get_current_time, }, get_weather: { description: 查询某个城市的天气, parameters: {type: object, properties: {city: {type: string}}, required: [city]}, function: get_weather, }, }这里采用一个简单的注册表模式每个工具都有描述、参数说明和可调用函数。描述信息是为了让模型理解该在什么场景下使用工具。真实项目里工具的 description 写得越清晰模型的工具调用准确率越高。需要特别说明这里的eval只作为演示生产环境千万不要直接这样使用否则任意表达式注入会带来严重安全问题。真实项目中推荐用ast.literal_eval或者专门的表达式解析库。4.4 封装大模型客户端大模型客户端负责两件事第一完成对话补全第二输出工具调用意图。现在主流模型都支持 function calling 风格接口因此我的客户端封装会贴合这种格式。# 文件路径agent-demo/llm_client.py from openai import OpenAI class LLMClient: def __init__(self, api_key: str, base_url: str None): self.client OpenAI(api_keyapi_key, base_urlbase_url) def chat_with_tools(self, messages, tools): 发送对话并返回模型响应。 response self.client.chat.completions.create( modelgpt-4o-mini, # 按实际可用模型调整 messagesmessages, toolstools, tool_choiceauto, ) return response.choices[0].message如果你使用的是国内模型服务可以在初始化时传入对应的base_url例如某些兼容 OpenAI 接口的服务地址。用统一封装的好处是切换模型时只需改配置不用大改 Agent 逻辑。4.5 编写 Agent 主循环Agent 主循环是核心。它不停执行下面的流程将用户消息和工具定义发送给模型。判断模型返回的是直接回答还是工具调用请求。如果是工具调用执行对应工具函数把结果追加到消息历史里。再次调用模型直到模型不再请求工具输出最终答案。# 文件路径agent-demo/main.py import os from dotenv import load_dotenv from tools import AVAILABLE_TOOLS from llm_client import LLMClient load_dotenv() def build_tool_schema(): 把工具注册表转换为模型可识别的 schemas。 schemas [] for name, info in AVAILABLE_TOOLS.items(): schema { type: function, function: { name: name, description: info[description], parameters: info[parameters], } } schemas.append(schema) return schemas def execute_tool_call(tool_call): 执行工具调用返回结果字符串。 tool_name tool_call.function.name arguments tool_call.function.arguments import json args json.loads(arguments) if arguments else {} tool_info AVAILABLE_TOOLS.get(tool_name) if not tool_info: return f未知工具: {tool_name} result tool_info[function](**args) return result def run_agent(user_input: str, max_iterations: int 5): client LLMClient(api_keyos.getenv(OPENAI_API_KEY)) tools build_tool_schema() messages [ {role: system, content: 你是一个乐于助人的 AI 助手可以使用工具完成用户请求。请一步一步思考并在需要时调用工具。}, {role: user, content: user_input} ] for step in range(max_iterations): print(f\n 第 {step 1} 轮 ) message client.chat_with_tools(messages, tools) # 无工具调用直接返回 if not message.tool_calls: print(最终回答:, message.content) return message.content # 模型要求调用工具 messages.append(message) for tool_call in message.tool_calls: tool_result execute_tool_call(tool_call) print(f调用工具 {tool_call.function.name}参数 {tool_call.function.arguments}) print(f工具返回: {tool_result}) messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result, }) print(达到最大迭代次数结束。) return None if __name__ __main__: demo_input 我想知道现在的时间然后帮我计算 (123 456) * 2 的结果 run_agent(demo_input)这段代码核心思路就是循环调用模型。第一次调用时模型可能会输出两个工具调用get_current_time和calculate。我们把工具执行结果放回消息队列模型看到结果后会汇总成自然语言回答。4.6 运行与预期结果在项目目录下执行pip install -r requirements.txt python main.py预期输出大致如下 第 1 轮 调用工具 get_current_time参数 {} 工具返回: 当前 UTC 时间是: 2025-06-14T03:22:01.123456 调用工具 calculate参数 {expression: (123 456) * 2} 工具返回: 计算结果: 1158 第 2 轮 最终回答: 当前 UTC 时间是 2025年6月14日 03:22:01计算 (123 456) * 2 的结果是 1158。如果你的模型不支持工具调用可以考虑换成 ReAct 模式让模型自己输出 JSON包含thought、action、action_input字段然后你手动解析并执行。两种模式本质相同都是“模型决定动作代码执行动作”。4.7 工程落地的重点上面的 demo 只演示了 Agent 最基础的能力。工程落地时还需要补充这些能力工具白名单与权限控制不同用户角色只能调用不同工具。工具调用审计保存每一次工具调用的参数、结果和时间。超时与重试第三方服务可能超时需要给工具执行增加超时上限。对话历史裁剪工具调用结果可能很长要及时截断防止上下文超长。评估集在 Agent 代码变更后需要自动跑一组测试用例判断工具调用准确率是否下降。这些点里评估集最容易被忽略但它的重要性仅次于基本的可用性。Agent 是概率系统不做回归评估就像没有测试的代码仓库上线全靠运气。5. 常见问题与排查思路5.1 工具调用失败或返回乱码问题现象常见原因解决思路工具名称拼写错误模型生成了不存在的工具名工具注册表增加纠错提取最近相似工具名参数格式错误模型生成的 JSON 缺失字段使用 JSON Schema 校验并引导模型补充缺失参数工具抛异常外部服务不稳定或输入不合法工具内部捕获所有异常返回统一错误结构上下文超长多次工具调用后历史过多对工具结果截断或摘要丢弃过旧消息5.2 模型不调用工具直接瞎答这种情况通常不是因为模型不会而是模型觉得自己可以直接回答。解决方法是把工具描述写得更具体让模型知道“这个问题必须调用工具才能获取最新数据”。此外可以降低 temperature 到 0 或 0.1减少随机性。5.3 Agent 陷入死循环Agent 最常见的故障模式是模型反复调用同一个工具拿到结果后仍不满意继续再调。这会耗尽 token 预算。解决方案有三个限制最大迭代轮次当同一工具被调用多次且参数不变时强制中断引入反思机制让模型区分“当前信息已经够用”和“还需要继续调查”。5.4 如何评估 Agent 质量Agent 评估不能只看最终回答是否满意要拆成多个维度工具选择正确率该调用工具时有没有调用。参数提取准确率用户自然语言里的实体有没有正确映射到参数。步骤顺序合理性先查信息再计算还是反着来。最终回答正确率对用户问题的最终回答是否准确。效率总 token 消耗、步数、耗时。建议提前准备 50 到 100 条典型 query 作为回归集每次改动 Agent 的提示词、工具描述或主循环逻辑后都跑一遍。6. 工程建议与最佳实践6.1 用状态机管理 Agent 生命周期Agent 不只是“模型调用循环”它是有状态的系统。复杂任务可能包含多个子任务Agent 需要记录当前进度、已获取的事实、尚未完成的目标。用状态机或工作流引擎管理 Agent 生命周期会比把所有内容塞进对话历史更稳定。把“思考”“决策”“执行”“验证”变成显式的状态代码可读性和可调试性都会明显提升。6.2 模型选择不要迷恋“最大最好”不是所有任务都需要最大参数模型。简单分类、抽取和改写任务7B 到 14B 的小模型已经能达到不错效果。采用“路由层”策略简单任务直接走小模型复杂推理再上大模型。这样可以显著降低延迟和成本。当前很多推理框架也支持“投机采样”和“早退机制”在小模型预测后续 token、大模型校验兼顾速度和质量。这也呼应了 Jeff Dean 提到的“多种模型协同工作”。6.3 安全边界优先Agent 能调用工具意味着系统暴露面变大。生产环境必须做严格的安全控制Agent 工具只能访问白名单 API不能任意访问文件系统。涉及数据库或支付等敏感操作必须人工审批不能让 Agent 自动执行。引入数据脱敏层Agent 看到的应该是脱敏后的数据。在工具返回结果中标记数据来源等级模型需要知道哪些信息经过确认、哪些只是推测。6.4 日志和追踪是刚需Agent 排错比普通代码麻烦得多因为每次运行轨迹都不一样。所以日志记录要足够细记录每一轮模型思考、工具调用参数、工具结果、token 消耗。有条件的话把对话轨迹可视化展示会极大提升排查效率。日志字段建议至少包含用户请求 IDAgent 会话 ID当前状态模型名称和参数调用的工具与参数工具执行耗时错误信息累计 token 数6.5 优先复用成熟框架但不要被框架绑定当前处理 Agent 编排的框架非常多。LangGraph 提供了节点状态机、条件重试LlamaIndex 偏向知识库与 RAG字节跳动的 Coze 等平台则更偏低代码。我的建议是如果你做的是内部工具或验证性项目直接用框架能节省大量时间但如果是核心业务链路建议把框架的逻辑抽象成自己的服务避免被上游版本频繁变更拖累。记住框架只是工具真正的核心竞争力是适配自己业务的 Agent 架构、工具设计和评估体系。7. 下一步学习方向如果你看完这篇文章想继续深入 AI 方向下面这条路线可以按顺序走下去先熟练掌握大模型 API 的基本用法包括对话补全、嵌入、函数调用。学会提示词工程尤其是上下文窗口管理和结构化输出解析。学习 RAG 相关技术向量数据库、文档切块、混合检索、重排序。动手写几个 Agent 小项目比如自动报告生成、客服工单分类、代码评审助手。阅读推理模型的论文与开源实现理解思维链、强化学习如何提升模型推理能力。学习大模型微调和量化部署掌握 LoRA、QLoRA、vLLM 等工具的用法。关注模型评估和数据工程这是最容易拉开差距的部分。Jeff Dean 所说的范式升级说的不是某一篇论文或某一个模型而是整个 AI 领域从“做出能说话的模型”到“做出能干事、能协作、能推理的系统”的转变。这个过程里新的工具会不断出现旧的套路会被淘汰但对系统设计、数据质量、工程判断力的要求始终不变。回到开发者的视角不管模型怎么升级我们真正要建立的是一种“AI 原生工程”的思维方式设计任务闭环的能力、拆分复杂问题的能力、评估系统质量的能力。只要能不断迭代这几种能力即便 AI 的范式再变你也不会被甩在浪潮后面。