Context Engineering: What It Is and Why It Matters
23:39 Share

本播客由谷歌支持。大家好，我是大卫，谷歌 Gemini 的产品负责人之一。如果你有梦想并能描述它，VO3 和 Gemini 可以帮你把它变成视频。现在有了令人难以置信的音效、背景噪音，甚至对话。使用 Google AI Pro 计划试用，或使用 Ultra 计划获得最高访问权限。访问 Gemini.Google 注册并向我们展示你的作品。

今天的 AI Daily Brief 的主题是：什么是上下文工程，以及它为什么重要？在此之前，新闻头条中，Anthropic 在合理使用方面取得了重大胜利。AI Daily Brief 是一款关于 AI 最重要新闻和讨论的每日播客和视频。大家好，朋友们。今天快速宣布一下。首先感谢我们今天的赞助商：Blitzy、Plum、Vanta 和 Google Gemini。当然，如果您想获得节目的无广告版本，请访问 patreon.com/AIDailyBrief。

公告与之前一段时间相同。我们正处于秋季赞助商讨论的深入阶段，如果您有兴趣，请通过 [email protected] 联系我。我们很快还将有一些关于超级智能的新闻，包括一些招聘信息，敬请关注。但今天有很多事情要谈论，包括一个你将听到越来越多的新术语。因此，让我们开始吧。

欢迎回到 AI Daily Brief 头条新闻版块，所有您需要的每日 AI 新闻，大约五分钟即可看完。我们今天首先报道 Anthropic 在其版权案中取得的相当大的胜利，一位联邦法官裁定 AI 训练属于合理使用。

现在，Anthropic 是众多 AI 实验室之一，这些实验室正在与作者和出版商就其使用受版权保护的作品和训练数据进行斗争。每个实验室都在有效地使用相同的论点，即 AI 训练类似于阅读，因此根据合理使用条款不构成版权侵犯。一位联邦法官现在已经接受了这一论点，在该案中给了 Anthropic 一场早期的胜利。

迈阿密大学法学院法律写作教授克里斯蒂娜·弗罗哈奇解释说，她说法院对 AI 模型得出了相同的结论。

在作出裁决时，法官评论说，引用，“他指出版权法，引用，”

现在，所有这些话都说了，这只是 Anthropic 的部分胜利。该命令仅根据这极其狭隘的法律条款作出决定，案件中的进一步争议将提交单独审判。该审判将处理 Anthropic 所称的“中心图书馆”，这是一个包含世界上所有书籍的语料库，用于创建训练数据集。除了扫描实体书外，原告还声称 Anthropic 盗用了 700 万份数字副本以创建此存储库。

在即将发生的事情的序幕中，法官写道，根据版权法，故意侵权最高可处以每件作品 150,000 美元的罚款。如果法院裁定 Anthropic 在盗版书籍时侵犯了数百万次版权，那么罚款很容易使这家初创公司破产。

法官指出，引用，“Anthropic 后来购买了它之前从互联网上盗取的一本书的事实并不能免除其盗窃责任，但它可能会影响法定损害赔偿的程度。”

需要注意的一个有趣的点是，合理使用裁决是基于 Anthropic 的 AI 输出具有变革性。也就是说，AI 模型无法直接复制受版权保护的作品，而是经过训练可以从其训练数据中创造出新的东西。事实上，法官将 Claude 的输出称为极其具有变革性，并指出，“……就像任何渴望成为作家的读者一样，Anthropic 的大型语言模型并非为了超越和复制或取代它们而接受训练，而是为了转弯并创造出不同的东西。”

因此，最终，Anthropic 还远未摆脱困境，法律也远未确定，但这仍然是 AI 版权问题的具有里程碑意义的裁决。重要的是，这只是一个联邦法院的裁决，因此它对其他案件不具有约束力，仍然可以上诉。但是，它可以用来劝说其他法官暂时遵循这种法律解释。显然，这是一个并且仍然是一个有争议的领域，我完全预料到在我们最终真正知道如何处理它之前，我们将需要在最高法院面前出庭。

接下来，让我们暂时继续关注法律方面，Sam Altman 正在 X 上与 IO 的诉讼作斗争。围绕 Johnny Ives 的 AI 设备初创公司和同名谷歌分公司展开的法律斗争开始变得有点激烈。诉讼文件正在流传，但 Sam Altman 决定直接讲述他的版本。昨天，他发布了，“‘Jason Rugolo 一直希望我们投资或收购他的公司 IO，I-Y-O，并且在他的努力中非常坚持。我们拒绝了，并且一路都很明确。’

现在他正在就名称问题起诉 OpenAI。这很愚蠢、令人失望且错误。我花了很多时间与 Jason 谈论他反复的请求，因为我喜欢帮助创始人。在诉讼几天前，他再次要求我们收购他的公司，即使在我们之前试图拒绝之后。

努力筹集资金或被收购，并尽一切努力使你的公司成功，这很酷。当你得不到你想要的东西时，转向诉讼就不酷了。这为试图帮助生态系统树立了一个糟糕的先例。尽管如此，我还是祝愿 Jason 和他的团队在构建优秀产品方面一切顺利。世界肯定需要更多这样的产品，而不是诉讼。

与此同时，OpenAI 的法律文件讲述了基本相同的故事。IO（这个新的 OpenAI 部门）的技术人员出于职业礼貌与 Rugolo 会面，对一个损坏的演示印象不深，然后继续构建他们所看到的东西以外的东西。Rugolo 在 Twitter 上的回应中，基本上说这是关于名称的问题。在一篇文章中，他写道，“……他们可以选择 675 个其他两个字母的名称，而不是我们的。”

基本上，如果你想了解社区对此的看法，我认为一方面，在 Sam 分享这些电子邮件后，OpenAI 方面的故事，即他们并没有那么印象深刻，看起来非常有共鸣，或者至少从他们内部讨论的内容来看是真实的。但与此同时，人们也觉得，嘿，你有没有必要选择一个这么接近的名称？最终，我的猜测是，这并不值得麻烦，OpenAI 只是更改了名称。但我怎么会知道呢？

关于 OpenAI 的另一件有趣的事情是，该公司悄悄地为 ChatGPT 设计了一套生产力套件，这可能会使他们与微软等大型支持者直接竞争。这些功能将允许用户协同处理文档并相互沟通，类似于 Microsoft Office 的功能，或者甚至更直接地说，是 Google Workspace。该信息报告称，尚未就推出该功能做出决定，但发布可能会进一步加剧 OpenAI 与其支持者微软之间的关系。

然而，在某些方面，这只是 Canvas 功能的自然延伸，该功能允许用户在 ChatGPT 中打开一个单独的文档窗口，从而使助手在工作环境中更有用。它还将允许 OpenAI 竞争成为一个全能应用程序。

巧合的是，我们本周早些时候收到了 XAI 也正在开发生产力套件的消息。那么这是一个重大的竞争变化吗？还是所有这些产品都趋向于相同的方向，并且将具有一些相似的功能？我倾向于认为是后者，而不是这两家“欢喜冤家”之间任何类型的重大新竞争。

最后，在我们进入主要内容之前，有一些产品更新。首先，Airtable 已经采取重大举措，重新推出作为 AI 原生应用程序。首席执行官 Howie Liu 发布了，我们不是仅仅向我们现有的平台添加更多 AI 功能，而是将其视为公司重新创立的时刻。我们从一张白纸开始，想象在代理时代构建应用程序的理想形式因素。

这个无代码数据库平台现在也是一个功能齐全的氛围编码应用程序。用户现在可以使用自然语言提示应用程序进入存在，同时将其集成到 Airtable 的生产就绪组件中。Lou 给出了创建 VC 交易跟踪器（进行自动公司研究）或营销活动管理器（监控所有相关竞争对手）的示例。

AI 集成还意味着您可以轻松地跨数据库运行查询。例如，您可以让助手处理数千张支持票，以快速找到常见的问题点。重建还添加了内置的代理功能，以帮助您管理大型数据工作流程。Howey 写道，当创建和不断发展应用程序的成本降至零时，一切都会改变。

公司将构建他们所需的东西，而不是满足于僵化的现成软件。新的默认设置是 AI 生成的应用程序加上全天候工作的内置 AI 代理。在这个新时代需要的是一种新的软件形式因素和范例，即 AI 原生应用程序平台。这就是新的 Airtable。而今天推出的仅仅是一个开始。我们很高兴在接下来的几个月里发布一系列新的 AI 驱动的功能，抢先看，生成任何可视化效果，利用 MCP 的代理，代理来源的数据集等等。

另一家变得完全代理化的公司是 Eleven Labs，他们推出了一款名为 Eleven AI 的新型语音 AI 助手。

其宣传重点是，这款语音助手具有完整的 MCP 集成，因此它可以从包括 Perplexity、Slack、Gmail 和 Google 日历在内的服务中提取数据。您甚至可以连接到您自己的 MCP 服务器，因此理论上助手可以访问您希望它访问的任何内容。从功能上讲，这与 Anthropic 上个月初与 Voice Mode 一起发布的语音助手非常相似。它被设计为访问各种 AI 功能的语音界面。广告也类似。

Anthropic 将其产品宣传为能够帮助年轻专业人士度过他们的早晨，而 Eleven Labs 的广告则讲述了一个类似的故事，但其中一位年轻男子在与老板进行网络会议前五分钟才起床。助手帮助他通过电子邮件推迟会议，订购油腻的早餐，并记住老板的宠物以便进行闲聊。该版本还附带了期待已久的移动应用程序，因此您可以在旅途中与 Eleven Labs 的助手聊天。

现在，我不确定这些助手的定位。我对这些通用的消费者助手比大多数人更持怀疑态度，但我可能大错特错。但是，再一次，如果 OpenAI 生产力套件的一些主题是所有这些平台融合成一组共同的功能，那么这又是另一个例子。

无论如何，这就是今天的 AI Daily Brief 头条新闻版的全部内容。接下来是主要内容。本集由 Blitzy 提供赞助。现在，我与许多渴望实施尖端 AI 的技术和业务领导者进行了交谈。但他们的优秀工程师并没有构建竞争优势，而是陷入了现代化古老的代码库或更新框架的困境，只是为了维持运营。这些项目，例如将 Java 17 迁移到 Java 21，通常意味着要组建一个团队一年或更长时间。

当然，副驾驶可以提供帮助，但我们都知道它们很快就会遇到上下文限制，尤其是在大型遗留系统上。Blitzy 改变了这种局面。Blitzy 的自主平台处理繁重的工作，处理数百万行代码并自动进行 80% 的必要更改，而不是工程师完成 80% 的工作。一家主要的金融公司使用 Blitzy 在短短三个半月内对 2000 万行 Java 代码库进行了现代化改造，减少了 30,000 个工程小时，并加快了其整个路线图。

请将主题行中包含“modernize”的电子邮件发送至 [email protected]，以获得优先加入。在竞争对手之前访问 blitzy.com。今天的节目由 Plum 提供赞助。你投入了大量时间，测试提示，改进 JSON，以及在画布上整理节点。现在，是时候为你的工作获得报酬了。

Plum 是唯一一个专为希望将其 AI 工作流程产品化的技术创作者设计的平台。使用 Plum，您可以构建、共享和获利您的流程，而无需泄露您的提示或配置。当您准备好进行改进时，您可以一键向您的订阅者推送更新。

在 useplum.com 上启动您的第一个付费工作流程。这就是带有 B 的 plum，并开始扩展您的影响力。

问题在于，导航安全和合规性既费时又复杂。这可能需要数月的工作，并占用宝贵的时间和资源。Vanta 通过自动化 35 多个框架的合规性来简化和加快这一过程。它可以在几周而不是几个月内让您准备好接受审核，并为您节省高达 85% 的相关成本。事实上，最近的一份 IDC 白皮书发现，Vanta 客户每年获得 535,000 美元的收益，并且该平台在短短三个月内就能收回成本。

事实胜于雄辩。超过 10,000 家全球公司信任 Vanta。在有限的时间内，听众可以在 vanta.com/nlw 获得 1,000 美元的折扣。这是 vanta.com/nlw，可享受 1,000 美元的折扣。欢迎回到 AI Daily Brief。

今天我们要讨论一个您可能在这个节目中听到过一点的术语。也许您已经看到它开始更多地出现在 X 或文章中。我们将讨论它的含义，为什么它现在越来越频繁地出现，以及它对整个行业的重要性。首先，让我们来看一下 Shopify 首席执行官 Toby Lutke 最近的一条推文。上周他写道，“我真的很喜欢上下文工程这个术语，而不是提示工程。它描述了”

它更好地描述了核心技能。为任务提供所有上下文，以便大型语言模型能够合理地解决问题的艺术。现在，许多人都加入了这场讨论以表示同意。McKay Wrigley 写道，“完全同意。如今，你从像‘如果你做对了，我将付给你 100 美元’这样的愚蠢技巧中获得的绩效奖金要少得多，这应该是这样。”

所有 alpha 都很好地汇集了上下文，以减少模型的战争迷雾。它正在融合成类似人类的信息需求。Nick Dobo 说，很快，上下文工程将包括提供工具、代理环境和防护措施，以便大型语言模型能够自行找到上下文。因此，基本上，我们这里有一种不同的思考方式，即如何充分利用大型语言模型。

自从 ChatGPT 出现以来，就出现了一个新的提示工程领域，它催生了无数的课程和在线教程，以及许多技巧、提示和窍门，说明如何以正确的方式提问才能从大型语言模型中获得所需的东西。现在，在此过程中，提示工程变得越来越，让我们说，分散，如果不是在这个阶段，那么它变得不那么重要了。我的意思是

随着模型变得越来越智能，六个月或十二个月前的技巧就停止工作了。在许多情况下，还存在与 UI 相关的或与界面相关的提示抽象，其中一些提示工程正在被工具本身所取代。举个例子，当我为最近的一集设计封面时，

我对 ideogram 的提示是：为《独行企业家的独角兽之旅》制作一个有趣的复古未来主义封面，1950 年代中期现代风格。然而，ideogram 将其变成了一个复古未来主义的书籍封面，风格为 1950 年代中期现代设计，描绘了一个意志坚定的穿着考究的独行企业家骑着一匹雄伟发光的白色独角兽穿过旋转的星云。这位独行企业家穿着剪裁得体的灰色西装，带着自信的笑容，并用未来主义的操纵杆驾驶独角兽，而独角兽的角则发出光束，照亮了前方的道路。

背景由风格化的几何行星和恒星组成，以青绿色、橙色和黄色的鲜艳调色板呈现，标题《独行企业家的独角兽之旅》则以经典的镀铬字体醒目地显示。因此，你会看到这种事情在不同的工具中发生得越来越多，这些工具本身试图抓住你所要求的本质，并提出比你更好的提示。

上下文是不同的东西，它指的是这些大型语言模型价值链的另一部分。上下文是你提供给大型语言模型的所有信息，这些信息有助于它更准确地回答问题。例如，如果您使用的是 ChatGPT 的 O3 或 O3 Pro（特别针对更好地处理上下文进行了优化），当您向提示添加大量文件时，

这就是你提供给它的上下文。然后，上下文工程就变成了，你是否为大型语言模型提供了它需要的信息，以便它能够提供你正在寻找的输出？事实证明，这不仅仅是关于与它共享哪些文档。它也是一项关于如何在更复杂的系统中传递上下文的工程任务。你可能还记得我们最近谈到了 Cognition（创建 Devin 的公司）的一篇文章，名为《不要构建多代理》。

这篇文章完全围绕上下文和上下文工程展开。基本上，对于那些不记得的人来说，这篇文章中的论点是，多代理工作流程（其中一个代理分解任务并将其交给多个不同的子代理，然后另一个代理在另一端组合结果）注定会相当脆弱，因为上下文从代理到子代理，然后从子代理到代理的传输可能非常困难。

他举的例子是：假设你的任务是构建一个 Flappy Bird 克隆。这被分解为子任务 1：构建一个带有绿色管道和碰撞盒的移动游戏背景。子任务 2：构建一只可以上下移动的小鸟。事实证明，子代理 1 意外地误解了你的子任务，并开始构建一个看起来像超级马里奥兄弟的背景。子代理 2 为你构建了一只小鸟，但它看起来不像游戏资产，而且它的移动方式与 Flappy Bird 中的小鸟完全不同。

现在，最终代理的任务是组合这两个误解。现在他转向了一些可能的解决方案，但仍然发现它们不可靠，最终得出了构建单线程线性代理的想法。

在 Cognition 模型中，代理分解任务并将其分解为子任务，而不是子代理。因此，同一个代理负责分解任务，然后执行子任务 1 和子任务 2，然后组合结果，其想法主要在于这比其他多代理系统更好地在不同任务之间传递上下文。在这里，上下文是连续的。

与此同时，他们认识到，随着非常大的任务开始拥有如此多的子部分以至于上下文窗口开始溢出，可能需要一种新的方法。他们共享的一种架构是并排上下文压缩大型语言模型的想法，该模型基本上在每个阶段都将迄今为止的对话和操作（即上下文）压缩成一组关键时刻和决策，而压缩后的上下文正是为下一个子任务的工作提供信息的内容。

现在，你是否同意这种策略并不重要。它旨在展示上下文工程如何开始成为 AI 中一些最重要问题的组成部分，这与如何构建实际高效的代理有关。如果你四处寻找大约五分钟，你会发现大量关于上下文工程的讨论。就在几天前，Lance Martin 在他们的博客上发表了一篇名为《代理的上下文工程》的文章。

Lance 写道，

就像 RAM 一样，大型语言模型的上下文窗口具有有限的通信带宽来处理这些各种上下文来源。就像操作系统管理适合 CPU RAM 的内容一样，我们可以将上下文工程视为打包和管理大型语言模型执行任务所需的上下文。因此，再一次，这与我们在 Cognition 博客中看到的相同问题相一致，即必须设计能够获得正确上下文但不会随意转储所有内容的系统。

Lance 指出的是这个领域的日益重要性。他引用了 Cognition 的话，后者写道，“……上下文工程实际上是构建 AI 代理的工程师的头号工作”，以及 Anthropic 的另一句话，“……代理通常会参与持续数百轮的对话，需要仔细的上下文管理策略。”

现在，这篇博客的第二部分是关于我们可以管理该上下文以及该类上下文管理的新策略，这有点技术性，超出了本节目的范围。但我将在节目说明中包含这一点，以便您可以自己查看。Lance 谈到了管理上下文，即管理代理在每次轮次中看到的标记，持久化上下文，

涉及系统来存储、保存和检索上下文，以及隔离上下文，涉及跨代理或环境划分上下文的方法。Lance 指出，我们仍然处于形成构建代理的一般原则的早期阶段，这就是为什么在这个讨论中会出现如此爆炸式增长的原因。另一篇在同一天发表的文章来自 Langchain 博客，名为《上下文工程的兴起》。

这篇文章写道，上下文工程是构建动态系统以提供正确格式的正确信息和工具，以便大型语言模型能够合理地完成任务。大多数情况下，当代理无法可靠地执行时，根本原因是尚未向模型传达适当的上下文、指令和工具。大型语言模型应用程序正在从单个提示发展到更复杂的动态代理系统。因此，上下文工程正在成为 AI 工程师可以培养的最重要的技能。

同样，这篇文章确实重申了，当代理系统出错并且大型语言模型倾向于出错时，要么是因为它们不够好，要么是因为它没有适当的上下文。更重要的是，作者认为，随着模型变得更好，它往往更多的是第二个原因。作者总结道，上下文工程并不是一个新想法。代理构建者在过去一两年里一直在这样做。这是一个新术语，恰当地描述了一项日益重要的技能。

因此，我认为实际上有两个不同的上下文工程领域值得我们牢记，也值得你和我去探索。第一个是在 AI 工程师和实际代理构建的背景下的上下文工程。

换句话说，对于那些构建代理系统的人来说，那些正在考虑如何使代理更高效并在更高复杂性和更高阶的任务上工作软件工程师来说，这些上下文工程问题是关于系统设计的。它们是关于与单代理系统一起工作并使其更好地工作的上下文压缩大型语言模型之类的东西。

在这个领域中正在发生着整个重要的论述，这将影响甚至非编码人员和非技术人员最终交互的代理的形状。然而，我的强烈猜测是，我们很可能会开始看到上下文工程也成为消费者和普通大型语言模型用户的术语。就像我们越来越多地教自己或试图教自己一样

如何提示大型语言模型以充分利用它们，我的猜测是，在用户环境中，上下文工程也将成为一个更重要的领域和学科。为任何给定模型提供多少信息是正确的？哪些模型更擅长处理不同类型的信息？

事实上，我们已经开始看到这一点的一个领域是 O3 Pro 的发布。你会记得，我认为对 O3 Pro 的最佳总结来自潜在空间的文章，名为《上帝渴望上下文》，它基本上认为 O3 和 O3 Pro 之间的最大区别在于 O3 Pro 更擅长处理大量上下文。

当这篇文章的作者向它提供大量关于他们公司的信息时，包括过去的会议记录和录音音频，它为他们提供了一个比单独使用 O3 更好的策略。因此，从用户的角度来看，我们有上下文工程，一方面是模型选择，以及哪个模型更擅长处理上下文，另一方面是提供哪种类型的上下文。

我认为这是一个极其动态的领域。我认为它很可能与提示工程一样重要，甚至比提示工程更重要，这关系到我们如何使用这些工具。我很高兴在它成为对话中更大一部分时分享更多关于这方面的信息。不过，就目前而言，这就是我们今天关于上下文工程的小小入门介绍。我希望这对您有所帮助。一如既往地感谢大家的收听或观看。直到下次，再见。