开发与工程 multi-agent-orchestrationcode-reviewtest-automationsecurity-scanningquality-gatesscope-enforcementtypescriptopencode-plugin

OpenCode Swarm

用分工明确的智能体和强制质量门禁验证 AI 生成的代码。

FollowAgents 评估 · FARS-2.1
谨慎使用
74/ 100 五分制 3.7 / 5
1 2 3 4 5 6
按维度查看评分与理由
1信任安全22 / 29 · 3.8/5

证据展示了较强的最小权限设计:只读审查角色、写入范围约束、路径包含与符号链接防护、默认关闭的外部技能整理和优化器,以及高风险操作的监督机制,足以支持 least_privilege 满分。确认和外部影响处理较好,危险重置要求 --confirm,Full-Auto 对含糊或高风险动作设置监督,但安装器会修改全局配置、禁用原生代理,自动继续模式也可降低阶段确认,因此 user_confirmation 与 external_effects 各扣 1 分。README 说明了 .swarm 状态、遥测、模型供应商、PR 监控和网络操作,但没有完整的数据字段、保留期限、传输目的地或隐私说明,data_flow_transparency 扣 1 分。存在密钥扫描、依赖审计和外部技能隔离/哈希校验,但未给出凭据存储、日志脱敏或事件响应政策,sensitive_data_handling 扣 1 分。依赖审计被声明且 GitHub Action 固定到提交,但依赖多用范围版本,所给材料没有锁文件、漏洞处置政策或更新机器人证据,dependency_security 扣 1 分。配置写入测试证明保留备份,技能优化器也声明原子激活和回滚,因此 rollback 满分。仓库和 npm 元数据可追溯到项目,MIT 文件存在,但许可证仅写 Copyright (c) 2025、没有明确权利人,且发布者身份未知,source_attribution 扣 1 分。

2可靠稳定8 / 14 · 2.9/5

README、package 元数据和局部 CLI 测试总体描述同一产品,但安装行为存在直接矛盾:前文称缺失时创建项目覆盖配置,Quick Start 又称不会创建项目配置,因此 self_consistency 仅 1 分。Bun/Node 最低版本、OpenCode 插件依赖、可选 peer dependency、模型后备和缓存升级路径都有说明,但未提供锁文件或所有外部服务离线/降级行为,dependency_availability 扣 1 分。测试覆盖无值参数、畸形 JSON、缺失环境变量和挂起超时的清晰错误,不过只证明 swarm-model 辅助脚本的一小部分,未展示主编排管线的系统性错误消息,failure_messages 扣 1 分。

3适用触发16 / 18 · 4.4/5

受众、常规开发、快速迭代、并行执行、无人值守、PR 反馈和多语言场景均有明确描述,audience_and_scenarios 满分。核心、可选、条件代理以及 strict/balanced/fast、Turbo、Full-Auto 的边界较清楚,但部分广泛承诺(如“任何 OpenCode 支持的供应商”)缺少逐项约束,capability_boundaries 扣 1 分。斜杠命令、issue 标签、配置开关、条件代理和活动架构师要求使触发条件精确,trigger_precision 满分。文档覆盖 Bun 与 Node、Linux/macOS/Windows 缓存布局、13 种语言、20 种语法和供应商格式,environment_fit 满分。

4规范维护14 / 18 · 3.9/5

README 具有清晰导航、架构、模式、命令、代理、升级和配置入口,information_architecture 满分。安装、运行时要求、npm 替代方案、首运行副作用和升级缓存处理具体,install_notes 满分。命令注册表被声明为事实来源,提供规范名称和弃用别名,naming_stability 满分。示例、演示脚本和配置片段丰富,但所给材料未包含完整 FAQ,且演示结果属于声明而非静态证实,examples_and_faq 扣 1 分。缓存问题、模式安全差异、命令冲突和自动暂停有所披露,但没有集中且完整的已知限制清单,known_limitations 扣 1 分。LICENSE 与 package.json 均明确 MIT,license 满分。语义化版本、升级说明和弃用兼容可见,但没有提供变更日志或版本到变更的完整映射,versioning_changelog 扣 1 分。仓库地址清楚,但许可证未标明具体权利人,材料也没有维护者、支持渠道、安全联系人或维护承诺,maintenance_responsibility 仅 1 分。

5有效结果9 / 13 · 3.5/5

状态、计划、证据、诊断、恢复会话和结构化反馈面向实际使用,且配置写入测试显示嵌套字段与备份可保留;但未执行主流程,也没有静态输出样例能够验证所有门禁产物,因此 output_usability 扣 1 分。角色分离、独立审查、范围约束、可恢复状态和多供应商路由相对单代理工作流具有可信增量价值,但对竞品的对比表缺少随附证据,marginal_value 扣 1 分。免费模型支持、可配置代理、串行回退和明确的成本 burn-in 提供成本意识,但没有延迟、令牌、资源占用或质量收益数据,cost_benefit 扣 1 分。

6证据核验5 / 8 · 3.1/5

文档将部分能力指向具体命令、配置键、源文件、问题编号和测试标识,claim_traceability 较好;然而“6000+ 测试”“每项任务均评审和测试”及竞品比较等核心宣传未由所给文件逐项支撑,扣 1 分。README 的版本、引擎、许可证、脚本能力与 package.json 和局部测试有一定交叉印证,但主编排、安全门禁和大量代理能力缺少相应实现文件或测试材料,cross_source_corroboration 扣 1 分。材料会区分默认、可选、条件能力,并指出实时代理列表和命令注册表才是事实来源,但演示故事板和比较表仍将预期行为表述为既成事实,fact_inference_separation 扣 1 分。

证据充分度: 评估于 2026年9月17日 审查版本 c2ef3e6d0640
上游仓库在本次评估后已有新提交;当前评分仍对应所示审查版本,可能尚未覆盖最新改动。
使用前请注意
  • 安装会修改 OpenCode 全局插件配置并禁用原生 explore/general 代理;使用前应备份配置并核对实际安装行为,尤其是文档对是否创建项目配置存在矛盾。
  • Full-Auto、auto-proceed、PR 自动反馈和并行工作树会扩大自动化影响面;应先在隔离仓库中启用,并保持高风险操作监督和严格写入范围。
  • 不要仅凭 README 的“6000+ 测试”、全门禁和竞品比较判断成熟度;所给证据只包含 swarm-model 辅助工具的少量测试,未静态证实主编排流程。
  • 运行会使用外部模型供应商,并可能启用 GitHub PR 轮询、遥测或外部技能发现;在处理敏感代码前应确认数据字段、目的地、保留期限和密钥/日志脱敏政策。
  • 依赖使用范围版本且未提供锁文件证据;部署前应锁定依赖、生成 SBOM,并执行独立漏洞与供应链审查。
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

OpenCode Swarm 是面向 OpenCode 的架构师主导型多智能体插件,把一次编码会话拆分为规划、实现、审查、测试、安全检查和文档更新等角色。架构师负责调度 coder、reviewer、test_engineer、critic、explorer、sme 等核心或可选智能体,并在任务和阶段边界执行门禁。它会读取代码库、生成分阶段计划、修改项目文件、运行构建与测试,并把计划、证据、上下文和遥测保存在项目的 `.swarm/` 目录中。内置能力包括 Tree-sitter 语法验证、占位符扫描、离线 SAST、依赖清单生成、质量预算、写入范围控制和 shell 写操作检测。它适合希望在 OpenCode 内获得可恢复、可审计开发流程的团队,但其核心运行方式依赖 OpenCode,并需要接受较复杂的配置、文件权限和多模型调用成本。

用户向 Swarm architect 提交开发任务后,architect 先调用 explorer 扫描代码库,并可向 sme 咨询领域问题;随后生成分阶段计划并交给 critic 审查。执行阶段由 coder 修改代码,系统运行 syntax_checkplaceholder_scansast_scanbuild_checkquality_budgetpre_check_batch 等检查,再由 reviewer 检查正确性和安全性,由 test_engineer 编写并运行测试。phase_complete 会在锁定的计划、配置和证据快照上重新验证适用门禁,通过后才提交阶段结果;失败则携带结构化反馈返回处理。系统还可以生成 CycloneDX SBOM、保存 .swarm/evidence/ 证据、恢复 .swarm/ 会话,并通过 diffgit_blamesymbolstest_runner 等工具分析代码。可选的 PR Monitor 使用 gh CLI 订阅 GitHub PR 状态;外部技能策展、技能优化器、测试变异和部分自动化功能默认关闭,需要显式配置或人工确认。

  1. 使用 OpenCode 开发生产应用的团队,希望让代码生成、独立审查、测试和安全扫描成为同一条强制流水线。
  2. 维护大型或长期项目的开发者,需要把计划、任务状态、技术上下文和验证证据保存在 .swarm/ 中,以便跨会话继续工作。
  3. 负责认证、加密或会话代码的工程团队,希望按文件模式触发额外安全审查,并限制 coder 只能写入声明范围。
  4. 同时维护 TypeScript、Python、Go、Rust、Java、C/C++、C# 等项目的团队,需要统一的语法检查、构建检查和测试调度。
  5. 在 GitHub 上处理实现任务或 PR 反馈的团队,希望通过 swarm-implement.yml、证据 PR 和可选 PR Monitor 跟踪验证结果。
  6. 希望进行无人值守编码的 OpenCode 用户,需要 Full-Auto 的确定性权限策略与 critic_oversight 审批记录。

这个 Agent 有哪些优点和局限?

优点
  • 实现、审查和测试由不同角色承担,并在任务与阶段结束时执行明确门禁,减少同一模型自我验证造成的盲点。
  • 内置 Tree-sitter 语法检查、68 条离线 SAST 规则、占位符扫描、CycloneDX SBOM、质量预算及项目原生构建检查。
  • 写入范围会跨进程持久化,并结合 TTL、真实路径校验、符号链接防护和多路径参数检查限制越界修改。
  • 计划、上下文、证据和遥测持久化到 .swarm/,支持中断后从 RESUME 和 EXECUTE 阶段继续。
  • 提供 13 种完整语言配置和 20 种 Tree-sitter 语法,且模型可按角色配置为 OpenCode、Anthropic、Google、Z.ai、MiniMax 或 Kimi 提供商。
局限
  • 它是 OpenCode 插件;离开 OpenCode 没有文档化的独立运行、库嵌入或面向 ChatGPT、Codex、Claude Code 的原生路径。
  • 安装依赖 Bun 1.3.13 以上,或 npm 路径所需的 Node.js 22.13 以上;OpenCode 的插件缓存还要求升级后显式刷新并重启。
  • 多角色规划、编码、审查和测试可能增加模型调用量、执行时间以及付费提供商成本,来源没有给出完整的成本基准。
  • 配置面较大,涉及智能体模型、权限、门禁、自动化、上下文预算和可选功能;错误配置可能绕过预期工作流,例如未选择 Swarm architect 时门禁不会运行。
  • 部分功能默认关闭或仍有限制:外部技能检查依赖静态正则且没有密码学签名、变异测试为可选项,一些 PR 和优化流程还要求人工确认。
  • README 对 Context Budget Guard 的描述存在内部矛盾:一处称其衡量完整会话并可执行预算限制,另一处又称只衡量注入内容且绝不阻塞,因此采用前应通过实际配置与行为验证。

如何安装或部署这个 Agent?

先安装 OpenCode,并准备 Bun 1.3.13 或更高版本。运行 bunx opencode-swarm install;该命令安装包、注册 OpenCode 插件、写入 ~/.config/opencode/opencode-swarm.json,并禁用可能冲突的原生 exploregeneral 智能体。若使用 npm,需要 Node.js 22.13 或更高版本,然后运行 npm install -g opencode-swarm && opencode-swarm install。安装过程可能创建缺失的项目覆盖配置;项目级配置 .opencode/opencode-swarm.json 也可按需手动创建。模型凭证取决于所选 OpenCode 提供商;文档给出的 OpenCode Zen 免费模型配置不要求 API 密钥。

如何使用这个 Agent?

运行 opencode,在智能体或模式选择器中选择 Swarm architect;若未使用 Swarm architect,门禁、审查和测试流程会被绕过。首先执行 /swarm help/swarm agents 确认插件及实时智能体名单,然后直接输入任务,例如 Build me a JWT auth helper with tests.。用 /swarm status 查看当前阶段和任务,用 /swarm show-plan 查看计划,用 /swarm evidence 检查审查、测试和安全证据。会话模式可通过 /swarm turbo [on|off]/swarm full-auto [on|off]/swarm auto-proceed [on|off] 调整。升级时运行 bunx opencode-swarm update 并重启 OpenCode;若需重新写入配置,则运行 bunx opencode-swarm install

这个 Agent 与同类方案有什么区别?

仓库将 Swarm 与 oh-my-opencodeget-shit-done 对比,并声称 Swarm 额外提供多种专业智能体、编码前计划审查、逐任务审查与测试、不同模型分工、shell 写入检测、跨进程范围控制、可恢复会话及内置安全扫描。来源只给出了 Swarm 自己的比较表,没有提供对另外两个项目实现的独立证据,因此这些差异应视为仓库作者的定位。

常见问题

必须购买模型 API 才能使用吗?
不一定。来源提供了使用 OpenCode Zen 免费模型的配置,并称无需 API 密钥;生产环境也可以按角色配置 Anthropic、Google、Z.ai、MiniMax 或 Kimi 等提供商,其费用和凭证由所选提供商决定。
插件可以修改哪些文件?
权限按智能体划分:默认示例中 coder 可写 src/tests/docs/scripts/,reviewer 主要写 .swarm/evidence/,explorer 与 sme 为只读。具体范围可通过 authority.rules 覆盖,.swarm/ 等受保护区域还有额外限制。
检查失败或会话中断后会怎样?
失败会通过结构化反馈回到执行循环;状态、计划和证据保存在 .swarm/。重新进入已有项目时,architect 可进入 RESUME 和 EXECUTE,而不必重复完整发现过程。
它会并行修改同一个代码库吗?
默认门禁设计避免智能体同时修改同一工作区。对于能够证明文件互不冲突的任务组,v8 可在隔离 worktree 中运行并行 coder;范围重叠或未知时自动退回串行执行。
是否需要 Docker 或持续联网?
本地质量门禁不需要 Docker。安装包、调用远程模型和可选的 GitHub PR Monitor 通常需要网络;外部技能策展等网络功能默认关闭,只有显式启用并配置来源后才会发起请求。

对比同类 Agent

用同一套 FARS 评审,横向比较这个 Agent 所属的短名单。

相关 Agents