深度探秘

「Agent」這個詞，其實是個大帽子

大家都在講 Agent，但講的是同一件事嗎？

過去一年 Anthropic 團隊和數十個產業的客戶一起打造 LLM Agent，發現一個有趣的現象：最成功的實作，往往不是靠複雜的框架或專門的函式庫，而是用簡單、可組合的模式堆出來的。

但「Agent」這個詞本身很模糊。有人說 Agent 是完全自主、能長時間獨立運作、自己選工具完成複雜任務的系統；也有人說 Agent 只是照著預先定義好的流程在跑的實作。

Anthropic 的做法是：把這些變體統稱為工作流與 Agent 兩種架構。">代理系統 (agentic systems)，但在底下畫出一條重要的架構分界線：

為什麼要分清楚這條線？

因為這條線幾乎決定了你系統的性格：工作流像照著食譜做菜，步驟寫好了，每次做出來的味道都差不多；Agent 像請一位大廚自由發揮，做出來的菜可能驚喜連連，但也可能失控。

這個分界不是學術定義遊戲，而是實務上「你要多信任模型自己做決定」的核心問題。

生活妙喻

食譜 vs. 請大廚自由發揮

兩種做菜的方式

想像你今天想做一頓晚餐：

• 工作流，就像照著食譜一步步做菜：先切菜、再熱鍋、下油、下料，每一步都寫得清清楚楚，你（程式）決定了整個流程，廚師（LLM）只負責在每個步驟裡把「切菜」「炒菜」這件事做好。不管做幾次，流程都一樣，結果也很穩定。
• Agent，則像把廚房交給一位有經驗的大廚，只告訴他「我要一頓能讓客人驚艷的晚餐」，剩下的——買什麼菜、先做哪道、要不要臨時調整——全部交給大廚自己判斷。大廚會不斷嚐味道（從環境得到回饋），決定下一步要加鹽還是收汁。

兩者的取捨

照食譜做菜比較穩定可預期，但遇到食譜沒寫到的情況（客人臨時說不吃辣）就會手足無措；讓大廚自由發揮比較靈活，能應對各種突發狀況，但也更依賴大廚的判斷力——萬一大廚判斷失誤，整頓飯可能就毀了。

flowchart TD
    A[代理系統] --> B[工作流：照食譜做菜]
    A --> C[Agent：大廚自由發揮]
    B --> D[程式決定步驟順序]
    C --> E[LLM 自己決定怎麼做]

實用超能力

看到系統時，先問自己這個問題

一個實用的檢查問題

下次你在設計或評估一個 LLM 系統時，可以先問自己：

「決定下一步要做什麼的，是我寫的程式碼，還是模型自己？」

如果答案是「程式碼」，那你手上大概是個工作流；如果答案是「模型自己決定」，那你手上就是個Agent。

為什麼這個問題很重要

這個問題會直接影響你怎麼除錯、怎麼測試、怎麼估算成本：

• 工作流的每一步都可預測，出錯了你可以精準定位是哪一步的提示詞或邏輯有問題。
• Agent 的每一步都可能不同，出錯了你得去看它在那個當下「看到了什麼、決定了什麼」。

本章接下來會先介紹一個最基礎的建構單元（加強型 LLM），再依序介紹幾種工作流模式，最後才談到真正的 Agent——這個順序本身就是在示範：先求簡單，再逐步增加複雜度，而不是一開始就跳去打造一個全自主的 Agent。

深度探秘

先求簡單，複雜是最後手段

第一原則：不是每個問題都需要 Agent

打造 LLM 應用時，Anthropic 給的第一個建議聽起來可能有點反直覺：

先找最簡單能解決問題的方法，只有真的需要時才增加複雜度——這甚至可能意味著『完全不要打造代理系統』。

為什麼？因為代理系統（工作流和 Agent）通常會用更高的延遲與成本，去換取更好的任務表現。這是一筆交易，而不是免費的午餐。

這筆交易划不划算？

你需要誠實評估：

• 這個任務真的需要多步驟、多工具、動態決策嗎？
• 還是其實一次 LLM 呼叫，搭配好的檢索 (retrieval) 和情境內範例 (in-context examples)，就已經綽綽有餘？

原文明確指出：對很多應用而言，優化單次 LLM 呼叫（搭配檢索與範例）通常就足夠了。 只有當任務真的複雜到需要拆解、或需要模型自己動態判斷路徑時，才進一步考慮工作流或 Agent。

複雜度該用在哪？

生活妙喻

叫計程車，還是自己組一個車隊？

用交通工具來想這件事

假設你只是要從家裡到公司，五分鐘的路程：

• 如果你花大把時間去組織一支專屬車隊（配司機、調度員、後勤團隊），那真的是殺雞用牛刀——多花的時間、金錢遠遠超過你省下的移動時間。
• 但如果你要做的是跨國巡演的樂團後勤，路線每天不同、突發狀況一堆（臨時改航班、場地異動），這時候一支能自己判斷、彈性調度的車隊反而是值得的投資。

對應到系統設計

• 「叫一輛計程車」就像優化單次 LLM 呼叫：夠簡單、夠快、成本低，很多時候這就是最佳解。
• 「規劃固定巡演路線的接送班表」就像工作流：路線固定、可預期，適合明確、可拆解的任務。
• 「配一支能臨場應變的車隊調度團隊」就像Agent：靈活但成本高，適合真正開放、多變的場景。

關鍵問題永遠是：這趟路真的複雜到需要車隊嗎，還是叫車就好？

flowchart TD
    A[任務進來] --> B{夠簡單嗎}
    B -->|是| C[優化單次 LLM 呼叫]
    B -->|否 但步驟固定| D[使用工作流]
    B -->|否 且需要動態判斷| E[考慮使用 Agent]

實用超能力

決定要不要用框架的三個判斷點

框架能幫你，也能害你

市面上有不少框架能簡化打造代理系統的過程，例如 Claude Agent SDK、AWS 的 Strands Agents SDK，或是拖拉式的 Rivet、Vellum 等 GUI 工具。它們把呼叫 LLM、定義與解析工具、串接多次呼叫這些低階雜事都幫你包好了。

但原文也提出警告：

框架常常會多加一層抽象，模糊掉底層真正送出去、收回來的提示詞與回應，讓除錯變得更難；也容易讓人「順手」加了不必要的複雜度。

三個實用判斷點

1. 先直接用 LLM API 練過一輪：很多模式其實幾行程式碼就能實作，親自寫過一次，你才知道框架到底幫你省了什麼。
2. 如果決定用框架，一定要搞懂底層在做什麼：原文特別點名，「對底層實際運作的錯誤假設」是客戶最常見的出錯來源。
3. 框架適合起步，不代表適合正式環境：上線前，別怕拆掉不必要的抽象層，換成更貼近底層的基本元件。

記住這句話：先自己動手做過一次簡單版，再決定要不要借助框架的力量。

深度探秘

所有代理系統，都是從這個最小單位長出來的

最基本的建構單元

不管你最後要做的是簡單的工作流，還是複雜的自主 Agent，一切都是從同一個最小建構單元開始：檢索、工具、記憶等能力，且模型能主動決定何時、如何使用這些能力的版本，是所有代理系統的最小建構單元。">加強型 LLM (the augmented LLM)——一個裝上了額外能力的 LLM。

這些額外能力通常包括：

• 檢索 (retrieval)：主動查找需要的資訊。
• 工具 (tools)：呼叫外部功能來完成任務。
• 記憶 (memory)：記住之前發生過的事、決定要保留什麼資訊。

關鍵在於，現在的模型已經能主動使用這些能力——自己生成搜尋查詢、自己選該用哪個工具、自己判斷什麼資訊值得記住。這跟過去「工程師手動決定每一步要查什麼」是完全不同的層次。

打造加強型 LLM 該關注什麼？

原文建議聚焦兩個重點：

1. 把能力打磨到貼合你的具體使用情境——不是隨便接個工具就好，而是這個工具、這份記憶，真的對這個任務有幫助。
2. 確保這些能力對 LLM 而言介面清楚、文件完整——模型要「看得懂」怎麼用這些能力，就像我們前面提過的，好工具的說明書要寫給模型看得懂。

Model Context Protocol（MCP）

實作這些能力的方法有很多種，其中一種是 Anthropic 推出的 Model Context Protocol (MCP)：它讓開發者只需寫一個簡單的客戶端實作，就能接上一個不斷成長的第三方工具生態系，不必每個工具都重新造輪子。

從這裡開始，本文接下來介紹的所有工作流與 Agent，都預設每次 LLM 呼叫背後，都已經具備這些加強能力。

生活妙喻

普通員工 vs. 配好裝備的專員

想像剛入職的新人 vs. 配好裝備的老手

一個普通 LLM，就像一位剛入職、什麼資源都沒有的新人：只能憑腦子裡記得的東西回答問題，問他公司上個月的業績，他只能靠印象亂猜。

一個加強型 LLM，就像替這位新人配好了裝備的專員：

• 給他一台能查資料庫的電腦（檢索）——他可以自己去查上個月業績的真實數字。
• 給他一支萬用工具腰帶（工具）——需要寄信、算數字、查天氣，通通能自己動手做。
• 給他一本隨身筆記本（記憶）——重要的事情記下來，之後隨時能翻出來用。

這位配好裝備的專員，不只『被動等你告訴他怎麼做』，他還會自己判斷：現在該查資料庫嗎？該用哪個工具？這件事值得記下來嗎？

flowchart LR
    A[基本 LLM] -->|加裝| B[檢索能力]
    A -->|加裝| C[工具能力]
    A -->|加裝| D[記憶能力]
    B --> E[加強型 LLM]
    C --> E
    D --> E

實用超能力

先把地基打好，才談上層建築

別急著蓋樓，先打地基

很多團隊一開始就想直接打造一個複雜的多步驟 Agent，卻忽略了最基本的問題：你的加強型 LLM 本身夠不夠好用？

在往上疊工作流或 Agent 之前，先問自己：

• 我給模型的檢索能力，真的能查到它需要的資訊嗎？
• 我給模型的工具，說明清楚到模型一看就懂該怎麼用嗎？（本章後面會深入談這點）
• 模型需要記住的東西，有被妥善保留下來嗎？

實務上的第一步：先用好 MCP 或類似機制

如果你打算自己接一堆工具、串一堆 API，不如先看看 Model Context Protocol (MCP) 這類方案——它的價值在於用一套簡單、標準化的客戶端實作，就能接上外部生態系裡持續成長的工具，省去你自己重新設計每個介面的功夫。

記住：本文後面提到的每一次「LLM 呼叫」，背地裡都假設它已經是一個加強型 LLM。把這個地基打好，後面的工作流、Agent 才會蓋得穩。

深度探秘

把大任務拆成一連串小任務

什麼是 Prompt Chaining？

Prompt Chaining（提示詞接龍）是最基礎的工作流模式：把一個任務拆解成一連串步驟，每一次 LLM 呼叫都處理前一步的輸出，像接龍一樣一步接一步往下傳。

你還可以在中間任何一個步驟加入程式化檢查——原文稱之為「gate（關卡）」——來確保流程還在正確的軌道上，沒有跑偏。

flowchart LR
    A[輸入] --> B[LLM 呼叫 1]
    B --> C{Gate 檢查}
    C -->|通過| D[LLM 呼叫 2]
    C -->|不通過| X[中止或修正]
    D --> E[LLM 呼叫 3]
    E --> F[輸出]

什麼時候該用？

這個工作流最適合任務能被乾淨拆解成固定子任務的情境。核心目的是：用延遲換準確度——把一個大任務拆成幾個小任務，每個小任務對模型來說都變得更簡單、更容易做對，整體出錯的機率就降低了。

常見應用範例

• 先生成一份行銷文案，再把它翻譯成另一種語言。
• 先寫文件大綱，檢查大綱是否符合特定標準，通過後再依大綱寫出完整文件。

這兩個例子都有一個共同特徵：後一步天生就依賴前一步的結果，而且每一步都可以被單獨檢查、單獨優化。

生活妙喻

工廠的生產線，一站一站往下傳

想像一條生產線

Prompt Chaining 就像工廠裡的生產線：

• 第一站：裁切原料，做成半成品。
• 品管站（gate）：檢查半成品尺寸對不對，不對就退回重做，不會讓瑕疵品流到下一站。
• 第二站：把合格的半成品組裝成成品。
• 第三站：包裝出貨。

每一站的工人（LLM 呼叫）只需要專心做好自己那一站的工作，不需要同時煩惱裁切、組裝、包裝三件事——這正是分工帶來的好處：每個小任務都變簡單了，整體品質反而更穩定。

為什麼要在中間放品管站？

如果生產線上沒有品管站，一旦第一站出了瑕疵品，會一路帶著錯誤流到最後，等到包裝完才發現整批報廢，浪費更多成本。Gate 就是那位站在生產線中間，隨時檢查有沒有走偏的品管員——及早抓到問題，及早止損。

這也是為什麼原文說，這個工作流是用延遲（多了幾道檢查、多了幾站）去換準確度（每站都做對、整體品質更穩）。

實用超能力

動手拆解一個真實任務

練習：把「寫一篇雙語產品公告」拆成鏈

假設任務是：寫一篇產品公告，先用中文寫好，再翻譯成英文，並確保翻譯後語氣一致。用 Prompt Chaining 拆解會是：

1. LLM 呼叫 1：根據產品資訊，生成一份中文公告草稿。
2. Gate：程式檢查字數是否在規定範圍內、是否包含必要的產品名稱關鍵字。
3. LLM 呼叫 2：把通過檢查的中文公告翻譯成英文，同時要求保持語氣一致。
4. Gate：檢查英文版是否仍包含相同的產品名稱、連結等關鍵資訊。
5. 輸出：中英文公告雙版本。

# 概念示意：Prompt Chaining 的簡化程式骨架
draft_zh = call_llm(prompt="寫產品公告", context=product_info)
if not gate_check(draft_zh, rules=["字數", "關鍵字"]):
    raise ValueError("中文草稿未通過檢查")

draft_en = call_llm(prompt="翻譯成英文，語氣一致", context=draft_zh)
if not gate_check(draft_en, rules=["關鍵資訊保留"]):
    raise ValueError("英文翻譯未通過檢查")

判斷小技巧

下次遇到一個任務時，可以問自己：這個任務能不能被拆成幾個『後一步需要前一步結果』的固定步驟？ 如果答案是「能」，且每一步都能被單獨檢查，那 Prompt Chaining 通常就是最划算的第一選擇。

深度探秘

先分類，再交給專家處理

什麼是 Routing？

Routing（路由）工作流會先替輸入分類，再依分類結果把它導向一個專門的後續任務。

這個模式的價值在於：它讓你能做到關注點分離 (separation of concerns)，替不同類型的輸入各自打造更專門、更精準的提示詞，而不必用同一套提示詞硬扛所有情況。

原文提醒：如果沒有 Routing，「為某一種輸入優化提示詞」很容易在傷害其他類型輸入的表現——因為你調整措辭去照顧 A 類型問題時，可能反而讓 B 類型問題的回答變差。

flowchart TD
    A[輸入] --> B[分類器]
    B -->|類型一| C[專門流程 一]
    B -->|類型二| D[專門流程 二]
    B -->|類型三| E[專門流程 三]

什麼時候該用？

Routing 特別適合：

• 任務裡有清楚可分的類別，且這些類別最好分開處理。
• 分類這件事本身能被準確地完成——不管是靠 LLM 分類，還是靠更傳統的分類模型／演算法。

常見應用範例

• 客服分流：把一般問題、退款請求、技術支援分別導向不同的下游流程、提示詞、工具組合。
• 依難度分流模型：簡單、常見的問題導向便宜、快速的小模型（如 Claude Haiku 4.5），困難、少見的問題導向能力更強的模型（如 Claude Sonnet 4.5），在效能與成本之間取得最佳平衡。

生活妙喻

醫院的分診台

急診室的分診邏輯

Routing 就像醫院急診室的分診台 (triage)：

病人一進門，分診護理師不會把所有人都塞給同一位醫生用同一套流程處理。她會先快速判斷：這是感冒、骨折，還是心臟病發？然後把病人導向對應的專科——感冒去內科、骨折去骨科、心臟病發直接送急救室。

如果沒有分診台，會發生什麼事？可能是一位全科醫生同時要顧感冒又要顧心臟病發，為了兼顧所有病症調整自己的判斷標準，結果每一種病都看得不夠精準——這正是原文說的「優化一種輸入會傷害其他輸入表現」。

分流也可以用在「找誰看診」上

醫院也會把普通感冒分給資源較少、速度較快的社區診所醫生（對應便宜的小模型），把複雜罕見病症分給專科主治醫師（對應能力更強的大模型），讓資源用在真正需要的地方。

flowchart LR
    A[病人 輸入] --> B[分診台 分類器]
    B -->|感冒| C[社區診所 小模型]
    B -->|罕見重症| D[專科醫師 大模型]

實用超能力

設計一個客服 Routing 系統

動手設計：三分類客服系統

假設你要打造一個客服系統，先用一次 LLM 呼叫（或傳統分類模型）判斷使用者輸入屬於哪一類，再分派：

# 概念示意：Routing 的簡化程式骨架
category = classify(user_message)  # 回傳 "一般問題" / "退款請求" / "技術支援"

if category == "一般問題":
    response = call_llm(prompt=GENERAL_PROMPT, tools=[knowledge_base])
elif category == "退款請求":
    response = call_llm(prompt=REFUND_PROMPT, tools=[order_system, refund_api])
elif category == "技術支援":
    response = call_llm(prompt=TECH_PROMPT, tools=[diagnostic_tool])

每個分支都有自己專屬的提示詞與工具組合，不必勉強共用同一套。

判斷小技巧

下次遇到輸入類型混雜的任務，問自己：

1. 這些輸入真的可以被清楚分成幾類嗎？
2. 不同類別分開處理，真的能讓表現變更好嗎？
3. 分類這一步，我能做得準嗎？（分類錯了，後面全盤皆錯）

三個問題如果都是「能」，Routing 通常就是值得投入的工作流模式；如果分類本身就很難做準，硬上 Routing 反而可能引入新的錯誤來源。

深度探秘

同時開工，再把結果彙整起來

什麼是 Parallelization？

Parallelization（平行處理）讓 LLM 同時對一項任務展開工作，再用程式把這些輸出彙整起來。這個模式有兩種關鍵變體：

• Sectioning（分段）：把一個任務拆成互相獨立的子任務，同時平行執行。
• Voting（投票）：同一個任務跑好幾次，得到多個獨立且各異的輸出，再彼此比對或投票。

flowchart TD
    A[任務] --> B[Sectioning 拆成獨立子任務]
    A --> C[Voting 同任務跑多次]
    B --> D[子任務一]
    B --> E[子任務二]
    D --> F[彙整結果]
    E --> F
    C --> G[輸出一]
    C --> H[輸出二]
    C --> I[輸出三]
    G --> J[比對 / 投票]
    H --> J
    I --> J

什麼時候該用？

Parallelization 在兩種情境特別有效：

1. 子任務可以被平行化以加快速度——原本要依序做的事，同時做能省下大把時間。
2. 需要多個角度或多次嘗試才能得到更有信心的結果——單一次嘗試不夠可靠時，多做幾次互相驗證。

原文還特別提到一個實務洞察：面對有多個考量因素的複雜任務，讓每個考量各自交給一個獨立的 LLM 呼叫處理，通常表現更好——因為每次呼叫能專注處理一個特定面向，不會被其他考量分散注意力。

常見應用範例

Sectioning：

• 護欄機制 (guardrails)：一個模型實例處理使用者查詢，另一個獨立篩查是否包含不當內容或請求——分開處理比同一次呼叫兼顧護欄與正常回應表現更好。
• 自動化評測 (evals)：每次 LLM 呼叫只評估模型表現的某一個面向。

Voting：

• 程式碼安全審查：讓多個不同的提示詞分別審查同一段程式碼、各自標記發現的漏洞。
• 內容審核：多個提示詞從不同角度評估內容是否不當，或要求不同的投票門檻，來平衡誤判與漏判。

生活妙喻

廚房同時開三個爐火，還是找三位評審打分

Sectioning：一人一菜，同時開工

想像辦一場宴席，如果所有菜都要一位廚師依序做完，客人可能餓到睡著。聰明的做法是：讓三位廚師同時各自負責一道菜——一位炒青菜、一位煎魚、一位煮湯，三個爐火同時開工，互不干擾，最後一起上桌。這就是Sectioning：任務彼此獨立，平行處理，省下大把時間。

Voting：找三位評審各自打分

另一種情境是選秀比賽：如果只找一位評審打分，難免有個人偏好或看走眼的風險。找三位評審各自獨立打分，再看多數意見或平均分數，結果通常更可靠、更有信心——這就是Voting：同一件事重複做幾次，用多個獨立視角互相驗證。

flowchart LR
    A[Sectioning] --> B[廚師一 炒青菜]
    A --> C[廚師二 煎魚]
    A --> D[廚師三 煮湯]
    E[Voting] --> F[評審一打分]
    E --> G[評審二打分]
    E --> H[評審三打分]

兩者的差別

Sectioning 的三位廚師做的是不同的事（不同的菜）；Voting 的三位評審做的是同一件事（打同一道菜的分）。搞清楚這個差異，才能選對變體。

實用超能力

把護欄機制拆成獨立的第二個 LLM

練習：guardrails 的 Sectioning 實作

假設你在做一個客服聊天機器人，需要同時做到「正常回應使用者」和「篩查不當內容」。原文建議：不要讓同一個 LLM 呼叫兼顧兩件事，而是拆成兩個獨立的呼叫平行進行：

# 概念示意：Sectioning 實作 guardrails
import concurrent.futures

def main_response(query):
    return call_llm(prompt=MAIN_PROMPT, context=query)

def safety_check(query):
    return call_llm(prompt=SAFETY_PROMPT, context=query)

with concurrent.futures.ThreadPoolExecutor() as executor:
    future_response = executor.submit(main_response, user_query)
    future_safety = executor.submit(safety_check, user_query)
    response = future_response.result()
    is_safe = future_safety.result()

final_output = response if is_safe else "抱歉，這個請求無法處理"

練習：程式碼審查的 Voting 實作

如果要審查一段程式碼是否有漏洞，可以讓多個不同角度的提示詞（例如「檢查 SQL 注入」「檢查權限控管」「檢查輸入驗證」）各自獨立審查，只要任何一個標記出問題就整合起來回報——這樣比單一提示詞包山包海更不容易漏掉。

判斷小技巧

問自己：這些子任務彼此需要對方的輸出嗎？ 如果不需要（各自獨立），且能同時進行，Parallelization 通常比循序處理（Prompt Chaining）更有效率或更可靠。

深度探秘

指揮官當場決定要派幾個人、做什麼

什麼是 工人 LLM、綜合結果的中央 LLM。">Orchestrator-workers？

在**Orchestrator-workers（指揮者-工人）工作流裡，有一個中央 LLM（指揮者）**負責：

1. 動態拆解任務——把大任務拆成幾個子任務。
2. 委派給工人 LLM——把拆好的子任務分派下去執行。
3. 綜合結果——把工人們回報的結果整合成最終答案。

flowchart TD
    A[使用者輸入] --> B[指揮者 LLM]
    B -->|動態拆解並派工| C[工人 LLM 一]
    B -->|動態拆解並派工| D[工人 LLM 二]
    B -->|動態拆解並派工| E[工人 LLM 三]
    C --> F[指揮者彙整結果]
    D --> F
    E --> F
    F --> G[最終輸出]

跟 Parallelization 長得很像，但差在哪？

原文特別提醒：Orchestrator-workers 在拓樸結構上跟 Parallelization 很像（都是一個中心點連到多個並行處理），但關鍵差異在於彈性：

什麼時候該用？

這個工作流特別適合你無法預先預測會需要哪些子任務的複雜任務。原文舉的例子是寫程式：需要改動幾個檔案、每個檔案要怎麼改，往往取決於這次具體的任務內容，沒辦法事先寫死。

常見應用範例

• 一次改動多個檔案的程式產品：指揮者依任務描述判斷要動哪些檔案、怎麼動。
• 蒐集多來源資訊的搜尋任務：指揮者依查詢內容決定要去哪些來源蒐集、分析可能相關的資訊。

生活妙喻

工地監工，現場決定怎麼分工

兩種蓋房子的方式

Parallelization（Sectioning） 像是蓋一棟制式樣品屋：設計圖早就畫好了，一開始就知道「這裡要三個工班：水電班、泥作班、油漆班」，各班同時進場、各做各的，事先分配好，照計畫執行。

Orchestrator-workers 則像是監工到了一個從沒見過的老屋，要進行不知道範圍多大的翻修工程。監工到現場當場勘查：喔，這裡壁癌要處理、那裡電線要重拉、屋頂可能要換——他當場決定要叫幾個工班、叫哪些工班、怎麼分工，因為在踏進這棟房子之前，根本沒人知道會遇到什麼狀況。

關鍵差異：計畫是「先畫好」還是「現場決定」

flowchart LR
    A[樣品屋 Parallelization] --> B[設計圖早就寫好三個工班]
    C[老屋翻修 Orchestrator-workers] --> D[監工現場勘查才決定怎麼分工]

監工（指揮者 LLM）的價值就在這裡：他能看著眼前的實際狀況，靈活決定該找誰、找幾個人、怎麼分配工作，而不是照著一份寫死的清單機械式執行。

實用超能力

設計一個能改多檔案的 Coding Agent 骨架

練習：程式修改任務的指揮者-工人架構

假設使用者說「幫我把整個專案裡所有用到已棄用函式 old_api() 的地方，換成新的 new_api()，並確認呼叫方式相容」。這個任務沒辦法事先知道要改幾個檔案：

# 概念示意：Orchestrator-workers 的簡化程式骨架
def orchestrator(task_description):
    # 指揮者先動態分析，決定要拆成哪些子任務（可能是任意數量的檔案）
    subtasks = call_llm(
        prompt="分析任務，列出需要修改的檔案與各自的修改要點",
        context=task_description
    )
    # 每個子任務交給一個工人 LLM 處理
    results = []
    for subtask in subtasks:
        result = call_llm(prompt="依修改要點編輯這個檔案", context=subtask)
        results.append(result)
    # 指揮者彙整所有工人的結果，確認整體一致性
    final = call_llm(prompt="彙整所有檔案修改，檢查是否有遺漏或衝突", context=results)
    return final

注意這裡的 subtasks 不是寫死的清單，而是指揮者依這次任務內容當場分析出來的。

判斷小技巧

問自己：如果換一個輸入，子任務的數量和內容會不會完全不同？ 如果答案是「會」，那就代表這是 Orchestrator-workers 的地盤，而不是能用固定拆法的 Parallelization。

深度探秘

一個寫、一個改，寫到滿意為止

什麼是 Evaluator-optimizer？

**Evaluator-optimizer（評估者-優化者）**工作流由兩個角色組成，在一個迴圈裡反覆運作：

• 生成者 (generator)：產生一份回應或內容。
• 評估者 (evaluator)：針對這份內容給出明確的評估與回饋。

生成者根據評估者的回饋修改內容，再交給評估者檢查，如此反覆，直到達到滿意的品質或次數上限為止。

flowchart LR
    A[生成者 產生內容] --> B[評估者 給出評估與回饋]
    B -->|需要修改| A
    B -->|已達標準| C[輸出最終結果]

什麼時候該用？

原文指出這個工作流特別有效的兩個訊號：

1. 當人類清楚表達出回饋時，LLM 的回應確實能被明顯改善——也就是說，這類任務「改進空間」是存在且可被具體描述的。
2. LLM 本身也能提供這樣的回饋——評估者角色需要有能力做出有意義、可操作的評價，不是隨口說好或不好。

原文用一個貼切的比喻：這很像人類作家反覆修稿的過程——寫一版，自己或編輯挑出問題，修一版，再挑，直到滿意為止。

常見應用範例

• 文學翻譯：翻譯者 LLM 一開始可能沒抓到某些細膩的語感或雙關，但評估者 LLM 能指出這些細節，給出有用的批評，讓翻譯逐輪改善。
• 複雜搜尋任務：需要多輪搜尋與分析才能蒐集到完整資訊，評估者負責判斷「目前資訊夠不夠、還要不要再搜尋一輪」。

生活妙喻

作家與編輯的反覆修稿

寫一本小說的真實過程

很少有作家能一次就寫出完美的定稿。真實的創作過程通常是：

1. 作家（生成者）寫出第一版草稿。
2. 編輯（評估者）讀完後，給出具體的意見：「第三章節奏太快」「這個角色的動機不清楚」「這段對話不自然」——不是模糊地說「不夠好」，而是明確、可操作的回饋。
3. 作家根據這些具體意見修改，交出第二版。
4. 編輯再讀一次，看看問題解決了沒，可能又挑出新的細節。
5. 如此反覆，直到編輯覺得**「這樣可以出版了」**。

為什麼這個模式有效？

關鍵在於：編輯的回饋必須是具體、有建設性的，而不是空泛的「再加油」。如果編輯只會說「感覺不太對」卻說不出哪裡不對，作家根本無從修改——這正是原文說的「LLM 能提供這樣的回饋」這個前提有多重要。

flowchart TD
    A[作家寫草稿] --> B[編輯給具體意見]
    B --> C[作家依意見修改]
    C --> D{編輯滿意了嗎}
    D -->|否| B
    D -->|是| E[定稿出版]

實用超能力

打造一個文學翻譯的評估-優化迴圈

練習：翻譯品質的反覆優化

假設任務是把一段有大量雙關語和文化梗的文學作品翻成中文，直接翻一次很難完美，適合用 Evaluator-optimizer：

# 概念示意：Evaluator-optimizer 的簡化迴圈
draft = call_llm(prompt="翻譯這段文學文字", context=source_text)

for attempt in range(MAX_ROUNDS):
    feedback = call_llm(
        prompt="評估這份翻譯是否保留原文語感、雙關、文化脈絡，給出具體修改建議",
        context={"original": source_text, "translation": draft}
    )
    if feedback["is_satisfactory"]:
        break
    draft = call_llm(
        prompt="根據以下具體建議修改翻譯",
        context={"translation": draft, "feedback": feedback["comments"]}
    )

final_translation = draft

注意這裡的停止條件：不是無限迴圈，而是「評估者滿意」或「達到最大嘗試次數」就停止——這跟 Agent 一節會提到的『停止條件』概念是相通的。

判斷小技巧

問自己兩個問題：

1. 這類內容，改進空間是不是真實存在、且能被具體描述？（不是隨便猜）
2. 評估者角色，是不是真的能給出有意義、可操作的回饋？

兩個答案都是「能」，Evaluator-optimizer 才值得投入；如果評估標準模糊到連人類都說不清楚哪裡該改，這個工作流很可能也幫不上忙。

深度探秘

從指令到收尾，Agent 怎麼運作

Agent 的完整生命週期

前面幾節談的都是工作流——流程由程式決定。現在終於輪到真正的Agent：LLM 自己動態決定流程與工具使用。

原文描述 Agent 的典型運作流程：

1. 開始：Agent 從人類的一句指令、或一段互動討論開始。
2. 規劃與行動：一旦任務清楚，Agent 就獨立規劃、獨立操作，可能過程中回頭找人類確認資訊或判斷。
3. 取得地面真相：執行過程中，Agent 必須不斷從環境取得回饋（例如工具呼叫的結果、程式執行的結果），用這些真實訊號評估自己的進度——原文稱之為「ground truth」。
4. 人類checkpoint：Agent 可以在檢查點、或遇到卡關時暫停，等待人類回饋。
5. 收尾：任務完成就結束，但也常見設定停止條件（例如最多跑幾輪迭代），避免失控。

flowchart TD
    A[人類指令 或 互動討論] --> B[任務清楚]
    B --> C[Agent 獨立規劃並行動]
    C --> D[從環境取得地面真相]
    D --> E{進度如何}
    E -->|需要調整| C
    E -->|卡關或到檢查點| F[暫停等待人類回饋]
    F --> C
    E -->|完成或達停止條件| G[任務結束]

為什麼「地面真相」這麼關鍵？

如果 Agent 只憑自己腦中的想像判斷進度，很容易愈走愈偏卻不自知。必須靠環境的真實回饋（工具回傳的資料、程式碼是否真的執行成功）校正自己的方向，這也是 Agent 能長時間自主運作、卻不至於完全失控的關鍵機制。

生活妙喻

放手讓資深員工去談成一筆生意

一個貼切的職場場景

想像你是主管，交給一位資深業務一個任務：「幫我把這家客戶談下來」。你不會逐字逐句告訴他該說什麼話、該走哪個流程——你只給目標，剩下的交給他。

• 他會自己規劃：先打電話還是先發信？該準備什麼提案？
• 他會自己行動：實際去談，過程中根據對方反應調整策略。
• 他會靠真實的回饋判斷進度：客戶回信了嗎？報價對方接受了嗎？——這就是他的「地面真相」，不是憑自己想像「應該差不多談成了」。
• 遇到卡關時，他會回來找你：「客戶要求的折扣超出我的權限，你要不要親自出面？」——這就是檢查點。
• 任務結束時，他知道該收尾了（合約簽了），也知道該停手了（談了三個月還沒進度，該報告放棄或改變策略）——這對應「停止條件」。

這跟工作流有什麼不同？

如果是工作流，你可能會寫一套死板的流程：「第一天打電話，第二天發信，第三天……」不管客戶實際反應如何都照表操課。而 Agent（資深業務）的價值正在於：他能依現場真實狀況隨時調整下一步。

flowchart LR
    A[主管給目標] --> B[業務自己規劃行動]
    B --> C[依客戶真實反應 地面真相 調整]
    C --> D{卡關嗎}
    D -->|是| E[回頭找主管 checkpoint]
    D -->|否| B

實用超能力

什麼任務值得放手讓 Agent 做？

判斷「值得放手」的三個條件

原文給出清楚的判斷標準：

1. 開放式問題：很難或不可能預先預測需要多少步驟。
2. 無法寫死路徑：任務的走法沒辦法事先用固定程式邏輯規劃出來。
3. 可以信任模型的決策：因為 LLM 會運作多輪，你必須對它在這過程中的判斷有一定程度的信任。

原文強調：Agent 的自主性很適合在「受信任的環境」裡把任務規模化——但這份自主也意味著更高的成本與錯誤累積、放大的風險。

實務建議：先在沙盒裡跑

正因為風險存在，原文建議：

• 在沙盒環境中做大量測試，觀察 Agent 實際會怎麼行動、會不會走偏。
• 搭配適當的護欄 (guardrails)，限制 Agent 能做的事情的邊界（例如不能直接刪除生產資料庫的資料）。

兩個 Anthropic 自己的實例

• Coding Agent：用來解決 SWE-bench 的任務，根據任務描述直接修改多個檔案——這正是前一節談過、無法預先寫死子任務的典型情境。
• 「Computer use」參考實作：讓 Claude 直接操作電腦畫面完成任務，是完全開放式問題的極端例子。

flowchart TD
    A[任務進來] --> B{能預測步驟數嗎}
    B -->|能| C[考慮用工作流]
    B -->|不能| D{能信任模型決策嗎}
    D -->|能，且已做好護欄與沙盒測試| E[考慮用 Agent]
    D -->|不能| F[先降低任務開放度或加強護欄]

深度探秘

兩個真實案例的共同特徵

Appendix 1：Agent 在實務中最亮眼的兩個領域

Anthropic 與客戶合作的經驗中，發現兩個特別能展現 Agent 價值的應用領域：客服與寫程式。它們有一個共同的深層特徵——原文總結為四點：

1. 需要對話與行動兼具（不是只回答問題，還要真的做事）。
2. 有清楚的成功標準（能明確判斷這次任務算不算成功）。
3. 能形成回饋迴圈（做完能立刻知道結果好不好）。
4. 能整合有意義的人類監督（在關鍵時刻讓人類把關）。

A. 客服：對話介面 + 工具整合

客服場景天然適合開放式 Agent，因為：

• 支援互動本身自然依循對話流程，但同時需要存取外部資訊與執行動作。
• 工具可以整合客戶資料、訂單紀錄、知識庫文章。
• 動作（如發放退款、更新工單）可以直接程式化執行。
• 成功能透過使用者自訂的解決標準清楚衡量。

原文提到一個很有意思的商業訊號：已有多家公司採用「只在成功解決問題時才收費」的計費模式，這代表他們對自家 Agent 的成效有相當高的信心。

B. Coding Agents：程式碼的可驗證特質

軟體開發領域展現出驚人潛力，從單純的程式碼補全演變到自主解決問題，因為：

• 程式碼解法可以透過自動化測試驗證。
• Agent 能用測試結果作為回饋來迭代改進解法。
• 問題空間結構清晰、定義明確。
• 輸出品質能被客觀衡量。

Anthropic 自己的實作已經能單靠 pull request 描述，解決 SWE-bench Verified 基準測試中的真實 GitHub issue。不過原文也提醒：自動化測試能驗證功能是否正確，但人類審查仍然是確保解法符合更廣泛系統需求的關鍵。

生活妙喻

為什麼這兩個領域像「量身訂做的舞台」

想像一場考試 vs. 一場開放式辯論

有些任務像申論題沒有標準答案的辯論：誰都說得通,很難判斷誰對誰錯，這種任務讓 Agent 難以自我校正，因為它不知道自己做得好不好。

但客服和寫程式，更像有明確評分標準的考試：

• 客服像客服中心的「案件是否結案」制度：顧客滿意度、問題是否解決，都是可以打勾的具體指標。就像一場口試，考官（顧客）當場就會告訴你「這題答對了沒」。
• 寫程式像一場自動評分的程式測驗：寫完程式碼，跑一下測試案例，馬上知道「通過」還是「失敗」，不需要等人來主觀評分。

為什麼「當場知道對錯」這麼重要？

如果 Agent 做完一步卻不知道自己做得對不對，它就沒辦法自我修正、往正確方向前進——就像一個人在黑暗中射箭，永遠不知道有沒有中靶。而客服與寫程式恰好都提供了清楚、即時的靶心回饋：訂單有沒有處理成功？測試有沒有通過？

flowchart LR
    A[Agent 採取行動] --> B[明確的成功標準]
    B --> C[即時回饋 顧客滿意 或 測試結果]
    C --> D[Agent 據此調整下一步]
    D --> A

實用超能力

用四個特徵檢視你的任務適不適合做成 Agent

拿你手邊的任務對照四個特徵

下次你在評估「這個任務適不適合做成 Agent」時，可以拿出這張檢查清單，逐項對照：

如果你的任務四項都能打勾，這通常是投入 Agent 的好時機；如果成功標準模糊、沒有回饋迴圈，那麼即使任務看起來很「智能」，也可能更適合用工作流，甚至只是單次 LLM 呼叫。

別忘了人類審查這一關

原文特別強調：即使自動化測試能驗證功能正確性，人類審查仍然不可或缺，因為測試只能驗證「程式碼是否如預期運作」，卻無法完全確認解法是否符合更廣泛的系統設計、商業邏輯或架構考量。這提醒我們：Agent 的自主性再高，人類監督這一環都不該被省略。

深度探秘

工具定義值得和提示詞一樣被精雕細琢

為什麼工具設計這麼重要？

Agent 的實作往往很直白：基本上就是 LLM 根據環境回饋，在迴圈裡使用工具。正因如此，工具與工具說明文件設計得清不清楚，直接決定了 Agent 表現的好壞。原文用一整篇附錄（Appendix 2）專門討論這件事。

同一個動作，可以有很多種表達方式

原文舉例：要指定一次檔案編輯，你可以：

• 寫一份diff（差異片段）；或
• 直接重寫整個檔案。

要回傳結構化輸出，你可以：

• 把程式碼包在Markdown 裡；或
• 包在JSON 裡。

這些差異在軟體工程角度看是表面的 (cosmetic)——可以無損地互相轉換。但對 LLM 來說，某些格式比其他格式難寫得多：

• 寫 diff 需要先知道這段變更會改幾行（在寫新程式碼之前，就要算出 chunk header 的行數）——這對模型是額外的認知負擔。
• 把程式碼包進 JSON（相較於 Markdown）需要額外處理換行與引號的escaping——這也是無關緊要卻容易出錯的細節。

三個挑選工具格式的建議

1. 給模型足夠的 token『思考』，別讓它還沒想清楚就被迫寫死答案，把自己寫進死角。
2. 格式盡量貼近模型在網路文本中自然見過的樣子——模型見過越多次的格式，用起來越順手。
3. 消除不必要的格式『overhead』——像是要求精確計算幾千行程式碼的行號，或是要求把程式碼字串轉義，這些都是與任務本身無關、卻容易產生錯誤的額外負擔。

生活妙喻

把 HCI 的用心，搬來做 ACI

人機介面設計，早就是一門顯學

我們都知道，設計一支好用的手機、一個好用的網站，需要投入大量心力做人機互動介面 (Human-Computer Interface, HCI)——按鈕要放在哪、字要多大、操作邏輯要多直覺，這些都被反覆打磨過。

原文提出一個關鍵類比：

該投入多少心力在 HCI 上，就該投入多少心力在「Agent-電腦介面」（Agent-Computer Interface, ACI）上。

也就是說，你替 LLM 設計的工具，就像替一位新來的『數位員工』設計操作介面。如果按鈕標示不清、操作邏輯彆扭，一般人類使用者會用得很挫折；同樣道理，如果工具的參數名稱模糊、說明不清楚，LLM 也會頻頻用錯。

站在模型的角度，重新審視你的工具

把自己想像成第一次拿到這個工具的人：

• 光看工具描述和參數，我能不能一眼看懂怎麼用？還是得反覆猜測、試錯？
• 如果連我自己（設計者）都要想很久才搞懂，那模型大概率也會卡住。

一個好的工具定義，通常會包含使用範例、邊界情況、輸入格式要求，以及與其他工具的清楚界線——就像一份寫給新進工程師的優質文件。

flowchart LR
    A[HCI 人機介面] -->|投入等量心力| B[ACI Agent電腦介面]
    A --> C[按鈕清楚 操作直覺]
    B --> D[工具說明清楚 參數命名直覺]

實用超能力

四步驟打磨你的工具

實務打磨流程

原文給出具體的操作建議，可以整理成四個實用步驟：

1. 同理模型：問自己「光看描述和參數，這個工具好不好上手，還是需要仔細想過才會用？」如果連你自己都要想，模型大概也會卡住。
2. 改善命名與說明：把參數名稱、描述寫得更明確——想像自己在替團隊裡的新人寫一份清楚的文件，尤其在有很多相似工具時，這一步特別重要。
3. 實測、觀察、迭代：在 workbench 這類環境中，跑大量範例輸入，觀察模型實際上會在哪裡犯錯，然後不斷調整工具設計。
4. poka-yoke 你的工具：這是一個源自日文的品管術語，意思是改造設計讓犯錯變得更困難——透過修改參數形式，讓模型幾乎不可能用錯。

Anthropic 自己踩過的坑：相對路徑 vs. 絕對路徑

原文分享了一個真實案例：在打造 SWE-bench 用的 Agent 時，他們發現模型使用相對檔案路徑的工具時，一旦 Agent 已經移出根目錄，就很容易犯錯——因為模型很難時刻記住自己目前在哪個目錄。

解法：把工具改成永遠要求絕對路徑。改完之後，模型使用這個工具的方式變得完全正確、零失誤。

# 修改前：容易因為目前工作目錄不確定而出錯
edit_file(path="src/utils.py")

# 修改後：poka-yoke，強制使用絕對路徑，消除歧義
edit_file(path="/home/project/src/utils.py")

這個真實案例完美示範了「poka-yoke」的精神：不是靠提示詞叮嚀模型『請小心使用相對路徑』，而是直接改造工具，讓犯錯的可能性從結構上被消除。

深度探秘

成功不是做出最複雜的系統

全文最重要的一句話

讀完整篇文章，原文用一段話總結核心精神：

LLM 領域的成功，不是做出最精巧複雜的系統，而是做出剛好適合你需求的系統。

具體的實踐路徑是：

1. 從簡單提示詞開始。
2. 用完整的評估 (comprehensive evaluation) 來優化它們。
3. 只有當更簡單的方案明顯不夠用時，才加入多步驟的代理系統。

這句話呼應了本章開頭第一節就強調的原則——先求簡單，再談複雜，現在我們繞了一圈回到這個起點，但多了整整一章的具體知識支撐它。

三個核心原則

實作 Agent 時，原文提出三個應該遵循的核心原則：

這三個原則，其實正好對應了整篇文章的三大主題：要不要用代理系統的判斷（簡單）、Agent 執行過程中的可觀察性（透明）、以及工具設計的打磨（ACI）。

生活妙喻

蓋房子不是比誰的藍圖線條最多

建築師的智慧

一位好的建築師，不會因為想炫技就把房子設計得越複雜越好——樑柱交錯得越花俏、機關越多，房子反而越容易出問題、越難維護。真正厲害的建築師，設計出的房子是剛好符合居住者需求的：夠用、耐用、住起來順手。

對應到三個原則：

• 簡單：不會為了展現設計能力硬塞多餘的結構，房間夠用就好，不需要為了「看起來厲害」多蓋一層根本用不到的樓層。
• 透明：好房子的管線圖、電路圖都清楚標示，維修工人一看就知道問題在哪，不必砸開牆壁到處猜。
• 打磨介面：門把、開關、水龍頭都設計得直覺好用——這正對應 ACI，讓使用者（模型）一用就懂,不需要說明書都能上手。

flowchart TD
    A[好的 Agent 系統] --> B[簡單 不多蓋沒用的樓層]
    A --> C[透明 管線電路圖清楚標示]
    A --> D[打磨 ACI 門把開關直覺好用]

框架就像請了設計顧問

原文提到框架能幫助快速起步，就像請一位設計顧問幫你套用現成的設計範本，能加快初期規劃；但等你真的要長期住進這棟房子（正式環境），別怕依照自己真正的需求，把不合用的部分拆掉重建。

實用超能力

把整章知識串成一張決策地圖

從頭到尾的決策流程

走過這一整章，我們可以把所有知識串成一張實用的決策地圖，下次遇到「該怎麼設計這個 LLM 系統」的問題時直接拿出來用：

flowchart TD
    A[有個任務要用 LLM 解決] --> B{單次呼叫加檢索/範例夠嗎}
    B -->|夠| C[優化單次呼叫 收工]
    B -->|不夠| D{任務能拆成固定步驟嗎}
    D -->|能 且循序依賴| E[Prompt Chaining]
    D -->|能 且需先分類| F[Routing]
    D -->|能 且子任務彼此獨立| G[Parallelization]
    D -->|能 且需要反覆生成評估| H[Evaluator-optimizer]
    D -->|不能 步驟數無法預測| I{子任務能動態決定嗎}
    I -->|能 有中央指揮| J[Orchestrator-workers]
    I -->|開放式 需要模型自主決策| K[Agent]
    K --> L[別忘了 打磨工具 ACI]
    K --> M[別忘了 設護欄與停止條件]
    K --> N[別忘了 沙盒測試]

三句話收尾

如果只能記住三句話，就記住：

1. 先求簡單，只有真的需要才加複雜度——複雜是最後手段，不是起手式。
2. 搞懂你在用的是工作流還是 Agent，這決定了你的除錯方式與信任程度。
3. 不管做的是工作流還是 Agent，工具與介面都值得像人機介面一樣被認真打磨——這往往是決定成敗的隱藏關鍵。

框架能幫你快速起步，但別忘了：走向正式環境時，勇於拆掉不必要的抽象層，用基本元件打造出真正可靠、可維護、被使用者信任的系統。