工作流程和代理該怎麼選？
Building with the Claude API
的第 57–67 堂先從 Claude Code 與 MCP
整合看代理如何使用工具，再用平行化、串連、路由與評估者-優化者拆出可預先定義的工作流程；本篇也整理抽象工具、環境檢查，以及可靠性和彈性的取捨，Computer
Use 主要作為理解環境觀察的例子。
上一篇〈Building with the Claude API（6/7）：MCP：Tools, Resources & Prompts〉把 MCP 的 tools、resources、prompts 接起來，讓 Claude 能碰到外部工具和資料。走到最後一段，我開始想另一個問題：工具都有了，下一步到底該由誰決定？
這次打開 Claude Academy 的 Building with the Claude API，也回到 Claude Platform 對照 API、Claude Code 和代理的關係。課程先用 Claude Code 拆解一個已經存在的代理，再把工作流程和代理放到同一張設計圖上比較。
| Section | 這一組在處理的問題 |
|---|---|
| Anthropic apps - Claude Code and computer use | Claude Code、Computer Use 為什麼可以當成代理的案例？MCP 又怎麼把外部能力接進來？ |
| Agents and workflows | 已知步驟、未知任務，以及可靠性、彈性和可測試性之間要怎麼取捨？ |
這兩組放在一起很有意思。前半段從產品回頭拆設計原則，後半段則從設計模式回頭問：這個任務真的需要代理嗎？
Claude Code 和 Computer Use 可以當成理解代理的兩個成品案例。
Claude Code 是跑在終端機裡的代理式編碼助手，可以編輯檔案、修復錯誤、回答程式設計問題，並協助建立開發流程。Computer Use 則讓 Claude 存取網站、瀏覽網路，或與需要視覺介面導航的桌面應用程式互動。
課程把它們拆成四個值得觀察的原則：
這個角度比「某個產品有哪些按鈕」更有用。你可以把 Claude Code 看成一個已經把工具、迴圈和環境互動組合好的案例，再反過來問自己的代理少了哪一塊。後面的環境檢查，也會從 Computer Use 的螢幕截圖機制接回來。
Claude Code 的能力可以先分成四類：
| 類別 | 能力 |
|---|---|
| 檔案操作 | 搜尋、讀取並編輯專案中的檔案 |
| 終端機存取 | 直接從對話中執行命令 |
| 網路存取 | 搜尋文件、擷取程式碼範例等 |
| MCP 伺服器支援 | 透過連接 MCP 伺服器新增額外工具 |
課程示範的設定流程很短：先安裝 Node.js，再安裝 Claude Code，最後執行 claude 登入 Anthropic 帳戶。安裝命令是：
npm install -g @anthropic-ai/claude-code
它支援 macOS、Windows WSL 和 Linux。這堂課的重點不在安裝本身，而在於安裝之後，Claude Code 會從「回答程式碼問題」往「在專案裡採取行動」移動。
/init 會掃描 codebase，理解專案結構、依賴項、程式碼風格和架構，再把整理出的內容寫進 CLAUDE.md。之後的對話可以把這個檔案當成專案上下文的一部分。
CLAUDE.md 可以放在三個範圍：
| 範圍 | 用途 |
|---|---|
| 專案（Project） | 放在專案根目錄，讓參與專案的工程師共用，通常提交到 version control |
| 本地（Local） | 個人的專案筆記，不提交到 git |
| 使用者（User） | 放在個人設定資料夾，套用到自己的所有專案 |
這個區分很重要。團隊共享的專案規範應該放在 project-level，個人偏好則留在 user-level；兩者混在一起，久了就會分不清哪條規則是專案共識、哪條只是某個人的習慣。
輸入 # 也可以快速加入筆記，例如：
# Always use descriptive variable names
Claude 會接著詢問這條筆記要加入專案、本地，還是使用者範圍。
課程整理出的工作節奏，是先讓 Claude 讀懂上下文，再讓它只做規劃，最後才進入實作：
如果改成測試驅動開發（TDD），順序會再多一步：先給上下文，再請 Claude 想測試案例，挑選相關案例寫成測試，最後請它寫出能通過測試的程式碼。這樣成功標準會先被固定下來，Claude 後面每一輪修改都有一個可以檢查的方向。
官方示範的完整節奏如下：
// First, ask Claude to read relevant files
> Read the math.py and document.py files
// Then ask for planning (not implementation)
> Plan to implement document_path_to_markdown tool:
1. Create a function that:
- Takes a file path parameter
- Validates the file exists
- Determines file type from extension
- Reads binary data from file
- Leverages existing binary_document_to_markdown function
- Returns markdown string
2. Add appropriate documentation
3. Register the tool with MCP server
4. Add tests
// Finally, ask for implementation
> Implement the plan
這和前面 Claude Code 課程裡的 Explore 探索 → Plan 計畫 → Code 編碼 → Commit 提交 是同一種節奏：先把問題放進正確的上下文，再定義成功的形狀，最後才讓模型動手。
Claude Code 內建 MCP client，可以接上 MCP server 擴充能力。每個 server 可以公開三類東西：tools 負責執行動作，prompts 提供可重複使用的指令範本，resources 則提供可以帶入上下文的資料。
註冊 MCP server 的命令很直接：
claude mcp add [server-name] [command-to-start-server]
claude mcp add documents uv run main.py # 例子
啟動 Claude Code 時，它就會自動連上已註冊的 server。課程用前面建立的 document server 當例子：當使用者要求把 tests/fixtures/mcp_docs.docx 轉成 Markdown，Claude Code 可以自行判斷要呼叫 document_path_to_markdown。
這裡把前一篇 MCP 課程的抽象概念接回日常工具。MCP server 負責維護外部能力，Claude Code 負責在任務中決定什麼時候使用它；原本散落在應用程式裡的整合程式碼，於是變成可以獨立測試與接入的工具介面。
工作流程和代理，都是處理「Claude 無法在單次請求中完成的任務」的策略。差別在於下一步怎麼產生：
| 選哪個 | 條件 |
|---|---|
| 工作流程 | 你能清楚描繪出 Claude 該經歷的確切流程／步驟；或 UX 把使用者限制在一組特定任務 |
| 代理 | 你不確定究竟會給 Claude 什麼任務或任務參數 |
工作流程是一系列預先安排的 Claude 呼叫，依固定步驟解決特定問題。代理則拿到一個目標和一組工具，讓 Claude 在執行當下決定如何組合它們。
課程先用「圖像轉 CAD」說明工作流程。使用者拖放一張金屬零件圖片，要產出 STEP 檔，流程可以固定成：
這是「評估者-優化者（evaluator-optimizer）」模式：
| 角色 | 職責 |
|---|---|
| 生產者 | 接收輸入、產生輸出，例如用 CadQuery 建模並渲染 |
| 評分者 | 依照標準評估輸出 |
| 回饋循環 | 評分者不接受時，把回饋送回生產者改善 |
| 迭代 | 重複到評分者接受 |
前幾篇的提示評估是在開發階段找出比較好的 Prompt；這裡則把「產生、評分、修正」搬進產品執行期間。相同的思路，使用時機不同。
假設正在做材料設計：使用者上傳零件圖片，系統要在金屬、聚合物、陶瓷、複合材料、彈性體或木材之間建議最佳材料。
把所有標準塞進一次請求，Claude 得同時處理太多競爭條件；只寫一個簡單提示，又沒有交代每種材料的判斷依據。平行化的做法是把同一張圖片送出多次，每個請求只負責一種材料的專門標準，最後再把分析結果交給彙總步驟比較。
流程可以畫成：
同一張零件圖片
├── 金屬標準 → Claude 分析
├── 聚合物標準 → Claude 分析
├── 陶瓷標準 → Claude 分析
├── 複合材料標準 → Claude 分析
├── 彈性體標準 → Claude 分析
└── 木材標準 → Claude 分析
↓
彙總所有結果
↓
最終建議
這種拆法的好處不只在於可以同時執行：
| 優點 | 內容 |
|---|---|
| 專注的注意力 | Claude 一次只專注一個面向，不必平衡相互競爭的考量 |
| 更容易調校 | 每個子提示可以獨立改善與測試 |
| 更好的可擴展性 | 加一種材料等於加一個平行請求，不必重寫既有提示 |
| 提升可靠性 | 降低模型的認知負擔，讓結果更一致 |
平行化適合複雜決策可以拆成獨立評估的情況。每個子任務都要能自己運作，並為最後的決策提供一塊獨特分析；如果子任務彼此需要對方的輸出，就該換成串連。
串連把一個大任務拆成較小、連續的子任務。後面的步驟必須吃前面的輸出，所以順序固定，也無法像平行化那樣同時處理。
官方用自動建立並發布影片的社群媒體行銷工具示範：
第 1、5、6 步不需要由 LLM 完成，這也是串連的彈性所在：流程裡可以混入搜尋、影音處理和發布等一般程式。
串連最有說服力的用途，是處理「長提示裡有幾條規則一直被忽略」的情況。與其在同一個 Prompt 裡持續加粗、加標題、重複提醒，可以把創作和修訂拆成兩次請求：第一步先接受一個還不完美的初稿，第二步讓 Claude 專心做規則檢查。
修訂下方提供的文章。請按照以下步驟重寫文章：
1. 找出文本中任何將作者標示為 AI 的位置並移除
2. 找出並移除所有表情符號
3. 找出任何令人尷尬的寫法，並替換成技術文件撰寫者會寫的文字
第二次請求只負責修訂，就不需要同時處理「產生內容」和「遵守所有限制」兩件事。這個做法也很容易套進文章、程式碼或報告的產出流程。
路由處理的是另一種問題：不同類型的使用者請求，需要不同的 Prompt、工具或知識背景。課程的例子是影片腳本——「程式設計」需要教育性內容，「衝浪」則需要娛樂導向的內容。單一通用提示很難同時把兩種需求處理好。
官方列出的六個內容類別如下：
| 類別 | 特徵 |
|---|---|
| 娛樂 | 高能量、具文化相關性，使用流行語言 |
| 教育 | 清晰、引人入勝的解釋，配相關範例 |
| 喜劇 | 尖銳、出乎意料，巧妙的觀察與時機掌握 |
| 個人影音日誌 | 真實、親密，對話式敘事風格 |
| 評論 | 果斷、基於經驗，突顯優缺點 |
| 敘事 | 生動細節與情感連結的沉浸式內容 |
路由是兩步流程：先分類，再交給分類對應的專門處理流程。分類請求可以這樣寫：
Categorize the topic of a video into one of the listed categories:
<topic>Python functions</topic>
<categories>
- Educational
- Entertainment
- Comedy
- Personal vlog
- Reviews
- Storytelling
</categories>
如果 Claude 回傳「教育」，第二次呼叫就使用教育範本。使用者的輸入只會進入其中一個專門流程，每一個流程都可以針對自己的使用情境調校。
API 1：「墾丁天氣好嗎適合衝浪嗎？」+ <分類表> → 回傳：娛樂
API 2：「墾丁天氣好嗎適合衝浪嗎？」+ <娛樂 prompt template> → 回傳：風格化的娛樂語氣回答
這裡的「專門流程」不只可以換語氣。客服系統可以依問題類型換知識庫和工具組，報告系統可以依文件類型換輸出格式；路由那一次分類呼叫，換來的是後面更窄、更容易調校的處理環境。
實作時也要替分類失準準備預設路徑。當回傳的標籤不在既定類別裡，系統仍然需要知道要交給哪個流程，這是路由額外引入的邊界條件。
走到這裡，代理的定義變得很清楚：知道確切步驟，就把步驟寫成工作流程；不知道下一個任務會長什麼樣，就給 Claude 一個目標和一組工具，讓它在執行時決定怎麼組合。
工具的設計會直接影響代理能處理的情境。課程用幾個日期時間工具示範組合能力：
| 請求 | Claude 怎麼組 |
|---|---|
| 「現在幾點？」 | 只呼叫 get_current_datetime |
| 「11 天後是星期幾？」 | 串 get_current_datetime + add_duration_to_datetime |
| 「設定下週三的健身房提醒」 | 依序用全部三個工具 |
| 「我的 90 天保固什麼時候到期？」 | 先反問購買日期，才能算到期日 |
最後一列很有代表性：代理不只會挑工具，也知道目前資訊不足，需要先向使用者提問。
課程最重要的設計洞見，是工具應該保持抽象、可組合，而非為每一種高階任務各做一個專門按鈕。Claude Code 的工具可以概括成：
bash（執行任何命令）、read（讀取任何檔案）、write（建立任何檔案）、edit（修改檔案）、glob（尋找檔案）、grep（搜尋檔案內容）
它沒有一個叫「重構程式碼」或「安裝依賴項」的專門工具。Claude 會自己把基本工具組合起來完成複雜任務，這讓代理有機會面對開發者事前沒有規劃過的情境。
這裡也能分清楚 workflow 和 agent 的另一個差別：工具描述本身不會讓系統變成代理，因為固定流程呼叫工具時也需要 schema。真正的差別在於誰決定呼叫順序和次數——workflow 把決定寫在程式碼裡，agent 則交給模型在執行時決定。
代理能採取行動，還不代表它知道行動有沒有成功。它需要一個觀察環境的手段，才能依結果調整下一步。
Computer Use 的例子很直觀：Claude 每輸入文字或點擊按鈕，就會收到新的螢幕截圖。按鈕可能把畫面導向新頁面、打開選單，或觸發其他狀態變化；如果看不到後果，它就沒有足夠資訊判斷剛才的操作是否生效。
檔案操作也遵循相同原則。要在 Python 檔案新增路由，先讀現有程式碼，了解目前的結構和命名方式，再開始修改。這個「先讀取再寫入」不是形式上的步驟要求，重點是不要憑印象覆蓋尚未確認的現況。
課程給影片建立代理的系統提示，則把觀察手段寫得更具體：
因此，設計代理時可以反覆問一句話：「Claude 如何知道這個動作是否成功？」
| 動作 | 可以使用的觀察手段 |
|---|---|
| 修改檔案 | 修改前先讀取，修改後跑測試或檢查 diff |
| 操作介面 | 取得新的螢幕截圖，確認畫面狀態 |
| 呼叫 API | 檢查回應是否包含預期資料 |
| 產生內容 | 依需求驗證格式、內容和輸出檔案 |
沒有觀察手段的代理，很容易變成只會一路往下執行的盲打流程。系統提示可以協助它記住檢查規則，但真正重要的是每個動作都要有相對應的回饋路徑。
把兩者放在一起看，差異可以整理成這張表：
| 優點 | 缺點 | |
|---|---|---|
| 工作流程 | 一次專注一個子任務，通常準確度較高；更容易評估與測試；執行可預測可靠；適合定義明確的問題 | 彈性較低；UX 較受限；需要更多前期規劃與設計 |
| 代理 | UX 更靈活；能以意想不到的方式組合工具；能處理開發時未預料的新情況；需要時可向使用者詢問額外輸入 | 任務成功完成率較低；更難監測、測試與評估；行為較不可預測 |
所以判斷順序可以很簡單：
這個結論有點反高潮，卻很務實。使用者在意的是產品能不能穩定完成工作，不在意背後是不是用了看起來很厲害的代理。可靠性是第一個目標，代理的彈性要在真的有需要時才換進來。
有 7 題。官方頁面本身是繁中，以下保留實際題目與正確答案。
答案：將請求路由到專門的處理流程
答案：針對每種材料類型平行發送個別請求
答案：使用工作流程，因為它更可靠且可測試
答案：提供抽象工具，例如「read_file」、「write_file」和「run_command」
答案：具有預定步驟的工作流程
答案：評估者-優化者模式
答案：將任務鏈接成專注的連續步驟
這個 section 沒有再手寫程式，重點轉成：什麼時候該用哪種工作流程。課程用範例把差別講清楚；上課時，我除了看課程內容，也會反問 agent：這是不是我平常工作流程的某一種形式，再把自己的案例帶進去追問。這樣比較快確認自己是真的理解，還是只記住了名詞。下面整理幾個我用來對照的問題，以及每一堂課留下的筆記：
在 Agents and workflows 裡，工作流程和代理都在處理單次請求做不完的任務。前者先寫好步驟，後者讓 Claude 在工具集合裡自己決定路徑；評估者-優化者則把提示評估的「打分再改」循環帶進 runtime。
平行化的本質，是把一個任務拆成互不相干的子任務。每個子任務只專注一種標準，同時發出去獨立判斷，彼此不知道對方的存在，最後再彙總結果。這個「拆窄→品質穩」的原則不限定於技術定義上的「代理」；任何一次 Claude 呼叫都適用。職責越單一、標準越明確，判斷就越可靠。
拿自己日常使用的 Claude Code 多 subagent 模式來對照：如果「分幾隻、每隻查什麼」是寫死在程式碼裡的，那就是這堂教的 parallelization（workflow）；如果由主控在執行時判斷要開幾隻、各自查什麼，則更接近 Anthropic〈Building effective agents〉 裡介紹的 orchestrator-workers。這是 Anthropic 列出的五種 workflow pattern 之一，而本課 61–64 堂只教了其他四種，剛好漏掉自己每天使用的這一種。
串連的核心，是把一件事拆成有先後依賴的小步驟，一步步個別執行。後面的步驟一定要吃前面的輸出，順序固定，不能打亂，也不能同時做；這和 62 堂子任務互相獨立、可以平行處理的做法正好相反。
路由可以看成兩次獨立的 API 呼叫：第一次把問題和分類表交給 Claude，取得類別標籤；第二次把原問題和該類別專屬的 prompt template 交給對應流程，產生最後的風格化回答，這次不需要再帶分類表。以「墾丁天氣好嗎，適合衝浪嗎？」為例，第一次呼叫可能回傳「娛樂」，第二次就使用娛樂範本回答。
官方列出的六個類別——娛樂、教育、喜劇、個人影音日誌、評論、敘事——主要是在換風格、語氣和人設，因為底層任務都是寫影片腳本。但路由能換的不只是語氣，也可以是不同的知識背景、工具組和輸出格式。放到客服機器人裡，分類後對應的往往是一整套不同的知識與工具。實作時還要替分類失準準備預設或兜底範本。
工具描述本身和「是不是代理」沒有直接關係。無論是 MCP 還是原生 tool schema，workflow 呼叫固定工具時也要先描述清楚；這是工具呼叫的前提，不是代理獨有。真正的差別在於誰決定呼叫順序和次數：workflow 把決定寫死在程式碼裡，agent 則交給模型在執行時判斷。
既然要做代理，工具的顆粒度就應該像 Unix 哲學一樣原子化：每個小工具只專精做一件事，例如讀檔、查時間或上網，不要包成一個全能的複雜功能。這樣 Claude 才能依需求推算並重新組合工具；至於抽象程度要設多高，還是要看模型本身能不能撐得起那個抽象層級。
環境檢查不是「在系統提示詞裡定義什麼叫做完」這麼單薄，核心原則更廣——代理每做一個動作，都要配一個觀察這個動作結果的手段，依動作類型不同，實作方式也不同：UI 操作配截圖、檔案操作配先讀後寫、生成內容配主動跑驗證工具或跟原始需求比對。寫進系統提示詞只是其中一種實作，不是全部。
「先讀取再寫入」的深層含義，不是「輸入一定要先於輸出」這種計算上的必然順序，而是：不要憑「假設／印象」去寫，要憑「剛確認過的現狀」去寫。防的是這種情境——如果使用者在背景同時改了筆記，而我憑對話前面讀過的舊版本去寫，就會蓋掉使用者剛做的改動、甚至產生衝突。使用者手動提醒「筆記我改過，你再讀一次」，做的正是這件事；而這個 session 自己用的 Edit 工具也有一部分自動防呆——檔案在讀過之後被改過，工具會拒絕寫入、逼重讀最新版本，是同一個保護機制。
主動跑驗證工具（官方例子是驗證自己生成的字幕時間戳），可以延伸成兩個方向：驗證「我自己剛做出來的輸出對不對」（官方方向），以及驗證「我拿到的輸入本身有沒有問題」（例如使用者可能貼錯圖片）——兩者都是「別盲目相信，主動找工具查證」，只是查證的對象相反。
這門課最後留下的判斷順序很簡單：能預先定義流程，就先用 workflow；任務多變、路徑難以規劃時，再考慮 agent。選擇的起點是可靠地解決問題，工具數量或架構名稱都排在後面。
最後，Building with the Claude API 是我到目前為止上過最扎實的一門課。課程設計了 67 堂課，預計總共 9 小時；但我原本規劃用三天上完課、寫程式，再同步寫鐵人賽文章，根本做不到 XDD。
第一天上完前兩個 section，筆記就累積了一萬九千多字，嚇到我自己，根本看不完。光是把課程內容聽完、理解它實際在說什麼，就花了三小時，還沒開始寫文章。發完鐵人文章後，我馬上重新排課，直接改成七天；現在回頭看，這個調整完全沒錯。
第二天進入第三個 section「提示工程技巧」後，每堂課都帶著很完整的教學心法。跟著課程走一遍，真的會發現很多平常沒注意到的細節，所以這門課很值得推薦大家跟著走一遍。
我自己的做法是先讓一個 agent 爬過課程筆記，再開始上課；上課時把筆記打開，另外讓一個 agent 用教學引導模式跟我討論哪裡理解錯了。每節課結束，我會先用口頭方式說出這堂課的核心重點，等 agent 確認方向沒有偏掉，再繼續往下一堂。這個方法不能保證我完全沒有誤解，但至少會逼我在前進前先說清楚自己到底學到了什麼。
如果你也想把這門課完整走完，可以接著挑戰〈Building with the Claude API：Final Assessment 最終測驗〉，裡面整理了 23 題最終評量、對應章節與考點。
我是 Jasper，從事軟體開發，目前專注打造 AI 工作流程。
官方圖解與完整表格在 Blog 版，和我一起探討更多 AI 議題 🚀
iThome鐵人賽
看影片追技術