Hermes Agent 语音模式——实时语音交互

大模型与Agent智能体

87人浏览 · 2026-07-25 06:45:13

大模型与Agent智能体 · 2026-07-25 06:45:13 发布

17. Hermes Agent 语音模式——实时语音交互

让 Agent 不再只停留在文字世界——Hermes 的语音模式把"开口说话、听见回复"的实时交互体验带到了 CLI、Telegram 和 Discord 三个主战场，本篇带你理清从安装、配置到调优的完整链路。

三种语音交互形态

Hermes 的语音能力并非单一入口，而是按场景分成三种形态。第一种是 CLI 交互式语音：在 hermes 启动后用 /voice on 开启，按 Ctrl+B 开始录音，松口后 Agent 自动转录、思考并用语音回复，录音还会自动重启进入连续对话。第二种是消息平台的自动语音回复：你在 Telegram 或 Discord 发文字，Bot 回文字的同时附带一段语音音频。第三种是 Discord 语音频道，Bot 直接"进房"旁听你的发言、处理后用语音回话，沉浸感最强。

安装与环境准备

语音依赖不在默认安装里，需要按需加装扩展包：

# CLI 语音模式（麦克风 + 音频播放）
cd ~/.hermes/hermes-agent && uv pip install -e ".[voice]"

# Discord + Telegram 消息（含 discord.py[voice]）
cd ~/.hermes/hermes-agent && uv pip install -e ".[messaging]"

# 高级 TTS（ElevenLabs）
cd ~/.hermes/hermes-agent && uv pip install -e ".[tts-premium]"

# 本地 TTS（NeuTTS，可选）
python -m pip install -U neutts[all]

系统层面还得装好 PortAudio（麦克风）、ffmpeg（音频转码）、Opus（Discord 编解码）和 espeak-ng（NeuTTS 后端）。macOS 用 brew install portaudio ffmpeg opus espeak-ng，Ubuntu/Debian 用 sudo apt install portaudio19-dev ffmpeg libopus0 espeak-ng。

STT 与 TTS 的提供商选择

语音链路分两段：语音转文字（STT）和文字转语音（TTS）。STT 方面，本地 faster-whisper 是免费首选，base 模型约 150MB，首次使用自动下载；若追求速度，Groq 的 whisper-large-v3-turbo 约 0.5 秒返回，有免费额度。TTS 方面，Edge TTS 免费且无需密钥、延迟约 1 秒，是默认回退项；ElevenLabs 音质最佳但付费。

一个关键点：只要装了 faster-whisper，CLI 语音模式的 STT 就完全不需要任何 API 密钥。付费的 Nous Portal 订阅则通过 Tool Gateway 同时搞定 LLM 和 OpenAI TTS，hermes setup --portal 一步到位。

CLI 语音模式的工作机制

按下 Ctrl+B 后，一段 880Hz 提示音标志录音开始，屏幕上会出现实时电平条 ● [▁▂▃▅▇▇▅▂] ❯ 直观反映输入强度。停止说话后，静音 3 秒自动结束录音，两声 660Hz 确认。之后音频经 Whisper 转录送入 Agent，若开启 TTS 则逐句流式朗读回复——它会把文字缓冲成完整句子、剥离 Markdown 和 <think> 块后再合成，所以你听到的是干净的自然语言。

静音检测是两阶段算法：先确认音频 RMS 超过阈值 200 至少 0.3 秒（允许音节间停顿），再等持续静音 3 秒触发结束。两个参数都能在 config.yaml 调。Whisper 偶尔会从背景噪音里"听"出"Thank you for watching"之类的幻觉文本，Hermes 用一份覆盖多语言的 26 条幻觉短语列表加正则来过滤。

Discord 语音频道：进阶玩法

想让 Bot 进入语音频道，得先补权限。在开发者门户给 Bot 加上 Connect、Speak 和 Use Voice Activity，更新后的权限整数是 309240908864，用它重新邀请 Bot（不会丢配置）。运行机器上必须装 Opus 编解码库。然后在文字频道发 /voice join，Bot 就加入你当前所在的语音频道。

进房后，Bot 独立监听每位用户的音频流，检测到 0.5 秒语音加 1.5 秒静音即触发处理，转录→Agent 流水线→TTS 语音回复。转录内容会同步打到文字频道里 [Voice] @user: ...，方便回看。Bot 播放 TTS 时会自动暂停监听做回声消除，避免自我复读。访问控制走 DISCORD_ALLOWED_USERS 白名单，未列出的用户音频被静默忽略。

配置参考与故障排查

核心配置集中在 config.yaml 的 voice、stt、tts 三段：

voice:
  record_key: "ctrl+b"
  max_recording_seconds: 120
  beep_enabled: true
  silence_threshold: 200
  silence_duration: 3.0

stt:
  provider: "local"
  local:
    model: "base"   # tiny/base/small/medium/large-v3

tts:
  provider: "edge"   # edge|elevenlabs|openai|neutts|...

常见坑：CLI 报 “No audio device found” 多半是 PortAudio 没装；Bot 在服务器频道不响应，默认要 @提及，用 DISCORD_REQUIRE_MENTION=false 或改走私信；Bot 能听到但不响应，先查 faster-whisper 是否装好或密钥是否配置；有文字但语音频道没声，多半是 TTS 提供商故障，Edge TTS 是兜底。

Frequently Asked Questions

Q：本地 faster-whisper 和云端 Groq Whisper，到底该选哪个？

A：看你的硬件和使用强度。faster-whisper 的 base 模型在普通笔记本上延迟可接受、完全免费、数据不出本机，适合日常 CLI 语音和隐私敏感场景。如果你追求接近实时的体验，或者机器算力有限，Groq 的 whisper-large-v3-turbo 约 0.5 秒返回、有免费额度，是性价比很高的选择。一个常见误区是上来就装 large-v3 本地模型——它质量最佳但很慢，在 CPU 上可能拖垮整条语音链路。建议从 base 起步，按需升级。

Q：Discord 语音频道里 Bot 总是复读自己的输出，怎么解决？

A： Hermes 内置了回声消除：Bot 在播放 TTS 时会自动暂停音频监听，正常情况下不会自我复读。如果你遇到这种情况，先确认 TTS 和监听是不是走的同一路音频设备，以及 Opus 编解码库是否正确加载。另外，语音频道里只有 DISCORD_ALLOWED_USERS 列出的用户才会被处理，Bot 自身的 SSRC 不会映射到白名单用户，所以即便监听漏一拍也不会把 Bot 的声音当成人话转录。日志在 ~/.hermes/logs/gateway.log，tail 一下就能看到监听暂停的时机。

Q：Whisper 转录经常冒出"Thank you for watching"这种无关内容，是模型坏了吗？

A：不是模型坏了，是 Whisper 对静音和背景噪音的已知幻觉行为。Hermes 已经用一份覆盖多语言的 26 条幻觉短语列表加正则来过滤，大多数情况下你感知不到。如果仍然频繁出现，可以从三方面入手：一是换个更安静的录制环境；二是调高 config.yaml 里的 silence_threshold（值越高，对微弱噪音越不敏感）；三是换一个更稳健的 STT 模型，比如 small 或 Groq 的 turbo 版。另外，录音前那声 880Hz 提示音如果被收进去也会触发幻觉，确认 beep 不会串入麦克风。

延伸阅读与交流

本文涉及的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/

003 | 可扩展性哲学与阅读指南

导读：前两篇拆解了多版本并发控制与进程模型两大架构赌注。本篇讲 Postgres 的第三个性格——可扩展性：它为什么"什么都能做"，又为什么这件事有代价。最后给出整套教程的阅读路线图、cinetrack 沙盒用法，以及一份新手最容易踩的坑清单。

可扩展性是一种哲学，不是一项特性

我加入过一个团队，他们的"简单 Postgres"安装拉了 14 个扩展：10 个是刚需，2 个把升级路径绑架了。Postgres"什么都能吸纳"的能力与这么做的运维代价之间的张力，直接来自 1986 年伯克利那篇原始 POSTGRES 研究论文——它主张数据库应当由用户扩展，而不只是由厂商扩展。Stonebraker 当年的赌注是：谁都没办法预见到每一种真实领域需要的类型、运算符和索引方法，所以数据库应该让人能加上它们，而不必重编译引擎。四十年之后，正是这个赌注给了 Postgres 它的性格，以及它最锋利的边缘。

从外部你不会把它看作一种"设计哲学"，你看到的是一个不停膨胀的特性目录：

地理类型；
时序分区；
向量嵌入；
全文搜索；
JSON path 查询；
B 树、哈希、GIN、GiST、SP-GiST、BRIN 和布隆索引（以 contrib 扩展形式发布）；
能从 MySQL、Redis、S3、或另一个 Postgres 读取的外部表；
自定义过程语言，让你可以用 Python、Perl、JavaScript 写函数。

这些几乎都不是从核心引擎里长出来的。 它们都从扩展开始，先变得流行，然后要么继续作为扩展存在，要么被吸纳进核心。

四个扩展接入面

"可扩展性"在 Postgres 里有一个具体的、技术性的含义。一共有四个地方，扩展可以不 fork 引擎就插进来：

类型。 CREATE TYPE 让你定义一种新的列类型，带上它自己的存储布局、输入/输出函数和运算符。PostGIS 加了 geometry，pgvector 加了 vector，JSON 当年也是先作为一个类型出现，后来才成为默认。
运算符和函数。 CREATE OPERATOR 和 CREATE FUNCTION 扩展 SQL 本身。区间上的 && 重叠运算符、向量上的 <-> 距离运算符——这些都不是核心 SQL，全是定义出来的运算符，被规划器视为一等公民。
索引访问方法。 这是让很多人意外的一个。Postgres 允许扩展通过索引访问方法 API 注册全新的索引实现：布隆过滤器、面向空间数据的 GiST、面向倒排索引的 GIN。规划器用与内置 B 树相同的那套机制来使用它们。
过程语言。 PL/pgSQL 是存储过程的默认语言，但 PL/Python、PL/Perl、PL/V8（JavaScript）等，都通过过程语言 API 插入。无论用哪种语言写的函数，对规划器来说都是一等公民。

这四个接入面加起来，正解释了为什么有人能不改一行 Postgres 核心代码就做出 PostGIS、TimescaleDB 或 pgvector。核心留出钩子，社区负责填。

-- Loading an extension is one statement.
-- Most extensions are header-and-shared-object packages installed via the OS,
-- then enabled per-database with CREATE EXTENSION.
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;

pg_stat_statements 按查询模板记录查询延迟；
pg_trgm 加上基于三元组的相似度匹配；
btree_gin 让你能在标量类型上建 GIN 索引。

三行，三种超能力。

没人愿意谈的代价

可扩展性不免费，这本博客也不会假装它免费。

第一个代价是"运维表面积"。 每一个扩展都是一个加载进后端进程的共享库。一个有 bug 的扩展可以让数据库崩溃；一个写得很烂的扩展可能泄漏内存，或持锁时间比你预期的长。RDS 和 Cloud SQL 故意限制你能装哪些扩展——云厂商不希望第三方共享对象在他们的舰队里运行。如果你的目标是 RDS，动手架构之前，先去查支持扩展列表。

第二个代价是"升级摩擦"。 大多数 Postgres 主版本升级，都要求每一个扩展同步升级。如果你的栈依赖 PostGIS，那么你的升级路径，会被 PostGIS 何时发布兼容版本卡住。本书的 cinetrack 技术栈只用核心发行版自带的扩展，外加一小撮维护良好的扩展。

第三个代价是"心智负担"。 同一个问题往往有三种解法，“什么是地道做法"这个问题的难度，远高于"只给一种方案的数据库”。全文搜索就是绝佳例子：内置 tsvector 加 GIN、pg_trgm 扩展、外部 Elasticsearch——三种都可行，这本博客覆盖其中两种。

你的每张 cinetrack 数据库应该装什么

这三个扩展，几乎在任何生产 Postgres 上都能值回票价：

pg_stat_statements：按查询模板聚合的查询延迟和调用次数。单一最有用的扩展。
pg_trgm：用于模糊文本搜索和加速 LIKE '%foo%' 的三元组相似度。
btree_gin 或 btree_gist：让你建出"标量列 + 数组/区间/JSON"的复合索引，适合那些"措手不及"的查询。

如果你的目标是自托管服务器，再装 pg_repack，用于在线重组表。在托管服务上，先看你能用什么再决定是否依赖。

小贴士
你可以用一条查询让运行中的数据库告诉你：哪些扩展已经加载、哪些是可用未加载的：
SELECT
  e.extname,
  e.extversion AS installed,
  a.default_version AS available
FROM pg_extension e
JOIN pg_available_extensions a ON a.name = e.extname;

cinetrack 沙盒

跑在同一个示例 schema 上。Cinetrack 是一个电影评论与 watchlist 应用：用户给电影评分、写影评、维护 watchlist、触发观看事件。

在 db-book-example 仓库的 chapter-NN/ 目录下都有一个自包含的代码项目，含：

一个 docker-compose.yml（Postgres，以及后期章节里的 pgbouncer、副本、Patroni 或 pgBackRest）；
一个 init.sql；
一个 seed.sql；
一个带注释的示例 queries.sql。

chapter-1 沙盒是最小版本：大约一百部电影、五十个用户、五百条评分、五十条影评。后续章节会扩展它：第 10 章为了 BRIN 演示需要一亿条 view_events；第 14 章需要分区表；第 26 章需要 WAL 归档。每章的 README.md 会说清"新加了什么"。

git clone https://github.com/umur/db-book-example
cd db-book-example/chapter-01
docker compose up -d
psql -h localhost -U cinetrack -d cinetrack -f init.sql
psql -h localhost -U cinetrack -d cinetrack -f seed.sql

三条命令，全新 Docker 镜像一分钟左右跑完。你此刻就坐在一个能跑的 cinetrack 数据库前的 psql 提示符旁，本篇每一条查询都从这里开始。

你的第一次多版本并发控制体检

跑一下这条：

-- Look at the system columns Postgres exposes on every row.
-- xmin: transaction that inserted this version.
-- xmax: transaction that deleted/updated this version (0 if alive).
-- ctid: physical location, formatted as (page, offset).
SELECT xmin, xmax, ctid, id, user_id, movie_id
FROM reviews
LIMIT 5;

你会看到每一行的 xmax = 0，因为没有影评被删过或改过。现在去改一条：

UPDATE reviews SET body = body || ' (edited)' WHERE id = 1;
SELECT xmin, xmax, ctid, id
FROM reviews
WHERE id = 1;

xmin 这次是你的更新事务。ctid 也会变：一条新元组永远写在一个新的物理位置。

补充解释：Postgres 有一个叫 HOT（Heap-Only Tuple） 的优化——当一次更新很小、且同一页上又有空闲空间时，它会跳过写新索引项：索引继续指向原来的行指针槽位，那个槽位再转发到新元组。但不管有没有 HOT，这一行都不是被原地改的——老版本还在那儿，盖着删除它的 xmax，VACUUM 之后才会回收它。

如何用好这套代码伴随

几条习惯能让这个伴随仓库物有所值。

规则一：真的去跑查询。 一本讲 Postgres 的博客，如果你只读不跑，等于在读另一本博客。正文里每一个代码片段都同时出现在 queries.sql 里，可以复制粘贴直接跑，注释与正文的叙述对齐。

规则二：读 EXPLAIN 输出。 大多数生产 Postgres 事故，都是不看查询计划的人干出来的。即使博客还没正式介绍 EXPLAIN，也请对每一条让你跑的查询都跑一下 EXPLAIN。你会开始吸收查询计划长什么样。

规则三：故意破坏。 cinetrack 沙盒是你的。删索引、塞一千万行、开着一个事务观察 VACUUM 停摆——这本博客会让你做所有这些事。你越早把数据库当成"可以拿来做试验的对象"，"专家级 Postgres"就越早变成你的肌肉记忆。

提示
cinetrack 代码住在一个公开的伴随仓库里。每一章的快照都是独立的，你在前面章节里瞎折腾，不会"污染"后面章节。

常见错误清单

把这一节当成"入门第一天就要避开的坑"。

1. 把 Postgres 当成"加了更多类型的 MySQL"

schema 迁得过去；心智模型迁不过去。Postgres 没有聚簇索引，每张表都是堆，并发写靠多版本并发控制而不是间隙锁解决。 你为 InnoDB 调过的查询，不是你应该在 Postgres 上跑的查询。

2. 假设连接很便宜

它们不便宜。每条连接都是一个 OS 进程，RSS 基线 5–10 MB（其中很大一部分通过 copy-on-write 共享，私有内存通常只有几 MB）。一个为"大量余量"调出来的连接池，会在还没真正服务流量之前就把服务器吃光。 生产 Postgres 前面永远有一个连接池。

3. 让长事务一直跑

一个开了几小时的事务，正在阻止 VACUUM 回收那些快照可能还看得见的任何元组版本。表会涨；副本会落后。设 idle_in_transaction_session_timeout，设 statement_timeout，别相信客户端会自己关掉工作。

4. 跳过 Autovacuum 调参

默认 Autovacuum 设置是给2010 年代早期的数据库调的。任何持续写入的现代负载下，默认值都太保守。 修法是按表调优，错误是以为"Postgres 自动处理 VACUUM"等于"我不用想它"。

5. 直接用 raw psql 连未池化的生产库

psql 是一个单行工具，会乐意开一个直到你退出才结束的后端。人们把它们丢在 tmux 会话里，忘了它，几周后才看到它还在占着连接槽。用池化，或者用 psql --no-psqlrc -c 'SELECT ...' 立刻退出。 专家模式是在连接本身的层面设超时：

PGOPTIONS="-c statement_timeout=30s -c idle_in_transaction_session_timeout=60s" \
  psql --no-psqlrc -c 'SELECT ...'

永远不要留一个长时间运行的交互会话直连主库。

6. 以为"Postgres 有 X"意味着 X 是免费的

它通常"有"；它通常不"免费"。每一个扩展都是跑在你后端里的一个共享对象；每一个特性都有运维代价。 选能解决问题的最小扩展集合，每次升级都审计一遍。Postgres"什么都能做"这件事的另一面，就是它能让你不小心把自己设计进升级路径塞不过去的角落。

Postgres 不是"加了类型的 MySQL"或"工具更差的 Oracle"。 不同的血统、不同的并发模型、不同的物理布局。你从别的数据库带来的技能，大概一半能用、一半反过来咬你。
多版本并发控制是定义一切的赌注。 每一行在磁盘上都可能有多版本。读写互不阻塞；代价是死元组、VACUUM 的运维税，和规划器每次读都要考虑可见性。
一连接一进程是另一个定义性的赌注。 每条连接是一个 OS 进程；连接很贵。生产 Postgres 必有 pgbouncer。
可扩展性是一种文化，不是一项特性。 自定义类型、运算符、索引方法和过程语言，通过文档化的 API 插进来。“Postgres 有 X"几乎总是成立；代价是运维表面积与"升级引力”。
这本博客是一条路径，不是参考手册。 按 Part I 的顺序读，cinetrack 沙盒是你的，每条查询都跑、每个计划都看。

带着这五条结论，我们已经准备好走进整套教程的地基——下一站，第 2 章，深入多版本并发控制与锁的内部。

下一篇： 004 | 锁、事务与多版本并发控制内部机制

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

Q1：博客说扩展可能"把升级路径绑架了"，这具体是怎么回事？

Postgres 每次大版本升级（比如 PG 15 到 PG 16），要求所有扩展也同步升级到兼容新版本的二进制。假设你依赖 PostGIS，但 PostGIS 的维护团队还没发布兼容 PG 16 的版本，那你就无法升级——你的 Postgres 版本被 PostGIS 的发布节奏卡住了。这在实际生产中很常见：团队想升级 PG 修复一个安全漏洞，但发现某个关键扩展不兼容，只能等。这也是为什么云数据库（RDS、Cloud SQL）会限制可安装的扩展列表——他们需要确保每个扩展都通过了自己的兼容性测试。建议：只用维护活跃、社区认可的扩展，避免引入冷门扩展。

Q2：博客说 pg_stat_statements 是"单一最有用的扩展"，不开启会怎样？

pg_stat_statements 按查询模板记录每个 SQL 的调用次数、总耗时、平均耗时、返回行数、IO 时间等。没有它，你只能靠应用层日志猜测哪个查询慢，但应用层看到的延迟包含了网络、连接池等开销，不纯粹是数据库的。更关键的是，很多性能问题是"某个查询突然被调用了一万次"导致的，没有 pg_stat_statements 你根本看不到调用模式的变化。生产环境第一件事就应该是开启它，并配置合理的采样参数。

Q3：博客说"跳着读这本博客很危险"，但我已经用了三年 Postgres 了，还需要从头读吗？

用了三年 Postgres 不等于理解了 Postgres。大多数开发者三年的经验是"会写 SQL、会建索引、知道怎么连数据库"，但对多版本并发控制、页结构、WAL、进程模型这些底层概念一知半解。这些概念——比如讲复制时说"WAL 是物理级别的"，讲锁时说"多版本并发控制只解决读写冲突"，讲膨胀时说"死元组留在堆里"。如果你不知道这些词的含义，读起来就是"每个字都认识但连起来不懂"。建议至少快速通读前三篇，建立概念词汇表后再深入你关心的内容。

大模型日报 · 2026年7月25日

以下为今日大模型领域5条重大新闻速览：

月之暗面发布全球最大开源模型 Kimi K3
月之暗面（Moonshot AI）发布开源大模型 Kimi K3，以 2.8 万亿参数刷新全球开源大模型记录，拥有 100 万 Token 上下文窗口。被华尔街称为继 DeepSeek-R1 之后的第二次“DeepSeek冲击”。17 岁深圳高中生陈广宇作为核心贡献者参与研发，引发全球科技圈广泛关注。
Anthropic 发布 Claude Opus 5 高性价比新模型
美国 AI 初创企业 Anthropic 发布全新模型 Claude Opus 5。该模型在多项核心性能上接近其旗舰模型 Fable 5，但使用成本仅为后者的一半。Anthropic 将“高性价比”作为核心卖点，瞄准企业日常办公与业务自动化市场，预计将成为企业客户处理日常任务的首选方案。
微软、英伟达等巨头联合呼吁发展开放权重 AI 模型
7月24日，微软总裁布拉德·史密斯等发布《开放权重与美国AI领导力》文章，微软、英伟达、Meta、IBM 等机构联合署名。文章认为开放权重模型有助于扩大 AI 应用、促进市场竞争，并将其类比为上世纪 80 年代的开源软件运动，呼吁政策层面给予支持。
AMD 发布 Helios 机架级 AI 平台正面挑战英伟达
AMD 正式推出 Helios 机架级 AI 系统及 MI450 加速器，定位前沿超大模型训练与推理，称部分推理性能优于英伟达下一代 Vera Rubin 平台，OpenAI 预计将大规模部署。同日英特尔公布 Q2 营收 161.3 亿美元同比增长 25%，数据中心与 AI 业务大增 59%，AI 算力市场呈现多方竞争格局。
Meta 高调入局 AI 代码大模型赛道
Meta 正式进入 AI 代码大模型领域，与 OpenAI、Anthropic 展开正面竞争。在 AI 代码生成与编程辅助需求快速增长的背景下，Meta 的加入进一步加剧了大模型在开发者工具赛道的竞争。分析指出，中国 AI 大模型市场规模有望在 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）技术方面，拥有丰富的机器学习咨询经验。