Swarm

核心用法

Swarm 是一个基于 Node.js 的 LLM 成本优化编排工具，核心策略是将昂贵的主模型（如 Claude Opus、GPT-4o）的负载转移到极便宜的 Gemini Flash（成本降低约 200 倍）。它通过本地守护进程管理多个并行工作节点，提供五种主要执行模式：

1. Parallel（并行）：同时执行 N 个独立提示，适合批量摘要、比较、实体处理
2. Research（研究）：多阶段流程（搜索→获取→分析），集成 Google Search 实时数据
3. Chain（链式）：多阶段流水线，支持 parallel/single/fan-out/reduce 四种阶段模式，内置 10 种专业视角（extractor、analyst、critic 等）
4. Skeleton-of-Thought（骨架思维）：先生成大纲，再并行扩展各章节，最后合并，适合长文档生成（14,478 字符/21秒，9.4/10 质量分）
5. Voting（多数投票）：同一提示并行执行 N 次，通过相似度/长度/LLM 评判选出最优答案

高级功能包括：LRU 响应缓存（212-514 倍加速）、结构化 JSON 输出（schema 验证）、自省反思（critic 自动优化）、成本追踪（session/daily 双维度）、基准测试（FLASK 六维评分）。

显著优点

• 极致成本效益：Gemini Flash 价格比 Claude Opus 低 200 倍，30 个任务从 $0.50 降至 $0.003
• 架构灵活：Chain 模式的四种阶段类型 + 自动深度预设（quick/standard/deep/exhaustive）适配从简单批处理到复杂多视角分析的全谱系需求
• 质量保障机制：多数投票策略（judge/similarity/longest）、自省反思（5.0→7.6 分提升）、骨架思维的高吞吐长文本生成
• 工程成熟：LRU 磁盘持久缓存、阶段级失败重试、结构化输出零解析失败、实时成本统计
• 零额外成本的实时搜索：Gemini 原生 Google Search grounding，无需额外 API 费用

潜在局限

• 供应商锁定：核心优化依赖 Gemini Flash，切换供应商（如 OpenAI、Anthropic）将失去 200x 成本优势，需重新评估性价比
• 网络依赖：Research 模式和 webSearch 选项依赖 Google Search，在某些网络环境或地区可能不稳定
• 本地运维负担：需维护 Node.js 守护进程（swarm start/stop/restart），相比纯云端方案增加本地故障点
• 复杂度阈值：Chain 和 Skeleton 模式虽有自动构建，但深度定制仍需理解阶段类型、视角角色、reduce 逻辑等概念
• 缓存新鲜度风险：212x 加速的 LRU 缓存对时间敏感任务（如价格、新闻）可能返回过时信息，需手动清除或禁用

适合人群

• 成本敏感型团队：AI 应用月消耗 $500+，希望在不牺牲质量前提下压缩 90%+ 成本
• 批量处理需求者：日常有 10+ 条独立分析任务（竞品监控、内容审核、数据提取）
• 研究型工作流：需要多角度分析、 adversarial review、结构化研究报告的产品经理、分析师
• 长内容生产者：技术文档、市场报告、指南类长文写作，追求 Skeleton-of-Thought 的高吞吐模式
• 已有 Node.js 生态的开发者：能轻松集成到现有工具链，使用 JavaScript API 构建自定义工作流

常规风险

• API 密钥管理：需配置 GEMINI_API_KEY，存在密钥泄露风险（建议限制密钥权限、使用环境变量）
• 速率限制：默认 max_concurrent_api: 16，高频调用可能触发 Gemini 限速，需动态调整配置
• 成本监控盲区：虽提供 session 和 daily 统计，但缺乏硬性预算熔断（仅有 max_daily_spend 软限制）
• 输出一致性：廉价模型可能在复杂推理任务上出现质量波动，建议对关键任务启用 voting 或 reflect 机制
• 守护进程单点故障：本地 daemon 崩溃将导致所有进行中的任务失败，生产环境需监控和自动重启机制

核心用法

Swarm 是一个 Node.js 并行 LLM 任务执行框架，通过"工人池"模式将高成本模型（Claude Opus、GPT-4）的批量任务，分发给低成本的 Gemini Flash 并行处理。用户通过本地守护进程管理任务队列，支持四种核心执行模式：

1. Parallel（并行）：N 个独立任务同时分派，适合批量摘要、实体提取
2. Research（研究）：多阶段搜索→抓取→分析流水线，自动调用 Google Search Grounding
3. Chain（链式）：多阶段递进处理，支持 parallel/single/fan-out/reduce 四种阶段模式，可自动或手动构建流水线
4. Skeleton-of-Thought：先生成大纲，再并行扩展各章节，最后合并成长文档

高级功能包括：内置 LRU 缓存（212-514x 加速）、多数投票机制（judge/similarity/longest 策略）、结构化 JSON 输出（原生 schema 验证）、自我反思优化（critic 打分→自动改进）以及成本追踪仪表盘。

部署方式：npm install 后运行 swarm start 启动守护进程（默认端口 9999），通过 CLI 或 HTTP API 调用。配置位于 ~/.config/clawdbot/node-scaling.yaml，支持最大 16 并发工人。

显著优点

• 极致成本效益：Gemini Flash 成本仅为 Claude Opus 的 1/200，30 任务从 $0.50 降至 $0.003
• 速度优势：并行模式下 30 任务从 30 秒压缩至 1 秒级
• 架构灵活：链式阶段的 fan-out（单输入多视角）与 reduce（多输入聚合）模式，天然适配复杂分析场景
• 质量保障机制：多数投票（3x 执行选最优）、自我反思（自动迭代至阈值）、Benchmark 模式（FLASK 六维评分对比）
• 工程成熟：缓存持久化、失败任务级重试（非全阶段重跑）、结构化输出零解析失败

潜在局限

• 供应商锁定：核心依赖 Google Gemini 的 responseSchema 与 Search Grounding，切换供应商需重构
• 本地运维成本：需维护 Node 守护进程，非无服务器架构，对纯 CLI 用户有认知负担
• 长文档延迟：Skeleton 模式虽然吞吐量高（675 chars/sec），但端到端仍需 20 秒级，非实时场景
• 缓存失效策略：TTL 固定 1 小时，无法按任务类型差异化配置
• 网络依赖：Research 模式强依赖 Google Search 延迟（~15s/2 任务）

适合人群

• 高频批量处理用户：内容审核、竞品监控、批量翻译/摘要场景
• 成本敏感的研究团队：需大规模数据提取但预算有限的分析师
• 多源信息整合需求：需同时抓取并对比 10+ 网页/文档的调研工作
• CLI 重度用户：习惯终端工作流、能自主维护 Node 环境的开发者

常规风险

• 提示词注入：虽有基础检测模块，但复杂越狱攻击仍需用户自行过滤输入
• API 密钥泄露：依赖用户正确设置文件权限（建议 600），共享环境存在配置泄露风险
• 成本监控盲区：max_daily_spend 为软限制，超量请求失败而非队列阻塞，可能影响业务连续性
• 模型漂移：Gemini Flash 输出质量波动可能导致链式/投票模式级联误差
• 缓存污染：重复相似任务可能命中过时缓存，需手动 DELETE /cache 清理