[音乐]

[音乐]

[音乐]

[音乐]

[音乐]

圣严：欢迎收听We播客。非常感谢你参加。 盛燕：是的，谢谢。非常高兴能来到这里。这是我第一次上播客节目。

[笑声] 圣严：太棒了。我很荣幸能主持你的首次播客亮相，而且我一直很欣赏你在“扩展发现需要遗忘”（Scaling Discovery Requires Forgetting）这篇论文中的工作。显然，我在DSPy社区看到了你许多出色的作品，比如“DSPy断言”（DSPy Assertions）等。真的很高兴终于能一起头脑风暴、探讨这些话题，这太棒了。所以我想以你的论文《扩展发现需要遗忘》作为开场。也许我们可以先谈谈“发现”（Discovery）这个词，究竟什么是发现？

盛燕：是的。这是一个很好的问题。我认为很多人对“发现”有着截然不同的定义。而我们关于发现的观点，源自我们早期的一项工作——Jephtha（杰夫萨）。简而言之，Jephtha是一个提示词优化器，它利用大语言模型（LLM）作为提议者或优化器来优化你的提示词。

当我们进行Jephtha的研究时，我们逐渐意识到，Jephtha不仅仅适用于提示词优化，它同样适用于其他任务。因此，我们开启了一系列研究工作：利用LLM甚至智能体（Agents）作为提议优化器，来优化文本制品。这可以应用于代码、内核等不同领域。你们中很多人在GPU上针对不同的内核做过类似的工作，甚至包括智能体框架（Agent Harnesses）。

换句话说，你可以利用文本优化任何事物。我们所说的“发现”，是指通过这种优化过程，形成一个自然的优化树结构。在这个结构中，每个候选方案都依赖于其父节点，并且某些候选者相比其他候选者在性能上具有优势。这种树状结构非常类似于文本制品的发现过程结构。

圣严：这里有很多有趣的思想。我也想到了JEPA与GEPA的区别。我原本以为我们会叫它GEPA，但……

[笑声] 盛燕：你可以继续说。我刚从Weaviate公司的团建旅行回来，我们在那里学习了杨立昆（Yann LeCun）提出的JEPA模型。

圣严：哦，是的，名字巧合地相同了。很多人都在讨论这个。不过我们是从G开始的，不是J。但JEPA确实是一项非常好的工作。

[笑声] 圣严：那么，我想先深入探讨一下GEPA的进化结构以及它如何创造多样性。那种提示词提议树的构建方式，我们将在接下来的一个小时播客中深入讨论。但我认为关于“优化任何事物”这一主题，特别是将提示词优化扩展到代码优化的部分也非常值得探讨。我想先从这个角度切入：提示词优化与代码优化有什么相似之处，又有什么不同？

盛燕：这也是一个很好的问题。在JEPA之后，我们发表了另一篇名为《优化任何事物》（Optimize Anything）的论文。正如标题所示，我们在该文中讨论了优化不同类型制品之间的差异，并提出了三组不同的问题。

提示词优化类似于一种泛化测试。如果你仔细思考，它与框架（Harness）优化类似：你希望优化的对象具有足够的通用性，能够处理大量不同的输入。因为你不想让提示词仅对单个用户查询有效，而是希望它能应对各种情况。

在训练或我们所说的优化过程中，你只能访问整个数据分布的一个子集。因此，当你优化提示词或框架时，没有办法确切知道该提示词将在哪些具体输入上运行。

程序优化则略有不同。很多时候，人们在进行程序优化时只关心特定的那个程序。例如内核优化的例子：如果你正在优化一个内核，人们通常只是针对特定GPU上的某个具体内核（如mad mar内核等）进行优化。你并不真正关心这段代码是否能在其他任何事物上泛化。

因此，这种优化过程是你可以信赖的。如果你的分数在优化过程中提升了10倍，你知道在生产环境中它也会提升10倍，因为你是直接针对该目标进行优化的。我们在论文中将这称为“单问题优化”。

还有第三种类型，介于两者之间：你并非直接优化单个制品，而是希望优化一组制品。例如同时优化10个或100个内核。在这种情况下，你无法一次性重写每个内核。因此，这可能是一种中间状态：你可能仍然在编写提示词来生成内核，但你并不关心训练数据之外的泛化能力。因此，你不必过于谨慎地处理验证等问题。我们大致将这些问题分为这三类。

圣严：这种关于泛化的观点非常有力，特别是当你训练模型而非提示词时，或者在编写代码时的对比。我也觉得评估成本可能更高。我们最近刚做了一期播客，邀请了Merv Shaw、Shu和Alexander……

盛燕：哦，是的，我们是朋友。 [笑声] 圣严：我们是非常好的朋友。我对使用Claude Code从头编写整个数据库的想法特别感兴趣，我想扩展一下对Claude Code可能性的认知。对我来说，这与训练或评估模型的关键区别在于：那种评估真的非常昂贵，因为你必须用大量数据加载数据库，这需要花费很长时间。

盛燕：对，没错。

这也是我近期对这个领域的一些思考。我一直觉得，在自动化研究（Auto Research）的世界里存在两条平行的时间线。一条是类似 JAX 风格的路径，即使用框架来进行优化；另一条同样优秀的平行路径则是类似 Capacities 的自动化研究风格，即你只有一个编码代理（coding agent）加上一个提示词。在这个提示词中，你告诉编码代理要优化什么、如何优化以及如何评估。这两种方法各有利弊，但随着自动化研究越来越流行，许多人实际上在日常工作中都在使用它。

正如你所说，我认为目前最大的问题之一是评估可能非常耗时。由于只有一个编码代理，所有控制权都掌握在它手中。如果评估花费很长时间，代理就必须等待信号才能继续推进。因此，Shu 等人最近提出的“发现”（Discovery）工作正是为了解决评估耗时较长时该怎么办的问题。

关于遗忘的工作，我们可以稍后更详细地讨论一下。当我开始这项工作时，我也意识到评估有时会很漫长，我们需要为此做些什么。这自然过渡到我们要讨论的主题：规模化发现需要遗忘。首先，什么是“发现”？在这个特定语境下，“遗忘”又意味着什么？

在我们为 Optimize Anything 进行大量实验时，有一件事让我们感到震惊。在开发该框架时，我们的目标是让它成为所有此类优化的通用前端接口，以便切换不同的后端。因此，我们在 Optimize Anything 中实现了多种后端，包括 Jepa、类似 Agent Big One 的自动化研究框架以及另一个名为 Meta Harness 的框架。

在进行相关实验时，我们意识到所有这些框架和不同的后端在启动轨迹优化中都遇到了相同的问题：一段时间后，进展似乎停滞不前。你会看到编码代理或优化器的轨迹起初上升极快，它们非常擅长将单一基线转化为更复杂的版本。

但随着优化进行到两小时左右，情况开始趋于平缓，整个过程中看不到太多进展。这促使我们思考是什么阻碍了进度。于是我们在实验中尝试了一个简单的技巧：将目前找到的最佳候选者放入另一个优化器中。当时我们想，也许 Jukebox 卡住了，而自动化研究可以解开这个僵局。

我们将来自 Jukebox 的候选者放入自动化研究中，效果非常好，另一个优化器开始对其进行优化。随后我意识到，将其放入另一个优化器并非成功的关键；关键在于遗忘其他所有信息，只保留目前为止的最佳候选者就足以打破僵局。因此，在我们语境中，“遗忘”意味着一旦陷入停滞，我们就不需要任何上下文背景，只需要该情况下的单一最佳候选者。

这让我想到了 Geppa 中的帕累托前沿（Pareto frontier）概念，我觉得这个想法非常酷。它展示了模型在某些样本上表现良好的一种历史持有方式。这也让我联想到我个人使用 Claude Code 进行自动化研究风格优化时的体验，我将“遗忘”视为在迭代过程中消除庞大的历史记录。

任何广泛使用编码代理的人都有过这样的经历：模型开始轻微漂移，做了你不希望它做的事。当你告诉它不要这样做时，它会遵循指令几个回合，但随后又会重蹈覆辙，因为这种行为已存在于上下文记忆中。这并非旧模型的特有现象，而是因为它们被训练去关注大量上下文信息，这对所有编码代理来说都是不幸的。

这种情况也出现在启动轨迹发现任务中。关于长上下文仍有大量研究要做，即使模型能处理它，这样做是否最优呢？虽然存在上下文压缩等技术，但这激发了我们对多样性的思考。例如代理团队的设计：很多人考虑让 Claude Code 在多个终端同时运行，如何设计发现型代理团队是一个值得深入探讨的有趣话题。

是的，遗忘之所以有效的一个主要原因是，即使是单个智能体也会随着对话时长的增加而失去两样东西。首先它会像你所说的那样丧失多样性，因为会话越长，智能体在特定方向上就会变得越固执。它会尝试该方向的不同版本，因为它从这个方向看到了良好的信号。假设算法A表现很好，编码智能体可能已经通过实现该算法取得了很好的结果，因此它们非常有动力去微调这个算法以使其更好。这就像人们在训练模型时找到一个好的架构，然后调整不同的超参数来更好地训练模型一样。

其次，随着会话变长，智能体还会失去动力。关于多样性这一点，当你拥有多个智能体时，你自然会增加多样性。如果你多次采样相同的路径，你就通过重复或并行采样获得这种多样性。有人可能会认为，在这种发现任务中增加多样性的方法就是堆叠智能体，比如并行运行八个或一万个。但这类自动研究任务不同，所有任务的轨迹都很长，意味着当前的编码智能体无法一次性解决这个问题。

它们都会先尝试实现一些东西，然后再进行修改。在进行这种试错和迭代改进时，你无法避免在优化过程中使用长上下文。这就是为什么即使只是想进行并行采样这种最简单的扩展发现方式，你仍然需要遗忘机制。我们在论文中表明，遗忘不仅有助于团队设置（即允许协作沟通），也适用于单智能体和并行扩展场景。

关于设计智能体团队，有两种思路。一种涉及不同角色如规划者、实现者和设计师；另一种则是给初始规格，让智能体提出多种解决方案并行工作并同步。我们实现团队的方式非常简单：开放所有智能体的工作区，让它们互相查看代码，但没有直接通信。这是因为直接沟通会消耗大量Token且往往浪费智能体的时间。

如果任务需要广泛协作，点对点通信是好的；但在这里，每个智能体都朝着同一个目标努力——让内核运行更快。因此，拥有较慢内核的智能体去询问已有快速内核智能体的做法没有意义。更有意义的做法是，较弱的智能体检查其他智能体做了什么，并尝试将他人的想法实现到自己的代码库中。

这种机制在我们的用例中非常有效。这个灵感来自几个月前的并行实验，当时我们没有很好地隔离智能体，它们无意间开始互相查看。结果得分很高，我发现这是因为这种机制起作用了。唯一的缺点是智能体会尝试复制彼此的代码，导致多样性丧失，使团队行为类似于并行采样。

为了解决这个问题，我们实施了一个小技巧：不允许智能体直接阅读其他人的代码，只允许它们查看他人的提交记录。这是一个非常简单的技巧，但效果显著。

我认为其工作原理是，智能体无法直接看到完整的文件。它们只能查看其他智能体的差异（diff）。在这种设置下，许多时候智能体之间的差异实际上对应着某种想法或算法。因此，其他智能体（例如较弱的智能体）会尝试将这些差异合并到其自身的代码库中，而不是简单地复制整个文件。不过，我想我们可能会发布另一篇博客文章来详细讨论这一点。这是一种非常不同的通信视角。

是的，我在软件行业已有五年经验，我认为差异（diffs）绝对是查看代码更改的最佳方式，相比于阅读整个文件。没错。完全正确。

是的，这种“用于多智能体通信的 Git”概念听起来非常强大。我想很多人使用的另一种解决方案可能是使用 Markdown 文件，或者有一个编排者智能体来检查每个并行代理的进展。例如，查看它们是否提交了当前的进度更新，这可能是另一种处理方式。

是的，我认为许多人使用的另一种非常常见的方法是拥有一个协作式的草稿区（scratchpad），每个智能体都可以写入，也可以读取。作为研究社区，我们仍处于早期阶段，尚不完全清楚哪种方法最适合不同类型的问题。在我看来，这些通信方式都非常依赖于具体问题。对于不同的问题，你需要不同的通信模式。我们选择了一种适合我们的方法，但我认为那里还有很多研究机会。

是的，这让我想起了 GEPA 以及帕累托前沿的概念。我想当你找到一个能在某些异常样本上起作用的小提示词调整时，它只是回到了当前的进化池中。这里可能缺乏一种结构化的通信机制，即“我在这个特定样本上发现了这个更新”。

是的。这确实激发了关于自然语言作为优化器的思考，以及它可以多么结构化。是的。我想谈谈我们对 GEPA 的想法。我们最初发明这个帕累托前沿池的原因是为了增加多样性。如果你想想看，在 GEPA 之前，人们在自动研究中通常只保留得分最高的候选者。

这样你的种群就会逐渐失去多样性。因为提示词优化的一个大问题是，假设你有 10 个不同的问题需要解决，也许提示词 A 能解决问题 1、2、3，而提示词 B 能解决 4、5、6。虽然它们都解决了三个问题，但它们处理的是完全不同的不相交的问题集。这意味着这两个提示词对于作为你进化的基础都是有价值的。

如果你移除其中任何一个，你就会丢失重要的信息。这就是我们在 GEPA 中保持多样性的方式。我认为 GEPA 是一个很好的算法，不仅适用于我们特定的框架，你还可以将这个帕累托池的概念实现到许多其他框架中。而在遗忘或优化类工作中，问题设置略有不同，我们不太关心泛化能力。

我想因为你不关心泛化，所以很难形成这种帕累托前沿池。因此，我们保持多样性的方式开始转向进化。所以我们更多地思考如何改进生成的多样性。并行采样肯定是一种方法，而遗忘则是保持更多多样性的自然延伸。我认为是的，多样性在发现中确实非常重要。

好的，让我们回到之前关于提示词优化与代码优化的话题上。我对这个话题非常着迷。早些时候我们讨论过泛化，在这个语境下可能完全不同。现在我在想，如果代码试图优化一个数据库系统，那么帕累托前沿就是不同类型的负载。你可能会有一种工作负载……

当然。是的，没错。这是一个很好的思考角度。如果你有这种用例，那就太好了。就像你想一想，Harness 也是代码，对吧？但它需要处理不同类型的输入。所以你不希望你的编码智能体只针对数据库应用程序工作，你希望它们是通用的。

因此，如果你想优化你的编码智能体 Harness，GEPA 的想法在这里仍然非常适用，因为你可以为 Harness 保持帕累托前沿。我想我们之前做过一些关于 Arc AGI Harness 的实验，效果很好。但我们还没有在编码智能体上进行大量实验，不过我认为这也是一个很好的方向。

是的，我喜欢这个想法：也许你有一组帕累托前沿的 Harnesses，当有新输入时你就路由到它们。我曾做过一项名为“检索 DSPI”的代码工作，旨在为信息检索程序搜索不同的 DSPI 程序。比如 Bright Benchmark，那些是长长的 Stack Overflow 帖子。在这种情况下，你可能需要一个能将查询分解为子查询的 Harness；而对于 Beer 或 Latte 这种短查询，你可能只需要获取结果然后重新排序。不同的输入需要不同的 Harnesses，就是这个意思。

是的，没错。这也是我……

我还在 Databricks 做过实习生。在那里我看到很多情况类似，人们往往害怕过拟合。有人称之为“路由”，比如根据数据先判断再决定加载什么代码或使用哪种工具，这本质上是一种过拟合。但我认为我们不应害怕过拟合，因为在生产环境中，如果你针对整个生产数据分布进行优化，那就不算真正的过拟合。

我们在 Java 中也尝试了类似的路由机制（如提示词路由），效果很好，即使用多个不同的提示词而非单一一个。我认为这是一个很好的方向，但目前似乎有些被低估了，很少见到人们频繁讨论这一点。

这就像深度学习中的经典观点：不需要泛化能力，只要训练集覆盖全面即可。这正是“痛苦教训”的核心所在。我认为优化过程应产生多种解决方案，这是一个强有力的理念，对于提示词和工具来说很直观。

但在数据库系统中则不那么直观，因为存在操作开销的问题。评估变得复杂：如何定义良好的指标？假设有十个不同任务对数据库性能贡献均等，它们在不同代码或输入下可能表现出不同的行为。

我记得 Shu 曾告诉我，他们的工作负载中不同输入确实需要不同的代码处理。内核优化也是如此：针对不同类型的输入生成专用代码是常见做法，例如根据输入大小生成特定优化的内核。

我可以想象将帕累托前沿的概念应用于此，即根据输入大小保留不同的候选方案并计算得分。虽然尚未尝试，但这确实是一个有趣的探索方向。

抱歉，我没有内核优化的经验。我想把话题带回数据库领域：我有些不同意“即时编译”（just-in-time）数据库的愿景，觉得这过于激进。我更倾向于一种分离存储架构：先用通用系统摄入数据和负载，然后像分支数据库那样将数据迁移到专用系统中。

我不认为会是真正的“即时编译”，因为那听起来很可怕，比如没有代码只有规范，输入来了才现场生成。但这确实是一个有效的观点。“即时”在这里可以有多种含义：一种是根据输入从头生成整个引擎，这让人担忧。

另一种理解类似于离策学习（off-policy）：不直接为当前输入生成最佳数据库，而是观察输入趋势或模式。当自动研究代理判断新引擎已成熟且基于预测曲线更具性能优势时，再进行切换。

我同意你的看法，不会是没有代码只有规范那种可怕的情况。虽然不能完全即时生成，但仍可以在运行时动态生成部分内容。

你也可以将其视为针对特定工作负载开启一个新分支，为该客户部署后在后台通过拉取请求（PR）解决。这确实是一个光谱：取决于编码代理的能力。

回想两三年前 GPT-3.5 或 4 时代，有一个 Python 项目很“笨”，只需写注释就能在运行时调用语言模型实现函数。当时人们觉得这是个笑话，因为那时的模型只能生成简单内容。

但我认为这在不久的将来可能会变得非常现实：代码的某些部分甚至没有预写，而是在运行时生成。据我所知，目前尚未有人真正大规模实现这一点。

关于基础设施领域的自动化研究，虽然有人以原则性的方式思考此类方法，认为无需全部代码即可由系统承担繁重工作，但我对此前的观点有所保留。我拥有五年经验，曾认为编译是静态过程，但发现其可在运行时进行。尽管了解编译耗时较长，但我对此领域细节知之甚少。有人引用林纳斯的观点指出，人们信任编译器是因为理解其输出；同理，当自动研究系统足够成熟时，用户将不再审视结果，而是直接信任函数头能实现预期操作。这种信任很大程度上源于测试覆盖和先验知识，即默认系统会按意图运行。

在自动化研究与实际生产之间存在巨大鸿沟。研究中，指标定义简单且评估快速（如十分钟出结果），容易获得高分；而在生产中，优化整个流水线往往面临评估困难或缺乏明确指标的问题。许多时候的“指标”实际上是高级工程师的主观审批，这几乎无法模拟。我希望更多人致力于研究如何定义这些难以量化的指标。鉴于当前大语言模型和编码代理在“爬山”式优化上表现卓越，若能将其转化为可量化的指标，我们将能利用代理进行更广泛的优化，从而显著提升编码生产力。

这一观点引发了关于评估成本的讨论。一方面存在时间或金钱成本极高的问题，例如运行一次评估需花费数天或数十万美元，这极大地阻碍了迭代；另一方面则是人类主观意见构成的瓶颈。虽然已有如Persimmon等研究试图通过自然语言反馈来缓解人类评估的局限，但高昂的计算成本问题依然严峻。在真实工作场景中，如训练模型或进行大规模实验时，启动编码代理并让其占用大量GPU资源会导致巨额开销。因此，如何在保证效果的同时降低评估成本，仍是亟待解决的关键难题。

最后回到“遗忘”这一主题，这不仅是代理记忆管理中的上下文控制技巧，也涉及机器学习和神经网络优化中“主动遗忘”的元概念。在我们的实验中观察到，当上下文窗口达到30万至40万字时，DeepSeek v4.1 Flash模型会声称已达到优化极限。然而，若我们持续要求继续优化，模型在重新思考后往往能提出新想法并提升分数。随后它又会回到“已达极限”的状态，反复多次。这明显表明之前的结论是错误的：只要还能找到更好的解决方案，就说明并未真正触及极限，“遗忘”旧有的限制性思维有助于突破瓶颈。

但由于上下文中存在所有这些内容，模型似乎真的开始呈现出一种放弃的趋势。这就是我想表达的核心观点：当你在进行长时间的优化会话时，模型基本上会失去继续尝试的动力。如果你考虑到这个特定情况并移除那些关于“已达到限制”的消息，模型自然会去尝试其他事情。这就是长上下文的一个问题，而遗忘机制有助于解决这一问题。

从更量化的角度来看，我们发现随着会话变长，模型每轮使用的思维令牌（thinking tokens）越来越少。相应地，模型编辑的行数也开始迅速缩减。起初模型可能试图修改100行代码，但经过30到40轮后，它只尝试编辑五六行。更令人震惊的是，这些修改中有很多仅仅是数字的变化。

模型开始调整超参数等细微之处，而不是尝试更大的创意构想。对于算法任务而言，最大的提升显然来自不同的算法或对其的轻微修改，而不是调整数字。虽然微调数字能通过提高几个百分点来优化分数，但幅度有限。因此，模型表现出一种行为模式：起初非常激进，最后则变得极其保守。

此外，由于初期有很大的提升空间（headroom），无论做什么都能显著提高分数。但随着优化后期这种空间的耗尽，大多数尝试都会失败。我们在训练思维链模型时也看到了类似现象，比如“我失败了太多次”、“实现这个想法风险很大”。这并不奇怪。

我不理解所谓的“风险”，实施一个想法有什么风险呢？你并没有在做任何危险的事情，这很荒谬。但在移除这些上下文并“遗忘”它们后，模型重新开始思考，再次对优化变得激进。虽然它偶尔会收缩，但在整个优化过程中我们需要多次执行遗忘操作。

查看论文第一部分可以明显看出，曲线在遗忘前趋于平缓，而在遗忘后迅速攀升。这为“遗忘”为何是一个极好的技巧提供了有力的实证证据。

对方回应说这是一个非常精彩的解释，他记下了很多想法。特别是关于智能体循环中每轮思维令牌减少这一实证观察非常有趣，这让人联想到全局与局部最优解的问题。他对上下文压缩很感兴趣，并询问如果用总结步骤代替遗忘会怎样？

我对此的直觉是：当上下文中有更多可用信息时，模型往往会遵循旧的轨迹。如果模型在上下文中已经见过算法ABC，它就会倾向于沿着这些方向继续。因此我推荐另一项名为“Fork and Flush”的并发工作，它提出了“理想基线锚定（ideal idea basing）”的概念。

该理论指出，当上下文存在很长时间时，由编码代理生成的许多代码在某种意义上是相似的，不会跳转到另一个想法基线。当所有代码或想法都集中在同一个基线上时，你只能获得非常微小的改进。这与我们关于思维令牌和代码行数变化的分析是互补的。

回到你的问题，当你进行压缩时，你仍然保留了很多信息，这可能无助于探索。我们之所以认为只保留最佳候选者有效，是因为：一方面，即使模型访问了所有其他候选者和上下文，编码代理仍然卡在性能平台上。这说明那些东西可能没那么重要。

另一方面，最佳候选者实际上包含了之前所有迭代中的大量有用信息。正如我们所说，最佳候选者通常不是来自代理的第一次生成，而是经过多次迭代、相互构建的结果。它可能结合了第11轮和第23轮的创意，因此包含了大量关于之前的有用信息。

人们常说我们移除一切太激进了，但实际上并非如此。最佳候选者实际上包含了很多信息，所以我们并没有失去你以为会丢失的那部分东西。

“最佳候选者，它在某种程度上捕捉了历史？” “是的，这也是思考这个问题的一个很好的方式。没错。”

“我想这也真的启发了我关于条件概率的思考，比如如果这只是基本的概率，即给定A和B时Y的概率。” “完全正确。所以，最佳候选者实际上是基于之前所有信息 conditioned 的，对吧？因此，它不是一个单一的候选项。”

“然后关于这些进化树有一个非常有趣的事情。因为如果我们有很多并行子代理，它们仍然像进化一样。自动研究的每一轮循环都可以抽象为一棵进化树。但关键在于，给语言模型两个想法的子集来提出新想法时，如果这两个想法是A和B与A和C相比，你可能会得到不同的潜在新想法。”

“是的。这确实与我们正在进行的团队设置有关。当我们进行团队协作时，我们实际上看到了很多案例是A加C的情况。因为产生代码A的代理目前的得分低于产生代码C的代理。所以，该代理会查看C，找到想法C，然后尝试实现它，从而得到A加C。因此，我们可能还需要做一些分析来看看这在哪里有帮助，但在经验上，团队协作确实非常棒。”

“我认为遗忘之所以在团队中效果很好的原因是：如果你仔细想想，这两种方式……基本上，团队协作让你爬坡更快，而遗忘让你不至于陷入停滞。如果你有一种能爬得更快且不陷入停滞的方法，那你就拥有了完美的自动研究硬度。”

“是的。这非常有趣。我还在思考LLM方法中的多样性问题，我一直很好奇向量嵌入是否能在其中发挥作用。比如在这个特定案例中，你可以基于两个处于异常聚类中的点来进行条件设定，让LLM在这种抽象空间中继续思考这些其他想法。这会在多大程度上影响它产生的想法类型？”

“是的，这确实非常有趣。我觉得我们未来要追求的一个方向是……目前我们将代码代理作为优化器，所以一切都会在这个代码代理中发生。我们框架的方式是希望分离出对代码代理的元控制，以便确切知道它在哪里生成了候选项，以及哪里可以继续或恢复操作。但我们还没有分离‘形成想法’和‘执行该想法’这两个概念。”

“如果我们在框架层面拥有这种控制，即框架实际上知道这个代码代理已经形成了想法ABC，那么我们就可以实施你的建议，对这些想法做更多事情。因为我们在框架本身中拥有这些想法的抽象表示，而目前一切都在代码代理的上下文中。这听起来是一个非常好的思考方向。”

“是的，如果我能把这与之前讨论的‘优化任何事物’以及提示词与代码优化的区别联系起来。我认为形成想法和执行它们是截然不同的，这对于代码来说非常直观，但对于提示词可能不那么明显。比如可能会说：‘嘿，我有一个提高这个提示词的高级想法，但我尝试了这些方法并没有特别接近目标，不过我认为提示词的某些措辞仍然朝着这个方向发展。’这说得通吗？”

“是的，如果你仔细想想，编码或另一个代理所做的每一个动作都对应一个想法。‘想法’这个词太抽象了。也许一种思考方式是，直接行动之前的思维链就是那个想法。那是语言模型想要做的事情，是它的思维过程，也就是抽象的想法。”

“所以我会说，即使是对于提示词优化，语言模型也会形成想法。这个想法可能是这样的：基于某些数据或我们看到的特定示例，我想以某种方式修改这个提示词。所以我认为它存在于所有问题中。只是我们还没有找到一种很好的方式来表示这一点，以便我们可以直接使用‘想法’这个术语。”

“是的。尚音关于技能和发现需要遗忘的这些精彩观点真是太棒了，讨论这项工作非常令人兴奋。我有一个问题想作为播客的锚点：除了你目前的工作外，作为一名在AI领域工作的人，哪些AI方向最让你兴奋？”

“嗯。让我最兴奋的肯定是基于一个我深信不疑的事实：前沿模型现在非常聪明，而人们并没有充分利用这些模型的极限能力。所以我感兴趣的方向是如何围绕这些模型构建系统以最好地利用它们。这也是我所有研究集中的方向，我认为这是一个非常值得思考的好方向。”

“是的，‘被误用的天才’。没错。我想说的就是这个。（笑声）” “这确实是一个很有趣的思考角度，即模型已经具备了它们所需的能力，接下来的关键在于工程实现。”

“是的。如果你仔细想想，即使是这项关于遗忘的工作也是如此。如果模型能力不足，无论你怎么尝试，它仍然无法产生更好的候选项。但既然模型足够聪明，问题在于那种记住一切的记忆机制反而阻碍了模型做出特定的进步。这就是为什么我们需要实施遗忘的概念。”

就像它必须得……呃，我们必须构建更好的自动研究能力。>> 是的，太棒了。没错，我认为这就是点睛之笔，也是结束本期节目的绝佳[笑声]观点。盛恩，非常感谢你加入我们。能和你深入探讨这一切真是太棒了，再次感谢。>> 是的，谢谢。非常感谢你。

[音乐]