💡一句話定義
LLM 應用開發的五層演進：提示工程（Prompt）管你送的字句 → 脈絡工程（Context）管模型看得到的資訊 → 骨架工程（Harness）管 agent 跑的環境 → 迴圈工程（Loop）管驅動它的迴圈 → 圖工程（Graph）管一群 agent 的組織。每一層都把前一層包在裡面，範圍越來越大，能力也越來越強。
🎮互動：工程演進階梯
同一個任務——「處理一封客戶詢問信」——點五個階梯往上爬，看每一層各自在「管什麼」、同一任務會怎麼被處理、解鎖了什麼能力、又還缺什麼。左邊的巢狀方框會顯示「一層包一層」。
🪜 工程演進階梯
🎯 任務：處理一封客戶詢問信（要回覆得準、還要把後續追蹤排進行事曆）
第 1 階
提示工程
Prompt · 字句
第 2 階
脈絡工程
Context · 資訊
第 3 階
骨架工程
Harness · 環境
第 4 階
迴圈工程
Loop · 迴圈
第 5 階
圖工程
Graph · 組織
⑤ GRAPH 組織
④ LOOP 迴圈
③ HARNESS 環境
② CONTEXT 資訊
① PROMPT 字句
＋ 另外 N 個同樣結構的 agent 節點
這一層在「管」什麼–
同一任務，這層怎麼處理–
✅ 解鎖了什麼能力–
⚠️ 還缺什麼（要靠下一層）–
系統能力–
🧩五層各自在管什麼
✍️① Prompt 提示工程
你送的字句：指令怎麼寫、給不給範例、要什麼格式。問「怎麼問？」
你送的字句：指令怎麼寫、給不給範例、要什麼格式。問「怎麼問？」
📚② Context 脈絡工程
模型看得到的資訊：系統提示、對話史、RAG、工具清單、記憶、狀態。問「這步該餵它什麼？」
模型看得到的資訊：系統提示、對話史、RAG、工具清單、記憶、狀態。問「這步該餵它什麼？」
🛠️③ Harness 骨架工程
agent 跑的環境：可用工具、權限、護欄、觀測、回饋，接到可執行世界。問「它能做什麼、被怎麼管？」
agent 跑的環境：可用工具、權限、護欄、觀測、回饋，接到可執行世界。問「它能做什麼、被怎麼管？」
🔁④ Loop 迴圈工程
驅動它的迴圈：act→observe→decide→repeat 的節奏與完成條件。問「怎麼反覆推進到完成？」
驅動它的迴圈：act→observe→decide→repeat 的節奏與完成條件。問「怎麼反覆推進到完成？」
🕸️⑤ Graph 圖工程
一群 agent 的組織：節點是誰、邊怎麼連、共享狀態放什麼、失敗往哪走。問「這群 agent 怎麼分工？」
一群 agent 的組織：節點是誰、邊怎麼連、共享狀態放什麼、失敗往哪走。問「這群 agent 怎麼分工？」
📚為什麼「脈絡工程」變成主角？
🪆一層包一層（不是彼此取代）
這五層是往外擴、互相包住，不是誰淘汰誰：Graph 決定有哪些 agent、怎麼連；圖上的每個節點是一個 Loop 驅動的 agent，它在一個 Harness（環境）裡運轉，每一圈由 Context（資訊）動態拼裝要餵的內容，而其中一段就是你寫的 Prompt（字句）。所以做小工具，prompt／context 就夠；要做會自己做完事情的 agent，才需要往上補 harness 與 loop；要讓一群 agent 分工協作，才需要 graph。
Prompt 沒有消失，只是不再由你手動輸入。Anthropic 的多 agent 研究系統就回報過：修正協作失敗最主要的槓桿還是 prompt engineering——早期版本一個簡單查詢就派出 50 個子 agent，解法是改 prompt，不是改拓撲。往上加層不代表下面那層可以隨便寫。
⚖️五層對照表
| 層 | 管什麼 | 控制單位 | 關鍵問題 | 例子 | 解鎖能力 |
|---|---|---|---|---|---|
| Prompt 提示 | 字句 | 一次回應 | 怎麼問？ | 指令、範例、輸出格式 | 控制語氣與格式 |
| Context 脈絡 | 資訊 | 一個上下文視窗 | 餵它什麼？ | 系統提示、RAG、記憶、工具清單 | 有所本、個人化、少幻覺 |
| Harness 骨架 | 環境 | 一個執行環境 | 它能做什麼、被怎麼管？ | 工具、權限、護欄、觀測、回饋 | 能安全地採取行動 |
| Loop 迴圈 | 迴圈 | 一個 agent 的週期 | 怎麼推進到完成？ | act-observe-decide、完成條件、步數上限 | 自主完成多步任務 |
| Graph 圖 | 組織 | 一群 agent 的分工 | 誰負責什麼、怎麼連？ | 節點、邊、共享狀態、條件分支、匯流 | 多 agent 平行協作 |
🕸️Graph 工程：最新、也最沒定論的一層
圖工程（Graph Engineering）是 2026 年 7 月才紅起來的說法，比 loop 晚了大約六週。它是這五層裡定義最鬆的一個——連詞的來源都還沒定案，而且會跟舊的「知識圖譜（knowledge graph）」撞名，看到這個詞要先確認對方講的是哪一個。
核心主張只有一句：Loop 讓「一個 agent 的行為」變得可程式化，Graph 讓「一整個 agent 組織」變得可程式化。你要設計的東西從「這一圈怎麼跑」變成「有哪些節點、哪些邊、共享什麼狀態、失敗往哪走」。
最實用的一個觀念：正式上線的系統同時跑兩張圖
🏢組織圖 Org Graph（穩定）
長期存在的 agent，各有名字與職責、負責一個領域、隨時間累積自己的上下文。改版重新部署才會變。
回答的是「誰負責什麼」。
長期存在的 agent，各有名字與職責、負責一個領域、隨時間累積自己的上下文。改版重新部署才會變。
回答的是「誰負責什麼」。
📋工作圖 Work Graph（臨時）
任務節點只在這件事進行時存在：需要平行就分岔、要收斂就匯流、發現某條支線不必做就直接砍掉。做完就消失。
回答的是「現在要做什麼」。
任務節點只在這件事進行時存在：需要平行就分岔、要收斂就匯流、發現某條支線不必做就直接砍掉。做完就消失。
回答的是「現在要做什麼」。
最典型的失敗模式：以 LangGraph 為例，圖是用
StateGraph 宣告在一個狀態結構上，節點用 add_node 註冊、邊用 add_edge 與 add_conditional_edges 接起來，節點本身只是「收 state、回傳部分更新」的函式。關鍵在於——沒有邊帶過去的東西，下一個節點就是看不到。多 agent 系統絕大多數的怪 bug，都是某個節點根本沒拿到它需要的資訊。
🤔什麼時候用哪一層？
常見誤解：以為新層會「取代」舊層。其實是需求越複雜、往上補越多層。
單次問答、寫文案 → Prompt 就夠。
要有所本、接自家資料、對話有記憶 → 加 Context（RAG／記憶）。
要它真的動手、呼叫工具、又要安全可追溯 → 加 Harness（工具／護欄／觀測）。
要它自主把多步驟任務從頭做到尾 → 加 Loop（迴圈與完成條件）。
要一群 agent 各司其職、還能平行跑 → 加 Graph（節點、邊、共享狀態）。
單次問答、寫文案 → Prompt 就夠。
要有所本、接自家資料、對話有記憶 → 加 Context（RAG／記憶）。
要它真的動手、呼叫工具、又要安全可追溯 → 加 Harness（工具／護欄／觀測）。
要它自主把多步驟任務從頭做到尾 → 加 Loop（迴圈與完成條件）。
要一群 agent 各司其職、還能平行跑 → 加 Graph（節點、邊、共享狀態）。
選層四問：照順序問，第一個「不是」通常就是答案
- 每一份輸出都有人在看過之後才會被拿去用嗎？如果是 → Prompt 層就夠了。往上加層買到的是「不用盯著也能跑」，不是「更聰明」。
- 「做完了」可以由人以外的東西判定嗎？測試、schema、評分規則、另一個模型都算。如果不行 → 你沒有停止條件，只有預算上限；那個迴圈會燒到 token 用完為止，而且不會大聲報錯。
- 這件事塞得進一個 agent 的上下文、也只跨一個領域嗎？如果是 → 做 loop 就好。單一條推理線是維持前後假設一致最便宜的方法。
- 有互不相干的支線需要同時跑嗎？如果是 → 這才是 graph 的問題：定義節點、邊、共享狀態與失敗路線。如果不是 → 先把 loop 的工具補強，不要急著加 agent。
代價要先知道。多 agent 的公開數據是：某內部研究評測進步 +90.2%，但 token 花費大約是單次對話的 15 倍，而且光是 token 用量就能解釋 80% 的成效差異。另外有個反例值得記：寫作類、需要通篇一致的工作反而不適合拆給多 agent——分散決策會產生互相打架的假設。大多數任務永遠不需要爬到第 5 階。
✅自我檢測
Q1. Prompt 與 Context engineering 差在哪？
Prompt 管「怎麼問」（你送的字句）；Context 管「模型這一步看得到什麼」（系統提示、對話史、RAG、工具、記憶、狀態），動態拼裝。前者是措辭，後者是資訊架構。
Q2. Harness engineering 是什麼？
設計 agent 運行的「環境／骨架」：可用工具、權限、護欄、觀測（log/追蹤）與回饋機制，把模型接到可執行世界（檔案、API、記憶），讓它能安全、可追溯地行動。
Q3. Loop engineering 是什麼？
設計驅動 agent 的迴圈：act→observe→decide→repeat，設定節奏、何時再跑一圈、何時算完成，以及步數／成本上限，讓它自主推進到目標。
Q4. Graph engineering 是什麼？
設計一群 agent 的組織方式：節點是誰、邊怎麼連、共享狀態放什麼、失敗往哪條路走。Loop 讓「一個 agent 的行為」可程式化，Graph 讓「一整個 agent 組織」可程式化。實務上會同時跑兩張圖：穩定的組織圖（誰負責什麼）與臨時的工作圖（現在要做什麼）。
Q5. 這五層是彼此取代嗎？
不是。它們一層包一層、往外擴：Graph 決定有哪些 agent、圖上每個節點是 Loop 驅動的 agent、跑在 Harness 裡、每圈由 Context 拼裝內容、其中一段是 Prompt。需求越複雜就往上補越多層。Prompt 也沒消失，只是不再由人手動輸入。
Q6. 做一個簡單文案工具需要 harness/loop/graph 嗎？
通常不用。單次生成用 Prompt（＋必要的 Context）就夠；要「會自己呼叫工具、多步驟做完事情」才需要 Harness 與 Loop；只有當有互不相干的支線需要同時跑、一個 agent 的上下文顧不來時，才需要 Graph。大多數任務停在第 4 階。
Q7. 多 agent 一定比單 agent 好嗎？
不一定。公開數據顯示多 agent 在某內部研究評測進步 +90.2%，但 token 花費約 15 倍。而且對「需要通篇一致」的寫作類工作反而更差——分散決策會產生互相打架的假設。要先確認有真正平行的支線，再考慮拆。
🎯重點整理
- 五層：Prompt 字句 → Context 資訊 → Harness 環境 → Loop 迴圈 → Graph 組織。
- 關係：一層包一層、往外擴，不是彼此取代。五種控制單位：一次回應 → 一個視窗 → 一個環境 → 一個 agent 的週期 → 一群 agent 的分工。
- Context 是新前沿：從「怎麼問」轉為「這步餵什麼資訊」，管記憶與狀態。
- Harness＝環境：工具、護欄、觀測，讓 agent 能安全行動。
- Loop＝迴圈：act-observe-decide 與完成條件，讓 agent 自主做完。難的不是迴圈，是停止條件——沒有機械化的「做完了」判準，它只會燒到預算用完。
- Graph＝組織：節點、邊、共享狀態。同時跑穩定的組織圖（誰）與臨時的工作圖（現在做什麼）。沒有邊帶過去的資訊，下個節點就看不到。
- 不要為了爬階而爬階：多 agent 約 15 倍 token，大多數任務停在第 4 階就夠。