用途：将 relay、relay-dashboard、relay-cloud 三个仓库的代码协调同步到 staging 分支，并在推送 relay-cloud 的 staging 分支时自动触发 GitHub Actions 部署到 Fly.io 的 staging 环境，用于生产前的功能验证与跨仓库集成测试。
主要能力：每个仓库维护独立 staging 分支；通过 git worktree 隔离地执行分支推送，避免污染主工作目录；relay-cloud 的 staging 推送自动触发 deploy-staging.yml 工作流，同时并行构建工作区镜像；支持通过 workflow_dispatch 手动触发并传入 relay_branch、dashboard_branch 可选覆盖参数，指定分支不存在时回退到 main；工作流对 https://agent-relay-staging.fly.dev/health 做 HTTP 200 健康检查，重试 30 次、间隔 5 秒（约 150 秒上限），并输出部署摘要。
使用方式：在各仓库内创建 worktree（如 cd /data/repos/relay 后执行 git worktree add .worktrees/staging-push main），进入该目录执行 git fetch origin main:main 与 git push origin main:staging，推送完成后用 git worktree remove .worktrees/staging-push 清理；依次对三个仓库执行，最后推送 relay-cloud 触发部署。部署进度可在 https://github.com/AgentWorkforce/relay-cloud/actions 查看，需要覆盖分支时访问 https://github.com/AgentWorkforce/relay-cloud/actions/workflows/deploy-staging.yml 点击 Run workflow 填写参数。
适用场景：跨仓库功能集成、多仓库特性分支联合验证、main 到 staging 的常规同步、部署流程与基础设施变更的验证。不适合紧急热修复（应走生产部署）、仅单仓库改动以及不打算部署的本地测试。
限制与前置条件：需要三个仓库的推送权限，以及 relay-cloud 中的 CROSS_REPO_TOKEN、FLY_API_TOKEN 或 FLY_API_TOKEN_STAGING 等 GitHub 密钥和 staging 环境配置；依赖支持 worktree 的 Git（2.5+）。仅 relay-cloud 的 staging 推送会触发部署，relay 和 relay-dashboard 不会自动同步；创建 worktree 前需提交或暂存未提交改动；指定分支名区分大小写，不存在时回退 main。具体价格、SLA 及其它平台支持情况暂未提供。