《Always-on Agents》讲义：一个会自己上闹钟的 AI 同事——Lee Robinson 在 Stanford CS146S 的 45 分钟

来源：X 帖文 《How do always-on, proactive agents like @Bot work? Watch my lecture at Stanford CS146S》（Lee Robinson / @leerob，2026-10-09）· 演讲人主页：ML @SpaceXAI · 场合：Stanford CS146S（The Modern Software Developer）· 时长约 45 分钟 · 英文逐字稿见另一篇

阅读说明（先说清哪些是原话、哪些是本文加的）

• 本文是这场 45 分钟讲座的结构化讲义，按演讲者自己在帖文里给出的六个章节走：How we got here → What changed in the models → Inside an always-on agent → The harness → Context engineering → Where this is going。每节标了对应时间点，可以跳着看。
• 引文都是讲座里的原话（英文原句照录，中文为本文翻译）；标为「本文补」的是本文补的背景、对照与追问，不是他的原话。
• 逐字稿是把推文里那段视频的音轨交给本地 Whisper 转写的，不是官方字幕；专有名词按上下文做过校正，但仍可能有听写误差。
• 文中提到的产品名、公司、工程细节与数字都来自他本人在讲座里的口述，本文未独立核验——它们是「他怎么说」，不代表事实一定如此。演讲里他介绍的是自家产品 GrokBot、以及团队所在的公司 SpaceX AI（他的主页写着 ML @SpaceXAI）；Whisper 早先把它听成了「SpaceX」和「Graukbot」，本文按上下文做了校正。

TL;DR

• 一句话：一个终端里的 harness，是「你按一下、它动一下」；而常驻智能体（always-on agent）是一个会自己上闹钟、有自己的电脑、有自己的记忆的同事——「它知道什么时候该安静」，也「不只是你敲键盘才能叫醒它」。
• 它和你最大的区别是持久性：跑在服务器上、能重启、能扛崩溃，跑完可以把状态存回数据库；「你合上笔记本，进程就停了」这件事，正是这一代要解决的问题。
• 架构上的两个关键判断：thin client / thick server（客户端很薄，重活全在服务端），以及客户端与服务端之间只留一个工具——send to user。所有客户端（手机、桌面、邮件、Slack）都只跟这一个工具打交道，客户端负责把它渲染成最合适的形态。
• 上下文工程 = harness 工程。核心抓手是 prompt caching：大部分 token 应该是命中缓存的，只有最新那条消息是没缓存的增量；「一次 cache miss 差不多就等于系统里的一个 bug」。
• 记忆是分层的：每次都必须带的用户核心事实 → 可做「垃圾回收」的偏好/事实 → 带日期的历史日志 → 只活 30–60 分钟的 scratch pad；其余一切都丢进文件，靠模型自己 grep 去查。
• 检索有一条由便宜到贵的阶梯：从「它已经知道的」开始，往上依次是插件/MCP/API → 网络搜索 → 打开浏览器搜 → 用整台桌面跑脚本；只有当这些全失败，才去打扰用户（比如要 2FA 验证码、验证码图片）。
• 工程原则：assume the models today are the worst they’ll ever be——今天先把产品做得尽量小、接口尽量简单，为下一代模型让路；用他的话说，要「delete the product」。

章节速览（帖文给出的章节时间轴）

• 00:00 开场
• 02:35 How we got here（我们是怎么走到这一步的）
• 06:13 What changed in the models（模型变了什么）
• 10:06 Inside an always-on agent（常驻智能体内部长什么样）
• 18:07 The harness（harness 的设计）
• 27:26 Context engineering（上下文工程）
• 34:26 Where this is going（接下来往哪里走）
• 45:16 结束

0. 这场讲座在讲什么

他把这代 agent 的定位说得很直白：

“unlike a harness in the terminal that is responding to every message that you send, this type of always-on agent is more like a colleague, where it doesn’t always immediately send you a message. It knows when to be quiet. Sometimes it might just want to work in the background a little bit, and only come back to you when there’s an important update.”

（不像终端里那个「你发一条它回一条」的 harness，这种常驻智能体更像一个同事：它不会每次都立刻给你发消息，它知道什么时候该安静，有时就在后台默默干一会儿，只在有重要进展时才来找你。）

“It can be triggered more than just you typing. Maybe there was a Slack message, or an email, or some other type of event that wakes up this agent to go do work.”

（叫醒它的方式不只是你打字——可能是一条 Slack 消息、一封邮件，或者别的什么事件。）

最终目标是让这些 agent 能在很长的时间尺度上工作：「不只是几小时、几天，也许甚至几周、几个月，而这需要一套稍微不一样一点的架构。」

本文补：这一段其实就是整场讲座的题眼。过去两年大家讨论的都是「怎么把 harness 做得更强」；这场讲座换了一个坐标——不是「模型更强」，而是「进程能不能一直活着」。一旦把 agent 从你的终端里搬到一台 7×24 的云主机上，内存、上下文、权限、成本、打扰频率这些问题会一次性全部浮上来，于是才有后面那一整套设计。

1. How we got here：四个阶段

他把「开发者与 AI 协作」划成四代：

1. 复制粘贴：从 ChatGPT 里抠代码贴进编辑器里——「感觉像几十年前的事，其实才两三年」。
2. 终端里的简化 harness：模型学会了编辑文件、跑 shell 命令，有了一个很简单的终端接口；因为它能「主动多做一点」，所以迅速传开。
3. 专属 App + 并行：把编码 agent 装进专门的 app，人们开始并行跑很多个，甚至跑在云上；但你还是瓶颈——「你几乎在盯着它们跑的每一条命令」。
4. 常驻（always-on）：现在进入新阶段——agent「环境式地」在后台跑，有自己的电脑、自己的记忆，能在工作里学新技能，你睡觉、去干别的活时它还在干。

交互方式也跟着变了：从「发指令 → 等待 → 批准 shell 命令」变成steering（边跑边纠正）——「嘿，去看一下这个帖子」，然后马上补一句「哦对了，那个改到周四做」。

本文补：第 3 代和第 4 代的分界线，是**「谁来批准」**。第 3 代的人类是「审批流里的卡点」，代价是你得一直在线；第 4 代要把这个卡点从「每一条命令」降级成「极少数不可逆的动作」——这也解释了为什么他后面花了那么大篇幅讲 auto-review、不可逆操作要确认、以及「该不该打扰你」这套启发式。

2. What changed in the models：模型变了什么

他把「为什么现在能做常驻」归因到四种能力同时到位：

• 工具调用：「几年前它们基本不会调工具，而且一直幻觉」；而现在——「你已经不太听人聊幻觉了，因为它基本被解决了」。他还说，现在给模型的工具，跟你给一个真实新同事的手册是一个量级。
• computer use（用电脑）：给模型一台完整的 Linux 电脑，它能跑 shell、能剪 demo 视频、能像人一样在屏幕上点来点去。含义是：「任何一个没暴露 API 或 MCP server 的 SaaS 产品、网站，都能被 headlessly（无头）地用起来」——自主地。
• 文件即记忆：把信息存进文件，「因为模型回查、搜索这些信息其实非常容易」。你可以问它「我上周干了啥」，它自己去翻。
• 从演示里学：你「给它演示一遍怎么做」，它就能把这件事转成 skills（技能）/ memories（记忆）/ routines（例程） 以后复用。

一个 bot 的「内心」大致长这样：先有对用户的画像（比如「用户喜欢小写、随性的消息」，那每一条消息都得带上）；再有一份工作日志，「就像跟一个同事共事，他每天记下自己干了啥」；这些全部落到文件里，模型自己 grep/搜索/翻看。

• skills：把你「怎么把某件事做对」的经验，编码进一个 markdown 文件；现在已经有一整个生态在写「怎么发一封好邮件」「怎么设计一个好 API」这类 skill。他举例说 GrokBot 有一整套插件系统，任何工具都能装。
• routines：本质就是 cron——「按某个时间表跑一段 prompt」。

本文补：这四条里最被低估的其实是第三条「文件」。模型并不需要什么花哨的向量记忆——一个能 grep 的文件夹，就是最通用、最可审计、最好版本化的长期记忆。这也埋下了他在上下文工程那一节反复强调的那句：这一切「就是文件、文件系统一路到底」。

3. Inside an always-on agent：常驻智能体内部长什么样

3.1 睡与醒

整条流水线是「左到右」的：

1. 触发器（左）：你直接发消息，或 Slack 消息、邮件、电话/会议、后台例程——把 agent 叫起来。
2. 服务器（中）：拉起全部状态、跑 agent loop。
3. 电脑（右）：需要时才开机（Chrome、文件、命令、桌面）。

用完就把两者睡眠：因为「世界上没有那么多电脑能一直为每个人开着」，而且服务器成本也扛不住。状态则持久化到数据库——对话日志、记忆、例程，全都在。

他还给了一个现场感很强的例子：

“It’s increasingly common now at SpaceX AI where we see bots joining meetings for employees where they could make it to the meeting, but they want their bot to go and just take notes and come back to them, which is kind of funny.”

（在 SpaceX AI，现在我们越来越常见到 bot 代替员工去开会——员工本来也能去，但更想让自己的 bot 去记个笔记再回来汇报，挺好玩的。）

消息进来后，有个路由层做去重、决定怎么并入对话，然后靠一条启发式判断：这条到底要不要打扰用户？

“do I need to bug the user about this or not? Because not everything is actually important. … You really only need a status update maybe, I don’t know, every day, depending on the task.”

（……我到底要不要因为这件事去烦用户？因为不是每件事都真的重要。 ……大多数情况下可能一天给一次状态更新就够了，看任务而定。）

3.2 那台「电脑」：Firecracker 沙箱

右侧的电脑是一台跑在 Firecracker 虚拟机里的 Linux box。好处是：

• 随时快照、关机、再拉起来，状态好存。
• 你可以接进去看一台实时画面，甚至自己动手控制它。
• 命令跑在隔离、加固的环境里，而不是你的个人笔记本上。
• 它带 Chrome，而且可以给每个 bot 各自的虚拟桌面——「你有五个、十个 bot，每个都要自己的浏览器，就给它们各自一块屏」。这些都是 bot 之间共享的基础设施。

3.3 为什么 agent loop 必须跑在服务端

这就是他反复讲的 thin client / thick server。理由有几层：

• 推更新方便：改 agent 代码只要推服务端，不用等应用商店审核。
• 重活快：转录、图片生成这类计算，「在服务器上一般比在设备上快」。
• 好扩容：服务器对付流量忽高忽低有成熟的打法。
• 最关键的一条：如果把 agent loop 放在虚拟机里，你就没法独立地把虚拟机换掉。比如某天要打一个 zero-day 的 Linux 补丁，「你会希望能重建这台机器，而不必把整个 agent loop 一起炸掉、让应用停摆」。

发送一条消息的流程也顺带讲了：客户端先立刻确认收到，然后进入一个 turn，把工具塞进循环、存进数据库；各客户端和服务端建立订阅、监听变化信号，收到信号再去拉最新数据；还要做去重，避免重试导致同一条消息显示多次。

3.4 用 durable workflow，而不是普通队列

这里有个很关键的分布式系统判断：job queue 会丢进度。他说，一个任务从步骤 1 走到 3，中途基础设施崩了，普通队列重启后得重放 1、2、3；而durable workflow「重试时直接从第 3 步接着走」。

他们直接用开源工具 Temporal 来做这件事——「这样我们就不必从零重造这些非常复杂的轮子」。

3.5 优先级与批处理

并发消息也有优先级：你直接给 agent 发的消息优先级最高——「我说一句『把这件事的日期改一下』，那个正在跑的 agent loop 就得停下来，我的消息优先于其它一切」；其它来源（群聊、Slack 线程、后台例程）排到队尾。而且如果三四条消息很快涌进来，agent 会把它们合并成一个 turn 处理。

4. The harness：一套「只有一件事」的架构

4.1 只留一个工具：send to user

他说 GrokBot 的 harness 跟市面上其它工具最大的区别，就是这个 thin client / thick server 设计，而它的极致形态是——客户端和服务端之间只有一个工具用来通信：send to user。

“there’s only one tool that communicates between the client and the server. And it’s just send to user. … regardless of where you spin up a new client, whether it’s a mobile app, a server, a desktop app, email slack, it all just has this one single tool that communicates back and forth with the server.”

（客户端与服务端之间只有一个工具在通信，就是 send to user。……不管你新起哪个客户端——手机 app、服务器、桌面 app、邮件、Slack——它都只用这同一个工具跟服务端来回。）

重活都放在服务端：跑 shell、读文件、调用云端 agent、录屏、做 demo。客户端虽然有且只有这一个工具，但收到之后能自己决定怎么渲染：需要登录就弹一个带 1Password 的登录表单；要付款就接 Stripe Link / XMoney；要做不可逆的动作（发邮件、发 Slack），就先请你编辑并批准草稿；什么都不用说时，甚至可以只留一个 emoji 反应。

本文补：这个「单工具」设计很反直觉，但和企业级系统里的做法是同一个思路：收敛到一条极窄、可审计的接口。客户端再怎么迭代（手机、桌面、邮件、Slack），服务端都不用改；反过来，服务端换工具、换模型，客户端也不知道。它把「多端一致性」这个老大难，退化成了「一进一出」。

4.2 动态工具发现（tool search tool）

上下文窗口是有限的「工作内存」。如果你把 Google Drive、Gmail、YouTube 这些连接器（每个 MCP server 都带一堆工具）一股脑塞进去，模型的 schema 就占满了，「留给真正干活的对话空间就不多了」。

对策叫 dynamic context / tool search tool：

“you’re only putting the names of the tools into every message that gets sent to the model. And then the model can decide … I can go read the information from a file. It’s kind of files and a file system all the way down for all of these things.”

（你只把工具的名字放进每条发给模型的消息里；模型需要时再去读文件里的详情。这些东西本质上就是文件、文件系统一路到底。）

4.3 检索阶梯：先试便宜可靠的，最后才问人

他给出了一条由便宜到贵的检索顺序：

1. 它已经知道的（对话历史里就有）；
2. 一个插件 / MCP server / API（比如用 Plaid 拉你的银行信息）；
3. 网络搜索（比如昨晚那场球赛比分）；
4. 到电脑上打开浏览器搜；
5. 用整台桌面——跑脚本、跑命令、动手搭东西；
6. 只有全都失败，才去问用户——「要个 2FA 验证码，或者碰到个验证码图片」之类。

「这真的能让它感觉像在和一个同事共事：他们不会为这点破事来烦你，而是先自己把各种办法都试一遍。」

在浏览器这层，「怎么读页面」也有讲究：截图最贵；读 HTML 次之；读 accessibility tree（无障碍树）最省 token，还够找到要点的按钮/链接/元素；再不行才点像素（有些网站会弹 modal / dialog，必须真点）。这同样是「先便宜后贵」。

4.4 主 agent + helper 子智能体：像「无限上下文」

主 agent 是编排者（orchestrator），你要把它的对话保持得尽量稀疏，因为它能把活派给一堆 helper（子智能体）。helper 去跑一大堆 shell、做贵重的工具调用，这些过程不会回流去撑爆主 agent 的上下文，只有结果回来。

“it’s only coming back with the result. And this is how you get to a product that feels like it has infinite context.”

（……只有结果回到主 agent。产品因此会有一种『上下文无限』的感觉。）

而每个 helper 自己又是一条 durable workflow：「视频 helper 崩了、内存吃爆了，它能重启接着干、不丢进度」。主 agent 则像一个管 to-do list 的同事：你能查它在干嘛、能给它发消息、能叫停某些 helper。整件事「参考的是一支工程师团队解决一个大问题的理想协作方式」。

4.5 从「搭产品」里抠出来的几条经验

• 不要在 turn 中间增删工具（会破坏 prompt cache）。
• 超长的工具描述 / schema 会吃掉上下文——对定价、对用量都不好，要在工程上把它削短。
• 「只留一个工具：跑 shell」这种极简 harness 确实成立，但如果模型 90% 的时间都在用 shell 干同一件事，给它一个专用工具反而更高效，「也更好让人读懂产品在干什么」。
• 给人类写的好错误信息，对 agent 同样有用：「这里失败了，点这个链接 / 下一步该做 X」——「给 agent 做 DX（体验）也是一门学问」。

4.6 安全：把信任当成默认前提来设计

当你把长期活儿托付给 bot，安全就是前提。他列了几条：

• auto-review：即便跑在自己的机器上，「你还是会希望有一个模型先审一遍每条 shell 命令」再放行。
• 不可信输入不能当用户指令：收件箱里一封钓鱼邮件、一个 webhook，「你不想把它塞给模型、还让它当成用户指令来执行」——prompt injection「行业里还有大量工作要做」。
• 不可逆动作要问：发邮件这类操作，「一定要先问用户」。
• 密码等敏感信息不进模型对话：用产品化的工作流把它挡在外边。

5. Context engineering：上下文工程也就是 harness 工程

他直接说：context engineering 就是 harness engineering，「它们是一回事，只是叫法在演化」。

5.1 prompt caching：大部分 token 应该是「缓存命中」

跟 agent 对话时，「你其实是在把整段对话一遍遍重发」——加一条消息，就要重发全部历史。所以：

“most of the tokens used are actually ideally cached tokens … keep them in the cached window as long as possible.”

（理想情况下，绝大多数 token 应该是命中缓存的……要尽量让它们停在缓存窗口里。）

做法是：让工具定义、system prompt 这些「固定的部分」在不同调用之间保持不变，这样缓存不被打破；固定的部分钉在顶上，只有最新进来的那条消息，才是你要为「未缓存」付费的增量。

由此引出一句很重的话：

“So if there’s a cache miss, it’s kind of like a bug in the system, really.”

（所以一次 cache miss，差不多就等于系统里的一个 bug。）

他回顾说，今年一月 OpenClaw 火起来、大家在订阅套餐里猛跑的时候，模型厂商没见过这种用法，harness 也没为这种负载优化过，「所以有大量 cache miss」——而对这种「一直跑」的 agent，那是很要命的，后来补了非常多修复。

一些具体的技巧：

• 保持 prompt 各段顺序固定，几乎可以给每一段做哈希；就算要做 A/B、塞一段新 prompt，也别搅乱别人的顺序，否则「你把全世界的缓存都打爆了」。
• 提前预热缓存：你一打开对话开始打字，「服务端其实可以提前把 prompt 准备好、把缓存焐热」，就像网页在链接 hover 时预取下一页。

5.2 compaction：在缓存还热的时候，赶紧压缩

“when you’re working over a very long period of time, you essentially have to get very good at compaction or summarization … all compression is lossy. So you have to figure out the best algorithm to do the compression and not lose important details.”

（要在超长时间尺度上工作，就必须非常擅长 compaction（压缩/摘要）……所有压缩都是有损的，所以你得找到最好的那套算法，尽量别丢掉重要细节。）

底下还藏着一个很实用的工程 trick：模型厂商的缓存窗口是有限的（可能 10 分钟，也可能 60 分钟）。所以——

“while you’re still within the warm cache period, you should probably do the compaction right now because … It’s going to be much cheaper. And now when the user comes back in 30 minutes … they’re starting from this summary.”

（趁缓存还热，就应该现在就把 compaction 做掉……会便宜得多。等用户 30 分钟后回来，他是在这份摘要的基础上继续，也就更便宜。）

5.3 记忆分层：核心事实 / 可回收事实 / 日志 / scratch pad

他把「该往记忆里放什么」分成几层：

1. 每次都必须带的核心事实（比如「用户要用小写、随性的语气」——否则某条消息突然变大写，会很怪）。
2. 偏好/事实：有很多算法可以决定「哪些事实最该留下」——「理想情况下这是对事实的一种垃圾回收」。
3. 带日期的历史日志：你过去的对话史。
4. scratch pad（草稿纸）：正在处理的小事，故意设计成短暂的，可能只对接下来 30 分钟到 1 小时有用。

他打了个很妙的比方：

“this is kind of how our brains work … You’re probably not thinking about a soccer match right now. And your brain is very good at keeping those ones in context right now.”

（这有点像大脑的运作……你现在大概没在想一场足球赛，而大脑很擅长把当下相关的留在上下文里。）

而其余一切，都靠文件：

“Everything else can be found through files. This is the magic of files … they can always just go look stuff up. And they’re actually very good at doing that.”

（其余的都能从文件里找到。这就是文件的魔法……它们随时能去查。而模型真的很擅长这件事。）

6. Where this is going：训练飞轮、delete the product、以及开放问题

6.1 内外两个循环

他把「把模型训得更适合这个产品」讲成一个飞轮：预训练 → SFT → RL。

• SFT：让模型见过这个 harness、知道有哪些工具、怎么在里面干活。
• RL：练指令遵循、练「在几百个 skill 里挑对那一个」、练「在浏览器里点对地方」。

飞轮有两圈：内圈是团队天天在做的「找 bug → 修 harness / 修 prompt / 修推理 → 用 eval 度量 → 上线」；外圈是「每隔几个月训出新模型」，新模型从这些 bug 和失败里学，在 eval 上爬到你要的水平，再塞回产品。新模型带来的能力跳跃，又会解锁产品的新用法——他甚至提到：「bot 在群聊里协作这件事，几乎没什么训练数据，是正被摸索出来的新能力」，所以「得让模型学会在多智能体系统里好好表现」。

推理侧也有取舍：主 agent 要低延迟（「立刻回你、回得飞快」），而派给 helper 的长期活，「10 分钟和 12 分钟的差别可以忽略不计」——所以你可以分开调优。

6.2 delete the product

“One of the principles that we had at Cursor and now at SpaceX AI is to delete the product. … assume that the models today are the worst they’ll ever be. … in six months you might need to completely rebuild the UI.”

（我们在 Cursor、现在在 SpaceX AI 的一条原则是删掉产品。……假设今天的模型是它一辈子最差的样子……六个月后你可能会需要把 UI 整个重搭。）

策略就是：为下一代模型而建——「尽量少建、先把产品撑住，只留一个极简接口，让模型自己去想、去做」。

6.3 接下来 6–12 个月，他押的几条

• agent 的工作时长会从几小时/一天，走向几周/几个月。
• 模型对过往信息的回忆会越来越好（图、文件，或者别的表示，都在探索）。
• 「给你的数字同事配齐你会给一个真人配的全部工具」，组织层面还在适应这件事。
• 交互会更简单，**语音对语音（speech-to-speech）**会有一批人喜欢（他还顺嘴提了「那个理想中会很酷的 Johnny Ive 设备」）。
• 模型/产品会越来越会在工作里学技能、并把它编码进文件与指令；人和公司也会越来越会把「自家的土办法」写清楚，好让 agent 能用。

6.4 他觉得还没解决的开放问题

• 评测的时间尺度错配：「你要评估一个跑一个月的 agent，但模型每个月都发布一次，你怎么办？」要么做出更好的 eval，要么别把模型发得那么快——「这是行业未来六个月必须解决的问题」。
• 记忆算法本身远没做完。
• 安全：怎么把 harness、以及围绕 agent 的基础设施做得无法被坏人接管。
• **「什么时候该安静、什么时候该找你」**的启发式还没调好：「要在这两者之间穿针引线——『我看到你昨天缺课了，我录了音、记了笔记，这个也许对你有用』……它可能很有帮助，也可能很烦人」。
• token 会暴涨：他赌「明年这时候，全世界流动的 token 会多得多」，所以把推理、模型、harness 优化到更省 token，会越来越重要。
• 新原语：他引了 OpenRouter 的 Alex 的一个判断——有人说「现在的 app 长得都一样，侧边栏 + agent + 聊天框」，但那就像 2005 年「人人都有服务器、数据库、CRUD 界面」一样，这就是新的常态：每个新产品都会有某种 agent 面，否则就会退化成「给别的 agent 用的无头数据」。而这些「积木」——durable workflow、沙箱、云电脑、记忆、skills、连接服务、语音、支付、身份、evals、可观测性——「每一个后面都是几十亿美金的风投，也许上万亿；每个方向都有 20 家创业公司」。

7. 给工程师的 takeaway

他最后收在三点：

1. 系统设计比以往更重要。因为「你今天做的这些决定会复利」——「我还是会看代码，尤其想搞清楚你在交付的架构是什么样」。
2. 动手做一个自己的版本。GitHub 上已经有开源的 GrokBot，配个 sandbox、一台 VM、加个 GUI，「你会更明白这些零件怎么转」。
3. 别回避去了解 LLM 是怎么工作的。不需要深挖 ML 或科研，但「就像写 Web 应用时你会想知道数据库怎么工作一样」——越来越多产品层与 harness 层的决定是被模型本身影响的，「有这种直觉，会让你在任何角色上都更有位置」。

本文补：如果只带走一句话，我会带走 「cache miss 就是 bug」——它把「上下文成本」这个模糊话题，变成了一个可监控、可归因、可当事故追的工程指标。第二句是 「为下一代模型而建，并为删掉它做好准备」：在这条曲线上，今天最好的 UI，往往就是明天要拆的脚手架。

---

英文逐字稿（带时间轴）见另一篇。