Prompt flow 的 DAG 與 flow.dag.yaml：把 prompt 從筆記本推進到 CI 的取捨
Build high-quality LLM apps - from prototyping, testing to production deployment and monitoring.
秒懂
- 它是什麼？
- 微軟的 Prompt flow 用一份 YAML 描述節點與連線，把 LLM、prompt 與 Python 程式碼串成可執行流程。它解決的是提示詞版本失控與評測無法重跑的問題，代價是你要接受一套新的專案結構。
- 適合誰用？
- 如果你的團隊已經在用 Python 寫 LLM 應用，而且痛點是「同一個 prompt 改了三次卻說不出哪版比較好」，Prompt flow 的 flow.dag.yaml 加上批次評測流程值得先花一個下午試跑。反過來說，如果你的應用是一支單檔腳本、或你打算把流程邏輯放在既有框架的程式碼裡，額外引入一層 YAML 只會增加同步負擔，此時不必採用。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 20 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是提示詞散落在程式碼裡的問題
多數 LLM 專案的起點是一支 Python 腳本：字串拼接 prompt、呼叫 API、印出結果。改到第五版之後，prompt 散在函式裡、參數寫死在 f-string 中，想比較兩版差異只能靠手動複製貼上。Prompt flow 的切入點就是把這件事結構化。README 的說法是它「links LLMs, prompts, Python code and other tools together」，產出的東西叫 flow，是一個可執行的單元，而不是一段被埋在應用裡的程式碼。
目標讀者很明確：需要把原型推進到有品質門檻的團隊。README 把開發週期拆成三步，develop a flow、improve the flow quality、deploy the flow to production，其中第二步是它真正想賣的東西。官方另有一份十五分鐘教學，路線是 prompt tuning 到 batch testing 再到 evaluation。換句話說，它假設你已經有能力寫出一個能跑的 prompt，問題出在無法證明改動是否真的變好。
這個定位也解釋了為什麼它同時提供 CLI 與 VS Code 擴充。CLI 對應的是自動化與 CI，擴充對應的是互動式調整。兩者共用同一份 flow 定義，這是一致性的來源，也是後面所有限制的來源。
flow.dag.yaml 是整個專案的中樞
一個 flow 的核心是一份 flow.dag.yaml。README 對它的描述是「outlines the flow, including inputs/outputs, nodes, connection, and the LLM model」。這是理解 Prompt flow 的關鍵：它不是把 prompt 寫在 Python 裡再由程式讀取，而是反過來，YAML 是事實來源，Python 節點是被 DAG 呼叫的執行單元。
節點之間靠輸入輸出接線，形成有向無環圖，這也是 DAG 這個名字的來歷。每個節點可以是 LLM 呼叫、prompt 模板，或是一段 Python 工具程式碼，README 用 tools 這個詞統稱後者。以 pf flow init 產生的聊天範本為例，裡面有一個 chat 節點，該節點在 YAML 中透過 connection 欄位指定連線名稱，透過 deployment_name 欄位指定模型。README 特別提醒，deployment_name 用來指定 OpenAI 模型，或 Azure OpenAI 的部署資源名稱，這兩種語意並不相同。
這種設計的直接好處是流程圖可以被工具解析。VS Code 擴充能畫出設計介面，靠的就是這份結構化描述；追蹤 LLM 互動也是沿著節點邊界記錄。代價是流程的形狀被限制在 DAG 能表達的範圍內，而且任何繞過 YAML 直接寫在 Python 裡的邏輯，都不會出現在設計介面上，也不會被評測流程自動涵蓋。
安裝與第一次執行的實際指令
README 建議的 Python 版本是 python>=3.9, <=3.11。安裝指令是 pip install promptflow promptflow-tools，兩個套件要一起裝，後者提供內建工具節點。README 另外提供 GitHub Codespaces 的預建環境，不想處理本機環境的話可以從那裡開始。
建立第一個 flow 用範本產生：pf flow init --flow ./my_chatbot --type chat。這會建立 my_chatbot 資料夾並產生所需檔案，包含 flow.dag.yaml 與連線用的 YAML 檔。
接著是連線設定，這一步最容易被忽略。OpenAI 的情況是 pf connection create --file ./my_chatbot/openai.yaml --set api_key=<your_api_key> --name open_ai_connection。Azure OpenAI 則是 pf connection create --file ./my_chatbot/azure_openai.yaml --set api_key=<your_api_key> api_base=<your_api_base> --name open_ai_connection。README 說明 --set 的用途是覆蓋 YAML 檔中的值，避免把金鑰寫進檔案，這一點在共用儲存庫時尤其要遵守。
最後用 pf flow test --flow ./my_chatbot --interactive 進入互動測試，結束按 Ctrl + C。要注意範本裡的 chat 節點預設連線名稱是 open_ai_connection、模型是 gpt-35-turbo。如果你在建立連線時換了 --name，就必須回頭改 flow.dag.yaml 的 connection 欄位，否則執行時會找不到連線。
評測能進 CI，但前提是資料集與指標要先想清楚
README 把「Evaluate your flow's quality and performance」列為三大能力之一，具體做法是用更大的資料集評測，並把測試與評測整合進 CI/CD 系統。這是 Prompt flow 相對其他提示詞管理工具最實質的差異：它把評測當成一等公民，而不是事後補上的腳本。
不過 README 只給了方向，沒有給指標清單。官方十五分鐘教學的路線是 prompt tuning、batch testing、evaluation 三段，另外有一份 chat with PDF 的端到端教學，示範如何建立聊天應用並用指標評測。這意味著「用什麼指標」是你自己的決定，Prompt flow 提供的是執行與比較的框架。
要留意的是評測本身有成本。用更大的資料集意味著更多次模型呼叫，而 LLM 輸出帶有隨機性，同一份 flow 跑兩次不會得到完全相同的分數。文件沒有保證評測結果的穩定性，實務上你得自己決定重複次數與判定方式。把評測接進 CI 之後，這個成本會變成每次提交的固定支出，值得先估算再決定觸發條件。
什麼情況下這套結構反而礙事
第一個明顯的限制是 Python 版本。README 明講建議 3.9 到 3.11。如果你的環境已經在 3.12 或更新版本上，官方文件並沒有給出相容性承諾，這不是可以靠 pip 參數繞過的類型問題。
第二個限制來自 YAML 與程式碼的雙軌。當流程需要條件分支、迴圈或複雜的錯誤處理時，你得判斷哪些放進 DAG、哪些留在 Python 節點裡。放進 DAG 的邏輯看得見但表達力受限，放進 Python 的邏輯自由但脫離了視覺化與自動評測的覆蓋範圍。這個界線沒有標準答案，卻是每次改動都要面對的判斷。
第三種不適合的情況是單檔應用。如果你的 LLM 邏輯就是一支腳本、一個函式，沒有多節點協作、也不需要跨版本比較品質，那麼引入 flow.dag.yaml 只會多出一份要同步維護的檔案。Prompt flow 的價值來自流程的複雜度與評測的需求，兩者都不存在時，它的結構就是純粹的負擔。
另外，README 把雲端版 Prompt flow in Azure AI 標為 optional but highly recommended，用詞是協作。這暗示單機 CLI 與雲端版本在團隊協作能力上有落差，但 README 沒有說明具體差異，這部分需要另外查 Azure AI 的文件才能判斷。
與 LangChain 的差別在於事實來源放在哪裡
LangChain 是這個領域最常被拿來對照的專案。兩者都能串接 LLM 與工具，但把「事實來源」放在不同位置：LangChain 以 Python 程式碼為主體，鏈的結構由程式碼中的物件組合決定；Prompt flow 則以 flow.dag.yaml 為主體，程式碼是被 DAG 呼叫的節點。
這個差異會直接影響工具鏈。因為結構寫在 YAML 裡，Prompt flow 能提供視覺化設計介面與 CLI 的 pf flow test，也能讓評測流程沿著節點邊界收集資料。相對地，LangChain 的流程是程式碼，除錯靠的是 Python 的除錯工具與日誌，視覺化需要額外接入。
反過來說，程式碼即結構的作法在處理複雜控制流程時更直接。當你需要動態決定要呼叫哪個工具、或根據中間結果改變後續路徑時，用 Python 寫比在 DAG 裡描述來得自然。兩者並非誰取代誰，而是取決於你希望流程的定義是可被工具解析的資料，還是可被程式設計師自由操作的程式碼。Prompt flow 選擇了前者，也就接受了前者帶來的表達限制。
維護成本與 MIT 授權的實際含義
從版本節奏看，promptflow 1.17.1 發佈於 2025 年 1 月 9 日，1.17.0 在三天前的 1 月 6 日，1.16.2 則在 2024 年 11 月 25 日。這種小版本密集推出的節奏，意味著升級時要預期行為可能變動，尤其是 CLI 參數與 YAML 結構這類對外介面。專案最後一次推送時間為 2026 年 8 月，且未封存，仍在維護中。
實務上的維護成本主要落在兩處。一是 flow.dag.yaml 的結構變更，這會影響所有既有的 flow；二是 promptflow-tools 提供的工具節點，升級時要確認你依賴的節點行為沒有改變。由於這兩者都是執行時的必要條件，建議在升級前先跑一次既有的評測流程，用分數變化當作升級的檢查點。
授權是 MIT，這在採用上相對單純，允許修改與再散布。但要注意 README 中提到的雲端版本 Prompt flow in Azure AI 屬於另一項服務，其條款與計費方式不在 MIT 授權範圍內，兩者不應混為一談。這裡不構成法律意見，若涉及商用再散布，仍應由法務確認授權條文與第三方依賴的授權疊加情況。
編輯結論
如果你的團隊已經在用 Python 寫 LLM 應用，而且痛點是「同一個 prompt 改了三次卻說不出哪版比較好」，Prompt flow 的 flow.dag.yaml 加上批次評測流程值得先花一個下午試跑。反過來說，如果你的應用是一支單檔腳本、或你打算把流程邏輯放在既有框架的程式碼裡，額外引入一層 YAML 只會增加同步負擔，此時不必採用。動手前先確認三件事：本機 Python 是否落在 3.9 到 3.11 之間、pf connection create 的 --set 是否能正確覆蓋 openai.yaml 裡的 api_key、以及 flow.dag.yaml 中 chat 節點的 connection 與 deployment_name 是否指向你實際要用的模型與部署資源。這三項沒對上，後面的評測數字就沒有意義。
社群筆記