Agent Swarm
用持久记忆和隔离执行环境协调企业 AI 工作团队。
按维度查看评分与理由
证据显示有RBAC检查脚本、API密钥边界检查、审计列检查，以及HITL门控模式，但未提供具体实现细节。扣分原因：权限最小化、用户确认、数据流透明性等仅通过脚本和文档断言，缺乏代码级证据。敏感数据处理有OAuth和密钥管理，但未展示具体保护措施。依赖安全有锁文件和CI检查，但未提供漏洞扫描证据。外部影响有Docker隔离和审批门控，但未展示具体控制。回滚有Swarm Apps安全回滚和部署回滚，但未提供具体机制。来源归属有明确的作者和维护者信息。
自一致性：README、package.json、CI工作流和测试文件描述一致，但未验证实际运行。依赖可用性：有锁文件和CI安装步骤，但未验证依赖可用性。失败消息：测试覆盖了错误处理，但未提供用户可见的失败消息示例。
受众和场景：README详细描述了多种使用场景和集成。能力边界：有架构图和文档说明，但未明确限制。触发精度：有调度和任务触发机制，但未提供精确触发条件。环境适配：支持多种部署方式和平台，但未提供所有环境的详细配置。
信息架构：有清晰的文档结构和架构图。安装说明：提供了快速开始和多种安装方式。命名稳定性：有版本号和CLI命令，但未提供命名规范。示例和FAQ：有playbooks和文档链接，但未提供FAQ。已知限制：未明确列出。许可证：MIT许可证明确。版本和变更日志：有版本号和CI检查，但未提供变更日志。维护责任：有维护者信息。
输出可用性：有CLI、API、Dashboard等输出方式。边际价值：提供了多种集成和自动化功能，但未量化价值。成本效益：未提供成本分析。
声明可追溯性：README中的声明有文档链接，但未提供具体证据。跨来源佐证：有CI和测试，但未提供独立验证。事实与推断分离：文档中区分了事实和推断，但未明确标注。
- 静态审查无法验证实际运行行为，所有关于安全、可靠性和有效性的结论均基于代码和文档推断。
- 依赖安全未提供漏洞扫描证据，建议检查依赖的已知漏洞。
- 权限最小化和用户确认机制仅通过脚本和文档断言，需审查具体实现。
- 回滚机制未提供具体实现细节，需验证其有效性。
这个 Agent 能做什么，适合哪些场景？
Agent Swarm 是面向企业 AI 工作的自托管协调系统，由 Lead Agent 拆解任务并调度多个 Worker。任务可从 Slack、GitHub、GitLab、邮件、Linear、Jira、WhatsApp、API 或 CLI 进入，Worker 在 Docker 隔离容器中执行工作。系统将会话学习写入共享记忆，并保存 Agent 的身份与上下文，以支持跨会话协作。它提供 MCP API Server、SQLite 数据库、实时仪表盘、工作流、定时任务和人工审批门。产出可回流为拉取请求、Slack 或邮件回复、议题回复及可共享页面；可通过 Docker Compose 部署，也提供 npm/Bun CLI。
输入任务后，Lead Agent 进行规划并委派子任务，Worker 在带有 git、Node.js、Python 等开发环境的 Docker 容器内运行。Worker 读取共享记忆和身份上下文，完成操作后把学习结果写回记忆，并将进度流式发送到仪表盘、Slack 线程或 API。系统可通过 DAG 工作流执行带重试、结构化输入输出和审批门的自动化，也可用 cron 调度 Agent 任务、工作流或目录脚本。CLI 提供 onboard、connect、api、worker、lead、e2b、x 与 docs 命令；MCP 工具覆盖记忆、页面、KV 等能力。
- 工程团队在 Slack 提交功能请求后，由 Lead Agent 拆分开发工作，并让 Docker Worker 生成 GitHub 拉取请求。
- 使用 Linear 和 GitHub 的产品团队，将工单与讨论同步为可跟踪的 Agent 任务。
- 客户成功团队为重点客户运行定期报告任务，并利用按客户累积的工作目录保存上下文。
- 运维团队接入 Datadog、New Relic 或 Sentry 告警后，让 Worker 排查问题或定期提出代码健康改进建议。
- 营销团队运行内容生成流程，为博客、社交媒体和网站更新创建素材。
- 支持团队通过 Slack、邮件或 WhatsApp 接收请求，并由 Agent 在对应对话渠道回复。
这个 Agent 有哪些优点和局限？
- Lead/Worker 模型结合 Docker 隔离执行，适合把并行且可审查的工作委派给多个执行者。
- 共享记忆、持久身份、混合检索和图关联记忆，使跨会话任务能够积累上下文。
- 同时支持 Slack、GitHub、GitLab、邮件、Linear、Jira、WhatsApp、API 与 CLI，便于接入既有工作入口。
- 支持 Claude Code、OpenAI Codex、pi-mono、Devin、Claude Managed Agents、原始 LLM 与 opencode，降低单一 harness 绑定。
- DAG 工作流、cron 调度、暂停/恢复、重试和 HITL 审批门覆盖持续运营自动化。
- 部署至少需要 Docker 和一种受支持 harness 的凭据；默认快速开始示例使用 Claude Code OAuth token。
- 每个外部渠道都需要单独配置集成，例如 OAuth、webhook 或对应服务的凭据。
- Worker 具有完整开发环境并可执行任务，采用前需自行定义审批门、允许的工具路由和基础设施边界。
- 部分高级能力有额外运行依赖或共部署要求，例如 agent-fs 共享文件服务、E2B 评测 harness，以及 OpenTelemetry 兼容后端。
- 所提供信息未说明托管服务价格、硬件容量规划或生产级资源成本。
如何安装或部署这个 Agent？
前提是 Docker 和至少一种受支持的 harness 凭据。最快的方式是运行 bunx @desplega.ai/agent-swarm onboard 或 npx @desplega.ai/agent-swarm onboard，由向导生成 Docker Compose 配置。手动部署可执行：git clone https://github.com/desplega-ai/agent-swarm.git、cd agent-swarm、cp .env.docker.example .env；在 .env 中设置 API_KEY 和所选 harness 的凭据，例如 CLAUDE_CODE_OAUTH_TOKEN，再运行 docker compose -f docker-compose.example.yml --env-file .env up -d。API 默认监听 3013 端口，交互文档位于 http://localhost:3013/docs。
如何使用这个 Agent？
部署后，通过 Slack 私信或 @mention、GitHub/GitLab 议题或 PR、邮件，或 API/CLI 创建任务；Lead Agent 会规划和委派，Worker 在容器内执行并输出结果。使用 bunx @desplega.ai/agent-swarm <command> 或 npx @desplega.ai/agent-swarm <command> 管理服务：lead 运行 Lead、worker 运行 Worker、api 启动 API 与 MCP HTTP Server。可在 http://localhost:3013/docs 查看 API，仪表盘本地开发可在 apps/ui 运行 bun install && bun run dev，访问 http://localhost:5274。