本章關(guān)鍵詞AI Agent、Tool Calling、Function Calling、Tools、Planning、Memory、Workflow、RAG、ERP、CRM、WMS、API、權(quán)限、安全一、RAG之后為什么還需要Agent上一篇我們完成了一個企業(yè)RAG知識庫它可以解決一個非常重要的問題讓AI能夠理解企業(yè)知識。例如用戶問WMS系統(tǒng)中庫存盤點出現(xiàn)差異應(yīng)該怎么處理RAG可以檢索《庫存盤點管理制度》 《盤點異常處理SOP》 《庫存調(diào)整管理規(guī)范》然后讓LLM生成答案。但是企業(yè)員工接下來很可能會問“幫我查詢一下SKU-10086現(xiàn)在有多少庫存?！边@時候RAG就不夠了。因為知識庫中的庫存數(shù)據(jù)可能不是實時數(shù)據(jù)。真正需要的是用戶 ↓ AI Agent ↓ 調(diào)用WMS API ↓ 查詢實時庫存 ↓ 返回結(jié)果進(jìn)一步用戶可能說“幫我把SKU-10086的庫存調(diào)整100件?！边@就不再是回答問題。而是執(zhí)行任務(wù)。這正是Agent解決的問題。二、什么是AI AgentAI Agent可以簡單理解為能夠理解目標(biāo)、決定下一步行動、調(diào)用工具、觀察結(jié)果并持續(xù)執(zhí)行直到完成任務(wù)的AI系統(tǒng)。普通Chatbot用戶 ↓ LLM ↓ 答案RAG Chatbot用戶 ↓ LLM ↓ RAG ↓ 企業(yè)知識 ↓ 答案AI Agent所以可以簡單理解LLM 大腦 RAG 知識 Tool 手 Agent 能夠使用大腦、知識和工具完成任務(wù)的執(zhí)行者三、Chatbot、RAG和Agent有什么區(qū)別這是FDE必須理解的一個核心問題。類型核心能力能否訪問企業(yè)知識能否調(diào)用系統(tǒng)能否執(zhí)行任務(wù)Chatbot對話???RAG知識問答?通常??Tool Calling工具調(diào)用可選?部分Agent自主執(zhí)行???Workflow流程執(zhí)行可選??可以把它理解成一個逐步升級過程Chatbot ↓ RAG ↓ Tool Calling ↓ Agent ↓ Workflow ↓ 企業(yè)AI應(yīng)用四、Agent最重要的能力Tool CallingAgent之所以能夠執(zhí)行任務(wù)關(guān)鍵原因之一就是Tool Calling。例如我們給AI提供一個工具get_inventory(sku)工具說明名稱 get_inventory 功能 查詢SKU實時庫存 參數(shù) sku 返回 庫存數(shù)量用戶查詢SKU-10086的庫存。LLM判斷這個問題需要實時庫存數(shù)據(jù) ↓ 調(diào)用get_inventory生成{ tool: get_inventory, arguments: { sku: SKU-10086 } }系統(tǒng)執(zhí)行g(shù)et_inventory(SKU-10086)WMS返回{ sku: SKU-10086, available: 1250, locked: 100 }然后結(jié)果重新交給LLMTool Result ↓ LLM ↓ 自然語言答案最終SKU-10086當(dāng)前庫存 可用庫存1250件 鎖定庫存100件這就是Tool Calling。五、Function Calling和Tool Calling是什么關(guān)系在不同AI平臺和框架中經(jīng)常會看到Function Calling Tool Calling兩者在實際應(yīng)用中高度相關(guān)。核心思想都是讓模型輸出結(jié)構(gòu)化的工具調(diào)用請求由程序真正執(zhí)行工具。例如LLM ↓ 決定調(diào)用工具 ↓ 輸出結(jié)構(gòu)化參數(shù) ↓ Application ↓ 執(zhí)行函數(shù)/API ↓ 返回結(jié)果 ↓ LLM需要注意一個關(guān)鍵點LLM本身通常并不是直接操作企業(yè)數(shù)據(jù)庫。而是LLM ↓ 提出工具調(diào)用 ↓ 應(yīng)用程序 ↓ 權(quán)限校驗 ↓ 真正執(zhí)行API這對于企業(yè)安全非常重要。六、Tool到底是什么Tool本質(zhì)上就是AI可以調(diào)用的一個能力接口。例如WMS查詢庫存 查詢訂單 查詢庫位 查詢SKU 創(chuàng)建入庫單 創(chuàng)建出庫單 創(chuàng)建盤點任務(wù)ERP查詢采購訂單 查詢銷售訂單 查詢供應(yīng)商 查詢物料 創(chuàng)建采購申請CRM查詢客戶 查詢聯(lián)系人 查詢商機(jī) 創(chuàng)建跟進(jìn)記錄 查詢銷售機(jī)會甚至可以是天氣API 地圖API 郵件 Excel 數(shù)據(jù)庫 搜索引擎 企業(yè)內(nèi)部API因此Tool AI可以調(diào)用的外部能力七、Tool設(shè)計是Agent項目的核心工作很多人做Agent時把注意力全部放在LLM上。實際上企業(yè)Agent能否穩(wěn)定運行很大程度上取決于Tool設(shè)計。一個好的Tool應(yīng)該職責(zé)單一 參數(shù)清晰 返回結(jié)構(gòu)化 權(quán)限明確 錯誤可控 可審計 可重試?yán)绮灰O(shè)計do_wms_everything()而應(yīng)該拆成get_inventory() get_order() get_location() create_count_task() create_outbound_order()這樣Agent更容易正確選擇。八、一個標(biāo)準(zhǔn)Tool定義例如{ name: get_inventory, description: 查詢指定SKU在指定倉庫中的實時庫存, parameters: { type: object, properties: { warehouse_code: { type: string }, sku: { type: string } }, required: [ warehouse_code, sku ] } }這里包含三個重要部分Tool Name Tool Description Tool Parameters尤其是Description非常重要。因為Agent需要根據(jù)工具描述判斷“什么時候應(yīng)該使用這個工具”九、Agent的基本運行循環(huán)一個簡單Agent可以抽象成這就是Agent的基本循環(huán)。十、Think → Act → Observe很多Agent架構(gòu)可以抽象成例如用戶“幫我找出庫存低于安全庫存的SKU并創(chuàng)建補貨申請?！盇gent可能需要這就是Agent與普通Chatbot最大的區(qū)別。十一、Agent RAGAgent并不意味著RAG消失了。恰恰相反Agent RAG是企業(yè)AI非常重要的組合。例如例如用戶 “按照公司的庫存管理制度 幫我檢查一下SKU-10086是否需要補貨?！盇gent需要第一步通過RAG查詢庫存管理制度 安全庫存規(guī)則 補貨規(guī)則第二步通過Tool查詢SKU-10086實時庫存第三步綜合判斷當(dāng)前庫存 安全庫存規(guī)則 補貨策略第四步返回SKU-10086當(dāng)前庫存低于安全庫存 建議創(chuàng)建補貨申請。這就是真正的知識 數(shù)據(jù) 推理。十二、Agent WMS對于FDE來說WMS是非常適合Agent落地的場景?？梢栽O(shè)計Tools可以包括查詢庫存 查詢訂單 查詢庫位 查詢SKU 查詢批次 查詢庫存狀態(tài) 創(chuàng)建盤點任務(wù) 創(chuàng)建補貨任務(wù)十三、一個完整的WMS Agent案例用戶“幫我檢查一下A倉庫庫存不足的商品?！盇gent① 查詢A倉庫庫存 ↓ ② 查詢安全庫存規(guī)則 ↓ ③ 計算庫存差異 ↓ ④ 找出低于安全庫存SKU ↓ ⑤ 生成結(jié)果例如SKU 當(dāng)前庫存 安全庫存 -------------------------------- SKU001 80 100 SKU002 30 50 SKU003 500 100Agent判斷SKU001 → 需要補貨 SKU002 → 需要補貨 SKU003 → 正常然后用戶繼續(xù)“那就幫我創(chuàng)建補貨任務(wù)。”Agent用戶確認(rèn) ↓ 權(quán)限檢查 ↓ 創(chuàng)建補貨任務(wù)Tool ↓ WMS API ↓ 返回任務(wù)號 ↓ AI反饋最終已創(chuàng)建2個補貨任務(wù) SKU001 → 補貨任務(wù) RT20260905001 SKU002 → 補貨任務(wù) RT20260905002這已經(jīng)不是簡單的AI問答。而是AI參與真實業(yè)務(wù)流程。十四、Agent ERPERP同樣可以提供大量Tools。例如采購訂單查詢 銷售訂單查詢 供應(yīng)商查詢 物料查詢 庫存查詢 財務(wù)數(shù)據(jù)查詢 采購申請創(chuàng)建例如用戶“幫我查詢最近30天采購金額最高的10家供應(yīng)商?！盇gent可以理解問題 ↓ 確定時間范圍 ↓ 調(diào)用采購數(shù)據(jù)Tool ↓ 獲得數(shù)據(jù) ↓ 排序 ↓ 生成報告如果進(jìn)一步連接RAG采購制度 實時采購數(shù)據(jù) Agent就可以回答“為什么這個供應(yīng)商不能直接下采購訂單”十五、Agent CRMCRM場景同樣非常適合Agent。例如客戶查詢 ↓ 商機(jī)查詢 ↓ 客戶歷史跟進(jìn) ↓ 合同查詢 ↓ 生成客戶分析用戶“幫我整理一下這個客戶最近的銷售情況。”Agent查詢客戶 ↓ 查詢商機(jī) ↓ 查詢訂單 ↓ 查詢跟進(jìn)記錄 ↓ 匯總 ↓ 生成客戶畫像進(jìn)一步“幫我給這個客戶創(chuàng)建一次跟進(jìn)任務(wù)。”Agent可以調(diào)用CRM API ↓ 創(chuàng)建跟進(jìn)任務(wù) ↓ 返回任務(wù)結(jié)果十六、Agent不是“無限自由”的AI企業(yè)環(huán)境下不能讓Agent想干什么就干什么。例如查詢庫存可以自動執(zhí)行。但是刪除訂單 修改財務(wù)數(shù)據(jù) 創(chuàng)建付款 刪除客戶 調(diào)整庫存可能必須人工確認(rèn)因此企業(yè)Agent應(yīng)該設(shè)計低風(fēng)險操作 ↓ 自動執(zhí)行 中風(fēng)險操作 ↓ 權(quán)限檢查 高風(fēng)險操作 ↓ 人工確認(rèn) ↓ 執(zhí)行十七、Human-in-the-Loop這就是人在回路中。例如用戶 “幫我把SKU-10086庫存增加1000件?！盇gent不能直接執(zhí)行。應(yīng)該Agent ↓ 生成操作計劃 ↓ 發(fā)現(xiàn)這是高風(fēng)險操作 ↓ 要求用戶確認(rèn)提示即將執(zhí)行 倉庫WH01 SKUSKU-10086 庫存調(diào)整1000 該操作會修改實際庫存。 是否確認(rèn)執(zhí)行用戶確認(rèn)然后權(quán)限校驗 ↓ 調(diào)用API ↓ 執(zhí)行 ↓ 記錄審計日志這才是企業(yè)級Agent。十八、Agent權(quán)限設(shè)計Agent的權(quán)限不能等同于系統(tǒng)管理員權(quán)限。應(yīng)該采用用戶權(quán)限 ↓ Agent權(quán)限 ↓ Tool權(quán)限 ↓ 業(yè)務(wù)數(shù)據(jù)權(quán)限例如倉庫操作員 可以 ? 查詢庫存 ? 查詢庫位 ? 查詢訂單 不能 ? 刪除庫存 ? 修改財務(wù)數(shù)據(jù) ? 修改系統(tǒng)配置因此Agent調(diào)用Tool之前十九、Agent Memory記憶Agent還需要處理上下文。例如用戶“查詢一下A倉庫?！盇gent好的。用戶“再看看庫存不足的。”這里的“再看看”依賴前面的上下文。因此Agent需要保存Conversation History Task State User Preference Execution State可以簡單理解為Memory ↓ 讓Agent知道 “剛才發(fā)生了什么”二十、Agent State狀態(tài)企業(yè)任務(wù)往往不是一次完成。例如創(chuàng)建采購申請可能經(jīng)歷DRAFT ↓ SUBMITTED ↓ APPROVED ↓ PROCESSING ↓ COMPLETEDAgent需要知道當(dāng)前任務(wù)處于什么狀態(tài)。因此可以設(shè)計Agent State task_id user_id current_step tool_result approval_status error retry_count這樣才能支持復(fù)雜任務(wù)。二十一、Agent錯誤處理真實環(huán)境中Tool不可能永遠(yuǎn)成功。例如WMS API超時 數(shù)據(jù)庫連接失敗 權(quán)限不足 SKU不存在 庫存不足 參數(shù)錯誤Agent需要處理這些情況。例如例如API Timeout ↓ Retry ↓ 成功如果Permission Denied則不能無限重試。應(yīng)該停止 ↓ 提示用戶權(quán)限不足二十二、Agent為什么容易“失控”Agent比普通Chatbot復(fù)雜很多。因為它可以思考 調(diào)用工具 執(zhí)行動作 繼續(xù)調(diào)用工具如果設(shè)計不好就可能出現(xiàn)無限循環(huán) 錯誤調(diào)用 重復(fù)執(zhí)行 錯誤參數(shù) 權(quán)限越權(quán) 數(shù)據(jù)污染 成本失控因此Agent必須有邊界。二十三、Agent Guardrails企業(yè)Agent應(yīng)該增加Guardrails。例如還應(yīng)該限制最大執(zhí)行步數(shù) 最大Token 最大調(diào)用次數(shù) Tool白名單 API權(quán)限 金額限制 數(shù)據(jù)范圍二十四、Agent Workflow很多人會問Agent和Workflow是不是一樣不是。Workflow流程預(yù)先定義 ↓ Step 1 ↓ Step 2 ↓ Step 3 ↓ Step 4Agent目標(biāo) ↓ AI自主判斷下一步 ↓ 選擇Tool ↓ 執(zhí)行 ↓ 根據(jù)結(jié)果繼續(xù)判斷簡單來說Workflow 路線提前規(guī)劃好 Agent 根據(jù)現(xiàn)場情況動態(tài)決定路線二十五、什么時候用Workflow如果業(yè)務(wù)流程非常固定訂單創(chuàng)建 ↓ 訂單審核 ↓ 庫存檢查 ↓ 出庫 ↓ 發(fā)貨就適合Workflow。如果問題變化很大“幫我分析一下這個客戶為什么最近訂單下降?！笨赡苄枰狝gent動態(tài)決定查詢客戶 ↓ 查詢訂單 ↓ 查詢銷售趨勢 ↓ 查詢歷史記錄 ↓ 分析原因因此實際企業(yè)應(yīng)用往往是Agent Workflow二十六、企業(yè)級Agent整體架構(gòu)可以把完整架構(gòu)設(shè)計成在外層再增加Authentication Authorization Guardrails Evaluation Audit Log Monitoring形成企業(yè)級架構(gòu)。二十七、FDE如何做一個最小Agent建議不要一上來做超級企業(yè)AI Agent而應(yīng)該先做一個Agent 三個Tools。例如WMSTool 1 get_inventory() Tool 2 get_order() Tool 3 get_location()然后用戶 ↓ Agent ↓ 選擇Tool ↓ 調(diào)用API ↓ 返回結(jié)果先完成查詢型Agent。二十八、第二階段加入RAG然后加入Agent ├── RAG ├── get_inventory ├── get_order └── get_location此時AI同時具備企業(yè)知識 實時數(shù)據(jù)例如“按照公司制度 SKU-10086庫存低于多少需要補貨 它現(xiàn)在是否需要補貨”AgentRAG ↓ 獲得安全庫存規(guī)則 Tool ↓ 獲得實時庫存 LLM ↓ 綜合判斷二十九、第三階段加入執(zhí)行能力最后加入create_replenishment_task()架構(gòu)變成Agent │ ├── RAG ├── 查詢庫存 ├── 查詢訂單 ├── 查詢庫位 └── 創(chuàng)建補貨任務(wù)這樣查詢 ↓ 分析 ↓ 決策 ↓ 執(zhí)行就完整了。三十、FDE Agent項目開發(fā)流程一個真實項目可以按照其中最重要的一步是確定Agent場景。不是所有業(yè)務(wù)都需要Agent。三十一、什么場景適合Agent非常適合復(fù)雜查詢 跨系統(tǒng)查詢 多步驟任務(wù) 異常處理 業(yè)務(wù)分析 智能客服 運營助手 銷售助手 倉庫助手 IT運維助手例如“幫我分析這個訂單為什么沒有發(fā)出去?！笨赡苄枰樵冇唵?↓ 查詢庫存 ↓ 查詢揀貨任務(wù) ↓ 查詢波次 ↓ 查詢異常日志 ↓ 綜合分析這就是典型Agent場景。三十二、什么場景不適合Agent如果流程非常簡單查詢訂單 ↓ 返回訂單直接API就可以。如果流程高度固定A ↓ B ↓ C ↓ DWorkflow通常更加穩(wěn)定。如果只是企業(yè)知識問答制度問題 ↓ RAG ↓ 答案也沒必要強(qiáng)行使用Agent。所以FDE應(yīng)該學(xué)會不是為了Agent而Agent而是根據(jù)業(yè)務(wù)復(fù)雜度選擇技術(shù)。三十三、Agent項目最重要的三個問題FDE做項目時可以一直問第一個問題AI需要知道什么答案可能是RAG 數(shù)據(jù)庫 企業(yè)知識第二個問題AI需要做什么答案可能是Tool Calling API Workflow第三個問題AI能做到什么程度答案取決于權(quán)限 安全 業(yè)務(wù)規(guī)則 人工審批 系統(tǒng)能力最終形成Knowledge Action Permission Enterprise Agent三十四、FDE真正需要掌握的Agent能力FDE不一定要成為AI算法專家。但應(yīng)該能夠這才是FDE Agent工程能力。三十五、從RAG到Agent的完整演進(jìn)到這里我們已經(jīng)完成了可以總結(jié)為三十六、FDE的最終目標(biāo)不是“做一個Agent”這是本章最重要的一句話FDE不是為了證明自己會做Agent而是要利用Agent解決真實業(yè)務(wù)問題。例如客戶說“倉庫主管每天都要花兩個小時檢查庫存異常?！盕DE應(yīng)該思考最終人工檢查2小時 ↓ AI輔助 ↓ 20分鐘這才是FDE真正創(chuàng)造的價值。三十七、FDE Agent完整技術(shù)路線最終可以形成外層增加Security Permission Guardrails Evaluation Monitoring Audit最終才是完整的企業(yè)Agent平臺。三十八、本章總結(jié)本章從RAG繼續(xù)向前一步。上一篇RAG ↓ 讓AI知道企業(yè)知識這一篇Tool Calling ↓ 讓AI能夠調(diào)用企業(yè)系統(tǒng)進(jìn)一步Agent ↓ 讓AI能夠自主完成多步驟任務(wù)最終構(gòu)成企業(yè)級AI Agent的核心技術(shù)體系。對于FDE來說最值得記住的是三十九、下一篇預(yù)告下一篇進(jìn)入一個非常重要的主題《FDE前沿部署工程師實戰(zhàn)教程》09 - Agent工具設(shè)計從API到Tool Calling的企業(yè)系統(tǒng)集成我們將進(jìn)一步解決一個實際問題Agent到底如何連接ERP、CRM、WMS、MES重點學(xué)習(xí)并進(jìn)一步實踐如何把REST API變成AI ToolTool Schema如何設(shè)計Function Calling完整流程GET / POST / PUT / DELETE如何封裝數(shù)據(jù)庫查詢ToolWMS庫存查詢ToolERP訂單查詢ToolCRM客戶查詢ToolTool權(quán)限控制Tool參數(shù)校驗Tool錯誤處理Tool超時與重試Tool審計日志Agent多Tool協(xié)作企業(yè)系統(tǒng)集成實戰(zhàn)最終形成這一步將真正把FDE從“AI應(yīng)用開發(fā)”帶入“企業(yè)AI系統(tǒng)集成”。