Scion
面向 AI Agent 团队的开源编排平台，让多个 Agent 分工、委派、共享发现并并行工作。
- Star 数
- ★ 2k
- 最近更新
- 今天
- License
- Apache-2.0
- 主语言
- Go
- FA 评分
- 43/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 软件团队希望多个编码 Agent 在同一仓库上分工（一个调试、一个写测试），需要按 worktree 隔离并汇总结果。
- 不适合
- 需要生产级稳定 API、不能接受 pre-1.0 配置改动的团队
- 完全不愿启用容器运行时（Docker/Podman 等）的单机用户
- 希望零配置、开箱即用且无需本地 Hub 服务的使用者
- 源码审查
- 43/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
Scion 是 GoogleCloudPlatform 下以 Apache-2.0 开源的 Agent 编排平台，目标是让多个 AI Agent 与人类协作者像团队一样工作。它把 Claude Code、Antigravity、Codex、OpenCode 等 harness 作为独立进程运行在容器里，每个 Agent 拥有独立的配置与凭据，并可选择共享工作区、独立 Git worktree 或独立克隆。核心组件包括本地 CLI、Workstation 本地 Hub 与 Web UI、Runtime Broker，以及可扩展到 Kubernetes 与 Cloud Run 的托管 Hub。所有 Agent 都通过 Hub 控制平面运行，由它管理状态、身份与任务分发。项目定位为 pre-1.0 的实验与测试床，API 与配置可能随版本变化。
Scion 通过 scion CLI 驱动整个流程：scion init --machine 初始化本机，scion init 在仓库内创建 .scion 项目目录；scion server start 启动本地 Workstation 服务（默认地址 http://127.0.0.1:8080/onboarding），该向导会探测 Docker、Podman 或 Apple Container 运行时、配置身份与容器镜像。随后 scion start <name> "<task>" 在容器中拉起一个 harness 进程，scion attach 接入 tmux 会话，scion message 向运行中的 Agent 发送消息，scion logs 查看日志，scion stop/resume/delete 管理生命周期。Agent 之间可通过 CLI 委派任务、互发消息，并在任务完成或需要关注时收到通知；同时可通过 Telegram、Discord、Slack、Google Chat、Microsoft Teams 或原生 Web 聊天与人类协作。模板、技能与 Skill Bank 负责复用系统提示与工具，A2A 桥接用于连接其他 Agent 系统。
- 软件团队希望多个编码 Agent 在同一仓库上分工（一个调试、一个写测试），需要按 worktree 隔离并汇总结果。
- 研究者要复现实验并观察 Agent 之间的消息与共享文件访问，用 Scion 回放协作过程做分析。
- 需要在本地快速试跑 Claude Code 或 Codex 等不同 harness、比较模型表现的开发者。
- 运维团队要在 Kubernetes 或 Cloud Run 上运行多 Agent 工作负载，并需要 Hub 统一管理身份与状态。
- 项目负责人希望通过 Telegram 或 Slack 跟踪 Agent 进度，而不必一直盯着终端。
- 教育或演示场景中，用纯 markdown 定义多 Agent 协作规则并在线展示协作可视化。
如何安装或部署这个 Agent？
推荐使用社区 Homebrew tap，它同时安装 scion CLI 与 scion-plugin-telegram 插件，并预配置 ghcr.io/homebrew-scion 作为默认镜像仓库：
brew tap homebrew-scion/scion
brew install homebrew-scion/scion/scion升级时执行：
brew update && brew upgrade homebrew-scion/scion/scion也可以从源码安装：克隆仓库后运行 make all，它会构建 Web 前端并将其嵌入二进制；需使用 go.mod 指定的 Go 版本，以及安装指南中列出的 Node.js 前置条件。容器运行时会被自动探测，顺序为 Podman、Docker（macOS 上为 Podman、Docker、Apple Container），可在 .scion/settings.yaml 中覆盖。
如何使用这个 Agent？
先启动本地 Hub 服务：
scion server start浏览器会打开 http://127.0.0.1:8080/onboarding，向导会完成运行时检测、身份配置、容器镜像设置与首个工作区创建。随后在仓库中初始化项目并启动第一个 Agent：
cd my-project
scion init
scion start my-agent "Your task here"常用管理命令：
scion list
scion attach <name>
scion message <name> "..."
scion logs <name>
scion stop <name>
scion resume <name>
scion delete <name>如果手动初始化机器而不使用向导，仍需运行 scion server start，因为所有 Agent 都通过 Hub 运行。建议将 .scion/agents 加入 .gitignore，避免嵌套 git worktree 冲突。
这个 Agent 有哪些优点和局限？
- harness 与模型可混搭，README 明确列出 Claude Code、Antigravity、Codex、OpenCode，并通过 harness 配置包在核心之外扩展配置与认证。
- 执行模式覆盖面广：同一套 CLI 从本地 Docker/Podman/Apple Container，扩展到 Kubernetes 与 Cloud Run，以及 Workstation、单节点托管与 HA 托管 Hub。
- 为 Agent 协作提供了可观测基础设施：日志、会话指标、系统健康、共享工作区与 worktree 隔离策略可按项目选择。
- 开放接口齐全：CLI、API、生命周期钩子、MCP 配置与 A2A 桥接，便于接入 GitHub Issues、Linear、Beads 等周边系统。
- Skill Bank 支持技能的发布与版本化，可从 GitHub 与外部注册表解析，适合沉淀可复用经验。
- 项目自述为 pre-1.0、快速演进，API 与配置可能随版本变化，接入生产流程存在迁移风险。
- 强制依赖本地 Hub 控制平面——即使手工初始化机器，也必须运行
scion server start，比纯 CLI 工具多一层常驻服务。 - 需要容器运行时（Docker/Podman/Apple Container 等），HA 托管还涉及 Postgres 与共享存储，部署成本不低。
- 并非 Google 官方支持产品，也不在 Google 开源软件漏洞奖励计划范围内，安全支持渠道有限。
- README 未给出定价或费用模型，模型调用成本由所用 harness 与模型供应商决定。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Scion 当前 | 43 · 缺口较多 | 命令行工具 | ★ 2k | 今天 | Go | Codex · Claude Code |
| Polter 多终端智能体监督器 | 80 · 表现良好 | 桌面应用免费 + 模型费 | ★ 20 | 1 天前 | Zig | Claude Code |
| MCO | 73 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 541 | 14 天前 | Python | Codex · Claude Code |
| NTM（Named Tmux Manager） | 73 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 460 | 今天 | Go | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
README 提到容器隔离、按 agent 配置凭据、托管模式下的角色与作用域密钥，但均为断言，未见权限最小化的具体实现或默认值说明；无用户确认流程描述；数据流（凭据、遥测、消息）透明度不足；敏感数据处理仅一句带过；go.mod 依赖众多且含 dev 版本（grpc dev、chromedp 伪版本），未见依赖审计或漏洞缓解说明；外部副作用（容器、云资源、消息平台）无回滚或确认机制描述；源码归属有 Apache-2.0 与版权头，故 source_attribution 给 2。
README 与测试脚本对行为描述基本一致，但存在自相矛盾之处：chart-integrity.sh 注释称 EXPECTED_TOTAL 应为 39 却写 49，并自述“本脚本因此退出 2”，说明测试基线未收敛；依赖可用性仅靠 go.mod 与 Homebrew tap 说明，未验证；失败信息方面测试脚本有清晰的 exit 0/1/2 契约与 META-FAILURE 说明，给 2。
README 明确列出本地、Workstation、单节点托管、HA 托管及多种运行时，场景覆盖较好；但能力边界（agent 能做什么、不能做什么）多为概念表，缺少精确约束；触发精度（何时启动、何时委派）无规范；环境适配（Docker/Podman/Apple Container/K8s/Cloud Run）有说明，给 2。
README 结构清晰、安装步骤具体（Homebrew 与源码），并明确 pre-1.0、API 可能变化等已知限制；但命名稳定性差（自述快速演进）、无版本号或 changelog 文件、示例与 FAQ 较少；许可证完整为 Apache-2.0 给 3；维护责任仅“非 Google 官方支持产品”一句，发布者身份未经验证，给 1。
输出可用性方面 README 给出 CLI 命令表与快速开始，但缺少端到端示例输出；边际价值主张（多 agent 协作编排）有说服力但缺乏可量化证据；成本收益未讨论（容器、云资源、模型调用成本），给 1。
README 中的主张（Google 内部实验、Scion Films 等）多为外部链接，仓库内无对应证据；测试脚本注释详尽且引用具体提交与测量，但属于自述，无法交叉验证；事实与推断分离尚可（脚本区分 META-FAILURE 与断言失败），但整体证据链薄弱，给 1。
- 发布者身份未经验证，README 自述“非 Google 官方支持产品”，不应据品牌推断安全性或可靠性。
- chart-integrity.sh 中 EXPECTED_TOTAL 与注释所述数字不一致，脚本自述会以退出码 2 结束，说明测试基线尚未收敛，不能据此认为测试通过。
- go.mod 含 dev/伪版本依赖（如 grpc dev、chromedp 伪版本），未见依赖审计或漏洞缓解说明。
- README 中关于 Google 内部实验与案例的主张缺乏仓库内可核验证据。
- 项目自述 pre-1.0、API 与配置可能变化，命名稳定性与升级路径存在风险。
常见问题
我已经安装了 CLI，为什么还必须运行 scion server start？
scion 命令都通过 Hub 运行 Agent，本地 Workstation 服务就是 Hub，负责状态、身份与分发；即使手动完成了机器初始化，也需要启动它。Scion 自己会调用哪家模型 API？
可以在 Kubernetes 或 Cloud Run 上跑吗？
这个项目适合直接用于生产吗？
人类如何跟踪 Agent 进度？
scion logs 查看日志，或在支持的 harness 上 attach 到交互会话。