1
00:00:00,000 --> 00:00:08,079
好的，我们首先删除 review.md 及其愚蠢的.env 担忧，将其移至垃圾箱，

2
00:00:08,079 --> 00:00:14,319
好了，关闭这些文件，现在我们将回到这里的代理那里看看

3
00:00:14,319 --> 00:00:19,520
如果我们不能改进这一点。好的，我刚刚粘贴了一个名为 Codex 的新版本

4
00:00:19,520 --> 00:00:23,760
审稿人。我还更改了文件的名称，使其美观、干净。你执行一个

5
00:00:23,760 --> 00:00:29,440
根据 Codex 的要求，对 plan.md 进行全面审查。您正在使用不同的 AI 代理

6
00:00:29,440 --> 00:00:34,720
对文件规划 plan.md 进行审查。您必须执行以下 shell

7
00:00:34,720 --> 00:00:40,240
命令进行审查。不要检讨自己。我对此非常清楚。好的，

8
00:00:40,240 --> 00:00:53,759
有了这个，让我们启动克劳德。好的，使用您的 Codex-Reviewer 子代理进行审核

9
00:00:54,319 --> 00:01:03,599
规划斜线计划.md。这看起来很清楚。让我们看看会发生什么。让我们看看会发生什么

10
00:01:03,599 --> 00:01:09,440
当我们这样做时。它在思考，它在庆祝，它被称为 Codex Reviewer。会做吗

11
00:01:09,440 --> 00:01:17,199
这？它正在读取 plan.md 本身，但它会启动 bash 命令吗？它会踢

12
00:01:17,199 --> 00:01:23,919
off 则运行 Codex。让我们看看 Codex 执行。看起来不错。是的，我们会让它运行。好的，

13
00:01:23,919 --> 00:01:30,639
Codex 现已运行。所以我们在 Claude Code 中运行一个子代理，这就是启动 Codex，

14
00:01:30,639 --> 00:01:36,879
现在它基本上是作为子代理运行的。我们使用不同的法学硕士真是太酷了

15
00:01:36,879 --> 00:01:46,000
以及一个不同的 LLM CLI 作为此过程的一部分。感觉很亚代理。所以这将会发生

16
00:01:46,000 --> 00:01:51,440
现在。 Codex 正在后台运行。我们会让这一切完成，所有的事情都完成

17
00:01:51,440 --> 00:01:56,480
两者之间的来回不会污染上下文。所以我们会以非常快的速度回来

18
00:01:56,480 --> 00:02:02,959
有效的方式，刚刚由 Codex 写入 review.md 的代码审查。我们就这样吧。

19
00:02:02,959 --> 00:02:09,839
我们收到了回复。这里有大量的反馈。我们去看看吧

20
00:02:09,839 --> 00:02:19,600
在审查时。它有一些优点，仅此而已。一些风险、差距。它关心的是

21
00:02:19,600 --> 00:02:24,559
技能没有被定义，但它已经被定义了。没关系。那是因为它只是看着

22
00:02:24,559 --> 00:02:31,839
该文件就在那里。它关心多边形。我们对此没意见。那不

23
00:02:31,839 --> 00:02:41,279
对我来说似乎是一个问题。好的。没有明确的，我想这很好。作者无意，是的。

24
00:02:42,080 --> 00:02:50,160
定价模型假设，看起来不错。好的。它不知道这一点

25
00:02:50,160 --> 00:02:56,720
显然，massive 是 Polygon IO 的新名称。总的来说，这是一个强有力的蓝图，应该

26
00:02:56,720 --> 00:03:01,919
启用并行执行。它几乎不知道这是第一个迹象的一部分

27
00:03:01,919 --> 00:03:08,320
并行执行。很不错。所以我们有这样的独立性真是太酷了

28
00:03:09,199 --> 00:03:15,360
另一个法学硕士去做这个分析，我们将所有这些打包到一个运行的子代理中

29
00:03:15,360 --> 00:03:19,600
在克劳德代码中。可能是克劳德，也许你只是坚持使用克劳德

30
00:03:19,600 --> 00:03:25,360
审查，那是完全好的。但这就是我们正在做的事情。好的。只是为了让这成为

31
00:03:25,360 --> 00:03:32,160
更有趣一点，我现在要改变这一点，不是审查 Planning.md，而是审查

32
00:03:32,160 --> 00:03:38,399
自上次提交以来的所有更改，使其成为一种更通用的工具。我只是要去

33
00:03:38,399 --> 00:03:43,199
称之为审稿人。我将使用 Codex，但您也可以使用 Claude Code。你不

34
00:03:43,199 --> 00:03:48,559
需要使用法典。我有点喜欢这样做，以将不同的法学硕士的想法融入其中，

35
00:03:48,559 --> 00:03:54,720
但这不是必需的。好的。所以我将其更新为change reviewer.md，更改reviewer。

36
00:03:54,720 --> 00:03:59,360
你可以看到它将对自发布以来的所有变化进行全面审查

37
00:03:59,360 --> 00:04:04,720
最后一次提交。该子代理使用 shell 命令检查自上次提交以来的所有更改。

38
00:04:04,720 --> 00:04:11,039
现在，我再次强调，您应该使用 shell 命令调用 Codex 来完成这项工作

39
00:04:11,039 --> 00:04:16,559
而不是自我检讨。但你可以告诉它自己进行代码审查。那会很有用的。

40
00:04:16,559 --> 00:04:20,799
克劳德·科德也很擅长。但如果你也有 Codex，那么这是一个有趣的方式

41
00:04:20,799 --> 00:04:26,239
让不同的法学硕士合作，参与这个过程。这就是我正在做的事情。

42
00:04:26,239 --> 00:04:34,000
我现在要从克劳德密码中走出来。然后我将再次发射克劳德。

43
00:04:35,679 --> 00:04:43,200
现在我要说使用，哦，我要删除review.md，删除。我不记得了

44
00:04:43,519 --> 00:04:51,519
自上次提交以来发生了什么变化，但我确信它可以。使用变更审阅者子代理

45
00:04:52,720 --> 00:05:02,480
查看自上次提交以来的更改。我们会看看那里会发生什么。但希望它会消失

46
00:05:02,480 --> 00:05:09,279
使 shell 命令调用 Codex。然后我们就会有一个更新，就这样。你

47
00:05:09,279 --> 00:05:16,480
可以看到它已经打开，正在等待执行。然后这将导致 Codex 写入一个文件，

48
00:05:16,480 --> 00:05:21,839
或者在你的情况下，也许是克劳德，将进行代码审查。而这显然是

49
00:05:21,839 --> 00:05:27,200
开始为多代理编排奠定基础。

50
00:05:27,200 --> 00:05:32,640
现在已经完成了。它对我来说确实使用了 Codex。也许你也这样做过。

51
00:05:32,640 --> 00:05:37,200
我可以看到它已经返回了结果，只需查看更改即可

52
00:05:37,200 --> 00:05:44,399
自上次提交以来，这很酷。是的，这是使用子代理的一个很好的例子

53
00:05:44,399 --> 00:05:49,920
因为自上次提交以来实际发生的变化的各种来回变化

54
00:05:49,920 --> 00:05:53,839
并决定如何调查这个问题，然后最终得出调查结果

55
00:05:53,839 --> 00:05:58,799
然后编写它们，所有这些都没有放入主上下文窗口中。这一切都是由

56
00:05:58,799 --> 00:06:04,559
子代理。对我们来说更重要的是，这实际上是由 Codex 在其他地方处理的，

57
00:06:04,559 --> 00:06:07,279
但其实没有必要。它本来可以由克劳德·科德（Claude Code）来处理。它会

58
00:06:07,279 --> 00:06:11,920
仍然与主要背景保持隔离，这就是重点。

59
00:06:11,920 --> 00:06:17,359
我们可以通过执行斜杠上下文并查看上下文窗口的样子来看到它。

60
00:06:17,359 --> 00:06:22,480
我们已经拥有了所有这些东西，但你可以看到基本上没有真正的对话

61
00:06:22,480 --> 00:06:27,600
发生了。一切都非常干净，因为我们的子代理已经处理好了。

62
00:06:27,600 --> 00:06:33,679
因此，在我们今天要介绍的内容清单中，我添加了代理团队，这是一个新的

63
00:06:33,679 --> 00:06:38,880
克劳德代码中的实验性功能。我会作弊一点，因为我只是覆盖

64
00:06:38,880 --> 00:06:43,519
我告诉你它将在第四天到来。当我们

65
00:06:43,519 --> 00:06:46,799
看看代理团队和许多不同的结构。但我确实想解释一下

66
00:06:46,799 --> 00:06:52,079
代理团队和子代理之间存在差异，因为它们有很大不同。分代理

67
00:06:52,079 --> 00:06:57,839
确实是这样将一项特定任务委托给另一个将要运行的克劳德代码

68
00:06:57,839 --> 00:07:03,359
具有孤立的背景。然后结果将返回到主 Claude 代码，该代码调用

69
00:07:03,359 --> 00:07:08,239
它。并且总是存在这样的关系，即有一个主要的克劳德代码只是委托

70
00:07:08,239 --> 00:07:13,279
将一项任务发送给子代理并返回结果。实际上是可以的

71
00:07:13,279 --> 00:07:17,760
该子代理在这些配置设置中具有更长期的记忆。你可以要求它

72
00:07:17,760 --> 00:07:22,959
具有类似项目级别的内存。但除此之外，除此之外，它确实让人感觉

73
00:07:22,959 --> 00:07:28,959
很像它只是执行一项任务。这就是它的目的

74
00:07:28,959 --> 00:07:34,000
整个安排。代理团队有点不同。代理团队的任务是组建一整套

75
00:07:34,000 --> 00:07:39,600
一组克劳德代码，全部协作运行以尝试解决问题。所以就是这个东西

76
00:07:39,600 --> 00:07:43,920
当您可能有很多时，我们将讨论群和编排

77
00:07:43,920 --> 00:07:50,799
一切都在同时进行。以及经纪人团队的重大未知时刻之一

78
00:07:50,799 --> 00:07:55,200
这些是不同的，我本来想说的是子代理，但这可能会让你感到困惑，

79
00:07:55,200 --> 00:08:00,000
组成代理团队的这些不同代理可以相互通信。他们不

80
00:08:00,000 --> 00:08:05,119
只需要浏览主要的克劳德代码即可。他们还可以互动。您可以拥有一名代理人

81
00:08:05,119 --> 00:08:10,399
是直接向前端代理和后端代理提供测试反馈的测试人员。

82
00:08:10,399 --> 00:08:16,880
因此，他们都在您的团队中长期存在，并且能够与

83
00:08:16,880 --> 00:08:21,359
彼此，互相挑战，尝试不同的事情，测试不同的假设，

84
00:08:21,359 --> 00:08:26,160
所有这些想法。对我来说，它在克劳德代码中是实验性的

85
00:08:26,160 --> 00:08:30,799
现在。也许当你看到它的时候，它就更成熟了。我们将对此进行实验，

86
00:08:30,799 --> 00:08:35,359
但这显然与与子代理合作有不同的思维方式，

87
00:08:35,359 --> 00:08:41,119
更具体，更简单。接受一项任务，委派它，然后得到答案。