CC Switch — 统一多 Agent CLI 管理桌面
Codex 核验（2026-10-09）：当前官方 README已列 Hermes：支持 provider coexist、MCP、Skills、Memory 与会话浏览；没有 Hermes local routing、aggregation 或 usage stats，且不能从面板恢复 Hermes/OpenClaw 会话，仅展示 Hermes 最近 500 次会话。因此早期“未支持 Hermes/所有客户端统一代理”的泛化都过时。工具覆盖应按能力矩阵分别看；本机集成未执行，第三方供应商广告不证明模型真伪、免费权益或当前服务可靠性。
基本信息
- GitHub: farion1231/cc-switch
- Stars: 103K+ (趋势榜)
- 技术栈: Tauri 2 (Rust + Web) + SQLite
- 平台: Windows / macOS / Linux
一句话定位
一个桌面 App 管理所有 AI 编码 CLI 的供应商配置、MCP、Skills 和会话。
支持的工具
| 工具 | 管理能力 |
|---|---|
| Claude Code | Provider 切换、MCP、Skills、会话 |
| Claude Desktop | 同上 |
| Codex (OpenAI) | 同上 |
| Gemini CLI | 同上 |
| OpenCode | 同上 |
| OpenClaw | 同上 |
| Hermes Agent | 同上 |
核心功能
1. 50+ Provider Presets
- 内置 AWS Bedrock、NVIDIA NIM、以及国内外社区中转的预置配置
- 一键切换，不需要手动编辑 JSON/TOML/.env
- 系统托盘快速切换（不打开主窗口）
2. 统一 MCP Management
- 一个面板管理 Claude/Codex/Gemini/OpenCode/Hermes 的所有 MCP 服务器
- 支持双向同步（一套配置推到多个工具）
- 我们已有 MCP 生态（gbrain、crw、nats 等），cc-switch 可以直接管理
3. 统一 Skills Management
- 同理，Skills 也可以跨工具统一管理
- 但我们有自己完善的 skill 系统（gbrain + skill_view/skill_manage），迁移成本可能不划算
4. Provider 切换与 Proxy Takeover
- 快速切换不同 API 供应商
- Proxy 接管能力（故障转移）
5. Session Search & Sync
- 会话搜索与同步
6. Cost Tracking
- 用量统计（对预算敏感场景有用）
与 Yunlu 的关系
✅ 直接相关的能力
| 维度 | CC Switch | Yunlu 现状 | 评估 |
|---|---|---|---|
| MCP 管理 | 统一面板 + 同步 | 各 Agent 独立 config.yaml 管理 | 🔶 有用但不紧急 — 我们目前 4 个 Agent 的 MCP 配置大同小异，手动维护还可行 |
| Provider 切换 | 50+ preset + 托盘切换 | 当前只用一个 provider (opencode-go) | 🔶 暂不需要 — 多 Provider 是 Phase 2 的事 |
| Hermes 支持 | 直接支持 Hermes Agent | 我们在用 | ✅ 兼容确认 — 以后扩展到多 Provider 时 cc-switch 是现成的面板 |
❌ 不重叠的部分
| 维度 | CC Switch | Yunlu |
|---|---|---|
| 多 Agent 协作 | 只是管理各自的配置 | NATS 总线 + gbrain 知识图谱 + 任务委派 |
| 自主性循环 | 纯被动管理工具 | 主动 cron 便签扫描 + 决策循环 |
| 知识图谱 | 无 | gbrain 全套 |
| 情绪/节律 | 无 | Eventide (开发中) |
| 便签系统 | 无 | 正在实现的主动性循环核心 |
值得借鉴的设计
- SQLite 原子写入 — 配置文件防损毁的简单方案
- 系统托盘快速切换 — Phase 2 多 Provider 场景可以用
- MCP/Skills 单面板管理 — UI 概念好，但目前我们不需要
结论
CC Switch 不是一个我们要「用」的工具，而是一个要「关注」的信号。
- 它证明「统一管理多 Agent CLI」是一个真实需求（103K⭐）
- 它直接支持 Hermes，说明我们的生态在增长
- 对我们当前的 Phase 0（自主性系统构建）帮助有限 — 我们更需要的是主动循环和认知架构，不是配置管理 UI
- 建议：保持观察，等 Phase 0 完成后，如果有多 Provider/多工具配置需求再评估