← 回 Eric 老師課程首頁
Eric 老師的分享・2026-09-29（09-30 補部署架構）

《Workflow Atelier 工作流工坊》

Eric 老師這次分享的是一套「工作流平台」：讓會員在畫面上拖曳出自動化流程，順序、分支與排程由確定性的引擎控制，AI 只負責被框住的那一步。共 15 頁講義、1 張整合架構圖與 1 張操作畫面；09-30 老師再補一份 20 頁的 Docker 部署簡報和一張新的操作畫面。全部拆成十課，跟著十課導覽一課一課看下去。

老師的話（轉貼原文，未修改）

AI Agentic整體架構已完成大部分的治理平台(採用.net core C#跨平台系統)。除了目前尚在開發的Workflow Hub治理平台外，只剩下一個採用架構在Java下的Spring Claud設計結合neflix erueka 的【API治理平台-微服務平台】。所有治理平台預定架構在那一台mac m4 mini 上進行整體測試。AI Agentic 我總構思不能只靠cowork或者Openclaw直接進行項目建立與Connector MCP或者是agent skill，企業需求的最後會回歸到一個完全客製化平台架構來運行，且所有資源必須完全治理與掌控，不單純是AI Agent Model，且需要完全掌握的原生碼系統流程與儲存環境。

白話讀法：老師說，他規劃的 AI Agentic 架構裡，大部分「治理平台」已經做完了（用 .NET Core／C# 寫，可以跨平台）。還在開發的是 Workflow Hub；另外只剩最後一塊，是用 Java（Spring Cloud 搭配 Netflix Eureka）做的「API 治理平台／微服務平台」。所有治理平台預定放在一台 Mac mini M4 上做整體測試。

他的構思是：AI Agentic 不能只靠 Cowork 或 Openclaw 直接建專案、接 Connector／MCP 或 agent skill。企業的需求最後會回到一套完全客製化的平台，所有資源都要能治理、能掌控，不只是一個 AI Agent 模型，還要完全掌握原生碼、系統流程與儲存環境。

封面：Workflow Atelier 工作流工坊
封面（p.01）：《Workflow Atelier 工作流工坊》，副標「ASP.NET Core 視覺化平台與 Agent／MCP 自動化實戰」，標籤「24 小時大師級架構藍圖」。logo 一半是齒輪、一半是神經網路：一邊是機械式的流程控制，一邊是 AI 推論，正是這門課的主題。
一分鐘看懂

這是什麼？一套「工作流平台」。會員登入後，在畫面上拖曳節點、用線連起來，就能組出一條自動化流程，例如「每天排程 → 查待處理資料 → 有資料就請 AI 摘要 → 把結果存起來」。

最重要的設計原則？分工。順序、分支、排程、錯誤處理，交給不會亂猜的「工作流引擎」；需要理解文字、做摘要的那一步，才交給被框住的「AI 代理」。

管得多嚴？AI 用的技能要審核、版本要固定；能呼叫哪些工具要先授權；輸出要過格式檢查；金鑰只放在伺服器端。這些檢查都在後端強制執行，不靠畫面上把按鈕藏起來。

怎麼裝起來？（09-30 補）用 Docker 拆成六個服務、兩個映像、四個常駐容器。資料庫是唯一的狀態中心：網站和排程程式互不呼叫，只透過資料庫交換狀態；對外只開網站一扇門。

15頁講義
24小時・十二節課
5層系統架構
6件交付成果
8種流程節點
6組資料模型

小提醒：每一張圖都可以點一下放大。看到不熟的名詞，最下面有名詞小抄。

十課導覽

第 01 課・整合架構圖

整體規劃：Workflow Hub 在最上層

先看老師一起轉貼的整合架構圖：最上面是還在開發的 Workflow Hub，下面是已經放進 Docker 的各個平台。這張圖標註「整合規劃示意」，兩邊還沒有真的接起來。

一張圖看完整體規劃

AI Agentic 管理與工作流整合架構：Workflow Hub × MCP × RAG × Docker
圖・整合架構圖 「AI Agentic 管理與工作流整合架構——Workflow Hub × MCP × RAG × Docker」，右上角標「整合規劃示意」。實線是既有的存取，虛線是規劃中的整合。

由上往下讀。最上層是 Workflow Hub，圖上寫著「AI Agentic 管理與設定」，並註明「借鏡 Claude Cowork 的協作概念」。中間一條「任務派送與結果回傳」的匯流排，把任務送到下面的主機與 Docker 容器，結果再送回來。

Workflow Hub 的七個模組

會員登入・角色授權先確認你是誰、能做什麼
流程編排拖曳節點、設定任務相依
Agent 設定模型、提示詞、執行限制
Skill 管理技能資料夾、版本、審核
MCP 工具工具選擇、權限設定
排程與審批週期觸發、人工確認
執行監控狀態、重試、稽核

下面的主機與 Docker 環境

圖的左下是一台 Windows 11 主機：有瀏覽器與 API 用戶端（Swagger、SSMS／sqlcmd、MCP Client、n8n 編輯器）、以主機行程執行的 Ollama（埠 11434，模型 embeddinggemma 與 gemma4:31b-cloud），以及 Docker Desktop（WSL2 虛擬機，Engine 29.8.0，24 核心，15.27 GiB 記憶體）。

右邊的 Docker 容器環境裡有六組 compose 專案，每一組都有各自獨立的網段。其中四組各自帶一個 SQL Server 容器（彼此不共用），另外兩組是 n8n：

專案・主機連接埠圖上標示的內容
dbgov15
5801／14334		web（5801）、sqlserver、worker（背景工作）、db-init（跑完就結束）
mcpplatform
5800／14333		web（5800）、sqlserver、demoapis（5080）、db-init
eric12
5802／14335		api（5802）、sqlserver，以及 db-init、migrate、db-grants 三個一次性作業；網段固定為 172.30.12.0/24
rag15
5805／14336		web（5805）、sqlserver，並連到主機上的 Ollama（圖上標「TypeSafe API」）
workspace
5679→5678		n8n-ubike（5678），連 YouBike API、Google Drive API 等外部服務
n8n
5678		官方 n8nio/n8n:latest 映像，教學用實例

有 SQL Server 的四組，圖上都標了兩個埠：前一個給網站或 API，後一個給 SQL Server（例如 dbgov15 的 5801 是網站、14334 是 SQL Server）。

對照前面的分享：dbgov15（埠 5801）與 mcpplatform（埠 5800）就是老師 9/27 分享的《Docker 微服務治理平台架構》裡的那兩套：Jev 資料庫治理平台，以及 MCP Server 治理平台。workspace 裡的 n8n-ubike 是 n8n × YouBike 資料工作流那門課的容器。eric12 與 rag15 的用途，圖上沒有寫。

怎麼讀這張圖

本課重點

  • Workflow Hub 在最上層，管七件事：登入授權、流程編排、Agent 設定、Skill 管理、MCP 工具、排程審批、執行監控。
  • 下面的 Docker 環境有六組專案，各有獨立網段；其中四組各自帶一個 SQL Server。
  • 虛線代表「規劃整合」：Workflow Hub 還沒有真正接上這些平台。
  • Ollama 跑在主機上，容器（例如 rag15）透過 host.docker.internal:11434 連過去。
01 / 07

第 02 課・p.02–03

核心哲學與交付成果

先搞懂整套設計最重要的一條規則：把「照表操課」和「需要判斷」分開放。再看這門課最後要做出哪六樣東西。

劃定邊界的藝術

系統願景與核心哲學：工作流引擎與 AI 代理
圖 p.02 系統願景與核心哲學：左邊是工作流引擎，右邊是 AI 代理，中間用虛線隔開；下方一句話點出核心原則。

左邊是「工作流引擎（Workflow Engine）」，負責順序控制、條件分支、週期排程與錯誤處理。它的特質是絕對的「決定論」：同樣的輸入、同樣的流程，一定得到同樣的結果，企業邏輯才穩定、可預測。

右邊是「AI 代理（Agent Runtime）」，負責讀取指定的 Skill、理解沒有固定格式的任務、提出工具呼叫（Tool Calls）。它的特質是受控的「非決定論」：同一件事可能有不同的處理方式，所以靈活、能解析非結構化的內容，也因為這樣才必須被管住。

核心原則：將「工作流程式控制」與「AI 任務執行」徹底分開。
用食譜想像：工作流引擎像食譜，先做什麼、再做什麼、火候到幾分鐘，都寫定了；AI 代理像廚師，只在「看食材狀況決定怎麼處理」的那一步發揮判斷。食譜不會因為廚師的心情改順序，廚師也只能在食譜劃好的那一格裡動手。

這門課最後要交出什麼

我們將建造什麼？最終交付成果解析
圖 p.03 最終交付成果解析：六個成果疊成一座機器，環繞著中間的齒輪方塊。
成果是什麼
視覺化編排器基於 Vue 3 與 Vue Flow，可拖曳、連線、儲存與發布。也就是使用者拉出流程的那個畫面。
Agent Skills 技術包經過嚴格審核上架、具備固定版本的指令集。可以想成給 AI 的「工作說明書」，審核過、版本鎖定才能用。
MCP 整合橋樑連接模型意圖與授權工具的雙向通道。AI 想用工具時，要經過的那道關卡。
MVC／API 雙核心處理前端頁面渲染，以及非同步的 JSON 請求。也就是網站的「畫面」與「資料介面」兩條腿。
Worker 執行緒獨立運作的排程與背景任務處理中心。沒人開網頁也照跑的背景工人。
AGENTDB以 SQL Server 驅動，集中管理權限、流程版本與執行日誌。「誰能做什麼、跑過什麼」都記在這裡。

本課重點

  • 核心原則只有一句：把「工作流程式控制」與「AI 任務執行」徹底分開。
  • 工作流引擎是「決定論」（結果可預測），AI 代理是「受控的非決定論」（有彈性，但被框住）。
  • 最終交付六件：視覺化編排器、Agent Skills 技術包、MCP 整合橋樑、MVC／API 雙核心、Worker 執行緒、AGENTDB。
02 / 07

第 03 課・p.04–05

分層架構與技術堆疊

系統怎麼一層一層蓋、每一層只准做自己的事，以及用到哪些技術。

五層架構：各管各的

系統分層架構圖（Separation of Concerns）
圖 p.04 系統分層架構圖（Separation of Concerns，關注分離）：由上到下共五層，中間的箭頭代表一層交給下一層。
層職責
Layer 1・Client
（Vue 3／Vue Flow）		只負責視覺化與拖曳，工作流的語意由後端來解釋。
Layer 2・Controllers
（MVC & Web API）		負責頁面渲染與 DTO 驗證（檢查送進來的資料格式），絕對不直接操作資料庫。
Layer 3・Services
（業務邏輯）		處理權限授權、流程發布與審核。
Layer 4・Engine & Runtime
（Workflow Engine／Agent Runtime）		流程狀態轉移與模型對話，不包含資料庫存取。
Layer 5・Data Access
（Repositories & 整合服務）		SQL Server 存取，以及 Ollama／MCP 連線。

這樣切的好處是：畫面只是一層外皮，真正的規則（誰能做什麼、流程代表什麼意思）都放在後端。引擎不碰資料庫，Controllers 也不直接碰資料庫，資料庫存取集中在最底下的 Data Access 層。每一層要改的時候，比較不會牽動其他層。

現代化技術堆疊

現代化企業級技術堆疊矩陣
圖 p.05 現代化企業級技術堆疊矩陣：後端核心、前端視覺、排程與執行、AI 與工具，四組技術。
類別用到的技術
後端核心
Backend Core		ASP.NET Core MVC＋Web API、.NET 10 LTS、EF Core（程式與資料庫之間的對照層）
前端視覺
Frontend Visual		Vue 3、Vue Flow（拖曳畫布）、Razor Views＋Bootstrap（古典書房與工坊風格）
排程與執行
Schedule & Worker		Quartz.NET（排程工具）、SQL Server 持久化、獨立 .NET Worker
AI 與工具
AI & Tools		Ollama Cloud（Gemma 4 31B 模型）、MCP Client（雙向工具整合）

後端這一側幾乎是一整套 .NET：ASP.NET Core、EF Core、Quartz.NET，加上獨立的 .NET Worker，資料庫則是 SQL Server。前端的拖曳畫布用 Vue，AI 則接 Ollama 上的 Gemma 模型。第 04 課的操作畫面，以及這份講義本身，都是同一種「古典書房與工坊」的視覺風格。

本課重點

  • 五層：Client → Controllers → Services → Engine & Runtime → Data Access，各層只做自己的事。
  • Controllers 與 Engine 都不直接碰資料庫；資料庫存取集中在 Data Access 層。
  • 技術選型：ASP.NET Core／.NET 10 LTS／EF Core、Vue 3／Vue Flow、Quartz.NET／SQL Server／.NET Worker、Ollama Cloud（Gemma 4 31B）／MCP Client。
03 / 07

第 04 課・p.06–07＋操作畫面

視覺化編排器與一條典型流程

看得見的部分：使用者怎麼在畫面上拖出一條自動化流程，以及老師貼出的真實操作畫面。

編排器的四個區域

視覺化編排器解剖（Anatomy of the Orchestrator）
圖 p.06 視覺化編排器解剖（Anatomy of the Orchestrator）：左邊節點庫、中間畫布、右邊屬性設定面板、下方測試結果與執行紀錄；最底下一排是八種節點。

圖最底下那一排，是節點庫裡的八種節點：

手動觸發人按一下才開始
排程觸發到指定時間自動開始
Agent Skill交給 AI，用一個審核過的技能處理這一步
MCP Tool呼叫一個有授權的外部工具，例如查資料
條件判斷依結果分岔，例如「有資料」或「沒資料」
資料轉換把資料整理成下一步需要的樣子
結果輸出把結果保存或記錄下來
結束流程收尾

典型工作流：從觸發到保存

典型工作流解析：從觸發到保存
圖 p.07 典型工作流解析：每日排程觸發，查詢待處理資料，判斷有沒有資料；有就請 AI 分析摘要再保存，沒有就記錄「無待辦事項」，最後都走到「結束」。
  1. 排程觸發（每日）：每天固定時間，流程自動開始。
  2. MCP Tool（查詢待處理資料）：透過已授權的工具，去查有沒有待處理的資料。
  3. 條件判斷（是否有資料？）：依查詢結果分成兩條路。
  4. 有資料：交給 Agent Skill（分析與摘要）處理，再由「結果輸出」保存結果，然後結束。
  5. 沒有資料：也不是什麼都不做，而是由「結果輸出」記錄「無待辦事項」，然後結束。
跨節點資料傳遞：節點可以引用上游節點的結果，例如 steps.queryOrders.output.orders；這個引用由平台「受限制的解析器」處理，杜絕任意程式碼注入。
白話：後面的節點可以「取用」前面節點的輸出，但只能用這種規定好的寫法去取，平台不會把你填的內容當成程式來執行，所以擋掉了「在欄位裡夾帶程式碼」這類攻擊。

真實操作畫面

Workflow Atelier 視覺化編排器操作畫面：每日訂單摘要流程
圖・操作畫面 Workflow Atelier 的視覺化編排器：左側深棕色選單、中間是「每日訂單摘要」流程、右側是選中節點的設定、下方是操作紀錄。
注意「固定版本 1.0.0」：流程節點引用的是「技能名稱＋釘死的版本」，而不是一份隨時可能被改動的活檔案。這正是第 05 課要講的「不可變版本」，在畫面上的樣子。
先驗證、再發布：工具列的「驗證」與「發布」是兩個按鈕。流程要先驗證，再發布成不可變的版本；排程只會綁定已發布的版本（第 06 課會再講）。

本課重點

  • 編排器分四區：節點庫、畫布、屬性設定面板、測試結果與執行紀錄。
  • 八種節點：手動觸發、排程觸發、Agent Skill、MCP Tool、條件判斷、資料轉換、結果輸出、結束。
  • 典型流程：排程觸發 → MCP Tool 查資料 → 條件判斷 → 有資料就交給 Agent Skill，沒有就記錄「無待辦事項」。
  • 節點之間傳資料只能走受限制的解析器，杜絕任意程式碼注入。
  • Agent Skill 節點填的是「技能名稱＋固定版本」，例如 order-summary 加 1.0.0。
04 / 07

第 05 課・p.08–10

AI 與工具怎麼被管住

這是整門課的重點：AI 那一步被三道規矩框住。技能要審核、版本要固定；模型呼叫要過六道關；工具授權不可繞過。

Agent Skills：像上架 App 一樣管技能

Agent Skills 技術包治理與版本控制
圖 p.08 Agent Skills 技術包治理與版本控制：左邊是技術包的資料夾結構，右邊是生命週期「草稿 → 待審核 → 核准 → 上架」，上架後會掛鎖。

一個技能就是一個資料夾，例如 skills/published/1.0.0/order-summary/，連版本號都寫在路徑裡。裡面有四樣東西：

技能要走完「草稿 → 待審核 → 核准 → 上架」，才能被流程拿去用；上架之後就「掛鎖」。

不可變版本原則：已上架的內容不得原地覆寫，要修改就必須建立新版本；目錄路徑由平台負責解析，防禦路徑穿越攻擊（有人想用 ../ 之類的寫法，跳到不該讀的檔案）。
順帶一提：這種「SKILL.md 加 references／scripts／assets」的資料夾寫法，和目前通行的 Agent Skills 格式是同一套（講義最後一頁也放了「Agent Skills 規格書」的標示）。差別在於這裡多了平台這一側的審核流程與不可變版本。

AI Runtime：六步管線把模型呼叫框住

AI Runtime：Ollama 與 Gemma 模型的安全整合
圖 p.09 AI Runtime：Ollama 與 Gemma 模型的安全整合。六個步驟由左到右，最下面是「金鑰隔離」。
  1. 取得設定：從節點讀出要用的 Skill ID 與固定版本。
  2. 安全驗證：檢查執行者的權限、技能是不是已上架，以及檔案雜湊對不對得上（雜湊像檔案的指紋，內容一被改動就對不上）。
  3. 載入資產：從核准目錄載入 SKILL.md 與參考資料。
  4. 組裝 Prompt：把任務輸入、平台規則與「允許使用的工具清單」組合起來。
  5. 模型呼叫：呼叫 Ollama Cloud 上的 gemma4:31b。
  6. Schema 驗證：驗證模型最後輸出的 JSON 格式對不對，才保存結果並留下稽核紀錄。
金鑰隔離：API Key 由伺服器端的環境變數提供，絕不暴露在前端、日誌或版本控制裡。

MCP 工具整合：兩種呼法，一條底線

MCP 工具整合：雙向迴圈與授權邊界
圖 p.10 MCP 工具整合：雙向迴圈與授權邊界。左右兩種呼法，最下面是共同的底線「授權不可繞過」。

直接 MCP Task（明確指定）

流程裡直接指定要用哪個 Tool；程式先驗證參數，再直接呼叫。

適用於確定性的 API 整合。

Agent Tool Call（模型自主提出）

模型從「允許清單」裡提出想用的 Tool Call；平台驗證授權與 Schema 之後，才去呼叫 MCP，再把結果交回給模型。

授權不可繞過：模型產生的工具名稱與參數，只是「執行請求」；平台會強制阻擋未經授權的越權呼叫，工具輸出也不得修改平台規則。
白話：AI 說「我要用某某工具」，只是遞上一張申請單，平台檢查過授權與參數才會真的執行；工具回傳的內容，也不能反過來指揮平台改規則。

本課重點

  • 技能是一個有版本的資料夾，要走「草稿 → 待審核 → 核准 → 上架」，上架後不可原地覆寫，要改就開新版本。
  • 模型呼叫走六步：取得設定、安全驗證、載入資產、組裝 Prompt、模型呼叫、Schema 驗證；金鑰只放在伺服器端。
  • MCP 有兩種呼法：流程直接指定，或由模型從允許清單提出；兩種都要過平台的授權檢查。
  • 模型產生的工具呼叫只是「執行請求」，不能繞過授權。
05 / 07

第 06 課・p.11–12

排程、資料與權限

流程不是只有人在網頁上按一下才會跑：有持久化的排程、有背景 Worker，還有一個集中管理權限與紀錄的資料庫。

持久化排程與 Worker：關掉瀏覽器也照跑

持久化排程引擎與 Worker 執行緒
圖 p.11 持久化排程引擎與 Worker 執行緒。副標寫著「即使會員關閉瀏覽器，自動化巨輪仍持續運轉」。

AGENTDB：資料模型與權限防護圈

AGENTDB 資料模型與權限防護圈
圖 p.12 AGENTDB 資料模型與權限防護圈：六組資料圍著中間的大鎖，鎖代表「權限防護圈」，下方一句話是底線「雙重驗證邊界」。
資料組放什麼
身分管理
Users／Roles		帳號、角色、停用狀態
工作流
Workflows／Versions		擁有者、草稿、不可變版本
執行
Runs／Invocations		狀態、耗時、重試、稽核
排程
Schedules／Quartz Tables		週期、綁定的版本
技術包
Skills／Reviews		路徑、雜湊、審核狀態
MCP
McpServers／ToolGrants		連線配置、授權清單
雙重驗證邊界：畫面上把按鈕藏起來，不能取代後端授權；API 與背景 Worker 在執行時，都必須嚴格驗證「資料擁有者」與「授權關係」。
白話：不能因為畫面上「看不到按鈕」，就以為別人做不到。後端每一次都要重新確認「這筆資料是不是你的、你有沒有被授權」，連背景 Worker 也一樣。

本課重點

  • 排程只綁「已發布版本」，事後再改草稿，不影響已排好的排程。
  • 前一次任務沒做完，預設略過重疊的執行並記錄；伺服器重啟後，排程由 Quartz.NET 與 SQL Server 恢復。
  • 對外部寫入結果不明的節點，標記成「待查核」。
  • AGENTDB 分六組資料：身分、工作流、執行、排程、技術包、MCP。
  • 授權要在後端強制驗證；畫面隱藏按鈕不算授權，背景 Worker 也要驗。
06 / 07

第 07 課・p.13–15

課程安排、驗收標準與結語

接著看這門 24 小時課程怎麼排、要驗收什麼，以及老師想表達的整體觀點。這一課提到的「課程地圖」，是老師原課程的地圖，跟上面的十課導覽不是同一張。

24 小時實戰課程地圖

24 小時實戰課程地圖（The 24-Hour Roadmap）
圖 p.13 24 小時實戰課程地圖（The 24-Hour Roadmap）：三段、十二節，像樓梯一階一階往上走。
段落四節內容（依序）
基礎架構
Sec 01–04		關注分離架構 → 會員授權與資料模型 → Vue Flow 拖曳畫布 → 流程儲存與不可變發布
引擎與 AI
Sec 05–08		無 AI 工作流引擎 → Skill 治理與審核 → Ollama 與 Prompt 組裝 → MCP Server 與授權工具節點
進階與維運
Sec 09–12		Agent 工具呼叫迴圈 → Quartz 持久化排程 → 執行監控與故障處理 → 端到端部署與驗收
順序是「先蓋沒有 AI 的確定性引擎，再接 AI」：Sec 05 先做無 AI 的工作流引擎，之後才依序接上 Skill、Ollama、MCP 與 Agent 工具呼叫。這正是第 02 課那條核心原則，排進了課表。第 04 課的操作畫面頁尾寫著「Section 03・拖曳畫布」，就是這張地圖裡第 3 節的成品。

企業級品質與端到端驗收標準

企業級品質與端到端驗收標準
圖 p.14 企業級品質與端到端驗收標準：驗收項目編號 A02、A04、A08、A10，這一頁只列了這四條。
編號・項目要驗證什麼
A02・絕對資料隔離會員無法透過篡改 ID，越權讀取他人的流程與結果。
A04・嚴格 Skills 治理未上架、遭停用，或雜湊不符的 Skill，絕對無法被 Invoke（呼叫）。
A08・背景排程韌性關閉瀏覽器、伺服器重啟之後，排程與 Worker 仍能精準觸發。
A10・企業級秘密保護Ollama API Key 與機敏資料，絕不外流到前端 JSON、瀏覽器或系統日誌。
怎麼讀這四條：A02、A04、A10 是「證明某件事做不到」：越權讀取、用不合格的技能、洩漏金鑰，都要證明做不出來。A08 則是「出了狀況之後照樣做得到」：關掉瀏覽器、重啟伺服器，排程照樣準時觸發。這一頁只列了四個編號，完整的驗收表沒有給。

結語：重塑工作流的未來

結語：重塑工作流的未來
圖 p.15 結語：重塑工作流的未來。下方三個 QR code 的標示是：Vue Flow 開發文件、Agent Skills 規格書、MCP 官方標準。

結語這一頁說：Workflow Atelier 不只是一門 24 小時的實戰課程，更是掌握 AI 時代企業自動化核心架構的藍圖；它要證明「嚴謹的傳統工程邊界」與「靈活的 AI 推論能力」，可以在 ASP.NET Core 架構下共存。

老師的五個核心主張

  1. 把「工作流程式控制」與「AI 任務執行」徹底分開。決定論的引擎管順序、分支、排程與錯誤；AI 只在被框住的節點裡做非決定論的部分（p.02，課程順序也是先蓋沒有 AI 的引擎）。
  2. AI 節點要被治理到「可版本、可審核、可稽核」。技能固定版本且不可變、工具走允許清單、輸出過 Schema、授權不可繞過（p.08–10）。
  3. 企業需求最後會回到「完全客製化平台」。不能只靠 Cowork 或 Openclaw 直接建專案、接 Connector／MCP／agent skill；所有資源必須完全治理與掌控，包含原生碼、系統流程與儲存環境（老師的轉貼文字）。
  4. 治理要在後端強制執行，而且要能驗收，不靠畫面。（p.12、p.14）
  5. 治理平台是一整組。Workflow Hub 還在開發；Java 側用 Spring Cloud 搭配 Netflix Eureka 的 API 治理平台（微服務平台）是最後缺的一塊，預定都在一台 Mac mini M4 上做整體測試（老師的轉貼文字）。

這份分享沒有講到的

  • 驗收標準只列了 A02、A04、A08、A10 四條，完整清單沒有給。
  • Workflow Hub 與 Workflow Atelier 的關係沒有明說：老師的文字寫的是 Workflow Hub，講義與操作畫面的名稱是 Workflow Atelier。看起來是同一套概念（推測：Atelier 是教學用的版本，Hub 是老師自己的平台）。09-30 的部署簡報多了一條線索，見第 10 課。
  • Java 側的 API 治理平台（Spring Cloud＋Netflix Eureka），講義與架構圖都沒有畫。
  • 使用 Ollama Cloud 時資料會不會送出境外、成本、授權與部署細節，這份分享沒有說明。

本課重點

  • 24 小時、十二節、三段：基礎架構（Sec 01–04）、引擎與 AI（Sec 05–08）、進階與維運（Sec 09–12）；先蓋無 AI 的引擎，再接 AI。
  • 驗收看四條：資料隔離（A02）、Skills 治理（A04）、排程韌性（A08）、秘密保護（A10）。
  • 老師的立場：企業要的是完全客製、完全掌控的治理平台；「嚴謹的工程邊界」與「靈活的 AI 推論」要能共存。
07 / 10

第 08 課・部署簡報 p.01–06＋操作畫面

部署全景：六個服務、兩個映像、四個常駐容器

09-30 老師又轉來一份 20 頁的部署簡報〈Docker Container 配置架構〉，講的是怎麼用 Docker 把這套平台裝起來：拆成幾個容器、各做什麼、誰先啟動。第 08 到 10 課整理的就是這份簡報，這一課先看全景和啟動順序。

隨簡報轉來的說明（原文，未修改）

Workflow HUB 治理平台 佈署架構(Docker Container)。請參考。六個Service，兩個Image。四個常駐Container。

白話讀法：整套平台拆成六個「服務」，但只用了兩種「映像」（可以想成兩種安裝包）：一種是微軟官方的 SQL Server 2025，另一種是老師自己建的 workflow-hub。六個服務裡有四個會一直開著（常駐），另外兩個只在啟動時跑一次，做完就結束。

跑起來的樣子

Workflow Atelier 編排器：北市即時資訊 Ubike 2.0 流程，Section 12 部署與驗收
圖・操作畫面（09-30） 編排器裡開著一條叫「北市即時資訊 Ubike 2.0」的流程，左下角頁尾寫「Section 12・部署與驗收」，也就是課程地圖的最後一節。流程目前是：每日排程 → MCP：查詢待處理資料 → 是否有資料 → 有就交給 Skill 分析與摘要，沒有就記錄無待辦事項 → 結束。右邊 MCP Tool 節點的 Server、Tool 欄位還是空的，右上角寫「尚未發布」，操作紀錄第 85 行是「尚未發布，無法執行。請先在編排器發布。」（截圖已裁掉瀏覽器網址列，也遮掉了左下角的登入帳號。）
怎麼讀這張：流程名稱已經換成 Ubike，但節點還是第 04 課「每日訂單摘要」那套範例的節點，MCP 也還沒接上任何伺服器，看起來是剛開始把 Ubike 題目搬進來（推測）。Ubike 這個題目老師之前用 n8n 做過一次，見n8n Ubike 那頁。另外，截圖網址是 localhost:5080，跟部署簡報裡 Docker 版對外的 5806 不一樣，推測這張是開發時直接執行的畫面，不是容器版（推測）。

封面與大綱

封面：Docker Container 配置架構
部署 p.01 封面〈Docker Container 配置架構〉，副標「compose 專案 workflow-hub：六個服務的角色、網路、儲存、秘密與互動關係」。來源標在範例資料夾「12_部署設定與成果驗收／docker」（docker-compose.yml、Dockerfile、init-db.sh），實測環境是 Docker Desktop・Windows 11・Linux 容器，日期 2026-09-29。
簡報大綱：六段
部署 p.02 大綱分六段，從全景看到細節：全景總覽、映像與啟動、各服務深入、互動流程、網路·儲存·秘密、維運與共存。

六個服務一覽

六個服務一覽：4 個常駐、2 個一次性
部署 p.03 六個服務一覽：4 個常駐、2 個一次性。compose 專案名稱叫 workflow-hub。
6個服務
4個常駐容器
2個一次性工作
2個映像
2個具名磁碟區
1個 bridge 網路
服務用哪個映像做什麼會一直開著嗎外面連得到嗎
sqlserverSQL Server 2025 官方映像資料庫，存放 AGENTDB常駐只有本機：127.0.0.1:14337
migrateworkflow-hub建立或升級資料庫結構一次性，做完結束不行
db-initSQL Server 2025 官方映像（借它的 sqlcmd）建排程要用的 14 張 QRTZ_ 表、建專用登入帳號 atelier_app一次性，做完結束不行
webworkflow-hub網站與 Web API，手動試跑也在這裡常駐可以：主機 5806 → 容器 5805
mcpdemoworkflow-hub示範用的 MCP Server（訂單工具）常駐不行，只在內部 :5301
workerworkflow-hub排程觸發、派送待執行的工作常駐不行，不開任何埠
對上老師那句話：六個 service＝上表六列；兩個 image＝SQL Server 2025 官方映像，加上老師自己建的 workflow-hub；四個常駐 container＝sqlserver、web、mcpdemo、worker。另外兩個（migrate、db-init）跑完就以結束碼 0 退出，所以用 docker ps 只會看到四個在跑。

整體架構圖

整體架構圖：Docker Desktop 主機上的六個服務與兩個磁碟區
部署 p.04 整體架構圖。最外框是 Docker Desktop 主機（Windows 11），裡面一層是 compose 自動建立的網路 workflow-hub_default（172.27.0.0/16）。線的顏色代表連線種類：HTTP、SQL（TDS）、MCP、sa 結構變更、磁碟區掛載、對外 HTTPS。
誰連到誰怎麼連
使用者的瀏覽器web主機 5806 → 容器 5805（HTTP）
web、workersqlserverSQL（TDS :1433），用專用帳號 atelier_app
web、workermcpdemoMCP :5301，請求帶 X-Api-Key
web、workerOllama Cloud（外部 LLM）對外 HTTPS /api/chat
migrate、db-initsqlserver用 sa 帳號改資料庫結構
管理者（SSMS／sqlcmd）sqlserver只能從本機 127.0.0.1:14337 連
web、workerappdata 磁碟區掛在 /data：技術包、金鑰
sqlserversqldata 磁碟區掛在 /var/opt/mssql：資料庫檔案

一個映像、四種用途

多階段 Dockerfile：一個映像、四種用途
部署 p.05 多階段 Dockerfile：第一階段用 .NET 10 SDK 編譯，第二階段只把成品複製進比較小的 ASP.NET 10 執行環境。產出的 workflow-hub:latest 實測 723 MB。

白話：老師只做了一個安裝包 workflow-hub，裡面同時放了四樣東西：web、worker、mcpdemo 三支程式，加上升級資料庫用的 efbundle。容器啟動時用 entrypoint 指定「這次要跑哪一支」，同一個映像就能當四種服務用：預設跑 web；worker、mcpdemo 改寫 entrypoint；migrate 跑 ./efbundle。

  1. 先只複製專案檔再還原套件：套件沒變的話這一步沿用快取，重新建置比較快。
  2. 安裝 dotnet-ef 10.0.12：用來產生資料庫升級工具。
  3. 複製原始碼，發布三支程式：Web、Worker、McpDemo，都用 Release 設定。
  4. 產生 migration bundle：輸出到 /app/db/efbundle，給 migrate 用。

執行時用非 root 的 app 使用者，開 5805 埠；/data 底下放技術包（skills/published、staging）和金鑰（keys）。

啟動順序

啟動順序：depends_on 條件串成的相依圖
部署 p.06 啟動順序：下 docker compose up -d --build 之後，compose 照 depends_on 的條件一個接一個啟動；每次 up 都會先重跑 migrate 和 db-init。
  1. sqlserver 先起來：每 10 秒跑一次 SELECT 1，最多試 20 次，回報 healthy 才往下走。
  2. migrate 用 sa 建立或升級資料庫結構：成功結束（結束碼 0）才往下走。
  3. migrate 成功後，db-init 和 mcpdemo 啟動。
  4. db-init 成功結束後，worker 和 web 啟動。web 另外等 mcpdemo「已經啟動」，但只等它啟動，不檢查它準備好了沒。
三種等法：「等健康」是等 healthcheck 回報 healthy；「等成功結束」是等一次性容器以結束碼 0 結束，失敗的話後面的服務都不會啟動；「等已啟動」只等容器開起來，不檢查能不能用（web 對 mcpdemo 就是這種）。

本課重點

  • 六個服務、兩個映像、四個常駐容器：常駐的是 sqlserver、web、mcpdemo、worker；migrate、db-init 跑完就結束。
  • 老師只做了一個 workflow-hub 映像，靠 entrypoint 切換，當 web、worker、mcpdemo、migrate 四種服務用。
  • 啟動順序靠條件保證：資料庫健康 → 建結構 → 建排程表與登入帳號 → 常駐服務。
08 / 10

第 09 課・部署簡報 p.07–13

各服務深入與兩條互動流程

這一課把六個服務一個一個打開來看，最後用兩張序列圖對照「手動試跑」和「排程執行」各走哪條路。

sqlserver：整個平台唯一的狀態中心

sqlserver：平台唯一的狀態中心
部署 p.07 sqlserver 的容器設定，右邊是 AGENTDB 裡有什麼（實測 35 張資料表），以及兩種登入帳號的權限。
項目設定
版本SQL Server 2025，Developer 版
對外埠127.0.0.1:14337 → 1433，只開給本機
資料放哪具名磁碟區 sqldata → /var/opt/mssql
密碼從 SA_PASSWORD 帶入，沒設就拒絕啟動
健康檢查sqlcmd 跑 SELECT 1，每 10 秒、逾時 5 秒、重試 20 次、開機寬限 20 秒
重啟策略unless-stopped（除非手動停掉，否則掛了就重開）
時區Asia/Taipei

AGENTDB 裡有兩類表：平台自己的表（工作流、執行紀錄、技術包、MCP 伺服器與工具呼叫、排程、稽核、帳號），以及 Quartz 排程器的 14 張 QRTZ_ 系統表（worker 重啟後靠這些表把排程還原）。帳號分兩種：sa 只給 migrate、db-init 改結構；atelier_app 給 web、worker 用，只能讀寫資料，不能改結構。

migrate 與 db-init：只跑一次的資料庫初始化

migrate 與 db-init：一次性的資料庫初始化
部署 p.08 兩個一次性服務：都設定成不自動重啟，做完以結束碼 0 退出，而且可以重複執行。
migratedb-init
用哪個映像workflow-hubSQL Server 2025 官方映像（借裡面的 sqlcmd）
做什麼等資料庫健康 → 套用 EF Core migration（全新資料庫會跑 9 個）→ 已經是最新就不動 → 結束，放行 db-init 和 mcpdemo建 Quartz 的 QRTZ_ 表（已存在就略過）→ 建立或更新專用登入 atelier_app（重跑時可以換密碼），給它讀寫資料的權限
安全細節用 sa 連線改結構三支腳本用唯讀方式掛進容器；sa 密碼放在環境變數 SQLCMDPASSWORD，不出現在命令列；用 UTF-8 讀含中文的腳本
「可以重複執行」為什麼重要：專有名詞叫「冪等」，意思是跑一次跟跑十次結果一樣。因為每次 docker compose up 都會重跑這兩個服務，如果不是冪等的，每重開一次資料庫就可能被弄亂一次。

web：網站與 Web API

web：平台網站與 Web API
部署 p.09 web 容器內部的請求處理流程，右邊是健康檢查的實測結果。

一個請求進來的路線：瀏覽器 → 主機 5806 → 容器裡的 Kestrel（5805，目前是 HTTP，沒有設 TLS）→ 登入與防偽造檢查（Cookie、CSRF）→ MVC 控制器 11 個加 API 3 個 → 核心服務（工作流引擎、節點執行器）。核心服務再往外連：資料庫、mcpdemo、Ollama Cloud，還有 /data 底下的技術包和金鑰。

健康檢查項目實測結果
hostHealthy
skillsHealthy（已上架的技術包：0 個版本）
databaseHealthy（AGENTDB 連得上）
modelDegraded：用的是 FakeChatModel（模擬模型）
綠燈不等於真的能用：執行環境裡沒有 curl，所以健康檢查改用 bash 內建的 /dev/tcp 去打 /api/health，回 200 就算健康。問題是整體狀態 Degraded 時也照樣回 200，docker ps 會顯示 healthy。實測當下沒填 Ollama 金鑰，AI 那一步用的是模擬模型，容器卻還是綠燈。要打開 /api/health 看內容，才知道模型是假的。

worker：排程與派送

worker：Quartz 排程與工作派送
部署 p.10 worker 不開任何埠，裡面跑四個背景服務，各自有自己的節奏。
背景服務多久一次做什麼
ScheduleSyncWorker每 15 秒把網站上設定的排程，同步成 Quartz 的工作與觸發時間（考慮時區、錯過時間怎麼補）
Quartz Scheduler時間到就觸發觸發時只建立一筆「待執行」紀錄，用預定時間防止重複
RunDispatcherWorker每 5 秒用「原子領取」把待執行紀錄拿去給工作流引擎跑；啟動時把上次中斷的標成「結果不明」
PlatformMonitorWorker每 30 秒呼叫共用的健康檢查，寫進日誌

白話：排程時間到，worker 不是馬上執行，而是先「掛號」（寫一筆待執行）；另一個每 5 秒巡一次的派送員再把掛號單領走、真正執行。「原子領取」的意思是同一張掛號單不會被兩個人同時領走，所以不會重複執行。

mcpdemo：只在內部網路的示範 MCP Server

mcpdemo：只在內部網路提供的示範 MCP Server
部署 p.11 mcpdemo 沒有對外的埠，主機連不到它，只有同一個 compose 網路裡的 web、worker 叫得到。
  1. 管理頁登錄端點：網址填 http://mcpdemo:5301/mcp，金鑰欄只填一個名字 MCP_DEMO_ORDERS_KEY，不填金鑰本身。
  2. 執行時才去找真正的金鑰：照這個名字到設定裡找實際的值，找不到就直接失敗。
  3. 放進請求標頭送出：用 X-Api-Key 標頭帶過去，連線逾時 15 秒。
  4. mcpdemo 這邊先驗金鑰：對不上就回 401；對得上才提供兩個工具：list_pending_orders（列出待處理訂單，一次 1～50 筆）和 get_order（用訂單編號查，例如 A001）。
資料庫只存金鑰的「名字」：真正的金鑰只放在部署機的 .env 裡。這對上第 05 課講的「金鑰只放伺服器端」。

兩條互動流程：手動試跑 vs. 排程執行

序列圖一：使用者在 web 手動試跑工作流
部署 p.12 序列圖①：使用者在網站上按「試跑」，整條流程在 web 容器裡跑完。
序列圖二：排程觸發到 worker 執行
部署 p.13 序列圖②：排程觸發由 worker 負責；web 和 worker 從頭到尾不直接對話，只透過 AGENTDB 交換狀態。
手動試跑（p.12）排程執行（p.13）
誰發動使用者在網站按試跑時間到，Quartz 觸發
在哪裡跑web 容器worker 容器
步驟讀流程定義、建立執行紀錄 → 讀技術包並驗 SHA-256 → 呼叫 Ollama → 呼叫 MCP 工具 → 寫入節點結果、工具呼叫、稽核 → 畫面顯示明細web 把排程寫進資料庫 → worker 每 15 秒同步 → 觸發時建「待執行」→ 每 5 秒原子領取並執行 → 結果寫回（標記觸發來源是排程）→ 使用者在執行歷程頁看
為什麼要讓 web 和 worker 互不呼叫：兩邊只靠資料庫交換狀態，任一邊重開都不用通知另一邊。推論起來，網站暫時掛掉時排程照樣會跑；worker 掛掉時網站照樣能開，只是排程不會執行（推論，簡報沒有直接寫）。

本課重點

  • AGENTDB 是唯一的狀態中心；sa 只給兩個一次性服務改結構，平日用只能讀寫的 atelier_app。
  • docker ps 顯示 healthy 不代表全部正常：模型用的是模擬模型時仍回 200，要看 /api/health 的內容。
  • 排程是「先掛號、再派送」，原子領取防重複；手動試跑在 web，排程執行在 worker，兩邊只透過資料庫溝通。
09 / 10

第 10 課・部署簡報 p.14–20

網路、儲存、秘密與維運

最後一課看「上線之後」的事：哪些門開著、資料放在哪、密碼怎麼保管、出事時會怎樣，以及同一台機器上跟其他專案怎麼共存。

網路與連接埠：只開必要的門

網路與連接埠：只開放必要的入口
部署 p.14 compose 自動建一個 bridge 網路 workflow-hub_default，服務之間用「服務名稱」找對方（Docker 內建 DNS）。容器 IP 會變，所以連線一律寫服務名稱。
主機這邊接到哪個容器誰連得到
0.0.0.0:5806web :5805主機所有網路介面，區網裡的人都連得到
127.0.0.1:14337sqlserver :1433只有本機（給 SSMS 用）
（沒有對外）mcpdemo :5301只有 compose 網路裡的服務
（沒有對外）worker它根本不開埠
上線前要補的那一格：簡報自己列了已知限制：目前沒有 TLS，網站走 HTTP。web 又綁在 0.0.0.0，區網連得到，所以對外之前要在前面放反向代理（IIS、Nginx 之類）處理 HTTPS，或直接在 Kestrel 設憑證。埠號為什麼是 5806、14337：主機的 5805 已經被 rag15 專案的網站用了，14333～14336 被其他專案的 SQL Server 用了，只好往後排。

儲存：兩個具名磁碟區，加三個唯讀掛載

儲存：兩個具名磁碟區＋三個唯讀掛載
部署 p.15 容器隨時可以砍掉重建，狀態只存在磁碟區裡；web 和 worker 必須看到同一份技術包。
磁碟區裡面放什麼誰用
appdata → /dataskills/staging（上傳、審核中的技術包）、skills/published（已上架，執行前驗 SHA-256）、keys（Data Protection 金鑰，網站拿來加密登入 Cookie 用的，本身沒有加密）web 寫、worker 讀
sqldata → /var/opt/mssqlAGENTDB 資料檔、交易記錄、備份sqlserver
三個唯讀掛載init-db.sh、app-login.sql、quartz-tables.sqldb-init

簡報列的三條備份原則

  • sqldata 和 appdata 要在同一個時間點一起備份，不然資料庫記的雜湊或路徑，會跟磁碟上的技術包對不上。
  • Linux 容器沒有 Windows 的 DPAPI 可以保護金鑰，keys 是明文，所以備份檔本身要加密保存。
  • 不要用 docker compose down -v：加了 -v 會連具名磁碟區一起刪掉，資料就沒了。

設定與秘密：密碼只放在一個地方

設定與秘密：.env → compose 變數 → 環境變數
部署 p.16 秘密只放在 docker/.env，版控和映像都把它排除；範本 docker/.env.example 只有變數名稱，沒有值。

密碼的流向：docker/.env（只在部署機上）→ compose 讀進來做變數替換，缺值就拒絕啟動 → web、worker 共用同一組設定 → 變成容器裡的環境變數。下表是每個秘密會發給哪些服務，沒打勾的服務拿不到：

變數用途發給誰
SA_PASSWORDsa 密碼（改結構用）sqlserver、migrate、db-init
APP_DB_PASSWORDatelier_app 的密碼db-init、web、worker
MCP_DEMO_ORDERS_KEYMCP 金鑰（呼叫的一方和驗證的一方用同一把）web、worker，以及 mcpdemo（當成它的 ApiKey）
OLLAMA_API_KEYOllama Cloud 金鑰；空白就改用模擬模型web、worker
ADMIN_EMAIL／PASSWORD第一次啟動時建立管理者web
WEB_PORT主機對外的埠（預設 5806）web
最小權限落在哪：web、worker 拿不到 sa 密碼；mcpdemo 只拿到自己那把金鑰。這對上第 06 課的「權限防護圈」，只是這次是在部署層做。

健康檢查、重啟策略與出事時會怎樣

健康檢查、重啟策略與故障行為
部署 p.17 一句話：設定錯了就不啟動、外部依賴不在就降級、執行中斷就交給人查。
階段做法
啟動前：快速失敗啟動時檢查連線字串、技術包資料夾的路徑；錯了就不啟動，不帶病上線。
執行中：降級但不中斷沒有 Ollama 金鑰就改用模擬模型（狀態 Degraded）；已上架的技術包資料夾不存在就回 503。
中斷後：交給人查核重開時還在跑的排程執行，一律標成「結果不明」，不自動重跑。
為什麼不自動重跑：跑到一半被中斷的流程，可能已經呼叫過外部工具（例如寫了一筆資料）；自動重跑可能讓同一件事做兩次，所以寧可停下來讓人判斷。另外，worker 找不到 QRTZ_ 表就起不來；mcpdemo 沒有 ApiKey 也不啟動。

同一台機器上的其他專案

主機共存：同一台 Docker Desktop 上的 compose 專案
部署 p.18 實測 docker ps：同一台 Docker Desktop 上跑著七個 compose 專案，各自一個網路、彼此隔離；只有發布到主機的埠會互相撞到。
compose 專案網站埠SQL Server 埠在跑的容器
n8n127.0.0.1:5678—n8n
n8n-docker0.0.0.0:5679—n8n-ubike
mcpplatform127.0.0.1:5800127.0.0.1:14333web、demoapis、sqlserver
dbgov15127.0.0.1:5801127.0.0.1:14334web、worker、sqlserver
eric120.0.0.0:5802127.0.0.1:14335api、sqlserver
rag15127.0.0.1:5805127.0.0.1:14336web、sqlserver
workflow-hub（本專案）0.0.0.0:5806127.0.0.1:14337web、worker、mcpdemo、sqlserver

埠號有規律：網站用 58xx，SQL Server 用 1433x，一個專案佔一號。這張表也對上第 01 課整合架構圖下半部那些「已經放進 Docker 的平台」：n8n-ubike、rag15、資料庫治理平台等，實際上都跑在同一台機器上。前面幾次分享整理過的頁面見 n8n Ubike、MCP 治理、Docker 治理。

維運指令速查

維運指令速查
部署 p.19 在範例根目錄（12_部署設定與成果驗收）執行的指令。左半是部署與升級（已實測），右半是檢查與排錯。
要做什麼指令
1. 準備秘密Copy-Item docker\.env.example docker\.env（再填值；.env 不進版控）
2. 建置並依序啟動docker compose -f docker/docker-compose.yml up -d --build
3. 冒煙測試pwsh deploy\smoke.ps1 -WebUrl http://localhost:5806（回 200 才算成功）
看狀態docker compose -f docker/docker-compose.yml ps -a（一次性工作應該是 Exited (0)）
追日誌docker compose -f docker/docker-compose.yml logs -f worker
看網路成員與 IPdocker network inspect workflow-hub_default
看健康檢查明細curl http://localhost:5806/api/health

這一頁最下面再提醒一次三件事：docker ps 顯示 healthy 不等於全部正常，要看 /api/health 的 model 是不是 Degraded；sqldata 和 appdata 要同一時間點備份，金鑰是明文，備份要加密；docker compose down 會保留磁碟區，加了 -v 就連資料一起刪。

總結：六個容器，一個狀態中心

總結：六個容器，一個狀態中心
部署 p.20 總結頁的六句話。
  1. 一個映像、四種用途：web、worker、mcpdemo、migrate 共用同一個映像，用 entrypoint 區分。
  2. AGENTDB 是唯一的協調點：web 和 worker 不互相呼叫，排程與執行狀態都經過資料庫交換。
  3. 啟動順序由條件保證：資料庫健康 → 建結構 → 建 QRTZ_ 與登入帳號 → 常駐服務。
  4. 最小權限、最小暴露：sa 只給一次性工作；只開 5806 和本機的 14337；秘密只在 .env。
  5. 狀態只在磁碟區：sqldata 和 appdata 同時備份，容器隨時可以重建。
  6. 看得見、能降級：/api/health 分項回報；中斷的執行交給人查核。

這份部署簡報沒有講到的

  • 實測環境是 Windows 11 的 Docker Desktop；頁首老師那段話提到預定整體測試用的 Mac mini M4，簡報沒有講會不會搬、要改什麼（SQL Server 2025 官方映像在 Apple Silicon 上怎麼跑也沒提）。
  • TLS 只列為已知限制，還沒有實際的反向代理設定。
  • 實測時 Ollama 用的是模擬模型、已上架技術包是 0 個版本；接上真的 Ollama Cloud 與真的技術包之後的結果，這份沒有。
  • 第 07 課那題「Workflow Hub 和 Workflow Atelier 是什麼關係」多了一條線索：部署的 compose 專案與映像叫 workflow-hub，裡面的程式檔叫 WorkflowAtelier.Web.dll 等。看起來是同一套程式，用 Hub 的名字部署（推測）。

本課重點

  • 對外只開一扇門：web 的 5806（區網可連、還沒 HTTPS）；資料庫只開給本機，mcpdemo 和 worker 完全不對外。
  • 狀態只在 sqldata、appdata 兩個磁碟區；兩個要同時備份，金鑰是明文要加密備份，千萬別下 down -v。
  • 秘密只在 .env，缺值就拒絕啟動；每個服務只拿到自己需要的那幾把。
  • 出事時的三段設計：啟動前快速失敗、執行中降級、中斷後標「結果不明」交給人，不自動重跑。
10 / 10・完課
名詞小抄
治理（Governance）
不只是「能用」，而是誰能用、用哪個版本、做了什麼，都有規則，也留得下紀錄。
決定論／非決定論
決定論：同樣的輸入一定得到同樣的結果。非決定論：同樣的輸入可能得到不同的輸出，AI 生成文字就是這樣。
Agent Skill（技能）
給 AI 的一份「工作說明書」資料夾，裡面有指令、業務規則、輸出範本，有時還有腳本。
MCP（Model Context Protocol）
讓 AI 模型用統一的方式呼叫外部工具的標準。
Tool Call（工具呼叫）
AI 提出「我要用某個工具、帶這些參數」的請求。
Schema
規定資料長什麼樣子的格式表，例如 JSON 要有哪些欄位、各是什麼型別。
雜湊（Hash）
從檔案內容算出來的一串「指紋」；內容只要被改動，指紋就對不上。
Worker
在背景默默做事的程式，不需要有人開著網頁。
稽核（Audit）
把「誰在什麼時候做了什麼」留成事後查得到的紀錄。
Docker／compose 專案
Docker 把程式包成容器來執行；compose 專案是把一組相關的容器一起定義、一起啟動。
映像（Image）／容器（Container）
映像像安裝包，容器是用安裝包開起來、正在跑的那一份；同一個映像可以開出好幾個容器。
healthcheck（健康檢查）
Docker 定時問容器「你還好嗎」的小指令；回答正常就標成 healthy。
具名磁碟區（Volume）
容器外面的一塊儲存空間。容器砍掉重建，磁碟區裡的資料還在。
冪等
同一個動作做一次跟做十次，結果一樣。
反向代理／TLS
擋在網站前面的一層，負責處理 HTTPS 加密（TLS），再把請求轉給後面的網站。
想看原始檔案的完整版本？ 下載原始講義 PDF（15 頁） 下載部署簡報 PDF（20 頁）