AI范式升级：从预测下一个词到自主完成任务的智能体-平芜编程栈

Jeff Dean谈AI的下一次范式升级：从“预测下一个词”到“自主完成任务的智能体”

很多人现在都有一种隐约的不适感：大模型已经火了好几年，ChatGPT 带来的震撼确实不小，但真要把它放到生产环境里，总觉得差一口气。

写文案、写代码、做总结，这些事模型确实能干。可一旦涉及到“帮我查一下这个订单为什么没发货，然后自动发一封催办邮件”，它就卡住了。不是模型不会写邮件，而是它不知道怎么查订单、怎么调用内部系统、怎么在多个步骤之间做判断。你必须在提示词里把每一步都写清楚，它才能勉强走通。

这种“半步之遥”的感觉，恰恰是 Jeff Dean 最近在访谈里反复提到的核心问题：AI 的下一轮范式升级，不是把模型做得更大，而是把模型从“一个会写字的聊天机器人”变成“一个能自主完成任务的智能体”。

这篇文章不打算复述整场访谈，而是提炼 Jeff Dean 以及 Google 团队近期公开的技术判断，结合 AI Agent、多模态、模型部署等方向，聊聊这轮范式升级到底是什么、背后的技术逻辑是什么、对普通开发者意味着什么，以及我们该怎么准备。

1. 这篇文章真正要解决的问题

先说一个判断：如果你还停留在“把大模型当高级搜索框用”的阶段，未来两三年你的竞争力会被快速稀释。这不是贩卖焦虑，而是技术分工变化的必然结果。

过去几年，大模型的核心能力是“生成”。给它一段输入，它吐出一段输出。无论是聊天、写作、翻译还是写代码，本质上都是“根据上下文生成下一个 token”。这个能力当然有价值，但它有一个天然短板——模型没有行动能力。它只能“说”，不能“做”。

而真实世界的软件开发、信息处理、业务协作，恰恰是“做”的过程：要调接口、要查数据库、要判断异常、要重试、要跟其他系统交互。如果模型永远停留在“生成文本”的层面，那它就永远只能是辅助工具，不可能成为真正意义上的“AI 员工”。

Jeff Dean 在访谈中提到的“范式升级”，核心就是这个：从“生成式 AI”走向“交互式 AI”，从“模型即生成器”走向“模型即智能体”。

为了讲清楚这件事，这篇文章会拆解几个关键问题：

下一次范式升级到底“新”在哪里？
Agent 为什么被看作 AI 的下一个核心形态？
多模态、长期记忆、工具调用这些技术如何支撑 Agent 落地？
作为开发者，我们该学什么、该做什么、该避开什么坑？

如果你正在做 AI 应用开发，或者正在评估公司的技术栈该怎么往 AI 方向演进，这篇文章值得你读完。

2. AI范式升级：从“预测下一个词”到“完成任务”

2.1 先解决一个认知误区

很多人以为“大模型越大会越智能”。这个说法在早期有道理，但现在已经越来越不准确了。

GPT-3 时代，模型规模的提升确实带来了明显的质变，大家第一次意识到“原来文字接龙能接出这么像样的答案”。但到了 GPT-4 时代，你会发现，单纯堆参数带来的收益正在递减。更重要的变化发生在训练方法和使用方式上：指令微调让模型学会听指令，人类反馈强化学习让模型学会对齐人类偏好，上下文学习让模型学会“现场读说明书”。

Jeff Dean 在这一轮访谈中强调的范式升级，本质上是在这个基础上再往前推一步：模型不仅要“理解指令”，还要“理解目标”；不仅要“给答案”，还要“制定计划、调用工具、验证结果”。

这句话翻译成技术语言就是：

从“语言模型”升级为“推理系统”；
从“静态模型”升级为“动态 Agent”；
从“单轮问答”升级为“多步骤任务执行”。

2.2 为什么现在才提“范式升级”

表面上，Agent 的概念并不新鲜，学术界喊了十几年，ReAct、Toolformer、AutoGPT 这类项目也早就火了。但真正让 Agent 可能落地的时间点，其实是最近一两年才到来的。

原因有三个：

第一，模型的推理能力上来了。Agent 的核心不是“会调用工具”，而是“能判断什么时候该调用什么工具”。这需要模型具备一定的规划能力和常识推理能力。2024 年之后发布的旗舰模型，在这方面的表现比两年前强了一个量级。

第二，工具生态成熟了。以前模型想调用外部工具，得靠工程师手工写接口。现在有了 Function Calling、MCP（Model Context Protocol）这类标准化协议，模型可以像人类使用 API 文档一样，动态发现并调用工具。

第三，评测方式在变。以前评测模型就是“考试”，拿一堆选择题、简答题去问它。现在业界开始用“实际完成任务”的方式来评测，比如让它自己登录网站、查资料、提交表单、发邮件。这种评测方式逼着模型从“会说话”走向“会做事”。

所以 Jeff Dean 说的“下一次范式升级”，不是一个突然冒出来的新点子，而是当基础模型能力、工具生态、评测标准都到达临界点之后，必然会出现的转向。

3. Agent：AI 从“回答者”变成“执行者”

3.1 什么是 Agent，它和聊天机器人有什么本质区别

为了说得清楚，这里用一个对比：

聊天机器人（Chatbot）的工作方式是：接收用户输入 → 生成回复 → 结束。

Agent 的工作方式是：接收用户目标 → 拆解任务 → 规划步骤 → 调用工具 → 检查结果 → 如果结果不对就调整策略 → 最终完成任务。

这两者的差异不是表面上的“功能多少”，而是控制逻辑的所在位置不同。聊天机器人的控制逻辑在用户手里，你说一句它回一句；Agent 的控制逻辑在系统内部，你给它一个目标，它自己决定每一步做什么。

举一个常见的业务例子：

用户说：“帮我把这个月的销售数据整理成周报，发给领导。”

聊天机器人能做到：生成一份周报的文字框架，然后告诉你“数据需要你自己填”。

Agent 能做到：连接数据库查询数据 → 按周汇总 → 调用报表工具生成图表 → 调用邮件接口发送给指定收件人 → 回来告诉你“已发送，这是摘要”。

在 Jeff Dean 的访谈里，他特别强调了一个词：“deliberate planning”（审慎规划）。AI Agent 不是莽撞地执行你给的第一步，而是要把最终目标拆成中间步骤，在每一步之间评估结果，然后决定下一步怎么做。

3.2 Agent 的架构拆解：它内部到底有什么

抛开那些复杂的商业概念，一个可用的 Agent 系统在架构上至少包含四个模块：

规划模块（Planning）：负责把用户目标拆解成子任务，并决定执行顺序。对应到工程实现，就是让模型输出 JSON 格式的“行动计划”，或者使用 ReAct 这类思维链模式。

记忆模块（Memory）：负责保存上下文、历史操作和结果。短期记忆对应对话上下文，长期记忆可以落库到向量数据库或图数据库，让 Agent 能在多次任务之间积累经验。

工具模块（Tool Use）：负责连接外部系统。每一个工具就是一个函数，有明确的输入输出描述。Agent 通过工具描述来发现“哪个工具能实现当前目标”。

反思模块（Reflection）：负责自我评估。执行完一个步骤后，Agent 要判断结果是否符合预期，不符合就重试或换方案。

这四个模块不是独立的，而是串成一条“感知 → 决策 → 行动 → 反馈”的循环。

# 文件路径：agent_simple.py # 一个极简的 Agent 运行循环示意，用于理解核心逻辑 def run_agent(task, tools): # 1. 规划：将任务拆成子步骤 plan = llm_plan(task) results = [] for step in plan: # 2. 决策：根据当前上下文选择工具 tool_name = llm_select_tool(step, results, tools) # 3. 行动：执行工具函数 result = tools[tool_name].run(step) # 4. 反思：判断是否成功，失败则重试 if not evaluate(result): result = retry_with_feedback(step, result) results.append(result) # 5. 汇总：生成最终输出 return llm_summarize(task, plan, results)

当然，真实生产环境的 Agent 系统远比这个复杂，需要处理工具鉴权、超时、并发、失败重试、安全审计等一系列工程问题。但这个最小循环足以说明 Agent 和“单次生成”的区别：它把“一次调用”变成了“一个过程”。

3.3 为什么说 Agent 是“下一次范式升级”

如果你只关注单点能力，Agent 确实没有在“文字生成”这个层面带来数量级的提升。但是，如果你关注 AI 在业务系统里的渗透率，Agent 带来的变化是革命性的。

过去，企业在业务系统里集成 AI，无非两种方式：要么在入口做一个人工客服，要么在文档处理流程里加一道“自动摘要”。这些都是“点状应用”，AI 只是流程中的一个节点。

Agent 不一样，它可以把整条业务链路串起来。从前端理解用户意图，到后端查询业务数据，再到执行操作、反馈结果，整个过程中 AI 扮演的是“执行者”而不是“辅助者”。这种变化意味着 AI 的能力边界从“内容生成”扩展到了“业务流程”。

这也是为什么各家大厂都在拼命推 Agent 平台：OpenAI 的 GPTs、Google 的 Gemini Agent、Anthropic 的 Claude 工具调用，本质上都是在为“AI 执行任务”铺设基础设施。

4. 多模态为何是 Agent 落地的关键一步

4.1 从“文本 Agent”到“多模态 Agent”

Jeff Dean 在访谈里专门花了不少篇幅聊多模态。在很多人看来，多模态只是“模型能看图、能听语音”，属于功能层面的加分项。但放在 Agent 的语境下，多模态的定位完全不同。

一个只能处理文本的 Agent，活在“文字世界”里。它能读 PDF、能写报告，但它看不懂界面、不会操作浏览器、无法理解一张图表的数据。

一个多模态 Agent，活在“真实世界”里。它能看截图、识别按钮位置、理解图表含义、甚至直接操作 GUI。这意味着 Agent 可以用“人操作电脑的方式”去完成任务——这在自动化领域有巨大的想象力。

一个很典型的例子是“网页自动化”。传统 RPA（机器人流程自动化）需要人工录制脚本或者写选择器，流程稍微变一点就失效。多模态 Agent 的做法是：给模型一张网页截图，让它判断“下一步该点哪里”，然后用代码模拟点击。网页改版了？没关系，模型看到新界面后自己会重新判断。

4.2 统一的输入空间是 Agent 理解世界的基础

从技术原理上看，多模态模型和纯文本模型的区别，不只是“多了几个输入通道”，而是它把视觉、听觉、文本放在了一个统一的语义空间里。

当模型能同时理解“这张图上的表格”和“这段文字描述的表格”时，它才真正具备了跨模态的推理能力。对于 Agent 来说，这意味着它可以同时处理“语音指令 + 屏幕截图 + 数据库结果 + 错误日志”，然后综合这些信息做决策。

Jeff Dean 之所以强调这一点，是因为他认为下一代 AI 系统不会是“一个文本模型”或者“一个视觉模型”的简单拼装，而是一个原生的多模态模型，能够把来自不同感知通道的信息融合成统一的世界模型，再基于这个模型去规划和行动。

4.3 开发者的机会点

对于做应用开发的团队，多模态 Agent 带来的机会其实很直接：

客服系统：用户上传一张故障截图，Agent 可以自己看图判断问题类型，然后调用知识库给出排查方案。
运维系统：Agent 可以查看监控大屏截图、分析日志文本、调用 API 做变更，形成一个闭环。
测试系统：Agent 可以自动操作被测应用的界面，根据视觉反馈判断页面是否正常渲染。

这些方向不是“未来畅想”，而是现在就可以尝试的技术方案。

# 文件路径：multimodal_agent_step.py # 示意：让 Agent 根据截图判断按钮位置并执行点击 # 这里使用伪代码表达思路，实际项目请替换为对应模型 API def click_by_screenshot(screenshot_path, target_text): # 1. 将截图交给多模态模型，识别目标元素的位置 vision_result = vision_model.analyze( image=screenshot_path, prompt=f"Find the button containing '{target_text}' and return its coordinates." ) # 2. 解析模型返回的坐标 x, y = parse_coordinates(vision_result) # 3. 使用浏览器自动化工具执行点击 browser.click(x=x, y=y)

需要注意，多模态模型的坐标定位在复杂界面上并不总是准确，真实应用中通常需要多轮反馈校准。但这一示例代表了一个趋势：Agent 正在从“纯文本工具”走向“视觉操作者”。

5. 模型部署与基础设施：让 Agent 跑起来的技术底座

5.1 更强模型不等于更好用，推理成本才是瓶颈

Jeff Dean 作为 Google 基础设施的核心人物，在这类访谈里一定会谈到硬件的走向。但真正值得开发者在意的不是“TPU 有多快”，而是背后一个关键趋势：AI 的重心正在从训练走向推理，而且推理的形态正在从“单次生成”走向“多轮交互”。

传统的大模型推理，是典型的“高并发、低延迟”场景：用户发一条消息，模型生成一段文本，响应时间可能几秒钟，用户能接受。但 Agent 场景完全不同，一次任务可能需要模型推理 10 次、20 次甚至更多次，每一次推理都要保持低延迟，总耗时才可能在可接受范围内。

这意味着，如果你要把 Agent 部署到生产环境，你最需要关注的不再是“模型聪明不聪明”，而是“模型便宜不便宜、快不快、能不能并发扩展”。

5.2 一个生产可用的 Agent 推理链路

从工程角度，一个生产级的 Agent 推理架构通常需要包含：

模型网关：统一入口，负责路由、鉴权、限流。
模型缓存：对于重复的子任务，直接命中缓存，省一次推理成本。
工具执行器：负责调用外部 API，处理超时和重试。
请求追踪：记录 Agent 每一步的输入输出，方便排查和审计。

# 文件路径：agent_gateway.yaml # 一个通用的 Agent 推理网关配置示例 gateway: host: "0.0.0.0" port: 8080 models: - name: "fast-model" # 用于轻量判断、文本分类 provider: "ollama" model: "qwen2.5:7b" timeout_ms: 5000 - name: "reason-model" # 用于复杂规划、工具选择 provider: "openai-compatible" model: "deepseek-chat" timeout_ms: 30000 cache: enabled: true backend: "redis" ttl_seconds: 3600 tools: - name: "search_order" endpoint: "http://order-service:8081/api/order" timeout_ms: 8000 - name: "send_email" endpoint: "http://notification-service:8082/api/email" timeout_ms: 10000

这里有一个容易被忽略的细节：模型路由。不是所有步骤都需要最强大的模型。Agent 内部可以设置一个“先快后慢”的策略——简单的意图识别用轻量模型，复杂的规划任务用旗舰模型。这个策略能从成本层面决定一个 Agent 项目能不能在业务上跑得通。

5.3 部署 Agent 的“反直觉”点

很多团队第一次把 Agent 部署到线上的时候，会遇到一个“反直觉”的坑：Agent 比传统 API 接口更容易超时，而且错误模式更隐蔽。

传统接口，输入输出的结构是固定的，出错也能很快定位。Agent 不一样，它内部有多个步骤，任何一步都可能出错。更麻烦的是，模型偶尔会“幻觉”出一个不存在的工具名称，或者生成了一个完全不符合规范的 JSON 参数。

所以，生产环境的 Agent 系统必须做三层保护：

协议校验：模型输出的 JSON 必须通过 schema 校验，不合法就重试。
工具熔断：连续失败的工具有必要摘除，避免 Agent 反复调用错误接口。
人工审计：Agent 执行的关键操作必须留痕，并且支持回滚。

这也是为什么 Jeff Dean 在访谈中多次强调“可靠性”。Agent 要成为一个真正可用的系统，就不能停留在“看起来聪明”的层面，而是必须变成一个“工程上可靠”的系统。

6. 范式升级之后，开发者该往哪个方向走

说了这么多范式、Agent、基础设施，回到一个最实际的问题：作为一个普通开发者，这轮范式升级对你意味着什么？

6.1 从“应用开发者”到“模型交互工程师”

过去一年，开发圈子里最火的一个新角色叫“AI 应用工程师”。这个岗位不需要你要能训模型，但你要非常清楚模型的能力边界、提示词策略、工具调用的工程实现。

Jeff Dean 访谈里透露的范式升级，实际上进一步强化了这个角色的价值。以后，业务系统的核心竞争力不在于“你会不会调 API”，而在于“你能不能把模型、工具、数据、业务流程编排成一个稳定的自动执行系统”。

6.2 学习路径建议

如果你担心自己跟不上这波变化，可以参考下面的路径，从易到难推进：

阶段一：学会“让模型稳定输出”

这个阶段的目标是：你能完全控制模型的输出格式。

具体做三件事：

学会写结构化提示词。
学会用 JSON Mode / Function Calling 让模型输出可解析的结构化结果。
学会用校验逻辑解决“模型输出不稳定”的问题。

# 文件路径：structured_output.py # 让模型输出结构化 JSON 的示例 import json from openai import OpenAI client = OpenAI() prompt = """ 你是订单处理助手。请从用户描述中提取订单信息，以 JSON 格式返回。 用户描述：我的订单 20250101 还没发货，帮我催一下。 要求返回格式： { "order_id": "订单号", "action": "要执行的操作", "urgency": "高/中/低" } """ resp = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"} ) data = json.loads(resp.choices[0].message.content) print(data["order_id"]) # 输出：20250101 print(data["action"]) # 输出：催单

模型输出格式不稳定，是所有 Agent 项目的第一道坎。这道坎迈不过去，后面都别谈。

阶段二：学会“把流程拆成 Agent 步骤”

这个阶段的目标是：把之前写死的业务逻辑，改造成“模型动态规划 + 工具执行”的结构。

建议动手做一个练习：写一个“支持自然语言查询数据库”的 Agent。用户输入“上个月销售额前五的产品”，Agent 自动生成 SQL、执行查询、返回结果。

做完这个练习，你会理解工具调用、Agent 规划、错误重试这三个核心概念。

阶段三：学会“评估 Agent 效果并优化”

Agent 上线后最大的问题不是“不能用”，而是“不知道什么时候用不好”。建议团队建立一套 Agent 评测集，把常见的用户输入、期望的工具调用顺序、期望的最终输出都记录下来。每次修改提示词、切换模型、调整工具参数后，都在评测集上回归测试。

6.3 需要警惕的坑

在往这个方向走的时候，有几个坑值得提前提醒：

坑一：把 Agent 当万金油。Agent 的规划能力在简单任务上显得“过度设计”，在极端复杂任务上又“不够用”。最适合 Agent 落地的场景是“中等复杂度、有明确工具支持、错误可容忍”的任务。

坑二：忽视延迟和成本。一次 Agent 任务可能等于 10 次模型调用。如果 Boss 期望 Agent 像普通接口一样 200ms 返回，这个需求大概率无法满足。早期就要管理好预期。

坑三：没有兜底方案。Agent 一定会出错，早晚问题。在设计系统时，就必须想好“Agent 失败后，用户怎么办”。人工接管、自动降级、操作回滚，这三个兜底策略至少要上一个。

7. 给开发者的可落地实践路径

如果你看完上述分析，觉得“这轮变化确实值得重视”，那么下一步可以按下面的清单去推进。这不是一个需要三年才能完成的大工程，一周之内就能跑起来。

7.1 第一步：搭建本地实验环境（1天）

先从部署一个小模型开始，不一定追求最强效果，关键是跑通“模型调用 → 工具调用 → Agent 循环”的完整链路。

# 安装 Ollama（macOS/Linux/WSL 均可） curl -fsSL https://ollama.com/install.sh | sh # 拉取一个支持工具调用的模型 ollama pull qwen2.5:7b # 启动本地模型服务 ollama serve

然后写一个最简单的 Python 脚本，验证本地模型能不能完成“根据用户输入返回城市天气”的工具调用任务。

7.2 第二步：为 Agent 添加 3 个真实工具（2天）

给自己的 Agent 添加三个有用的小工具：

一个查数据库的工具，用于验证“模型生成 SQL”的能力。
一个查 HTTP API 的工具，用于验证“模型根据 API 描述调用接口”的能力。
一个执行 shell 命令的工具，用于验证“模型执行本地操作”的能力。

工具数量不需要太多，但一定要包含“有输入参数、有返回错误”的真实函数，这样你才能测试到模型面对错误之后的反应。

7.3 第三步：建立最少 20 条的评测集（2天）

不管用什么模型，都要准备一个评测集。至少包含 20 条任务，覆盖正常任务、模糊需求、缺少参数、工具调用失败这些场景。

每次调整 Agent 后，跑一遍评测集，记录成功率。你会很快发现，表面“看起来聪明”的 Agent，真实成功率可能低得惊人。

8. 常见问题与排查思路

这几个问题，是初学 Agent 的人最容易遇到的，建议收藏备用。

问题现象	可能原因	排查方式	解决方案
模型不按格式输出 JSON	提示词约束不够，或模型本身较弱	打印模型原始输出，检查解析器报错位置	使用 response_format，必要时做输出格式二次修复
Agent 反复调用同一个错误工具	工具描述不清晰，或规划逻辑进入死循环	查看调用日志，检查工具描述里的触发条件	增加最大迭代次数；优化工具描述；加入失败熔断
调用工具后无法解析结果	工具返回了预期外的格式	打印工具返回值，检查 Agent 对结果的解读提示词	增加结果解析步骤，先让模型把工具输出转为标准格式，再做综合分析
Agent 响应太慢	多步骤串行调用模型，且每步都用了大模型	查看日志中的每一步耗时	引入模型路由，简单步骤用小模型；并行的工具调用改成并发执行
上线后效果和测试环境不一致	测试数据和真实数据分布差异大	对比测试集和真实输入样本	扩大评测集样本量；增加线上日志回流
Agent 执行了危险操作	工具权限控制不足	检查工具注册表里的权限声明	所有工具必须显式声明权限范围，关键操作加入人工审批

9. 总结与后续学习方向

Jeff Dean 的访谈里有一个观点，我认为是所有开发者都值得记住的：AI 的进步不应该以“模型能生成什么”来衡量，而应该以“模型能帮你完成什么”来衡量。

这句话的含义很清晰。过去我们关注的是模型的“上限”，也就是它能写出多好的文章、能生成多复杂的代码；但接下来我们要关注的是模型的“闭环”，也就是能不能自己发现问题、制定计划、调用工具、修正错误，最终把一件事做成。

对我们开发者来说，这意味着一个朴素但重要的行动建议：开始把大模型当作一个需要“工程化协作”的系统组件，而不是一个“无所不能的神器”。多去研究它的工具调用协议、输出稳定性、纠错机制、成本控制，多花时间搭建自己的 Agent 实验环境。

从“会写代码”到“会调用模型”，再到“会设计让模型自主行动的系统”，这是这轮范式升级对开发者的新要求。Jeff Dean 和他的团队已经在 Google 的基础设施里布局了这条路径，而作为应用层开发者的我们，完全可以更早一步，把 Agent 技术用在今天就能解决的业务问题上。

这套课程从概念、架构到工程实践都覆盖到了，建议收藏备用。接下来，可以先选一个小任务，花一个周末时间把它做成 Agent 原型，真实感受一下“模型自己做决定”和“模型给你提建议”的区别。

AI范式升级：从预测下一个词到自主完成任务的智能体