[music]
1969年，就在离这里大约30英里的地方，肯·汤普森坐在贝尔实验室。他的妻子刚带着他们一岁的儿子去加利福尼亚探望祖父母，为期一个月。于是，他坐下来心想：“我有一个月的时间，还有一个我想做的项目。我要把它拆解开来：一周内构建一个内核；一周内构建一个编辑器；一周内构建一个汇编器。然后，你知道的，再花一周时间做另一件事。”到了月底，他完成了Unix。
肯·汤普森所经历的过程之美在于，他拥有所谓的“概念完整性”。这意味着一个人可以将整个项目容纳在脑海中，并从头到尾执行该项目。还有另一个操作系统也是在20世纪60年代和70年代初由IBM在构建System/360及OS/360时进行的巨大工程。在此之前，如果你想升级计算机硬件，每次都必须重写随之而来的所有软件。
因此，OS/360是一项庞大的工程，IBM押上了全部身家，雇佣了成千上万的工程师。他们仅凭一些粗略的计算就断定：“好吧，这大约需要5000个‘人年’的工作量。所以让我们雇佣多达1000名工程师投入这个项目，看看是否能在短时间内完成。”该项目带来了许多经验教训。弗雷德·布鲁克斯是项目管理者之一，他总结道：“我们学到了很多东西，让我们把它写下来。”
于是他在《人月神话》一书中记录了这些内容。这是一本非常流行的书，汇集了如何构建和交付OS/360这一庞大项目的组织和管理经验。其中一个重要收获是，组建团队最有效的方式类似于外科医疗小组：有一位领导者或主刀医生，周围环绕着十位专家。
你可能有外科医生、语言律师（处理语法细节）、助手和副驾驶，每个人都有其专业领域。但主刀医生最终将一切掌握在脑海中，并维持那种概念完整性。这很棒，你们可以创造奇迹，外科医生经常在小团队中做到这一点。但我们也希望将这种结构进一步扩展规模。
快进到一个月或两个月前，我们看到了Linux 7.2的发布。这是另一个操作系统项目，历时九周，来自300多家不同公司的2600多名开发者做出了贡献。起初并非如此，Linux的贡献方式逐渐演变成了这种结构。回顾1998年的内核邮件列表，你会发现林纳斯·托瓦兹实际上处于崩溃边缘。
他收到人们的补丁，人们发邮件说：“我已经发了三次邮件给你我的补丁，为什么你没有提交到内核？”他心想：“够了。我要去度假了，我不想再听到这些消息。别出现在我的收件箱里。”他达到了崩溃点。我认为许多现在协调和管理大量智能体的人，可能会开始感受到成为瓶颈和达到极限的感觉。
当许多智能体贡献大量PR（拉取请求），而我们坐在GitHub上批准PR并确保一切按预期工作时，这种感觉尤为强烈。直到几年后我们才真正改变了这种状况。但在林纳斯发布“我受够了，我要去度假”的帖子第二天，拉里·麦克沃伊发帖说：“问题在于林纳斯无法扩展。”
拉里也做了一些自我宣传，他说：“我有一个想法。如果我们使用版本控制会怎样？”他当时在推广一款商业产品。直到大约四年后的2002年左右，林纳斯才承认：“你说得对，我无法扩展。与其让所有人直接向我贡献（星型结构），我们需要更像网络一样工作。”
我们建立信任层级，人们可以向受信任的维护者提交贡献，由他们审查代码。只有极少数例外情况会上报给林纳斯，但他仍然是最终合并到主分支的人。左侧显示星型结构有36个不同的参与者直接贡献；右侧则是优美的层级结构，每层最多只有四人向上汇报变更。
在旧金山的AI Engineer会议上，塔里克和加里传达的信息是：“我们有Fable，这令人兴奋，是时候变得不合理了。我们要更有雄心壮志，构建更大的事物。”加里告诉你们要“煮沸海洋”（意指处理海量任务）。因此，我们拥有非常强大的模型。
今天我们要探讨如何协调这些模型进入能够相互协作的系统，以构建极其庞大的项目并解决更大的问题。我是CJ Avilla，Anthropic的技术团队成员；这是哈里森，我也是Anthropic的技术团队成员。大家早上好！怎么样？兴奋吗？气氛不错，能量满满。
好吧，随着会议开始，我想简要介绍一下本次会话的流程。一部分是解释什么是Claude托管智能体（managed agents），我们要讨论什么，以及我们将花一些时间解释的多智能体编排引擎。另一部分是动手工作坊，所以请拿出笔记本电脑稍后幻灯片会有开发者额度信息，让你们可以亲手实践。
尝试一些我们非常兴奋推出的功能。在此之前，我们会先给大家一个关于……
这里到底在发生什么？所以，周五我们非常兴奋地宣布，在我们名为“Claude Managed Agents”的产品表面（即 Anthropic 在四月推出或已推出的产品）中，我们支持一个名为“Flows”的新功能。本质上，“Flows”是多智能体编排的下一个版本，你可以让 Claude 完全自主地编排其自身多智能体拓扑的全部结构。
正如 CJ 刚才谈论的，这些非常复杂、相互连接的网状结构映射到现实世界中的组织。我们设想未来 Claude 能够基本上自主进行编排，对吧？而“Flows”就是我们通过 API 表面实现这一目标的方式。因此，在我们深入探讨具体的 API 表面和体验之前，你们中很多人可能已经熟悉 Claude Code 中的动态工作流。
你知道的，你输入：“嘿 Claude，去执行 X、Y 和 Z。使用 Ultra Code。”它会启动一个相当复杂的智能体网络，并完全自主进行编排。它在底层使用了一个非常有趣的 JavaScript 引擎，基本上支持在 Claude Code 深处进行的类似 Map-Reduce（映射归约）和询问等活动。
我们知道这已经成为一个非常受欢迎的产品，人们通过终端输入指令并实时使用它。幻灯片上有很多例子，但核心理念是：你不必像以前那样去绘制这种分类动作或扇出并合成对抗性验证风格的拓扑结构，比如你说：“这是智能体一，它做这个；那是智能体二，等待智能体一采取某些行动等等。”
相反，你只需告诉 Claude 使用 Ultra Code 来实现其目标。基于我们内部进行的模型训练以及它自身的能力，Claude 将知道如何有效地编排自己，以完成越来越困难的工作。我们认为，这让我们尝到了如何利用完全自主的智能体自动化来解决人类最棘手问题的方法之一。
我对这个方向感到无比兴奋，虽然我肯定是个技术宅，对此很着迷。动态工作流以及一般性地使用多智能体拓扑（而非单个智能体）的真正酷之处在于，单个智能体会在更短的时间内、面对野心较小的任务时就崩溃。这里是一些粗略估算的数字：单个智能体运行一小时，而协调员和名单系统（这是我们多智能体的初步尝试）则能运行更久。
我们的“协调员和名单”系统类似于一个单一的协调者，其下只有一层智能体去执行非常具体的任务。但动态工作流我们认为才是解决真正难题的关键，它支持任意复杂的嵌套智能体集合并行运行并相互交互。我们花了很多时间与用户交谈，今天我也非常兴奋能与在座的各位交流，因为我想你们中的一些人对行业最新动态也有独到的见解。
我们听到了许多共同的主题。首先，你们正在构建自己的多智能体框架，做一些疯狂的事情。你们构建了极其复杂的系统，以解决我们刚才提到的单个智能体无法解决的问题。因此，你们正在手工打造多智能体编排系统，不得不处理容器重启等问题。
比如，如果你的100个智能体中有一个在任务进行两小时后崩溃了，你如何实际从该智能体离开的地方继续？确保你能理解整个拓扑结构的总体状态等。这通常是非常非平凡的任务，很难做到。此外，幻灯片左下角的要点基本上是说：你让单个智能体跟踪其下方的60个（举例）智能体。
正如 CD 提到的，Linus（指 Linus Torvalds）那样的方式并不具备这样的可扩展性。他是一位不可思议的协调者，但不幸的是，单个智能体能够“记在脑子里”的内容是有上限的。最后但同样重要的是，你必须弄清楚如何检查你所构建的智能体图。
你是否需要去探查图中的每个节点并询问其当前进度？是否将所有内容都通过协调员运行？一般来说，你如何在过程中的任何时间点理解图的状态？我们不仅从使用 Claude Code 的人那里听到了这些反馈，也从我们自己 API 的初步版本中听到了。
我记得有个梗说，大概在 Opus 4.5 发布后（那时模型真正起飞，自主编码能力变得极其强大），人们走路时笔记本电脑都半开着，以免他们的 Claude Code 崩溃，并确保智能体仍在运行。就像公园里的人们不停地点击“批准、批准”，只是为了让程序继续跑下去。
我们认为这具有巨大的局限性，对吧？如果我们要解决真正的、社会层面的难题，这种方式对于我们的雄心来说是无法扩展的。因此，快进到 Claude Managed Agents 以及我们如何将这种复杂的多智能体拓扑嵌入到我们自己的生态系统中。我意识到在座的许多人可能已经……让我问问，有多少人听说过 Claude Managed Agents？
[喷笑] >> 哦哇，这比例相当可观。大约占房间人数的一半。对于那些还不知道的人来说，你们应该去看看它。这也是我过去一年多来基本上每天每时每刻都在思考的事情。本质上，它是一个 API 表面，让你能够由 Anthropic 管理智能体的生命周期。
你定义一个智能体（基本上是一系列技能、工具、MCP 服务器等的列表），然后在会话中实例化该智能体（这本质上是一个请求，旨在完成实际工作）。然后那个智能体就放手去干，根据它试图实现的目标进行“烹饪”（即处理任务）。我们拥有整个 API 表面，使得存储这些有状态的 API 资源成为可能。
然后通过持久事件日志实时监控一切。所以，是的，去看看 Claude Managed Agents 吧，我们当然在这里是为了与你们讨论它。不过回到五月，当时我们发布了被称为……
就像多智能体 V1 版本，对吧？在这里你需要定义主智能体能够启动的每个子智能体。然后你必须监听基本上所有我们称之为“线程”的内容，即这些智能体各自运行的操作上下文。所以这非常像操作系统：总体进程拥有不同的线程，每个线程都有自己的上下文环境。虽然它们之间共享一些状态，但通常为了共享状态，你必须管理所有线程之间的消息发送和接收。
我提到这些的目的是想说明，即使我们的 API 表面支持这种设置，它也不是一个最简单的任务。但快进到上周五，我们发布了云托管智能体中的新功能——动态工作流（Dynamic Workflows）。我们认为通过这种极其简单的方式，能够更轻松地从这些日益强大的模型中获取能力。
其工作原理是：你有一个负责创建计划的主智能体，决定如何完成任务。例如，“将我的百万行单体仓库从 Python 迁移到 Rust”。该智能体在启动后，能够根据其自身的理性或能力判断，自动扩展并管理一组它自己创建和销毁的子智能体。
在多层多智能体编排的不同阶段，它能够完成离散的、可验证的工作单元，而无需你去管理这些组件之间的任何互连。简单来说，第一阶段可能是读取文件，它会启动一批探索者智能体去执行；第二阶段可能识别这些文件的某些特征。显然现在的智能体比我聪明得多，会制定出更好的计划。
我们认为这是通过 API 表面在平台上完成真正艰巨工作的路径。如果你想将其集成到产品中，这是一种非常简单的方法，无需再次打开 Cloud Code 或连接你自己的系统。在动态工作流运行时，你可以非常轻松地实时观察正在发生的事情。有一个单一的事件流基本上提供了智能体在实时的所有操作信息，你可以逐个检查每个智能体的事件。
此外，我们知道 Token 消耗是一个真实存在的问题，你可以在启动会话前设置预算，以免烧掉大量的 Token。如果你有一个系统实时监听智能体的总体操作方向，而你对它们可能的走向感到不安或想要引导它们，你可以通过 API 表面直接中断它们来实现。
与 Cloud Code 相比，我意识到这可能会让人有些困惑，因为两者都是工作流。但我们今天讨论的是云托管智能体内部的工作流。这是一个你应该能够集成到自己应用界面、内部流程或任何你想嵌入 Cloud 的系统中的 API 表面。你不必在终端上打字或与界面实时交互，也许你想将其挂钩到 CI（持续集成）中？这是实现这一目标的简单方式。
在我们的对比图表中，我认为值得强调的是，我们看到很多用户以调度运行的方式使用这些功能并监听 Webhooks。GitHub 的例子非常经典：也许你想构建一个“漏洞猎人”工作流，我们稍后会详细讨论并展示。好了，我想分享的就这些。那么，让我们开始其中一个吧。废话少说，我们来看看效果如何？
是的，无缝过渡。大家好吗？好的，我把它放大一点。我也意识到在座的有些人可能从未见过 Cloud Console（云控制台），所以我花一分钟简单介绍一下它。请耐心听我说。Cloud 控制台是作为 API 集成者，你可以管理 Anthropic API 服务中几乎所有资源的地方。
在控制台中，我处于默认工作区，会看到一个不错的下拉菜单。为了让你看清左侧那个不太美观的下拉菜单“管理智能体（Manage Agents）”，我先缩小一下画面。这是存放“管理智能体”产品所有 API 资源的地方，也是我们今天主要花费时间的地方。
如果你点击“快速开始”，你会看到各种基本上是一键式启动的工作流供你运行。但如果你滚动到底部，会看到一个名为“动态工作流”的小标签页，这就是我之前几分钟所讨论的内容。鉴于在座有很多金融领域的人士，我们将运行“股票观察清单扫描器”动态工作流。
你可以看到这个配置本质上是在创建一个使用 Claude Opus 5.5 的智能体，传入类型“multi-agent-2026-10-01”，并提供一个系统提示词，这基本上定义了智能体本身的角色或人格。我不打算过多赘述细节，但为了让大家了解清楚，当我们点击“使用此模板”时，这实际上是在底层创建智能体资源。
让我们开始运行看看效果如何。你的智能体要在现实世界中完成任何任务，首先需要的就是一个环境，对吧？这本质上是一台供 Claude 操作的计算机。在过去的十到十二个月里，我们一直认为给 Claude 提供对计算机的访问权限使其整体能力大幅提升。配置你的环境就是给予 Claude 这种计算机访问权的方式，我已经创建好了一个环境。
我不会重新构建它，但如果我是从零开始创建一个新系统，我会直接点击这个四键按钮。不过，“股票监控列表扫描器环境”是我今早测试时使用的运行环境，你可以看到我只需点击标有“启动会话”的按钮即可。我对苹果、英伟达、亚马逊、摩根大通、埃克森美孚和Costco感兴趣。我不知道还有什么需要添加的吗？嗯，我也不知道，我就先这样吧，因为我现在没什么创意。好，那我们继续按回车键。这一步是在启动一个会话，真正的多智能体编排将在此处发生。我稍后会深入其中看看具体情况，但大体来说，这只是利用我们 API 今天支持的现有原语（在托管智能体中），去切实完成实际工作。
让我们进入会话面板，这里可以看到我在平台上做的其他事情。抱歉，这里的缩放显示有点奇怪。我要快速浏览一下这个界面，因为我不确定有多少人曾在真实世界中见过它实际运行过。在这种情况下，我们有一个智能体，即我们的股票监控列表扫描器智能体。打个比方吧，我忘了那个负责监督一切网络的最终角色的名字了，但这就像是金字塔顶端的人，也就是首席执行官（CEO），他在管理着底下的所有人。然后我们有环境，即我之前提到的 Claude 运行的计算机；还有一堆关于实时发生情况的详细信息。
你可以看到智能体已经启动并开始工作了，这是实际运行的过程。稍后我们会更详细地解释这些抽象概念的含义。基本上来说，Claude 正在基于其自身的自我编排能力，使用其自身定义的 essentially（本质上）一组智能体，一步步实现每一个目标。你可以看到我之前提到的会话线程机制——即单个上下文窗口、智能体的单次实例化——正在并行启动。嗯，挺酷的。我不知道怎么说……我觉得这很酷，因为这一切基本上都可以通过提示 Claude 来完成。
我们可以跳进之前的会话看看发生了什么，因为它比当前的进度要快一些。嗯，这基本上展示了和我刚才展示相同的内容，但这些都是已经完成的状态了。我不打算深入讨论输出文件细节，但这里的主要观点是：我认为在这种情况下，每一步只有大约六个并发智能体。但 Claude 可以根据任务的复杂性来增加或减少智能体的数量。嗯，我在想还有什么要展示的吗？我想这主要涵盖了这个界面的功能。当然，我们稍后可以通过回答问题来更深入地探讨。你介意切回去吗？>> 好的，没问题，我们来做吧。嗯。
又一次无缝过渡。 >> 是的。 >> [笑声] >> 好的，所以在之前的演示中……谢谢 Harrison。嗯，很好的 walkthrough（讲解）。哇哦。是的。所以，那只是一个示例，展示了如何在控制台中进行原型设计、设置流程并在其中测试。这是在实验中查看流程是否按预期运行的非常常见的方式。然后，一旦你对你的工作流感到满意（无论你的用例是什么），你通常会将其集成到你自己的应用程序或工作流程的某个部分中。
无论是你想按计划触发这个监控列表扫描器，使其每天或每个工作日在市场开盘前运行——比如安排在开盘前 5 分钟运行，以便在开盘时立即收到报告；还是你想从 Slack 或其他界面触发这些流程或任务。这就是创建智能体的代码示例。它只是像这样传递多智能体配置以启用多代理功能。然后，当你创建第一个事件并将其发送给主智能体时，你只需说“运行工作流”。这就是让流程启动并运行的全部所需操作。就像告诉 Claude：“是的，使用多智能体”和“是的，运行工作流”。
默认情况下，这是最简单的入门方式。但在本例中，Claude 会动态创建执行该工作所需的任何子智能体。因此，在智能体配置中也可以传递预配置的子智能体。如果你有一组知道如何查看雅虎财经、特定新闻来源或美国证券交易委员会（SEC）的 Edgar 网站等的子智能体……如果你拥有在研究过程中重要的特定活动方面专精的子智能体，你也可以在设置智能体时将它们配置为其中的一部分。你可以设置专门从事某项活动的独立智能体。
还有一点我觉得现在知道会很不错：你也可以赋予这些智能体访问自定义技能、MCP 服务器的权限。你可以让它们运行你自己环境内的自定义工具。它们非常强大，并且所有这些功能都与工作流协同工作。我们稍微谈到了环境，你也可以在自己的环境中运行它——你可以自带沙箱（bring your own sandboxes）。如果你愿意，可以在自己的基础设施中运行这个自托管环境。
所以，我再简单回顾一下那个监控列表扫描器正在做什么。通常，如果你要用单个智能体创建监控列表扫描器，你可能会进入 Claude Code 并说：“这是股票代码。请去研究它们并回来告诉我。”Claude（或任何单个智能体）会尽力查看每个股票代码，但当只有一个智能体时，它会面临几个不同的困难。我们稍后会讨论这些困难以及工作流如何解决它们。但在工作流的帮助下，我们将拆分股票代码列表，并将每个代码传递给扫描智能体。我们正在进行“扫描阶段”。所以我们取一个单个股票代码并传递……
将其交给扫描智能体，这是一个隔离的上下文环境。在这个环境中，它只关心自己的一个股票代码（ticker），并且可以在不受其他任何股票或其他上下文中的搜索结果影响的情况下独立运作。一旦扫描完成，它就可以将结果传递给下一个阶段。此时，“审查”步骤也是一个独立的上下文环境，它可能需要也可能不需要反馈给扫描器，或者输出那些需要写入的报告细节。
我们尝试过以单一智能体的形式运行这种“关注列表扫描器”，也将其作为工作流（flows）来执行。在大多数情况下，当你考虑使用工作流时，你应该思考如何确保对试图解决的问题进行极其全面、深入的排查。这意味着你要不遗余力地挖掘细节，并且愿意为此投入相应的成本。
因此，你会在右下角看到运行工作流的成本要高得多；但在中间面板中，你会发现它在发现所有细节方面要有效得多。如果你使用过动态工作流（例如 Claude Code），你可能经历过类似的情况。这也是一个讨论如何提示 Claude 构建工作流的契机：你可以要求它在不同阶段分配不同的资源。
例如，你可能会说：“我想在扫描阶段投入更多的测试计算时间。”你可以提示 Claude 并指定：对于扫描阶段，我们可以使用 Haiku。这是一个非常快速、高效的模型，它的唯一任务就是去互联网上进行扫描。因此，我们可以说：“为每个股票代码启动两个 Haiku 智能体，进行非常全面的扫描。”这可能是一个成本较低的阶段。
然后你会说：“一旦我收回所有网页并查看细节时，有时会遗漏一些信息。因此，我想在审查阶段投入更多资源。”所以，我希望使用 Fable 智能体深入回顾所有返回的细节。我会说：“Claude，请在审查阶段使用一个 Fable 智能体，并为每个股票代码在审查阶段分配两到三个智能体。”
你可以想象这些工作流是可以扩展或收缩的，具体取决于你愿意在该流程点上投入多少资源。这是一种非常有效的方法，可以让你在每个阶段尝试不同的投资比例，以获得确切想要的结果。因此，强烈建议通过全面的评估集来确保工作流在非常重大且重要的任务中按预期运行。
我们在控制台中展示的“关注列表扫描器”就是你可以开始使用的一个模板。你只需点击即可浏览。此外，还有一些模板是直接构建并捆绑在 Claude Code 和 Claude API Skill（技能）中的。如果你安装了从周日晚上开始的 Claude Code，你应该能够运行由 Claude 管理的智能体（managed agents），并使用“关注列表扫描器”模板。
这将启动一个模板，并允许你直接从 Claude Code 管理你的智能体。我认为这是驱动 Claude 托管代理以及使用 Claude API 的一种非常有效的方式，即在 Claude Code 内部进行操作。你可以指示 Claude Code：“启动这个资源”或“启动那个资源”，它将使用另一个名为 Ant CLI 的命令行界面来驱动并与 Claude API 交互。
因此，很多时候我不用控制台，而是使用 Claude Code 并说：“启动一个执行 X 任务的托管智能体。”今天当你进行实验时，如果你不想使用控制台，我会推荐这种方式作为切入点。此外，我们还对哪种初始系统提示或初始消息最适合工作流进行了大量实验。
我们发现，在开始时让 Claude 自由发挥的空间越大、越模糊，效果往往越好。只需告诉 Claude：“嘿，我想让你使用一个针对单个股票代码的工作流智能体，去进行这项扫描。这是我大致寻找的内容。”让 Claude 控制构建初始工作流的过程，然后你可以在之后进行微调。
让我们实际演示一下。屏幕上会显示一个二维码，用于提供 API 额度，以便你快速上手。如果你还没有 Claude Platform 账户，我们本周还宣布了一项新消息：对于 Max 和 Team（团队）订阅用户，你的订阅中包含一些 API 额度。因此，你可以链接你的订阅以确保拥有这些 API 额度。
如果你有 Max 计划，我想是每月的 $100（Max 5X）。团队订阅则高达 $500。此外，还有额外的 $50 用于实验这个 Claude 托管代理工作流。我认为到目前为止我们可以暂停一下。我们还有更多内容想要讲解，但让我们先停下来。请尝试操作一下，然后我们可以开放提问环节，如果任何人有任何问题。
好的，这是一个很好的问题。问题是：当你在 Claude Code 中运行 {slash} Claude API Skill（技能）时，这是在本地机器上运行的，还是作为 Claude 托管代理的一部分在云端运行？Claude API Skill 和 Claude Code 将在你的机器或云环境中运行，具体取决于你如何设置 Claude Code。这与 Claude 托管代理是完全独立的系统。
你的 Claude Code 将根据其配置在本地或云端运行。当你启动它时，这将从 Claude Code 环境向 API 发出调用，以创建智能体、会话以及 API 中的所有其他不同资源。那么，它与插件合并的路线图是怎样的？目前，插件涵盖了许多不同类型的资源。
其中一种就是技能（skills）。当你查看 API 表面时，你会注意到有一个名为“resources”的字段与之关联。
此外，还有一些与插件中显示的技能相关的其他 API 字段。简短的回答是，插件的各个组件应该直接融入当前的 API 表面。至于将其合并……抱歉？哦，没关系。另一种情况是工作流生成一个标量值，你可以将其拉取回你的 Claude Code 吗？或者你能再多说一点关于这方面的情况吗？我明白了。好的，所以问题基本上是：给定一个你为潜在收购研究创建的动态工作流，你能有效地将其作为插件分发吗？
答案是今天还不行。对于未来某个时候是否会完全支持开箱即用的功能，我目前没有很好的答案。但你可以基本上将工作流运行过程中生成的提示词提取出来，直接放入 Claude Code 或其他地方。它是一个文本文件，检查结果可能会非常接近。是的。所以问题是，如何在 Mac 环境或其他不仅仅是托管表面的环境中运行代理？
我们有一个称为“自定义工具”的抽象概念，这基本上是一种让模型调用你、请求你采取某些操作的方式。工作流程是这样的：在工作流运行期间，为你的代理定义一个自定义工具。然后，每当你想在本地 Mac OS 机器或互联网上的其他任意计算机上运行某些内容时，你只需获取该自定义工具调用，在那台机器上做你想做的事，然后将结果返回给模型。这回答你的问题了吗？
好的，太好了。是的，完全正确。所以问题是，我们都在意令牌消耗的问题，我们需要能够优化我们的流程，以免基本上花费大量的令牌。因此有几种不同的方法可以做到这一点。这是一个可泛化的问题，类似于基于某些内部标准（如令牌或能力等）对提示词进行爬山式优化。
我记得我们是否发布了这个爬山技能……是的，在 Claude Code 中有一个爬山技能，它可能有助于你至少对提示词本身进行优化。至于工作流操作的调整……这是一个有点逃避的答案，但你将获得 Claude 在工作流运行期间所做的一切的完整转录。
因此，你可以提取这些转录文件，交给 Claude，要求它识别工作流中可能做得过多或不足的地方。它能够基本上自我优化。这样你就可以根据你想要的任何标准要求 Claude 进行优化。但是，我要说我们上周五发布了这个功能，我怀疑这种原生集成将是许多人关注的重点。
是的，我要补充的一点是，还有另一个名为“梦境”（Dreaming）的产品。你可以在 Claude 托管代理中提供一组会话来进行这种做梦过程，它可以像结晶一样基本上改进与这些会话相关的记忆存储。因此，你可以附加一个记忆存储，运行你的工作流，然后在执行了十次或更多之后，让那些会话通过梦境进行结晶并改进跨会话的记忆。
我不知道你是否还有更多关于梦境的想法或……是的，我想我基本上描述了手动实现你自己的“做梦”功能。但我忘了我们有一个专门为此设计的产品。是的，没错。所以你可以使用“梦境”产品，也可以使用工作流来实现做梦功能。
是的，完全正确。所以你可以直接在控制台中可视化它……抱歉，退一步说。问题是：你能在工作流运行时可视化多代理拓扑结构吗？在控制台中可以，我们稍后会给大家机会去查看。但如果你想围绕此构建自定义 UI 也是完全可以的，因为这些工作流中的每一个都会启动拥有自己会话线程的子代理。
这是它运行的上下文，所有这些信息在基于每个线程的基础上都可以通过 API 表面访问。因此，你可以围绕它启动任意有趣的 UI，以满足你的任何需求。是的，我看到 Jay 可能正要……是的，你可以像……看所有的线程。
你可以深入到单个子代理中。你可以看到它们正在做什么。如果你是以编程方式访问它，还可以查看在会话流式传输期间发出的大量非常全面的事件。你会看到每一个工具调用和结果，以及从子代理移交回主代理（即领导代理）等的时间点。
是的，所以在当前的工作流中，仪表板中的 UI 绝对是我们将继续改进和迭代的东西。但你可以深入挖掘并看到大量细节。例如，你可以看到这个是“收到线程消息”事件。因此，你可以知道领导代理实际上传递给了子代理什么内容？你可以在这里查看该有效负载以深入理解整个图中每个转换的实际发生情况。
我还要说，这是建立在公共 API 之上的，仪表板本身也是如此。因此，你在这里看到的任何东西都可以完全手动实现。问题是：它是否意识到自己的预算？目前，模型在运行时并不知道其预算。预算主要作为护栏，以确保它不会失控导致令牌消耗激增。
我们发现，至少在最新的模型中，如果你告诉它预算，Claude 会变得有点焦虑，而我们不希望发生这种情况。但我强烈怀疑随着时间的推移这会有所改善。所以它与工作流配合使用的方式是，如果你达到 5 美元（假设单位），你会收到一个基本上表示“预算已达成”的事件。
然后，如果你想查看发生了什么并可能提高预算，你可以在会话运行时进行操作。如果你想要添加更多资金也是可以的，工作流将会拾取并继续运行。
比如它从哪里继续工作。所以，这里有一个很好的暂停组件，如果你增加预算，你已经完成的工作不会被丢弃。但这完全取决于你基于你自己的……是的。那么问题是，与 Claude Tag 集成的计划是什么？嗯，Claude Tag 本质上就像一个 Slack 机器人，将你所有的信息连接在 Slack 界面内。因此，它是一个稍微正交的产品界面，而这是一个 API 界面，如果你想直接与 Claude 构建集成，你会使用类似这样的东西。嗯，我怀疑至少目前不会有直接连接……你知道什么？是的，是的。如果你想自己构建类似 Tag 的东西，你可以使用流程（Flows）。
如果你在使用 [snorts]。完全正确，完全正确。所以就像……是的。嗯。>> 是的。我还要说的是，像这样——我们想要改进的很多方面就是让这些产品界面更好地协同工作。所以我会说，预计在未来几个月内……你知道的——你会继续看到这些接缝开始消失。你可能已经注意到，比如 Co-work 和 Chat……我们合并了其中一些功能。你现在可以看到你可以从许多不同的界面使用 Cloud Code。所以随着时间的推移，我们会缩小这一差距。是的，嗯，Cloud Tag 绝对是一种使用这些工具的非常有效的方式。而且我们……令人惊讶地大量使用了它。Cloud Tag 对我们许多实施来说是一个巨大的日常驱动工具。所以……
那么问题是，代理之间是否有通信的方式？比如流程中的子代理？嗯，没有像通过 API 直接说“子代理 A”给“子代理 B”发送消息并发送有效负载 X 这样的直接方式。但是所有子代理都共享一个文件系统。因此，如果你的工作流程中需要它们相互通信，它们可以有效地使用文件系统作为来回发送消息的方式。嗯，但没有像代理消息发送和接收那样的直接抽象来让你看到消息的回传。没有一种直接的方法可以强制一个子代理向另一个发送消息。是的，所以问题是流程是否本质上能够修改自身并根据可能发现的问题进行爬山式优化自己的提示词？
嗯，做到这一点最好的方法可能与刚才讨论的“爬山”规模类似，以及潜在的“梦境（Dreaming）”产品界面，这样代理可以看到它过去做了什么并从错误中学习。没有像……嗯，实际上这里我会快速展示一下。我们有这个部署的概念，基本上部署是一种按计划运行这些会话的方式。没有一种方法可以像计划那样自我改进事物，但我完全可以想象一个世界，你可以使用这些组件构建它，那将会很酷。>> 另外，关于我们要反复提到的“爬山”规模，这是 Claude API 技能的另一个子命令。嗯，所以在 Claude Code 中，你可以输入 {slash} Claude API hill climb（爬山），然后告诉它你想要迭代改进的事物。这有点像将 Andrej Karpathy 的自动研究烘焙成一个每个人都可以使用的技能，以便迭代改进他们自己的提示词。
所以如果你从一个你知道的现成用于查看列表扫描的提示开始，然后你可以进入 Claude Code 并说，“Claude API hill climb（爬山）这个提示”，然后它会与你合作迭代地找出，好吧，我们在优化什么，然后它就会一直 grind（磨练）直到为你生成一个非常好的提示词，以便你……嗯，满足你的需求。所以取决于爬山过程中发生的情况，有时它会给你它真的完全取决于你试图解决的确切项目或问题。所以当几周前宣布 Haiku 时，或者一切发生得如此之快……我想可能是上周吧，我不知道。嗯 [笑声] 当 Haiku 宣布时，我为我和孩子们玩传声筒游戏构建了这个工具。所以它有一个网络摄像头，它会给我们一张卡片，我们试图表演出来，然后 Haiku 会猜……你知道我们在做什么。
所以我使用了这个爬山命令，Claude 为我生成了一个工件（artifact），让我可以录制自己做一些滑稽事情的会话……比如划船和打网球等等，这样它就可以改进并迭代提示词，说哦我们需要这么多帧每秒，并且需要更新提示词来做这个。所以取决于问题是什么……当你运行爬山时，Claude 可能会或可能不会给你一个人类界面来迭代那个东西，你也可以请求 Claude 为你做那件事。所以它实际上相当强大。>> 是的，所以问题是关于纳维-斯托克斯方程（Navier-Stokes）以及这些突然同时发生的科学发现，如果是这样的话……我们会用什么来做这个。我认为也许在我们的演示中我们的股票行情显示器不够雄心勃勃，因为你几乎……你完全说对了，因为推动实质性科学进步的方式基本上就是缩短完成这类工作所需的时间。嗯，流程本质上是一种……抱歉，向难题投入测试时计算（test-time compute）的方法，并从模型中更快地获得更强的能力。
所以嗯……我不能具体谈谈像我们内部如何喜欢我们运行这类研究工作负载的 harnessing（适配层）看起来是什么样的，但就像我们认为特别是作为一个 API 界面……解锁这种力量是我们迈出的第一步，让这类发现或广泛的科学进步对公众变得可行。所以嗯……是的，我对那件事感到非常兴奋（jazzed）。>> 是的，我要补充的另一件事是……就像我们在之前的 Claude Managed Agents（Claude 托管代理）的多代理设置中一样，如果你有一个协调器和一组代理列表……我们有一些限制关于你可以启动多少个子代理。使用流程（Flows）目前，我认为它可以是 1,000 个代理。所以像……这个其他有趣的部分是，你的主代理可以启动多个流程
流程结束后，可以启动另一个新流程。因此，你可能会将一个庞大的项目交给一组智能体来处理。我其实原本希望这个项目能早点完成，但并没有。不过我在周五启动了一个由1000个智能体组成的流程来构建一个操作系统，并向你们展示。它已经运行了大约85个小时。目前尚未完成，流程已推进到第三或第四阶段，并且一直在与大量智能体协作处理这个更大的项目。这些是你完全可以投入给它的任务。显然，由于这类任务耗时较长，我在周五刚开始时就放手不管了，希望周一早上9点能准备好。这确实适合投入给云管理智能体流程。
让我们稍后再保存这个案例，但它实际上非常轻量级。我对它说：“肯·汤普森一周内就做出了Unix。你能尝试做一个与Unix兼容且带有Python解释器的操作系统吗？使用流程，请大胆一点，最多可以使用1000个智能体。”基本上就这些指示。然后让它运行，我还给了它一个GitHub仓库供其工作。我上次检查时，该仓库已有约1000次提交记录。所以是的，智能体仍在持续工作。
有人问，我们是否注意到像增加新员工一样，随着子智能体的数量增加会出现边际效益递减的情况？在组织规模达到一定程度后，协调成本等会随时间推移而增加。这是一个非常好的问题，我没有完美的数据或答案。我认为这个研究领域还很新，未来对于每个子智能体的能力曲线斜率——即每增加一个额外智能体时的增量效果，可能会更容易计算。但我目前没有一个确切的好数字。
有一点我要说的是，使用流程的好处在于你可以以有组织的方式将问题抛给智能体，而不是无序地处理。如果你把同样的100个智能体扔向问题，有流程会更好，因为通过门控和不同阶段，这些上下文之间存在组织和隔离。
那么问题来了：有没有办法防止无限循环或级联错误？答案是有的，某种程度上可以。为了防止会话失控，我会设置预算限制，具体取决于你的预算是多少。除此之外，Claude在检测行为不端的子智能体并进行相应管理方面表现得相当不错。我们在评估中发现，Claude擅长自动检测这类错误并切断它们。
另外，我们讨论了“做梦”、爬山算法以及从过往运行中学习等概念，我们认为这是一种非常强大的方式。如果你希望优化流程的特定部分或Claude试图完成的任务的具体方面，这是一个很好的方法。让我复述一下你的问题：你想知道是否可以根据某些标准（如较小的变化信号），只执行流程的特定部分，以避免浪费令牌。目前平台上除了让Claude在单个流程中条件性地执行操作外，没有其他类似机制。如果非要诚实回答，我可能会在你的应用层在流程之上添加额外的检测逻辑。
所以你可以大致估算你要做的工作量。我认为对于单个智能体能在30秒内完成的任务，流程并不是好的选择；它更适合那些雄心勃勃、复杂的任务。
接下来我想谈谈智能体之间的上下文护栏，以及每个智能体所持有的“世界观”。每个智能体都被生成到一个独立的会话线程中，这在数据库中是完全物理隔离的独立上下文窗口。默认情况下，这些上下文窗口不会通过文件系统等方式泄露。此外，每个智能体都有自己的系统提示词。你可以使用自己的系统提示词，或者让Claude自动生成，这是强制实施完全独立人格的好方法。
此外，线程消息的发送和接收是查看智能体间通信的良好方式，以确保中层管理智能体没有对其下属做你不希望它做的事。关于之前提到的共享文件系统作为子智能体交互的方法，以及如何物理隔离它们的问题：目前的做法基本上是通过提示词来实现。如果你想让智能体只专注于特定的目录路径子集，只需在提示中说明即可。目前没有针对目录路径的权限层，但这似乎很有用，我们可能会考虑后续改进。
关于使用钩子（hooks）来控制对文件系统不同部分的访问，这正是托管智能体中的工作方式。虽然不完全像钩子那样，但你实际上在帮我回答这个问题：我们可以通过一种抽象称为“工具”来实现这一点。
权限方面，基本上每当智能体想要读取文件时，根据您提供的配置，它可能需要向您或您的系统请求权限。在这种情况下，如果您想要锁定某个路径（例如 /mount/fubar），您可以直接读取工具发出的请求——即 Claude 提出读取该文件的请求，检查实际运行该读取操作的智能体，如果不想让智能体拥有访问权限，就直接拒绝它。
哇，谢谢。很感激您的解答。哦天哪，您这是在给我铺垫呢。嗯，我们要进入下一个话题了。问题是关于凭据管理的。这里的要点是，“天哪，一千个智能体，这太疯狂了。” 这样让它们在互联网上肆意运行似乎并不安全。我们将在本次演示的后半部分专门讨论智能体安全性问题。
问题是，是否有方法在流程中融入人类反馈？目前实现这一点的常用方式是使用“自定义工具”。基本上，就是给 Claude 一个名为“请求人类反馈”的工具。每当它需要时，Claude 会向您请求这种反馈，您可以提供所需的任何响应作为该工具调用的结果。
问题是，在构建操作系统的例子中，如果进程崩溃了怎么办？或者发生了其他意外。您如何查看中间状态？在它运行过程中，您如何与之交互？您是否想……
是的，当然。我在提示词中要求它组建一个文档编写团队，并指定使用 Sonnet 5.5。我非常喜欢由此生成的文档质量。在每个流程结束时，这个文档编写团队会回去撰写关于该阶段实现内容的文档。因此，我可以直接去 GitHub 仓库查看正在生成的文档。
这是一种方法。另一种方法是……您刚才问是否有暂停或停止的方法。稍后我们会讨论中断会话的功能，您可以中断流程并说：“实际上你们走错方向了。请在这里停下。” 您还可以提示 Claude 提供报告，或者随着流程推进更新特定报告。通常它会生成一些标记好的文件供您打开查看。
是的，产品界面有一个很酷的特点是：无论您是否使用流程功能，只要让 Claude 将输出写入其 outputs 目录，就会有一组可下载的文件。这些文件通过我们称为 V1 Files 的另一个 API 接口保持持久性。或者，您可能像 CJ 那样向 GitHub 提交代码更改。因此，在这些运行过程中会产生大量输出供您自行检查。
问题是，在处理某个极其宏大的问题时，中途您从外部发现了一些可能改变整体运行轨迹的信息。您是愿意浪费两天的 Token 从头开始，还是有其他办法？目前的做法是中断会话并提供更多信息。例如告诉 Claude：“引理 X 对您可能很有用，请查看一下。”
Claude 作为您交互的主要智能体，拥有流程当前状态的完整视图。它可以检查之前停在哪里，从而启动一个新的流程，既考虑新信息也结合历史背景。目前不支持的是：您不能将第一个计划中的单个步骤注入到中途，然后重新运行后续步骤等。但这就是目前摄入更多信息的方式。
笑声。问题是，作为一名游戏开发者，假设您想通过流程等功能在游戏中加入遥测数据（telemetry）。我想确认我是否回答了您的问题，因为我可能偏离了方向。当我想到遥测时，我认为是指智能体运行时的相关信息。
您可以将智能体放入任何产品体验中，无论是游戏、网站还是其他应用。但遥测方面更侧重于当前正在发生什么：我是否需要基于会话的操作采取行动？我们是否走在正确的方向上？
好的，太好了。在我们的 API 界面中，我们有极其丰富且持久的实时事件流，您可以实时流式传输所有正在发生的事件。您也可以通过静态 API 端点列出这些事件……
是的，我在思考。我不确定我们是否……是多模态的吗？所以，如果您想在 Claude 管理的智能体中投入类似游戏截图的内容并据此采取行动……我认为目前这可能会带来较差的用户体验，因为取决于您在游戏中构建的具体内容，处理起来会花费太长时间。
但我要说的是，Claude 管理的智能体确实支持图像输入，而且 Claude 在检查图像方面非常出色或正变得非常擅长。因此，完全存在这样一种场景：您只需投入截图，Claude 就可以根据您的需求采取相应行动。目前它不会感觉像实时那样快，但确实可行。
哦，是的，没错，完全正确。这实际上是一个很好的观点：也许遥测用于调试崩溃等情况时非常有用。您可以截取游戏发生情况的屏幕截图，并将其投入管理的智能体中。这完全可行且合理。
问题是关于共享这些资源。您可能是一个组织，拥有一套模板化的智能体供您使用，并希望确保不仅仅是您自己拥有访问权限。目前实现这一点的两种方式：首先，我们有一个 Terraform 提供商，您可以使用它来创建智能体。
此外，控制台还提供多种导出功能，允许您导出智能体并将其放置在其他地方。但目前没有“一键分享”按钮让您与他人共享一个智能体。基本上，我们只是试图打破……
降低门槛，以便获取智能体的主体部分或任何 API 资源。我们已尽力使其尽可能简单，只需将其上传至其他地方即可。但目前 API 中尚无类似的一等公民共享机制。>>我认为，向客户提供此工具的最常见方式是为其构建产品界面。
因此，您可以建立自己的网站或应用程序等，用户通过您基于托管智能体构建的层与之交互。许多 Claude 托管智能体的互动直接通过 API 进行，许多客户将其作为内置功能提供给最终用户。例如，如果您在使用一个流行的项目管理工具中的看板界面，将卡片从一列拖到另一列时，可能会触发一个 Claude 托管智能体会话。
该会话通过 API 启动流程或创建执行后台任务的会话，而非作为前端组件直接共享给 Claude 服务。这是一种更偏向幕后、集成到您自己产品中的机制。是的，>>关于分配给他们的内容……问题是是否有方法调整智能体的行为？与其在系统提示中设定，不如根据分配给智能体工作的类型进行键控。
这是一个有点回避问题的答案，但我可能会基于工作规模在系统提示中设定：如果希望智能体考虑粗略的工作量大小，它应根据工作量采取不同类型的行动。没有专门的旋钮……好吧，我收回这话。有一种方法可能可行，具体取决于您想实现的目标：我们在每个会话基础上设有“努力程度”旋钮。
我们还能够在每个会话的基础上覆盖部分字段。因此，给定任务和智能体时，您可以设置这些努力程度旋钮或更改智能体的不同部分以适应目标。这可能是我处理该问题的方式。是的，问题是 Claude 如何知道规模？它如何确定操作层级？
我的回答可能不够令人满意，但关键在于评估和较低的默认值。例如，若查询股票代码，我们不应启动一千个消耗大量令牌的智能体；但若涉及纳维-斯托克斯方程，则可能需要更强力地推动流程，具体指示其启动相应层级的智能体及并行化。
好的，我想我们继续吧，还有一个问题。最后一个问题后，我们也可以接受更多提问。明白了。问题是：基本使用 Markdown 文件既观察智能体行为又定义智能体的正确方法是什么？我认为这取决于具体情况。我们的 API 表面功能丰富，具体取决于您的目标。
例如，如果您将 API 密钥放入直接交给 Claude 的 Markdown 文件中，这肯定是不好的做法。切勿这样做。因此，这真的取决于您通过 API 表面表达内容的复杂性。如果您只是希望基于基本 Markdown 进行一次性操作，那么 Claude Managed Agent 可能不是合适的抽象层。
但 Claude 底层工作原理基本基于文本，所以差别不大。好的……>>我再补充一点：需考虑某些上下文对每个子智能体的相关性。一种技术是逐步揭示上下文，例如使用链接到其他 Markdown 文件的文件。如果您是负责内核的工程团队，主文档可列出索引：内核、汇编器或编辑器在此处。
这样子智能体即可读取相关细节，从而节省令牌量。>>准备好继续了吗？>>开始吧。好的……抱歉，我们必须加快进度。稍后会有问答环节。请保存您的问题，结束后我们可能还会停留片刻交流。我猜大家还没看控制台……希望一切顺利。若未成功，我们很乐意稍后协助您运行首个流程。
之前讨论过或 Harrison 提到的 Bug Hunter，以及上一场 AI 日出现的另一个常见主题：循环。我们如何闭合这些循环以使系统更自主运行？Bug Hunter 是一种有效的流程和模式，也是可用的模板及 Cloud Code。其理念是：提交 PR（拉取请求）后，由 Bug Hunter 流程审查并揭示性能问题或实际故障。
这使人类能更快速地审查 PR。与单个智能体审查不同，Bug Hunter 通过流程将代码分割为切片，每个切片交由独立的上下文处理。拥有审查该特定代码片段的智能体负责标记潜在问题，然后进入第二阶段：评审者基于该片断同意或不同意这些发现。
不同的问题，然后将所有这些问题呈现给一个阶段，该阶段可以挑选出可能是我们需要去验证的真实问题的候选项。所以，如果你是一个人工审查代码合并请求（PR）的审核员，正在查看某些代码时，你通常会对代码库中甚至未在此 PR 中提到的一些部分拥有背景知识。因此，这往往是我们信任人工去继续审查进入代码库的代码的原因。但这变得更为有效，因为智能体可以开始向你揭示这些问题。
作为人类，你可能会说：“我认为这会成为一个问题，因为我了解代码库中另一个角落的情况。让我拉取这个 PR 并验证这是否确实是一个问题，以及问题的严重程度如何。”你可以运行这一“证明”阶段：下载代码库（可以让智能体执行），尝试复现 bug 或验证该问题是否确实存在，然后生成报告。在这种情况下，我们称之为报告，但在实践中，这些内容会作为评论添加到实际的 PR 中，“Bug Hunter”会在行内提出问题。
它会说：“好的，你正在对此文件进行更改，而在代码库遥远的角落处，这将导致意想不到的问题。”它还可以提供优先级排序，比如这是非常严重的问题还是不太严重的。因此，这又是一个可以根据代码库及其构成（是单体仓库还是有多个不同仓库等）将测试时间计算资源分配到问题不同部分的实例。“Bug Hunter”是一个帮助闭环处理 PR 流程的有效工具。
这是通过 Cloud Code、Cloud API、托管智能体以及 Bug Hunter 启动它的方式。嗯，这就是它的运作方式。另一个非常有趣的流程。有多少人关注我们的 Twitter（推特）账号 Cloud Devs？你们有在 Twitter 上关注我们吗？好的。哦，关注者不够多啊。确实不多。好吧。
所以，如果你在 Twitter 上关注 Cloud Devs，你会发现很多时候当我们宣布新产品或新功能时，都会附带一个解释该功能如何工作的动画视频。实际上，我们使用一种流程来生成许多这些视频。我可以启动一个流程并说：“解释动态工作流程是如何工作的。”然后它会经历各个阶段，或者作为子流程（抱歉，不是子流程，而是独立的单独流程）。
它将有一个研究阶段。它会去查找关于其工作原理的所有实际细节，然后进行规划、侦察和事实核查。接着构建简报。随后，它可以将设计简报移交给生产阶段，由后者制作单个场景并为其添加动画。在实践中，我们还有一组额外的阶段来处理音效、配音和脚本编写等工作。最终你会得到一个视频。“Explainer Studio”是一个相当有趣的流程工具。
作为协助我们 Twitter 账号运营的一员，我觉得它为我节省了大量时间。我想四年前制作我们要发布的视频可能需要花费 20 个小时来添加动画并使其精美。而现在，只需向流程发送一个非常简短的提示即可。你也可以在 Cloud Code 中通过 Cloud API、托管智能体和 Explainer Video Maker 来实现这一点。
你可以问：“什么是 DNS？DNS 是如何工作的？”我不知道，让我们看看。它会生成一个流程。我们有一些它制作的视频。来看看结果吧。“好的”，那么如果任务对于单个智能体来说包含太多部分该怎么办？我们有 300 份合同，希望它遍历所有这些合同并找出某些信息。
使用动态工作流程时，智能体会编写工作流，然后查找这些控制权变更条款。服务器将在后台运行该工作流。“这主要是我的声音。”“是的，因为我们……”（笑声）听起来不错吧？不。结果返回并汇总在一起。这些是我们讨论过的不同事件。你可以看到动画效果相当不错，解释了会话线程的工作原理、如何通过传递多智能体参数通过 API 启用它。
并告诉你：“哦，是的，设置预算可能很重要。”如果预算发生变化，或者如果你提前结束而未用完预算，你可以延长它等。嗯。“我如何部署到 YouTube？”“它不会部署到 YouTube。”（笑声）这是一个好问题。我们应该这样做，真的应该。对。所以，如果你在 YouTube 上关注 Claude AI 频道，我们在那里做了一些非常有趣的事情，比如直播音乐。Claude FM 最近进行了一场非常有秋日氛围的音乐直播。
谁想看自行车是如何制造的？好的，有多少人想看看马桶是怎么制造或如何工作的？是的，不是怎么造出来的，而是工作原理。好的，让我们看看。“马桶”似乎赢了，虽然优势不大。（笑声）我想我们知道自行车的工作原理。而且我喜欢它给视频加上了 Claude 的品牌标识。（笑声）我们要求它们提供带有相同颜色和背景风格的标志，你可以赋予其自己的品牌风格。
另一个建议是使用 Claude Design 来设定你的品牌风格并创建你自己的设计系统。你可以进入 Claude AI/design，或直接在 Claude 桌面应用中使用 Design，然后根据你设定的品牌风格提供给流程。甚至底部的字体也是 Anthropic 的字体，这非常酷。所以这是一个强大的工具，特别是如果你负责在互联网上发布动画视频的话。
这是另一个非常有趣的流程示例，但还有很多很多……
不同的用例，无论你是试图解决一些你知道的、真正重要的千年难题，还是尝试生成视频，或者是想改进你的股票选择或开发流程。[清嗓子] 使用工作流（flows）可以构建非常多、各种各样的东西。嗯，所以，我们之前稍微讨论过的一点是，单智能体（single agents）在应对某些情况时会感到吃力。这是我们作为动态工作流的一部分所学到的一个重要结论，我想稍微谈谈这些挑战以及它们如何应用于 Claude Code 和由 Claude 管理的智能体。
首先是“代理懒惰”（agentic laziness），其次是“自我偏好偏见”（self-preferential bias），第三是“目标漂移”（goal drift）。嗯，事实证明，如果你的提示词是这样的：“我们现在正经历一次服务中断。请去查看这 50 个不同的服务，告诉我故障的根本原因是什么，但不要触碰生产环境。我是说，真的不要在生产环境中做任何更改。去研究一下是否有服务中断？绝对不要触碰生产环境。”单个智能体可能会遇到这样的问题：在它看到 35 个服务都健康后，它开始说服自己说：“哦，看起来一切都很好。可能没问题了。”
它会想：“我真的不需要再看剩下的那些服务了。”所以，我们观察到“代理懒惰”是单个智能体可能遇到的一个问题。在它看到了太多健康的服务后，它可能会觉得：“好吧，我想我们没问题了。”于是决定不再查看剩余的部分，以节省一些 token 成本，并告诉人类：“我们可以继续了。”协调者（Coordinator）也会遇到类似的问题。
你可能有三个子智能体向报告者或协调者汇报，而协调者仍然需要跟踪：“好吧，我们已经检查了多少个？”以及所有服务是否都健康？而且这些子智能体自己在某个时刻也可能变得懒惰。因此，这并没有比使用单个智能体有太大的改进。当我们拥有工作流时，虽然这不一定是确定性的，但我们有能力拆分并指派一个独立的智能体专门负责每个服务。
这样，它们只对自己小范围的工作负责，我们可以得到更好的答案回来，因为我们可以通过工作流告诉它：“好吧，向所有 50 个服务扇出（fan out），并为每个服务指派一个智能体去检查该服务是否健康。”到最后，我们可以确定我们确实检查了每一个服务。这就像是扇出和循环智能（loop intel）的结合体。“自我偏好偏见”。
如果你要求一个智能体写一首诗，然后问它：“那写得好吗？”它会说：“是的。”这相当常见。如果你要求智能体写一些代码，然后你说：“这段代码好吗？”它也会说：“是的。”这是因为它通常是执行工作的那个智能体，并且对它所做的工作感到满意。所以，如果你能将这两者分开，你会得到更好的结果。
我们从“顾问模式”（advisor pattern）中知道了这一点：你可能有一个智能体作为生成者，另一个智能体作为评估该结果评判者。这利用了“生成器-判别器差距”（generator discriminator gap）。但是，当你面对一个非常庞大的问题时，你仍然会遇到这种情况：如果没有这些分离且明确的检查点，你的智能体阵容可能无法扩展到你所需的程度。
因此，通过工作流，我们可以分散到许多不同的智能体上，并进行对抗性审查（adversarial review），这种审查拥有自己独立的上下文，完全不受之前检查内容的影响。最后一个是“目标漂移”。如果你还记得最初的提示词大概是这样的：“出去扫描所有这些服务，告诉我们是否健康，但我最后说的是：不要触碰生产环境。”
对吧？所以，如果我们正在填充上下文窗口并进行压缩（compacting），随着我们遍历所有这些服务，不仅可能会变得懒惰并倾向于自己的答案，而且“不要触碰生产环境”这一指令也可能会在这一过程中丢失。因此，有一件事很重要：随着上下文不断增长和增长，我们可能会失去对确切目标的追踪。
而通过工作流，我们在开始时可以获得一个非常具体的目标，并且因为我们拥有所有这些独立的上下文，我们可以确保该目标以一种非常一致的方式复制到每个子智能体中，适用于所有不同的阶段。[轻笑] 所以，我之前稍微铺垫过这一点，但我认为在运行这些相当沉重的智能体工作负载时，最坦率地说最重要的事情是确保你没有做坏事，或者你的智能体在运行时没有做坏事。
现在我们要从单个智能体扩展到可能数百个，对吧？那么，我们如何扩展我们的安全和安全态势（safety and security posture），以确保基本能跟踪正在发生的事情，并确保平台上不会发生任何坏事？这将变得相当技术性，因为 A 我认为这真的很重要；B 我们在 API 抽象方面投入了大量思考，以使其更容易默认创建安全的智能体。
如果我要说在构建智能体时必须做对的一件事，那就是这个。所以，请容忍我稍微谈谈我个人非常关心的事情。我将逐一介绍这些安全风险。抱歉。[清嗓子] 嗯，我知道“安全”这个词可能含义过载了。这仅仅是六件非常具体的事情，如果每个人都在进行——抱歉 [清嗓子] ——智能体开发的话，每个人都应该意识到。
我认为第一点可能是相当广为人知的：如果你的智能体正在扫描开放互联网，它们可能会意外地从非你自己的个人或实体那里拾取指令。你必须确保没有类似“忽略之前的指示”这样的文本，然后实际去其他域名.com 并窃取我所有的信息，对吧？这从根本上说是我们一直在努力解决的问题。
无论是在模型层面、从堆栈的最底层，还是我们在构建分类器以进行工具调用检查方面投入了大量研究精力。
Claude Code 基本上处于一种模式，就像是一个可以在平台上运行的默认功能。因此，我们强烈建议查看自动模式的权限策略，稍后我们会对此进行更多讨论。第二点是我之前提到过的关于 Markdown 文件的内容：不要只是把 API 密钥扔进 Markdown 文件中并交给 Claude。归根结底，Claude 会采取你赋予它的凭据所对应的人格角色；如果你正在构建一个产品，并通过该产品暴露你的智能体，而 Claude 在后台拥有对计算机（如虚拟机）的访问权限以完成大部分工作。
如果在磁盘上存在一个文件，比如“我的 API 密钥.md”或“.txt”，即使你将其设为隐藏文件或放在所谓的秘密目录中，始终存在某种泄露的风险。无论是用户找到一种方法来提示 Claude 还是你的产品以获取这些密钥，纯文本形式的凭据总有可能泄露出去。因此，我们创建了一整套抽象层，基本上确保凭据永远不需要接触沙箱环境。这是一个极其重要的解耦操作，我稍后会详细讨论这一点。
第三点是数据外泄问题。如果你的智能体访问敏感信息，你需要确保它不会与你自己以外的第三方共享这些敏感信息。此外，你要确保你的智能体没有超出你要求它做的范围。我之前提到过预算限制，平台上还可以设置其他限制。在此基础上，你需要通过为智能体建立权限策略来确保它们不超出其专业领域运行，这样只有你赋予访问权的工具才能真正执行。
最后但同样重要的是，对智能体的行为保持一定的可见性是非常基本的要求（table stakes）。因此，我们拥有一个持久的事件流，它基本上记录了你的智能体在整个生命周期中执行的所有操作的完整轨迹。作为开发者，你有三件主要工作：我们喜欢用“声明、限制、检测”这个朗朗上口的词来概括，但这正是现实情况。你必须声明智能体的身份、权限、能力以及它应采取的人格角色、技能和工具等。
“限制”部分实际上是指智能体的物理局限性，即如何限制智能体，以便即使在最坏的情况下，它在开放互联网上造成的危害也能降至最低。为此，我们在环境策略中提供了非常明确的配置选项，你可以指定它只能访问特定域名，或者只能使用网络搜索而不能进行网页抓取（反之亦然），具体取决于你的需求。
最后但同样重要的是，我反复提到的那个持久事件流是你实时检测正在发生的事情的关键方式。如果智能体做了你不满意的事情（无论你对“满意”的定义是什么），你可以实时监听这些事件流，并立即中断那些偏离你预期方向的任何会话。让我们看看。酷。
当我们去年四月推出 Claude 托管智能体时，几乎出现了一种说法，即 Anthropic 平息了这场争论：在构建代理基础设施时，“大脑”和“双手”应该是分离的。玩笑归玩笑，我们认为这是使安全性成为默认可能的基础设施的关键组成部分。这里的理念是，“大脑”——即实际运行推理循环的通用代理框架以及会话状态（涵盖每个智能体和会话生命周期中发生的所有事情）——与我们所称的 Claude 的“双手”完全分离。“双手”是智能体实际上能够在现实世界中采取行动的地方。
你可以将“双手”想象成在 Claude 可以访问的计算机上运行 grep，或者把它想成一个自定义工具（更准确地说是一个可能在你之前提到的 Mac OS 机器上运行的自定义工具）。从广义上讲，不应该有任何方法让你通过给予“双手”访问权来以任何被视为有害的方式完全操控“大脑”。这是我们将所有需要可访问的机密信息与“双手”本身分离的关键所在。
因此，我们以一种非常有趣的方式确保了凭据注入的工作机制（如果我记得没错的话，我稍后会更详细地讨论这一点）。其思想是：任何访问任何秘密的容器都完全伪造这些凭据，也就是说，如果你尝试使用那些值调用 myapi.com 之类的服务，它们实际上无法工作。只有在右侧的出口代理层这一退出路径上，这些凭据才会被替换为实际的真实凭据。
因此，在物理层面上没有任何方法可以提示 Claude 或通过访问沙箱从沙箱或 Claude 的大脑中窃取该凭据。这完全解耦了代理相关操作与实际凭据本身的关系。我其实已经铺垫过了，基本上来说，默认情况下你不应该在使用 Claude 托管智能体或自行构建任何代理工作负载时“自毁”（foot gun yourself），从而导致凭据泄露。所以，一定要认真对待这一点，我认为这非常关键。
现在我将把时间交给 CJ 来谈谈 >> “好的，我们将逐一介绍这些不同的功能以及你如何通过 API 控制它们。再说一次，确保限制 Claude 托管智能体的重要方法之一（我们之前讨论过几次）是设置预算。我们可以说：‘好吧，运行这个流程，你有 1.25 美元的额度。’
如果它达到了 1.25 美元且流程尚未完成，你可以决定是否要增加预算并让它继续运行。它不需要重做已经完成的任何工作；或者你只需说：‘好吧，这就是我们为特定会话分配的预算。’因此，每次启动任何会话时（无论是否是流程），你都可以使用这个功能。
预算，这与 Claude 托管代理的另一个部分——“结果（Outcomes）”搭配得非常完美。这两者的结合非常美妙，因为现在你可以说：“我希望得到这个结果。这是我想要的成果、我期望的评估标准以及我的预算。”也就是说，在给定预算的情况下完成这一目标。这里的“预算”是一种确保我们控制成本、不让代理意外持续消耗令牌的方式。
下方的第二个代码示例展示了如何从 API 中断运行中的流程。你可以传递 user.interrupt 事件来停止当前流程，然后重新提示 Claude 或执行其他所需操作以继续。这是两种不同的机制：一个是预算控制，另一个是在会话运行中途进行中断。
为了测试这一点，你可以使用今天运行的流程，设置一个低于预期消耗的预算（例如一美元），然后运行该流程。当达到预算限制时，增加预算并观察其继续执行，这样你就可以稍微实验一下这种机制。
我们之前讨论过的另一个能力是：让审查代理回顾所有会话，理解其中发生的事情，并了解调用了哪些工具以及是否发生了任何意外。这是一个可以使用 Claude 托管代理的用例，通过提示词指定需要检查的内容。
由于我们拥有持久的日志和每一个发生的事件记录，你可以通过 API 提取这些转录文本并传递给托管代理。你可以要求它：“审查整个转录文件以及过去一周的所有历史会话，告诉我我的代理是否做了任何意外之事、访问了不该访问的资源或调用了奇怪/意外的工具。”
因此，构建一个 Claude 托管代理并将今天的会话交给它，询问“这些会话中是否发生了任何异常”，这是一个非常方便的操作。最后一点（我认为这是最容易实现的低垂果实）是：如果你今天有任何 Claude 托管代理集成，请将你的权限策略从“始终询问”或类似模式切换为“自动模式”。
开启自动模式非常重要，且属于低垂果实。我们进行了一些研究（也有公开的研究报告），指出当你的笔记本电脑开着盖、你在公园时，Claude 不断询问“你批准吗？”，人们往往会连续点击“是、是、是”。
作为人类，我们 97% 的情况下都会点击批准，容易陷入盲目同意的状态。但 Claude 更有耐心，使用自动模式它可以判断单个工具调用是否安全、是否会执行破坏性操作以及是否应该真正执行该动作。
你只需将权限策略从“始终询问”切换为“自动模式”，这就是最容易实现的改进。接下来，我想详细谈谈我之前提到的“保险库（Vaults）”概念，以及为什么我们认为凭据管理是任何代理平台至关重要的部分。
在这个例子中，我们通过环境变量使用 Twilio API。在简单的情况下，我们可能会上传一个包含 .env 文件（内含 Twilio API 密钥）的文件到容器或会话中，以便代理读取并在 Python 脚本等行动中调用 Twilio API。
但问题在于明文存储的风险，这也是我之前一直在谈论的内容。因此，与其让密钥默认暴露在容器外，你可以使用凭据和凭据保险库来管理这些秘密。在这种情况下，我们使用 Vault 凭据将 Twilio API 密钥存储为环境变量。
这个“注入位置”字段主要用于配置网络出口：我期望秘密以何种形式出现？是作为出站请求中的 Bearer Token，还是直接出现在请求体中？你可以根据此字段进行配置。
此外，“网络哈希”与“允许的托管域名”配合使用，用于指定：给定凭据 X 时，出站时应替换为哪个域？如果我们能轻易猜出容器中的占位符秘密或真实密钥，我们绝不希望 Twilio API 密钥泄露到像 mydomain.com 这样的无关域名。
因此，安全处理这些信息至关重要。一旦在保险库中创建了凭据，你只需在创建会话时传入该保险库。平台会足够智能地根据保险库内容、存在的秘密以及出口层的占位符，确定如何注入正确的值。
我们还讨论了给代理提供尽可能小的工具集。我们代理工具集中一个有趣的工具是“网页抓取”和“网络搜索”。你可能希望默认禁用它们，因为你不希望代理在未经你明确允许的情况下访问互联网。
在这种情况下，你可以将想要禁用的任何工具类型的 enabled 字段设置为 false。这里有一些关于代理工具的基本示例。“MCP（模型上下文协议）”工具非常有趣，因为你无法预先知道 MCP 服务器会返回哪些 MCP 工具。
例如，假设你调用了 GitHub MCP。虽然我们相信 GitHub，但如果发生入侵攻击者添加了恶意工具怎么办？
提取工具或类似的东西，你可能不希望代理抓取它。因此，你可以基于每个工具启用 MCP 工具体系结构中的特定设置。此外，你还能通过物理使用环境配置来限制代理的网络访问权限。你可以将环境再次视为 Claude 运行的计算机。因此，如果我只希望 api.twilio.com 可访问，我可以在环境配置中明确指定这一点。这样，我的 API 密钥就隐藏在潜在窃取风险之外了。我可以物理调用 api.twilio.com；如果我尝试调用其他网站，它将在出口流量发生时，在防火墙层物理失败。
好吧，让我们回到开头。我们认为在许多情况下，我们正在试图重新发明我们在 70 年代关于如何组建庞大的人类团队以完成这些工程壮举的组织经验。因此，我们非常兴奋地向你开放 Flows 功能，并期待看到你利用它构建什么。希望你能借此实现一些雄心勃勃的项目。从模板开始，将其塑造为你自己的风格。告诉我们你的发现，是的，我们很乐意回答更多问题。我想我们要接近尾声了，但我们也可以在走廊区域继续交流，非常乐意解答任何问题。
我看到这里有一个问题。是的，问题是：你试图给代理一个任务，但它返回的结果不太容易验证。例如在视频生成中，这很大程度上取决于人的审美品味。那么当你给出反馈时，如何在 Flows 中进行迭代？我建议从使用 Claude Code 并开始迭代某个流程入手。你可以动态工作流在 Claude Code 中使用，或直接尝试生成第一个视频的流程，然后让 Claude 将你所做的编码为一个技能，以便在作为流程一部分的 Claude 托管代理中使用。
通常起初会有相当多的迭代过程，以确定所有不同的阶段以及该流程实际如何运作。也许你需要在组织内进行事实调查，以了解现有流程是如何构建的。然后尽力将其编码，并使用爬山技能来迭代实际提示并改进它。这种“爬山”机制可以是人为驱动的。你可以说让我们通过爬山让视频变得非常出色，它会生成一个或两个版本，你选择偏好的那个。然后它再生成更多，你再选偏好者，这样它就会自行迭代其提示词。
我认为问题是回到操作系统示例：何时使用 Ultra Code，何时使用 Claude 托管代理（即 Flows）？是的，Ultra Code 适用于你坐在笔记本电脑前、在终端中输入内容并直接交互式使用 Claude Code 的场景。而 Claude 托管代理 Flows 工具则适用于你希望定期发生某些可重复操作，并希望将 API 集成到某个产品界面中，而不是直接仅使用 Claude Code。你最后的描述方式正是正确的思考角度：Ultra Code 本质上是一个单一实例，而我们实际上将 Ultra Code 的抽象或方法推广到了 Claude 托管代理 API 中的 Flows。
你可以将 Ultra Code 视为我的一次性交互，而 Claude 托管代理则是“我想将其提升一个层级并复用它们”。你可以按照任何触发器计划运行它们。这是一个很好的问题。那么，如果平台上发生恶意事件，你如何看待责任归属？不幸的是我不是律师，我无法明确介入太多。我认为应将其视为运营任何其他平台型业务：如果你集成 API 并在其之上构建产品，最终平台本身将与用户直接建立关系。因此，这是一种纵深防御机制，确保堆栈的每一层都尽力防止平台上发生坏事。
问题是关于持久事件流以及内部人员构建的用例。我在想一个有趣的例子：有人在内部构建了类似 Catan 的竞争性模拟，它使用所有事件来解释每个玩家做出选择的原因。它使用了自定义工具，这是将 Mac OS 机器暴露给云托管代理以执行主机环境外操作的方式。也许你们这里有一些有趣的案例？我认为思考它的最好方式是如果你想构建自己的 UI，显示所有不同的工具调用等。
很多人都在重新发明轮子，也有一些前端工具帮助你暴露代理的事件流并返回来自代理的消息。构建聊天界面如今已是基本标配，但在这种与代理对话的聊天界面中，你可以看到工具调用。然后你可以展开这些工具调用，也许某个生成式 UI 的工具调用会显示图表。特别是对于金融用例，你可以说每当我的股票行情观察列表遇到有趣的事情时……
渲染图表，以便我可以添加技术分析等内容到图表中，使其具有高度交互性。你可以利用返回的事件流来实现很多功能。希望这回答了你的问题。我认为有很多事件，这是一套非常通用的工具集，你可以基于它构建基本上任何用户界面。
那么问题来了：原生 Anthropic 和自托管版本之间是否存在兼容性差异？自托管沙箱中有一些功能尚未完全支持，但流功能是完全可以支持的。使用自托管沙箱时，这些功能开箱即用。我还在回想哪些功能不支持，但总体而言，我们尝试在所有环境中（无论是自托管还是其他环境）都支持类似的功能。
只是你在创建会话时传入的环境参数会改变类型。那么，在 Bug Hunter 的例子中，存在多仓库依赖图的情况下，我们实际上如何构建结构？Cloud 究竟是如何知道该做什么的？事实上，这主要取决于 Cloud。如果你赋予 Cloud 访问 GitHub 仓库的权限，这些仓库最终都会挂载在 Cloud 运行的容器内部。
这样，Cloud 就可以做出决策。如果你有一个很好的构建配置和清晰干净的依赖树，Cloud 可以使用它想要的任何工具在容器内检查这些依赖关系。而如果你使用的是像 ABC 这样的纯文本语言，它没有非常明确的依赖映射，或者构建该图并不简单，那么 Cloud 可能不得不通过搜索文件中的符号等方式来处理。
对于你拥有的每个 PR（拉取请求）审查，你都必须在容器上重新挂载仓库。是的，这就像一般的 CI（持续集成）任务一样：你需要先在 Git 仓库上执行检出操作，然后才能对其采取行动。那么问题是，如果你能够提前构建出依赖图，这是否有助于优化流程？答案是肯定的。
如果你有某种代表依赖图的表示形式，并且知道提前生成它会花费很长时间，你可以将其作为文件上传到会话中。我们平台支持一般的文件上传功能。然后你可以告诉 Cloud：“顺便说一下，你关心的完整依赖图位于这个文件路径。”
那么问题来了：这些多智能体拓扑结构中嵌套的层级有多少限制？目前实际的答案是只有一层嵌套。我们不支持像超大规模扇出那样任意复杂的拓扑结构。虽然我们在未来某个时候可能希望支持这一点，但我们需要确保安全性等一切内容都真正稳固。
我先试着重新表述一下这个问题，请告诉我我理解得是否正确：基本上是说，有一些身份验证或数据访问权限在你的本地机器上无法获取，因为它们位于 VPN 后面。这些数据是否可以通过任何内部 MCP（模型上下文协议）服务器访问，还是只能在本地机器上访问？好的，我明白了。
因为抽象处理这种情况的方式是使用我们称为 MCP 隧道的功能。这基本上是一种让你通过 Cloudflare 隧道为平台上的智能体提供私有 MCP 访问权限的方法。这基本上是一种让你在不通过公开互联网暴露任何内容的情况下提供访问的方式。我认为这可能是最接近你想要做的，或者是你需要为这些内容获取访问权限的做法。
是的，连接是直接从你的私有 MCP 服务器运行的地方到发生 MCP 调用的地方的。所以我会建议你研究一下这个。第二个问题关于 Anthropic 内部的工作方式。我们基本上非常推崇 Claude Tag，它为我们自主完成了大量工作。
对于那些查看 Jira 以及过去 24 小时内的所有活动，甚至主动提出对工单的更改建议的工作负载。我们通过类似 Claude Tag 形状的东西完成了大量此类工作。是的，Claude Tag 支持这一点。
是的，Claude Tag 可以做到这点。我想如果你只是说“在每天早上 6:00，执行这个操作”，我认为它会开箱即用。非常感谢大家的关注，不胜感激。也感谢各位。好的。（掌声）