起點(diǎn)課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識AI 產(chǎn)品：Planner (規(guī)劃者)、Executor (執(zhí)行者) 和 Tool Handler (工具處理者)
在人工智能領(lǐng)域，尤其是智能體（Agent）架構(gòu)的設(shè)計(jì)中，如何實(shí)現(xiàn)高效的任務(wù)規(guī)劃、執(zhí)行和工具調(diào)用是一個(gè)關(guān)鍵問題。本文深入探討了智能體架構(gòu)中的三大核心組件：Planner（規(guī)劃者）、Executor（執(zhí)行者）和Tool Handler（工具處理者），并詳細(xì)分析了它們在解耦與協(xié)作機(jī)制中的作用。
Planner (規(guī)劃者)、Executor (執(zhí)行者) 和 Tool Handler (工具處理者) 這三大核心組件在 Agent 架構(gòu)中的解耦與協(xié)作機(jī)制。理解它們?nèi)绾螀f(xié)同工作，是構(gòu)建健壯、高效智能體的關(guān)鍵。
這三者就像一個(gè)高度專業(yè)化的項(xiàng)目團(tuán)隊(duì)，各司其職，又緊密配合，共同完成復(fù)雜任務(wù)。
一、Planner（規(guī)劃者）：Agent 的“大腦”和“戰(zhàn)略家”
核心職責(zé)： Planner 的主要任務(wù)是將一個(gè)復(fù)雜、高層次的用戶目標(biāo)或系統(tǒng)目標(biāo)，分解成一系列清晰、可執(zhí)行的、原子化的子任務(wù)（Steps），并確定這些子任務(wù)的邏輯順序或依賴關(guān)系。它負(fù)責(zé)“想清楚”怎么做。
如何實(shí)現(xiàn)復(fù)雜任務(wù)分解？
1）目標(biāo)理解與澄清：
Planner 首先接收用戶輸入的模糊或復(fù)雜目標(biāo)（例如：“幫我規(guī)劃一次下周去大阪的旅行，要經(jīng)濟(jì)實(shí)惠但體驗(yàn)要好，還得避開熱門景點(diǎn)”）。
它會利用其底層的 LLM 的理解能力和世界知識，對目標(biāo)進(jìn)行解析，提取關(guān)鍵實(shí)體、約束和期望。
產(chǎn)品經(jīng)理視角： 確保 Planner 的 Prompt 設(shè)計(jì)能充分引導(dǎo) LLM 進(jìn)行目標(biāo)理解，甚至可以在理解不清晰時(shí)主動向用戶提問澄清（這是優(yōu)秀 Agent 的表現(xiàn)）。
2）知識和能力匹配：
Planner 會“審視”Agent 擁有的所有可用工具（Tools），以及自身具備的內(nèi)部知識（Memory）。
它會評估：要完成這個(gè)目標(biāo)，我能用什么工具？我有哪些內(nèi)部信息？哪些工具可以處理哪些類型的子任務(wù)？
產(chǎn)品經(jīng)理視角： 清晰定義每個(gè)工具的功能描述（Tool Description）和輸入?yún)?shù)（Input Schema），這是 Planner 選擇工具的依據(jù)。工具描述越清晰，Planner 越能準(zhǔn)確匹配。
3）多步驟思考與分解（Chain-of-Thought / Tree-of-Thought）：
這是 Planner 的核心智能所在。Planner 會調(diào)用其底層的 LLM，采用 Chain-of-Thought (CoT)、Tree-of-Thought (ToT)、ReAct (Reasoning and Acting) 等推理策略。
- CoT： 簡單任務(wù)分解，一步步列出執(zhí)行步驟。
- ToT： 復(fù)雜任務(wù)分解，Planner 可能會探索多個(gè)可能的路徑，并進(jìn)行前瞻性思考，評估每個(gè)路徑的成功概率，甚至在發(fā)現(xiàn)死胡同時(shí)進(jìn)行回溯（Backtracking）。
- ReAct： Planner 可能會在思考過程中，先執(zhí)行一些初步的“觀察”行動（調(diào)用搜索工具、查詢數(shù)據(jù)庫），根據(jù)觀察結(jié)果動態(tài)調(diào)整其規(guī)劃。
產(chǎn)品經(jīng)理視角： 在設(shè)計(jì) Planner 的 Prompt 時(shí)，鼓勵(lì)其輸出思考過程（Thought: Plan: Sub-task: 等），這有助于調(diào)試和理解 Agent 行為，也有助于用戶信任。
4）生成可執(zhí)行的子任務(wù)列表：
最終，Planner 會輸出一個(gè)結(jié)構(gòu)化的計(jì)劃，通常是一個(gè)子任務(wù)列表，每個(gè)子任務(wù)都足夠具體，可以直接交給 Executor 去執(zhí)行。
每個(gè)子任務(wù)可能包含：任務(wù)描述、預(yù)期輸入、預(yù)期輸出、所需工具（或內(nèi)部操作）、依賴關(guān)系。
示例分解： “規(guī)劃大阪旅行”
- 子任務(wù)1：查詢大阪熱門景點(diǎn)及開放時(shí)間（工具：旅游信息API）
- 子任務(wù)2：查詢大阪經(jīng)濟(jì)型住宿信息（工具：酒店預(yù)訂API）
- 子任務(wù)3：查詢大阪特色美食推薦（工具：美食點(diǎn)評API）
- 子任務(wù)4：避開高峰期和熱門景點(diǎn)，生成個(gè)性化行程草案（內(nèi)部邏輯/LLM推理）
- 子任務(wù)5：評估行程草案的經(jīng)濟(jì)性和體驗(yàn)（內(nèi)部邏輯/LLM推理）
- 子任務(wù)6：提供最終推薦行程和理由（輸出）
二、Executor（執(zhí)行者）：Agent 的“手腳”和“行動者”
核心職責(zé)： Executor 接收 Planner 生成的子任務(wù)列表，負(fù)責(zé)按照規(guī)劃的順序逐一執(zhí)行這些子任務(wù)。它負(fù)責(zé)“做事情”，并將執(zhí)行結(jié)果反饋給 Planner（或 Memory）。
如何確保子任務(wù)的按序執(zhí)行和錯(cuò)誤處理？
1）任務(wù)調(diào)度與執(zhí)行：
Executor 維護(hù)一個(gè)任務(wù)隊(duì)列，按照 Planner 給出的順序（或根據(jù)依賴關(guān)系）執(zhí)行子任務(wù)。
對于每個(gè)子任務(wù)，Executor 會判斷其類型：是調(diào)用工具？是內(nèi)部邏輯（如簡單的文本處理）？還是需要輸出給用戶？
產(chǎn)品經(jīng)理視角： 設(shè)計(jì) Executor 時(shí)要考慮任務(wù)的并發(fā)性。某些子任務(wù)可以并行執(zhí)行（例如同時(shí)查詢酒店和景點(diǎn)），而另一些則有嚴(yán)格的順序依賴（必須先查詢到酒店信息才能評估行程）。
2）工具調(diào)用與結(jié)果捕獲：
如果子任務(wù)需要調(diào)用工具，Executor 會將請求參數(shù)傳遞給 Tool Handler，并等待其返回結(jié)果。
Executor 會捕獲工具調(diào)用的原始輸出，并將其轉(zhuǎn)換為可供 LLM 理解的格式（例如，將 JSON 格式的 API 響應(yīng)轉(zhuǎn)換為自然語言摘要）。
產(chǎn)品經(jīng)理視角： 確保 Tool Handler 返回的結(jié)果對 Executor 是清晰可讀的。設(shè)計(jì)工具返回的Schema，避免歧義。
3）錯(cuò)誤處理與重試機(jī)制：
這是 Executor 魯棒性的關(guān)鍵。當(dāng)子任務(wù)執(zhí)行失敗時(shí)（例如，API 調(diào)用失敗、網(wǎng)絡(luò)錯(cuò)誤、工具返回非預(yù)期結(jié)果），Executor 需要有機(jī)制來處理：
- 重試（Retry）： 針對瞬時(shí)錯(cuò)誤，可以設(shè)置重試次數(shù)和間隔。
- 錯(cuò)誤報(bào)告： 將錯(cuò)誤信息反饋給 Planner，讓 Planner 重新評估計(jì)劃或生成新的子任務(wù)。
- 回退（Fallback）： 如果某個(gè)工具調(diào)用失敗，是否可以嘗試替代工具？
- 請求人工干預(yù)（Human-in-the-Loop）： 對于無法自動解決的嚴(yán)重錯(cuò)誤，將問題拋給人類，并提供足夠的上下文。
產(chǎn)品經(jīng)理視角： 需要與研發(fā)團(tuán)隊(duì)明確錯(cuò)誤等級和處理策略。哪些錯(cuò)誤可以自動重試？哪些需要通知用戶？哪些需要人工介入？這直接影響用戶體驗(yàn)和系統(tǒng)穩(wěn)定性。
4）狀態(tài)更新與反饋：
Executor 會將每個(gè)子任務(wù)的執(zhí)行結(jié)果（成功/失敗，以及輸出內(nèi)容）更新到 Agent 的**內(nèi)存（Memory）**中，或直接反饋給 Planner。
這使得 Planner 能夠根據(jù)最新狀態(tài)進(jìn)行自我評估和調(diào)整。
產(chǎn)品經(jīng)理視角： 內(nèi)存的設(shè)計(jì)應(yīng)支持記錄詳細(xì)的執(zhí)行日志和中間結(jié)果，這對于后續(xù)的調(diào)試、優(yōu)化和可解釋性至關(guān)重要（例如，通過 LangSmith 等工具進(jìn)行可視化）。
三、Tool Handler（工具處理者）：Agent 的“橋梁”和“翻譯官”
核心職責(zé)： Tool Handler 是 Agent 與外部世界交互的“網(wǎng)關(guān)”。它負(fù)責(zé)將 Planner/Executor 的高層指令“翻譯”成特定工具（API、數(shù)據(jù)庫、內(nèi)部函數(shù)）可理解的請求，并將工具的原始響應(yīng)“翻譯”回 Agent 可理解的格式。它負(fù)責(zé)“打交道”。
如何封裝外部系統(tǒng)，讓 Agent 能夠“用”起來？
1）工具封裝與標(biāo)準(zhǔn)化：
Tool Handler 將各種復(fù)雜、異構(gòu)的外部系統(tǒng)（如第三方API、企業(yè)內(nèi)部數(shù)據(jù)庫、計(jì)算器、文件系統(tǒng)等）統(tǒng)一封裝成 Agent 可以理解和調(diào)用的標(biāo)準(zhǔn)接口。
每個(gè)工具都應(yīng)有一個(gè)清晰的名稱、功能描述，以及輸入?yún)?shù)的 Schema（例如，JSON Schema），告知 LLM 這個(gè)工具能做什么，以及需要什么輸入。
產(chǎn)品經(jīng)理視角： 設(shè)計(jì)工具時(shí)，要站在 LLM 的角度去思考：這個(gè)工具的描述是否足夠清晰？LLM 能否輕易理解它的功能和參數(shù)？工具的粒度是原子化還是更粗粒度？
2）參數(shù)映射與調(diào)用：
當(dāng) Executor 決定調(diào)用某個(gè)工具時(shí)，它會將 LLM 理解的參數(shù)（通常是自然語言中提取出的信息）傳遞給 Tool Handler。
Tool Handler 負(fù)責(zé)將這些參數(shù)映射到實(shí)際工具 API 所需的參數(shù)格式。
然后，Tool Handler 會發(fā)起實(shí)際的 API 調(diào)用（HTTP 請求、數(shù)據(jù)庫查詢、本地函數(shù)執(zhí)行等）。
產(chǎn)品經(jīng)理視角： 了解工具的速率限制、認(rèn)證方式、錯(cuò)誤代碼等，這些都會影響 Tool Handler 的健壯性和 Agent 的整體性能。
3）結(jié)果解析與轉(zhuǎn)換：
Tool Handler 接收到外部工具返回的原始響應(yīng)（通常是 JSON、XML 或數(shù)據(jù)庫記錄）。
它負(fù)責(zé)將這些原始響應(yīng)解析并轉(zhuǎn)換為對 Agent 有意義、易于 LLM 理解的格式（例如，將復(fù)雜的 JSON 響應(yīng)總結(jié)成自然語言描述或關(guān)鍵數(shù)據(jù)點(diǎn)）。
產(chǎn)品經(jīng)理視角： 結(jié)果轉(zhuǎn)換的質(zhì)量直接影響 Planner/Executor 對信息的利用。如果轉(zhuǎn)換不當(dāng)，即使工具返回了正確信息，Agent 也可能無法正確理解。
4）錯(cuò)誤和異常處理：
Tool Handler 需要處理工具調(diào)用過程中可能出現(xiàn)的各種錯(cuò)誤（網(wǎng)絡(luò)連接失敗、API 返回錯(cuò)誤碼、參數(shù)校驗(yàn)失敗等）。
它會將這些錯(cuò)誤信息以結(jié)構(gòu)化或友好的方式報(bào)告給 Executor。
產(chǎn)品經(jīng)理視角： 明確工具的錯(cuò)誤類型和錯(cuò)誤信息，以便 Executor 能據(jù)此做出正確的處理決策。
四、三者的解耦與協(xié)作機(jī)制：一個(gè)動態(tài)循環(huán)
這三者之間的關(guān)系是一個(gè)動態(tài)的、迭代的循環(huán)：
1）用戶目標(biāo) → 提交給 Planner。
2）Planner 思考、規(guī)劃 → 生成子任務(wù)列表 → 交給 Executor。
）3Executor 逐一執(zhí)行子任務(wù)：
- 如果需要外部能力 → 請求 Tool Handler 調(diào)用工具。
- Tool Handler 調(diào)用工具 → 獲取原始結(jié)果 → 解析并返回結(jié)構(gòu)化結(jié)果給 Executor。
- Executor 接收結(jié)果 → 將結(jié)果更新到記憶（Memory），或直接反饋給 Planner。
4）Planner 接收 Executor 的執(zhí)行結(jié)果（無論是成功還是失?。?，進(jìn)行自我評估/反思（Self-Reflection）：
- 如果任務(wù)完成 → 輸出最終結(jié)果。
- 如果發(fā)現(xiàn)錯(cuò)誤或進(jìn)展不順 → 重新規(guī)劃，生成新的子任務(wù)列表（可能包括調(diào)試、重試或嘗試新方法）。
- 如果需要更多信息 → 可能生成新的子任務(wù)去調(diào)用工具或查詢記憶。
這個(gè)循環(huán)會持續(xù)進(jìn)行，直到任務(wù)完成或達(dá)到預(yù)設(shè)的停止條件（例如，達(dá)到最大嘗試次數(shù)）。
產(chǎn)品經(jīng)理需要理解的是：
- 每一個(gè)環(huán)節(jié)都可能出錯(cuò)： Planner 可能規(guī)劃錯(cuò)誤，Executor 可能執(zhí)行失敗，Tool Handler 可能調(diào)用錯(cuò)誤或返回亂碼。設(shè)計(jì)時(shí)必須考慮這些點(diǎn)。
- 每一個(gè)環(huán)節(jié)都是可優(yōu)化的： 優(yōu)化 Planner 的提示詞可以提升規(guī)劃質(zhì)量；優(yōu)化 Tool Handler 的封裝可以提升工具調(diào)用效率；優(yōu)化 Executor 的錯(cuò)誤處理可以提升系統(tǒng)魯棒性。
- 解耦帶來的靈活性： 這三者的解耦使得你可以獨(dú)立地優(yōu)化或替換其中一個(gè)組件，而不會影響其他部分。例如，更換一個(gè)更強(qiáng)大的 Planner LLM，或者集成一個(gè)新的 Tool。
這種解耦與協(xié)作機(jī)制是構(gòu)建復(fù)雜、智能 AI Agent 的核心，理解它能幫助你更好地與研發(fā)和算法團(tuán)隊(duì)協(xié)作，共同推動你的“智能表單生成 Agent”等項(xiàng)目落地。
五、AI 創(chuàng)建表單機(jī)器人流程中的三者作用
1. Planner (規(guī)劃者) 的作用：理解需求，制定創(chuàng)建表單的“藍(lán)圖”
輸入： 用戶的自然語言需求：“幫我創(chuàng)建一個(gè)用戶注冊表單，需要收集姓名、郵箱、電話，以及一個(gè)密碼字段，密碼要有兩次輸入確認(rèn)，并且電話和郵箱要驗(yàn)證格式?！?/p>
核心動作：理解與分解
Planne（通常由一個(gè)強(qiáng)大的 LLM 扮演）會執(zhí)行以下思考和規(guī)劃：
1）意圖識別： 識別用戶核心意圖是“創(chuàng)建表單”，表單類型是“用戶注冊”。
2）關(guān)鍵信息抽?。?/strong> 提取表單所需的關(guān)鍵字段：姓名、郵箱、電話、密碼。
3）約束與規(guī)則識別：
- 密碼要有兩次輸入確認(rèn)：這是一個(gè)邏輯約束，意味著需要 密碼 和 確認(rèn)密碼 兩個(gè)字段，且二者需要校驗(yàn)一致性。
- 電話和郵箱要驗(yàn)證格式：這意味著這兩個(gè)字段需要對應(yīng)的校驗(yàn)規(guī)則（正則匹配或內(nèi)置驗(yàn)證）。
4）任務(wù)分解與排序： 將復(fù)雜的表單創(chuàng)建過程分解為一系列有序的、可執(zhí)行的子任務(wù)。
子任務(wù) 1：理解表單字段需求 (內(nèi)部思考)
- 識別核心字段：姓名 (文本)、郵箱 (郵箱格式)、電話 (電話格式)、密碼 (密碼類型)。
- 識別密碼確認(rèn)邏輯：添加 確認(rèn)密碼 字段。
子任務(wù) 2：規(guī)劃字段屬性與校驗(yàn)規(guī)則 (內(nèi)部思考)
- 為每個(gè)字段分配合適的輸入類型 (text, email, tel, password)。
- 為郵箱和電話字段指定格式驗(yàn)證規(guī)則。
- 指定密碼和確認(rèn)密碼的匹配規(guī)則。
子任務(wù) 3：調(diào)用工具生成表單結(jié)構(gòu) (需要工具)
根據(jù)規(guī)劃好的字段和規(guī)則，調(diào)用“表單生成工具”的 API 來創(chuàng)建表單的 JSON 或特定格式結(jié)構(gòu)。
子任務(wù) 4：檢查生成表單的邏輯和完整性 (內(nèi)部思考/可能需要工具)
- 評估生成的表單結(jié)構(gòu)是否符合所有用戶要求和邏輯規(guī)則。
- （可選，如果需要外部工具）調(diào)用“表單校驗(yàn)工具”進(jìn)行更嚴(yán)格的結(jié)構(gòu)校驗(yàn)。
子任務(wù) 5：輸出表單鏈接或可嵌入代碼 (需要工具)
- 如果表單生成成功且校驗(yàn)通過，調(diào)用“表單發(fā)布工具”生成可分享的鏈接或嵌入代碼。
- 將最終結(jié)果反饋給用戶。
輸出： 一個(gè)結(jié)構(gòu)化的執(zhí)行計(jì)劃，包含多個(gè)子任務(wù)及其依賴關(guān)系。
2. Executor (執(zhí)行者) 的作用：按計(jì)劃推進(jìn)，協(xié)調(diào)工具調(diào)用
輸入： Planner 生成的子任務(wù)列表。
核心動作：調(diào)度與執(zhí)行
Executor 會按照 Planner 的計(jì)劃，一步步執(zhí)行子任務(wù)，并與 Tool Handler 交互。
執(zhí)行子任務(wù) 1 和 2 (內(nèi)部邏輯): Executor 知道這兩個(gè)是 Planner 的內(nèi)部思考結(jié)果，不涉及外部調(diào)用，只是 Planner 的輸出。
執(zhí)行子任務(wù) 3 (調(diào)用工具):
Executor 識別到“調(diào)用工具生成表單結(jié)構(gòu)”這個(gè)任務(wù)。
它會準(zhǔn)備好調(diào)用“表單生成工具”所需的參數(shù)，例如：
JSON
{
“form_name”: “用戶注冊表單”,“fields”: [
{“name”: “姓名”, “type”: “text”},
{“name”: “郵箱”, “type”: “email”, “validation”: “email_format”},
{“name”: “電話”, “type”: “tel”, “validation”: “phone_format”},
{“name”: “密碼”, “type”: “password”},
{“name”: “確認(rèn)密碼”, “type”: “password”, “validation”: “match_password”}
]
}
然后，Executor 將這些參數(shù)傳遞給 Tool Handler，請求調(diào)用 create_form 工具。
接收工具結(jié)果與錯(cuò)誤處理：
Executor 從 Tool Handler 接收 create_form 工具的執(zhí)行結(jié)果（例如：成功生成表單的 ID 或錯(cuò)誤信息）。
- 錯(cuò)誤處理： 如果 create_form 失敗（如 API 錯(cuò)誤、參數(shù)不正確），Executor 會捕獲這個(gè)錯(cuò)誤。
- 簡單錯(cuò)誤： 嘗試重試幾次。
- 復(fù)雜錯(cuò)誤： 將錯(cuò)誤信息反饋給 Planner，讓 Planner 重新評估，可能調(diào)整生成邏輯或提供用戶友好的錯(cuò)誤提示。
執(zhí)行子任務(wù) 4 (檢查與校驗(yàn)): Executor 接收到生成表單的成功信息后，可能會觸發(fā)內(nèi)部的邏輯校驗(yàn)，或者如果 Planner 規(guī)劃了，再次調(diào)用一個(gè)“表單校驗(yàn)工具”。
執(zhí)行子任務(wù) 5 (發(fā)布工具):
- 如果校驗(yàn)通過，Executor 會準(zhǔn)備參數(shù)，調(diào)用“表單發(fā)布工具”的 API，請求生成一個(gè)可分享的鏈接。
- 接收鏈接后，Executor 將最終的鏈接信息作為結(jié)果。
輸出： 中間執(zhí)行狀態(tài)、工具調(diào)用結(jié)果，以及最終的表單鏈接。
3. Tool Handler (工具處理者) 的作用：實(shí)現(xiàn) Agent 與“表單系統(tǒng)”的交互
輸入： Executor 發(fā)出的工具調(diào)用請求（工具名稱、參數(shù)）。
核心動作：封裝與轉(zhuǎn)換
Tool Handler 負(fù)責(zé)實(shí)際與你背后的**表單生成平臺（或你的內(nèi)部表單系統(tǒng) API）**進(jìn)行交互。
1）工具定義與封裝：
你的表單系統(tǒng)會暴露一系列 API，例如：
- create_form(form_definition): 根據(jù)表單定義創(chuàng)建表單。
- validate_form_structure(form_id): 驗(yàn)證表單結(jié)構(gòu)是否有效。
- publish_form(form_id): 發(fā)布表單并返回分享鏈接。
Tool Handler 會將這些 API 封裝成 Agent 可以調(diào)用的“工具”，并定義它們的功能描述和參數(shù) Schema，供 Planner 識別和使用。
例如，定義一個(gè)名為 create_form 的工具，描述為“用于根據(jù)給定字段定義創(chuàng)建新的表單”，參數(shù)為 form_definition (JSON 對象)。
2）參數(shù)映射與實(shí)際調(diào)用：
當(dāng) Executor 請求調(diào)用 create_form 工具，并傳遞了表單定義 JSON 時(shí)：
Tool Handler 會接收這個(gè) JSON，將其作為請求體，向你的表單系統(tǒng) API POST /forms 發(fā)送一個(gè) HTTP 請求。
示例請求（HTTP POST）：
POST /api/v1/forms
Content-Type: application/json
{
“name”: “用戶注冊表單”,“elements”: [ // 假設(shè)你的表單系統(tǒng)內(nèi)部是叫elements
{“type”: “text”, “label”: “姓名”},
{“type”: “email”, “label”: “郵箱”, “validation_regex”: “^\\S+@\\S+\\.\\S+$”},
{“type”: “phone”, “label”: “電話”, “validation_regex”: “^\\d{11}$”},
{“type”: “password”, “label”: “密碼”},
{“type”: “password_confirm”, “label”: “確認(rèn)密碼”, “match_field”: “密碼”}
]
}
3）結(jié)果解析與返回：
- Tool Handler 接收到表單系統(tǒng) API 的響應(yīng)（例如，{ “form_id”: “FORM123”, “status”: “created” }）。
- 它會解析這個(gè)響應(yīng)，并將其轉(zhuǎn)換為 Agent（Executor）能夠理解的、更簡潔或結(jié)構(gòu)化的形式返回。
示例返回給 Executor：{“status”: “success”, “form_id”: “FORM123”, “message”: “表單創(chuàng)建成功”}
4）錯(cuò)誤和異常傳遞：
如果表單系統(tǒng) API 返回錯(cuò)誤（如 400 Bad Request），Tool Handler 會捕獲這些錯(cuò)誤，并將其轉(zhuǎn)換為 Executor 可以處理的異?；蝈e(cuò)誤信息，而不是直接拋出原始 API 錯(cuò)誤。
輸出： 工具執(zhí)行的成功/失敗狀態(tài)，以及相應(yīng)的返回值。
本文由 @浮云志 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自 Unsplash，基于 CC0 協(xié)議
該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
- 目前還沒評論，等你發(fā)揮！
