最近看到一篇論文，讓我重新想 AI workflow 的核心問題不是生成速度
最近看了一篇 arXiv 論文，題目是「From Specification to Execution: AI Assisted Scientific Workflow Management」，發表於 2026 年 6 月。作者把 LLM 接上 Pegasus workflow management system，並加了一個 LLM-based debugging agent，用醫療影像 federated learning workflow 做驗證。
嚴格來說，這篇不是在討論「LLM 能不能生成 workflow code」，而是在問：生成之前，有沒有先做對事情？
大部分把 LLM 用在 workflow 自動化的做法，都是直接讓模型輸出程式碼。速度快、看起來很聰明，demo 做起來也好看。問題是：出錯了怎麼辦？誰知道它為什麼這樣生成？生成結果能不能被驗證？如果兩週後換一個人來接這個 workflow，他能不能看懂發生了什麼事？
這篇論文的做法是把整個流程拆成幾層：先做 structured specification，把 intent、design、implementation 分開，驗證過後才進行 generation，之後還有 debugging 和 distributed execution 幾個階段。它沒有跳過中間層，直接從「我想做 X」跳到「這是程式碼」。
這個選擇讓我覺得很有意思，因為它的核心是在建立一個「中間表示」。
我在研究 LLM 的過程中有個觀察：很多研究在 benchmark 上跑得很好，但真正進到 production 的比例非常低。差異通常不在生成能力，而在可驗證性、可重現性、以及 failure handling。如果你的系統只是「LLM 輸出程式碼就去跑」，那 debug 的時候你根本不知道要從哪裡下手，是 prompt 問題？模型的問題？還是下游系統的問題？
這篇論文提出的 LLM-based debugging agent，可以跨多層系統診斷失敗原因。這在大規模 scientific workflow 裡特別重要，因為你可能跑的是上千個 job，一個地方壞掉，追蹤起來很麻煩。
Pegasus + MCP 的組合提供了統一的 workflow submission 和 monitoring 介面。MCP 這個選擇我覺得值得注意，它讓 LLM 跟既有的 workflow system 有一致的互動方式，不是每個系統都要重寫一套整合邏輯。
從 NLP 研究者的角度來看，這篇論文真正有價值的地方在於：它把「工作流程設計」這件事，從只有少數人掌握的隱性專家知識，轉成可驗證、可除錯、可交接的中間表示。之前你要設計一個好的 federated learning workflow，需要理解很多分散式系統的細節，非專家進入門檻很高。這個框架讓非專家也能產出接近專家水準的設計，不是因為 LLM「知道答案」，而是因為多了一層 structured validation 讓錯誤更早浮現。
這跟 AI 輔助寫作、AI 輔助 code review 有類似的邏輯：LLM 本身不保證正確，但加上合理的流程設計，可以讓錯誤更早被發現、更容易被修正。
談 AI workflow 自動化的文章不少，但大多數停在 demo 層面。這篇從 specification phase 開始設計，真的有在想 production 環境裡的問題，包括 failure handling、可重現性、和跨層診斷。這才是從實驗室到真實部署那一段路上，最容易被忽略但最重要的事。
作者：陳思維