在 AI 资讯群里看到这句话“这人谁啊哈萨比斯都让位了。”第一反应不是去猜“谁让位”而是先确认一件事哈萨比斯是谁他目前在哪个位置为什么他的“让位”会成为一条值得讨论的标题哈萨比斯通常指 Demis HassabisGoogle DeepMind 的联合创始人兼 CEO。他因 AlphaGo、AlphaFold 等成果成为 AI 领域最有代表性的研究者之一。如果连他都被说成“让位”那这个标题背后一定指向某种更深层的行业变化——可能是某个新模型在排行榜上超越了 DeepMind也可能是某位新研究者在舆论场上压过了他的声量。这篇文章不急着给“这人到底是谁”下结论。因为仅凭一句话标题很多信息都无法确认。更实际的做法是把这个标题当成一个引子拆解哈萨比斯和 DeepMind 的技术脉络解释“让位”这种说法为什么会流行再给出一套公开数据验证方法。读完你可以自己查清楚“让位”到底指什么以后遇到类似“xx 都让位了”“xx 都慌了”的 AI 热点也能用同样的方法判断真伪。文中的查询脚本基于 arXiv 和 Hugging Face 公开接口不需要 GPU不占显存轻量可跑。适合想持续跟踪 AI 行业动态、又不想被标题带偏的开发者。1. 核心信息速览项目说明关注对象Demis HassabisGoogle DeepMind 联合创始人兼 CEO标题来源中文 AI 资讯、短视频、自媒体对 AI 竞争格局的一种夸张表达“让位”常见含义模型排名被超越、某个新研究者声量更大、或媒体渲染的“新王登基”验证工具arXiv 论文接口、Hugging Face 模型库、Chatbot Arena 排行榜硬件要求无 GPU 也能跑只需要 Python 环境和网络连接显存占用0本文不涉及本地大模型推理接口能力arXiv API、Hugging Face API 均提供公开 HTTP 接口批量任务可写脚本定时查询多关键词保存结果到 CSV适合读者AI 研究者、开发者、科技媒体编辑、关注行业动态的爱好者这里的核心判断是AI 领域的“让位”通常不是职务意义上的让位而是注意力分配发生了变化。DeepMind 并没有因为某个新模型的出现就失去存在价值但公众话题中心确实会转移。2. 哈萨比斯与 DeepMind 的技术里程碑先补背景。Demis Hassabis 是英国神经科学家、AI 研究者也是 DeepMind 的联合创始人之一。他早期做过游戏开发后来转向认知科学和人工智能研究。DeepMind 最广为人知的成果主要有几个方向。AlphaGo 是 DeepMind 在围棋领域发布的 AI 系统。2016 年 AlphaGo 与李世石的比赛让“人工智能战胜顶级棋手”从实验室话题变成了公共事件。2017 年 AlphaGo Master 又与柯洁进行了公开对局。这几次事件让 DeepMind 成为全球知名 AI 实验室之一。AlphaFold 则把 DeepMind 从棋盘游戏带到了科学研究领域。AlphaFold 的目标是预测蛋白质的三维结构。它在相关评测中的表现引发了生物学和药物研发领域的广泛关注。虽然具体技术细节在持续迭代但 AlphaFold 已成为“AI 推动基础科学”的代表案例。Gemini 是 Google DeepMind 与 Google Brain 合并后推出的多模态模型系列。Gemini 覆盖文本、图像、音频、视频等多模态输入输出直接对标 OpenAI 的 GPT 系列。它的发布让哈萨比斯在公共传播中不只是“AlphaGo 那个人”而是大模型竞争中的核心人物之一。从这些里程碑可以看出哈萨比斯的行业地位来自长期的技术积累而不是某一次单点突破。所以“哈萨比斯都让位了”这句话听上去戏剧性很强但离真实的技术评价还有很大距离。3. 为什么会出现“都让位了”这种说法“让位”是媒体传播中非常典型的情绪化表达。它把技术竞争压缩成一场“王座更替”的叙事游戏。这种叙事通常有几个触发条件。第一某个新模型在公开排行榜上超过了 DeepMind 发布的大模型。比如 Chatbot Arena、LMSYS 排行榜、MMLU、GPQA 等基准测试一旦出现新榜首就很容易出现“xx 把 yy 拉下马”的传播句式。问题在于排行榜只代表模型在某类测试上的表现不代表它全面领先。模型的分辨率、上下文长度、推理成本、部署便利度等因素都不会直观体现在一个分数里。第二某位新研究者或新团队的论文、产品获得了超出预期的关注度。比如某个年轻学者带着一篇高影响力论文走红自媒体可能会用“哈萨比斯都让位了”来形容“新一代已经把老一代盖过去”。但这种说法忽略了科研体系的连续性——很多新成果本身就建立在前人的基础上很难用“替代”来形容。第三行业会议、奖项提名、高管任命等信息被误读成“下台”。哈萨比斯依然是 Google DeepMind 的 CEO没有公开信息显示他从这个职位上离开。所以“让位”更可能来自标题党而不是职务变动。还有一个隐藏因素AI 的公众讨论正在从“技术原理”转向“江湖排位”。观众更需要一个简单又刺激的故事“让位”天然比“模型在某个评测集上超过 baseline 3 个百分点”更有传播力。作为读者看到这类标题时要记住它只能用来提示“这个话题可能有热度”不能当作“技术事实已经被确认”来看待。4. 环境准备搭建一个 AI 热点查证工具既然标题不可全信那就自己查。下面这套查证工具不需要厚重环境也不需要显卡只要一个能联网的 Python 环境就能跑。主要目标是用 arXiv 查最新论文看是否有高影响力的新研究者或新方向。用 Hugging Face 查热门模型看是否有新模型下载量异常高。用公开排行榜对比模型排名判断“超越”是否真实存在。推荐环境是 Python 3.8 及以上版本。需要安装 requests 和 pandas。如果只是跑少量请求pandas 可以不装但做批量保存时比较方便。pip install requests pandas网络环境需要能访问 arXiv 和 Hugging Face。如果访问不稳定可以调整超时时间增加重试机制或者使用 Hugging Face 的国内镜像服务。注意不要在这里引入任何非常规网络工具只做常规请求处理。这个脚本跑完以后你可以把搜索结果组合成一张“近期 AI 热点清单”用于判断“让位”是不是有真实依据。5. 用 arXiv API 查询最新论文arXiv 的接口是最稳定的公开学术接口之一。它允许按关键词、作者、分类、时间范围查询论文。我们这里用它来搜索最近一段时间内可能引发“让位”讨论的论文。arXiv 接口地址是http://export.arxiv.org/api/query参数通常包括search_query、start、max_results和sortBy。返回格式是 Atom XML需要用 Python 的 XML 模块解析。下面这段代码可以搜索标题或摘要中包含“AI agent”或“large language model”的论文并输出最近结果的标题、作者和发布时间。import requests import xml.etree.ElementTree as ET query_url http://export.arxiv.org/api/query params { search_query: all:\large language model\ OR all:\AI agent\, start: 0, max_results: 10, sortBy: submittedDate, sortOrder: descending } resp requests.get(query_url, paramsparams, timeout30) resp.raise_for_status() ns { atom: http://www.w3.org/2005/Atom, arxiv: http://arxiv.org/schemas/atom } root ET.fromstring(resp.text) for entry in root.findall(atom:entry, ns): title entry.find(atom:title, ns).text.strip().replace(\n, ) published entry.find(atom:published, ns).text authors [a.find(atom:name, ns).text for a in entry.findall(atom:author, ns)] link entry.find(atom:id, ns).text print(f标题: {title}) print(f发布时间: {published}) print(f作者: {, .join(authors[:5])}) print(f链接: {link}) print(---)这段代码最关键的一点是如果某个论文方向突然爆发它的“作者”和“提交时间”会集中在某个区间。你可以用这一点判断“让位叙事”是否真的和学术动态同步。如果直接访问 arXiv 不稳定可以在请求前加User-Agent头或者把请求超时调大。不要把失败原因无脑归为用户网络问题arXiv 接口偶尔也会限流。6. 用 Hugging Face API 查看热门模型学术论文能说明研究方向但“让位”这类话题更多来自模型产品和开发者讨论。Hugging Face 每天都有大量模型上传下载量和点赞数可以在一定程度上反映关注度。Hugging Face 提供了公开 REST API。最常用的两个查询是https://huggingface.co/api/models?searchxxx按关键词搜索模型。https://huggingface.co/api/models?sortdownloadsdirection-1按下载量排序。下面这段代码会搜索名称或描述中包含“agent”的模型并把前 10 个模型的下载量打印出来。import requests url https://huggingface.co/api/models params { search: agent, sort: downloads, direction: -1, limit: 10 } headers { User-Agent: hot-topic-checker/0.1 } resp requests.get(url, paramsparams, headersheaders, timeout30) resp.raise_for_status() for model in resp.json(): print(f模型ID: {model.get(id)}) print(f下载量: {model.get(downloads)}) print(f点赞数: {model.get(likes)}) tags model.get(pipeline_tag) or model.get(library_name) print(f类型标签: {tags}) print(---)Hugging Face 的search参数匹配的是模型 ID 和标签不是全文描述。所以如果你搜不到某个具体模型可能是模型命名和你的关键词不一致此时应该换成更宽泛的词比如llm、diffusion、text-to-video等。用 Hugging Face 看“谁热门”有一个问题下载量可以反映使用量但也可能被特定任务刷高。只能把它当成“关注度信号”不能当成“技术能力证明”。一个模型下载量超过 Gemini不代表它就是更好的模型。如果你的网络对 huggingface.co 访问不稳定可以在请求时使用配置好的镜像域名或者直接查询镜像站的上传模型列表。不要随意修改Host头那很容易触发 Cloudflare 拦截。7. 查看聊天机器人排行榜Chatbot Arena / LMSYS论文和模型库是“供给侧”排行榜才是“对战结果”。Chatbot Arena 是目前 AI 社区引用最多的模型对战平台之一。它让用户对两个匿名模型的输出进行盲评最终生成模型排名。要查看当前排名最简单的方式是打开 Chatbot Arena 官网页面页面里通常有按综合得分排序的表格。你也可以按类别筛选比如只看“英语”“代码”“长文本”或“中文”维度。在命令行脚本里一般不直接爬取排行榜页面因为页面结构和反爬策略可能变化。更稳妥的做法是把你关心的模型名称列出来然后通过聊天接口做几个固定问题的小样本对比形成自己的“微测评”。比如可以准备一组测试题包含代码生成、中文常识、逻辑推理、长文本总结四类。每个模型跑一遍记录回答质量和响应时间。这样做不需要依赖第三方排名能更贴近实际使用感受。questions [ 用 Python 写一个快速排序并解释时间复杂度。, 解释什么是 RAG并说明它适合解决什么问题。, 写一段 200 字的夏日海边文案不要用陈词滥调。, 推理题有三个盒子一个里面是苹果一个里面是香蕉一个里面是苹果和香蕉。所有标签都贴错。只能打开一个盒子看一次如何确定所有盒子的内容 ] for model_name in [模型A, 模型B]: print(f当前测试: {model_name}) for i, q in enumerate(questions): print(f问题{i1}: {q}) # 这里替换成实际模型的调用 API # response call_model_api(model_name, q) # print(response) print(---)这段代码只是一个占位模板。实际调用时你需要替换成可用的模型 API并注意不同模型的上下文长度、收费规则和请求频率限制。排行榜给你的只是一个先验预期真正合不合适要在你自己场景里测过才知道。8. 批量查证与每日自动跟踪如果你需要持续跟踪“哈萨比斯让位”这类说法是否反复出现可以把它做成一个简单的批量任务。思路是准备一组关键词每天定时跑一次 arXiv 和 Hugging Face 查询把结果保存到 CSV 文件。这样你就能在几周后回看“热点”到底是被真实论文推动还是被自媒体放大。crontab -e0 9 * * * cd /path/to/your/project python track_hot_topics.py run.log 21脚本内部可以这样组织import csv import datetime import requests keywords [AI agent, AGI, reasoning model, multi-modal] results [] for kw in keywords: arxiv_params { search_query: fall:{kw}, start: 0, max_results: 3, sortBy: submittedDate, sortOrder: descending } try: r requests.get(http://export.arxiv.org/api/query, paramsarxiv_params, timeout30) r.raise_for_status() results.append([datetime.date.today(), kw, arxiv, r.text[:200]]) except Exception as exc: results.append([datetime.date.today(), kw, arxiv, ferror: {exc}]) with open(hot_topics.csv, a, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerows(results)注意CSV 里保存返回头的开头 200 个字符并不是最佳实践实际使用时应保存论文标题和链接。这里只是演示批量任务的流程。批量查询时一定要控制请求频率。arXiv 官方明确建议请求间隔不要过密通常每秒 1 次左右比较安全。Hugging Face 对匿名请求也有频率限制。如果请求过快会收到 429 Too Many Requests需要等待一段时间再重试。9. 常见问题排查问题现象可能原因排查方式解决方案arXiv 请求超时网络访问不稳定或接口临时限流打印异常信息确认是否偶发增加 timeout 或重试次数Hugging Face 返回 429请求频率过高查看响应头 Retry-After降低请求频率或增加 sleepHugging Face 返回 401需要认证但未配置 token检查 API Key在请求头加入 Authorization: Bearer xxx论文结果不相关关键词太宽泛查看返回标题和作者加引号精确匹配或限定分类模型下载量看不出“谁更火”忽略了模型用途差异同时比较 pipeline_tag 和 downloads按类别分别排序排行榜页面结构变化页面改版或反爬策略更新查看页面源代码是否可读改用官方 API 或人工查看这些排查项的核心思路是先看异常是来自网络层、参数层还是服务端限流再决定如何处理。不要一遇到失败就反复重试很多接口的限流是累积的越重试冷却时间越长。10. 使用边界与内容安全用公开接口做热点查证是合规的但有几个边界要注意。arXiv 和 Hugging Face 的接口都受服务条款约束。批量请求要设置合理频率不能把公共接口当成无限数据源。不要把抓到的数据直接用于商业分发尤其不要大规模重包装论文摘要或模型描述。如果查询结果涉及具体研究者不要轻易给人家贴上“取代哈萨比斯”的标签。论文作者和模型开发者有自己的工作积累一条热搜不代表一次完整的学术评价。涉及人脸、声音、姓名等信息时要特别注意隐私和名誉风险。如果你做的是模型对比测试要用自己的账号和合法授权调用 API不要尝试绕过服务商限制。生成内容如果用于文章或视频需要标明来源如果涉及版权素材要提前确认授权。这篇文章里的所有脚本都只做公开数据的基础查询不涉及任何破解、逆向或绕过机制的手段。11. 总结“这人谁啊哈萨比斯都让位了”这句话听起来比大多数论文摘要都刺激但它只能作为传播信号不能作为技术结论。哈萨比斯依然是 DeepMind 的代表人物DeepMind 也依然是 AI 领域最前沿的实验室之一。所谓“让位”更多是公众注意力从旧叙事转向新叙事的自然过程。对开发者来说与其被动接收标题不如用 arXiv 查最新论文、用 Hugging Face 看模型趋势、用排行榜和自测建立判断标准。这套方法不需要 GPU不占显存只需要 Python 脚本和一点耐心。第一次跑通 arXiv 搜索后你会明显感觉到AI 圈并不是一场“王座游戏”而是很多人在不同轨道上同时推进。真正值得关注的不是谁让位而是哪些新工具真的能解决你的问题。