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、MCPModel Context Protocol这类标准化协议模型可以像人类使用 API 文档一样动态发现并调用工具。第三评测方式在变。以前评测模型就是“考试”拿一堆选择题、简答题去问它。现在业界开始用“实际完成任务”的方式来评测比如让它自己登录网站、查资料、提交表单、发邮件。这种评测方式逼着模型从“会说话”走向“会做事”。所以 Jeff Dean 说的“下一次范式升级”不是一个突然冒出来的新点子而是当基础模型能力、工具生态、评测标准都到达临界点之后必然会出现的转向。3. AgentAI 从“回答者”变成“执行者”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( imagescreenshot_path, promptfFind the button containing {target_text} and return its coordinates. ) # 2. 解析模型返回的坐标 x, y parse_coordinates(vision_result) # 3. 使用浏览器自动化工具执行点击 browser.click(xx, yy)需要注意多模态模型的坐标定位在复杂界面上并不总是准确真实应用中通常需要多轮反馈校准。但这一示例代表了一个趋势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( modelgpt-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 循环”的完整链路。# 安装 OllamamacOS/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 原型真实感受一下“模型自己做决定”和“模型给你提建议”的区别。 
长河君 · 2026/8/30 5:36:00 · 阅读 1.2k 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、MCPModel Context Protocol这类标准化协议模型可以像人类使用 API 文档一样动态发现并调用工具。第三评测方式在变。以前评测模型就是“考试”拿一堆选择题、简答题去问它。现在业界开始用“实际完成任务”的方式来评测比如让它自己登录网站、查资料、提交表单、发邮件。这种评测方式逼着模型从“会说话”走向“会做事”。所以 Jeff Dean 说的“下一次范式升级”不是一个突然冒出来的新点子而是当基础模型能力、工具生态、评测标准都到达临界点之后必然会出现的转向。3. AgentAI 从“回答者”变成“执行者”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( imagescreenshot_path, promptfFind the button containing {target_text} and return its coordinates. ) # 2. 解析模型返回的坐标 x, y parse_coordinates(vision_result) # 3. 使用浏览器自动化工具执行点击 browser.click(xx, yy)需要注意多模态模型的坐标定位在复杂界面上并不总是准确真实应用中通常需要多轮反馈校准。但这一示例代表了一个趋势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( modelgpt-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 循环”的完整链路。# 安装 OllamamacOS/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 原型真实感受一下“模型自己做决定”和“模型给你提建议”的区别。