7. Agent 與工具調用層（Agents & Tool Use）

在前面的視覺、語言等能力層中，模型大多還是“被動回答”的形態——接收輸入、給出輸出。而在很多真實業務裡，我們需要的是一個 可以主動規劃、調用外部工具、串聯工作流的智能體（Agent） ：它不僅能看懂/讀懂/聽懂，還能自己“決定下一步做什麼”，比如去查資料、跑代碼、讀寫文件、調用內部系統，然後再把結果整合、解釋並反饋給用戶。

這一層可以被理解為“把基礎模型變成可行動系統”的關鍵粘合層：通過 結構化工具調用接口、工作流編排、多 Agent 協作以及人類在環機制 ，把 LLM 從一個強大的“認知內核”擴展為能夠完成端到端任務的“數字員工”。

7.1 工具調用與執行（Tool Calling / Function Calling）

在只讀不寫、只說不做的純文本時代，LLM 更像一個“超級對話者”：可以理解問題、給出建議、寫代碼、列方案，但所有“真正執行”的工作——查數據庫、跑腳本、生成文件、調雲服務——仍然要人工接手完成。而工具調用 / Function Calling 的出現，讓模型第一次可以在安全邊界內“動手”：根據自然語言自動生成結構化參數，去調用搜索引擎、數據庫、計算引擎、圖像/音頻/視頻生成服務等外部能力，再把執行結果整理返回，從而形成“理解 → 決策 → 執行”的閉環。

從產品角度看，工具調用是絕大多數 Agent 系統的“底盤能力”：OpenAI Assistants API、LangChain、LlamaIndex、AutoGen、各類雲廠商的 Agent 平臺，實質上都是在 LLM 之上，圍繞如何定義工具、如何讓模型正確選工具、如何處理出錯與重試搭建一層運行時。下面同樣從 場景 、原理和模型三個角度梳理這一層能力，並在後續小節中分別展開“工具調用接口設計”“工具選擇與策略”“典型工具類型”三個方向。

• 場景
  • 智能問答與檢索增強：模型根據用戶問題自動決定是否調用檢索工具（向量/關鍵詞搜索）、查企業內部知識庫或公網搜索，並將查到的文檔、FAQ 整合進最終回答。
  • 數據與報表自動化：面對“幫我查這段時間的銷售額並畫圖”“給我算一下這個投資組合的風險指標”之類請求，模型自動生成 SQL 或分析參數，調用數據庫和計算引擎，返回圖表與結論。
  • 文檔與文件操作：自動讀取 PDF/Word/Excel/數據庫表，抽取和彙總關鍵信息，或按指令生成新文件（如報表、合同、方案），並通過工具上傳/存儲到指定位置。
  • 媒體生成與處理：根據文本指令調用圖像/音頻/視頻/3D 生成服務，或對現有媒體做剪輯、壓縮、轉碼、水印等操作，形成一鍵“文案 + 設計 + 導出”的內容流水線。
• 原理 工具調用的核心是： 用自然語言驅動結構化函數調用 。
  • 首先以 JSON Schema 或函數簽名的形式，將外部工具的名稱、說明、參數結構（類型、必填項、枚舉值等）暴露給 LLM。
  • 當用戶發出請求時，LLM 不僅要理解語義，還要判斷“是否需要調用某個工具”“需要哪個（些）工具”“這些工具的參數應該怎麼填”。
  • 一旦模型決定調用某個工具，就生成一段結構化參數（通常是 JSON），由運行時去真正執行外部 API / 程序，並把執行結果以結構化形式返回給模型，讓模型基於結果繼續推理或生成最終回答。
  • 為保證安全與魯棒性，系統需要在這一過程中處理參數校驗、超時、錯誤返回、重試與回退，並對可能涉及安全/隱私的調用做權限與審計控制。
• 模型 支撐這一能力的模型與框架主要包括三類：
  • 支持 Function Calling 的 LLM：如 GPT‑4.1 / o 系列等，原生在解碼層面理解“工具簽名 + JSON Schema”，能夠在合適時機主動或被動地產生結構化調用參數。
  • 工具增強推理範式：如 ReAct、Toolformer，將“思考 + 工具調用”編織進同一推理鏈條，將工具使用視作中間步驟的一部分，而不是簡單的前/後處理。
  • 工程框架與運行時：OpenAI Assistants API、LangChain、LlamaIndex、AutoGen、各雲廠商 Agent 平臺等，為工具定義、調用路由、狀態管理、錯誤處理與日誌審計提供基礎設施，讓開發者可以聚焦在“暴露哪些工具”和“抽象怎樣的業務 API”上，而不必從零搭建運行時。

7.1.1 工具調用接口：從自然語言到結構化函數調用

一個可用的工具調用系統，首先需要一個清晰、規範、對 LLM 友好的“工具接口層”。它承擔著把外部世界的 API、腳本、服務包裝成模型可理解、可安全調用的“函數”的職責，讓模型可以像寫偽代碼一樣“說出”自己希望調用的工具及其參數。

• 工具定義與參數模式 在接口層，通常會用類似 JSON Schema 或函數簽名的結構定義每個工具：包括名稱（name）、說明（description）、參數字段（properties）、類型（string / number / boolean / array / object）、是否必填（required）、取值範圍或枚舉等。 這些信息一方面被用來驅動前端/SDK 的類型檢查，另一方面也直接提供給 LLM，幫助模型“學會”如何正確填寫參數。描述越清晰、約束越合理，模型生成的調用就越規範，出錯率越低。
• LLM 生成結構化參數 當用戶提出“幫我查 2024 年 Q3 的營收並畫一張按地區拆分的柱狀圖”這類請求時，模型需要先推理出：這至少需要一個“報表查詢工具”（訪問數據）、可能還需要一個“圖表生成工具”（畫圖）。對每個工具，它要從原始語言中抽取並映射結構化參數，如時間範圍（start_date/end_date）、維度（region）、指標（revenue）、圖表類型（bar）、輸出格式等，然後以 JSON 輸出交給運行時。 這個過程中，模型本質上在做“自然語言 → 任務規劃 → 參數抽取 / 填充”的一體化推理，因此工具描述的自然語言提示、參數示例和 few‑shot 樣例都非常關鍵。
• 工具執行與結果回傳 運行時接收到模型產出的 JSON 調用後，會先進行參數校驗與安全檢查，再去真正調用後端 API 或程序。執行完成之後，將結果封裝為結構化對象（如查詢結果表格、文件 URL、媒體資源 ID 等）返回給模型。 隨後，模型會把這些原始結果轉化為用戶可讀的解釋或進一步加工，如總結報表、生成自然語言分析、嵌入圖表標註說明等。對於模型而言，工具結果只是中間信息的一部分，它仍然要負責“理解結果 + 解釋結果”。

7.1.2 工具選擇與策略：在多工具世界裡做決策

當系統中只有一個工具時，“要不要用工具”是唯一的問題。但在現實 Agent 應用中，往往會有幾十甚至上百個工具：不同數據源的檢索、不同部門的業務 API、不同技術域的生成/分析能力，這就引出了一個新的挑戰： 模型如何在多工具環境下做合理的選擇和編排 。

• 工具選擇與路由 首先，模型需要判斷“當前請求是否需要調用工具”，以及“需要調用哪一個（或哪幾個）工具”。這通常通過在系統提示中列出可用工具的說明，並提供典型示例，讓模型學會根據用戶意圖選擇合適工具。 對於工具數量較多、描述相似度較高的場景，很多框架會引入“工具路由器”（如基於向量檢索或規則的前置篩選），先從大列表中篩出若干候選工具，再暴露給 LLM 選擇，從而降低模型負擔和誤選概率。
• 多工具順序與組合 複雜任務往往需要多個工具協同完成。例如“調研某行業主要上市公司，並生成一份包含財務對比圖表的報告”，可能涉及搜索引擎、財報數據庫、計算引擎、圖表生成工具、文檔導出工具等。 在這種情況下，模型需要做一個輕量級的任務規劃：先用哪個工具獲取列表，再對列表逐個查詢詳細信息，之後合併數據、做計算與可視化，最後調用導出工具生成報告。典型實踐包括 ReAct/Planner‑Executor 思路，讓模型在“思考（Plan）—調用（Act）—反思（Reflect）”的循環中，逐步完成工具組合調用。

7.1.3 典型工具類型：從檢索到媒體生成的能力拼圖

不同類型的工具，為 Agent 系統提供了不同維度的“外接大腦”。從工程實踐來看，以下幾類工具幾乎是所有複雜應用的“標配”。

• 檢索工具：向量與關鍵詞搜索 檢索工具負責把“記憶”擴展到外部世界：
  • 關鍵詞搜索適合結構化較好、字段清晰的傳統文檔和業務數據庫。
  • 向量搜索則通過嵌入（embedding）為非結構化文本、代碼、對話記錄、甚至多模態數據建立語義索引，支持“模糊但語義相關”的檢索。 在 RAG 場景中，LLM 通過檢索工具拉取與用戶問題相關的上下文，再在此基礎上進行推理與生成，大幅提升回答的時效性和準確性。
• 代碼執行與計算引擎 代碼執行類工具（如 Python/JS 沙箱、Notebook 執行器）讓 LLM 可以“寫一段代碼並立即跑起來”，解決複雜計算、數據處理、數值模擬、可視化等問題。 模型負責產出代碼與輸入參數，執行環境負責安全隔離、資源限制與結果收集。這類工具在數據分析、量化研究、自動化報表、科學計算以及 Agent 自我驗證（模型生成答案後用代碼校驗）等場景中非常關鍵。
• 文件與數據源訪問 文件讀寫工具負責將外部文件系統和數據源引入到 Agent 視野中：讀取 PDF/Word/Excel、訪問數據庫表、調用內部業務 API 等。模型通過這些工具獲取真實業務數據，再進行歸納、對比和報告生成。 與之配套的還有文件寫入與管理工具：將生成的報告、圖表、PPT、代碼等持久化存儲，並返回鏈接或 ID，方便用戶後續訪問與集成。
• 媒體生成與處理工具 媒體生成工具則為 Agent 增添了“創作”和“設計”的手臂：
  • 圖像/視頻生成與編輯：根據文案自動生成配圖、海報、分鏡，或對已有媒體進行裁剪、上字幕、加水印等。
  • 音頻生成與處理：TTS、配音、音樂生成、音頻增強與剪輯。
  • 3D / 工程類工具：生成簡單 3D 場景、CAD 草圖、UI 原型等。 在內容生產、營銷設計、教育培訓、遊戲與多媒體應用中，這類工具讓“從想法到成品”更接近一條自動化流水線。

綜合來看，工具調用與執行把 LLM 從“語言模型”擴展為“具備行動接口的通用控制器”：模型通過語言理解需求與環境，通過工具執行真實操作，通過反饋不斷修正策略。搭配合適的工作流編排與多 Agent 協作（見 7.2），就構成了新一代智能應用的基礎架構。

7.2 工作流編排與多 Agent 協作（Workflow & Orchestration）

有了工具調用能力，LLM 不再只是一個“回答問題的人”，而可以成為面向具體任務的“執行單元”。但現實業務往往遠比單次對話複雜：一個完整的訴訟分析、一次市場調研、一輪 A/B 實驗配置、一次端到端運維處理流程，通常都需要多步操作、多種工具、甚至多方角色長期參與。這時，單一 LLM + 工具的模式就顯得吃力，需要進一步的 工作流編排與多 Agent 協作 。

從系統視角看，這一層的職責是： 把一個複雜的、多步驟、多參與方的業務流程，抽象成可被 LLM 理解與操控的工作流圖 ，然後在這個圖上調度一個或多個 Agent，配合人類干預，共同完成任務。典型實現包括 Planner‑Executor 型 Agent 架構、具備反思 / 自我修正能力的 Agent、以及基於圖結構的 Workflow Orchestrator；相應的產品形態則是各類自動報告生成與運營自動化平臺、低代碼工作流 + LLM 集成、複雜業務流程機器人、自動運維繫統等。

• 場景
  • 報告與內容流水線：從“接收需求 → 檢索與數據拉取 → 分析和可視化 → 撰寫報告 → 審核修改 → 導出與分發”，將多步內容生產流程自動化或半自動化。
  • 業務流程自動化：如電商運營中的“商品分析 → 競品監控 → 活動策略生成 → 落地配置”，運維場景中的“監控告警 → 根因分析 → 緩解措施執行 → 覆盤報告”等。
  • 跨角色協作：讓不同領域 Agent（法律、財務、技術、運營）圍繞一個複雜項目協同工作，例如併購盡調、投融資材料準備、大型項目標書編制。
• 原理 工作流與多 Agent 協作的核心，是在 LLM 之上再加一層 結構化控制與狀態管理 ：
  • 將複雜任務拆分為若干有依賴關係的子任務，用 DAG / 狀態機 / 有向圖等結構表示，併為每個節點配置觸發條件、輸入輸出和所需 Agent/工具。
  • 由 Planner 型 Agent 或上層 orchestrator 決定何時觸發哪個節點、用哪個 Agent 或工具，並根據執行結果動態調整後續路徑（條件分支、循環、錯誤回退）。
  • 在關鍵環節引入人類在環（Human‑in‑the‑loop），對高風險決策和關鍵輸出進行人工確認與編輯，並將人類反饋迴流到系統，用於更新策略或微調模型。
• 模型 支撐這一層的主要技術方向包括：
  • Planner‑Executor 型 Agent 架構：由一個“規劃 Agent”負責任務分解與路徑設計，一個或多個“執行 Agent”負責具體步驟的落地實施。
  • 反思 / 自我修正 Agent：在執行過程中不斷回顧自己的表現，對不合理的中間結果進行反思和修正，減少“自信錯誤”的靜默擴散。
  • Graph‑based Workflow Orchestrator：將整個任務流程建模為圖結構，引入節點狀態、邊條件、並行/串行控制等機制，使 LLM 調用變成圖中的一個或多個節點，而不是唯一的控制中心。

7.2.1 任務分解與規劃：從“一句話需求”到可執行流程

用戶給 Agent 的通常是一句高度壓縮的自然語言需求，例如“幫我做一個關於新能源車行業的市場調研並輸出 PPT”，背後實際包含了檢索、篩選、分析、可視化、排版、多輪修改等大量步驟。如何從這句話出發，自動構建一條清晰、可執行的工作流，是工作流編排的第一步。

• 從自然語言到子任務圖 Planner 型 Agent 首先需要把需求“展開”：結合內置模板、歷史案例、以及工具清單，識別出關鍵階段（如信息收集、數據分析、結構設計、內容撰寫、審校與導出），並進一步細化為可執行子任務（如“檢索 5 篇近一年權威行業報告”“拉取近 3 年銷量數據並按車型細分”“生成 3 張對比圖表”等）。 這些子任務之間的依賴關係和調度邏輯，會被顯式表示為一張圖或一個狀態機：哪些可以並行、哪些必須順序執行、在哪些節點需要人工確認、在什麼條件下需要回退或重試。
• 條件分支、循環與異常路徑 真實流程往往並不是線性流水線，而是包含 條件分支 （如“如果檢索不到足夠高質量報告則換關鍵詞或換數據源”）、 循環 （如“持續嘗試改寫和壓縮，直到報告長度滿足限制”）和 異常路徑 （如“某個數據源不可達時，切換到備選源或採用估算方法”）。 這要求工作流編排層能夠在圖結構上表達 if/else、while/for、try/catch 等控制流語義，並允許 Planner Agent 或上層 orchestrator 在運行過程中根據實時結果做決策，而不僅僅在開始時一次性規劃好所有步驟。
• 與工具調用的銜接 任務分解與規劃與 7.1 中的工具調用是緊密相連的：Planner 在生成子任務時，往往會同時指定“該任務需要用到哪些工具/Agent”和“該節點的輸入輸出格式”，為後續自動參數填充和工具執行打基礎。 一些系統會採用“Plan + Execute”顯式兩階段：先由 Planner 輸出一個機器可讀的計劃（如 JSON 工作流描述），再由 Executor 嚴格按計劃調用工具與 Agent；也有系統採用 ReAct 風格，將“思考–工具調用–觀察–再思考”編織在同一對話中，以獲得更靈活的自適應執行。

7.2.2 多 Agent 協作：讓“虛擬團隊”各司其職

單個大模型固然強大，但在複雜業務場景中，不同領域往往需要不同的知識結構、風格偏好和安全策略。多 Agent 協作的思路，是把一個“大而全”的智能拆解為多個“專而精”的角色：有人負責規劃，有人負責執行，有人負責審校，有人負責領域專業判斷，形成一個由 Agent + 工具 + 人類共同組成的虛擬團隊。

• 角色分工：規劃、執行與審校 在一個典型的多 Agent 流程中，常見角色包括：
  • 規劃 Agent：負責理解用戶需求、設計整體計劃、拆分子任務，並在執行過程中根據結果動態調整路徑。
  • 執行 Agent：圍繞某些工具或子領域進行深度優化（如檢索 Agent、數據分析 Agent、內容撰寫 Agent），按規劃要求完成具體步驟。
  • 審校 Agent：從結構性、邏輯性、風格一致性和風險控制等角度，對中間和最終產出進行檢查和修訂，類似“虛擬編輯/Reviewer”。
• 領域專家 Agent 協同 對於法律、金融、技術、運營等專業性極強的領域，可以進一步細分出領域專家 Agent：如“法律顧問 Agent”“投研分析 Agent”“雲原生運維 Agent”“廣告投放優化 Agent”等。 它們可以基於領域專用知識庫、工具、甚至專門微調模型，參與項目式協作：例如在一份投融資材料中，由技術 Agent 負責技術可行性部分，財務 Agent 負責財務模型與估值，法律 Agent 負責合規與風險披露，運營 Agent 負責市場與增長策略，再由總控 Agent 彙總和統一風格。
• 協作協議與消息路由 多 Agent 協作的關鍵，還在於“誰在什麼時候跟誰說話”。系統需要一個消息路由與協調機制：
  • 決定某條用戶請求或中間結果應當被哪個 Agent 處理。
  • 維護共享上下文與各自的私有記憶。
  • 控制並行與串行執行，以及衝突解決（如不同 Agent 提出相互矛盾的建議時如何仲裁）。 這類能力通常由上層 orchestrator 或“管理 Agent”提供，而 LangChain、AutoGen 等框架則在工程層面提供了對話路由、多 Agent 會話、角色設定等基礎設施。

7.2.3 人類在環（Human‑in‑the‑loop）：把風險關口握在手裡

即便工作流與多 Agent 協作再智能，真實業務中仍然無法完全脫離人類判斷，尤其在高風險、高成本、高敏感度的場景下，如法律合規、金融決策、醫療建議、大規模生產變更、輿情響應等。人類在環（Human‑in‑the‑loop） 的設計，正是要在自動化與可控性之間找到平衡：該自動的自動，該人工確認的一定要停下來讓人看一眼。

• 關鍵步驟人工確認 在工作流圖中，通常會顯式標記若干“人工審批/確認節點”：
  • 例如在自動生成合同時，在簽發前需要法務和業務負責人雙重確認；
  • 在自動運維繫統中，對涉及生產環境變更、批量重啟、配置修改的操作，必須有值班工程師點擊確認；
  • 在內容生成場景中，對大量公開發布或品牌敏感的內容，需要人工審稿。 Orchestrator 會在這些節點暫停自動執行，將中間結果發送給對應人類角色，並在收到反饋後再繼續後續流程。
• 反饋驅動的策略更新 人類不僅在某一時刻“按下通過或駁回”，更重要的是反饋的內容可以被系統吸收：
  • 將人工修改後的版本與原始輸出對比，作為“正負樣例”記錄下來，用於後續的提示優化或模型微調。
  • 基於統計分析，識別出哪些類型的任務/步驟最容易被人工反覆修改，進而優化對應 Agent 的提示詞、工具組合或工作流設計。
  • 在極端或異常案例中，人工可以添加“黑名單 / 白名單 / 特殊規則”，直接影響系統在類似情況中的策略選擇。
• 風險分級與可觀測性 最後，人類在環還需要一套清晰的風險分級和可觀測性機制：
  • 根據任務類型、影響面、金額規模、涉及的敏感信息等維度，將流程分為不同風險等級，對應不同強度的人類介入（如只讀審閱、強制審批、多級審批）。
  • 通過日誌、審計、可視化看板等方式，讓運營/管理人員能夠隨時追蹤哪些任務在跑、跑到哪一步了、哪些地方觸發了人工介入、歷史上出現過哪些失敗與人工修正。 這些能力不僅提高了系統在企業內的可接受度，也為後續的合規審查和責任劃分提供了基礎。

綜合來看，工具調用與執行（7.1）解決的是“單步行動”的問題，而工作流編排與多 Agent 協作（7.2）則試圖回答“如何把很多步串起來，讓不同角色長期協作並可控運行”。兩者疊加，再加上人類在環與良好的工程實踐，構成了面向真實業務場景的新一代智能應用底座。