产品上线真正难的，是把多个系统变成一个可恢复过程
仓库事实会变化
框架、构建命令、环境变量、数据库迁移和静态资源都绑定具体 Commit。部署计划如果不锁定源码版本，验证过的内容和实际上线内容可能不是同一份。
供应商之间有依赖顺序
应用、数据库、域名、邮件和密钥并非独立。数据库连接需要先可用，DNS 不能在候选尚未验证时提前切换。
成功响应不等于产品可用
构建成功、容器健康和首页 200 都只是局部证据。真实发布还要检查登录、关键协议、静态资源、消费者兼容和回滚点。
中断会制造重复资源
请求超时后直接重试可能重复购买、创建实例或迁移。恢复必须先读取供应商事实并对账。
AgentMesh Deploy 的五步上线链路
- 只读分析仓库：识别框架、服务、环境变量、数据库、域名和构建方式，记录锁定 Commit 与指纹。
- 生成部署计划：把供应商动作、依赖、预算、风险、证据和恢复路径写入外部 Control Home。
- 连接最小权限凭证：持久对象只保存 Secret Ref，不把真实 Token、连接串和私钥写入计划或日志。
- 部署候选环境：先完成 Sandbox、Preflight 和候选验证，避免直接在生产环境摸索。
- 审批生产切流：用户查看数据库、DNS、邮件、费用与回滚证据后，对当前对象给出精确授权，再执行生产变更与最终验证。
产品仓库默认只读。部署状态、供应商回执、审批和恢复记录放在仓库外控制平面。需要源代码变化时，只生成 Patch 提案，不把部署工具变成仓库里的隐形作者。
不同供应商在部署链路中负责什么
| 供应商 | 典型职责 | 需要重点审批的风险 |
|---|---|---|
| Vercel | 前端与 Web 应用构建、预览和生产部署 | 环境变量、域名绑定、生产分支 |
| Railway | 服务、Worker 和运行时资源 | 实例规格、持久卷、公开端口与费用 |
| Neon / Supabase | PostgreSQL、连接与迁移目标 | 迁移、数据保留、连接范围和回滚 |
| Cloudflare | DNS、代理、边缘规则与域名入口 | 正式 DNS、缓存和生产流量切换 |
| Resend | 事务邮件域名与发送 | DNS 验证、真实收件人与发送授权 |
如果你最关心“Agent 在什么动作前必须停下”，继续阅读 审批式 DevOps 指南。
常见问题
会直接修改产品仓库吗？
默认不会。仓库是只读来源；需要改代码时，只生成 Patch 提案，由仓库负责人决定是否应用。
支持哪些云服务？
面向 Vercel、Railway、Neon、Supabase、Cloudflare 与 Resend 等供应商，实际范围取决于项目配置、连接和授权。
能自动切生产流量吗？
不会默认执行。数据库、正式 DNS、邮件、付费升级与生产切流需要单独、准确的当前任务授权。