Agent 是什麼？先想清楚要不要用

同一個字，工程師講的常常不是同一件事——先畫清界線，再談要不要動手蓋

「Agent」這個字，其實有點混亂

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

但問題是，「Agent」這個詞本身很模糊。有人說它是完全自主、能長時間獨立運作、自己選工具完成複雜任務的系統；也有人拿它形容照著預先定義好的流程在跑的實作。同一個字，兩種完全不同的東西。

🍳

先給你一個畫面

想像你今天要做一頓晚餐。有一種做法是照著食譜一步步來——切菜、熱鍋、下油、下料，每一步都寫得清清楚楚；另一種做法是把廚房直接交給一位經驗老到的大廚，只說「我要一頓讓客人驚艷的晚餐」，剩下的全部交給他自己判斷。這兩種，做出來的「晚餐」性質完全不同。

Anthropic 怎麼畫這條線：原文對照

Anthropic 的做法是：把所有變體都先歸類成代理系統（agentic systems），再在底下畫出一條真正重要的架構分界線——直接讀官方原文，比任何轉述都精準：

原文 · Anthropic Engineering At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents. Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks. When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.

白話翻譯

在 Anthropic，我們把這些變體統稱為「代理系統」，但在底下畫出一條重要的架構分界線——工作流（workflows）與 Agent（agents）。

工作流：LLM 和工具，是照著預先寫好的程式路徑被編排、被指揮的系統。

Agent 則相反：LLM自己動態決定流程要怎麼走、要用哪些工具，掌控權在它自己手上。

打造 LLM 應用時，我們建議先找出最簡單能解決問題的方法，只有真的需要時才增加複雜度。

這甚至可能意味著——根本不需要打造代理系統。

💡

判斷句只有一句話

下次要分辨眼前這個系統是工作流還是 Agent，只要問：「決定下一步要做什麼的，是寫好的程式碼，還是模型自己？」答案是程式碼，就是工作流；答案是模型自己，就是Agent。

兩張卡片，定義兩種性格

這條分界線幾乎決定了你系統的「性格」。工作流像照著食譜做菜，每次做出來的味道都差不多；Agent 像請大廚自由發揮，可能驚喜連連，也可能失控。

📋

工作流 Workflow

LLM 與工具照著預先寫好的程式路徑被編排執行。流程固定，每次跑出來都差不多——換來的是可預測性與一致性。適合任務明確、可以乾淨拆成固定步驟的情境。

🧭

Agent

LLM自己動態決定流程怎麼走、用什麼工具，掌控權在它手上。換來彈性，能應付開放、多變的任務——代價是更高的延遲與成本，也更難預測。

⚖️

代理系統不是免費的午餐

代理系統（不管工作流還是 Agent）常常是拿更高的延遲與成本，去換更好的任務表現——這是一筆交易，你得先誠實評估划不划算。原文甚至直接說：對很多應用而言，優化單次 LLM 呼叫（搭配情境內範例與檢索）通常就已經足夠，根本不必勞師動眾上代理系統。

動手分分看：這個情境該用哪一種？

把下面六個實際情境，拖到它比較適合的分類——「用工作流」還是「用 Agent」。拖完按「對答案」。

客服機票退款：固定四步驟（核對訂單→查政策→算退款→發通知）

開放式研究任務：不知道要查幾輪資料、每一步該搜什麼要邊做邊判斷

行銷文案先寫好、再翻成另一種語言，兩步驟順序固定

需要即時讀取環境回饋、邊除錯邊決定下一步指令的除錯任務

格式轉換：把同一批檔案，每天定時批次轉成同一種格式

開放式編碼任務：需要自己讀程式碼、自己決定要改哪個檔案、要不要跑測試

用工作流 Workflow ——步驟固定、可預期

拖到這裡

用 Agent ——路徑無法預先寫死，得靠模型當下判斷

拖到這裡

🔑

分類的關鍵不是「難不難」

不是「聽起來複雜」就該上 Agent。真正的判準是：這條路徑「能不能在寫程式的當下就先想清楚、寫死」。能，就是工作流的地盤；不能——得等模型看到當下狀況才知道下一步——才輪到 Agent 出場。

框架能幫你，也能害你

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

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

先徒手做一輪

很多模式其實幾行程式碼就能實作。親自用 LLM API 直接寫過一次，你才知道框架到底幫你省了什麼。

搞懂底層在做什麼

如果決定用框架，一定要懂它底層在做什麼——「對底層運作的錯誤假設」是客戶最常見的出錯來源。

上線前敢拆

框架適合起步，不代表適合正式環境。別怕拆掉不必要的抽象層，換成更貼近底層的基本元件。

小試身手

看懂這一格，你就抓到整章的核心判斷框架了。來兩題：

根據 Anthropic 的定義，區分「工作流」和「Agent」最關鍵的架構差異是什麼？

開發 LLM 應用時，Anthropic 給的「第一原則」是什麼？

🧱

下一站：先打好地基

先搞懂什麼是「加強型 LLM」——所有代理系統共用的最小單位，再看最簡單的一種工作流：Prompt Chaining 接龍。往下捲。

基石：加強型 LLM 與鏈式工作流

先把新人變成配好裝備的專員，再學兩招最基本的排兵佈陣——接龍與分流

在疊工作流之前，先把「地基」打好

不管你最後想蓋的是一個簡單的三步驟流程，還是一個能自主決策的複雜 Agent，一切都是從同一塊最小積木開始的：加強型 LLM（the augmented LLM）。

它比一般 LLM 多了三樣裝備：

🔎

檢索 retrieval

主動查找需要的資訊，不再只靠腦中記得的東西亂猜。

🛠️

工具 tools

呼叫外部功能來完成任務——寄信、算數字、查天氣，通通能自己動手。

🧠

記憶 memory

記住之前發生過的事，還會自己判斷什麼資訊值得留下來。

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

🧑‍💼

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

一個普通 LLM，就像剛入職、什麼資源都沒有的新人：只能憑腦子裡記得的東西回答問題，問他公司上個月的業績，他只能靠印象亂猜。加強型 LLM，則是替這位新人配好了裝備的專員——給他一台能查資料庫的電腦（檢索）、一支萬用工具腰帶（工具）、一本隨身筆記本（記憶）。他不只是被動等你告訴他怎麼做，還會自己判斷現在該不該查、該用哪個工具、這件事值不值得記下來。

原文怎麼說：地基打好，後面才蓋得穩

這幾句話，是整篇文章從「打地基」進入「蓋工作流」的關鍵轉折。左邊是 Anthropic 原文，右邊是白話翻譯，一句對一句：

原文 · Anthropic Engineering The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory. Our current models can actively use these capabilities—generating their own search queries, selecting appropriate tools, and determining what information to retain. We recommend focusing on two key aspects of the implementation: tailoring these capabilities to your specific use case and ensuring they provide an easy, well-documented interface for your LLM. For the remainder of this post, we'll assume each LLM call has access to these augmented capabilities.

白話翻譯

代理系統最基本的建構單元，是一個裝上檢索、工具、記憶等加強能力的 LLM。

現在的模型已經能主動使用這些能力——自己生成搜尋查詢、自己選合適的工具、自己判斷該記住什麼資訊。

我們建議聚焦兩個重點：把能力打磨到貼合你的具體使用情境，並確保這些能力對 LLM 而言介面清楚、文件完整。

從這裡開始，本文接下來的所有內容，都預設每次 LLM 呼叫背後，都已經具備這些加強能力。

💡

最後一句是伏筆

「假設每次呼叫都已加強」這句話很好懂但很重要——後面要介紹的每一種工作流、每一種 Agent，骨子裡疊的都是這塊地基，不用每次重講一次「這次呼叫有沒有工具」。

怎麼實作這些加強能力？MCP 是其中一種答案

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

🔌

萬用轉接頭

不用替每個第三方工具重新設計一套介面，寫一個簡單的客戶端就能接上不斷成長的工具生態系——就像一個轉接頭適用所有插座，而不是每個國家的插座都自己買一顆變壓器。

在往上疊工作流或 Agent 之前，先問自己三個問題：我給模型的檢索能力，真的能查到它需要的資訊嗎？我給模型的工具，說明清楚到模型一看就懂該怎麼用嗎？模型需要記住的東西，有被妥善保留下來嗎？

🏗️

別急著蓋樓，先打地基

很多團隊一開始就想直接打造複雜的多步驟 Agent，卻忽略了最基本的問題：你的加強型 LLM 本身夠不夠好用？地基沒打好，上面疊再多流程也是空中樓閣。

工作流一：Prompt Chaining（提示詞接龍）

Prompt Chaining 把一個任務拆解成一連串步驟，每一次 LLM 呼叫都處理前一步的輸出，像接龍一樣一步接一步往下傳。你還可以在中間插入程式化檢查（gate），確保流程沒有跑偏。

下面演給你看：一份雙語產品公告，怎麼從草稿一路接龍到中英文雙版本，中間還會被品管站攔一次。按「下一步」試試看——如果卡在關卡，流程會被打回上一步重做。

📝

輸入任務

✍️

LLM 呼叫 1：寫中文草稿

🚧

Gate 品管關卡

🌐

LLM 呼叫 2：翻成英文

📦

雙語成品

按「下一步」開始這趟接龍

🏭

生產線比喻

Prompt Chaining 就像工廠生產線：每一站的工人只專心做好自己那一站的工作，不需要同時煩惱裁切、組裝、包裝三件事。如果沒有品管站，第一站的瑕疵品會一路帶著錯誤流到最後才被發現，等到包裝完才報廢，浪費更多成本——這正是「用延遲換準確度」：多花幾道檢查的時間，換每一步都做對的機率。

這個工作流最適合任務能被乾淨拆解成固定子任務的情境，例如：先生成行銷文案再翻譯成另一種語言；或是先寫文件大綱、檢查大綱是否符合標準，通過後再依大綱寫出完整文件。這兩個例子都有一個共同特徵——後一步天生依賴前一步的結果，而且每一步都能被單獨檢查、單獨優化。

工作流二：Routing（路由分派）

Routing 會先替輸入分類，再依分類結果把它導向一個專門的後續任務。這樣就能做到關注點分離—— 替不同類型的輸入各自打造更精準的提示詞，而不必用同一套提示詞硬扛所有情況。

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

💬

簡單問題 → 小模型快速回覆

常見、簡單的客服問題，導向便宜、快速的小模型（如 Claude Haiku 4.5），秒回不浪費資源。

🧩

複雜問題 → 大模型深入處理

困難、少見的問題導向能力更強的模型（如 Claude Sonnet 4.5），在效能與成本之間取得平衡。

💳

退款申請 → 專門流程

導向能存取訂單系統與退款 API 的專屬下游流程、提示詞與工具組合，跟一般問題、技術支援互不干擾。

🏥

急診室的分診邏輯

Routing 就像醫院急診室的分診台：病人一進門，護理師先快速判斷是感冒、骨折還是心臟病發，再導向對應專科。如果沒有分診台，一位全科醫生同時要顧感冒又要顧心臟病發，為了兼顧所有病症調整判斷標準，結果每一種病都看得不夠精準。

Routing 特別適合：任務裡有清楚可分的類別、且這些類別最好分開處理；同時分類這件事本身能被準確地完成——不管是靠 LLM 分類，還是靠更傳統的分類模型或演算法。分類錯了，後面導向的整套專門流程就用錯了地方，所以「分類要準」是這個工作流成立的前提。

小試身手

兩招最基本的排兵佈陣，你已經摸過一輪了。來兩題檢查一下：

Prompt Chaining 工作流的核心運作方式是什麼？

Routing 工作流要發揮效果，原文強調的重要前提條件是什麼？

🎬

下一站：工作流升級

接龍與分流都是「一步一步、一次一條路」的排法。下一站，我們要看三種更聰明的組合方式——平行處理、指揮官帶工人、生成與互評，讓多個 LLM 呼叫同時開工、彼此把關。

更聰明的工作流：平行、指揮與互評

當「一步接一步」不夠用——讓多個 LLM 呼叫同時開工、互相監督、甚至反覆修稿

別再排隊，讓大家同時開工

前面看到的 Prompt Chaining、Routing 都是「一次一步」。但有些任務根本不需要排隊——子任務彼此互不相干，那就讓它們 Parallelization（平行處理）同時跑，跑完再由程式把結果彙整起來。這個模式有兩種關鍵變體：

分

Sectioning（分段）

把一個任務拆成互相獨立的子任務，同時平行執行——各做各的事，最後彙整。

票

Voting（投票）

同一個任務跑好幾次，得到多個獨立且各異的輸出，再彼此比對或投票。

什麼時候該用？兩種情境特別有效：子任務可以平行化以加快速度；或是需要多個角度、多次嘗試才能得到更有信心的結果。原文還提到一個實務洞察——面對有多個考量因素的複雜任務，讓每個考量各自交給一個獨立的 LLM 呼叫處理，通常表現更好，因為每次呼叫能專注一個面向，不會被其他考量分心。

🍲

一人一菜，同時開工

辦宴席若讓一位廚師依序做完每道菜，客人都要餓到睡著。聰明的做法是讓三位廚師同時各自負責一道菜——這是 Sectioning。選秀比賽若只找一位評審，難免有個人偏好；找三位評審各自獨立打分，再看多數意見，這是 Voting。三位廚師做的是不同的事，三位評審做的是同一件事——搞懂這個差異，才能選對變體。

直接讀原文：guardrails 為什麼要拆開處理

原文舉的第一個 Sectioning 範例，是聊天機器人的護欄機制（guardrails）——一起讀讀 Anthropic 怎麼寫的。

原文 · Anthropic LLMs can sometimes work simultaneously on a task and have their outputs aggregated programmatically. Sectioning: Breaking a task into independent subtasks run in parallel. Voting: Running the same task multiple times to get diverse outputs. Implementing guardrails where one model instance processes user queries while another screens them for inappropriate content or requests. This tends to perform better than having the same LLM call handle both guardrails and the core response.

白話翻譯

LLM 有時候可以同時對一項任務展開工作，再用程式把輸出彙整起來。

Sectioning：把一個任務拆成互相獨立的子任務，平行執行。

Voting：同一個任務跑好幾次，得到多樣化的輸出。

實作護欄機制時，讓一個模型實例處理使用者查詢，另一個獨立篩查是否包含不當內容或請求——這往往比讓同一次 LLM 呼叫同時兼顧護欄與核心回應，表現更好。

🛡️

為什麼不要「一次呼叫兼兩件事」？

把「回答問題」和「檢查有沒有不當內容」丟進同一次呼叫，模型的注意力會被分散。拆成兩個獨立呼叫平行跑，各自專心做好一件事，最後再用程式決定「安全就放行，不安全就擋下」——這正是 Sectioning 的精神。

當任務沒辦法事先拆好：換指揮者上場

Sectioning 有個前提——你得事先知道怎麼拆。但如果任務千變萬化，沒辦法預先寫死拆法呢？這時候需要 Orchestrator-workers（指揮者-工人）工作流：一個中央 LLM（指揮者）負責動態拆解任務，把子任務委派給工人 LLM執行，再把結果綜合成最終答案。

原文特別提醒：這個模式跟 Parallelization 拓樸結構很像（都是一個中心點連到多個並行處理），但關鍵差異在彈性——Parallelization 的子任務是事先定義好的固定拆法；Orchestrator-workers 的子任務則是當場由指揮者依輸入內容決定。原文舉的例子是寫程式：需要改動幾個檔案、每個檔案怎麼改，往往取決於這次具體的任務內容，沒辦法事先寫死。

🏚️

樣品屋 vs. 老屋翻修

Sectioning 像蓋制式樣品屋：設計圖早就畫好「這裡要三個工班」，各班同時進場、各做各的。Orchestrator-workers 則像監工到一棟從沒見過的老屋——他得現場勘查才知道壁癌要不要處理、電線要不要重拉，然後當場決定要叫幾個工班、怎麼分工。因為踏進這棟房子之前，根本沒人知道會遇到什麼狀況。

三種工作流放在一起，點點看差在哪

到目前為止出現了三種「多重 LLM 呼叫」的模式，長得都有點像。點下面每個方塊，看它的定義，以及跟另外兩種的關鍵差異。

⚡ Parallelization
分工同做／多次表決

🧭 Orchestrator-workers
中央指揮動態拆工

🔁 Evaluator-optimizer
一評一改，迴圈打磨

Parallelization（分工同做／多次表決）：Sectioning 把任務拆成互相獨立的子任務同時跑；Voting 把同一任務跑好幾次取多個獨立輸出。子任務內容「事先定義好」，跟其他兩種的關鍵差異：不需要指揮者臨場判斷，也不需要反覆迭代——一次平行跑完就結束。

🔑

一句話分辨三者

子任務「早就知道怎麼拆」——用 Parallelization；子任務「要看情況才知道怎麼拆」——用 Orchestrator-workers；任務不是「拆」而是「同一份內容反覆修」——用 Evaluator-optimizer。

像作家改稿：生成、評分、打回重寫

Evaluator-optimizer（評估者-優化者）工作流由兩個角色組成，在一個迴圈裡反覆運作：生成者產出一份內容，評估者給出明確的評估與回饋，生成者再依此修改，如此反覆，直到達到滿意品質或次數上限為止。原文用一個貼切的比喻：這很像人類作家反覆修稿的過程。

什麼時候該用？兩個訊號都成立時特別有效：人類清楚表達回饋時，LLM 回應確實能被明顯改善；而且LLM 本身也能提供這樣的回饋。原文舉的例子是文學翻譯——譯者 LLM 一開始可能沒抓到細膩的語感或雙關，但評估者 LLM 能指出這些細節，讓翻譯逐輪改善。

✍️

生成者 Generator

🧐

評估者 Evaluator

✅

定稿輸出

按「下一步」看反覆修稿的迴圈怎麼跑

⚠️

回饋不能只是「感覺不太對」

編輯若只會說「不夠好」卻說不出哪裡不好，作家根本無從修改。評估者的回饋必須具體、可操作——這正是這個工作流成敗的關鍵前提。也別忘了設「最大嘗試次數」當迭代（iteration）的煞車，不然生成者跟評估者可能永遠打不完收工。

小試身手

三種「多重呼叫」工作流都認識了，來兩題確認一下有沒有真的分清楚。

一個搜尋任務要依查詢內容，當場決定去哪些來源蒐集資訊、分析多少篇文章，數量和來源每次查詢都完全不同。這最適合用哪種工作流？

用 Evaluator-optimizer 做文學翻譯時，評估者只對譯文說「感覺不太對」，卻說不出哪裡有問題。這會怎麼樣？

🤖

下一站：Agent

下一站：當任務真的需要「自己規劃、自己收尾」，我們就進入 Agent 本身，看它在真實世界怎麼運作。

Agent 本身、實務案例與打造好工具

當步驟數再也算不出來——放手讓模型自己規劃、行動、看真實回饋修正方向

前面都是工作流，這節終於輪到真正的 Agent

前幾個模組談的工作流，走的每一步都是你先想好、寫死在程式裡的。這節要談的 Agent 不一樣——流程不是你規劃的，是它自己邊做邊想出來的。

原文描述得很具體：Agent 從人類的一句指令、或一段互動討論開始；任務清楚之後，就獨立規劃、獨立行動，過程中不斷回頭跟環境要真實回饋，判斷自己走得對不對；卡關或到了檢查點就暫停等人類表態；任務完成就收尾，也常設停止條件兜底，避免它跑到失控。

開始

一句指令，或一段互動討論，任務目標逐漸清楚。

規劃與行動

Agent 獨立規劃下一步，呼叫工具、實際動手做。

取得地面真相

從環境（工具結果、程式執行結果）拿到真實回饋，校正自己的判斷。

收尾或喊停

任務完成就結束；沒完成但踩到停止條件，也要收手回報人類。

🧭

放手讓資深業務去談成一筆生意

你不會逐字告訴業務該說什麼話——只給目標，剩下交給他自己規劃、自己行動。他靠地面真相（客戶到底回信了沒、報價接受了沒）判斷進度，遇到超出權限的折扣要求就回頭找你——那就是檢查點。

跑一次看看：Agent 的自主迴圈

這不是一條直線流程，是一個會反覆繞回去的迴圈。按「下一步」，特別留意它怎麼繞回規劃那一步。

🧑

人類

🧠

Agent 規劃

🔧

工具呼叫

🌍

環境回饋

按「下一步」開始這個迴圈

🔁

重點是那條繞回去的箭頭

如果 Agent 只憑自己腦中的想像判斷進度，很容易愈走愈偏卻不自知。正因為它每一步都繞回環境要真實回饋，才能長時間自主運作、卻不至於完全失控。

直接讀原文：Agent 是怎麼被定義的

這一段是全文對 Agent 最完整的定義，值得逐句核對原文。

原文 · Anthropic Agents begin their work with either a command from, or interactive discussion with, the human user. Once the task is clear, agents plan and operate independently, potentially returning to the human for further information or judgement. During execution, it's crucial for the agents to gain "ground truth" from the environment at each step (such as tool call results or code execution) to assess its progress. Agents can then pause for human feedback at checkpoints or when encountering blockers. The task often terminates upon completion, but it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control.

白話翻譯

Agent 的工作，從人類的一句指令、或一段互動討論開始。

任務一旦清楚，Agent 就獨立規劃、獨立行動——過程中也可能回頭找人類要更多資訊或判斷。

執行過程中，Agent 必須在每一步都從環境取得「地面真相」（例如工具呼叫結果、程式執行結果），用來評估自己的進度。

Agent 可以在檢查點、或遇到卡關時暫停，等待人類回饋。

任務通常在完成時結束，但也常常設定停止條件（例如最多跑幾輪），藉此維持對系統的控制。

⚖️

什麼時候才該放手用 Agent？

原文給了明確的判斷標準：任務是開放式問題、難以事先預測要跑幾步、沒辦法把路徑寫死，而且你對模型的判斷有一定信任。Agent 的自主性很適合把任務規模化，但也代表更高的成本、以及錯誤可能累積放大的風險——所以要先在沙盒裡大量測試，搭配護欄限制它能做的事。

兩個真正跑起來的案例：客服與寫程式

Anthropic 跟客戶合作的經驗發現，客服和寫程式是特別能發揮 Agent 價值的領域。原因不是巧合，而是它們剛好都具備四個共同特徵：既要對話又要真的做事、有清楚的成功標準、能形成回饋迴圈、能整合有意義的人類監督。

🎧

A. 客服

對話天然依循流程，同時要存取客戶資料、訂單紀錄、知識庫；退款、更新工單能直接程式化執行；成功與否由使用者定義的解決標準清楚衡量。

💻

B. Coding Agent

程式碼解法能被自動化測試客觀驗證；Agent 拿測試結果當回饋迭代；問題空間結構清晰；Anthropic 自己的 Agent 已能單靠 PR 描述解掉 SWE-bench Verified 的真實 GitHub issue。

🎯

考試 vs. 沒有標準答案的辯論

有些任務像申論辯論，誰都說得通，Agent 很難自我校正。但客服和寫程式更像一場當場能打分數的考試——顧客滿不滿意、測試過不過，都是清楚的靶心回饋。已經有多家公司採用「只在成功解決問題才收費」的計費模式，這正說明他們對自家 Agent 的成效有相當高的信心。

但原文也提醒一句很關鍵的話：自動化測試能驗證程式碼是否如預期運作，人類審查仍然是確保解法符合更廣泛系統需求的關鍵——測試過關不代表可以完全省掉人來看一眼。

工具不是隨手寫的：Agent-電腦介面（ACI）

Agent 的實作往往很直白——基本上就是 LLM 根據環境回饋，在迴圈裡使用工具。正因如此，Agent-Computer Interface（ACI）設計得清不清楚，直接決定 Agent 表現的好壞。

原文舉了具體例子：同一個檔案編輯動作，可以寫成diff，也可以整檔重寫；結構化輸出可以包在 Markdown、也可以包在 JSON。這些差異在軟體工程角度看只是表面（cosmetic），但對 LLM 來說，寫 diff 得先算好會改幾行才能下筆，JSON 又得多處理換行跟引號的轉義——都是跟任務本身無關、卻容易出錯的額外負擔。

給模型足夠 token「思考」

格式貼近網路文本常見的樣子

消除不必要的格式 overhead

別讓模型還沒想清楚就被迫寫死答案、把自己寫進死角。

🛠️

該投入多少心力在 HCI 上，就該投入多少在 ACI 上

把自己想像成第一次拿到這個工具的人：光看描述和參數，能不能一眼看懂怎麼用？連設計者自己都要想很久，模型大概率也會卡住。實務打磨流程是：同理模型 → 改善命名與說明 → 在 workbench 裡實測觀察 → 用poka-yoke直接把犯錯的可能性設計掉。

Anthropic 打造 SWE-bench 用的 Agent 時就踩過真實的坑：模型用相對路徑工具時，一旦 Agent 移出根目錄就很容易犯錯，因為它很難時刻記住自己在哪個目錄。解法不是在提示詞裡叮嚀「請小心」，而是直接把工具改成永遠要求絕對路徑——改完之後，模型使用這個工具就變得完全正確、零失誤。

小試身手

Agent 的迴圈、實務案例、還有打磨工具的心法，來兩題檢查一下。

Agent 執行任務過程中，為什麼必須不斷從環境取得「地面真相」？

為什麼原文建議把 Agent 導入正式環境前，要先在「沙盒環境」中大量測試並搭配護欄？

🏛️

三原則收攏這一整節

簡單：別為了複雜而複雜，維持 Agent 設計的簡單性。透明：明確展示 Agent 的規劃步驟，讓人類看得懂它在想什麼。打磨 ACI：工具說明跟提示詞一樣值得被精雕細琢、測試迭代、做好防呆——這往往是決定 Agent 成敗的隱藏關鍵。

🍽️

下一站

讀完 Agent 怎麼被設計出來，下一篇文章要問一個更根本的問題——怎麼餵給 Agent「剛剛好」的情境？往下捲，進入 Context Engineering。