你让 AI 助手调研竞品、总结发现、起草对比文档，然后发邮件给团队。单个 agent 可以完成其中每一步——但要把它们做好，按顺序执行，同时在四个任务之间保持上下文，就会触及单个 agent 会话能优雅处理的极限。上下文窗口被填满，agent 丢失了早期步骤的线索，最终输出的质量下降，因为模型同时在处理太多事情。
这就是 agent 集群要解决的问题。不是让一个 agent 做所有事，而是由一个协调 agent 将任务拆分为子任务，并将每个子任务委派给专门的 agent。调研 agent 搜索网页并返回结构化发现，写作 agent 拿到这些发现并起草文档，邮件 agent 发送结果。每个 agent 在自己的容器中运行，拥有自己的上下文窗口，专注于一件事。
这个想法不新鲜——CrewAI 和 AutoGen 已经探索多 agent 模式一年多了。NanoClaw 的不同之处在于，集群中的每个 agent 都在自己的隔离容器中运行，这意味着适用于单 agent 对话的安全和隔离保证自动扩展到多 agent 工作流。
集群在 NanoClaw 中如何运作
NanoClaw 的集群架构建立在一个简单的原语上：一个 agent 可以生成其他 agent。当 Claude Code 在容器内运行时，它的可用工具之一是 agent 委派——描述一个子任务并让 NanoClaw 启动一个新容器来处理它。父 agent 在子 agent 完成时获取结果。
编排通过 Claude 自身的推理自然发生。你不需要定义工作流图或在 YAML 文件中配置 agent 角色。你描述你想要什么，Claude 决定是直接处理还是将部分委派给子 agent。这个决策基于 Claude 擅长分解复杂问题的同一种推理能力——它能识别出任务中哪些独立组件会从专注处理中受益。
实际上，这看起来像一棵容器树。根容器接收你的消息，决定需要网页调研和文档写作，生成两个子容器，等待它们的结果，然后综合出最终响应。每个子容器都有自己的 CLAUDE.md 上下文、自己的挂载工作区和自己的工具集。调研 agent 启用了网页浏览；写作 agent 有对共享工作区的文件写入权限。两者都无法访问对方的上下文或工具。
为什么容器隔离对集群至关重要
大多数多 agent 框架在同一个进程中运行所有 agent。CrewAI 的 agent 共享一个 Python 运行时。AutoGen 的 agent 共享一个对话线程。这在演示中没问题，但在规模化时会产生事后难以修复的问题。 第一个问题是爆炸半径。如果集群中的一个 agent 遭遇 prompt 注入——一个试图劫持 agent 行为的恶意网站——注入被限制在那个单一容器中。它无法影响父 agent，无法访问其他子 agent 的上下文，也无法读取原始用户的对话历史。被攻破的容器在完成时被销毁，父 agent 收到它产生的输出（父 agent 可以在使用前评估其质量）。
第二个问题是资源争用。共享进程中的 agent 竞争相同的上下文窗口、相同的内存和相同的 CPU。在 NanoClaw 中，每个容器都有自己的资源。一个正在浏览大量网页的调研 agent 不会拖慢正在起草文档的写作 agent。容器在独立线程上并发运行，宿主机的资源管理负责调度。
第三个问题是凭证范围。调研 agent 需要网络访问但不应该有文件写入权限。文件管理 agent 需要磁盘访问但不应该有网络访问。在共享进程框架中，执行这些边界需要应用层的权限检查，而这些检查可以被绕过。在 NanoClaw 中，边界就是容器挂载——调研 agent 确实无法写入磁盘，因为没有可写路径被挂载到它的容器中。
实际的集群模式
从实际使用中涌现的模式比理论架构更有意思。最常见的是调研-综合模式：父 agent 生成 3-5 个调研 agent 并行调查问题的不同方面，收集它们的发现，然后产出一个比任何单个 agent 一次通过能产出的更全面的综合答案。
第二个常见模式是起草-审查。一个 agent 写初稿，然后生成一个审查 agent 并指示其进行批评。审查者的反馈返回给原始 agent（或一个新的起草 agent）进行修改。这比单次生成产出明显更好的结果，因为审查 agent 有一个全新的上下文窗口，可以在没有写作认知负荷的情况下评估草稿。
第三个模式是工具专业化。有些任务需要昂贵或有风险的工具——网页浏览、shell 命令执行、文件系统修改。父 agent 可以将这些操作委派给具有特定工具访问权限的子 agent，保持自己的上下文干净、权限最小化。父 agent 永远不直接接触文件系统或网络；它只处理子 agent 返回的结果。
集群的局限
集群不是免费的。每个子 agent 都是一次独立的 Claude API 调用，意味着独立的 token 成本。一个生成五个调研 agent 的集群大约花费单个 agent 做所有调研的五倍。对于简单问题——"天气怎么样？"或"翻译这句话"——集群纯粹是额外开销。
延迟也会累积。即使并行执行，父 agent 也必须等待最慢的子 agent 完成才能综合结果。一个五个 agent 的集群中如果有一个花了 30 秒浏览一个慢网站，那用户就要等 30 秒加上综合时间，不管其他四个有多快。
NanoClaw 务实地处理这个问题。Claude 根据任务复杂度决定何时使用集群——简单问题直接回答，复杂的多部分请求则委派。用户不需要配置集群行为；他们只管提问，系统会根据复杂度调整方式。目标不是到处使用集群——而是在集群确实能比单个 agent 产出更好结果的地方使用。
多 agent 的未来不是要取代单个 agent。而是赋予单个 agent 在需要时寻求帮助的能力，以安全、隔离和透明的方式。NanoClaw 的每 agent 一容器模型使这成为可能，而不需要在共享环境中运行多个 agent 所带来的安全妥协。