在AI快速融入生產系統的發展格局中，編排工具正在爭相適應變化。最近釋出的 Airflow AI SDK 為希望將語言模型整合到現有工作流基礎設施中的團隊提供瞭解決方案，引發了關於AI時代工作流編排未來的討論。
工作流編排領域正在分化
社群討論揭示了工作流編排空間的顯著分化。雖然 Apache Airflow 仍被廣泛使用，擁有十年可靠性的記錄，但像 Prefect、Dagster、Temporal、Hatchet 和 Hamilton 等新興競爭者正在挑戰其主導地位。每個平臺都帶來了管理工作流的不同方法，複雜性和靈活性各不相同。
許多從業者對當前工作流編排工具的狀態表示不滿。有些人認為 Airflow 雖然老舊但可靠，而其他人則對特定實現如亞馬遜的 Managed Workflows for Apache Airflow (MWAA) 感到困擾，一位使用者將其描述為垃圾，因為存在效能問題和無法解釋的崩潰。這種不滿推動了對替代方案的探索，儘管尚未出現明確的繼任者。
「我在大約1.5年前做了深入調查，最終結論是直接使用 airflow 進行構建。你要麼獲得簡單性，但代價是你的系統需要完美對齊。要麼獲得複雜性，但基本上可以與任何東西配合使用（airflow）。」
確定性LLM增強 vs. 完全代理式工作流
從業者如何看待AI整合到工作流中，一個有趣的模式浮現出來。許多人質疑完全代理式工作流是否對大多數用例必要，認為具有針對性LLM增強的確定性流程可能更實用、更可靠。這代表了一種更保守的AI整合方法，將LLM作為傳統工作流中的元件而非自主代理。
Airflow AI SDK 透過提供像 @task.llm 和 @task.agent 這樣的裝飾器解決了這一中間地帶，允許開發人員在熟悉的 Airflow 任務正規化中整合LLM呼叫和代理行為。雖然一些評論者質疑這些裝飾器相比直接函式呼叫的價值，但SDK的作者澄清說，它們啟用了特定於 Airflow 的功能，如日誌分組，從而提高了可觀察性。
Airflow AI SDK 的主要特點
- @task.llm：定義呼叫語言模型處理文字的任務
- @task.agent：使用自定義工具編排多步驟 AI 推理
- @task.llm_branch：基於 LLM 輸出改變 DAG 控制流
- 自動輸出解析：使用函式型別提示進行解析和驗證
- 模型支援：支援 OpenAI、Anthropic、Gemini、Ollama、Groq、Mistral AI、Cohere
社群對工作流工具的關注點
- Airflow：被視為老舊但可靠；日誌記錄和部署方面存在操作問題
- MWAA：效能問題，包括由於持續 DAG 解析導致的高 CPU 使用率
- 較新的替代方案：Prefect 因本地除錯和 K8s 整合而受到讚揚
- 資料庫原生：基於 PostgreSQL 的工作流解決方案受到越來越多的關注
資料庫原生AI工作流受到關注
幾條評論強調了對資料庫原生方法處理AI工作流的興趣。像 PostgresML 和自定義 Postgres 原生工作流引擎等解決方案正被探索作為傳統編排工具的替代方案。這些方法將AI能力直接整合到資料庫系統中，透過消除單獨的編排層潛在地簡化了架構。
這一趨勢反映了透過利用現有資料庫基礎設施而非新增專門的編排工具來減少複雜性的願望。對於不需要複雜DAG的簡單工作流，帶有整合LLM呼叫的資料庫觸發器提供了一個吸引人的替代方案，使處理更接近資料。
未來可能屬於動態執行引擎
討論中的一個反覆出現的主題是傳統工作流工具如 Airflow 是否適合高階AI工作流的動態特性。一些評論者對現有工具有效處理代理工作流的能力持極度悲觀態度，認為設計用於高動態執行的平臺如 Temporal 或像 DBOS 這樣的新進入者可能更有優勢。
基本挑戰在於，許多傳統工作流引擎是圍繞靜態、預定的執行圖設計的，而複雜的AI工作流通常需要動態、自適應的執行路徑，能夠響應前一步驟的輸出。這種靜態編排與動態執行之間的張力代表了行業面臨的一個關鍵架構挑戰。
隨著組織繼續將AI整合到其運營系統中，用於編排這些工作流的工具和模式可能會繼續發展。Airflow AI SDK 代表了一種將傳統編排與現代AI功能連線起來的方法，但社群討論表明，我們在確定這些混合系統的最佳模式方面仍處於早期階段。