110. 逐段讲解Kimi K2报告并对照ChatGPT Agent、Qwen3-Coder等：“系统工程的力量”

Kimi K2 就非常实在，把很多 recipe 或者小技巧都已经放在这里了。但是我觉得，假如我们真的要把它做出来，以一种很高效的方式把它高质量地做出来，本身可能还是很难的。因为每一个部分都要把 prompt 调好，还要把各种参数调好，保证它能够平稳运行并且有很高的质量，这本身就是非常大的工程量。

这里有点像一门手艺活，需要研究员像老师傅一样做手艺活。

今天我们要读的论文，是最近几个星期内最值得品读的几篇技术报告，分别是 Kimi K2、ChatGPT Agent、Qwen3-Coder 的技术报告，以及 Manus 的一篇技术博文。它们的相关性在于，这几篇内容都和 Agent 智能体有关。

今天的嘉宾是俄亥俄州立大学在读博士生郑博元，他的研究方向就是 Language Agent，也就是语言智能体。他会带着我们一起阅读上述技术报告和博文。

博源，先给听众朋友们打个招呼，并且做一个简单的自我介绍。

大家好，我叫郑博元，是俄亥俄州立大学三年级的在读博士生。我的研究方向是 Language Agent，也就是智能体。

能不能给大家介绍一下你个人研究的主线？

1. Agent研究主线

我自己的研究，主要就是想把 Language Agent 真正做出来。特别是让 Language Agent 学会操纵电脑或者浏览器，帮助大家完成一些日常工作，甚至起到助理的作用。我们现在管它叫 Computer-Use Agent。

形象来说，我的研究在于如何让这个 Agent 学会感知环境、理解环境，在这个基础上进一步生成动作，也就是 Action，和环境进行交互。

我的研究内容基本上一直围绕着如何真正把这个 Agent 做出来。一开始我们的难点在于，如何让 Agent 理解互联网或者网络这样一个环境。最开始大家只有单一模态的 Language Model，那时候 Language Agent 只能看 HTML 并理解它，但 HTML 的内容非常冗杂。

随后我开始研究如何让 Language Model，或者说让 Language Agent，理解 GUI 界面，进而更高效地理解环境并生成 Action。后来我发现，Language Agent 虽然能够理解环境，知道 GUI 上有哪些功能，也能够准确地用语言描述下一步应该执行什么 Action，但它往往不能把这个 Action 很好地转化成可执行的操作。

所以我进一步做了一个叫 Grounding 的工作，让 Language Agent 生成的 Action 能够准确转化成程序，并且在浏览器上执行。

在这个基础上，我们逐渐能够帮助 Language Agent 在单一的步骤上做到很好的效果。但是一旦让它做一些非常长、非常复杂的任务，效果就会差很多。随后我开始研究如何让 Language Agent 做比较长的规划和推理。在这个基础上，我们提出了如何用 Language Model 内部的世界模型，辅助 Language Agent 做规划。

最近我在 AI2 实习，主要研究如何用大规模强化学习，把 Language Agent 的效果做得更强。

所以你研究 Agent 已经有几年了？

我从 PhD 开始基本上就在研究 Agent，已经两年了。今年刚好是博士第二年结束，即将开始第三年。

我的 PhD 研究，和我之前的经历其实是一个很有趣的衔接。因为我硕士和本科时研究的领域，是自然语言处理中的信息抽取。这个领域想做的事情是，把非结构化的语言，比如日常聊天或者一篇文章，通过 NLP 技术变成结构化的表述，比如整理成一个图或者一张表，然后在这个基础上进一步做一个像 ChatGPT 这样的 Agent。

当 ChatGPT 出来之后，整个研究方向发生了很大的变化。我发现，ChatGPT，或者说 Language Model，总体上已经能够很好地作为人类语言和意图之间的一个界面。

所以我就开始想，能不能在这个基础上，利用这样一个很好的语言界面，进一步做一些更难、或者对人类更有帮助的事情。

我们今天的重点，就是给大家读几篇关于 Agent 的最新论文。过去两周，OpenAI、Kimi、阿里，包括前两天的智谱，都发布了新的模型，它们都是为 Agent 工作流而设计的模型。

与此同时，Manus 的首席科学家 Peak 也发布了一篇文章，讲构建 Manus 的经验和教训。今天我们就请博源，来讲解这几个和 Agent 相关的技术报告和博文。

延续我们之前的传统，我先问博源几个问题，然后就把时间交给他。我们今年讨论 Agent 非常多，能不能先给大家讲一讲，怎么给 Agent 下一个定义，并且给 Agent 做一个常见的分类？

2. Agent的定义

首先我觉得，Agent 这个词现在用得比较杂，有各种各样的用途。但是就我个人的认知，我会首先把它叫作 Language Agent。

目前大家的 Agent，基本上都是基于 Language Model 构建的。而且这些 Agent 会用语言作为沟通、交流、推理和规划的载体。

关于这个定义，有一个常见的问题：Language Agent 和 Language Model 的核心区别是什么？因为它们看起来非常相似。

我觉得核心区别在于，这里面是否存在一个环境。Language Agent 需要学会更好地和环境进行交互，具体有两个点：第一，它要能够很好地感知环境，我们管它叫 Perception；第二，它要能够很好地生成并执行 Action，从而影响环境。

我们可以具体看一下，Language Model 和 Language Agent 在训练以及推理时的范式有什么区别。

对于一个 Language Model，它接受的信息是一个 Input，然后输出一个 Output，这个过程就结束了。但是对于 Language Agent，首先 Agent 会感知环境，从环境中获得一个 Observation，也就是观察。Observation 的类型，会随着 Agent 所处的环境和应用场景不同而变化。

比如，如果是一个 Coding Agent，它的 Observation 可能是一整个 Codebase，也就是代码库，还有它当前执行的记录或者环境反馈。如果是一个 Computer-Use Agent，它的 Observation 可能就是当前浏览器或者电脑屏幕上的 GUI 截图，或者对应的 HTML。

随后，这个 Observation 会作为模型 Input 的一部分，被送给 Language Model 处理。当然，在这个过程中还会包括 Agent 需要完成的 Task，以及之前和环境交互的内容。

比如，我们的任务是让 Agent 帮我们订一张机票，那么 Task 就是订一张从北京到上海的机票。之前的交互内容，就是 Agent 已经执行过的操作，比如在输入框里输入了什么。

在这个基础上，Language Model 会基于这样的 Input 生成一个 Action，随后我们对它进行执行，环境状态也可能发生变化。比如页面刷新了，或者对于 Coding Agent 来说，我们获得了一个新的执行结果，发现它有 Bug，于是就需要进一步 Debug，改变执行结果。

这就是我理解的 Agent 的基本定义。

Agent 现在和应用非常相关，我们也可以基于应用场景，对它做一个简单的划分。

目前研究比较多的 Agent，主要有几类。首先，我觉得现在做得最成熟的，应该是 Coding Agent。比如 Cursor，还有前段时间被收购的 Windsurf，里面都包含 Coding Agent。

具体来说，Coding Agent 就是我在写代码的时候给它一个指令，比如“请帮我写一个什么样的 GUI 界面”。这个 Agent 会写一段代码，然后自己执行，执行之后看一下结果。如果有 Bug，就自动 Debug，最后生成一个不错的 GUI 界面。它也可以用来 Debug 有问题的代码。

整体上，我感觉现在 Coding Agent 的效果已经非常强大了。包括我自己写代码的时候，我觉得就像不停地有很多实习生帮我写代码，而且效果和体验都非常强大。有时候我甚至可以同时开好几个 Agent，比如在 3 到 5 个进程、3 到 5 个界面上，同时完成几个任务，对生产力的帮助非常大。

另外一种比较强大的 Agent，叫 Search Agent。典型案例就是 OpenAI 的 Deep Research，包括 Gemini 等公司也都有对应的产品和模型。

这类 Agent 做的事情是，给它一个指令，它会对这个指令进行大规模检索或者搜索。比如我们让它调研当前市场上所有 GPU 提供商的价格、策略以及能够提供多少 GPU，那么这个 Agent 会先理解 Task，再使用 Google Search 或者一系列搜索引擎，访问不同的 URL，进行大规模的搜索和检索，最后生成一份报告。

我觉得这种 Agent 对市场调研之类的场景，会有非常大的帮助。

还有两类我觉得最近做得比较多的 Agent。一类是 Tool-Use Agent，这也是我们这次会讲到的 Kimi K2 和 Qwen3-Coder 的实验中非常强调的场景。另一类是 Computer-Use Agent，比如这次会讨论到的 OpenAI ChatGPT Agent 和 OpenAI Operator，它们属于这一类型。

Computer-Use Agent 具体做的事情，就是给它一个 Task，比如订机票，或者在网上预约一家餐厅，Agent 会自己生成一串 Action，去完成这个任务。

传统行业里其实有比较类似的场景，比如 RPA，也就是流程自动化。Salesforce 这类公司过去要做的是，给一个固定流程，然后手动写一串 Workflow 去完成这件事。

但现在有了这些 Agent，或者基于 Language Model 的其他 Agent，我们可能可以完全自动化这个过程，不需要大量工程师手动编写 Workflow，而是用一个 Agent 一键自动完成整个过程。这可能也会对 RPA 产业产生影响。

这些 Agent 基于应用场景的不同，会有很大区别。但从任务建模上看，它们的区别主要在于 Observation Space，也就是观察空间。

Coding Agent 的 Observation 是 Code；Search Agent 的 Observation 是 Text Browser；Computer-Use Agent 的 Observation 是 GUI Browser。

它们的 Action Space 也不一样。Coding Agent 的 Action 是生成一段代码，或者修改某一段代码；Computer-Use Agent 的 Action，则是各种浏览操作，比如点击，或者在某个输入框里输入内容。

具体来说，这次的 Kimi K2、Qwen3-Coder、ChatGPT Agent，以及应用公司 Manus，它们之间的技术方案有什么差异吗？

3. 模型训练路线分化

有。我觉得比较大的差异，还是 Manus 和其他几个模型之间的不同。

这可能就像 Manus 博客里提到的，区别在于我们究竟是利用模型的 In-Context Learning 能力，还是从头到尾重新训练一个 Agent。

Manus 属于非常详尽、非常精细地利用 Language Model 的 In-Context Learning 能力。它们可能不太涉及模型训练，而是通过很好地调节 Prompt，以及设计 Multi-Agent 系统，快速迭代出一个大家可以直接使用的产品，并且快速改进。

这种方式非常容易迭代，也非常容易调节 Agent 的各种能力，还能很好地实现 Multi-Agent 场景。

比如设计一个系统时，我们会认为里面有不同角色，或者不同模型承担不同角色。假如我们要写一个网站，可能需要一个产品经理，去设计网站的外观，以及对用户来说比较重要的属性和 Feature。

同时，我们还需要一个很会写代码的 Agent，比如现在大家一般会用 Claude。在这基础上，可能还需要一个专门 Debug 的 Agent，或者一个专门评判代码质量的 Agent。

这就是一个 Multi-Agent 系统。In-Context Learning 范式，让这样的操作非常方便。现在不同模型各有所长，基于这种方式，可以很好地组合出一些好用的产品。

但是，如果我们有一个非常明确的场景，比如 Coding 或 Browsing，也就是 Computer Use，那么如果能端到端训练出一个模型或者 Agent，它会变得更强大。

端到端训练的模型，如果我们能够以一种很好的方式获得大量 Reward Signal 或者 Training Data，我们就可以在特定场景下训练出一个非常强大的 Agent。它的好处是，在某个特定场景上会非常强大。

但我觉得，目前 End-to-End Training 范式如果要做 Multi-Agent，可能会相对困难，因为数据比较难获得。

如果要训练这样一个 Agent，数据上需要两方面：一方面是 Synthetic Trajectory，也就是 Agent 的 Action 和 Environment Feedback 相互交叠的数据。到了 Multi-Agent 场景，这种数据会非常难生成或者获得。

当然，我们也可以拿它做 RL，也就是强化学习。我们给它一个任务，让 Agent 自己探索，最后判断它是否成功。但在 Multi-Agent 场景下，执行轨迹会非常长，而且每个 Agent 都有自己的身份和角色。这样我们很难判断最后的 Reward 应该属于哪个 Agent，也很难把训练信号传导回去。

为什么我听到大家对于 OpenAI 的 Agent，整体上比较失望？整个 AI 社区对它的评价是什么样的？

4. OpenAI失望与Kimi走红

我前段时间刚从 ICML 回来，ICML 上大家讨论得非常多。我觉得不同身份的人，反馈可能不一样。

做科研的朋友，比如我们这样的 PhD，以及一些更资深的研究人员，大家会有一种“舒了一口气”的感觉。

我们一直担心，哪一天 OpenAI 或者 Google 通过 Scale Up RL Training，或者 Scale Up 在环境里的 Exploration，一次性把这个问题变成一个 Well-Solved 的问题。

这种事情其实已经发生过几次了。比如 2022 年 ChatGPT 带来的冲击，基本上把 NLP 的很多小方向都影响了，甚至可以说做掉了。我自己以前的一个方向就是如此。

因为我们发现，大规模训练有时候能够在很大程度上解决一些细分的小任务。后来 OpenAI 发布 GPT-4V，也对多模态研究产生了很大的影响。

所以当我们看到 ChatGPT Agent，或者说 OpenAI 的 Operator 和 Deep Research 时，就会觉得这种范式可能存在比较明显的 Scale-Up 方案，能够在很大程度上解决问题。

大家就会有一点提心吊胆。我当时的感觉是，如果它一下子发现了特别强的 Agent，可能会让整个研究方向发生比较大的转向。

但我觉得这个问题确实很难解决，里面还有非常大的探索空间。

除了研究人员，初创公司也极其兴奋。很多人做了一些有趣的小 Demo 和视频，把自己的 Agent 拿出来和 OpenAI 的 ChatGPT Agent 做对比。

比如我看到一些很逗的 Demo，他们搞了一个斗兽场，或者像足球解说一样，在一个显示屏上开两个窗口，左边是他们自己的 Agent，右边是 ChatGPT Agent。两边同时开始完成 ChatGPT Agent 展示的 Task，主要是 Flight Booking。

因为初创公司可以通过收集一些领域数据，或者做一些特定的 Prompting，让自己的 Agent 很擅长做某件事。于是就会看到他们不停解说：“ChatGPT Agent 现在还在完成这个操作，但是我们的 Agent 已经结束了。”

所以整个 Startup 圈都特别开心。因为这可能证明这个问题比较难解决，里面还有很多探索空间，对融资和产品都会有一定帮助。

相比来说，Kimi K2 为什么这次激起了比较大的水花？另外，阿里 Qwen 和 Kimi 发布的 Agent 模型，它们之间有什么相似和不同？

我觉得 Kimi 这次发布的时间非常好。这应该是比较早的、专门聚焦 Agent 能力的模型。当然，之前也有很多 Language Model 已经包含了 Agent 能力，但这次 Kimi 在宣传上主要强调的是 Open Agentic Intelligence，论文标题也是这样。

正好最近大家对 Agent 能力比较感兴趣，Agent 本身也比较受欢迎，所以一下子变得非常热门。

另外，我觉得这个模型本身已经足够强大。现在整个预训练数据方面，Kimi 或者 Qwen3-Coder 已经有了很大的积累，内部有大量数据，再加上训练算法和架构上的成熟，本身能力就很强。

我整体使用的体感，就像一个小型 ChatGPT，是一个完全开源的小型 ChatGPT。这样我们就可以免费获得一些非常强大的 Agent。

大家可能会拿这些模型去做一些小应用，比如写网页前端，会发现效果确实非常不错。所以我觉得这可能是它受欢迎的一个原因。

因为 Agent 从大脑里走出来，要和世界发生交互，甚至和物理空间发生交互。你觉得 Agent 的安全问题，值得更多考虑吗？

5. Agent安全与训练

是的，我觉得这是非常重要的问题。我昨天刚发布了一篇论文，研究的就是这个问题。

首先，我想整体展开讲一下，为什么 Agent Safety 会产生影响。

Agent 执行的某些 Action，可能会对世界产生难以逆转的影响。当然，这也取决于 Agent 的类型。

比如 Deep Research 这类 Agent，可能只是在网页上进行读取操作，它不会对世界，或者对网站本身产生影响。即使它生成了很离谱的 Action，做了一些奇怪的事情，也不会影响其他人，所以相对比较安全。

但是如果是 Computer-Use Agent，比如 Operator，它可能就会实实在在地影响世界。

我有一个亲身经历。大概一年半之前，我做了一个叫（可能是 SeeAct）的工作，当时应该是市面上比较早的、真正把 Web Agent 放到真实网站上运行的工作。

有一次我在做 Demo，任务是“帮我在特斯拉的某家门店预约一次试驾”。我当时没有特别在意，但这个 Agent 真的做成了。

一开始我也没太在意，后来圣诞节的时候，它就不停给我发邮件，说“你是时候来提车了”。

这可能是一个很简单、影响力也不是很大的例子。但假如我们开的不是一个 Agent，而是 1000 个 Agent，那就相当于有 1000 个 Agent 重复做类似的事情。

假如所有 Agent 都在同一家门店预约试驾，或者给它发送请求，这可能就变成一种智能化的 Agentic DDoS Attack，对互联网安全产生比较大的影响。

Agent 的自动性和便利性，也会带来很多其他危险。比如你想让 Agent 帮你订机票、下单买东西，比如咖啡机，或者起草一些邮件，但它一不小心下单了 1 吨鲜肉，买了 1000 杯咖啡，或者不小心给别人发了一封比较粗鲁的邮件，这些情况都会非常危险。

所以，我们可能需要更多地思考如何控制 Agent 本身的行为。

比如我最近发布的工作，就是想建立一种 Guardrail，在 Agent 执行 Action 之前判断一下它对世界或者对其他人的影响有多大。如果影响足够大，就先暂停这个 Action，提醒用户：“你确定要执行这个 Action 吗？”

这有点像自动驾驶。一方面是确保安全性，另一方面也是解决伦理问题。只要用户批准了这件事，伦理和责任就可以归到用户一方，这可能会让 Agent 的商业化更加稳妥。

ChatGPT Agent 的论文，或者说我们一会儿讲 Kimi K2 的时候，也可以看到它们都花了很多精力研究 Agent Safety。OpenAI 这次和 Sequoia 的采访中，也提到了很多 Safety 相关的内容。

我很好奇，训练 Agent 和之前训练 Chatbot，有什么不一样吗？能不能对训练 Agent 的一些方法做一个概览？

我觉得 Agent 的训练主要有两方面。

一方面，是获得大量 Synthetic Data。这些数据是 Trajectory。具体来说，我们需要通过大量 Agent 风格的数据，教会 Agent 如何和环境交互。

Agent 和环境交互、生成 Action 的过程大概是：首先观察环境，获得 Environment Observation，可以是 Screenshot、HTML，或者其他不同环境中的观察；接下来基于 Observation 生成 Action；执行 Action，获得环境反馈；然后循环反复地做这件事。

如果要训练一个 Agent，让它很好地完成这件事，就需要大量各种类型的数据，也就是 Observation、Action 和反馈相互交织的数据。

这种数据在自然的预训练数据中，占比应该比较小。当然，预训练数据里肯定也有，但这些数据不足以构建一个足够强大的 Agent。

所以我们需要想办法生成大量相关的 Trajectory，或者人工标注数据。我们一会儿讲 Kimi K2 论文时，可以看到他们在这件事上花了很多精力。

另外一个非常重要的训练范式就是 RL，也就是强化学习。这是我觉得最近非常有前景的方向，我自己也在研究。

相比前面的 Data Synthesis，RL 更容易 Scale Up。做 Data Synthesis 时，需要生成大量完整的 Trajectory；但做 RL 时，我们只需要一个 Agent 要完成的 Task，以及对应的 Verifiable Reward，判断这个 Task 有没有完成。

在这个基础上，我们可以让 Agent 自己探索、自己尝试，给它 Reward，告诉它成功还是失败。这样训练 Agent，可能更容易大规模增加训练或推理计算量，让 Agent 的能力变得更强。

下面把时间交给博源。他会重点讲解 Kimi K2 的技术报告，对比并穿插 OpenAI Agent、Qwen3-Coder，并概括介绍 Manus 的博文。我中间会以观众视角提问，可能在中间，也可能在最后。博源，你来吧。

6. Kimi的数据合成

好的，谢谢小珺。我们现在开始读 Kimi K2 的论文。很多论文里面涉及的 Data Synthesis、RL，或者其他技术，在几个工作之间其实是共享的。

所以我会先总结每个部分面临的主要难题，以及可能的解决方案，然后再具体展开这些论文是怎么解决的。

我们先快速过一下这篇论文和它的主要贡献。

Kimi K2 的论文标题很有意思，叫《Kimi K2: Open Agentic Intelligence》。它也是比较早宣称自己是 Agentic Model 的工作。

它主要有 3 条贡献。

第一条是 Muon 优化器。Kimi 很早就尝试使用 Muon 优化器进行训练，这次训练时他们发现效果非常好，Training Curve 看起来也非常漂亮。当然，之前也有其他论文尝试过类似的事情，但 Kimi 很早就做了各种创新尝试，这一点非常值得尊敬。

不过，优化器和 Agent 能力基本上是相互垂直的关系，所以我们这次会更侧重后面两个部分。

第二个贡献，是提出了一个大规模 Agentic Data Synthesis Pipeline，能够系统性地生成 Tool-Use 数据。他们不仅在仿真环境里获得数据，也在真实世界里获得数据，我们一会儿会具体讲。

第三个贡献，是一个通用的 Reinforcement Learning Framework，讲如何结合 Verifiable Reward 和 Self-Critique Rubric Reward，来训练 RL 模型。

关于 Rubric Reward，最近也有很多工作在进一步展开。前段时间 Scale AI 发布了一篇论文，叫《Rubrics and Reward》，标注了大量相关数据。

最近可能有一个潜在趋势：大家从标注 SFT 的 Input-Output 数据，逐渐转向标注 Task，再加上 Reinforcement Reward，或者 Rubrics as Rewards。这可能是新的数据标注范式。

我们先简单过一下 Pre-Training 这部分。除了模型优化器，他们也设计了一个 Data Synthesizer 方案。

众所周知，Language Agent 和 Language Model 的发展，已经不像之前那么快了，我们把它叫作 Plateauing。一个核心原因是数据快被用完了，整个互联网的数据基本都被爬取过了。

但 Agent 可能在一定程度上解决这个问题。Agent 在每一轮交互中，都会观察新的数据，不断有新信息进入。因为它会执行 Action、观察环境、获得反馈，然后继续执行。

在这个范式下，Agent 系统不是一个封闭系统。它和 RLHF 这种只训练 Preference 的方式不同，Agent 的 Multi-Turn RL Setting 会不断获得新信息。

假如我们能够很好地整理这些信息，把它们整理成 Knowledge，比如从中抽取有用的 Procedure 或 Fact，那么基于 RL 训练的 Agent，或者 Agent 本身，也许能够成为新的 Data Engine，进一步增强 Language Model。

这还是一个探索方向，不一定特别严谨，但我觉得是非常令人兴奋的研究方向。

回到这篇论文本身。这里的曲线就是我们前面提到的 Muon Optimizer，曲线看起来非常平滑。

再往下看数据生成过程。他们总体上是用一个现有的 Language Model，这里应该是 Kimi K1.5，对已有数据进行重写和筛选，从而获得不同的数据，形成 Data Synthesis 过程。

第一类数据是 Knowledge Data，比如维基百科、书本，或者知识密集型文档。他们使用了大量 Prompt，控制重写数据的风格和视角，从而获得更加多样化的数据。

但重写过程中不可避免会出现 Hallucination。即使只是重写一篇文章，模型也可能不小心把某个知识点改掉。

所以他们接下来提出了两种方案，尽量减少 Hallucination，保证数据质量。

第一个叫 Chunk-Wise Autoregressive Generation。简单来说，就是把大文章切成一块一块，每一块分别重写。这样重写短文章时，更容易控制质量，保证它和原文没有知识冲突。

比如，一篇 1 万字的论文，老师让我们重新写一遍或者复述一遍，我们很可能会记错某些细节。假如原文写的是一个人物在壁炉前喝咖啡或者喝茶，我可能不小心写成他在壁炉前吃烤肉或者面包。

这种小的知识错误，可能会影响文章整体的准确度。如果错误文本出现在预训练数据中，就可能让模型的幻觉变得更加严重。

所以要进行 Chunk-Wise Autoregressive Generation，把文章分成一块一块，逐块进行重写。

这会不会影响模型的智商？

我觉得会有一定影响。因为模型很难完全 Attend 到上下文中的所有 Token。

之前有一篇很早的论文，是 Nelson 等人发表的《Lost in the Middle》。它发现 Context 变长之后，模型的各种 Performance 都会受到影响。

在 Agent 里面可能也有类似问题。当 Agent 和环境交互很多、前面的步骤变多之后，我觉得它整体上会变得笨一点，因为它记了太多东西，有点内耗。

当然，这只是一个比较意识流、开玩笑式的说法。整体上，是因为 Context 里塞进了越来越多内容，导致 Attention 不能很好地集中到我们需要的部分。

Manus 的博客里也提到了这一点，我们一会儿可以看看他们是怎么从工程上解决这个问题的。

Chunk-Wise Generation 可以在一定程度上减少幻觉或者知识性错误，但我们没办法完全保证它没有错误，所以还需要加入 Fidelity Verification。

这一步基本上就是再拿一个模型，比较重写后的文章和原文章之间有没有常识性错误，检查一遍，然后把错误数据去掉。

经过这 3 步，我们就可以得到大量重写后的 Knowledge-Related Data，用来做数据增广。

接下来有一个问题：新生成的数据效果怎么样？

论文里的 Table 1 做了很详细的 Case Study。实验是在 SimpleQA 数据集上进行的，用 Accuracy 做 Evaluation。

不同设置的区别，在于预训练时使用的 Wikipedia 数据有没有经过这套 Pipeline 重写，以及重写了几遍。

最简单的 Baseline 是完全不重写，但把数据喂给模型训练 10 次，最后结果是 23.76。

在此基础上，把数据重写 1 遍再喂给模型，Performance 提升了很多。更激进的方案，是把文章重写 10 遍，再把这 10 份数据混在一起训练，效果进一步提升。

论文里也提到，这套 Pipeline 在很多数据集上都有效。

这部分主要针对知识密集型数据。接下来还有 Mathematical Data 的重写，也就是数学相关文档。

他们具体做的是，把高质量数学文档重写成 Learning Notes 格式。这套方案参考了一篇名称可能是 SolaMath 的论文。

可以形象地理解为费曼学习法：学完一个内容之后，怎么检验自己是否真的学会，或者怎么更高效地学习？就是学完之后，再教别人怎么学习这个内容。一旦能够把别人教会，可能就真的掌握了。

Learning Notes 可能也是类似的形式，是一种更加简洁、更加密集、重写过的格式，用这种方式增广数学数据。

这两部分，主要是 Pre-Training 阶段的数据增广和重写过程。通过这种方式，可以在一定程度上缓解数据稀缺问题。

接下来简单看一下模型架构。它其实没有特别大的不同，基本沿用了 DeepSeek-V3 的架构。

知乎上有团队作者提到，他们之前也做过不同尝试，但发现 DeepSeek-V3 本身是优化得比较好的架构，所以直接沿用了。

他们的不同之处，主要在于更换了 Expert 数量，以及调整 Attention Head 和 Dense Layer 的参数，在这个基础上调了一些超参。

直接沿用 DeepSeek-V3 架构，对 Inference Efficiency 和用户使用也有很多便利。开源社区，比如 vLLM 或 SGLang，已经针对 DeepSeek-V3 架构做了大量优化。如果直接 Follow 这个架构，他们自己做 Inference 时也会更方便，效率更高。

我觉得这可能也是开源的好处。开源之后，很多细节放给社区，会有来自世界各地的博士和工程师，自发优化这个架构、提供服务，像是免费雇佣了一大批工程师。

整体来说，这部分主要是架构内容，创新不多，基本沿用 DeepSeek-V3。当然他们在训练基础设施上也做了各种优化，但因为我们这次主要讲 Agent，所以会更多关注 Agent。

接下来进入 Post-Training 部分。这是和 Agent 能力最相关的一部分，主要包括 Data Synthesis Pipeline 和后面的 RL。

先讲 Data Synthesis。这里提到，他们训练时使用了 Muon 优化器，后面的 RL 也保持一致。

他们强调的核心是：一定要让数据足够 Diverse。

我自己做实验时也发现类似现象。Agent 数据如果从头自动生成，很可能会受到各种限制。

比如在一个网站环境里，让 Language Model 自己提出 Agent 要完成的 Task，很快就会遇到 Diversity 的上限，因为它观察到的数据非常有限。

这件事本质上是在用 Language Model 自己去 Sample Task，因此会受到模型内部 Prior 的影响。

所以这里的核心，就是采用各种方案，让数据变得更加多样化。接下来可以具体看他们是怎么实现 Diverse Data 的。

这部分叫“大规模 Tool-Use Learning 数据合成”。从 Figure 8 可以看到，它分成 3 个部分。

第一部分是 Tool Specification Generation，也就是生成大量 MCP Tool。先生成大量 MCP 作为 Tool-Use 的工具，再基于这些工具构建各种使用场景，生成进一步的数据。

第二部分是 Agent Task Generation。他们从所有 Tool 里 Sample 一些子集，每个子集构建对应的任务和使用场景，最后基于 Agent 和 Task 生成 Trajectory。

先看他们如何生成和收集 Tool。

第一步是在 GitHub 上收集大量 MCP Tool。这里补充一点背景：MCP 是 Model Context Protocol，由 Anthropic 提出。简单来说，它规定了一套标准协议，让 Language Model 或 Agent 能够以规范的方式使用 Tool。

MCP 的出现，为 Tool-Use Research，包括 Data Synthesis 和 RL，提供了很多便利。

以前没有 MCP 时，可能需要直接调用 API，但各种参数和接口都不统一。真正做起来，就要花很多精力给接口和工具调用做工程化处理。

有了 MCP，很多东西都标准化了。MCP 生态也非常丰富，所以他们收集了 3000 多个工具。

而且最近出现的 MCP Tool，或多或少都带有应用场景和应用价值，因此质量可能比凭空爬取 API 更高。

他们还对收集到的 MCP Tool 做了可视化，用 t-SNE 进行了展示。图里每个点代表一个 Tool，不同颜色代表不同领域或类别。

但一开始的分布比较稀疏，零散地分布在图中。他们希望让分布更加密集，增加更多工具和领域，于是进入第二部分：系统性地演化 Tool，通过 Hierarchical Domain Generation 生成更多工具。

这里用了 WizardLM 的数据合成方案。论文没有特别明确地说明，所谓 Tool Synthesis 或 Tool Generation，究竟是重新生成一个 MCP，还是组合现有 MCP，生成新的 MCP Interface、Description 或操作逻辑。

根据上下文和论文的描述，我猜测应该是对原来的 MCP 进行组合，并且对组合后的 MCP 重新编写工具接口、描述以及操作逻辑。

这样一来，右边的分布就变得更加密集。通过这两步，第一步获得 3000 多个 Tool，第二步获得 2 万多个 Tool，从而得到一个超级大的 Tool-Use Action Space。

接下来是 Agent Diversification。

他们通过生成大量 System Prompt，在不同场景下创造各种 Agent。System Prompt 是放在 Language Model 里，用来定义 Agent 行为的 Prompt，比如它有什么能力、擅长什么领域，以及具有什么行为模式。

有的 Agent 擅长写代码，有的擅长数据分析，有的擅长项目管理，有的情商比较高。

这个过程本质上是在为下游用户的应用场景创造环境。比如从 2 万多个 MCP Tool 中随机选择 10 个，那么当前场景里就只有这 10 个工具。接着在这个场景下生成任务，并规定 Agent 的行为。

这样在 Data Synthesis 时，就可以不断逼近下游应用场景，模型在真实使用时也会更加自然。

这也是保证数据 Diversity 的一种方案。假如笼统地告诉 Language Model 使用这些 Tool，它未必能生成非常多样的数据。但如果给它具体 Context，让它进行角色扮演，知道自己的 Role，生成质量就会更好。

到这里，相当于定义了 Action Space，创造了各种小型 Tool-Use Environment 以及对应的 System Prompt。

接下来，要在某个小 Environment 中生成 Rubrics 和 Task。

Rubrics 是一段文本描述，用来说明一个 Task 在什么时候算完成。它的作用是筛选生成的 Trajectory 或 Data，因为我们不能保证每个 Task 都能被完全完成。

具体来说，针对每一个 Agent Configuration，也就是 System Prompt 和对应的 Tool，他们从中生成 Task。

比如，我选择了 10 个用于市场营销或数据分析的 MCP，同时生成一个 System Prompt：“你是一名数据分析和市场调研专家，需要完成某项工作。”接着基于这个 Configuration 生成 Task，比如调研市场上所有水果的行情，或者 GPU Provider 的价格和市场变化。

他们还采用了 Simple-to-Complex 的操作，逐渐提高生成难度。一方面保证生成质量，另一方面保证数据的 Diversity。

生成 Task 的同时，也会生成对应的 Rubrics，指定成功标准、预计使用的 Tool 模式，以及 Evaluation Checkpoint，也就是进行到哪一步算完成了多少，最终成功条件是什么。

实验上看，Task 和 Rubrics 同时生成，通常会更加准确。因为生成 Task 时，模型可能已经能够预测之后 Evaluation 的标准。

接下来是 Multi-Turn Trajectory Generation，也就是开始真正生成 Trajectory Data。

第一部分叫 User Simulation。他们用一个 LLM 生成 User Persona。Persona 是对一个人的性格或属性的描述，比如一个研究 AI 的理工科大学博士生，以及他的兴趣爱好。

但下游使用时会有各种各样的用户，有产品经理、律师、厨师，每个人都有不同的交流需求、交流方式和完成任务的偏好。

所以通过这种方式，可以模拟下游应用场景，让 Agent Performance 更接近真实用户。同时，加入 Persona 也是保证数据 Diversity 的一种方式，因为它迫使 LLM 在生成 Trajectory 时，和各种不同的 Communication Distribution 交互。

用 Persona 提高数据 Diversity 的方案，在很多地方都出现过，从实验上看确实是很好的方案。

接下来是 Tool Execution Environment。我们有了 User 和 Agent，还需要真正执行，获得 Environment Feedback 和更新后的 Observation。

他们建立了一个 Tool Simulator，并称其等价于一个 World Model。论文没有详细说明这个 Simulator 究竟是什么。

我有两个猜测。一个是它可能真的使用 Neural Network，也就是一个训练好的模型来模拟环境；另一个是建立某种 Sandbox，比如在本地建一个小环境来提供 Simulation。

根据论文描述，我更倾向于前者。但无论怎么优化 Simulator 或 World Model，它和真实世界可能还是会有很大差异，因此会产生噪音，数据也不一定完全真实。

所以他们后面提到采用 Hybrid Approach，不仅需要仿真数据，也需要和真实环境交互的数据。

对，这里确实比较模糊。听众朋友们也可以自己看一下论文，看看你们认为它具体是怎么实现的。

接下来是 Quality Validation and Filtering。

我们前面提到，不能保证每条 Trajectory 都成功，所以需要用 Rubrics，让 Language Model 判断这个 Task 有没有成功完成。成功了就把数据留下；不成功就重写，或者直接丢掉。

到这一步，我们就获得了足够的 Synthetic Data。接下来就是 Hybrid Data Synthesis。

为什么需要 Hybrid？可以进一步讲一下 Simulation 和 Real World 的 Trade-off。

我觉得现在对 Agent 来说，一个很大的难题，是如何让它和环境的交互变得高效，并且把成本降下来。

学界可能在一定程度上低估了环境交互的价格，但实际上它非常贵。

比如训练 Deep Research 或 Search Agent，如果使用真实环境，就需要调用 Google Search API。这个 API 不是完全免费的，因为涉及 Google Cloud 的算力，以及它为互联网建立的 Index。

即使一次调用只要 1 分钱，但 Deep Research 会进行大量搜索。我的粗略估计可能是 100 到 150 次，价格也不少。训练时需要大量 Rollout，大量搜索，成本会非常高。

在 Browser 或 Computer-Use 场景下，价格可能更贵，因为要和真实网站的 Server 以及 Browser 交互。

假如直接把 Web Agent 跑在网站上，运行次数多了，IP 地址可能就会被封掉。这是真实发生过的事情。比如我公寓和实验室里的电脑 IP 都被封过，实验室里大家跑实验，也在一定程度上把学校 Cluster 的 IP 跑封过。

这是很多做 Web Agent 的朋友都遇到过的普遍现象。

所以现在可能会使用 Cloud Browser，也就是云端浏览器。它们有自己的 IP Address，也做了大量工程优化来防止 IP 被封，但收费特别贵。

比如 Browserbase 的 B 轮融资也拿了不少钱。它们通过提供这类 Service，可能赚到很多钱。

粗略估计，假如做 100K 次 Rollout，也就是生成 100K 条抓取轨迹，光交互成本可能就要几千美元，这个价格非常高。

当然，也可以在本地 Host Sandbox Environment，比如开一个 Docker，在里面部署网站前端和后端，然后进行交互。但 CPU 和 Memory 成本也很高。一旦同时开大量 Sandbox，对环境本身也是很大消耗。

Kimi、Qwen3-Coder 和 OpenAI 都在解决这个问题。Hybrid Approach 的意思就是，在 Sandbox Simulation 里相对更容易、更快、更稳定地产生交互，从而获得更多数据；但这些数据的真实性肯定有噪音，不能保证完全高质量，所以还要和真实数据结合。

这在机器人领域里，真实数据和仿真数据的比例差别很大。机器人领域的真实数据可能只占 1%，仿真数据占 99%。

是的。机器人可以作为 Agent Environment Interaction Cost 的一个极端案例。

我们现在假设的 Agent 是 Digital Agent，成本肯定比机器人低一些。机器人真实数据需要有人操纵，运行本身也有消耗，还要耗电。

但 Digital Agent 的成本仍然很高。所以我觉得，研究 Agent 可能需要花很多精力处理环境问题：降低环境交互成本，让交互更加稳定，以及如何大量制造 Environment。

如果 RL 真的是非常有效，接下来大家的重点可能就是不断制造 Environment，在此基础上生成大量 Task 和 Verifiable Reward，作为新的 Scaling 范式。

这就是整个 Data Synthesis 方案。总结一下，他们先通过各种方案定义 Action Space，再定义各种小环境，生成各种 Prompt 和 Agent，进行 Trajectory Synthesis，最后 Filtering，获得大量数据。

核心是提高 Diversity，接下来再用这些数据训练。

这里对工程能力的需求应该比较多吧？

是的。我觉得这里有非常多的小技巧和 Trick。

Kimi K2 非常实在，很多 Recipe 和小技巧都已经放在论文里了。但是如果我们真的要把它做出来，以一种高效的方式高质量地做出来，本身可能还是很难。

每一个部分都要把 Prompt 调好，还要把各种参数调好，保证它能够平稳运行并且有很高的质量。这本身就是非常大的工程量。

这里有点像一门手艺活，需要对 Language Model 的行为、Prompt 调节、Data Synthesis 和 Filtering 有很强的 Sense。我觉得这是现在 Language Model 或 Agent Training 中非常重要的一部分。

所以研究员都是老师傅，干的是手艺活，像一个老师傅？

对。

所以这是系统工程大于 Idea，对吧？

我觉得一定程度上可以这么说。

现在很多 LLM 的 Idea，其实在论文和研究会议上都能看到。Kimi K2 的作者非常好的一点，就是把每个部分用到的 Trick，以及对应的论文都列出来了，比如 WizardLM、SolaMath 等。

很多 Idea 在学术界已经出现过，大家也在小范围内验证过，像是 Proof of Concept。

但 LLM 是一个系统工程，需要把各种 Trick 结合到一起。一方面，要放到 Language Model Training 范式下，看它究竟有什么作用；另一方面，要把它的规模放大，看看效果是什么。

现在很多 Idea 好像都已经在那里了，甚至我自己也能比较清楚地感觉到接下来要做什么，以及哪些事情可能有效。但每件事都需要大量工程，把效果真正做出来。我觉得工程是一个很大的问题。

7. 强化学习进入系统工程

这部分就是 Data Synthesis。接下来进一步讲强化学习。

我们现在进入强化学习部分。我最近主要也在做这件事，觉得这里非常有意思，可能会产生一些新的范式，还有很多可以探索的地方。

论文最上面讲到的内容，可以总结为 Scale Up RL，也就是如何把 RL 训练做得非常大规模。

Scale Up 的核心，是获得大量非常 Diverse 的 Task 和 Verifiable Reward，然后进行大量训练。这里的关键，还是如何大量获得这种数据，以及如何确保 Verifiable Reward 的质量。

并不是所有任务都能够获得客观的 Verifiable Reward。这里可以延伸一下，目前主要有两种类型的任务和 Reward。

第一种是经典的 Verifiable Task，比如数学和代码。这是 DeepSeek-R1（音）、OpenAI o1 这一波模型最早做得非常好的方向。

它们的典型特点是，任务结果或者模型生成的最终结果是对还是错，可以很容易通过程序或函数判断。

比如数学，可以判断推导是否正确，最终答案是否正确。代码则可以看它是否通过 Unit Tests。我们写一个函数或功能，可以给它写一堆测试案例，规定输入、输出和通过条件，像 LeetCode 题目的测试一样。

通过这种方式，可以快速、高质量地获得客观的 Verifiable Reward，用来训练。

但不是所有 Task 都能获得 Verifiable Reward。比如论文里提到的 Creative Writing，写小说或者自由发挥的内容，以及 Open-Ended Question Answering，就很难找到一个客观评价方案。

所以这时候就提出了 Self-Critique Reward，让模型自己判断回答结果，用它作为 Reward。

这篇论文通过大量工作，形成了一种两方面结合的 Reward 方式。

我们先进入 Verifiable Reward 部分。论文把这一部分分成 Math、STEM 和 Logic Tasks。

数学、理工科问题和逻辑推理，都比较容易获得 Verifiable Reward。比如生成答案之后，用数学 Parser 解析，或者抽取最终结果，看是否正确。

这里提到两个要求：Diverse Coverage 和 Moderate Difficulty。

第一，Task 和 Prompt 要足够多样化，这样训练效果会更强，不容易 Overfit，也能让模型有更多探索。

第二，任务难度要适中，不能太难，也不能太容易。

假如 Task 太容易，每次尝试都成功，能够获得的 Signal 就非常少。就像高中刷数学题，如果一直做简单题，全部做对，其实学不到什么东西。

另一个极端是 Task 太难。即使回答 100 次、200 次，可能也只成功 1 次，或者完全不成功，这样 Reward Signal 也非常稀疏。

假如一个 Batch 里的所有 Rollout 都失败，模型优化时可能根本不知道应该往哪个方向优化，训练方向就会变得很奇怪。

这里我发现，宣传和论文写作之间稍微有一点区别。OpenAI 会不断强调 Easy to Verify but Hard to Answer，Qwen3-Coder 也强调问题要有很高难度。

我觉得这个难度可能取决于 Base Language Model 本身的能力，是一个 Case-by-Case 的问题。

控制难度的方案其实很简单：先拿一个没有做过 RL 的模型，把同一个问题给它尝试，看看最终准确率，再基于这个结果筛选。

至于具体应该控制在什么程度，论文没有明确说明。我觉得可能会随着训练过程不断调节。

这一部分就是获得数学、STEM 和逻辑任务的过程。这类数据和 Verifiable Reward 相对最容易获得，这也是数学问题最早在 RL 中取得效果的原因之一。

接下来是 Complex Instruction Following。

对于 Agent Task，Instruction Following 能力非常重要。因为 Agent 要处理的 Context 比以前复杂得多，它要不断和环境交互，对环境反馈做出反应，不断调整 Action，同时还要和最初给定的 Task 及 System Prompt 保持一致。

这对 Instruction Following 能力提出了很高要求，而且 Context 会随着交互次数增加而变得非常长。

他们专门为 Instruction Following 生成了数据。第一部分是 Hybrid Rule Verification。

他们首先使用 Code Interpreter，对输出进行验证，比如检查长度、文本风格和各种 Constraint；在此基础上再使用 LLM Judge Evaluation，提供新的 Reward Source。

根据论文描述，这相当于防止 Reward Hacking 的一层机制。

Reward Hacking 的例子是：Language Agent 足够强之后，可能变得非常“狡猾”，发现 Reward 的漏洞并利用它。

就像高中做题时，最后猜中了答案，但中间推理过程乱写，最后依然得分。Language Agent 发现这种 Cheat 之后，就会不断 Overfit 到这个漏洞上，训练效果就会变差。

所以需要加入机制，防止 Reward Hacking。

接下来是如何生成 Instruction 和 Data，让模型进行 Verification。他们提供了一个 3 步的数据生成 Pipeline。

第一步，收集 Human-Crafted、Human-Expert-Annotated Data，找人工标注员标注复杂的 Instruction-Following Task。

这类数据很贵，也不好 Scale Up，所以第二步使用 AutoIF，也就是 Qwen 之前发布的一篇论文中的方法，自动根据种子任务扩展生成新任务。

最后再用一个反向模型生成额外 Instruction，专门涉及失败案例和 Edge Case。这样既能保证数据 Diversity，也能让 Instruction 变得更加复杂。

通过这个模块，可以生成大量考验模型复杂 Instruction Following 能力的数据，并且提供比较可靠的 Reward，来进行 RL 训练。

接下来还有 Faithfulness。

模型有时候会胡说八道，甚至它输出的 Thought、Thinking Process 和最后的答案没有太大关系。所以这里加入一个 Reward，用来减少模型 Hallucination，让答案更加真实。

他们使用了 Google 的 Fact Grounding 工作，通过 Sentence-Level Fact Judge Model，判断答案是否 Grounded，也就是其中有没有幻觉或常识性错误，再把这个结果加入 Reward。

我觉得这里很有意思。有些论文单独看，可能只是 Fact Verification 任务，但放到 Language Model 或 Language Agent 的 RL Training 范式下面，就会有额外意义，变成一种调整模型行为的方式。

我查了一下 Kimi K2 在 Hallucination Benchmark 上的分数，它的排名确实比较高，在所有模型里大概是前十左右。可能这些 Trick 起了一定作用。

接下来是代码能力和 Coding 的核心。

一方面，他们收集了大量 Competition-Level Programming Problem，比如 LeetCode 或代码比赛的数据，用来训练。

另一方面，我觉得很重要的是，他们在 GitHub 上收集大量 Pull Request 和 Issue，并且用当前 Checkpoint 搭建 Software Development Environment。

比如随机找到一个 Repository，其中有人提交了一个 Pull Request。我们可以把这个时间点的 Codebase 下载下来，用它搭建一个 Sandbox，再把 Pull Request 内容和最终 Solution 作为 Verifiable Reward 的结果。

当然，这里面也会有很多 Unit Test，用这种方法大规模扩展 Coding 或 Debugging 场景中的 Task、Verifiable Reward 和 Environment。

我觉得这是非常有帮助的一点，也可能是 Kimi K2 RL 能力的核心。

这里我想拓展一下：有没有办法让 Agent 自己主动找到 Reward Signal，然后让它自己训练自己？

假如有一个外部 Agent，它能够在网络上不断爬取和探索，也许它会偶然进入一个 GitHub Repository，发现这里有一个 Verifiable Reward 和一个 Task，然后自动把数据拿过来，自动搭建 Sandbox Environment。

即使不能完全自动化，也可以用 Agent 本身作为探索方案，去获得 Verifiable Reward。这样也许能够实现 Agent 的 Self-Improvement，也就是自我提升。

这目前更像是一个 Brainstorm，可能还没有人在真正做，但我觉得是非常有意思的研究方向。

接下来涉及如何搭建 Environment，这也是几篇论文都提到的一点。

如果要做 RL Policy Training，就需要大量 Rollout，有大量 Task 同时执行，因此会遇到环境并发问题。

他们提供的解决方案，是使用 Kubernetes，同时 Host 大规模并发的 Sandbox，在里面进行 Rollout、生成代码并获得 Verifiable Reward。

Kubernetes 可以理解为专门针对高并发和大规模场景的容器编排解决方案。这是比较成熟的工业化方案。

Qwen3-Coder 也提到，他们在阿里云上部署了大量类似的 Sandbox。OpenAI ChatGPT Agent 则提到使用了大量 Virtual Machine，为训练 Agent 提供 Rollout 环境。

最后还有 Safety 相关内容。他们使用一批人工设计的 Safety Prompt，围绕暴力、诈骗、歧视等风险进行分类，也针对 Jailbreak 场景设计了一套方案，用来提供 Verifiable Reward，进一步调整 Agent 的行为，让它变得更安全。

到这里就是 Verifiable Reward 部分。

下一部分叫 Beyond Verification，也就是 Self-Critique Rubric Reward。

这个场景需要大量 Rubric，也就是评价标准。通过这种方式，可以为 Creative Writing 等无法直接获得 Verifiable Reward 的 General Task 提供 Reward Source。

同时，通过 Rubrics 可以调整 Language Model 的行为模式。比如在 Rubrics 里加入希望模型具备的价值观或属性，包括 Helpfulness、Creativity、Depth of Reasoning、Factuality 和 Safety。

通过 Verifiable Rubric Reward，可以更好地调整 Agent 的行为，也能让它在更 General 的 Task 上进行 RL Training。

接下来就是 RL Training 部分。Kimi K2 这次在算法上没有特别大的创新，主要沿用了 Kimi K1.5 的 Mirror Descent 算法。

他们在 SFT 阶段使用 Muon Optimizer，所以在 RL Training 时也继续使用这个优化器。

再往下是 Budget Control。

Agent 在 Inference Time，有时候不希望在无关的 Action 或任务上做过多 Thinking，因为还需要更高效的 Inference。

所以当模型生成的 Response 太长时，就直接截断，并给它一个 Penalty，通过这种方式控制模型输出。

我在知乎上看到有人说，Kimi 的 Response 倾向于比较短、比较简洁，而且最后会很贴心地写一个 Summary，总结刚刚说了什么。我觉得可能和这个 Reward 有关。

Kimi K1.5 的论文里，也有一个更详细的 Reward，用来控制输出长度。这次 Kimi K2 有点返璞归真，用更简单的 Penalty 方式控制输出长度。

接下来是 PTX Loss。

模型训练时，可能会忘记一些东西。RL 更多是让 Language Agent 学会如何采取 Action、和环境交互，但在这个过程中，预训练阶段的重要知识可能会丢失。

所以他们引入 PTX Loss，从预训练数据里采样一些高质量、人工提取的数据，在 RL Training 时一起训练。通过这种方式，防止模型忘记预训练中的重要知识。

再往下是 Temperature Decay。

在模型不同训练阶段，需要使用不同 Temperature。Temperature 代表模型生成时的 Randomness，也就是生成结果有多单一或者多样。

刚开始训练时，模型能力比较弱，可以给它更大的探索空间，让它更多探索环境，生成各种多样的 Action。Action 可能是错的，但在训练初期没有关系。只要有 Positive Reward，就鼓励这种行为；Negative Reward 则减少这种行为。

通过更多 Exploration Budget，可以让 Agent 更好地探索环境，找到 Positive Reward。

但训练到后期，模型整体效果已经比较好，行为也比较稳定，这时就不希望它做过多探索，而是希望它逐渐收敛，进入退火阶段，所以后面会逐渐降低 Temperature，保证训练稳定。

到这里就是整个训练算法和 Reward 的内容。

我想特别强调一下 Infra。Agent Training，尤其是 Multi-Turn RL Setting，对模型训练 Infra 提出了新的要求。

现在很多训练框架和 Scheduling 算法，主要针对 RLHF 或传统 Rollout 设计。每轮 Rollout 的 Latency 比较稳定，也没有太多多轮交互，因此比较容易估计时间，大部分时候 GPU 都在运行。

但 Agent 不一样。第一，Agent 和环境的交互时间，也就是 Delay，不稳定。

比如 Web Agent 生成 Action 后要执行，但浏览器可能突然卡住，网络不稳定，甚至浏览器崩溃。假如没有针对训练 Infra 做优化，GPU 可能一直卡在那里，或者某个 Rollout 直接崩掉，导致 GPU Utilization 很低。

第二，Agent 是 Multi-Turn Interaction。有些 Task 两三步就完成，有些 Task 可能要二三十步。

Inference 时 Batch 相对稳定。比如一个 Batch 有 256 条 Rollout，其中 250 条 5 步内完成，花 3 分钟，但剩下 6 条可能需要 10 分钟。这样就会有大量 GPU 时间被浪费掉，专门等待那 6 条 Rollout。

Kimi K2 提供了几个解决方案。

第一，从环境角度解决。如果某个环境特别重、很占 GPU 和 Memory，运行起来消耗很大，他们就把这个环境单独包装成 Service，启动一个服务，通过 API 交互。

这样可以给 Host 这个环境的计算资源更多算力，或者单独做优化，让它变得更加稳定。

第二，使用大量 Concurrent Rollout 缓解 Latency。比如最后只需要 64 条 Rollout，但一开始可以同时启动 640 条，只要完成 64 条，就结束 Rollout 过程，以此提高效率。

还有一种方案，如果主要耗时在和环境交互，就可以在每次 Rollout 生成一个 Action 后，同时开 10 个 Environment 和它交互，选择最快完成交互的结果，降低环境交互时间的方差。

针对某些 Rollout 特别长的问题，也就是 Long-Tail Trajectory，他们采用 Partial Rollout，直接把这条长轨迹暂停，下一轮 RL Iteration 再恢复。

这个方案能够提高利用效率，但也有潜在问题：下一轮继续 Rollout 时，轨迹里的 Action 不是当前模型策略生成的。

比如上一轮 Rollout 时，模型会犯一个错误，但参数更新之后已经不会犯这个错误了。可是 Buffer 里的 Rollout 还是上一轮生成的，于是看起来模型还会犯错。如果继续拿这条 Rollout 更新模型，就可能产生问题。

总体上，他们设计了各种 Optimization 来优化模型训练效率。

代码实现层面，他们使用了 OpenAI Gym 的框架，现在对应的 Codebase 叫 Gymnasium。它基本上通过 Wrapper 处理 Agent 和环境的交互，向外暴露 Step 和 Reset 接口。

大部分 RL Training Code，基本都沿用了这一套。

后续他们可能还会把训练 Infra 扩展到更多样的 Interactive Environment，包括 Browser 或 Computer Use，让大家更容易做这类训练。

总结一下，RL 这部分就是通过大规模生成 Task 和 Verifiable Reward 做 RL Training，同时对训练 Infra 和 Environment 进行各种优化。

Qwen3-Coder 主要发布了一篇博客，没有特别详细地讲 Data Synthesis，只提到 Scale Up Data Synthesis，但花了很多篇幅描述如何 Scale Up RL Training。

他们同样需要 Host 大量 Sandbox，所以两边解决的是类似的工程问题。

OpenAI 的 ChatGPT Agent 也提到 Host 了大量 Virtual Machine，用于 Agent 在环境中探索，并且在 Virtual Machine 和环境优化上花了很多精力。

接下来我们一起看一看 ChatGPT Agent 的技术报告。

8. ChatGPT Agent统一行动

ChatGPT Agent 这边主要是一篇发布博客。我会结合最近 ChatGPT Agent 团队和 Sequoia 的一次采访，整体讲一下。

ChatGPT Agent 总体上，是把 ChatGPT 的几个产品统一到一起：Operator，也就是 Web Browsing Agent，以及 Deep Research，也就是 Search Agent 的 Action Space。

这个 Agent 一方面可以做浏览操作，比如点击网页；另一方面又可以在网页上进行搜索和大量检索，把两方面结合起来。

他们在采访中解释，为什么要做这件事：Operator 擅长理解 GUI、操作网页和浏览器，进行 Navigation，但对于寻找大量文本信息，未必是最强的。

Deep Research 的环境则是 Text Browser，上面有大量文本信息，可以进行搜索、点击新的 URL 并总结信息。

所以团队认为这两方面能力可以很好地结合起来，让 Agent 变得更强。

关于它具体怎么实现，目前有两种猜测。

第一种是 Multi-Agent 系统：一个 Operator Browsing Agent，加上一个 Deep Research Search Agent，再加上 Tool-Use Agent，最后把多个 Agent 结合起来，通过端到端 Reward Signal 训练。

第二种是直接把 Action Space Unify 到一起，让一个 Agent 同时具备 Browsing、Search 和 Tool Use 能力，再进行端到端训练。

博客里主要强调的是 RL，尤其是如何获得大量 RL Signal。他们强调 Task 要足够难，同时容易 Verify，基本上和前面说的 Verifiable Reward 类似。

他们提到一种数据，类似 BrowseComp 的 Information-Seeking 数据：给模型一个描述，然后让它找到一条非常难找、但答案很短的信息。

我可以展示一个例子。这只是猜测，我不确定它是否真的在训练数据里，但它和他们的描述非常像。

比如 Task 是找到某个信息，Answer 只是一个很短的答案，比如 “Plastic Man”。这样可以很容易给出 Reward，只需要比较模型找到的结果是否一致，或者是否包含这个答案。即使更难一些，直接让 LLM 评估是否一致，也能取得不错效果。

很多其他例子也都是答案很短，但信息非常难找。通过这种方式，可以大量、简单地获得题目和答案，同时问题足够难，能够迫使模型不断提升自己。

这有点像我们做题时，给自己出一道难题，但又知道答案是什么，通过这种方式不断训练自己。

他们还提到，会启动大量 Browser Session，进行大规模训练。但 Browser Session 有时并不稳定，需要很多工程投入才能让它真正运行起来。

我觉得 Computer-Use Agent 或 ChatGPT Agent 的训练，还有一个很大的难点：很难在 Web 环境里找到大规模、高质量的 Verifiable Reward。

如果是 Information Seeking，比如 BrowseComp，相对容易。但假设任务是下单、点击某个按钮，或者查看机票，Agent 就需要不断进行 Browsing Action。

问题是，大部分网站都无法访问后台数据，导致 Verification 比较困难。

当然，可以在小规模 Sandbox 里训练，因为能够获得后台数据。但如果真的要 Scale Up，可能需要非常高明的方式获得 Verifiable Reward。

再看 ChatGPT Agent 的博客，我目前感觉它更像是把 Action Space Unify 到一起，而不是一个 Multi-Agent 系统，但博客没有明确说明。大家可以讨论或者猜测它究竟怎么实现。

这个产品会逐步 Roll Out，ChatGPT Pro 和 Plus 用户会逐渐获得权限。

博客主要展示了各种 Use Case。第一个是让 ChatGPT Agent 制作 PPT。

以前有人说，让 Agent 做 PPT 是一件很难的事情。最早大家使用 Agent 或 Language Model 做 PPT，通常采用 LaTeX 形式，让 Agent 写代码，生成格式固定的 PPT。

但 ChatGPT Agent 能结合 Browsing Action 之后，制作 PPT 或者完成类似操作，会变得更容易。

另一个 Use Case 是把 Research 和 Action 结合起来。Agent 一方面可以调研和查信息，另一方面可以浏览新的页面，进行定制化操作，比如制作 Slides。

他们也做了各种 Evaluation。

其中 Humanity’s Last Exam 是一个非常难的任务，但它的 Success Rate 被展示得很高。也许它虽然叫“人类的最后测验”，但现在效果这么好，可能已经不是人类的最后测验，而是倒数第二个或第三个。

FrontierMath 也是非常难的数学 Benchmark，整体分数没有特别高，但相对于 Baseline 提升了很多。

此外还有各种 Knowledge Task，以及 Data Science Task。这里展示的是操作 Spreadsheet，也就是 Excel，这和前面 Demo 中的场景相互关联。

我觉得每个 Evaluation 基本都对应一个真实的用户应用场景。

ChatGPT Agent 整体大概就是这样。它和 Kimi K2 不同的地方，主要是针对 Browser，也就是 Computer-Use Agent，再加上 Deep Research Agent，比较早地尝试把两者统一起来。

但确实很难把这件事做成功，所以我觉得这是一个非常厉害的尝试。

接下来我们是不是可以看一下 Qwen3-Coder 的技术报告？它相对也比较简单，对吧？

9. Qwen3 Coder扩展浏览

对，它没有太多细节。我很想看更多细节，但我们可以做一些简单猜测。

他们发布了一个 Leaderboard，整体上是在和 Kimi K2 比较，分数确实会高一些。不过我觉得现在大家好像不太只看 Leaderboard 了，因为它未必能完全反映模型 Performance。

大家可能更在意实际使用体感，以及最近 OpenRouter 这类平台上各种 API 的使用情况。

当然，Qwen3-Coder 在 OpenRouter 上的使用排名也很高，所以这些都是非常强大的模型，在实际生活和应用中也被广泛使用。

Qwen3-Coder 相比 Kimi K2，增加了 Agentic Browser Use 任务。

WebArena 和 Mind2Web 都是 Browser Use，也就是 Web Agent 的 Evaluation Benchmark。

我们组有一项名称可能是 Mind2Web 的工作。我们在大量真实网站上，让标注员标注了很多 Trajectory，再让模型预测每一个 Action 是否正确。

这是一个比较难的 Task，因为网站和任务足够多样，要求 Agent 能够泛化到各种网站上，挑战很大。

WebArena 则建立了很多网站 Sandbox，在里面做 Evaluation。因为是 Sandbox，所以可以访问后台数据库，从而准确判断一个 Task 是否完全完成。

从结果看，Qwen3-Coder 的 Performance 确实不错，相对于其他模型有一定提升。

再看博客，Pre-Training 部分路线差不多，增加了 Context Length。Synthetic Data 只提到 Scale Up Data，没有更多细节。

Post-Training 部分提到 Scale Up Code RL，以及“Hard to Solve but Easy to Verify”。

随着训练数据增加，各种场景的 Performance 都有提升，呈现出 Scaling Law。

他们还增加了 Long-Horizon Training。如果步数特别长，模型 Performance 通常会变差，所以专门针对这一点进行训练。

这里也提到需要 Infra Support。环境支持和 Infra 优化是很大的问题。他们建立了 2 万个独立的并行环境，部署在阿里云上。

这种训练对学界可能不太友好，因为能够启动这么多 Session，本身就有很高成本，学界也需要足够的工程能力才能完成。

Qwen3-Coder 还有一点值得强调，就是现在大家常见的做法：发布模型的同时，也发布 CLI Tool。

它的 CLI Tool 可以直接对接 Gemini。我觉得这在一定程度上反映出，这些模型不只是训练模型、刷榜、堆参数，而是真的应用到了各种实际场景。

如果能够收集用户和 Agent 的交互数据，也许还能进一步改进 Agent 本身。

他们还提供了 VS Code 插件，可以直接使用。

我们还有 Manus 关于 Context Engineering 的博客，也可以简单讲一下。

10. Manus的上下文工程

Context Engineering 是 Manus 前段时间提出的一个概念，主要讲如何更好地管理 Context 中的内容，让模型 Performance 更好。

我觉得这和以前所说的 Memory 有一定关系。

这篇博客的作者也是从 NLP 和 BERT 时代过来的。那个时候模型没有 In-Context Learning 能力，只能针对一个场景或一个 Task 做好，或者只能处理一类 Task。

比如 BERT 是 Google 做的 Encoder Model，如果想让它在下游任务上做好，一定要拿 BERT 做 SFT 才行。

但 ChatGPT 这一波大模型出现之后，有了 In-Context Learning 能力。只需要通过语言描述，就可以让 Language Model 泛化到一定场景或 Task。

这样一来，只需要做一些 Prompt Engineering，就可以快速迭代出一个模型。

Manus 最初也在两个路线之间纠结：一个是 End-to-End Training，这非常昂贵；另一个就是现在的路线，专注于 Context Engineering，快速迭代出产品。

这篇博客分享了很多 Context Engineering 的经验。整体思路，我觉得是针对 KV Cache 做优化。

KV Cache 是让 Agent 更快、更省钱的一种方案。

Transformer 或 Language Model 里面最重要的概念之一是 Attention。文本或 Input 放进去之后，会生成 Q、K、V 3 个矩阵。

如果 Context 或前文一致、没有变化，K 和 V 矩阵就可以重复使用，不需要每次重新计算。这样可以让 Inference 更快，也更省钱。

他们列出的数据是，使用 KV Cache 可能只花 0.3 美元，不使用 Cache 可能要花 3 美元，差距非常大。

接下来，他们讲如何更好利用 KV Cache。

第一，让 Prompt 前文保持一致，不要修改，这样不用重新计算 KV Cache。

第二，不要修改 Context 中间的内容，只是不断把新内容追加到后面，这样也可以保证 KV Cache 不变并重复使用。

还要加入 Breakpoint。

另外，Mask 不要 Remove。如果中间有些内容不用了，比如想更换几个 Tool 或 MCP，不要直接从 Context 里删除并修改 Context，而是把它 Mask 掉，让模型生成时忽略它。

这样可以保证 KV Cache 继续复用，是一个很巧妙的小技巧。

他们还提出把 File System 作为 Context。

但这里有一个问题：采用这个策略确实能够复用 KV Cache、降低成本、提高速度，可是 Context 会不断增加，变得越来越长。Context 变长之后，模型可能会变笨。

那怎么让模型把注意力放到我们希望它关注的地方？他们提出用 Todo.md 去控制模型的 Attention。

最后一点是，如果模型中间犯了错误，出现 Failure 或做错了什么，也要保留在 Context 里面。

还有一个关于 Few-Shot Learning 的例子。

当我们希望模型具备某种行为模式，或者遵循某种格式时，会在 Context 里放一些 Example。比如 Action、Observation、Action 1、Observation 1、Action 2、Observation 2，这样 Agent 就会进一步遵循新的 Action。

但他们提出，Context 或内容最好更加 Diverse，而不是高度一致。否则模型可能倾向于不停重复前面的内容，生成时出现重复，浪费 Token，或者产生无用内容。

这里我想延伸到 Agent Memory。

Agent Memory 可能需要很多新工作，才能做得更好。传统 Chatbot 的 Memory，通常是持续聊天产生的非结构化数据。

但在 Agent 场景中，交互和数据高度结构化，有 Action、Observation 和 Environment Feedback，而且轮数很长。

所以我们可能需要一种机制，结构化地管理 Agent Memory。比如某个 Action 之后会发生什么，或者每次有新的 Action 时，怎么判断它是否有用，怎么把它插入 Memory。

也就是说，可能需要一个高效的增删改查机制。当某个 Action 执行之后，需要修改某条 Memory，就可以快速修改。

目前这方面可能还需要更多研究。这就是 Manus 博客的主要内容。

今天我们把这几篇技术报告都完整讲了一遍。信息量非常大。接下来你觉得 Agent 未来的发展会是什么样？

11. Agent走向自我提升

我觉得这非常刺激，有很多好玩、有意思的事情可以发生。

我可能从研究和应用两个方面来说。

从研究上看，我觉得最有意思的事情是：能不能用 Agent 作为一种方式，实现 Self-Improvement，也就是自我提升。

前面讲 Kimi K2 时，我们提到 Kimi K2 的研究员手动在 GitHub 上找了一些 Pull Request 或 Issue，基于这些内容建立 Sandbox，让 Agent 做 RL Training。

但假如 Agent 能够自己在网页上执行 Action，自己爬取、自己探索，自动找到这样的训练 Reward 和 Environment，或者不完全自动化，只负责找到候选环境，再由研究员或工程师筛选，提供给 Agent 训练，也许就能让 Agent 自己寻找 Reward，进一步不断自我提升。

假如 Web Agent 已经足够强大，能够稳定、高效地在网站上爬取和探索，它也许可以成为一个非常高效的 Data Engine，找到新的、之前没有被发现的数据。

它还可以不断和网站交互，这也许本身就是 Agent 自我学习的过程。

另外一个有意思的点是，在 RL 范式下，能不能更高效地利用 Rollout，也就是 Agent 和环境交互的数据。

目前的强化学习范式，是先做 Rollout，最后通过 Verifiable Reward 得到一个 Reward 值，再用这个结果训练。但 Rollout 过程中有很多数据，我们其实没有高效利用起来。

也许可以从 Exploration 或 Rollout 数据中抽取有用知识。

比如我前段时间做了一个工作，叫 SkillWeaver。具体来说，我让 Web Agent 在一个新环境中自己提出可完成的 Task。

比如在航班网站上，它可以提出“我要订一个航班”，或者搜索某个信息。接着 Agent 自己探索、自己执行，尝试完成这个任务。

它还有一个 Reward Model 模块，可以判断这条 Trajectory 或探索是否成功。如果成功，就把探索轨迹转化成一个 API。

通过这种方式，可以把 Agent 的 Rollout 和 Exploration 过程，转化成大量有用的 Procedure Knowledge。在这个案例中，就是大量 API。

我们可以随机拿一个网站，自动为它生成大量 API。之后在 Inference 或用户需要时，Agent 就不必从头一步一步执行 Action，因为那样很慢，每一步都需要重新经过模型生成，而是可以直接调用 API，快速执行。

这只是一个简单例子。我想说明的是，Agent 的 Rollout 和 Exploration 过程中有大量有用数据和知识。也许我们可以把它们积累起来，进一步提升 Agent 或 Language Model 的能力。

这也许可以成为 Language Model 或 Agent Self-Improvement 的一种方案。

从应用层面看，也有很多有意思的事情。现在 Agent 逐渐接近真正有用的阶段。

比如 Coding Agent，基本上每天都和人类一起工作。我现在很多代码都是 Agent 写的，我更多是在修改它，给它提供 Reward。

假如有大量 Agent 产品出现，那么人类用户和 Agent 交互、使用它的过程，其实就像是在做标注，或者不断给它提供各种 Reward。

随着产品越来越多，我们可以利用人类和 Agent 的交互数据，进一步提升 Agent 能力。

这让我想起几个事情。比如 Murati 他们（可能是 Thinking Machines Lab）提到过 Research-Product Co-Design，也就是研究和产品相互迭代。

获得数据，再进一步提升研究和模型能力，也许会形成这样的循环。

前段时间 Windsurf 被收购，我觉得收购方看中的一个很有吸引力的点，就是它积累了大量用户和 Agent 数据。

不管是用这些数据进一步改进 Prompt，还是训练 Agent，都可以很好地提升 Agent Performance。

除此之外，Agent 和人类的交互方式也有很多需要改进的地方。

比如我自己使用 Web Agent 时，发现我的指令大部分情况下其实非常含糊。大多数人不可能一次性给 Agent 最精准的指令。

我曾经试过一个案例：我想买一台咖啡机，第一印象是告诉 Agent：“帮我找一台咖啡机，价格在 100 元以下，这是我比较关注的点。”

但它找到结果之后，我发现种类太多了，而且我也不想让它随便买一台。

这时候 Agent 应该学会，在信息非常含糊的情况下主动提问，比如询问需要什么颜色、什么品牌，还有没有其他要求，从而把需求变得更明确，最后完成任务。

也就是说，Agent 需要不断主动和用户沟通，解决 Ambiguity，让使用体验更加舒适。

Coding Agent 在这方面做得非常好。比如我有时候写代码，一开始也不知道自己到底要写什么。Agent 会不断和我迭代、修正，最后我终于明白自己要写什么，代码也写出来了。

大概就是这几个展望：研究上有很多有意思的探索方向，应用上也越来越接近日常生活。我特别希望看到 Agent 被大家真正用于日常工作。

你觉得 Agent 和人类最后会构建出一个什么样的关系或者网络？我不知道怎么描述比较好，是共生体，还是其他什么？

我有时候觉得，Agent 是我的另外一个大脑，是一个拓展的大脑。

所以以后每个人都会有一个分身？

可能是一个分身，也可能是一群分身。

比如我的 Coding 会交给 Claude 做；有时候帮我润色论文或者写作，会用 ChatGPT；Gemini 的长 Context 特别强，所以我有时喜欢把一堆文档交给它，让它帮我整理内容。

最后相当于，我日常做事情时，背后有一个军团在帮我。

有时候我也会和 ChatGPT 聊天。有些不太确定的事情，我会先和它聊一下，看看它有什么回复。但当我需要非常尖锐、非常刻薄的建议时，就会用原生 DeepSeek。

因为 DeepSeek 有时候说话比较直接，但它的观点非常鞭辟入里。

所以我感觉，以后每个人都可能会有一大串 Agent，组成一个 Family of Agents，帮助大家做日常生活中的各种事情。

所以 ChatGPT、DeepSeek，以及元宝、豆包、Kimi，它们的性格个性还是很不一样的，对吗？虽然看起来好像都是差不多的 Chatbot。

是的。DeepSeek 比较特殊，它说话特别直接。我觉得这反而可能让它挺可爱，可能是因为训练数据里有很多贴吧数据。大家也喜欢调侃这一点，在社交媒体上可以看到很多 DeepSeek 说话尖锐的内容，挺有意思的。

我有时候特别喜欢逗它。

元宝就比较“舔狗”。

ChatGPT 好像最近也变得情商更高了，但它情商变高之后，好像变笨了。情商高是调什么参数？

我觉得应该是在 Alignment 时，让它更符合人类的倾向。

比如我们刚才说到 Kimi K2 的论文，它里面有一个 Rubric-Based Reward。Rubrics 里可以写 Helpfulness、Creativity，也可以加入情商高、有同理心、说话好听等要求。

当然，也可以反向调整，让它说话更加尖锐。

你觉得今年 Agent 可以发展到什么程度？明年呢？Agent 已经爆发了吗？

我觉得要看不同场景。

Coding 已经爆发了。大家可以看到现在的 Coding Agent，比如 Cursor、Windsurf，还有 Augment Code 等公司。

以我目前的感受，我和朋友们现在自己写代码越来越少，基本都是让 Agent 先写一个大概，再自己修改。

它们有些地方还不太擅长，比如系统层面的代码，像 Ray，或者多进程相关的代码。但写前端之类的任务真的非常强大。

而且它的增长可能会越来越快。加上更多用户交互数据之后，我觉得 Coding 可能会爆发得特别快。

Tool Use 可能也会很快，但它的 Infra 仍然有难度。Browser 这边的 Infra 难度可能更高一些。

总体来说，我觉得它的发展会非常快。

现在选择 Agent 作为研究方向的博士生多吗？

现在挺多的。其实从论文数量就能看出来，论文实在太多了，每天都有大量 Agent 论文出现。

我刚开始读 PhD 的时候，这个领域可能一周一变，甚至一个月一变。有一次我休息了两周，没怎么看论文，回来之后发现整个领域变天了，觉得非常可怕。

今天也感谢你。你是早上凌晨 3 点钟起来，凌晨 5 点钟给我们录播客。

没有，正好倒过来了。非常开心能和大家一起聊一聊，也非常感谢小珺的邀请。