Swarm 和 Strands：通过新兴的任务交接实现自主编排

继《Strands 多智能体编排系列》之后，这次轮到 Swarm（群集）了。我将通过一个游戏化示例来解释，涉及五个专业智能体，每个负责设计视频游戏的不同维度。该方案已通过两种方式测试：使用 Gemma4 + Ollama 和 Gemini API。

要开发并理解 Strands 框架中的智能体，我建议你学习其基础课程或阅读文档（文档很详细）。基础知识很重要！了解如何为智能体增加复杂性至关重要，不要期望把所有设计责任都委托给 AI（相关资源在文末）。对于这个概念验证，我使用了两种本地执行方案来分析结果：

Ollama + 小型模型 gemma4:e2b-it-qat（大约 4GB）在 Docker 中运行。

Ollama + 小型模型 gemma4:e2b-it-qat（大约 4GB）在 Docker 中运行。

使用 Gemini API。API 密钥可以免费生成，并使用"Gemini 2.5 Flash"模型。

使用 Gemini API。API 密钥可以免费生成，并使用"Gemini 2.5 Flash"模型。

🎮 用来开发 Swarm 模式的用例是基于一个前提创建游戏设计文档 (GDD)："诅咒城堡中的盗版烹饪类游戏..."。五个专业智能体参与其中，每个负责游戏设计的不同维度：机制、叙事、关卡、传说（故事、神话、规则、历史数据）和游戏体验。它们协作，将一个简单的前提转变为一份连贯的游戏设计文档 (GDD)。

与线性流水线不同，智能体可以检测到它们决策之间的摩擦（一个机制与叙事相矛盾、一个传说规则破坏了平衡），并与相应的智能体重新开启对话，直到达成共识。

➡ Swarm 是一种协作型智能体编排模式，多个智能体如同一个团队一起工作来解决复杂任务。与传统的多智能体系统（无论是顺序型还是层级型）不同，群集允许具有共享上下文和工作内存的智能体之间自主协调。

Swarm 适用于以下情况：

步骤序列无法预先定义：你事先不知道哪个智能体需要介入，因为这取决于生成的内容。

可能存在更正或回溯：问题需要在专家之间多次往返（例如：一个智能体的决策会使另一个智能体的工作失效）。

存在多个相互冲突的专业领域：每个智能体代表不同的观点，价值恰好在于它们之间的协商，而不是孤立工作。

需要新兴的集体推理：最终解决方案源于智能体之间的相互作用，而不是由单个智能体（或人类）从上往下协调一切。

❗ 当工作流程固定和可预测时，它不是理想模式。

➡ 内存 / 上下文 它们拥有共享的工作内存和完整的上下文。当群集执行时，完整的消息历史（先前智能体的提案、异议和推理）会传递给接管控制的新智能体（任务交接）。任务交接有效负载：除了累积的历史记录外，当智能体执行任务交接工具时，可以附加显式消息或说明（message / context）来解释为什么要转移任务以及期望对方做什么。

➡ 节点 vs. 智能体 在 Swarm 中，每个智能体都注册为一个"节点"(SwarmNode) 来包装该智能体。这个区别很重要，因为群集不是按照"谁是谁"来推理，而是"哪个节点接下来执行"。最终结果暴露为 node_history，一个已执行节点的列表，而不是对话：这使得稍后可以重建实际执行的拓扑，而不必提前设计它。

➡ 任务交接机制是工具调用，不是魔法上下文转换 值得明确说明的是，handoff_to_agent 不是框架之外的特殊函数，超出了 LLM 范例：它是另一个工具，由 Strands 自动注入到群集中的每个智能体，使用与任何其他工具相同的函数调用机制。结果是，Swarm 模式的可靠性完全取决于底层模型执行工具调用的效果如何。这不是 Strands 的限制，而是该模式的结构性依赖。这就是为什么这篇文章附带的用例通过两种方式进行了测试：使用小型 Gemma4 模型和 Gemini 2.5 Flash 模型。

➡ 新兴拓扑 vs. 预定义拓扑（"为什么采用 Swarm"的核心论证）在 Swarm 中，拓扑是结果，不是输入。它在执行期间才被发现，并且在相同前提的不同运行中可能会变化（例如：我有 5 个智能体，但只有 4 个会介入）。这既是适应性的优势，也是非确定性风险。需要指出群集的开始位置，每个决策点由智能体本身根据累积的上下文来决定。以下是用例的示例拓扑：

mechanic_designer
      ↓
level_architect ←──────────┐
      ↓                    │
playtest_simulator ─────────┤ (iteration 1: objection → adjustment)
      ↓                    │
level_architect ──────────→┘
      ↓
playtest_simulator ─────────┐ (iteration 2: objection → adjustment)
      ↓                    │
level_architect ←───────────┘
      ↓
narrative_weaver
      ↓
lore_keeper
      ↓
playtest_simulator ─────────┐ (iteration 1: objection → adjustment)
      ↓                    │
level_architect ←───────────┘
      ↓
playtest_simulator
      ↓
[VERDICT: NO FRICTION DETECTED] → END

➡ 护栏作为设计的一部分 max_handoffs：整个群集中允许的最大智能体转移次数，强制在此之前切断。这是完整执行"步骤"的全局限制。max_iterations：允许的群集迭代的最大次数（节点执行次数）。实际上，它与 max_handoffs 一起充当第二道防线，防止失控执行。execution_timeout：完整群集执行可持续的总秒数，总计所有智能体和交接。如果超过，即使在进行中，群集也会以 Status.FAILED 切断。node_timeout：单个智能体在一个回合中（一次模型调用及其响应）可以花费的最大时间（秒）。防护单个节点卡住而不影响全局限制。repetitive_handoff_detection_window：Strands 分析的"窗口"大小（最近交接的数量）以检测重复模式。使用 6，它查看最后 6 个交接来决定是否存在循环。min_unique_agents：在该窗口内，必须参与的最少不同智能体数量，才能认为流程是"健康的"。如果在最后 6 个交接中参与的独特智能体少于 3 个（例如只有 2 个相互反弹），Strands 会将其检测为乒乓球现象并切断群集。所有上述护栏对于生产中的群集都不是可选的，它们是必需的，以限制智能体的自主性，并防止 token 成本、时间或付费 API 支出失控。

➡ Prompt 设计的重要性 Strands 提供任务交接机制（工具、钩子、护栏），但不决定何时使用它，这在每个智能体的系统 prompt 中。在此用例中，每个 5 个 prompt 都明确定义三件事：智能体的角色和评估标准、在什么条件下应向谁转移控制，以及收敛规则以防止一旦解决就再次反对（"收敛规则"）。

最后一条之所以需要写入是因为在最初的执行中，一些智能体用不同的措辞多次重新开启同一分歧，产生既不被护栏也不被钩子能区分为合法协商的非生产性循环。解决方案是在 prompt 上，明确指示每个智能体在第一轮后接受更正，除非出现新的理由。护栏防护结构性循环；这解决了语义循环。

➡ 钩子作为扩展点以缓解所选模型的限制 Strands 允许通过钩子挂接到智能体执行循环中，拦截诸如工具调用成功等事件。在该用例中，实现了 StopAfterHandoffHook，它强制智能体在成功交接后立即停止回合。

当仅靠提示词不足以保证某种行为时，可以使用这一机制。它能够防止模型在单个轮次中多次调用 handoff 工具。这是一种代码层面的确定性干预，不依赖提示词工程。

➡ 评估（Evals）

strands-agents-evals package 提供了可复用的评估器（按输出评估、按 tool-call 轨迹评估、按执行追踪评估等）。本用例实现了两种评估器：

• 轨迹评估（Trajectory Evaluation）。它不要求 handoff 严格遵循某个固定序列，而是验证执行过程的结构属性：

  • 入口点是否正确。
  • 是否有最低数量的不同智能体参与，以及必不可少的智能体（例如 mechanic_designer）是否介入。

• 输出评估（Output Evaluation）。检查最终 GDD 是否包含游戏领域中预期的关键词（例如 "curse"、"ingredient"、"castle"），以此作为一项基础检查，确认生成的内容与原始设定相关。

⭐ 这种方法体现了它与 agents-as-tools 等确定性更强的模式之间的一项关键区别：在后者中，可以依据精确的预期结果进行评估（是否委派给了正确的智能体）；而在 Swarm 中，需要评估的是行为的形态，而不是某个固定序列。

解决方案说明

📦 GitHub 仓库：github.com/reinalau/strands-swarm

正如我在上文中提到的，我使用了两种模型方案来执行并分析行为，不过你也可以只使用其中一种：

a. 使用 Docker Desktop，然后下载 Ollama 镜像并安装 gemma4:e2b-it-qat（大小略超 4GB）。你可以在这里找到所有 gemma 模型。

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. 从这里生成一个免费层级的 Gemini API key。它允许你使用 Gemini 2.5 Flash 模型。

多智能体代码使用 Python 编写，项目结构的设计旨在更清晰地说明其逻辑：

strands-swarm/
├── README.md
├── requirements.txt
├── .env.example
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── main.py                  # entry point, builds and runs the swarm
│   ├── config.py                # model provider config, timeouts, swarm limits
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   ├── _common.py           # shared model factory + prompt loader
│   │   ├── _hooks.py            # StopAfterHandoffHook
│   │   ├── mechanic_designer.py
│   │   ├── narrative_weaver.py
│   │   ├── level_architect.py
│   │   ├── lore_keeper.py
│   │   └── playtest_simulator.py
│   │
│   ├── prompts/
│   │   ├── mechanic_designer.md
│   │   ├── narrative_weaver.md
│   │   ├── level_architect.md
│   │   ├── lore_keeper.md
│   │   └── playtest_simulator.md
│   │
│   ├── swarm/
│   │   ├── __init__.py
│   │   └── build_swarm.py       # instantiates agents + configures Swarm (max_handoffs, etc.)
│   │
│   └── output/
│       ├── __init__.py
│       └── gdd_builder.py       # consolidates node_history/results into the final GDD
│
├── evals/
│   ├── __init__.py
│   ├── eval_cases.py            # EvalCase definitions (premise, expected agents, keywords)
│   └── run_evals.py             # trajectory + output evaluators over the swarm
│
├── examples/
│   └── example_premise.txt      # "cooking roguelike in a cursed castle"
│
├── outputs/
│   └── .gitkeep                 # generated GDDs land here after each run
│
├── logs/
│   └── .gitkeep                 # execution logs / handoff events
│
└── tests/
    ├── __init__.py
    └── test_swarm_flow.py

克隆源代码仓库，并准备好运行 gemma 4 模型的 Ollama Docker 容器或生成 Gemini API key 后，我们就可以开始搭建环境。在 requirements.txt 中可以找到以下依赖：strands-agents[ollama] strands-agents[gemini] strands-agents-evals python-dotenv pytest

pip install -r requirements.txt

.env 中需要配置：OLLAMA_HOST=http://localhost:11434 MODEL_NAME=gemma4:e2b-it-qat MODEL_PROVIDER=gemini # ollama GEMINI_API_KEY=tuapikeyOpcional GEMINI_MODEL_NAME=gemini-2.5-flash LOG_LEVEL=INFO MODEL_TEMPERATURE=0.5 MODEL_MAX_TOKENS=3500 MODEL_NUM_CTX=4096 MAX_HANDOFFS=12 MAX_ITERATIONS=12 EXECUTION_TIMEOUT=5000 NODE_TIMEOUT=1500 REPETITIVE_HANDOFF_DETECTION_WINDOW=6 REPETITIVE_HANDOFF_MIN_UNIQUE_AGENTS=3 ENTRY_POINT_AGENT=mechanic_designer LOG_DIR=logs OUTPUT_DIR=outputs

   cp .env.example .env

测试采用两级方案组织（tests/）：

第 1 级（快速且确定性）：验证 swarm 的结构、节点与限制配置、文本提取以及 GDD 整合，不会真正调用模型。它使用 "Cooking roguelike in a cursed castle." 或 "Test Premise" 等模拟字符串。

   python -m pytest

第 2 级（端到端集成测试）：使用真实模型（Ollama 中的 Gemma4 或 Gemini）运行完整的 swarm。该测试默认禁用，pytest 会自动跳过它；在本次执行中可通过以下方式启用：

   RUN_INTEGRATION_TESTS=1 python -m pytest -m integration

📝 注意：对于依赖真实 LLM 的测试，采用显式启用或禁用的方式是一种常见实践，尤其是在将这些流程集成到 CI/CD 流水线时，因为每次提交都真正调用模型会非常慢。

接下来执行主 Swarm。它既可以使用本地 Ollama 模型运行，也可以通过 Gemini API 运行。在 .env 中进行配置，注意将 MODEL_PROVIDER 修改为 "gemini" 或 "ollama"。此外，我也建议检查 src/config.py 中的默认值。

python -m src.main

智能体之间的调用日志可在 logs/ 文件夹中查看。智能体集群交换消息后的最终结果是游戏设计文档（Game Design Document），它会以 Markdown 文档的形式保存到 outputs/ 文件夹。

⭐ 建议你在执行后分析 handoff 拓扑，以了解这些智能体是否需要调整提示词、hook 或配置参数。

最后，我们通过“Evals”概念对真实智能体进行测试评估。这对于你未来构建的所有智能体都很重要：阅读 Strands 文档，弄清楚我们应该如何评估智能体，以及为什么要评估它们。这里通过 OTEL_SDK_DISABLED=true 禁用 OpenTelemetry 遥测收集器，以避免在本地使用 Ollama 模型时发生卡死（如果内部无法连接到某个端点，它会无限期挂起）。

export OTEL_SDK_DISABLED="true"
python -m evals.run_evals

📝 注意 2：GitHub 仓库中的 README.md 详细说明了代码以及逐步执行过程。

Swarm 模式将流程控制权交给模型本身。一次运行可能经过 4 个步骤，也可能经过 11 个步骤；可能花费一分钟，也可能花费两个小时，这取决于参与其中的智能体所做出的决策。在使用小模型时，我遇到过 handoff 循环、智能体之间来回“乒乓式”移交，以及仅在文本中叙述移交、却没有真正执行移交等问题。为了解决这些问题，我不得不加入显式控制：迭代次数限制、重复检测，以及在确认 handoff 后立即终止当前轮次的 hook。Swarm 的自主性无法取代工程护栏，反而使其变得不可或缺。

⭐ 未来还需要思考，如何实现可用于生产环境的 Swarm 多智能体项目。当前项目以教学为目的，有助于理解该模式的运行原理，但不足以直接用于生产。AWS 已经为此提供了一条自然的演进路径：Amazon Bedrock AgentCore。这是一种 serverless runtime，能够运行 Strands 智能体，并提供会话级隔离、可观测性、托管内存和自动扩缩容。后续文章将继续探讨这一迁移过程。

基础课程 Building AI Agent Harnesses with Strands Agents Building AI Agent Harnesses – Video Course

基础课程 Building AI Agent Harnesses with Strands Agents Building AI Agent Harnesses – Video Course

Strands Agents 文档 Swarm Evals

Strands Agents 文档 Swarm Evals

其他内容 Blog Writer Agent using Swarm Pattern Building AI Agent Harnesses – Video Course 阻止 AI 智能体产生幻觉

其他内容 Blog Writer Agent using Swarm Pattern Building AI Agent Harnesses – Video Course 阻止 AI 智能体产生幻觉

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。