Dev、Staging、Production：AI Workflow 的環境管理

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 方案。包含三環境晉升流水線、版本差異比對、核准關卡、部署追蹤、回滾和稽核追蹤。進一步了解企業功能或開始免費試用。