DevOps 多年前就为软体解决了这个问题。你不会直接将程式码推送到正式环境。你在本地开发、在 staging 测试、透过关卡晋升，并在审查后部署。这个模式之所以有效，是因为它能在错误触及使用者之前拦截下来。
AI workflow 值得相同的纪律。提示词变更、模型切换、新工具整合——这些对正式环境输出品质的影响，就如同程式码变更影响应用程式行为一样重大。但大多数 AI 平台将每次变更都视为正式环境变更。编辑 workflow，它就上线了。没有审查。没有 staging。没有安全网。
JieGou 的环境管理将 dev-staging-prod 流水线带入 AI workflow。
三个环境
每个 workflow 独立存在于三个环境中。各自有自己的配置、核准要求和部署历史。
| 环境 | 需要核准 | 最低晋升角色 |
|---|---|---|
| Development | 否 | Member |
| Staging | 是 | Dept Lead |
| Production | 是 | Admin |
Development 是沙盒。团队中的任何人都可以在此部署而无需核准。测试新提示词、切换模型、新增步骤——自由迭代而无风险。
Staging 镜像正式环境但有安全边界。从 dev 晋升到 staging 需要 Dept Lead 审查并核准变更。这是你在 workflow 处理真实工作负载之前，验证其行为正确性的地方。
Production 是即时环境。从 staging 晋升到 production 需要 Admin 核准。这里的变更会影响真实使用者、真实资料、真实输出。
每个环境的独立设定
环境不只是权限层级。每个环境都有自己的运作配置：
- MCP server 实例 — dev 用沙盒 Slack，prod 用正式 Slack。对模拟整合测试而不触发真实副作用。
- 预设 LLM provider 与模型 — dev 用更便宜、更快的模型进行快速迭代。prod 用最佳模型确保输出品质。
- 核准关卡 — 每个环境有不同的角色要求，符合你的组织在各层级的风险容忍度。
- 部署 webhook — 依环境通知不同的 Slack 频道或 CI/CD 系统。Dev 部署通知
#eng-dev，production 部署通知#ops-alerts。 - 环境变数 — 注入步骤范本的非机密键值对。在 staging 将
API_BASE_URL指向测试伺服器，在 prod 指向正式伺服器。
这种分离意味着 development 中的 workflow 可以呼叫沙盒 API、使用更便宜的模型、并跳过昂贵的工具呼叫——而 production 中的相同 workflow 使用真实整合、最佳模型和完整处理。
晋升流水线
晋升遵循严格顺序。没有捷径。
- 开发者进行变更并部署到 dev。不需要核准——想部署几次都可以。
- 开发者请求从 dev 晋升到 staging。系统计算版本差异——比对当前 staging 版本与提议版本之间变更的结构性比较。
- Dept Lead 审查差异并核准或拒绝晋升。
- 核准后，workflow 版本自动部署到 staging。这是原子性的——核准和部署在一个步骤中发生。不存在晋升已核准但尚未部署的空窗期。
- 相同流程从 staging 重复到 production，需要 Admin 核准。
防止自我核准：请求晋升的人无法核准它。这强制每个朝向 production 移动的变更都要有第二双眼睛检视。
版本差异引擎
审查者不会盲目核准。他们能准确看到变更内容。
差异引擎依 ID 匹配跨版本的步骤，并比对 15+ 个属性：
- 步骤类型、标签、模型和 provider
- Recipe 指派和任务描述
- 系统提示词内容
- 条件逻辑（if/then/else 配置）
- 回圈配置（迭代限制、中断条件）
- 评估标准和品质门槛
- 步骤依赖
- 条件和回圈内的巢状步骤
变更呈现为人类可读的描述：
- 「模型从 ‘claude-sonnet’ 变更为 ‘claude-opus’」
- 「品质门槛从 0.7 变更为 0.9」
- 「系统提示词已修改」
- 「步骤 ‘Summarize’ 已新增」
- 「回圈最大迭代次数从 3 变更为 5」
差异也会侦测输入/输出 schema 变更（栏位新增、移除或修改）和执行模式变更（循序 vs. DAG）。审查者能看到完整全貌：哪些步骤变更了、如何变更，以及 workflow 整体发生了哪些结构性转变。
部署追踪
每次部署都会建立记录：
- 状态 —
active、superseded或rolled_back - 部署者 — 谁触发了部署
- 核准资讯 — 谁核准了晋升、何时核准，以及原始请求者
- 差异摘要 — 与前一次相比此次部署变更了什么
- 时间戳记 — 部署上线时间
部署历史可依 workflow、依环境查询。你可以追踪任何环境中任何 workflow 的完整生命周期：部署了什么、何时、由谁，以及每次变更了什么。
回滚
一键。即时。
回滚不会重新执行任何东西。它翻转部署状态：当前的 active 部署标记为 rolled_back，而前一个 superseded 部署再次变为 active。
这是状态变更，不是重新部署。前一个版本已经在那里——只需要重新启用它。没有建置步骤、没有晋升流水线、不用等待核准。当 production 出问题时，你在几秒内修复它，然后有充裕时间调查根本原因。
稽核追踪
每个操作都被记录：
- 环境设定的配置变更
- 部署到任何环境
- 晋升请求（谁请求、从哪个环境、到哪个环境）
- 晋升核准、拒绝和取消
- 回滚操作
每条记录项目都包含完整的变更前后快照。你可以重建任何环境在任何时间点的确切状态。这不只是运作卫生习惯——对于受监管产业的组织来说，这是合规要求。
与 VPC agent 整合
对于执行混合部署的组织，VPC 执行 agent 可以限定范围到特定环境。
Production agent 只处理 production workflow 执行。Dev agent 只处理 development 执行。这在基础设施层级提供资料隔离——development 实验永远不会碰触 production 运算资源，production 资料永远不会流经 development 基础设施。
结合环境专属的 MCP server 和环境变数，这从整合层到执行层创造了完整隔离。
可用性
环境管理适用于 Enterprise 方案。包含三环境晋升流水线、版本差异比对、核准关卡、部署追踪、回滚和稽核追踪。进一步了解企业功能或开始免费试用。