00:00:00Opus 4.6 是 Anthropic 唯一的升级吗？
00:00:03你们已经了解子代理（sub-agents）了，即每个代理作为一个独立的实体运行，
00:00:07拥有各自的上下文窗口。
00:00:09但当任务需要它们之间进行协作时，这些子代理就失效了。
00:00:13在这种情况下，编排者必须介入，获取一个代理的响应并将其委派
00:00:17给另一个代理，或者代理必须依赖项目文件夹中的笔记。
00:00:21由于这种沟通鸿沟，简单的任务也会变得过于复杂。
00:00:25为了解决这个问题，Anthropic 对子代理发布了一项新升级，并将其命名为“代理团队”（Agent-Teams）。
00:00:30它们是随 Opus 4.6 一起推出的。
00:00:33虽然这仍然是一项实验性功能，但我们已经将其应用于多个工作流程中，
00:00:37而最大的改进在于完成这些任务所花费的时间大幅减少了。
00:00:41但它之所以是实验性的，是因为仍有一些不完善之处，我们也找到了解决这些问题的小方案。
00:00:44这些问题的解决方法我们也已经掌握了。
00:00:47“代理团队”的核心理念是让多个 ClaudeCode 实例协同工作。
00:00:51团队的每个成员负责独立的任务，并由一个代理进行中心化管理。
00:00:55由一名代理控制。
00:00:56现在，你可能会觉得这听起来与现有的 Claude 子代理非常相似，因为
00:01:00两者都并行运行并拆分任务，但它们并不相同。
00:01:03这是因为“代理团队”解决了子代理框架存在的一个核心问题。
00:01:08子代理无法直接相互通信，必须依靠编排者代理
00:01:12作为它们之间的沟通媒介。
00:01:15而团队成员之间则能够直接沟通。
00:01:18“代理团队”的核心概念是让多个 ClaudeCode 会话协同工作。
00:01:22一个会话担任团队负责人，负责协调工作、分配任务并综合结果，
00:01:27而团队成员则在各自的上下文窗口中独立工作。
00:01:31子代理拥有自己的上下文窗口，并将结果报告给调用者。
00:01:34但对于团队来说，运作方式有所不同。
00:01:36代理团队的每个成员都是一个完全独立的终端会话。
00:01:40它们不受仅负责分发任务的编排者限制或协调。
00:01:43相反，这些终端会话由主团队负责人开启和关闭。
00:01:47它们能够处理需要代理之间讨论和协作的任务，
00:01:52因为它们具备沟通能力。
00:01:54所以，一个代理团队本质上由一名团队负责人和若干团队成员组成。
00:01:57团队负责人是创建团队并协调其工作的主代理。
00:02:01团队成员则是实际执行任务的工作者。
00:02:03每个团队成员都会收到一份任务列表，这是一个共享的项目列表。
00:02:07每个成员从中识别出自己需要做的事情并执行。
00:02:10为了进行沟通，它们还有一个共享邮箱，允许它们互相发送消息。
00:02:15那么问题来了：如果每个团队成员都是独立的，这到底是如何运作的？
00:02:19它们如何知道其他成员在做什么？
00:02:21这是因为所有关于团队、成员以及每个成员正在处理的任务信息，
00:02:26都存储在本地的 .claud 文件夹中，并通过任务名称进行识别。
00:02:30此功能仍处于实验阶段，且默认禁用，因此在此阶段
00:02:34在处理团队成员时可能会出现一些漏洞。
00:02:36为了进行尝试，我们必须手动启用它。
00:02:38我们通过将 Claude Code CLI 的实验性代理团队标志设置为 1 来实现。
00:02:43启用此 CLI 标志后，代理团队即可在后续会话中使用。
00:02:47有了这个标志，我们就能访问 Claude Code 中的团队功能。
00:02:51由于这是实验性功能，我们需要使用特定的措辞来告诉
00:02:55Claude 我们希望使用代理团队来执行某项工作。
00:02:58我们的团队已开始使用此功能来并行化代码审查，让代码问题
00:03:02在被发现的同时得到修复。
00:03:04为此，我们要求 Claude 使用一名团队成员在代码库中查找问题，
00:03:08并使用另一名成员来修复第一名成员发现的问题。
00:03:11我们必须在提示词中详细说明，以使其遵循正确的方向。
00:03:15现在，如果是子代理在处理，它们会把报告写进某个物理文件，
00:03:19以便让其他代理知道要修复什么。
00:03:21但在这里，我们希望通过省去写入本地文件的开销，
00:03:26来加速审查过程。
00:03:27当我们向 Claude Code 发出提示时，团队成员便产生了，每个成员都受
00:03:31团队负责人的控制。
00:03:32负责人将提示词分发给各个代理，告知它们要执行的任务。
00:03:36首先，代码审查代理开始工作，在分析任务后，它逐个 Bug 地
00:03:40向代码修复代理共享消息。
00:03:42该代理优先处理关键的安全问题，一旦代码修复代理收到
00:03:47来自代码审查代理的消息，它就开始实施修复，而代码审查代理
00:03:51则继续寻找更多问题。
00:03:53同样，它们保持对话，并汇报已实施的更改。
00:03:57关键问题处理完毕后，两名代理开始着手修复
00:04:01中等优先级的问题。
00:04:02代码审查和修复是同步进行的，这节省了大量时间。
00:04:06这种方式的好处在于，你还可以为团队成员分配或修改任何任务。
00:04:10通过启用此功能，你可以引导特定团队成员的工作方向。
00:04:14代理完成工作后，控制权将交还给主代理，
00:04:18主代理负责确保所需的更改已正确实施，并负责
00:04:22优雅地关闭这些代理，确保它们的退出不会在以后引起错误。
00:04:26你可能已经注意到我们在这些视频中制作了很多东西。
00:04:28所有的提示词、代码、模板，也就是那些你通常必须
00:04:32暂停视频并从屏幕上复制的东西，都在我们的社区里，包括本视频及
00:04:36之前的所有视频。
00:04:37链接在描述栏中。
00:04:38大规模地发现和修复问题是一件好事，但经常会遇到
00:04:43出现问题却无法查明原因的情况。
00:04:45在这些情况下，我们可以使用代理团队来测试同一个应用的多个维度，
00:04:49并逐步逼近 Bug。
00:04:51这样，团队成员可以相互交流发现，并共同推进。
00:04:55我们要求 Claude 在代码库中查找一个 Bug，并指定使用多个团队成员，
00:04:59让他们从不同的角度切入问题。
00:05:02随后它生成了四个子代理，每个都专注于同一应用的不同维度。
00:05:06它们从团队负责人那里收到类似的提示，并根据其负责的
00:05:09特定方面调查错误，而主负责人则等待它们完成，
00:05:14然后分析它们的调查结果。
00:05:16如果没有团队模式，我们将只能使用单线程，那会耗时得多。
00:05:19但有了这些代理，过程就快得多了。
00:05:22调查很快就完成了，所有代理的调研工作在大约
00:05:272 到 3 分钟内完成，相比于线性检查，这是一个显著的进步，
00:05:31线性检查通常需要 5 到 10 分钟。
00:05:33需要注意的一点是，这种方法会消耗大量 Token，因为每个代理都有
00:05:37独立的上下文窗口，所以我们需要谨慎对待。
00:05:40代理返回输出并关闭后，团队负责人还会通过
00:05:45自行检查来核实结果。
00:05:46所有四个代理都指向了同一个 Bug，并正确地指出了
00:05:50useEffect 中闭包过期（stale closure）的问题。
00:05:52这部分内容被所有四个代理同时标记了出来。
00:05:54另外，如果你喜欢我们的内容，请考虑点击“赞同/推荐”按钮，因为这能
00:05:59帮助我们创作更多此类内容，并触达更多受众。
00:06:02这个代理框架改变了我们处理长周期任务的方式，因为凭借这些能力，
00:06:07代理不再仅依赖于记录它们的进度。
00:06:10通过代理团队，我们可以并行处理应用的各个方面，
00:06:14并专门派出一名成员负责调研。
00:06:16当我们给 Claude 发出提示词时，它生成了 6 个代理。
00:06:19其中两个负责调研和打基础，其余的负责构建
00:06:23页面内容。
00:06:24构建代理被负责打基础的代理阻塞了，因为后者负责
00:06:28安装所需的包，并准备好带有所有依赖项的环境。
00:06:32每个代理都收到了定义其职责的特定提示词。
00:06:35被阻塞的代理会一直等待团队负责人的“解除阻塞”信号。
00:06:38一旦调研和基础工作完成，剩余的代理即被解除阻塞，并开始
00:06:43并行实施各自的应用部分。
00:06:46它们之间保持沟通，以确保各组件之间的一致性。
00:06:49团队负责人持续协调代理，一旦有代理完成任务，负责人就会
00:06:53向该代理发送关闭消息，优雅地处理其退出。
00:06:57整个过程消耗了大约 170k 的上下文窗口 Token，但最终，
00:07:02我们仅凭一个提示词，就完全按照预期构建出了应用。
00:07:05如视频中所述，当我们的团队测试此功能时，我们发现了几种
00:07:09让代理团队更好地为我们服务的方法，同样，这些最佳实践
00:07:13可在 AI Labs Pro 中获取，你可以亲自尝试。
00:07:16第一个建议通常适用于所有代理，不限于
00:07:20代理团队功能。
00:07:21你需要明确指定代理应当工作的范围。
00:07:25你可以通过在提示词中定义，指定执行任务时需要查看哪些文件，
00:07:29或者在项目中创建包含独立任务的文档来实现。
00:07:33就像我们在工作流中所做的那样，我们为每项分配准备了正式的任务文档，
00:07:38以便代理可以在正确的范围内独立工作。
00:07:41另一件需要记住的事是，每个代理应处理相互独立的
00:07:45任务，因为如果它们同时编辑同一个文件，
00:07:49就会产生冲突，并可能导致内容被覆盖。
00:07:52除此之外，有时我们发现，如果某个代理花费了很长时间才完成任务，
00:07:56主代理会变得“不耐烦”，转而开始自己执行该任务，
00:08:00而不是等待团队成员完成。因此，务必提醒主代理
00:08:04在继续下一步之前等待团队成员完成任务。
00:08:06你还需要合理划分任务的颗粒度。
00:08:08如果你分配的任务太小，会产生协调开销。
00:08:11如果任务太大，则会增加努力付诸东流的风险，所以任务需要均衡
00:08:16且自包含。
00:08:17最后，你需要监控代理的工作。
00:08:19如果任何代理的表现不符合预期，你可以停止它的执行，并给予它
00:08:23关于它应该做什么的新指令。
00:08:25遵循这些实践会让这个实验性功能的使用变得更加有效。
00:08:29视频到这里就结束了。
00:08:31如果你想支持本频道，并帮助我们继续制作此类视频，你可以
00:08:35通过点击下方的 Super Thanks 按钮来实现。
00:08:38一如既往，感谢观看，我们下期再见。