Agent 實作 — 常見的工作流模式 (workflow patterns)

先前在 AI 代理是什麼? 一文中，我們談到 2025 年的 AI 關鍵字是代理；在 2025 的年中，各大公司都開發了自己的 AI 代理產品。以工程師會用到的產品來說，OpenAI 的 CodeX、Anthropic 的 Claude Code、Google 的 Jules 都在相近的時間點發表。

在 AI 代理高速發展的同時，不同的工作流 (workflow) 也逐步匯聚成形。在開發 AI 代理時，比起使用現有的框架，更推薦回到根本來思考，這時掌握基本的工作流，搭配所在的領域，去客製化自己的 AI 代理，獲得的成果也往往會比較好。

代理 (agent) 與工作流 (workflow) 的區別是什麼?

之所以需要 AI 代理或工作流，是因為代理能夠幫忙解決某些特定的問題；然而，許多問題其實可以不用代理，也能順利解決。如果能清楚界定兩者的不同，在選擇要用什麼解決方案時，也能夠更精準地選到適合的方案。

在 Anthropic 的《Building effective agents》一文中，有對兩者清楚的區別。文中談到，所謂的工作流 (workflow)，是設定既定的路徑，然後讓 AI 在既定的路徑中去執行不同任務。目前在社群中可以看到像是 n8n 或者 Zappier 這類工具，都偏向工作流這一個分類。使用者預先設定某個流程，例如要為某個演講做摘要，可以設定先請 AI 把演講錄音轉成文字，接著進到下一步把文字做順稿，最後再把順好的文字擷取重點精華。

在這個工作流中，雖然錄音轉文字、文字順稿、擷取精華，這些步驟都會用到 AI，但是這些流程是預先設定好的，而非由 AI 在運作的過程中自己決定的。而因為根據在 AI 代理是什麼? 一文提到的代理定義，AI 代理不需要事先設定好的流程，只需要目標，就會自行完成指定的任務，所以這種既定的流程，還不能算是代理，而只能被稱為工作流。

AI 代理不一定是最佳的解決方案

雖然說工作流並非代理，在技術難度上比較低，但是推薦讀者們不要輕忽工作流的好。身為一個工程師，重要的不只是技術，而是要能解決問題。如果用一個比較簡單的工作流，就能解決問題，那即使不用 AI 代理，也完全沒問題。

退一步來說，給定的工作流效率通常會比較高。因為 AI 代理本身牽涉到思考、推理、規劃等步驟，這些都需要時間，因此假如某一個問題，用工作流跟用代理都能解決，通常用工作流的速度會比較快，因為步驟已經設定好，所以能夠省去代理額外花費的時間。省時間之外，通常也能省下額外的成本，因為 AI 代理做的推理與規劃，都是需要額外消耗 token、需要額外花費的。

因此，如同殺雞焉用牛刀，在選擇用 AI 代理的解決方案前，先探索是否有更簡單、更快速、更省成本且可達到目標的方案，會是更推薦的做法。

然而，什麼時候該選擇用 AI 代理呢? 推薦是只有在工作流不足以滿足需求時，再來評估是否用 AI 代理。這種狀況通常代表，某一個任務比較複雜，或者某一個任務可能有比較多不同的變異狀況，因此很難用簡易的工作流來處理所有情境，這種狀況下，使用 AI 代理就會是更合適的選擇。

舉例來說，協助工程師完成程式的程式代理 (coding agent) 選擇用代理就會比工作流更合適，因為不同的程式實作，需要的步驟不同，這時如果預設了某個工作流，很可能導致既定的流程不符合解決問題所需的步驟，導致無法順利解決問題。

常見的的工作流模式

在了解完 AI 代理與工作流的區別後，接著讓我們來看有什麼常見的 AI 工作流。以下我們會主要談 Anthropic 發布的《Building effective agents》一文中，談到的不同工作流模式。

連結模式 (Chaining Pattern)

首先，連結模式是最常見的模式，我們前面提的整理會議記錄的例子，就屬於連結模式。當某一個任務，能夠具體地被拆成不同步驟，然後每一個步驟的成果，能被用在下一個步驟做為輸入，這時候連結模式就是很不錯的選擇。

特別注意，在連結模式的某一個節點，都可以加入閘門 (gate)，所謂的閘門是檢查輸出的結果是否如預期，可以有簡易的檢查，也可以搭配另一個 LLM 模型來幫忙檢查。

連結模式 (Chaining Pattern)

以整理會議記錄的範例來說，可以先請 AI 把演講錄音轉成文字，這時文字輸出就可以做為下一步的輸入，請大型語言模型順稿(例如把錯別字更正)，順完稿的內容又能做為輸入，請 LLM 來擷取重點精華。假如以程式碼來表示，會是像下面這樣

// 連結模式的主要部分
// audioToText、runLLM 以及 isValidOutput 等效用函式具體會是呼叫第三方效用函式
async function processAudioToSummary(
  audioFile: string,
  promptChain: string[]
): Promise<string[] | string> {
  const responseChain: string[] = [];
  let response = await audioToText(audioFile);

  // 檢查音檔轉文字結果，isValidOutput的檢查做的就是閘門在做的事
  if (!isValidOutput(response)) return response;
  responseChain.push(response);

  // 依序處理每個提示詞
  for (const prompt of promptChain) {
    response = await runLLM(prompt, response);
    if (!isValidOutput(response)) return response;
    responseChain.push(response);
  }

  return responseChain;
}

// 不同步驟的提示詞
const promptChain = [
  "將文字轉錄內容進行順稿，確保語句通順且符合邏輯。",
  "將內容分段，並標記每段的主題。",
  "根據順稿後的內容，擷取最重要的三點精華。",
];

// 使用範例，audioFile 會來自使用者
await processAudioToSummary(audioFile, promptChain);

閱讀更多

以上我們介紹了工作流與代理的區別，也談了連結模式。除了這個模式外，還有其他常見的工作流模式，我們在 E+ 成長計畫中的主題文都有談到。

對更深入了解這個主題，以及其他前後端開發、軟體工程、AI 工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。