00:00:00最近 Kimi 2.5 彻底火了。这是一个开源模型，在某些基准测试上
00:00:05甚至超越了 Opus，还拥有一个极其精妙的智能体集群（Agent Swarm）模式，编排器可以为复杂任务
00:00:11生成多达 100 个专门的智能体。但你知道吗？Claude 的代码中也潜藏着这个功能，
00:00:17虽然被隐藏在了一个开关后面，但还是被一名推特用户发现了。他是怎么发现的？
00:00:23Anthropic 是抄袭了 Kimi 的创意吗？点个关注，我们这就来深度解析。Anthropic 其实在去年 7 月
00:00:30就宣布了自定义子智能体功能，从那时起，大家就开始用它们来处理各种
00:00:35专业化任务。当时我们也专门做过视频。但子智能体本身
00:00:41只能获取全局上下文的一小部分，因为它们是为特定任务设计的。所以它们在完成任务、
00:00:48返回数据后，记忆就会清零。因此，人们不得不通过让子智能体
00:00:54将结果输出到 Markdown 文件，并更新主上下文文件的方式来手动实现“记忆”。
00:01:01这样，当同一个或另一个子智能体被要求更新时，就能通过读取这些文件
00:01:06来衔接之前的进度。但你仍然需要手动创建子智能体，
00:01:12为其分配角色、特定技能、工具和权限等等。这就是为什么 Kimi 的新功能
00:01:19“智能体集群”将效率提升到了新高度，因为编排器可以根据特定任务
00:01:25动态创建专门的子智能体，无需你亲自动手。这些子智能体
00:01:31可以并行协作完成总目标，当它们完成各自的部分后，会将结果交给编排器，
00:01:36由编排器决定是否需要根据这些数据生成新的子智能体
00:01:42来继续推进复杂任务。虽然 Kimi 的集群模式还是个研究项目，但与
00:01:48单智能体工作流相比，已经展现出了巨大的进步。看看这张图表，任务越复杂，
00:01:53处理速度却能保持一致，这就是多个智能体并行工作的威力。
00:01:58说实话，在 Claude Code 里你其实也能实现类似的效果，
00:02:04利用那个较新的任务功能，你可以创建任务清单并分发给各个
00:02:10子智能体。问题在于这些子智能体是通用的，并非针对特定任务进行过优化。
00:02:15而且我不确定 Claude 是否能自动将任务分配给最合适的
00:02:21自定义子智能体。如果你试过这个功能，欢迎在评论区分享。但看起来
00:02:25Claude 团队一直在研发一种让编排器根据任务即时自动创建
00:02:31子智能体的方法，这个功能被隐藏在了一个标识位后面，被 Mike Kelly 发现了。
00:02:37他在推文中展示了运作方式，并分享了一个名为“Claude Sneak Peek”的代码库链接，它是 CC Mirror 的分支。
00:02:42让我们来试试。这是一份由 AI 编写的计划书，目标是为一个名为 XDL 的工具制作网页前端，
00:02:48这个工具可以让你在终端下载 X（原推特）上的视频。我已经安装并运行了 Claude Sneak Peek，
00:02:55它看起来就像一个极简版的 Claude Code。我要让它读取 plan.md 文件，并创建
00:03:00可由智能体集群执行的任务。分配完任务后，现在它已经完成了，
00:03:05我要让它利用子智能体来执行这些任务。在开始之前，
00:03:11为了确认目前没有预设任何子智能体，我会运行 agent 命令，
00:03:16你可以看到没有任何专门或自定义的子智能体存在。现在开始
00:03:21执行任务，你可以看到它自动添加了一个“前端构建智能体”来处理前端任务。
00:03:26点击查看团队，我们可以看到已经有五个
00:03:32智能体就位了：一个团队负责人、一名 QA 测试员、一名后端构建员、一名组件构建员以及一名前端构建员，
00:03:37它们正在同步处理任务。我们还能实时查看团队中每个智能体的动态。
00:03:42比如 QA 测试员正在搜索模式，后端构建员也在执行同样的搜索
00:03:48并读取文件，组件构建员和前端构建员也是如此。如果
00:03:53想查看某个智能体的具体动作，只需按下回车进入智能体视图，
00:03:57我们甚至能看到它的系统提示词。返回主界面，智能体已经增加到了 8 个：多了一个组件创建员、
00:04:02一个 API 服务器人员、一个负责 Vite 配置的人员、一个负责 API 集成的人员，
00:04:07现在又多了一个负责 CSS 的人员，我们的智能体团队似乎在不断壮大。点击进入“团队负责人”，
00:04:13就会回到主 Claude Code 视图，也就是说团队负责人就是主 Claude Code 编排器。
00:04:18在主视图中，每个子智能体都会向我们汇报当前状态。
00:04:24如果我稍微缩小并向上滚动，就能看到之前所有
00:04:29不同智能体发送的消息。当所有任务完成后，我们会得到一个“集群项目完成文件”，
00:04:34记录了所有操作，还会生成一份“集群执行报告”，
00:04:41显示了所使用的专业智能体数量、它们的角色以及是否完成了任务。
00:04:47我们还可以向下滚动查看每个智能体工作的详细信息。考虑到 Claude 团队
00:04:52已经在该功能上投入的精力，我不认为他们抄袭了 Kimi。我觉得他们是看到了
00:04:59网络上像 Agents 和 BeMad 这样的实现方式，想在 Claude Code 中加入原生支持，
00:05:04但我完全理解他们为什么还没正式发布。首先，我不认为这个功能经历了像
00:05:10Kimi 2.5 编排器那样长时间的训练；其次，对于那些已经拥有
00:05:16一些甚至许多子智能体的用户来说，情况会变得非常复杂。例如，当用户想要完成一个复杂
00:05:22任务时，编排器如何判断是该创建一个全新的前端子智能体，
00:05:28还是调用用户现有的子智能体？它依据什么指标或数据来做出判断？
00:05:35此外，技能（Skills）也增加了复杂性。如果用户已经下载了一堆技能，编排器
00:05:42该如何决定是让新智能体使用这些技能，还是下载它认为
00:05:49更适合当前任务的新技能？也就是说，如果 Anthropic 发布这个功能，
00:05:56编排器在决定是否需要创建子智能体以及该分配什么资源之前，
00:06:02必须先扫描大量的用户既有数据、智能体、工具和技能。我其实不知道团队
00:06:10现在是否还在研发这个功能，或者他们已经觉得太复杂而决定放弃了。谁知道呢。
00:06:16说到功能，如果你正在利用 AI 或人工快速为项目增加功能，并
00:06:22想确保系统稳定不崩溃，那么你一定要试试 Betastack，它能够
00:06:28监控服务器日志，并利用异常检测在问题发生前向你发出预警。
00:06:33它还拥有原生 AI 错误追踪功能，能让你掌握前端的任何异样。
00:06:38所以，今天就去试试 Betastack 吧。
00:06:44on your front end. So go and check out Betastack today.