上一篇討論的是系統結構：哪些步驟由程序提前組織，哪些行動交給模型根據反饋決定。這一篇把視角放到 Agent 內部，看看它怎樣從理解請求走到實際執行，又怎樣與其他 Agent 協作。
結合 OpenAI 的 《A practical guide to building agents》，本文從三個層次展開：
- 組成與執行： Model、Tools、Instructions 各自負責什麼，怎樣配合完成一次單 Agent 的執行。
- 協作方式： 什麼時候需要拆分為多個 Agent，Manager 與 Handoff 分別怎樣委派工作和轉交處理權。
- 行動邊界： Guardrails 怎樣約束操作，哪些情況需要 Human Intervention（人工介入）。
下面用一個假設的訂單售後場景貫穿全文：用户説“包裹一直沒到，幫我看看能不能退款”。沿着這條請求，逐步説明這三層關係。
一、一個 Agent 怎樣完成任務h2
OpenAI 將 Agent 的基本組成歸為 Model、Tools 和 Instructions。可以分別理解為：負責判斷的模型、連接外部系統的工具，以及指導處理過程的指令。
這三個組成不能互相替代。模型能夠理解“我想退款”，不代表它知道這筆訂單的真實狀態；能查詢訂單，也不代表它有權修改訂單；有了修改工具，仍然需要知道什麼情況下應該使用。
1. Model：依據當前信息，決定下一步h3
面對售後請求，模型首先要處理的是判斷問題：用户是在詢問物流，還是已經明確要求退款？現有信息足夠嗎？應該先問訂單號，還是可以查詢當前賬號的訂單？
這些判斷會影響後面的工具調用。如果訂單還在運輸途中，接下來可能需要查物流；如果已經退回倉庫，就要結合售後規則判斷下一步。模型的作用不只是組織回答，而是把當前信息轉化為下一步行動。
因此，評價模型是否適合這個任務，不能只看它回答得是否流暢。還要看它能否識別缺失信息、選對工具，並根據工具結果調整判斷。例如，查詢返回“未找到訂單”時，是否會請求核實訂單號，而不是繼續編出一個物流狀態。
模型能力、延遲與成本也需要放在具體任務中看。OpenAI 建議先用能力較強的模型建立效果基線，再嘗試用較小模型承擔能夠勝任的部分。這樣才能區分：問題出在模型能力，還是工具和指令本身沒有設計清楚。
2. Tools：讓判斷連接真實信息和操作h3
模型可以根據用户的話提出退款建議，但訂單狀態、物流記錄和退款結果，都需要從外部系統獲取。Tools 承擔的就是這層連接。
在這個例子裏，可以按用途理解幾類能力：
| 工具用途 | 假設的工具 | 提供什麼能力 |
|---|---|---|
| Data：讀取信息 | get_order、get_delivery_status | 獲取訂單和物流狀態 |
| Action：執行操作 | submit_refund_request | 向售後系統提交申請 |
| Orchestration：委派工作 | 調用專門的物流 Agent | 讓另一個 Agent 完成一部分任務 |
最後一類也是後面 Manager 模式的連接點：對調用者來説，另一個 Agent 可以表現為一個工具；區別在於，這個工具內部也會進行判斷和執行。
工具定義是否清楚，會直接影響模型能否正確使用它。假設同時存在 refund_order 和 submit_refund_request，但沒有解釋兩者的差別，模型就可能把“提交申請”誤當成“直接完成退款”。
更清楚的定義應該交代：什麼時候用、需要哪些參數、會產生什麼效果，以及結果代表什麼。例如，submit_refund_request 返回申請編號，只能説明申請已經受理，不能據此回覆“退款已經到賬”。
這也説明，調用成功和業務完成是兩回事。工具不僅要能被調用，還要讓返回結果足以支持下一步判斷。
3. Instructions：把處理規則寫成可執行的指導h3
“你是一名專業的售後助手”只規定了角色，沒有解釋售後請求應該怎樣處理。真正影響執行的是更具體的規則：需要先查什麼，缺少信息怎麼辦，哪些條件下可以繼續，哪些情況必須停止。
例如，可以把這個場景的指導寫成：
- 缺少訂單信息時，先請求用户補充，不猜測訂單。
- 查詢訂單及物流狀態，依據返回的信息説明當前情況。
- 按現行售後政策判斷可用的處理方式，不自行承諾例外。
- 提交申請前確認用户意圖；需要人工批准的操作先暫停。
- 根據工具返回的實際狀態答覆，區分申請受理、退款處理中和退款完成。
這幾條分別説明了信息缺失、正常處理、業務條件、操作邊界和結果表達。它們比單純要求“認真負責、準確回答”更容易落實到具體行動。
已有的業務政策、操作文檔和客服流程，可以成為指令的基礎，但不能只是整段塞進上下文。整理時需要把條件和動作對應起來：遇到什麼情況，應該做什麼；不能繼續時，又該怎樣處理。
不過，指令仍然是在指導模型。把“不要操作其他人的訂單”寫進 Prompt，不等於完成了訂單訪問控制。真正的權限校驗，需要由工具和業務系統落實。這一點會在第三部分繼續串起來。
4. Single-Agent：三種組成怎樣協同執行h3
有了模型、工具和指令，接下來要解決的是執行怎樣持續推進，也就是 Orchestration（編排）。它不是與前三者並列的第四種基礎組件，而是把這些能力組織起來的方式。
單 Agent 可以連續進行多次判斷和工具調用，並不等於“一次模型調用”。對於這條售後請求，一段執行可能是：
識別用户意圖 → 查詢訂單 → 讀取物流結果 → 判斷可用的處理方式 → 答覆用户或請求確認
如果用户沒有提供訂單號，就先等待補充；如果查詢失敗，就依據失敗信息決定是否重試。下一步依據當前狀態決定，不要求每一條請求都完整走過同樣的步驟。
這裏還有一個容易忽略的區別：模型決定下一步做什麼，運行程序負責真正執行工具、記錄結果並控制是否繼續。 最大輪次、調用失敗和等待用户輸入等退出條件，不能只靠模型自由發揮。
所以，單 Agent 已經可以包含完整的判斷與執行過程。新增一項查詢能力，首先可以考慮增加定義清楚的工具，而不是立即增加一個 Agent。
二、多個 Agent 怎樣協作h2
5. 什麼時候單 Agent 需要拆分？h3
OpenAI 的建議是先充分發揮單 Agent 的能力，再考慮 Multi-Agent。這個順序很重要：拆分應該解決已經出現的職責複雜度，而不是為了讓架構看起來更完整。
可以從兩個具體問題判斷。
第一，處理規則是否已經難以集中表達。 如果同一個 Agent 同時承擔物流查詢、退款爭議和商家申訴，大量條件分支混在一起，不同任務的指令就可能互相干擾。可以先整理共用規則，把變化的政策抽成模板參數；這些方式仍然難以管理時，再按職責拆分。
第二，工具之間是否持續發生混淆。 關鍵不只是數量，而是名稱、用途和參數有沒有明顯重疊。先改進工具定義；如果模型仍然頻繁把某一領域的工具用於另一領域，就可以讓不同 Agent 只接觸各自需要的工具。
拆分後的價值，應該能夠説清楚：哪個 Agent 負責什麼，它需要哪些信息，向誰交付什麼結果。如果這些問題沒有答案，只是把原來的一大段 Prompt 分成幾段，複雜度未必真的下降。
而且，職責分開也會帶來新的工作：上下文如何傳遞、結果怎樣彙總、失敗由誰處理。Multi-Agent 是重新分配職責，同時也重新分配了協調成本。
6. Manager：委派工作，再接回結果h3
假設一個售後請求需要綜合物流情況和退款規則，但最終仍希望由同一個負責人向用户解釋。可以讓一個 Manager Agent 委派具體工作，再讀取結果、繼續判斷。
例如，Manager 調用物流 Agent，獲得包裹狀態；必要時再調用售後規則 Agent，獲得可用方案。隨後由 Manager 綜合這些信息，決定是解釋物流、請求確認，還是提出需要批准的操作。
被調用的 Agent 完成的是一項委派工作，結果會返回 Manager。 Manager 仍然負責整體處理，不是把用户交出去後就退出。
這就是 agents as tools 的含義。專門 Agent 內部可以調用自己的工具、進行多步處理，但對 Manager 暴露的是一項可調用的能力。
這種結構適合需要統一組織結果的任務。相應地，Manager 也必須正確理解子任務的返回結果：物流 Agent 説“信息不足”，不能被彙總成“包裹已丟失”；規則 Agent 説“滿足申請條件”，也不等於退款已經執行。
7. Handoff：把後續處理交給接手者h3
另一種情況是，入口 Agent 只負責識別請求類型。確認這是訂單售後問題後，後面的追問、查詢和答覆，都可以由售後 Agent 獨立完成。
這時使用 Handoff（交接） 更貼切：接待 Agent 轉交相關上下文與執行控制，由接手者繼續處理。
它與 Manager 的區別不在於有沒有分類，也不在於用了幾個 Agent，而在於：專門 Agent 是返回一份結果，還是接過後續處理權。
Handoff 本身不隱含“做完再回來”。如果售後 Agent 處理過程中發現需要轉回接待 Agent，應該明確設計另一次交接，而不是把它當作普通函數返回。
把兩種關係放在一起，可以這樣對照：
| 對比項 | Manager | Handoff |
|---|---|---|
| 專門 Agent 的職責 | 完成委派工作並返回結果 | 接手後續處理 |
| 誰繼續組織任務 | Manager | 接手的 Agent |
| 誰面向用户 | 通常由 Manager 統一答覆 | 接手者可以繼續與用户交互 |
| 適合的情況 | 需要綜合多份結果、保留統一負責人 | 某項職責可以交給專門角色獨立推進 |
同一套系統也可以組合兩種模式。接待 Agent 先把請求交給售後 Agent；售後 Agent 再以 Manager 的方式調用物流查詢能力。要看清的是每一次調用和交接的含義，不是給整個系統貼一個固定標籤。
三、Agent 的行動邊界怎樣確定h2
8. Guardrails：提出操作，不等於獲准執行h3
前兩部分解決了怎樣判斷、怎樣執行和怎樣分工，但還有一個獨立問題：模型提出的操作，是否可以真正執行？
同樣是工具調用，查詢物流與修改收款賬户的風險顯然不同。即使模型認為“這樣能夠滿足用户要求”，系統也需要檢查它是否有權這麼做、是否符合業務規則，以及是否需要額外批准。
我更願意沿着一次處理過程理解 Guardrails（防護約束）：
- 接收請求時： 識別越界請求或試圖改變系統行為的惡意指令。
- 執行操作前： 檢查身份、資源訪問權限、業務條件，以及必要的批准。
- 生成答覆時： 檢查敏感信息和實際結果，避免泄露他人數據或錯誤宣稱操作已完成。
這是從執行過程組織檢查的位置，不意味着只需設置三道固定關卡。不同風險可能分別由程序規則、內容檢查或模型判斷處理；它們也不能替代業務系統原有的身份認證和權限控制。
例如，指令可以要求“只處理當前用户的訂單”，但查詢工具仍應驗證訂單歸屬。否則，一旦模型傳入別人的訂單號，單靠一句指令就無法阻止數據被讀出。
類似地，涉及資金的操作如果要求人工批准，就必須先取得批准，再執行工具。事後檢測到違規，不能撤銷已經發生的所有影響。 有些普通檢查可以並行進行，但不應把這種做法直接套到必須先獲准的高風險操作上。
9. Human Intervention：知道什麼時候交給人h3
人工介入不只是“模型答錯以後找人補救”。它也可以是正常處理過程中的明確安排：有些事情允許 Agent 準備信息和提出建議，但最後的決定必須由人作出。
第一類情況是無法繼續可靠推進。例如訂單系統連續查詢失敗，或者反覆確認仍無法識別用户要處理哪一筆訂單。繼續重試不一定增加有效信息，反而可能消耗時間或產生重複操作。系統需要設置嘗試上限，達到條件後停止並轉交。
第二類情況是操作風險本身要求人工決定。例如存在爭議的退款或不可逆操作，即使模型已經給出清楚的理由，也不代表可以省略必要的批准。
交給人時，真正有用的不是一句“處理失敗”，而是一份能夠接着往下工作的説明：用户想解決什麼、已經查到什麼、嘗試過哪些操作、卡在哪裏，以及需要人決定哪件事。
這也與前面的 Handoff 不同。Handoff 是 Agent 之間轉交執行；人工介入是把特定決定或後續處理交給人。兩者都涉及控制權變化，但接手者的責任和可執行權限並不相同。
把組成、協作與邊界連起來h2
從這條售後請求回看整套結構，Model 依據當前信息判斷下一步，Tools 連接訂單與物流系統，Instructions 説明處理規則。單 Agent 可以把它們組織成完整執行；職責複雜到需要拆分時，再明確是由 Manager 接回結果，還是通過 Handoff 交出處理權。
而無論由哪個 Agent 處理，提出一個操作都不等於獲得執行許可。權限校驗、防護檢查與人工批准，需要約束真正發生的行動。
理解一個 Agent，既要看它如何作出決定，也要看決定如何被執行、由誰繼續負責，以及什麼情況下必須停下來。 這幾層關係清楚了，組件和編排方式才能對應到具體任務，而不只是停留在架構圖裏的名稱。
幾個關鍵問題，串起組成、協作與邊界h2
沿着前面的售後場景，可以把這些關係歸納成幾個問題。
模型已經能理解用户意圖，為什麼還需要 Tools 和 Instructions？
理解“我想退款”，不等於知道訂單狀態，也不等於知道這筆訂單適用什麼規則。Model 負責依據已有信息判斷，Tools 提供實際信息和操作能力，Instructions 説明處理目標與規則。三者解決的是不同問題：換一個更強的模型，不能替代缺失的訂單接口；增加退款工具，也不能替代清楚的處理規則。
模型決定下一步，為什麼還需要程序控制執行？
模型可以提出“查詢物流”或“提交退款申請”，但真正調用工具、接收結果、保存狀態和限制重試次數，仍需要運行程序完成。這裏要區分行動決策和執行控制：模型決定想做什麼，程序控制這個動作如何發生、是否允許發生，以及執行何時暫停或結束。Orchestration 組織的正是這些關係，而不是與 Model、Tools、Instructions 並列的第四種基礎組件。
一個 Agent 的工具越來越多，就應該拆成多個 Agent 嗎？
工具多隻是現象，要看它是否造成持續的職責衝突或選擇混淆。如果工具定義清楚、處理規則一致，單 Agent 仍然可以完成多步任務；如果不同領域需要不同規則、工具和權限，拆分才可能讓職責更清晰。判斷拆分是否有價值，不只看子 Agent 是否更專注，還要看增加的上下文傳遞、結果彙總和失敗處理成本是否值得。
同樣是找另一個 Agent 幫忙，Manager 和 Handoff 到底差在哪裏？
看交出去的是一項工作，還是後續處理權。Manager 請物流 Agent 查包裹，拿到結果後仍由自己繼續處理和答覆；Handoff 則把請求交給售後 Agent，由接手者繼續追問、查詢和回應。前者返回的是子任務結果，後者改變的是當前負責人。Handoff 不隱含自動返回，如果還要交回原 Agent，需要明確安排另一次交接。
Instructions 已經寫了“不能越權”，為什麼還要做執行前檢查？
指令是在指導模型的判斷，權限校驗是在限制系統實際能執行的操作。即使模型傳入了別人的訂單號，工具也應該拒絕讀取，而不是依賴模型記住一句“只處理當前用户的訂單”。同樣，需要批准的退款必須在調用工具前暫停。描述一條規則，與在操作發生的位置執行這條規則，是兩回事。 Guardrails 需要與身份認證、權限控制配合，不能替代它們。
轉交另一個 Agent、繼續重試和交給人工，分別解決什麼問題？
轉交 Agent 解決的是職責歸屬，例如把售後請求交給專門角色；重試適合預期能夠恢復的臨時失敗，但必須有次數或時間上限；人工介入則用於需要人作出決定，或系統已無法可靠推進的情況。訂單查詢暫時超時，可以有限重試；達到上限後，應交代已有信息和失敗位置；退款需要人工批准時，則應直接等待批准，不能靠重試或換一個 Agent 繞過去。