智能体有两样东西：模型和框架。对吧？所以，围绕模型的种种事物将其转化为一个智能体。这被称为“模型驱动”方法。在这种方法中，我们将大量的编排工作委托给模型本身。随着这些模型变得越来越好——而且是以加速的速度变好，智能体工作流、模型驱动的方法也随之扩展。对吧？你不需要做任何改变。使用更新的模型，一切都会变得更好。但这并不是“YOLO”（盲目行事），对吧？周围也有确定性的护栏。这就是我们开始定义什么是框架的地方。

如果你去年看过 Strands 然后就没再回来，我会说再看看它吧。事情已经发生了相当大的变化。欢迎来到 AWS Developers 播客。今天，我们要谈谈 Strands 及其演变过程。Strands 是 AWS 于 2025 年 5 月作为开源项目发布的智能体框架。我们将讨论过去一个月中发生的所有变化以及大量的创新。为此，我今天有两位特邀嘉宾。我们有摩根·威利斯（Morgan Willis）。摩根，你以前在不同的职位上已经上过这个节目了，当时你在培训和认证团队。现在，你在开发者关系部门工作。所以，摩根，欢迎做客节目。

谢谢。是的，我很久没来了，但自那以后，我转到了 DevRel（开发者关系），并与 Strands 团队及智能体 AI 紧密合作。很高兴能在这里和大家多聊聊最近的情况。太棒了。还有艾伦（Aaron），你去年其实也上过这个节目，当时发布了 Strands 智能体。我们将与你探讨其演变及未来动向，我对此非常兴奋。摩根，你花了几天时间帮助开发者实际采用 Strands 智能体或现在的 Strands 框架。当你看到有人拿起 Strands 时，你看到的最大的“顿悟时刻”是什么？

嗯，我认为这是从认为需要定义工作流中的每一个步骤以实现结果，转变为给予智能体足够的上下文和工具，让它自行解决问题的思维转变。我认为随着人们使用像 Cloud Code、Codex 或 Kiro 这样的智能体，大家开始理解它是通过迭代来解决问题的。但再深入一层，使用像 Strands 这样的框架构建自己的智能体时，你会真正理解智能体的工作原理以及如何为自己的工作流构建智能体，而无需经过某种繁琐的逐步定义。

艾伦，你上次出现在节目中时 Strands 刚刚开源。所以从那以后，你们发布了很多东西。是的，我们构建了很多功能。如果你必须用一句话来描述 Strands 今天的位置，它现在在哪里？一句话。我们将在节目中展开阐述。嗯，我会说今天的 Strands 是一个产品组合，对吧？我们现在提供的开源产品已经从简单的智能体循环 SDK 演变为帮助安全地容纳和运行智能体的工具、最先进的框架式智能体，以及产品组合中的许多其他内容。令人兴奋。好的。这就是一句话。差不多吧。很好。现在，让我们深入探讨 Strands 智能体。你能谈谈自去年以来 Strands 的演变吗？正如你指出的，它带来了以模型为中心的概念，而不是其他更侧重于工作流的智能体框架。这就是 Strands 的基础，这帮助我们创造了一些非常棒的产品。让我们谈谈这一点以及过去一年发生的事情。

我们最初是从内部需求开始的，正如我之前在上一期节目中提到的那样，Strands 源于我们的内部需求。我们最初是与 Q Developer、后来与一些 Kero 产品、Amazon Q 以及 AWS 中许多其他专注于 AI 和基于 AI 的内部产品一起构建它，用于许多内部事务，如 DevOps 和安全。去年我们决定将其开源，这是基于我们所取得的巨大成功以及倾听客户的反馈，他们面临着同样的问题：许多难以定义的工作流图，例如智能体工作流、AI 工作流非常脆弱，未能像我们希望的那样扩展。因此，我们提出了模型驱动的方法，将大量的编排任务委托给模型本身，对吧？最先进的模型，比如 Claude、GPT、Gemini、Nova 等等。我们将编排任务委托给这些模型，并且从此一直坚持这种做法。我认为我们也看到行业也是如此。随着这些模型以加速的速度变得越来越好，智能体工作流、模型驱动的方法也随之扩展，对吧？你不需要做任何改变。使用更新的模型，一切都会变得更好。所以我们真的采用了这种方法并一路发展至今，我们看到这已成为一种标准。

是的。我觉得这在某种程度上已经成为“入场券”了，对吧？我认为人们理解这种模型和方法，但我看到 Strands 团队以及许多其他工作正在探索的地方是：你如何给予模型自由和自主权，使其能够在框架内朝着目标工作，同时高效且安全地做到这一点？我觉得有很多关于效率方面的工作以及定义护栏、控制机制方面的内容。随着 Strands 世界中的框架和产品端变得更加成熟，我看到客户能够更多地利用这些杠杆来调整他们的智能体运行方式并对其进行控制。

我认为也许我们是有偏见的，因为我们与许多高级客户互动，但我观察到的一个趋势是第三方用户、Kira 用户等都在说：“好吧，过去我们在智能体周围设置了太多的护栏，因为智能体会做一些我们不期望的事情。现在人们说：‘好吧，既然 Opus 这么好，你就不需要在 Edit 或其他模型、前沿模型周围设置那么多护栏了。’所以，基本上你的意思是说，对于那些采取这种模型驱动路径的人来说，他们不需要改变围绕模型的整个框架以提高效率。”

我认为我们自己和客户都看到了这一点。我们当时正在工程化许多状态机，我想说的是：如果发生这种情况，那么……

知道，调用这个子代理，或者如果发生这种情况，就调用那个子代理。是的，随着模型的进步，我们基本上让模型自己决定这些事项。但这并不是毫无约束的（YOLO），周围也有确定性的安全护栏，这正是我们开始区分“Harness”与单纯“代理”定义的地方。此外，围绕模型调用和这种智能体循环（agentic loop）还有许多机制，使我们能够安全地执行操作。

团队近期与亚马逊的自动推理小组合作，进行了一项非常有趣的工作：将这种智能体循环与神经符号人工智能（Neural Symbolic AI）相结合。也就是说，在代理的每一个周期中，它都会根据某种策略（例如Dogwood政策）来验证自己的行为。Dogwood是我们发布的一个开源时序策略引擎（temporal policy engine）。代理与该引擎配对，以便当代理说“嘿，我想给用户退款100美元”时（假设这是一个客服代理），我们会根据策略进行验证。

例如，该用户在过去24小时内是否下过单？如果是视频游戏退款，他们玩游戏的时间是否少于2小时？这类检查还包括信任评分是否足够高。所有这些验证都会针对策略运行。如果通过，操作继续；如果不通过且存在不允许的理由，代理（模型）会被告知原因。随后它会向用户展示该信息或寻找替代方案，例如升级到人工客服工单以供审核。因此，这不仅仅是黄色预警（yellow），你还可以为代理添加这些安全护栏，这也正是Harness定义的体现。

好的，我觉得我们稍微跳得太远了，进展也太快了，但让我们继续吧。稍后我们会再讨论这一点，但现在我们回到Strands的演变过程……是的，正如你之前指出的那样，确实存在一个围绕代理的循环，我们提供工具。因为去年我们通过MCP（模型上下文协议）等引入了被称为“Strands”的东西，以及使用Strands构建自定义工具的能力。那么自那时以来模型是如何演变的呢？也许Morgan，如果你想分享一下你的观点……

我认为这是我在X平台（以前的Tech Twitter）上深入关注的内容，感觉每两天就有新的趋势出现。这反映了该领域发展速度之快，以及我们如何学习构建、管理和运行代理的最佳方式。起初是提示工程（prompt engineering），然后是AI工程，接着出现了循环工程、图工程、DevOps工程、工具工程等——似乎万事皆需“工程学”。

正是Harness工程。是的，完全正确。随着演变的继续，我们采用了新的方法。我想你们也看到了Strands团队在产品及其提供的内容方面的这种演变。其中之一是从仅仅拥有一个框架SDK（你创建一个简单的循环，给它工具）转变为现在称之为Harness SDK。它为你提供从头构建Harness所需的所有不同组件。

最近，Strands团队发布了预优化的“Strands Harness”，你可以开箱即用地在线使用。所以我认为最初的Strands宣传点是：你可以在几行代码中获得一个代理，提供一个循环，你可以添加工具。而现在我们说的是，在几行代码中你就可以获得一个拥有完整内置Harness的代理，包括记忆和上下文管理。Aaron，请帮帮我在这里定义一下这具体是什么……

正如Morgan提到的那样，12到18个月前我们拥有代理循环时，这对每个人来说都很有趣。现在模型可以调用工具并执行操作了。18个月前确实不算太久，在宏观视野中更是如此。现在这已成为基本配置（table stakes）。每个构建代理的人都会期望这一点，如果没有这些功能，它就不是最先进的代理。

我们自己也在经历这一切，例如构建Amazon Q、Cairo等产品，以及一些AWS前沿代理和我们在Agent Core方面的工作。Strands团队与所有这些小组紧密合作。我们也看到了与客户相同的问题出现：我们需要保持技术领先，需要比仅仅代理循环更多的东西。因此，我们推出了Strands Harness，其中包含许多预构建功能（如Morgan所述），还内置了一套可能对您的代理有用的默认工具，例如文件操作、网络搜索工具以及以编程方式调用工具的能力。

还有一些高级的上下文管理技术，我们不仅仅是将内容追加到有限的上下文窗口中（如果太大，模型可能会偏离轨道）。它是即时组装上下文的。因此，你可以让多个代理甚至一个人向这种上下文日志写入内容，它会重新组装并仅提取重要部分以使代理表现良好。拥有许多类似的功能。

是的，我们推出它时秉持的理念与推出SDK时相同：Harness是建立在SDK构建块之上的。你在Harness中发现的一切都在SDK中，它只是我们对这些构建块的一种有观点的配置（opinionated configuration），并且我们已经进行了基准测试。我们发布了结果，你可以在strandsagents.com博客上找到它们。

好的……是的，跟进一下关于工具选择的问题：为什么是这些工具（如文件编辑、Shell、网络搜索）？我们发现通用代理，即那些可以编写代码、访问文件、从互联网获取信息的代理所使用的工具，往往足以满足各种用例。因此，我很想听听Aaron的想法：为什么具体包括这些工具？以及人们如何添加自己的自定义工具……

是的，大部分来自客户反馈，也再次来自我们自身的经验。即使你有一个代理（也许它不是编码代理），Strands是一个通用代理和Harness组合，适用于任何类型的代理。

包括编码代理在内，当存在这类用例时，对于支持代理而言，能够以受控、安全、私密且隔离的方式读取和写入文件仍然很有用。同样，能够像引用文件那样引用事物也很有价值。此外，存储记忆功能也很关键，这样当同一用户一个月后再次联系支持代理时，系统能够从历史记录中检索相关信息。通过程序化工具调用，例如将多个工具组合成脚本并执行，可以更高效地运行，从而减少令牌消耗和成本。这些功能非常通用，再次回到 Strands 的理念：所有代码均为开源且预配置完成，我们已经为您进行了基准测试。

然而，您可以自定义其中的所有内容。那里的每一样东西都可以启用、配置或禁用，您还可以添加自己的工具。例如，在某些情况下，客户支持代理可能需要将问题升级给人工处理。“好的。”那么我想现在是时候休息一下了。现在请定义一下什么是“Harness 工程”或什么是 Harness。我们一直在谈论 Harness，我还有后续问题要问大家。那么谁愿意给 Harness 下一个定义呢？

“我来试试。”我想网上有很多关于它的定义，当然每个人都有自己的看法。但我认为代理由两件事组成：模型和 Harness。“嗯。”“没错。”Harness 是围绕模型的组件，它将模型转化为代理。就像那个智能循环一样，它处理对模型的调用，处理模型请求的工具调用（例如在支持代理案例中的提交退款工具调用），以及我提到的上下文管理，即智能的即时上下文组装。它还处理钩子（hooks）等功能。

我提到过，在 Dogwood 中的一些自动推理内容旁进行配对验证检查，这就像是在每次模型调用和工具调用之间或当模型完成时注入的一个钩子。所以，它是围绕模型的所有这些不同部分以及一些额外的有用功能（如长期记忆）。代理能够存储关于用户及其已完成任务的信息。它可以将这些信息发送给人工操作员进行批准或审查。正如我提到的，Strands 是可配置的。

如果您更喜欢更自主的方式，甚至可以让代理自行完成这些操作，或者通过二次模型调用来充当裁判，在整合更改之前进行审查。这就是我对它的定义：代理等于模型加上 Harness。“好的。”“是的。”“那么，用一句话来概括吧。摩根，因为你已经列举了 Harness 的许多特性和能力，但我们试着用一句话来总结。”“我刚才已经给过一句简短的回答了，现在轮到摩根说了。”

“我认为摩根刚才那句就是艾伦刚刚所说内容的极简短版本：代理是模型加上 Harness。所以，任何不是模型的都属于 Harness。”因此我会说，Harness 是围绕在模型周围、将其转化为运行中代理的软件系统。这就是我一句话的定义。但如果进一步引申，我认为它正是所有允许模型与现实世界交互所需的东西 Harness 一直存在我们今年才开始使用“Harness”这个术语，但即使当时只有一个简单的带有工具调用的代理循环，所有的工具调用都属于 Harness。

“我认为这只是我们行业在制定词汇来定义那些我们已经在使用和做的事情。”“我觉得现在的 Harness 比12到18个月前先进得多，所以也许值得拥有自己的术语。确实，过去的一年里在这个定义中增加了很多内容。”“是的，而且我认为保持一定的模糊性是有帮助的。因为变化太快了，如果我们要具体定义哪些项目属于 Harness 而哪些不属于，我认为这对行业来说并不有利。因为事物变化得太频繁了。”

“所以我认为这是一个有意为之的模糊术语，它让我们能够谈论我们正在做的事情并使用共享词汇，而不必过于规定性。”“那么 Harness 的例子包括 Hero、Quake（你也提到了）、Flood Code，或者 Codex 和分析工具等。”“没错。我们最近发布了一篇关于某些结果的博文。随着 Harness 的发展，其中的内容越来越多，现在一个高性能的Harness已成为基本门槛（table stakes）。要想获得最先进的结果，今天就需要它。”

“我们之所以自己构建 Harness 的原因之一（当然也是为了帮助客户），就是封装来自亚马逊和 AWS 工程师的所有知识，并与世界分享这些经验教训。它还允许我们（如果您使用 Strands 框架构建自定义 Harness，而不是预构建的 Harness），或者能够定制如 Strands Harness 这样的东西。当我们将其专注于特定领域时，我们取得了很好的成果。”

“我们在发布的 Strands Harness 中展示了显著的令牌效率提升。它还允许您进行专业化定制，例如我们一直在物理 AI 领域进行大量实验，并将其作为机器人的智能 Harness。”“我们将为此制作一期特别节目来进一步探索。这很好。”好的，所以你提到了 Strands Harness。基本上，我们现在所知的 Strands 代理 SDK 现在被称为 Strands Harness SDK。在此基础上，我们有一个抽象层（你称之为 Strands Harness），它基本上以 YAML 文件的形式出现。

“关于 Harness，有两点：它具有流畅的界面（fluent face）。Strands 使用 Python 和 TypeScript，所以我们有两个编程接口。目前 Harness、SDK 等都提供了这两个接口。我们还推出了 Strands CLI，它与 Harness 同时发布，允许您快速创建和交互这些代理。所以目前的接口包括 Python、TypeScript 以及……”

Strands 中的代理配置功能可以定义为文件，也就是你提到的 Romain 所说的配置文件并加载。但基本上主要有两个编程接口：一个用于 Python，另一个用于 TypeScript，同时也支持命令行界面（CLI）。

是的，这里有一个值得强调的优点：你可以将这个库嵌入到你的应用程序中。只需一行代码，你就能获得一个包含所有预建且带有特定默认值的代理框架（Harness）。当然，你也可以在命令行中运行它。通过命令行运行本质上是一样的操作，只是接口不同而已。无论你是想仅使用命令行来原型化开发以了解其工作原理，还是希望将其嵌入到自定义应用程序中，都可以实现。这节省了你需要自行预先定义和配置几乎所有代理所需模块的时间，例如对话历史、会话管理、上下文处理以及基础工具等。

我认为，光是弄清楚该调整哪些构建模块和参数也是一项不小的任务。正如我提到的，现在的代理框架已经相当先进，拥有许多相互交织的功能，例如上下文管理。因此，将这些功能集中在一处，并由亚马逊和 AWS 投入大量资源进行优化，能够与世界分享这些最佳实践和学习成果（特别是来自服务数百万用户的代理经验），也是我们的目标之一。

能否详细谈谈 CLI？我的意思是，开发者为什么选择使用命令行界面而不是 Python 或 TypeScript 脚本呢？

CLI 在开发和入门阶段非常有用。我现在可以通过 NPM 安装 Strands CLI，只需运行几个命令，如果偏好交互式界面，还可以按下终端 UI 中的按钮。这样我就能立即拥有一个就绪的代理，与其对话、交互并观察其行为。此外，我也能相当容易地将其集成到 CI/CD 流程中。我可以通过 Strands CLI 运行代理，甚至如果我不愿意的话，完全不需要编写任何代码。因此这里有多种选择：它既适合开发，也能很好地集成到 CI/CD 和 GitHub Actions 等工具中。当然，正如 Morgan 提到的那样，对于生产系统中作为应用程序后端进程的深度集成，我仍然拥有编程接口选项。

Morgan 还有什么要补充的吗？

我认为 Harness 的另一个亮点是它对技能（Skills）的支持。以 CI/CD 为例，你可以将所需的技能放入它已支持的目录中，从而快速构建一个可以通过脚本插入流程的代理。这种架构通常是事件驱动的：当触发特定事件时，代理会被唤醒并加载相应的技能。由于所有功能都已内置，它可以迅速启动运行。因此，这是一种构建代理的极快方式。你可以以此进行原型设计，但这不仅仅是一个入门工具。Strands Harness 本身支持从原型到生产的全流程应用。由于它在底层基于 Strands Agents SDK 构建，你可以覆盖其中的任何元素。这意味着虽然起步很快，但并不会受到限制。因此，拥有多种接口（如 CLI）确实提供了更多选择。

不过，我们自己也在生产环境中运行它。如果你今天使用 Agent Core Harness，你实际上就是在底层使用 Strands Harness。

好的，那我们快速谈谈 Agent Core Harness 吧。它到底是什么？

Agent Core Harness……好吧，我们一直在讨论 Strands Harness，这是一款基准级的、最先进的开源软件。只需一行代码即可实现它具备完全可定制性，并拥有我们提到的 Python、TypeScript 和 CLI 接口。而 Agent Core 则是 AWS 中的一系列服务，包括托管的代理基础设施和应用层功能。我们拥有 Agent Core Runtime（特定于代理的计算资源），以及 Agent Core Observability（用于可观测性）。例如，如果你有来自代理的 OpenTelemetry 或追踪数据，你可以看到代理的思考过程、它为何做出某些决定以及在生产中使用了多少令牌。Agent Core 中还有记忆功能、代码解释器等诸多特性供探索。

Agent Core Harness 是位于这些服务之上的一层，它将它们连接在一起为你所用。你可以在 AWS 控制台的游乐场中进行实验：勾选一个框即可启用代码工具，再勾另一个框就能访问网络搜索信息等。我们还有 Agent Core CLI，你可以在本地终端中使用它进行实验、开发或运维。但 Harness 本质上只是 Strands Harness 的托管版本。你不需要将代码部署到 Lambda、ECS 或其他环境中，只需调用 API 即可。

没错，你只需要调用一个 API，提供我之前提到的那些配置项：你想从 Harness 加载哪些工具、如何启用或禁用记忆功能、代理的指令和提示词等。只需一个 API 调用，AWS 就会为你管理无限扩展、吞吐量等各种事宜。所以可以说，这是一个构建在 Strands Harness 之上的生产级托管代理框架。

听起来不错。你之前提到关于 Strands Harness 时有两点，但基本上通过 CLI 你可以构建一个代理。那么你能说说使用 CLI 后生成的产物是什么吗？当你与这个代理互动并想要导出时，你会得到配置文件还是其他形式？

Strands CLI 中有几个命令。如果你访问我们的网站并查看 Strands CLI 的 README，你会看到其中列出了不同的命令。在终端 UI 中输入斜杠（/）也能看到它们。

有一个导出命令，你可以运行“slash export”（即 /export），它会将你在 CLI 中构建的内容导出为代码。然后你可以将这些代码部署到你需要的地方，或者通过 Python 在本地运行。

TypeScript，无论它是什么。”“好的，酷。基于你之前提到的内容，我想问第二个问题，你暗示了Strands Harness能更好地利用Token。所以，你能再多谈谈这一点吗？我想我们有一篇博客文章讨论过性能问题，比如我们在28%的Token成本下达到了前沿的性能水平。你能详细解释一下吗？这意味着什么？为什么我们会得到这样的结果？”

“是的，对于Claude、GPT等模型，我们发现Strands Harness在基准测试中比Claude Code和Codex效率高出约34%。我们运行了六个基准测试，这些是编码、游戏解决和一些物理AI相关任务的标准化基准。我们在几种不同的试验中运行了它们，结果显示它在这些用例以及某些开源Harness中的效率高出约34%。”

“使用相同的模型进行比较，只是更换了Harness，对吧？我们提到过智能体等于模型加Harness。两者都对性能有巨大影响。当然，首先是模型，然后是Harness。如果使用相同的模型但不同的Harness，智能体的性能会有很大差异，包括准确性、执行效果以及成本和速度。”

“是的，我认为Strands Harness中引入的上下文工程部分在其中起到了巨大作用。其中之一是工具卸载（tool offloading）。当智能体解决问题时，它会调用API、运行代码、查看日志文件或读取本地磁盘上的文件等。所有这些上下文都会在智能体运行的每一步都提交给模型。”

“因此，在某个时刻，部分上下文可能不再完全相关。与其将所有工具结果保留在上下文中，它会激进地截断这些信息，并将其存储到外部文件中。这种截断就像是一个预览，告诉模型该文件里本质上有什么内容。如果需要查找更多信息，它可以按需从文件中检索更多数据。”

“这是一种渐进式披露的概念应用于工具结果。将这部分移出上下文窗口确实极大地影响了Token效率。此外，它还会主动进行压缩（compaction）。我想是80%还是85%？Aaron，我不记得确切数字了，但它也会在后台自动执行这一操作。”

“是的。我认为像Strands这样的框架中，亚马逊内部团队和客户发现能够自定义所有这些设置也能带来更高效的智能体。例如，我们不需要20个工具，Strands Harness中只有基础的五六个工具集。”

“你可以开启或关闭它们以节省Token，使模型更加专注，从而改善结果，包括准确性和成本。”

“是的。甚至对于压缩的自定义功能也是如此，它会在后台自动使用模型分析当前上下文中的内容，然后提供摘要或某种形式的压缩分析。但你可以覆盖这些设置，指定使用特定的模型进行总结并使用具体的指令。”

“Strands团队制定了适用于广泛用例的通用默认设置，效果非常好。但你仍然拥有覆盖这些设置的权限，以便根据你的特定用例进一步调整性能和效率。”

“你之前提到了Dogwood。请提醒我们一下，什么是Dogwood以及它与Strands Box的关系。”

“是的。Strands Box是我们最近一个月左右发布的产品，还有更多工作正在进行中，敬请期待。”

“它是一个预览版吗？”

“是的，目前它是预览版。Strands Box本质上是一个智能体的隔离层（containment layer）。它与Strands无关，你可以在其中容纳各种不同类型的智能体。Strands Box是用于智能体的文件系统和网络隔离层。”

“假设你构建了自己的智能体，可能使用了Strands Harness，其中包含文件编辑、网络搜索和网络抓取等工具。使用Strands Box，我可以在其内部运行智能体，并通过策略限制它允许读取、写入和编辑的文件系统操作及文件夹。”

“网络方面也是如此。那里使用的策略层是Dogwood，这是最近发布的开源项目，基于亚马逊和AWS的Cedar构建。Dogwood增加了一个时间层（temporal layer），因此它也能看到过去发生的事情。”

“它允许你定义策略，例如在用户请求退款的支持智能体用例中。如果用户请求退款，确保他们订购了产品并完成了某些步骤等。批准退款申请必须有一系列前置条件。通过Dogwood，它可以分析这些序列。”

“这是一种确定性的策略，就像一种证明一样。如果你编写了策略，Strands Box将保证强制执行它。你也可以在那里进行网络和文件系统操作。”

“是的，我认为Strands Box提供了你对沙箱的期望。虽然我们提到了网络和文件限制，但Dogwood策略允许你编写更丰富的语义策略。”

“你可以使用上下文信息，如基于时间的因素。在发布博客中提到的一个例子是我本地运行并使其工作的案例：假设我有一个可以访问Slack的事件响应智能体，我们希望它向Slack发布更新。”

“你可以设置一个Dogwood策略，规定它可以调用Slack，但每10分钟只能一次。这样它就不会向频道疯狂发送Slack更新。”

“因此，沙箱Strands Box允许你实现标准的沙箱功能，同时也允许定义更有趣、丰富的策略来界定智能体的行为。这不仅包括它能访问的文件和网络，还包括它具体能做什么。”

它能做什么，在什么情况下、什么样的语境中。所以，Dogwood 有一个引擎，叫做本地 Dogwood 引擎，它嵌入在 Strands Box 中，允许你评估这些策略，然后 Strands Box 实际上执行对这些策略的强制实施。>> 另一个我最近经常使用的有趣功能是，你知道，我有一个非常强大的、最先进的智能体，也许又是基于 Strands Harness 构建的？有了 Strands Box 和 Dogwood，我可以启用我的智能体执行诸如检索客户信息等操作，从而帮助客户。我还可以给它提供一个 API，正如 Margo 提到的那样发布到内部 Slack。但是，我不希望这两个功能混合在一起，对吧？我不想让我的智能体将任何客户信息发布到任何地方。有了 Dogwood 策略，我可以编写一个策略并由 Strands Box 强制执行：如果智能体接收了客户信息，例如进行了查找客户的工具调用，我可以随后拒绝所有来自该点的 Slack 消息。任何数据可能从智能体上下文外部离开的途径，我都可以从此处阻止它。如果该信息尚未被检索到，智能体可以自由地发布到 Slack 等地方。这是我最近使用的一个例子，以前很难编写：我必须有一个复杂的、类似状态机的结构来存储是否发生过这种情况。而现在 Dogwood 和 Strands Box 只是为我处理这些事宜。

是的，我也有另一个类似的例子作为这种方法的佐证：我有一个客户支持示例，随着情况的变化我一直在修改它。这是一种分层的安全护栏方法，确保我的智能体不会批准不应批准的退款。它有退款的限额。这是一个客户支持类型的例子。我在测试过程中注意到，今年早些时候，它偶尔会尝试在未先验证资格的情况下发出退款。尽管在我的运行手册和技能中我会设定：“查找订单，确保已核实它实际上可以退货，然后再执行退货。”但有时它会跳过这一步。因此，我利用 Dogwood 能够做的是将这一要求放入时间策略中：该工具只能在最近大约 5 分钟内调用了已验证的查找工具时被调用。所以，是的，它为你打开了大门，让你可以定义非常细粒度且针对你用例特定的策略，并在与你其他类型的隔离策略相同的空间中做到这一点。

Strands Box 的另一个酷之处在于，它目前是在本地运行的，但正如我们在发布时所说的那样，我们也在致力于支持 Linux。一旦它有了 Linux 支持，你就能在任何地方运行它，比如在云端、托管智能体上。这将为客户提供一种极佳的方式，既可以在本地又可以在云中运行智能体，使用相同类型的隔离和策略。>> 我认为我们喜欢一个……抱歉。>> 我们要做的另一件事，也是我们目前正在努力的事情是让人们更容易编写这些策略。你可以想象像智能体技能这样的东西，例如帮助你编写 Dogwood 策略。你也可以想象我们在前面提到的 Strands CLI 中的某些功能，帮助你在创建智能体时编写这些策略。甚至可以从生产环境中真实的智能体运行中生成它们，对吧？那些关于智能体做了什么、为什么这么做以及它的推理过程、工具调用及其发生顺序的可观测性数据。能够从中提取并编写策略，也许模拟这些场景并从它们生成策略。这些都是我们目前正积极致力于 Dogwood 的事情。

所以，你将 Box 描述为一个沙盒环境，在那里你有 Dogwood 提供的非常细粒度的策略等。那么这与其它沙箱类型的解决方案有何不同或互补之处？你提到了 Agent Core 运行时，它本身也是一种沙箱化技术。我们有 Lambda micro VMs（微虚拟机）和其他解决方案来进行沙箱化处理。你能就此 elaborates 一下吗？帮助我们将 Strands Box 在这个背景下定位好。>> 我的一位杰出工程师同事 Mark Brooker 为此写了一篇很好的博客文章。如果你想深入了解技术细节，你可以在 strandsagents.com 的博客上找到相关信息，也可以在 Mark 的个人博客中找到信息。但是，有几种对智能体进行沙箱化的方法：一种是用不同的计算节点， literally 一台不同的电脑，比如两台笔记本电脑、两个 EC2 实例、两个 ECS 容器或两个在计算层面分离的 Lambda 函数。

第二个选项，稍微低一点层级的是微虚拟机（micro VMs）。是的，我们有 Lambda micro VMs。Agent Core 运行时也是基于微虚拟机的概念构建的，其中每个智能体会话都是一个微虚拟机。它比单独的计算节点要轻量得多，资源消耗也少得多。我们只需为每个会话启动一个微虚拟机，它是隔离的、安全的，并且我们能够以高密度和高性能运行它。当你在生产中运行大量智能体时，这非常有用；例如构建像 Agent Core 运行时这样的服务时这样做会很有用。所以我们在那里广泛使用微虚拟机。Strands Box 是另一种方法，它是一个进程沙箱（process sandbox）。

Strands Box 本身作为另一个进程运行。它将你的智能体封装在该进程中。这里也有权衡：它更加轻量，甚至比微虚拟机还要轻，没有微虚拟机的开销，因此你可以更密集地打包这些智能体。它还允许你强制执行其他机制无法做到的某些事情。其权衡在于，Strands Box 的可信计算基（trusted compute base）更大，边界上的攻击面也更多。但是，这就是我们构建它的原因，我们将亚马逊和 AWS 以及我们自己经验中的所有工程最佳实践和学习成果封装到 Box 中。

有几种不同的选项，包括独立的计算节点、微虚拟机（Micro VM）以及进程沙箱化等。>> 但是，我们应该将它们结合起来吗？我是说，Rangan，你好像有话要说。

没错，Strands Box 是操作系统级别的隔离机制，你可以将其与其他方法结合使用。比如，我目前正在通过一个智能体（Agent）来研究这个问题：如果你给智能体运行 Shell 命令、访问互联网以及读写和运行代码的权限，并且所有这些操作都在微虚拟机上运行——假设智能体的源代码也位于该微虚拟机中。例如，在 Agent Core Runtime 上运行一个智能体并让它直接在主机机器上读写和运行代码时，它将拥有对该主机机器上一切资源的访问权限，包括其自身的源代码。它还可以访问与 IAM 相关的凭证服务等所有相关内容。因此，人们通常希望隔离智能体的运行环境以及代码的执行位置。同时使用这些技术可以实现这一目标，它们是互补而非冲突的。你会在微虚拟机内部运行操作系统级别的隔离机制；微虚拟机提供外层边界，而操作系统级的隔离则允许你在特定的受限文件和网络范围内读写或运行代码，并提供 Dogwood 策略来限制可执行的操作。因此，这些是真正互补的技术而非竞争关系。

我们在 re:Invent 期间一直在研究一个智能体，它训练并编写自己的策略和奖励函数，模拟月球着陆器安全降落在月球上。>> 好的。

你知道，你有一个基于 Strands Harness构建的智能体在迭代运行，对吧？我使用 Box 是因为我希望这个智能体能在我笔记本电脑上的 EC2 实例上运行。它是如何知道月球着陆器是否成功降落的呢？我们有一个脚本，从数学角度定义它是否安全降落——比如以正确的角度、缓慢的速度触地并关闭引擎。所有这些都以算法形式编程定义。我不希望我的智能体直接读取该脚本，因为它会作弊或操纵结果来欺骗评分系统。

因此我使用 Strands Box 隔离了智能体，使其无法读取评分脚本或评估脚本的文件。我们在 re:Invent 的工作坊中也将其托管在 GitHub 上。通过 Strands Box，我还限制了其网络访问权限（Dogwood 策略）。因此它既不能访问 GitHub，也不能读取本地副本的评分脚本。虽然仍使用计算节点或微虚拟机的外层边界，但在内部将其分为两部分：智能体和隔离的评估环境。

很好。那么关于 Strands Box，另一个近期发布的有趣功能是 Strands Decider。我之前录制了一期与 Mike Chambers 关于 Jeff 的节目，几天后你们发布了 Strands Decider。你能谈谈它吗？

是的，Strands Decider 背后有个有趣的故事。我认为 Mark Brooker（我共事的杰出工程师）和 Fabio（我们的一位首席应用科学家）共同构建了这种决策模型，即所谓的“系统一”模型。在短短三四天内完成开发、验证并确认其有效且用户体验良好后，我们就将其发布了。这是一个“系统一”模型：超轻量级、非常小，我们发布了几种不同尺寸版本（部分基于 Gwen 模型，部分基于 Gemma 模型），它们能极快地做出决策。就像对待其他智能体一样，我们提供相关上下文和允许选择的选项，它会返回这些选项的概率。例如典型用例中支持智能体决定是否退款：提供对话上下文后，选项包括“给予退款”、“转交人工处理”或“拒绝退款”。调用 Strands Decider 模型（如 Jev）后，它会返回每个选项的概率值。你可以选择概率最高的执行即可。这就是 Strands Decider 的功能，它是 AWS 的“系统一”模型之一，可在 SageMaker 上托管或本地运行。我们有从数十亿参数到两百多亿参数的不同模型规模，随着参数量增加能力增强但计算需求也相应提高。我们可以在 GPU 或 CPU 上运行它，视具体需要而定。

我认为它在引导干预等方面有有趣的应用场景。Strands 的设计允许通过介入或引导将这些模型引入智能体，而无需重写整个工作流。这种灵活性和可组合性使得新技术出现时可以轻松集成并提升 Token 效率——对于分类任务而言，使用常规大语言模型会消耗大量 Token。此外我注意到上周 X 平台上有人讨论安全漏洞问题，他们创建了一个能够接收诊断信息并决定是否需要升级处理的智能体。通过每分钟采样一次这种方式，相比以往方法成本极低。我认为人们正在以许多有趣的新方式应用这类模型。

决策模型完全开源，包括配方和权重。因此，您可以下载它并根据特定用例进行定制、微调。我认为客户将从这类模型中获得巨大价值。没错，这方面完全开源。我们用于训练该模型的数据也是公开的。

我们还看到了一些更有趣的应用场景，目前正积极将其集成到 Strands 评估包中。这是之前提到的 Strands 产品组合的一部分，不仅仅是一个 SDK。我们有 Harness、Box、Strands Decider，还有评估工具。构建好智能体后，如何确保它在大多数或所有情况下都能可靠地按预期运行？评估包正是为此提供帮助。

我们将系统 1 模型也集成到了其中，它们可以作为 LLM 裁判的替代品。以往使用 LLM 作为裁判有时成本高昂，取决于所选模型和测试用例的数量。引入系统 1 模型可大幅降低这一成本，在某些情况下甚至能提高准确性。如摩根所言，这里的一切完全开源。

如果您有相关数据，也可以轻松将 Strands Decider 模型微调至最终用例。Strands Evals 甚至通过合成数据生成帮助您创建这些数据，我们内部也在广泛使用。我在 X（原 Twitter）和其他平台上看到有人利用系统 1 模型和 Strands Decider 来玩游戏。

没错，我们看到它们玩《毁灭战士》、俄罗斯方块、贪吃蛇等各种游戏，还能控制机器人。我们还在实验一些有趣的事情：让机器人向前移动、向左平移或向右平移等。由于系统 1 模型更小更快，只需一次通过即可，不像 LLM 需要多次处理。

速度极快，对于机器人等场景至关重要，延迟必须控制在毫秒级。这也是我们进行实验的原因之一。我认为这很有趣，正如 AI 工程的演进所示：如今仅靠暴力穷举和大量 Token 或许能解决问题，但随着系统 1 模型等新技术和上下文工程技巧的出现，系统设计方式正在改变。

系统 1 模型标志着我们设计系统方式的重大转变。分类器并非新鲜事物，多年来一直存在。但这些系统 1 模型更有趣的地方在于其通用性。过去的分类器必须针对特定用例进行微调，别无选择，虽然可行但成本高、耗力且需要专业技能。

而像 Strands Decider 这样的系统 1 模型基于 Gwen 或 Gemma 等 LLM，具有通用性。您不必非要微调它（尽管因为完全开源且配方公开，您可以选择这样做）。这是系统 1 模型的一个显著不同点：它们更具通用性。

我创建的用例很有趣，尝试复刻 HBO 剧集《硅谷》中的“热狗非热狗”测试，在多模态模型下效果不错。是用 Strands Decider 做的吗？那是其中一个用例，但我还有更有趣的涉及追踪多模态数据的案例。

我觉得游戏场景非常有趣，比如向其输入《毁灭战士》的游戏截图。机器人的多模态应用也很有意思，我们给它提供摄像头画面流。在 Mac 上本地运行效果很好，延迟表现令人印象深刻。

关于 Strands Decider 就聊到这里，鼓励大家尝试一下，非常有趣，我相信未来会出现更多精彩用例。我认为路由模型（决定使用哪个模型）将是越来越常见的场景。

我们有模型路由器功能。构建智能体时，您可以在 Strands Harness 中自定义其使用的模型，比如 GPT、Claude 或开源模型。您还可以添加一个智能路由器，集成 LLM 或系统 1 模型来自动在它们之间做出决策。

我漏掉了这个细节，在哪里可以找到？它是 Harness SDK 的一部分吗？是的，您可以在那里找到它。太好了。最后我们要讨论的是语音智能体，可以谈谈吗？当然可以。摩根有一个很酷的项目叫“Billy Bass”，让她来介绍吧。

Strands 一直支持双向流媒体，我们最近将其从实验阶段移除，在 Python SDK 中正式提供。您可以实时与智能体对话，就像手机 App 那样即时互动。这不是简单的语音转文本再回复，而是直接将您的声音输入模型。

这带来了一些纯文本或语音识别无法实现的功能：语调、语气和情感，以及停顿或对某些词的强调。这些通过声音传递的差异在文本中往往会丢失。我们最近刚将其作为 GA（一般可用）版本发布，支持多种提供商，如亚马逊新发布的 NovaSonic 2.5。

您也可以使用 GPT Live 和实时模型，以及 Gemini 语音模型等许多不同选项。我认为如果没有这种集成……

语音转语音，但你需要在编排方面做很多底层工作才能从中构建出一个智能体。因此，Strands 发布了双向流媒体支持，提供了一个易于使用的接口来接入该模型。这样一来，就像你可以选择模型提供商、创建智能体循环并赋予它工具一样，使用正常的大语言模型（LLM）可以构建智能体；对于语音智能体也可以做同样的事情。今年夏天，当该功能仍处于实验模式时，我拿了一个“大嘴比利鱼”（Big Mouth Billy Bass）玩具，拆掉了所有内部零件，换上了一个树莓派。这个树莓派在云端通过 Bedrock 调用 Amazon Nova Sonic，从而实现了语音交互。

我基本上将电线连接到树莓派上，由它控制电机驱动器，这样鱼的头和尾巴就能继续“说话”。我让它变成了一个完全动画化的 AI 智能体鱼，并赋予了它访问我的日历、浏览网页等工具。有一次我把它放在书桌上，我会问：“嘿比利，今天有什么新闻？”它会醒来并告诉我当天的新闻。有趣的是，它的延迟非常低，对于语音模型来说令人惊讶。历史上，语音智能体最大的痛点之一就是响应速度慢。

双向流媒体连接使得架构更具响应性：你的声音直接传入模型，一旦你停止说话，它就能立即开始回应。在我那个“比利鱼”的有趣例子中，这更加好玩，因为我和它对话之间没有那种长达 10 秒的延迟。感觉就像在进行真正的对话。这种模式同样适用于客户服务智能体或其他类型的语音智能体。

当双向流媒体从实验版进入主 SDK 并正式成为 GA（通用版本）时，推出了一些很好的功能，例如回声消除。在正常的电话通话中如果麦克风和扬声器是分开的，互不干扰就没问题。但在我的“比利鱼”案例中，麦克风和扬声器在同一空间内，它会听到自己说话。这些语音转语音模型的一个特性是允许用户打断它，这样如果它在中间说话时你纠正说“不，我不是那个意思”，它会改变说法。

但如果它能听到自己的声音，它就会打断自己，这会导致它非常困惑。在夏季实验阶段我遇到过这个问题，现在成为 GA 版本后，SDK 已经清理了这些问题。使用现成的框架可以为你提供这些经验教训和最佳实践，否则你需要自己解决这类问题。我对这些功能感到非常有趣。

我们也一直在使用它，今年在 re:Invent 大会上你会看到更多应用实例，例如我们与机器人的结合。我可以与一个类人机器人进行实时对话，它的“语音大脑”能与我交谈，理解我的情绪和停顿。正如摩根提到的，我可以打断它。机器人硬件上麦克风和扬声器靠得很近，因此回声消除功能非常有用，这使得机器人具有高度的互动性。

语音模型能够像其他基于 LLM 的智能体一样进行工具调用，从而控制机器人。它可以跳舞、握手、在互联网上查找信息并告诉我结果。我们将在今年的 re:Invent 大会上展示许多此类案例。好了，今天讨论了很多话题。在结束提问之前，我想确保你有机会分享关于 Strands 及其发展历程的最后想法。

我们可以谈谈目前正在关注的一些事情，我可以分享一下。我们之前简要提到了历史：Strands 最初源于开发 Q Developer、Kiro、Amazon Quick 和 AWS Frontier Agents 等产品，它被用于其中几个产品的后端。在过去一年中，正如摩根提到的，经历了提示工程、上下文工程、开发工程和编排工程等阶段。这一系列事件在过去大约 18 个月内发生，Strands 品牌也随之演变。

最初我们有 Strands 的螺旋形标志，代表 DNA 的两条链，即模型和工具。这就是 Strands 名称和原始螺旋标志的来源。最近我们升级了产品组合和网站，现在你会看到一只青蛙吉祥物。如果你获得 Strands 的周边商品，也会看到这个青蛙标志。这象征着从 DNA 螺旋到现实生物（青蛙）的演变，反映了行业发展的步伐。

我们发布了 Box、Strands 编排框架、Decider 模型和 Evo's SDK，以及 Strands Shell。在 Strands Labs（我们的研究和实验领域）中也有许多成果，例如机器人相关技术。目前我们重点关注智能体控制和安全。这些智能体非常强大且有用，节省了大量时间并提高了生产力，但我们必须确保它们在安全的环境下运行。

我们与 Dogged、Strands Box 以及亚马逊自动推理小组合作的项目，结合神经符号推理集成，都专注于强大智能体的控制和安全。目标不是限制智能体能力，而是确保它们能在安全、受控的环境中发挥强大作用。此外，“递归自我改进”是当前非常热门的话题，即你使用智能体或编排框架越多……

它会变得更好，对吧？我们已经有记忆和智能体一段时间了，这并不新鲜，但这些技术正在进步。现在有更多的方式让智能体自我进化：它甚至可能修改自己的提示词，或者在运行时生成新的工具供自己使用。例如，它可以为自己创建一个新工具并运行它；或者执行类似生成形式化证明的任务——也许它会生成代码，并同时生成该代码属性的形式化验证。显然，当拥有一个能够执行此类操作的强大智能体时，智能体的安全性和控制就变得尤为重要。因此，这两个领域目前是我们关注的重点和热门话题。

令人兴奋啊！太酷了。是的，我认为Aaron主要已经涵盖了这些内容。对我来说，我 definitely 非常关注AI2 Growth在智能体安全方面所做的工作，并且非常期待看到该领域涌现出的所有精彩成果及其连接方式。我想给各位的建议是：如果你去年看过Strands但之后就没再关注，我建议你再次看看它。情况已经发生了很大变化，现在有一套非常强大的工具集，可以帮助你在生产环境中运行智能体，并利用AWS工程师为数百万客户实践的最佳做法。

所以，我鼓励大家访问网站，查看产品及其相互关系。你也可以随时通过社交媒体联系我们。还有一个Discord社区：如果你想加入Strands的Discord，网站上有链接。那里有很多人在交流、分享想法、协作并为这个项目做出贡献。我会把相关链接添加到节目备注中，这很棒，谢谢。

接下来是收尾问题：你有什么书推荐吗？有没有哪本书你觉得特别好并愿意推荐给听众的？你刚才说什么来着？是的，一本书。最近的话……在我职业生涯早期（我从事这行快二十年了），有一本《Google SRE书籍》——即系统可靠性工程书。谷歌几周前刚刚发布了第二版，其中广泛融入了人工智能内容：既讲述了生成式AI如何帮助工程师和运维人员，也探讨了从系统角度大规模可靠地运行生成式AI的方法。我非常喜欢这本书。

哇，不错！是的。对我来说，这不仅仅是一本实用书籍，更有趣味性。有一本书叫《代码：隐藏计算机硬件和软件的语言》（Code: The Hidden Language of Computer Hardware and Software）。随着我们深入AI领域，它抽象掉了许多底层细节——这确实令人惊叹。但对我这样在行业深耕多年的人来说，剥开层层表象，更多地了解我们从何而来、起点何在，也是很好的。这本书 literally 从莫尔斯电码开始讲起，然后层层构建：计算机是如何工作的、密码学等等。

有趣的是，我这本书放了好久。2017年有学生买给我，它就一直搁在书架上，直到最近我才翻开阅读。我正在逐步研读它。我觉得这是一个回顾过去、惊叹于我们走了多远的好时机，所以这是我推荐的书。谢谢！你最近发现了什么最喜欢的开发工具？不一定是亚马逊的。

我最近发现的最喜欢的开发工具……我今天用我的智能体做很多事情，所以答案就是“我的智能体”。我知道这有点像是回避问题，但我想很多观看的开发者工程师都会同意吧？我今天把大量工作都交给了我的智能体。另外，我最近很喜欢Kiro Crew（基罗团队），它太棒了！我非常喜欢Kiro Crew。它是一个基于Kiro CLI构建的框架（harness），我还可以将多个实例链接在一起。我可以从手机远程连接并与它对话，查看它在做什么；还可以在云端运行任务。

是的，我也强烈推荐Kiro Crew，我觉得大家应该去看看。不过我同意你的观点：我现在几乎用智能体处理一切事情。以前我们可能需要创建非常复杂的技能和工具，但随着模型变得越来越强大，我们可以简化这些步骤了。完全同意！那你接下来打算学习什么或深入钻研哪个领域？

我目前深度参与物理AI（Physical AI）相关的工作。也就是说，在大型语言模型、智能体和生成式AI取得巨大进展的同时，将这些技术应用于物理世界。我们要确保这样做是安全的——因为物理世界的约束和限制与数字世界截然不同。因此，我正在努力做的第一件事是将这些伟大的进展应用到该领域；第二件事是确保我们以安全、负责任的方式进行。

因为物理世界中有真人存在嘛！没错，正是如此。好的，Morgan你呢？对我来说，我将更深入地探索智能体安全领域，特别是形式化验证（formal verification）以及神经符号AI等方向。我之前对这些概念有所耳闻，但现在我想深入钻研以更好地理解它们。是的，我也会使用我的智能体来帮助我理解这些内容——毕竟我没有数学学位，虽然我有计算机科学学位，但那是很久以前的事了，当时并没有深入涵盖代码的形式化验证。所以我接下来打算深入研究这个领域。

不错！最后一个问题：你推荐邀请哪位开发者来做下一期播客？谁是你认为适合上节目的人选？嗯，我最近和Mark Brooker合作得很愉快。你一定要和他聊聊。他是AWS的杰出工程师（Distinguished Engineer），是我们许多技术背后的核心人物，最近主要参与Decider模型的工作，同时也深度参与了Strands Box项目。Mark非常棒！

是的，我推荐C2，我们的机器人代表（robots person）。我觉得你可以和他进行一场非常有趣的对话，探讨机器人和物理AI以及该领域的发展方向。我相信他也会带来一些实物展示在视频中。好的，这就是本期节目了。感谢Morgan和Arun的参与，也感谢所有听众。如果你喜欢这期内容，请在YouTube或你收听播客的平台点赞并订阅。并请留下评论——你的反馈能让我把节目做得更好，那么……下次见！谢谢，再见。