19. 免费运行 Nemotron 3 Ultra——Hermes 实操指南

Nous Research 加入了 NVIDIA 牵头的 Nemotron Coalition，并与 Nebius 合作把 Nemotron 3 Ultra 在 Nous Portal 上免费开放了两周。本篇用一条最短路径，带你把这款前沿模型跑进自己的 Hermes Agent。

限时福利与那个关键的 :free 后缀

这次免费窗口是 6 月 4 日到 6 月 18 日，模型变体是 nvidia/nemotron-3-ultra:free。有一个细节必须强调：是那个 :free 后缀让它留在免费档位。如果你只选了 nvidia/nemotron-3-ultra 而没带 :free，就会按付费档计费。官方文档里反复提醒这一点，说明踩坑的人不少——选模型时一定核对完整字符串。

路线 A：桌面应用（最省事）

如果你不想碰终端，桌面应用是最丝滑的路径。

1. 下载安装 Hermes Desktop 的 macOS 或 Windows 安装包，首次启动它会自动完成剩余设置，通常不到一分钟。
2. 应用打开后看到 “Let’s get you set up” 界面，点 Nous Portal（标着 Recommended）。浏览器会弹出，注册或登录 Nous Portal 账号，选 Free 计划，授权 Hermes，应用自动连上。
3. 连接完成后会显示一个 Default 模型卡，点 Change，搜索 nemotron 3 ultra，选中带 Free tier 标记的变体：nvidia/nemotron-3-ultra:free。
4. 点 Start chatting，开始对话。

全程零终端操作，适合第一次接触 Hermes 的同学。

路线 B：命令行

终端党可以走命令行。macOS/Linux/WSL2/Android 上一行命令装好：

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Windows 上对应：

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

想先审一眼脚本再跑也支持——下载 install.sh 检查后执行。装完记得 reload shell：source ~/.bashrc 或 source ~/.zshrc。

接着跑 hermes setup 选 Quick Setup，Hermes 会打开浏览器标签并等你完成后续步骤。在浏览器里创建/登录 Nous Portal 账号、选 Free 计划，提示连接 Hermes 时点 Connect。回到终端，从模型列表里选 nvidia/nemotron-3-ultra:free，走完剩余 Quick Setup 提示，运行 hermes 就能开聊。

之后想再切回来

如果 Hermes 已经配了别的模型，切换很方便。桌面应用打开模型选择器，搜 nemotron 3 ultra 选 Free tier 变体即可。CLI/TUI 里在会话中直接 /model nvidia/nemotron-3-ultra:free，或运行 /model 打开选择器从列表挑。记住同样要带 :free 后缀。

故障排查

列表里看不到这个模型？先确认 Nous Portal 连接已完成、且账号在 Free 计划上，CLI 里 hermes portal info 能确认你已登录且走的是 Nous 路由。选错变体了？重新选 nvidia/nemotron-3-ultra:free，:free 后缀是留在免费档的必要条件。浏览器没自动打开、或者你在远程主机上跑 CLI？参考 OAuth over SSH / Remote Hosts 的端口转发方案。

Frequently Asked Questions

Q：活动已经结束了（6 月 18 日之后），这篇指南还有意义吗？

A： 有意义，而且价值不止于这一次活动。首先，整套安装和 Portal 接入流程对任何 Nous Portal 模型都通用——你照着做一遍，以后换别的模型只是选不同变体。其次，:free 后缀这个细节揭示了 Nous Portal 的计费逻辑：同一模型可能有多个档位，免费窗口结束后你仍可能在列表里看到它，只是切到付费档。建议把这篇当作"如何用 Hermes 接 Portal 模型"的标准操作手册来读，活动本身只是个练习场景。

Q：我已经用别的模型配好了 Hermes，怎么最快验证 Nemotron 3 Ultra 跑通？

A： 最快的方式是在会话里直接 /model nvidia/nemotron-3-ultra:free 切换，不用重启、不用重装。切完随便问一句让它自报模型名，或跑一个需要工具调用的任务看响应是否正常。要确认是否真的走 Portal 路由，CLI 里 hermes portal info 会显示登录状态和路由信息。一个常见坑：切了模型但没带 :free 后缀，结果走付费档扣了额度——切之前务必核对完整模型字符串。

Q：远程服务器上跑 hermes setup，浏览器打不开怎么办？

A： 这是 SSH/远程主机场景的典型问题，OAuth 回调需要一个能被浏览器访问的本地端口。官方文档有 OAuth over SSH / Remote Hosts 的端口转发方案，核心思路是用 SSH 端口转发把远程的回调端口映射到本地，让浏览器完成授权后回调能到达远程的 hermes 进程。具体做法是在 SSH 连接里加 -L 参数转发对应端口，然后本地浏览器打开授权 URL。如果用得频繁，建议在 ~/.ssh/config 里固化转发配置，省得每次手敲。

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

• 主题：AI原生Hermes自进化智能体系统
• 时间：2026年8月22-23日
• 形式：线上直播
• 内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。联系邮箱：hiheartfirst@gmail.com

技术交流

• 联系人：Sam
• Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/

005 | 元组可见性与更新的幻象

导读：上一篇把"事务 ID + 快照"两根支柱立好了。本篇顺着支柱往下走：先手把手带你走一遍每条元组都要过的可见性检查——它只有"是、否、再看看"三种答案；再揭开 SQL 里最容易骗人的动词 UPDATE，看清"一个 UPDATE 等于一次 INSERT 加一个墓碑"这一幻象背后真正的物理戏法，以及它给 schema 设计埋下的伏笔。

元组可见性

一条查询从页里读出一个元组。在 Postgres 把它返回给你之前，执行器要跑一遍可见性检查。这个检查只回答一个问题：给定我的快照，这个物理元组我能不能看？答案是"能"、“不能”，或者"再仔细看看"。而且规则不论这个元组是来自顺序扫描、索引查找，还是连接探测，全都一样。

这套算法在 Postgres 源码里叫 HeapTupleSatisfies多版本并发控制，叫了二十年。名字不友好，逻辑一点不复杂。

用大白话讲一遍检查

就当你是在亲手处理一个元组，一步步走。

第 1 步：插入者提交了吗？ 看 xmin。借助提交日志查出这个事务是提交、中止，还是还在飞。

• 如果它中止了，这个元组其实从来没被真正写过。跳过它。
• 如果它还在飞、而且不是你自己的事务，你没法看到还没发生过的写入。跳过它。
• 如果它已提交，继续。

第 2 步：插入者对你的快照可见吗？ 把 xmin 跟你的快照比。如果插入事务在快照开始之前就已提交，你能看到这次插入。如果它在你的在飞列表里，你看不到（它在你快照拍下时还在飞，所以它的影响对你不可见）。如果它在你快照的 xmax 之后，同理：不可见。如果这次插入对你的快照不可见，那这个元组就轮不到你读。跳过它。

第 3 步：这个元组是不是已经被删除或更新"删没了"？ 看 xmax。如果是零，元组活着、可见。返回它。如果非零，对那个删除事务重复一遍"提交 + 快照"检查。

• 如果删除者中止了，这次删除从未生效。元组对所有人都还活着。返回它。
• 如果删除者还在飞（而且不是你），这次删除对任何人都还不算可见。返回它。
• 如果删除者已提交、且对你的快照可见，那么从你的角度看这行已经死了。跳过它。
• 如果删除者的 xid 在你的 xip 列表里（你快照拍下时它在飞），那么不论它现在提交与否，快照都把它的效果当作不可见。在你看来，这行还活着。返回它。

两个事务 ID、一个快照、少量提交日志查询，换一个"是/否"。

三个真实案例

把它落到具体数字上。假设你的快照是 xmin=100, xmax=105, xip={101,103}。

案例 A。 元组 xmin = 90, xmax = 0。插入者——事务 90——早在你快照之前就提交了。元组没有删除者。可见。

案例 B。 元组 xmin = 90, xmax = 101。插入者已提交、对你可见。删除者在你的在飞列表里：事务 101 在你快照拍下时还在飞（它在 xip 列表里）。对你快照而言，不管它实际到底有没有提交，它都仍当作还在飞看待。可见（在你眼里还活着）。

案例 C。 元组 xmin = 90, xmax = 102。插入者已提交且对你可见。102 在 xmin 和 xmax 之间、却不在 xip 列表里，所以它算提交且对当前快照可见。这次删除对你可见。从你的角度元组已死。不可见。

这种手工推演你一辈子大概只做一次——就是头一回调试"这查询怎么看到这堆东西"的谜题时。做完一次，规则就成了肌肉记忆。要紧的不是背下来，而是内化一点：可见性是逐元组、逐快照的计算，而不是逐表、逐逻辑行的属性。

这套算法对查询意味着什么

有几条结论从算法里自然掉出来，值得单独拧开看。

每一次读都要付可见性检查的代价。 一个 SELECT count(*) 若要知道有几行活着，没法只信索引。索引不懂可见性，它指向每一个元组版本，死的活的都指。执行器必须访问堆（或可见性映射）才能确认每个元组对当前快照可见。这就是为什么 Postgres 上的 count(*) 出名地比那些在元数据里维护行计数的数据库慢——你要的那个数，看是谁在问。

索引会"撒谎"。 每一个物理元组在索引里都有一条，包括那些删除事务早已提交的死元组。索引会"乐意"地告诉你"ctid (5,12) 上的那行匹配你的过滤条件"，结果你访问堆才发现是个死元组。这种错配，正是为什么索引扫描总要去堆上确认可见性。可见性映射是那层优化：一张逐页位图，记录哪些堆页只含对所有事务都可见的元组，于是当整页都可见时，仅索引扫描可以跳过堆访问。

长事务把历史当人质。 你快照的 xmin 是系统见到的、还在飞的、最小那个事务。任何删除 xmax 大于那个 xmin 的元组都可能仍被需要。VACUUM 不能回收它。所以一个两小时前启动、至今还没提交的事务，正在悄悄阻止 Autovacuum 在数据库里每一张繁忙表上释放空间。

警告：最常见的、生产环境里非预期膨胀的成因，就是一个被忘掉的 BEGIN; SELECT ...; 会话里敞开的事务。查询是空闲的，事务不是。请设置 idle_in_transaction_session_timeout。请设置 statement_timeout。别指望你的应用代码自己会关事务。

你能从 psql 里看到什么

两条查询就能把它看清楚，无需任何工具：

-- 看看 Postgres 内部用的可见性头信息。
SELECT xmin, xmax, ctid, id, body
FROM reviews
LIMIT 5;

-- 看当前事务正跑在哪个快照下。
SELECT pg_current_snapshot();

你现在读到的，正是可见性检查在读的同一批数字。从另一个会话跑一个更新，再回头查第一个会话。看老版本上的 xmax 变了、又冒出一个带新 ctid 的新元组。当你在自己键盘上亲眼看着这一切发生时，多版本并发控制 的机制就不再是抽象的了。

---

更新的幻象

更新是 SQL 里最会骗人的动词。这个关键字暗示"就地编辑"。但在 Postgres 里的现实，是一段精巧的小舞步：把旧行复制到一个新位置，把旧的那个标记为死，把新的写为活，再把所有索引都指向新位置。行从来没有被编辑过，它被替换了；而旧版本还留在磁盘上，等着 VACUUM。

在 Postgres 里，一个更新是一次插入加一个墓碑。 墓碑是盖在那个旧元组上的 xmax。插入是那个带着崭新 ctid 和崭新 xmin 的新元组。这两个动作在同一事务里原子地发生，而上一篇里的可见性规则把它们缝成了一副"从应用看就像是就地编辑"的样子。

重要提示：事务进行中，旧元组的 xmax 带的是仅锁的 infomask 位：它还活着，但被锁住了。一旦更新提交，这些位翻转，元组就死了。

眼看着它发生

最干净的验证办法，是盯着 ctid 挪动。

SELECT xmin, xmax, ctid, id FROM reviews WHERE id = 1;
-- xmin | xmax | ctid  | id
-- 738  | 0    | (0,1) | 1

UPDATE reviews SET body = body || '!' WHERE id = 1;

SELECT xmin, xmax, ctid, id FROM reviews WHERE id = 1;
-- xmin | xmax | ctid  | id
-- 901  | 0    | (0,2) | 1

ctid 从 (0,1) 变成了 (0,2)。这不是比喻。新元组就在同一页上另一个物理位置。(0,1) 那个旧元组还在原地，被标记为死，xmax = 901，对任何"快照在 901 提交之后拍下"的人都不可见。VACUUM 最终会走这个页，把 (0,1) 的槽位回收复用。

如果当前页装不下新元组，Postgres 就把它写到另一页上，ctid 变化更夸张：比如说从 (0,1) 到 (57,3)。行的逻辑身份没变，物理地址变了。

正是这种移动，让"物理布局在写入下漂移"成了 Postgres 里的一桩事实。一张起初按插入顺序干干净净聚簇的表，更新一个月后就会像战场：活元组散落在各页之间，死元组填在缝隙里，当初的排序早不知去向。

那索引怎么办？

Postgres 里每一条索引项都是一个 (value, ctid) 对。当 UPDATE 把一个元组搬到一个新 ctid，凡覆盖该表任何一列的索引都需要一条指向新位置的新项。十二个索引？每次更新就是十二条新索引项。 这笔账在重更新工作负载下极其残酷，也是人们看到 Postgres 的表在一次写入猛冲后膨胀得超出预期的原因之一。

有一个优化能缓解它，叫 HOT（Heap-Only Tuple）。如果一次更新只改了未被任何索引覆盖的列，并且新元组能和旧元组落在同一页，Postgres 就完全跳过写新索引项。旧元组被打上 HEAP_HOT_UPDATED 并向前指向新元组；新元组被打上 HEAP_ONLY_TUPLE。被索引的那个 ctid 上的行指针在链条推进时一直有效，所以索引查找先落在行指针上，顺着链一路跟到活版本。

HOT 就是一次"只写一页"的更新和一次"写十三页"的更新之间的那条分界线。条件很严格：

1. 没有索引列被改。 一旦碰到任何一个被索引覆盖的列，HOT 关掉。
2. 新元组装得下同一页。 一旦页装不下，新元组去了别的页，链就断了。

HOT 资格是逐索引列判定的：如果每个索引列的新值与旧值二进制相等，那么即使你写的是 UPDATE … SET indexed_col = indexed_col，HOT 也照常适用。检查的是索引列本身，而非你到底碰没碰这行。

这两条条件会引出两条后果，而这两条后果都在塑造生产环境的 schema 该怎么设计。

第一条是 fillfactor 在重更新表上很重要。 fillfactor 是一个逐表设置，告诉 Postgres 在插入时把每页装多满。默认是 100%，意味着每页都塞满。把一张频繁更新的表降到 80 或 70，你就为 HOT 更新能落在同一页留出了余地。

第二条是加一个多余的索引能毁掉更新性能。 那个给"以防万一"的列加索引、又每次写入都更新这列的团队，等于签字把这张表的 HOT 永久关掉。读快了 5%，写慢了 50%。这种交易我见过太多次，都是无意中做出来的。

重要提示：有热点更新路径的表（一小撮行被每分钟更新上千次）是 多版本并发控制 的代价砸得最狠的地方。每一次更新产生一个死元组。VACUUM 得跟上。索引得跟上。如果 Autovacuum 没法像你的应用造死元组那样快地把它排走，表就膨胀得比它收缩得还快，有一天机器磁盘就满了。

关于原子性的一个小谎

"一个 UPDATE 是一次 INSERT 加一个墓碑"这话是真的，但比现实稍微干净了一点。Postgres 的这个操作是在行锁下做的，所以对同一行的两个并发更新不会竞速。第一个写者拿锁。第二个写者等。第一个提交后，第二个看到新元组再决定怎么办——怎么决定取决于隔离级别：

• 读已提交 会顺着链走，对着新版本把 WHERE 子句重新评估一遍。
• 可重复读 会抛一个序列化错误。

写者是会阻塞写者的——当他们改的是同一行。 读者仍然不阻塞写者，写者仍然不阻塞读者。多版本并发控制 的契约依旧成立；行级锁负责"写者对写者"那一部分，而且它又窄又短命。

这对 schema 设计意味着什么

趁人在这里，捞几条实操要点出来。

如果某列被频繁更新，给它建索引前三思。 索引不是免费的，你可能在替整张表关掉 HOT。

如果某表被频繁更新，把 fillfactor 调到 100 以下。 80 是个不错的默认值。多花点磁盘，换回 HOT。

如果某行被频繁更新，问一句：高变动的那部分能不能拆到另一张表里？ 一张 reviews 表，既有 body 列又有 view_count 列，对 HOT 是个杀手——因为每次浏览都会 bump view_count。把 view_count 挪到它自己的表里，要么干脆删掉、改成从 view_events 聚合，于是 reviews 表就从"更新风暴靶子"变成了"读多写少"。

---

下一篇： 006-删除是墓碑与 多版本并发控制 的代价

---

常见问题答疑（学员答疑）

Q1：博客说"索引不懂可见性"，那索引扫描每次都要去堆里确认一遍？岂不是很慢？

是的，普通索引扫描确实需要回堆检查可见性——这就是 Postgres 的索引扫描比某些数据库慢的原因之一。但有一个优化：可见性映射（Visibility Map）。它是一个位图，记录哪些页"只包含对所有事务都可见的元组"。如果索引指向的元组所在页在可见性映射里标记为"全部可见"，就可以跳过堆访问，直接从索引返回数据——这就是"仅索引扫描"（Index-Only Scan）。问题在于，频繁更新的表会让可见性映射的标记频繁失效，导致仅索引扫描退化为普通索引扫描。所以写密集的表即使建了索引，count(*) 之类的操作也可能比预期慢。

Q2：博客说 UPDATE 等于 INSERT 加墓碑，那如果我更新一行100次，磁盘上就有100个版本？

理论上是的，但实际上有两层缓解机制。第一是 HOT 更新：如果更新没碰任何索引列、且新版本能塞进同一页，Postgres 不会写新索引项，死元组也能被"机会性修剪"在读取时顺手回收。第二是 Autovacuum：它会在后台扫描表，回收已经没有任何事务需要看到的死元组。所以实际磁盘上的版本数取决于"你产生死元组的速度"和"VACUUM 回收的速度"之间的赛跑。如果你更新速度远超 Vacuum 的处理能力，版本就会堆积，表就会膨胀——这就是热点行更新场景需要特别关注的原因。

Q3：fillfactor 降到80就能让 HOT 更新更多，那我直接降到50岂不是更好？

不一定。fillfactor 越低，每页预留的空闲空间越多，HOT 更新更容易落在同一页——这确实对写性能有利。但代价是：同样的数据需要更多的页来存储，全表扫描要读更多页，缓冲缓存能装的行数变少，内存利用率下降。打个比方：你把仓库的货架每层只放一半，搬货确实方便了，但你需要租更大的仓库。80是更新密集表的经验值，70也可以接受，低于50就很少有道理了。关键是根据你的更新频率和模式来调，并持续观察 n_tup_hot_upd / n_tup_upd 的比率。

大模型论文日报

2026年7月27日 · 本周最受关注 5 篇论文精选

本期精选本周大模型领域最受关注的 5 篇论文，覆盖交互式世界模型、生成模型理论、科研智能体、具身智能缩放定律、高效生成五大方向，并逐篇梳理方向、摘要、结论及对既有假设的挑战。

论文 01 · 交互式世界模型

ABot-World-0：单卡桌面 GPU 上的无限交互世界生成
方向：交互式世界模型 / 可进入、可控制、持续演化的生成环境

摘要：在单张桌面 GPU 上实时生成 720p 交互世界，最高 16 帧/秒、端到端延迟仅 1.2 秒。论文将视频生成、动作控制与长时稳定性统一到同一系统，并用 WorldExplorer 智能体在 AAA 游戏、仿真引擎与互联网视频中主动采集训练数据，再以训练反馈动态调整采集策略，形成多源数据闭环；系统拆解并逐一攻克了交互式世界建模的四个耦合瓶颈——数据获取、动作一致性、长时稳定性、实时性。

结论：首次在单张消费级 GPU 上实现“可进入、可控制、持续演化”的无限交互世界 rollout，标志着世界模型从实验室走向大众的转折时刻。

对旧假设的挑战：直接挑战“只要把视频生成模型规模做大就能得到世界模型”的流行假设——论文论证单靠扩展视频模型无法解决四个耦合瓶颈；同时打破“世界模型必须依赖大规模算力集群”的门槛认知。

论文 02 · 生成模型理论

TBSM 三体散射模型：一步生成质量超越多步扩散
方向：生成模型理论 / 扩散模型加速

摘要：提出“三体散射”机制，将传统需数十步去噪的扩散过程压缩为单步生成，并在图像生成基准上取得 FID=1.63，生成质量反超多步扩散模型。

结论：一步生成不仅更快，还可以更好，对生成模型“速度—质量”关系进行了一次根本性重写。

对旧假设的挑战：直接挑战扩散模型领域的主流共识——“多步迭代去噪是保证生成质量的必要条件”、“速度与质量天然存在不可兼得的权衡”。TBSM 表明在恰当的散射机制下，单步即可同时突破速度与质量两道天花板。

论文 03 · 科研智能体

AREX：从“搜索然后回答”到“搜索→审计→追问→更新”的递归研究 Agent
方向：科研智能体 / 检索增强研究自动化（arXiv:2607.00597）

摘要：由伊利诺伊大学厄巴纳-香槟分校、宾夕法尼亚大学、斯坦福大学与 Together AI 联合提出。针对“知道自己想找什么却说不清楚”的文献检索痛点，AREX 不再做一次性检索-生成，而是构建“搜索→审计→追问→更新”的递归闭环：先检索，再审计结果是否真正回应了研究意图，继而追问并修正查询，循环逼近真正所需的文献。

结论：将研究型 Agent 从“单轮问答”升级为“递归式自主研究”，在模糊意图下显著提升文献命中率，迈向真正的自主研究。

对旧假设的挑战：挑战传统 RAG“一次检索 + 一次生成”的范式假设，也挑战“检索等于关键词匹配”的直觉——证明只有引入审计与追问的递归过程，才能逼近真实的研究意图。

论文 04 · 具身智能

RynnBrain 1.1：具身 AI 同样遵循缩放定律，122B 模型横扫三项基准
方向：具身智能 / 视觉-语言-动作（VLA）缩放定律

摘要：在统一训练配方下将具身基座做到 122B 参数、10B 激活（122B-A10B），在 VSI-Bench、MMSI、RefSpatial-Bench 三项基准上全面超过 GPT 5.4、Gemini 3 Pro、Claude Sonnet 4.6 等闭源前沿模型。方法上用“接触点预测 + 原生 3D 定位”把表征拉向机器人操作，再用“统一动作空间 + 本体掩码”把 VLA 策略部署到三台异构真实机器人，联合训练成功率由 86.67% 进一步提升。

结论：验证“大就是好的”逻辑在具身 AI 同样成立，开源 122B 具身基座在多项基准上反超闭源前沿，并在真实机器人上部署成功。

对旧假设的挑战：挑战“具身/VLA 任务不适合一味 scale up、小模型即可”的怀疑；也挑战“闭源前沿模型不可超越”的惯性认知——开源大模型在具身基准上完成反超。

论文 05 · 高效生成

Mage-Flow：紧凑也可以很强，4B 模型 0.59 秒出图（微软）
方向：高效图像生成 / 紧凑模型协同设计

摘要：微软提出可复制的“Tokenizer-Backbone-System”三层协同设计方法论，仅用 4B 参数实现 0.59 秒出图，在速度与质量上同时具备竞争力。

结论：证明紧凑模型同样可以很强，并给出一套可复制的高效生成系统设计方法论，而非单纯依赖堆参数。

对旧假设的挑战：挑战“模型越大越强、高质量生成必然依赖大模型”的规模迷信；指出通过 Tokenizer、Backbone、System 三层协同设计，小模型也能逼近大模型表现。

本周研究主线：世界模型从“实验室原型”走向“单卡实时可用”；生成模型的速度-质量权衡被重新定义；研究型 Agent 从单轮问答走向递归自主；具身智能验证缩放定律并完成开源反超闭源；高效生成证明“紧凑也可以很强”。

大模型日报 - 2026年7月27日

本期精选 5 条大模型领域重大新闻，聚焦今日开源里程碑与产业格局变化。

——————————————————————————————

【新闻一】月之暗面 Kimi K3 今日正式开源：全球最大开源大模型，2.8万亿参数

7月27日，月之暗面正式开源 Kimi K3。该模型总参数达2.8万亿，是全球首个超2万亿级别的开源模型，也是目前全球参数最大的开源模型。采用 MoE 稀疏架构，配置896个专家模块，每次推理仅激活其中16个；支持100万token上下文窗口，原生支持视觉理解。在前端代码领域的 Arena AI Frontend Code Arena 以1679分登顶，马斯克评价"厉害"。发布后不到三天，美股AI板块市值蒸发约4700亿美元。

——————————————————————————————

【新闻二】中国大模型"撕裂"硅谷：中美AI差距缩至3~5个月，撼动OpenAI估值逻辑

中国开源模型迎来新一波发布潮，Kimi K3、Qwen3.8-Max、DeepSeek-V4 多模型密集发布，引发美国两派激辩。走访过 Kimi 的美国AI研究者内森·兰伯特判断，中美模型差距已缩短到3~5个月。OpenAI 与 Anthropic 等呼吁白宫"封杀"，而 Meta、英伟达等25家企业反对，黄仁勋、扎克伯格呼吁"快开源美国AI"。费城半导体指数较高点跌超20%，进入技术性熊市。

——————————————————————————————

【新闻三】阿里即将开源2.4万亿参数的 Qwen3.8-Max

阿里巴巴宣布千问3.8（Qwen3.8）将正式发布并面向全球开源，是开源模型中全球第二个参数破2T的模型。预览版已于7月19日在阿里云 Token Plan、Qoder 及 QoderWork 平台上线。该模型为多模态大模型，编码能力接近国际顶尖水平。

——————————————————————————————

【新闻四】DeepSeek-V4 正式版预计月底发布，国产开源"三剑客"格局成型

DeepSeek 继 R1 横空出世后，V4 正式版预计7月底发布，继续推进中国开源大模型发展。此前 DeepSeek 总参数为1.6万亿，本次迭代备受行业期待。随着 Kimi K3、Qwen3.8、DeepSeek-V4 接连落地，国产开源大模型"三剑客"格局加速成型，进一步缩小与国际顶尖闭源模型的差距。

——————————————————————————————

【新闻五】院士观点：赫尔佐格称AI下一个突破口是小型智能体协作

德国国家工程科学院院士、中国工程院外籍院士赫尔佐格荣获2025年度中华人民共和国国际科学技术合作奖。他在接受专访时表示，人工智能领域下一次重大突破绝非单一大型系统，而是众多小型专业化智能体协同运作。这一判断为大模型应用落地指明了新方向，与本届WAIC 2026"从参数比拼转向智能体商业化落地"的产业趋势相呼应。

2026年重磅喜讯！ 喜报！热烈祝贺Gavin大咖人工智能领域经典著作《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》中国水利水电出版社发行上市!

内容提要

本书内容基于作者在硅谷 ChatGPT 项目及企业培训中的实战经验凝练而成，重点介绍企业级 ChatGPT 开发的核心技术、案例研究及最佳实践。全书共 16 章，分为基础篇和实战篇两大部分。

基础篇：

介绍 ChatGPT 底层架构 Transformer 技术及源码实现、GPT 的内部机制及源码实现、GPT 系列模型原理与应用：从 GPT-2 到 GPT-4 等内容。

实战篇：

介绍基于 ChatGPT 的端到端语音聊天机器人项目实战，企业级 ChatGPT 开发的三大核心内部机制及案例实战，ChatGPT 插件的内部机制、源码及案例实战，ChatGPT 提示词开发实战，思维链及 ReAct 解析与实战，提示词本质解析及评估实战与源码解析，LangChain 大模型框架的七大核心组件及案例解析（上、下），LangChain 代理深入解析及源码解析，AutoGPT 源码解析及综合案例实战，使用 LangChain 构建问答聊天机器人案例实战，构建基于大模型的自治代理案例，Llama 2 模型与 LangChain 项目详解。书中每个知识点均配有相应的实现代码和实例。

本书适合有一定 Python 基础的 ChatGPT 爱好者阅读，主要面向从事大模型应用开发、机器学习、数据挖掘或深度学习的专业人员，高等院校相关专业的师生，以及相关领域的科研人员。

本书附赠丰富的学习资源，具体如下：①同步学习资源，即 16 集同步教学视频，视频时长共计约 1000 分钟；②教师授课的辅助资源，即 187 个案例知识点、15 个项目实战的全部源代码。

前言

在当今快速发展的科技时代，人工智能（artificial intelligence，AI）技术正以惊人的速度改变着人们的生活和工作方式。在这个新时代的浪潮中，大模型技术成为AI领域的一颗耀眼新星。ChatGPT作为大模型技术的重要应用之一，正在引领着人机交互领域的革新浪潮。本书将带领读者深入探索大模型新时代，通过ChatGPT实战项目和内部解析，深入掌握基于ChatGPT的大模型应用开发领域的关键技术，并解密ChatGPT的底层架构和实现原理。

本书主要内容

本书通过ChatGPT实战项目的方式，为读者呈现一个全面、系统的学习路径，从基础知识的介绍开始，带领读者深入了解ChatGPT的工作原理和实际应用。本书非常适合具备Python基础的读者学习。

全书共16章，分为基础篇和实战篇两大部分。
基础篇包括第1～3章；实战篇包括第4～16章。

第1章 ChatGPT底层架构Transformer技术及源码实现，详解最大似然估计、最大后验概率、贝叶斯Transformer及自编码与自回归语言模型的内部机制。

第2章 GPT的内部机制及源码实现，剖析GPT运行机制、掩码机制、Decoder-Only模式，详解数据流动生命周期及GPT-2源码。

第3章 GPT系列模型原理与应用：从GPT-2到GPT-4，解析ChatGPT提示词流程、GPT-2运行机制，可视化解读GPT-3/4的内部机制。

第4章 基于ChatGPT的端到端语音聊天机器人项目实战，涵盖ChatGPT API开发、前后端构建（ReAct+FastAPI）及项目优化。

第5章 企业级ChatGPT开发的三大核心内部机制及案例实战，解析企业级开发核心，演示Notion问答对话AI案例。

第6章 ChatGPT插件的内部机制、源码及案例实战，详解插件工作原理、检索插件源码及全流程开发实战。

第7章 ChatGPT提示词开发实战，基于LangChain框架的提示词、思维链、链式提示词及模型评估开发。

第8章 思维链及ReAct解析与实战，剖析思维链推理、ReAct技术原理、框架源码及案例实战。

第9章 提示词本质解析及评估实战与源码解析，包含问答评估、代理评估源码解析及提示词本质探讨。

第10～11章 LangChain大模型框架的七大核心组件及案例解析（上、下），涵盖模型、词嵌入、提示词、内存、回调、数据连接、代理等核心组件及聊天机器人综合案例。

第12章 LangChain代理深入解析及源码解析，详解代理工作原理及AutoGPT源码解析。

第13章 AutoGPT源码解析及综合案例实战，剖析AutoGPT内部机制及其在LangChain代理、内存、PromptGenerator中的应用。

第14章 使用LangChain构建问答聊天机器人案例实战，涵盖GPT-4代码生成全流程及LangChain开发实战。

第15章 构建基于大模型的自治代理案例，详解自治代理原理、工具、示例及开源实现源码。

第16章 Llama 2模型与LangChain项目详解，包括模型部署（Replicate）、Hugging Face/LangChain实践、检索增强生成及自定义提示词RetrievalQA开发。

本书特色

●深入探索，全面剖析。
本书涵盖ChatGPT案例实战、LangChain项目实战及框架源码解析等多个层面的内容。每章都深入探讨相关技术与案例，并提供源码解析，使读者能够全面了解ChatGPT和LangChain等技术的内部机制与开发原理，为实际项目的应用提供有力指导。

●实战剖析，项目揭秘。
本书每章都提供具体的案例实战与项目解析，引导读者通过实际操作和代码理解技术细节和底层逻辑。通过理论结合实践的方式，使读者能够更好地运用所学知识，深入了解项目和框架的实现细节。

●前沿突破，技术驱动。
本书介绍了一系列突破性的技术，如ChatGPT、LangChain、Transformer、Prompt、Llama 2、AutoGPT、BabyAGI、CoT、ToT、ReAct、MRKL等。通过对这些技术的深入剖析，读者可以了解相关技术的发展和应用，并了解它们在实际项目中的具体应用场景和效果。

●源码解析，细致讲解。
本书对LangChain框架的关键技术进行了逐行源码剖析。读者可以深入理解源码实现和机制原理，从而更好地理解技术细节和底层逻辑，并将其应用于实际开发工作中。

本书还为读者提供了丰富的知识和实用的技能，帮助读者在ChatGPT和LangChain领域取得突破性的进展。无论是初学者还是有一定经验的开发者，都可以从本书中获得有价值的学习资源。

配套资源

为便于教与学，本书配有同步教学视频（约1000分钟）、源代码、数据集、教学课件、教学大纲、安装程序。

作者简介

王家林

美国斯坦福大学计算机专业毕业。曾在美国担任硅谷顶级机器学习和人工智能实验室主任、杰出AI工程师及首席机器学习工程师，专精于对话式人工智能（conversational AI）。现担任硅谷某知名对话机器人公司CTO，自2019年起专注于基于红队测试（red teaming）的责任型AI（responsible AI），并热衷于构建生成式AI/大语言模型教练系统（GenAI/LLM coaching systems）。在硅谷任职期间，曾领导多个GenAI/LLM解决方案项目，成功平衡企业业务需求下的大模型推理（reasoning）系统与幻觉（hallucinations）及偏见（biases）风险的最小化。

作为数据科学、机器学习、NLP、ChatGPT及大模型等领域25本书的主要作者，王家林对利用人工智能提供解决方案，以及通过机器学习驱动的NLP与LLM流程帮助组织实现数据驱动决策充满热情。他曾领导Apple、PayPal、Chase Bank、Faethm、LinkedIn等公司的11个重大NLP项目。

在NLP、对话式AI、大数据及基于AWS的无服务器（serverless）技术方面，拥有丰富的机器学习咨询经验。

段智华

中国电信股份有限公司上海分公司高级工程师。长期从事大模型与智能体技术领域，专注Agentic AI、Harness Agent等前沿方向研究。

新书购买链接

《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》
购买链接：https://item.jd.com/15389212.html