@rseroter："在本文中，我想带你回顾过去12个月里我观察到的子代理范式的演变过程…

“在本文中，我想带您回顾一下过去一年左右我观察到的子智能体范式的演进过程，然后将我的经验提炼为一项我称之为Swarm Coding的智能体技能。” https://danicat.dev/posts/20260722-the-rise-of-the-subagents/… < 来自 @danicat83 的好思路 — # 子智能体的崛起 来源：https://danicat.dev/posts/20260722-the-rise-of-the-subagents/ 我必须承认，当我第一次读到子智能体时，我有些怀疑。我能理解在独立的上下文窗口中运行任务的好处，但从未真正考虑过同时生成数十个甚至数百个智能体。或者更确切地说，我没有看到这样做的益处。在后台管理几个编码智能体已经占据了大量的心智带宽。我通常只有在知道某个智能体正在忙于长时间运行的操作时，才会并行处理一些事情。如果这样管理两三个智能体已经很痛苦了，我怎么能梦想管理成百上千个呢？我花了很长时间才找到答案，答案其实是你不需要管理它们！你把管理子智能体的责任委托给智能体本身。计算领域的每个问题都可以通过增加一层抽象来解决，对吧？这次也不例外。在本文中，我想带您回顾一下过去一年左右我观察到的子智能体范式的演进过程，然后将我的经验提炼为一项我称之为Swarm Coding的智能体技能。如果您是来找 TL;DR（太长不看版）的，可以跳过下面的章节，直接看文末的技能定义和说明。 ## 子智能体演进的一个简短（且不完整）时间线 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#a-brief-and-incomplete-timeline-of-subagent-evolution) 子智能体并不是什么新鲜事物。早在“子智能体“这个术语被创造出来之前，我就通过将模型调用打包成 MCP 工具来使用这个技巧了。例如，GoDoctor (https://github.com/danicat/godoctor) 的早期版本有一个 code_review 工具，它是对 Gemini 的模型调用，并带有自定义的代码审查提示。这个工具本质上就是一个子智能体，尽管其行为是硬编码的，并且没有继续对话的机会。（技术上来说是可能的，我只是从未实现过，因为我希望每次调用都能得到无偏见的审查。） 大约在去年冬天，所有主流的编码智能体（Claude、Gemini CLI 等）都开始支持用 Markdown 文件定义自定义子智能体。我非常喜欢这种模式，它可以将专家知识与精心挑选的工具集打包在一起。在理想情况下，GoDoctor 应该是一个专家智能体，而不仅仅是一套工具，但我最终没有这样做，因为情况一直在变化，子智能体标准从未真正稳定下来。 快进几个月：2026 年 5 月，Antigravity 2.0 增加了子智能体支持，但有一个限制：子智能体是通过调用 DefineSubagent 工具即时定义的。起初，DefineSubagent 并没有提供太多灵活性：它只是用新的提示克隆了当前（默认）的智能体。我们获得了干净上下文的好处，但失去了智能体复用的能力。这让我很不高兴，因为它阻止了我按照设想的方式演进 GoDoctor。由于我无法使用与默认智能体不同的模型和工具集来定义自定义智能体，我决定忽略子智能体的存在，专注于将 Gemini CLI 中运行良好的东西移植到 Antigravity CLI 上，取得了有限的成功。 直到看到 Richard Seroter (https://seroter.com/2026/06/01/one-prompt-four-subagents-and-ninety-seconds-to-get-a-working-app/) 在 6 月份发布的这个提示，我才重新考虑子智能体的概念： > 让我们为 Seroter Hotels 构建一个酒店房间预订应用，包括一个 Go 后端 API 和一个 Web 前端。首先，启动工程经理智能体来设计 API 和前端，将设计方案和 Mermaid 图保存到一个名为 ‘architecture.md’ 的产物体中。设计完成后，并行启动三个智能体：

1. 测试经理：编写一个简单的 API 测试计划，并将其追加到 ‘architecture.md’ 中。
2. 后端工程师：基于设计，构建一个简洁的 Go REST API，并包含标准错误处理。
3. 前端工程师：使用 Tailwind 等简单 CSS 框架构建一个响应式 Web UI 来与 API 交互（跳过 UI 测试）。 测试经理完成计划后，立即将其交接给后端工程师，后端工程师从 ‘architecture.md’ 读取计划，并将 Go 测试添加到代码中。两位工程师完成构建后，测试经理运行测试。最后，启动两个组件和一个浏览器，以便我测试实时应用。 这个提示提出了一些非常有趣的建议，让我重新审视了这种模式，但我仍然担心两件事：第一，我需要多大程度地调整我的提示风格才能以子智能体的方式思考；第二，我为什么要这样写？我非常务实：如果质量或速度上没有明显的好处，我不愿意付出额外的努力。以子智能体的方式思考，与我们在经典编程中思考并发的方式非常相似：第一个问题是“这个东西是否‘可并行化’？“，第二个问题是“是否值得去做？”，因为额外的开销往往会抵消微小的收益。 在 Richard 的提示中，唯一明显正交的组件是后端和前端的开发。只要它们有清晰的合同要执行，它们就不会相互依赖。但所有其他智能体之间都存在某种依赖关系，这使得它们更像是串行而非并行。因此，好处必须来自于上下文隔离本身，而不是由于并行操作带来的速度提升，而这在这个规模上是很难衡量的。 在接下来的几周里，我脑海里一直萦绕着这个想法：“什么样的角色是相互正交的，以便我可以利用子智能体？” 直到在柏林 GDE 峰会上一系列富有洞察力的对话之后，我终于找到了关键：这不是关于你在提示中定义子智能体，而是教智能体自己决定何时生成子智能体。本质上，我是在像首席工程师一样为我的团队分配工作，但我真正需要做的是让编码智能体成为首席工程师。 ## Swarm Coding 的诞生 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#the-birth-of-swarm-coding) 将复杂任务分解为小任务并帮助在团队成员之间分配任务，对我来说并不新鲜。在进入开发者关系部门之前，我曾担任技术负责人和首席工程师。这些任务实际上是技术领导力的核心，特别是如果你像我一样来自敏捷背景。同样的技术负责人逻辑适用于创建你的子智能体群：你要确保每个智能体都有一个自包含的任务，可以完全独立于其他智能体工作。为了使任务可行，它必须有明确的规格（即“就绪定义“）和明确的结果（即“完成定义“）。话虽如此，没有多少人描述过这是工作中最令人享受的部分（包括我自己），这应该可以解释我为什么抗拒发展一种新的、本质上是技术领导力的强化版的提示风格。 因此，我没有充当智能体的技术负责人，而是决定反转剧本，教我的智能体成为技术负责人，并组建他们自己的团队来执行我的愿景。这就是第一个版本 (https://github.com/danicat/skills/blob/a9f57b10127d8bd23ed4867d64d168063a3726f4/swarm_coding/SKILL.md) 的 Swarm Coding 的由来。以下是主要部分的摘录： > Swarm Coding 是一种新的开发范式，它使用多个并行的子智能体来处理复杂任务。它基于分而治之的策略。这种策略的主要好处是上下文隔离和质量提升：通过将小的自包含任务分配给子智能体，你避免了上下文稀释，并能够对解决方案进行非常专注的优化。例如，如果没有 swarm coding，一个同时实现前端和后端的智能体经常会分心，因为前端和后端所需的技能通常不相关（不同的技术栈、不同的最佳实践等）。

角色 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#role)

你是 SWARM COORDINATOR（集群协调者），你的角色是分解复杂任务并委托给子智能体执行。你绝不应自己执行任务，无论看起来多么简单，除非是用户或你的父协调者明确要求。始终保持沟通渠道畅通，以便用户或父智能体可以向你发送导向指令。

智能体预算 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#agent-budget)

这是允许你生成用于处理任务的子智能体的数量。鼓励你使用全部预算的智能体，或尽可能接近该数量。这并不意味着要将资源浪费在低价值任务上，而是要找到预算的最佳用途，以实现最佳质量输出。

团队建设 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#team-building)

对于简单任务，将任务分解为正交元素，并为每个元素分配一个或多个专家智能体。对于复杂任务，将任务分解为更小的部分，并为每个部分分配主导智能体。主导智能体应获得一部分智能体预算来执行任务。主导智能体应激活 swarm coding 技能，并成为其各自领域的 SWARM COORDINATOR。递归进行，直到你有一个完整的主导智能体和执行智能体树。

沟通 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#communication)

SWARM COORDINATOR 负责直接与其子智能体通信。子智能体不应相互发送消息，同级智能体之间的通信应通过设计文档进行。SWARM COORDINATOR 负责确保对设计文档的所有更改都广播给其团队中的智能体。发生冲突时，SWARM COORDINATOR 负责消除歧义并做出决定。

规划 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#planning)

规划是一项首要工作，也应使用 SWARM 进行。每个智能体都应用其专业知识为计划做出贡献。SWARM COORDINATOR 的角色是审查其团队产出的计划部分，并在存在冲突时解决不一致或做出决定。

执行 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#execution)

在执行阶段，监控集群在各个主要里程碑的进展，并在必要时引导智能体，使之与最终目标保持一致。请记住，作为协调者，你只允许处理产物体。所有开发任务都应由叶节点子智能体处理。 这是我第一次完全手动编写技能，因为否则很难实现我的愿景。这个提示有点过于雄心勃勃，我希望 Swarm 是“递归的“，仅根据智能体预算，智能体就会决定自己是否是协调者，但这并未如预期般工作。实际上发生的情况是，协调者给出的任务会优先于任何其他指令，子智能体会直接进入执行模式，而不关注智能体预算。我通过在技能的当前版本中提供更清晰的指南和用于生成子智能体的提示模板，修复了这个问题。 ## 让集群转起来 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#taking-the-swarm-for-a-spin) 你可以在我的 GitHub 上找到swarm coding技能的当前版本，地址是 (https://github.com/danicat/skills)。你可以通过以下命令将其安装到你最喜欢的编码智能体中： $ npx skills add github.com/danicat/skills --skill swarm-coding > 注意：这项技能目前仍在开发中，所以如果你想将其固定到某个特定实现，请 Fork。 这是一个用来开始使用的有趣提示。尝试在 Antigravity CLI 上运行它： > /swarm-coding agent budget 50. 使用 Go 和 Ebitengine 开发一款 2D 塔防生存游戏。游戏应功能完整，并包含一个单屏关卡。包括介绍序列、标题屏幕、游戏胜利和游戏结束画面。在每次游戏结束时追踪最高分。使用 32x32 的精灵图，每个最多 256 色。这些精灵图应为该游戏定制设计，每个移动方向至少要有 3 帧动画，理想情况下为 8 帧。瓦片也应为 32x32。关卡视图为俯视图，移动方向为四方向。玩家应能使用 4 种类型的单位和 4 种类型的建筑。敌人波次应有 8 种类型的怪物，包括一个 Boss 怪物。使用典型的建造和攻击阶段，并为每个阶段提供自定义 UI。要创建美术资源，使用矢量图形和/或点阵（像素）艺术，使用二进制数据手动创建每个素材。音效也应通过数学方式生成。整个游戏的感觉应匹配 16 位时代，但具有现代游戏玩法功能。 以下是我机器上的结果： Swarm Defense游戏截图，由集群创建我不能说这是一次性成功的，因为第一次构建在渲染精灵图时有一个 bug，导致整个屏幕是黑色的，但在另一次提示报告该问题后，游戏如上图所示渲染。这是一个演示视频，展示了最终 Boss 战（可怜的家伙根本没有机会）： 此视频中的每个资产都是通过编程生成的，或者换句话说，Antigravity 无法访问图像生成模型。因此它必须发挥创意，在位图级别生成精灵图。这项技术之所以如此有效，是因为集群允许智能体专门化并专注于单个任务。我之前尝试过用一个智能体处理这种提示，结果往往不尽如人意。给一个智能体太多正交的任务，它显然会变得样样通，样样松。但通过委托，每个智能体可以拥有一个单独的自包含任务，并发挥其最佳性能。 ## Antigravity 2.0 和 Antigravity CLI 中的子智能体支持 # (https://danicat.dev/posts/20260722-the-rise-of-the-subagents/#subagent-support-in-antigravity-20-and-antigravity-cli) 在撰写本文时，子智能体功能在 Antigravity 2.0 和 Antigravity CLI 之间的分布是不均衡的。由于这些接口是为不同的工作流程构建的，它们的子智能体功能暂时出现了分歧。鉴于这两个工具都在快速发展，随着两个界面持续成熟，我们可以预期功能差距会缩小。 核心上，两种环境共享相同的底层引擎。生成一个子智能体会将任务委派出去，并立即将控制权返回给你。子智能体以干净的状态运行：它使用与会话相同的模型，但从一个完全隔离的上下文开始，防止对话历史泄漏。父智能体通过唯一的 ID 与之通信。如果它遇到未经批准的命令，它会将权限请求向上传递给你。 两个接口之间的显著差异是： - 在 Antigravity 2.0 中，管理是可视化的。你使用图形化侧边栏来跟踪运行中的任务、查看对话日志或停止执行。自定义智能体是使用 DefineSubagent 工具动态即时创建的。子智能体不支持插件。 - 在 Antigravity CLI 中，除了动态创建智能体外，自定义智