> ## Documentation Index
> Fetch the complete documentation index at: https://felimet-hub.jmcores.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 01-5 Workflow Engineering：把多步任務編排成可重複流程

> prompt engineering 管這一句怎麼問，context engineering 管視窗裡該有什麼，workflow engineering 管的是多步驟用什麼結構串起來、誰先誰後、哪裡放關卡。

export const LearnerPrimer = ({items = [], lang = "zh"}) => {
  const t = lang === "en" ? {
    title: "Before this unit, be honest with yourself",
    sub: "If you can't answer these, that gap is exactly what this unit closes."
  } : {
    title: "讀這個單元前，先誠實面對",
    sub: "這幾題答不出來，正是這個單元要替你補的洞。"
  };
  const css = `
  .lp-root{--lp-bg:#FAF7F1;--lp-surface:rgba(191,117,81,0.05);--lp-border:rgba(0,0,0,0.09);--lp-edge:rgba(191,117,81,0.42);--lp-text:#2b2722;--lp-dim:#6f6a62;--lp-accent:#bf7551;border:1px solid var(--lp-border);border-left:3px solid var(--lp-edge);border-radius:13px;background:var(--lp-bg);color:var(--lp-text);overflow:hidden;margin:1.25rem 0;}
  .dark .lp-root{--lp-bg:#1b1a18;--lp-surface:rgba(207,138,104,0.07);--lp-border:rgba(255,255,255,0.08);--lp-edge:rgba(207,138,104,0.5);--lp-text:#e7e3da;--lp-dim:#a8a299;--lp-accent:#cf8a68;}
  .lp-head{display:flex;align-items:center;gap:9px;padding:13px 18px 11px;border-bottom:1px solid var(--lp-border);background:var(--lp-surface);}
  .lp-ic{color:var(--lp-accent);flex-shrink:0;}
  .lp-htx{display:flex;flex-direction:column;gap:1px;min-width:0;}
  .lp-title{font-size:14px;font-weight:650;line-height:1.3;letter-spacing:.01em;}
  .lp-sub{font-size:12px;color:var(--lp-dim);line-height:1.4;}
  .lp-list{list-style:none;margin:0;padding:10px 18px 14px;display:flex;flex-direction:column;gap:0;}
  .lp-item{display:flex;align-items:baseline;gap:11px;padding:7px 0;font-size:14px;line-height:1.6;border-top:1px solid var(--lp-border);}
  .lp-item:first-child{border-top:none;}
  .lp-mark{flex-shrink:0;color:var(--lp-accent);font-size:13px;font-weight:700;line-height:1.55;font-variant-numeric:tabular-nums;opacity:.85;}
  .lp-q{flex:1 1 0;min-width:0;color:var(--lp-text);}
  @media (max-width:620px){.lp-head{padding:12px 14px 10px;}.lp-list{padding:8px 14px 12px;}}
  `;
  return <div className="lp-root">
      <style>{css}</style>
      <div className="lp-head">
        <svg className="lp-ic" xmlns="http://www.w3.org/2000/svg" width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round"><circle cx="12" cy="12" r="10" /><circle cx="12" cy="12" r="6" /><circle cx="12" cy="12" r="2" /></svg>
        <span className="lp-htx">
          <span className="lp-title">{t.title}</span>
          <span className="lp-sub">{t.sub}</span>
        </span>
      </div>
      <ul className="lp-list">
        {items.map((q, i) => <li className="lp-item" key={i}>
            <span className="lp-mark">{String(i + 1).padStart(2, "0")}</span>
            <span className="lp-q">{q}</span>
          </li>)}
      </ul>
    </div>;
};

<LearnerPrimer
  lang="zh"
  items={[
"workflow 不修爛 prompt，只把它放大成更爛。",
"你把可平行的串成 pipeline，慢了三倍。",
"fan-out 後接 barrier，快的分支乾等最慢的。",
"loop-until 沒設上限，就是燒錢機器。",
"上游錯誤沒攔下，下游每步都在替它放大。",
"你拆得太細，狀態管理成本超過任務本身。",
"看起來該用 agent 的任務，多半好好寫 workflow 就解了。",
]}
/>

<Info>
  **這個單元解決什麼問題**

  單次 prompt 解不了的多步任務，靠 workflow 編排：拆解、串接、平行、驗證、收斂。prompt engineering 管「這一句怎麼問」，context engineering 管「視窗裡該有什麼」，workflow engineering 管的是「這些步驟用什麼結構串起來、誰先誰後、哪裡放關卡」。把這層做對，多步流程才會可重複、可審查、不靠運氣，而不是每跑一次結果都不一樣。
</Info>

## 學習目標

* [ ] 能判斷一個任務何時超出單次 prompt 的範圍、需要 workflow 才能可靠執行，並分清「workflow」與「agent」的界線。
* [ ] 能把複合目標拆解成有依賴關係的步驟，辨識哪些可平行、哪些必須有序（DAG 思維）。
* [ ] 能套用 pipeline、fan-out、barrier、loop-until 等原語，並對應到 Anthropic 歸納的五種具名模式。
* [ ] 能在流程的關鍵節點放入對抗式驗證與收斂關卡，防止上游錯誤靜默傳遞。

***

## 1. 何時需要 workflow：單 prompt 的天花板在哪

**當任何一步的輸出是下一步的輸入、而且這個中間結果難以在同一個上下文裡可靠地維持時，你就需要 workflow。** 反過來說，能在一次 prompt、一個上下文視窗內穩定完成的，就別拆，拆了只是徒增延遲與狀態管理成本（見第 8 節常見誤區）。

單次 prompt 會撞到三道牆：

* **輸出長度**：模型單次回應有 token 上限，要它一口氣產出一份長報告加完整程式碼加測試，要嘛截斷，要嘛每段都草草帶過。
* **上下文深度**：任務需要「記住前面算出來的中間結果」再往下做時，這些中間結果會擠在同一個視窗裡互相稀釋，觸發 01-4 講的 lost in the middle 與 context rot。
* **外部取值**：某一步要先去查資料庫、跑測試、抓網頁，拿到結果才能決定下一步怎麼走。單輪 prompt 沒有「停下來取值再繼續」的結構。

典型超出邊界的任務：大型程式碼重構（跨多檔、要先理解再改再驗）、多文件摘要比對（先各自摘要再交叉比對）、迭代品質提升（產出 → 評估 → 修正 → 再評估）、資料管線（抓取 → 清洗 → 轉換 → 載入）。共同特徵都是「中間結果要落地、要被下一步消費」。

<Tip>
  **workflow 與 agent 不是同一件事**

  Anthropic 在 *Building Effective Agents* 裡的區分是：**workflow 是「LLM 與工具被預先寫好的程式路徑編排」的系統；agent 是「LLM 自己動態決定流程與工具用法、自行掌控如何完成任務」的系統** \[1]。

  差別在「誰決定下一步」。workflow 的步驟與跳轉是你預先以程式碼定義好的，模型只在每個節點內做事；agent 是你給它目標與工具，由它自己規劃步驟。本單元先把 workflow 練到位，因為它**可預測、可重現、好除錯**；agent 的彈性要付出可控性的代價，那是 01-6 harness 的範疇。實務上絕大多數「看起來需要 agent」的任務，一個設計良好的 workflow 就解決了，而且更穩。
</Tip>

## 2. 拆解與依賴：DAG 思維

把複合目標拆成步驟，最可靠的方法是**從終點往回問**：「這個最終輸出，直接需要哪些東西？」每個答案再往上追一層「那它又從哪來？」，追到不可再分的原子步驟為止。比起從頭往下想「第一步做什麼」，逆推不容易漏掉隱含的前置步驟。

拆完之後，把步驟畫成一張有向圖：節點是步驟，邊是依賴（A → B 表示 B 要用到 A 的輸出）。這張圖必須**無環**（acyclic），有環代表 A 等 B、B 又等 A，會死鎖。這就是 DAG（directed acyclic graph，有向無環圖）思維。

DAG 一畫出來，平行機會就自己浮現了：**沒有路徑相連的節點，可以同時跑**。

```mermaid theme={null}
graph LR
  A["抓取原始資料"] --> B["清洗 / 去重"]
  B --> C1["摘要來源 1"]
  B --> C2["摘要來源 2"]
  B --> C3["摘要來源 3"]
  C1 --> D["交叉比對 / 找矛盾"]
  C2 --> D
  C3 --> D
  D --> E["撰寫報告"]
```

這張圖裡，C1、C2、C3 三個摘要步驟互不依賴，可以平行；但它們全都得等 B 完成（要清洗後的資料），也全都得在 D 之前完成（比對要三份摘要都到齊）。D 就是一個天然的**屏障點**（barrier，見第 3 節）。

拆解最常犯兩種相反的錯：

* **把可平行的串起來**：明明 C1/C2/C3 互不相干，卻一個做完才做下一個。沒有錯誤，只是白白把三步的時間加總，慢三倍。
* **把有依賴的平行掉**：把 D（比對）和 C（摘要）同時發動，D 拿到的是還沒算完的摘要，產出不一致甚至基於空值。這種錯比較隱蔽，因為它「跑得很快」，但結果是錯的。

## 3. 常見模式：從機械原語到具名模式

四個原語（primitive）是你編排時實際操作的積木；Anthropic 把它們組合成五個更高層的具名模式。先掌握積木，再認得組合，遇到新框架只是換語法。

**四個機械原語：**

* **pipeline（串接）**：A → B → C，每步輸出餵給下一步。適合線性轉換。對應 Anthropic 的 **prompt chaining**：把複雜任務拆成依序的步驟，每步之間可以插程式化檢查點（checkpoint）確認進度再往下 \[1]。
* **fan-out（扇出）**：同一個輸入同時送給多個平行步驟。適合對同一份資料做多視角分析（同時查安全、效能、型別）。
* **barrier（屏障）**：等所有平行分支都完成才繼續。fan-out 之後通常接 barrier 再聚合。fan-out + barrier 合起來就是 Anthropic 的 **parallelization**，它又分兩種變體：**sectioning**（把任務切成互不相干的子任務同時跑）與 **voting**（同一個任務跑多次拿多個獨立結果再表決）\[1]。
* **loop-until（收斂迴圈）**：重複執行直到驗證通過或達上限。適合品質迭代與自我修正。對應 Anthropic 的 **evaluator-optimizer**：一個 LLM 呼叫產出、另一個給評分與回饋，在迴圈裡逼近合格 \[1]。

<Warning>
  **barrier 是有代價的，預設用 pipeline**

  一個常見的過度同步：先 fan-out 三個分支、用 barrier 等全部完成、再把結果統一往下送。但如果三個分支裡有一個特別慢，barrier 會讓另外兩個快的乾等。除非下一步**真的需要所有分支的結果一起到齊**（例如要跨全部結果去重、或比對彼此），否則讓每個分支各自獨立往下走（pipeline 化）才不浪費。判準：下一步是否需要「跨分支的全局資訊」？需要才設 barrier，不需要就別擋。
</Warning>

**何時模式會「升級」成 agent？** 上面四個原語的跳轉都是你預先定義好的。當「要拆成哪些子任務」這件事本身得由模型看了輸入才能決定，預先寫不出來，你就需要 Anthropic 的另外兩個模式：

* **routing（路由）**：先用一個分類步驟判斷輸入屬於哪一類，再導向對應的專門處理。本質還是 workflow（路由表是你定的），但多了一層動態分派。
* **orchestrator-workers（協調者-工作者）**：一個中央 LLM 動態拆解任務、把子任務分派給 worker、再綜合結果 \[1]。和 parallelization 的關鍵差別是：**子任務不是預先定義的，而是 orchestrator 看了輸入才決定的**。到這一步，你已經一腳踏進 agent 領域了，控制權部分交給了模型。

**一個你手邊就有的具體 workflow：對抗式程式碼審查**

場景：審查一個分支的改動。用 pipeline 把「審查」和「驗證」兩階段串起來，並對多個維度 fan-out。

```text theme={null}
維度清單 = [正確性， 安全性， 效能， 風格]
對每個維度（pipeline，互相獨立、不設 barrier）：
  階段 1：spawn 一個子代理審查該維度 → 回傳 findings（結構化）
  階段 2：對每條 finding，spawn 獨立子代理「對抗式查證」→ 回傳 verdict
最後：收集所有 verdict.isReal == true 的 findings
```

為什麼這樣設計：四個維度互不相干，pipeline 化讓「正確性」的查證在「效能」還在審查時就能開跑，不被最慢的維度拖住（對照上面的 barrier 警告）。階段 2 的對抗式查證是第 4 節的重點，先記住它的位置。Claude Code 的子代理（Task 工具）與 SDK 層的 orchestrator 模式正是為這種編排設計的（截至 2026-05）\[2]。

## 4. 驗證與收斂：在關鍵節點放對抗式驗證

不放驗證的後果很具體：上游一個小錯，會在後續每一步被當成正確前提繼續放大，等到三步後產出明顯不對時，你已經難以歸因是哪一步壞的，而且中間每一步消耗的 token 全部白費。**驗證關卡的價值，是把錯誤擋在它還便宜的時候。**

「驗證」最弱的形式是讓同一個模型自己檢查自己，但模型傾向認同自己剛才的輸出，效果有限。更強的是**對抗式驗證（adversarial verify）**：用不同視角、或獨立的模型呼叫，去「挑戰」前一步的輸出，而不是「確認」它。

兩個關鍵設計手法：

* **角色換成挑剔者**：驗證步驟的 prompt 不要寫「檢查這個結果對不對」，要寫「試圖反駁這個結論，不確定時預設判為不成立」。把舉證責任反過來，假陽性才壓得下去。
* **多視角而非多份相同**：若一個結論可能以多種方式出錯，給每個驗證者不同的鏡頭（正確性、安全性、能否重現），比跑三份一模一樣的檢查更能抓到不同的失效模式。這正是 Anthropic parallelization 裡 voting 的用法 \[1]。

收斂關卡（尤其 loop-until）必須有三個明確的出口條件，缺一個都可能在生產環境變成資源黑洞：

1. **通過標準**：用結構化的 pass / fail schema，不要用「看起來還行」這種模糊判斷。
2. **最大重試次數**：迭代到第 N 次仍不過就停，別無限迭代。
3. **逾時退出**：單輪或整體超過時間上限就中止。

**loop-until + 對抗式驗證的收斂迴圈**

任務：產生一段要併入主幹的程式碼，要求通過測試且無明顯安全問題。

```text theme={null}
bugs_confirmed = []
for round in 1..MAX_ROUNDS:          # 最大重試上限
    候選 = 生成步驟（任務， 前一輪回饋）
    # 對抗式：3 個獨立 reviewer，各自試圖反駁「這段是安全且正確的」
    votes = parallel(reviewer_1, reviewer_2, reviewer_3)
    refute_count = count(v for v in votes if v.refuted)
    if refute_count == 0:            # 通過標準：無人能反駁
        return 候選                  # 收斂，跳出
    回饋 = 彙整（votes）               # 把反駁意見餵回下一輪
return 失敗（"未在上限內收斂"）        # 出口：別讓它無限轉
```

三個 reviewer 平行跑（fan-out + barrier 等票），多數能反駁就打回重來。沒有 `MAX_ROUNDS` 這行，一旦遇到模型怎麼改都過不了的案例，這個迴圈會燒到你發現帳單為止。Claude Code 的 Stop hook 可以充當這個收斂哨兵，在每回合結束時做確定性的 pass / fail 檢查（截至 2026-05）\[2]。

## 5. 概念階梯定位

在工程四層裡，workflow 佔 L3：它向下依賴 L2 context 的品質，向上需要 L4 harness 兜底（四層由淺入深，見 01-3 prompt、01-4 context、本單元 workflow、01-6 harness）：

```text theme={null}
L1 Prompt engineering   ── 單次請求怎麼寫
L2 Context engineering  ── 視窗裡該有什麼
L3 Workflow engineering ── 多步驟用什麼結構串（本單元）
L4 Harness engineering  ── 讓整套穩定運轉的外殼（監控、權限、kill switch）
```

兩條邊界要記牢：

* **向下接 context**：workflow 的每一個節點，本質上都是一次 context 組裝。節點產出的品質，上限由你給它的 context 品質決定（見 [01-4](/code-agent/foundations/context-engineering)）。workflow 結構再漂亮，單個節點的 context 設計爛，產出一樣爛。**workflow 放大良好設計，也放大爛設計。**
* **向上接 harness**：workflow 只描述「步驟怎麼串」，它不負責「跑壞了誰來踩剎車」。把監控、權限邊界、記憶持久化、kill switch 加上去，才是完整的 agentic harness（見 [01-6](/code-agent/foundations/harness-engineering)）。只做好 L3 卻不設 L4 的 kill switch，等於裝了賽車引擎卻沒有剎車。

這個定位也直接破掉兩個常見誤判：把 workflow 當成能修復爛 prompt 的萬靈丹（它不能，它只放大），以及把某個 agentic 框架當成做 workflow 的唯一選項（多數時候一段帶迴圈與條件判斷的程式就夠了）。

## 工具對照

把多步編排落地，主要有三類載體，適用場景不同（截至 2026-05）：

* **Claude Code 的子代理編排**：在 orchestrator prompt 裡用 Task 工具 spawn 多個子代理，每個子代理有獨立上下文、自己的工具集，只回傳最終結論而非過程 \[2]。適合「編排對象就是 LLM 工作」且想留在 Claude 生態內的情況。Anthropic 於 2026-05-28 推出研究預覽的 Dynamic Workflows 作為更大任務的編排層、以及以 git 共享工作區協作的 Agent Teams （截至 2026-05，研究預覽）\[2]。
* **n8n**：視覺化低程式碼 workflow，節點對應步驟，強項是整合大量外部服務（資料庫、API、訊息平台）。其 AI 能力以 LangChain 為底，提供 70 個以上 AI 節點，AI Agent 節點預設走 Tools Agent，並支援「工具執行前需人工核准」的 human-in-the-loop （截至 2026-05）\[4]。適合流程橫跨許多 SaaS、且希望非工程角色也能看懂改動的場景。
* **LangGraph**：以 Python / TypeScript 把流程描述成圖，三個原語是 State（所有節點共享的狀態）、Node（讀寫 state 的函式）、Edge（直接或條件跳轉）。1.2 版（2026-05-11 釋出）把一次 agent 執行當成可持久的圖執行（durable execution），靠 checkpointing 在每個節點存檔，server 重啟也能從斷點續跑 \[3]。適合需要細粒度控制、狀態持久化與 human-in-the-loop 的 agentic 流程。

三者的取捨：除錯可見性 n8n（視覺化）最直觀；細粒度控制與可測試性 LangGraph 最強；想完全留在 Claude 生態、編排對象就是 LLM 子任務，Claude Code 子代理最省事。

| 概念                | Anthropic Claude（主範本）                           | OpenAI                            | Google                                              | GitHub Copilot                  | Cursor               |
| ----------------- | ----------------------------------------------- | --------------------------------- | --------------------------------------------------- | ------------------------------- | -------------------- |
| 多步任務編排入口          | Claude Code Task 工具 / 子代理；SDK orchestrator 模式   | Agents SDK / Responses API（含工具呼叫） | Vertex AI Agent Builder；Gemini API function calling | Copilot coding agent（雲端自主、開 PR） | Background agents    |
| 平行子任務（fan-out）    | orchestrator prompt 內 spawn 多個 Task 子代理，各自獨立上下文 | Agents SDK 多代理 handoff            | 官方文件未作對等說明                                          | 官方文件未作對等說明                      | Background agents 平行 |
| loop-until / 自我修正 | orchestrator 條件判斷再呼叫；Stop hook 作收斂哨兵            | Agents SDK 迴圈 + guardrails        | 官方文件未作對等說明                                          | 官方文件未作對等說明                      | 官方文件未作對等說明           |
| 外部 workflow 整合    | n8n、LangGraph 皆可呼叫 Claude API                   | n8n、LangGraph 皆支援 OpenAI          | n8n、LangGraph 皆支援 Gemini                            | 經 API 整合                        | 經 API 整合             |

<Note>
  **對照表只給座標，不給細節**

  各 cell 的精確機制名稱、版本與設定路徑屬快變動事實，部分以較穩定的描述呈現；官方文件無對應說明者以各官方文件為準。本表用途是讓你知道「同一個編排概念在你的工具叫什麼」，深入設定見 Part II 與 Part IV。
</Note>

## 動手做

兩個練習，從紙上拆解到實際編排：

1. **把一個現有手動任務畫成 DAG。** 挑一個你平常手動跑的多步流程（例如：蒐集資料 → 各別摘要 → 交叉比對 → 撰寫報告）。畫出節點與依賴邊，標出哪些節點可平行（沒有路徑相連的）、哪些必須有序。再問每個節點三件事：輸入從哪來、輸出給誰用、通過標準是什麼。哪個節點最該加驗證關卡（通常是「錯了會被下游當正確前提放大」的那個）？

2. **用 Claude Code 實作一個最小 pipeline。** 三步串接，第二步驗證第一步的輸出：

   ```text theme={null}
   # orchestrator prompt 的骨架（交給 Claude Code 主代理執行）
   步驟 1：派子代理 A 讀取 src/ 並產出「模組依賴清單」（結構化 JSON）。
   步驟 2：派子代理 B 對抗式查證該清單，逐項確認檔案與符號真的存在；
           不存在的標記為 invalid。schema 不通過則退回步驟 1 重做（上限 2 次）。
   步驟 3：僅以通過查證的項目，產出重構建議。
   ```

   把「驗證」獨立成一個帶 pass / fail 與重試上限的節點，就是這個練習的重點。再加一個 Stop hook 做確定性收尾檢查，這個 pipeline 就有了收斂哨兵。

## 常見誤區

<Warning>
  **反模式清單**

  * **把 workflow 當成萬靈丹**：workflow 只是結構。某個節點的 prompt / context 設計爛，再好的流程也救不回來，反而會把爛輸出原樣傳下去放大。先把單節點做對，再談編排。
  * **跳過驗證節點**：假設上游輸出正確、直接串下一步。錯誤往往三步後才浮現，既難歸因又把中間每步的 token 全浪費掉。錯誤要擋在它還便宜的時候。
  * **過度拆解**：把本可一次 prompt 完成的任務硬拆成五步，徒增延遲與狀態管理複雜度。先確認單 prompt 真的勝任不了再拆。
  * **濫設 barrier**：凡 fan-out 必接 barrier 等全部完成。下一步若不需要跨分支的全局資訊，barrier 只會讓快的分支乾等最慢的。預設 pipeline，barrier 是例外。
  * **loop 沒有出口**：loop-until 不設最大迭代與逾時。一旦遇到收斂不了的案例，生產環境會無限消耗資源直到你發現帳單。
  * **該用 workflow 卻硬上 agent**：把控制權交給模型動態決定（orchestrator-workers）看起來省事，代價是可預測性與可重現性。能用預先定義路徑的 workflow 解的，就別交給模型自由發揮。
</Warning>

## 自我檢核

<Check>
  **通過本單元的標準**

  1. 給你一個多步任務，你能不能講清楚它為什麼超出單 prompt 的範圍（輸出長度、上下文深度、還是外部取值）？答不出來，可能根本不需要拆。
  2. 你設計的 workflow，能否對每個節點回答「輸入從哪來、輸出給誰用、通過標準是什麼」？任何一個節點答不出來，設計就還沒成熟。
  3. 你的 fan-out 後面那個 barrier，是真的需要跨分支的全局資訊，還是只是順手擋了一下？
  4. 你的 loop-until 有沒有明確的最大迭代上限與逾時退出？
  5. 你能分清自己現在做的是 workflow（路徑預先定義）還是 agent（模型自己決定路徑）嗎？兩者的可重現性代價不同。
</Check>

## 來源與延伸閱讀

事實主張依官方文件，快變動項標註截至 2026-05。

<div className="references">
  * \[1] E. Schluntz and B. Zhang, "Building Effective Agents," Anthropic Engineering, Dec. 19, 2024.（workflow 與 agent 的定義、prompt chaining / routing / parallelization / orchestrator-workers / evaluator-optimizer 五模式）[https://www.anthropic.com/engineering/building-effective-agents](https://www.anthropic.com/engineering/building-effective-agents) （截至 2026-05）
  * \[2] Anthropic, "Create custom subagents"（子代理獨立上下文與工具集、只回傳結論；Task 工具編排；Dynamic Workflows 與 Agent Teams 研究預覽，2026-05-28），Claude Code Docs. [https://code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents) （截至 2026-05）
  * \[3] LangChain, "Durable execution," LangGraph Docs（State / Node / Edge、checkpointing、durable execution；LangGraph 1.2 於 2026-05-11 釋出）. [https://docs.langchain.com/oss/python/langgraph/durable-execution](https://docs.langchain.com/oss/python/langgraph/durable-execution) （截至 2026-05）
  * \[4] n8n, "AI Agent node documentation"（LangChain 為底、Tools Agent 預設、工具執行前人工核准的 human-in-the-loop；70+ AI 節點），n8n Docs. [https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/) （截至 2026-05）
</div>

* 銜接：[01-3](/code-agent/foundations/prompt-engineering) 單節點的 prompt 品質、[01-4](/code-agent/foundations/context-engineering) 每個節點的 context 組裝與子代理隔離、[01-6](/code-agent/foundations/harness-engineering) 把 workflow 包成有監控與 kill switch 的 harness、[05-1](/code-agent/case-studies/openclaw)／[05-2](/code-agent/case-studies/hermes-agent) 兩個開源 agent 的實際編排設計。