好的，让我们看看这具体是什么样的。分析谷歌和微软的情况。理想情况下——希望现场演示能顺利成功——主代理会评估它是否拥有相关信息，然后提供一个自定义工具。我们将利用该工具为每项金融数据资产启动独立的会话。大家会看到“调度分析”这一环节，它将为两只股票代码调用该工具，并为每只代码启动运行任务。这就是我们编排多会话的方式：每个会话都包含执行协作工作的多个代理，并且每个会话都有结果定义，从而利用记忆库实现自我监督，让各个部分相互学习。
接下来我们进入压轴环节：如果你想进行重复性工作该怎么办？比如你有一组关注的公司名单，希望每天上午九点或每月一号自动对这些公司进行分析。这就是“部署”的功能。部署的一切都是基于 API 的。虽然你可以通过控制台与平台交互，但我们主要期望你通过 API 和 SDK 来使用它。你可以构建自定义界面和工作流，所有这些模块都是可以组合在一起的积木块，用于将你的应用构建成更庞大的系统。
在这里你可以看到 Claude 创建了一个部署项，就在右侧。部署接收代理定义（在本例中是“研究桌每周备忘录”使用的特定代理）、运行时间表以及初始消息集。你还可以传入资源，如记忆库、GitHub 仓库或文件供其每次运行时使用。这意味着每月一号下午一点左右，它将运行这个特定的会话。我现在就可以触发它（通过控制台），或者你也可以为其构建一个界面，就像我们在这里做的那样。我可以列出和搜索我的部署项，并在任意时刻启动一个。
我不确定为什么它们失败了，但我稍后会询问 Claude 关于“梦想”（Dreaming）和自我改进的问题。在我回答大家可能有的许多问题之前，我要展示一下“梦想”功能的预览版。“梦想”功能允许你选择一个记忆库（这里使用我们一直在用的那个），选择模型，并可以给予自定义指令（但我们使用默认提示词）。然后让它通过流式分析处理过去 30 天的会话记录。点击“开始流式传输”后，它会启动一个使用管理代理的会话，实际上会启动许多子代理来分析其他被要求评估的会话转录本。
这些会话都使用了记忆库。“梦想”功能会分析：记忆库是否编码了所有必需的信息？会话运行中是否出现了导致问题的错误？我们能从中吸取什么教训吗？这种情况是否多次发生？我们是否可以更新指令以作改进？实际上，它发现我们要创建的“技能”在编写方式上存在几个空白之处。因此，它更新了记忆库，告知即使有该技能，也应结合我们从中学到的知识来扩展这一认知。
我们可以想象，未来我们将不仅改进记忆库，还会直接改进技能、代理提示词和子代理提示词等。演示到此结束，抱歉网络有些不稳定，希望大家回家后能跟上进度。让我们继续回答问题环节。“好的，我们可以接受提问。”“这边有个问题。”“是的，请讲。”“谢谢演示。我们没有看到代理中的遥测（telemetry）或仪器化内容，这是默认的原生功能吗？”
“你所说的遥测是什么意思？因为你可以完全观察到发生的所有事件。进入控制台可以看到实时数据，当然也可以通过 API 获取。虽然转录视图是一个不错的展示方式，但如果进入调试模式，可以看到该会话中发生的每一个事件。例如，你可以精确看到何时开始调用模型、何时结束调用，从而获取延迟指标等数据。你所说的遥测是指其他方面吗？”
“嗯，问题在于通常在软件开发周期中，你会定义想要观察的内容。你们是如何决定要观察什么的？”“目前你可以获取所有事件并在你的端进行过滤。如果你认为缺少某些内容，请告诉我们，我们会讨论添加它们。”“好的，我可以引入自己的可观测性栈吗？你是说导出到 OTEL（开放遥测标准）？”“是的，因为它是 API 形式，你可以相当容易地构建那种连接器。我们不想强加特定观点，因为每个人的需求不同，但一切都是 API 调用。”“谢谢。”
“我们还有一个问题。我有一个疑问：这些代理能运行多久？我知道你提到了‘梦想’功能，但你能让它们无限期运行吗？还是说持久化存储会不断增加大小，最终需要离线重新压缩？”“我们正在为你运行压缩功能，以便你可以让代理连续运行数天。我们的一些用户在生产中已经看到了长达 10 小时的会话。”“所以理论上，你可以让代理运行一年或无限期？”
“是的。你是指让代理连续运行一年，还是指一个特定的会话持续进行……”“不，基本上是说，如果我有一个需要每天执行的任务，我可以让它连续运行六个月吗？它不会耗尽持久化存储吧？”“没错。”“那么，有没有像编排这样的机制，比如我有三个代理：A 做某事并委托给 B 和 C？这是你们具备的能力吗？”“目前，你需要……”
你会使用子代理，并告诉 Claude 你想要什么。我们发现人类有一种约束 Claude 的行为及其方式的欲望。随着 Claude 变得越来越智能，我们将不断移除这些护栏，让 Claude 自由发挥，让它做它认为最好的事情。所以目前你认为三个子代理可能是最佳拓扑结构。但如果我们让 Claude 自己决定，它实际上最终表现会更好。
但是这里的 UI 中还没有任何基于拓扑或图的工作流功能，比如我可以…… 还没。还没。还没。但也许很快会有。 呃…… 你可以大声一点说。是的，抱歉，抱歉。我们会回到你的问题上来。
很抱歉刚才的干扰。 嘿，你右边这位朋友。 在我右边？好的，是的。所以有个问题。嗯……
看起来很棒，有很多集成点。我很好奇的是，对于可能管理多个代理的复杂组织来说……我认为他们希望有一些分离、仲裁或其他机制。那么，对于拥有不同代理的复杂组织来说，什么是有效管理这些代理的建议方法呢？
我们目前的基础单元是工作区（Workspaces），你可以将不同的客户放入不同的工作区，从而以这种方式进行细分，并授予特定用户访问这些工作区的权限。但我们知道目前提供的功能仍有差距……这也是我们路线图上的内容。所以我们确实希望提供更细粒度的控制，但目前工作区是一种清晰分离代理的方式：你可以有一组人访问工作区 A，他们可以访问其中的所有代理；你也可以设置工作区 B，拥有不同的用户集和不同级别的权限。
所以你好，精彩的演示，非常兴奋。我有两个问题。第一是部署（Deployment）。我的理解是，部署就像是所有代理在某一时刻的快照？ 不。部署本质上是一种让你为特定代理按计划运行会话的方式。你可以说“研究桌代理，每季度去调研一下 NVIDIA”，它就会每个季度创建一个会话来进行调研并生成报告。而记忆（Memory）是一种状态，会跨所有会话持久保存。
没错。 你将记忆存储附加到会话上。所以你可以决定将哪个记忆存储附加到哪个会话。因此，记忆存储是一个独立实体，你只需在需要时将其附加即可…… 对。最后一个问题是关于 Harnesses（工具链/框架）。第一，Harnesses 是做什么的？因为每个人对它的定义都不同。第二是关于置信度（Confidence）。所以当我在这里更改某些内容时，我怎么知道它…… 没有按预期工作？对吧？作为开发者，我如何建立自己的信心。
嗯，你说得对，每个人对 Harness 的定义都不同。当我们在 Anthropic（注：原文CMA推测为Anthropic口误或特定语境缩写，结合上下文指代平台方）谈论 Harness 时，我们主要指的是工具循环执行。即管理上下文和管理会话状态，确保代理能够完成它想做的工作。当大多数构建者谈论 Harness 时，他们通常指的是协调多个代理和会话作为一个工作单元的能力，以实现某种更大型的任务，并以拓扑结构的形式呈现。我们正在为你提供“单个会话”作为工作单元的抽象概念，你可以利用它以及会话这一基础单元来构建你自己的 Harness。
嗯…… 然后是你关于如何知道代理表现的第二个问题？我们最好的建议是在你的代理上运行评估（Evals），使用不同类型的任务，看看代理在这些任务上的表现。Outcomes 是一个非常好的方法，我们可以引导代理为你获得特定的结果，你可以定义一个精确的评分标准（Rubric），比如“这是我想要的确切结果”，并设置最大迭代次数，代理将持续运行直到获得该结果。
是的，就是加布（Gabe）提到的验证器代理。 你好……所以……之后？ 酷。嘿，谢谢演示，我很享受。嗯，我核心的问题有点关于如何在技能和代理之间做出选择。我想问你们大家认为根本区别是什么？围绕代理的 Harnessing 是否有什么优势，使其产生的结果比技能（Skill）更好？我问这个原因之一是我害怕总是投资于新的……我想说是围绕模型的 Harnessing 和工具，这一直尝试新东西可能有点累。嗯，所以是的，我只是想听听你们的想法：区别大吗？它会很快改变吗？
嗯……厚 Harness、薄技能，这是一个不断演变的问题。我认为我们发现的是，随着 Claude 变得越来越智能，我们希望给予 Claude 的边界和帮助开始融化并消失。所以今天你需要的东西可能不是明天所需要的。无聊的答案是只是运行评估来评价这些东西。这听起来显然很令人疲惫，是的……每次新模型出来时我都需要评估所有这些内容。
我们认为技能在今天是一个很好的抽象，它给予模型足够的信息去做它需要做的事情。但我推测它将开始转变、融化并变得越来越薄，最终模型将能够在没有特殊请求和指令的情况下自行做事。所以在我看来，多代理似乎更有用……但你的具体情况可能因任务而异。
你好。 嘿，嗨。所以我的问题与最后两个问题相关，特别是关于评估（Evals）。让我兴奋的一点是“做梦”（Dreaming），但做梦实际上会如何影响最终结果？ 这就是评估介入的地方，但你可能会有多次迭代的“做梦”循环，它们可以朝不同方向发展。所以有计划吗？或者你们已经支持某种自动化的“做梦”功能，通过运行评估并查看结果……嘿，不同的方向如何进入？我们应该根据正在发生的事情选择哪一个？
是的。所以“做梦”所做的是……你可以选择代理进行“做梦”的持续时间。比如你说我想让这个代理会话在过去 30 天内进行回顾，然后查看所有转录记录并分析你试图实现的任务，接着提出一个新的记忆存储，使其更侧重于……你当时正在尝试做的事情。我们通常会在后端运行评估来
确保“Dreaming”能为你提供更好的结果。我们看到客户通过运行 Dreaming 然后使用新的记忆服务器，在评估指标上获得了显著提升。但归根结底，一切都与评估（eval）相关。这就是你判断某项功能是否如预期表现的方式。
是的，我认为拥有自己的一套评估标准会很好。“Dreaming”目前处于研究预览阶段。这就像是一个大型实验项目，我们通常看到它带来了提升。大家关心的是如何建立信心？这就像将评估与 Dreaming 连接起来，我们可以发现多种路径。例如，虽然九个会话可能说“这是错的”，但一个会话说“这是好的”。如果你只依赖那个会话，我觉得我们可能无法捕捉所有见解。如果我让你相信我呢？（笑声）谢谢。
大家好，非常感谢。这令人印象深刻。那些使用 Claude Code 一年或更久的人一直在做类似的事情，但看到它以如此成熟的形式呈现很好。我有一个问题：其中有多少是直接构建在 Claude Code 之上的？也就是说，如果有雄心壮志的人，他们能否构建类似的东西？我还想鼓励你们保持开放。有些人已经在利用 JSON 会话文件中的数据，并开始实验使用像 HePo 这样的工具来管理记忆和创建记忆池。恭喜你们，谢谢。请保持开放。另外，有没有什么不是基于 Claude Code 构建的部分？
我们借鉴了 Claude Code 的框架作为灵感。我们发现它非常适用于编码任务，但对于其他任务有不同的灵活性层级。我们正在构建一个 API，让你带入自己的上下文、信息和能力并在其基础上构建；而 Claude Code 则是试图提供一个开箱即用的产品。所以我们的价值主张略有不同，它不是完全封闭的盒子，尽管理想情况下它在各种任务上的表现至少一样好甚至更好。这肯定受到我们从 Claude Code 看到的提升的启发和激励。
Claude Code 是一个终端工具，而我们显然希望成为一个可扩展、可靠的 API 产品和基础设施。我们在演示开始时提到的那些挑战中投入了大量工作，以确保为大家提供一个非常稳固的产品来使用。
对于 Bedrock 来说，有像这里这样的控制台吗？这是一个相当直接的问题，我只是想管理和查看所有内容。
这在 Bedrock 上不可用，但在 AWS Cloud Platform 上是可用的。因此有一个适用于该平台的控制台版本供你使用。
好的。还有一个问题：在使用模型方面有限制吗？比如非 Anthropic 的模型……就像 Claude Code，我可以运行非 Anthropic 的模型吗？
目前仅限云模型。
好的，那么第二个问题是关于最终用户的使用：他们必须拥有控制台账户才能使用它吗？还是说我可以为这个创建一个自定义 UI，然后让他们直接使用？
Cloud Console 帮助你创建 API 密钥。这就是你访问我们 API 的方式。注册 Cloud Console 是免费的，不需要单独付费。你创建 API 密钥，然后根据令牌使用量进行支付。
对于像 SaaS 这样的案例，比如我们有多个租户的情况……为了提供这种代理服务，你们已经部署了什么样的模型？以便我们可以遵循。例如，每个公司或租户是否应该有不同的空间？或者是否有针对此的子模块用于每个租户？我们实际上将如何组织这一点？
我们看到，对于多租户的最佳模型不是“自带密钥”（BYOK），因为你会失去可观测性，因为它运行在你的最终用户的 API 密钥上而不是你的。因此我们鼓励你使用工作区（workspace）作为租户原语来建模事物。我们正在改进这一点，以便更容易在此基础上构建多租户应用程序。
是的，所以我认为目前你可以将所有客户数据放入单个工作区中，然后在你的端维护一个映射关系，记录哪个代理对应哪些客户。或者像 Gabe 所说，你可以为每个客户创建一个工作区，但这可能会更复杂，因为你必须重新创建你的代理。
你们是否看到人们在这个工作区之上添加了额外的安全层或 RBAC（基于角色的访问控制）层？对我来说，这可能有点……
是的，那可能是一种目前很好的做法，因为我们除了工作区级别外没有其他 RBAC 控制。你工作区内的一切对该工作区的每个人都是可访问的，但我们正在努力改进我们的 RBAC 并提升体验，特别是当你代表客户构建基于云管理代理的应用时。
那么有没有办法展示如何扩展这一点？如果有多个租户在操作……
是的。
是否有任何缩放参数，比如最小的 Pod 或其他这些参数？
我的意思是，你可以定义它。你想创建多少个会话都可以，没有限制。当然我们有一些速率限制，但没有让你说“现在我需要运行 10,000 个 Pod”这样的缩放参数。
目前还没有像 Kubernetes HPA（水平自动伸缩）那样的东西，你可以设置超时等缩放参数吗？
你不需要那样。因为你不需要担心，我们为你管理一切，你只需进行 API 调用而已。
好的，谢谢你的回答。顺便说一下，我提供的链接无法工作。
对于我来说，我不确定这是否是唯一的方案。>> 是的。谢谢你的分享。>> 谢谢。谢谢。>> 好的，请继续。
大家好。首先非常感谢。我一直对你们发布的所有内容感到非常兴奋（玩得很开心），而且我对你们如何使用 UI 非常感兴趣。嗯，你们正在启动一个服务器并分发它，但我们如何部署呢？无论是内部使用，还是面向客户群体。例如，如果我想制作一个占星师的应用程序 >> 嗯，用户需要输入敏感数据。所以对我来说，能够拥有这样一个层级结构真的很好 >> 拥有一个保护层。是的。>> 因此有一些流程性的事情，比如星盘示例。虽然我没有构建这个，但这作为一个例子很好：我可以有一个子代理进行解释，这个过程可能持续约 90 秒。它可以创建一些资产等。当结果达成时，它可能会关闭。所以这给了我一种方法来实现非常干净的部署，我只需要开启 >> 然后一切都可以从这里启动。>> 是的，完全正确。
因此有一些类似 MCP（模型上下文协议）通道的东西指向这里，比如使用假聊天作为示例，这是一种让你能够使用 Claude 并通过 UI 与其通信的通道。但我看到很多情况下，你只是在项目内部启动一个服务器，这很容易在内部分发。但如何大规模部署呢？>> 嗯，我的意思是，我们目前已经在生产环境中以规模部署了这一点。例如，Notion 的外部代理就是基于此构建的。所以这是今天存在的东西，你可以去使用它，并基本上通过 Notion 利用云托管代理，例如用于 Atlassian Jira 集成。嗯，肯定有方法可以做到这一点。我认为如果你有具体问题我们可以讨论 >> 是的，我们可以在会后讨论，但通常你可能会构建你要分发给客户的产品和 UI，然后调用我们的 >> 短语 >> 管理一切通过 API >> 所有这些都是正确的 >> 所以你将管理所有的 API 调用，并围绕这一点构建你的产品和 UI。
大家好。首先感谢这次精彩的研讨会和演示。我的问题并不是针对代理本身，而是就像我看到 Android 刚刚发布了 Sunet Five（注：此处音译或误听，可能指特定模型版本）。是的。>> 所以我只是想知道你们是否有任何可以与我们分享的信息。是的。>> 这是一个很棒的模型。>> 是的。（笑声）>> 试试看。它支持云托管代理。去试试吧。你今天就可以使用并查看效果。
大家好。嗯，如果我们有商业合作伙伴今天正在使用类似云协作（Cloud Co-work）的工具，其中一些技术能力较强的用户会使用 Cloud Code 为特定的业务案例构建一些点对点解决方案。>> 你认为开始使用托管代理（Managed Agents）的成熟度水平大概是什么，因为这似乎更强大 >> 但是你知道，对于非工程师来说，云平台可能会让人感到 intimidating（望而生畏/难以驾驭）。是的。我认为控制台的快速入门可能是我演示中的一部分，你基本上就像是在告诉 Claude 你要构建的代理应该做什么，这会让即使是非技术用户也能轻松进入并构建他们的第一个代理。但显然这是一个 API 产品，自然会稍微让人感到有些 intimidating。但如果他们熟悉 Cloud Code，我们确实有一个与 Cloud Code 配合使用的托管代理技能（Skill），基本上就像用自然语言引导你构建你的第一个代理。这大概是我的建议，去试试看。我认为最大的区别在于 Co-work 是构建个人代理。而这个则是试图构建一个可能面向你的团队、内部组织可用的代理，或者你正在构建要交付给最终客户的产品。但如果你是在构建个人代理，Co-work 仍然是一个非常棒的工具来继续这样做。
是否有某种技能可以将从 Co-work 中存在的某些东西迁移过来？有一种与我们 API 交互的技能。所以那个 Cloud（可能指某种工具或环境）大概就足够了。所以说“这是我之前在 Co 中做的，这是调用 API 的技能”，进行翻译我觉得相当有信心。是的，我们会为你搞定它。>> 嗯，我的问题是关于企业级的。有很多企业希望将这些东西在内部运行，因为他们有敏感的数据集不希望外泄；此外他们可能已经设置了自己的安全代理来访问 Anthropic 的模型，比如 GCS（Google Cloud Storage）等。还有另一个关于扩展性的问题：在企业内部，你现在可以分配计算资源以我们自己的方式对其进行缩放。那么这种本地部署（on-prem）的解决方案，你们考虑过吗？>> 嗯，这肯定是一部分企业客户的客户需求，我们目前正在认真思考并考虑这一点。但我们目前还没有可以分享的东西，不过我们正在认真地考虑它。
打扰一下。你能展示显示研讨会二维码的最后一张幻灯片吗？>> 嗯，你在找仓库（repo）还是积分/学分？>> 是仓库。好的。是的。