FMS智能運營體正在重塑貨代行業(yè)的操作邏輯。本文以訂單管理為實戰(zhàn)場景，揭秘如何通過Prompts、Skills、Subagents等核心組件，將傳統(tǒng)Chatbot升級為能自動執(zhí)行復雜業(yè)務流程的智能中臺，實現(xiàn)從基礎對話到自動化工作流的跨越式進化。
本文旨在通過 1.1 訂單管理 這一具體業(yè)務場景，詳細演示如何利用 FMS 智能運營體 (FMS-Ops-Agent) 的核心組件（Prompts, Skills, Projects, Subagents, MCP）構建一個智能化的貨代操作系統(tǒng)。我們將展示從簡單的對話指令進階到復雜的自動化工作流的完整過程。
1. 核心概念概覽
在開始實戰(zhàn)之前，我們先統(tǒng)一一下對 FMS-Ops-Agent 組件的理解：
- Projects (大腦)：系統(tǒng)的“長期記憶”與“知識庫”。它讓智能體懂你的業(yè)務上下文。
- Prompts (神經指令)：日常的“指令”。用于處理一次性的、即時的任務。
- Skills (職業(yè)技能)：封裝好的“SOP（標準作業(yè)程序）”。讓智能體學會執(zhí)行復雜的標準化流程。
- Subagents (職能分身)：專職的“虛擬員工”。處理特定領域的專業(yè)任務（如報關、航線規(guī)劃）。
- MCP (手腳)：系統(tǒng)的“感官與執(zhí)行器”。連接數據庫、API 和外部工具。
2. 實戰(zhàn)演練：構建智能訂單管理系統(tǒng)
我們將按照構建順序，一步步搭建這個系統(tǒng)。
第一步：Projects (大腦) —— 建立“訂單管理”專屬空間
首先，我們需要讓 FMS-Ops-Agent 理解什么是“貨代訂單”。
操作動作：
1）在智能體配置中創(chuàng)建一個新 Project，命名為 “FMS 訂單管理系統(tǒng)”。
2）上傳知識庫：將以下核心文檔添加到 Project 的上下文中：
- 1.1 訂單管理.md（核心業(yè)務邏輯、字段定義、流程圖）
- 1.2 作業(yè)管理.md（訂單拆解后的下游任務）
- 15.1 基礎數據管理.md（港口、航線、費用代碼定義）
- 數據庫 Schema 定義文件（如 orders.sql, customers.sql）
效果：現(xiàn)在，當你對 FMS-Ops-Agent 說“創(chuàng)建一個海運出口訂單”時，它不再需要你解釋“海運出口訂單有哪些字段”，因為它已經“讀”過了 1.1 訂單管理.md 中的“頁面原型設計”和“數據流轉圖”。它知道必須包含“起運港”、“目的港”、“件重尺”等信息。
第二步：MCP (手腳) —— 打通“任督二脈”
光有知識是不夠的，智能體需要實時數據。我們需要通過 MCP 連接公司的數據庫和外部 API。
操作動作：
1）配置 Database MCP Server：
- 連接到 FMS 的測試數據庫（PostgreSQL/MySQL）。
- 賦予只讀權限（初期安全起見），允許執(zhí)行 SELECT 查詢。
2）配置 External API MCP Server：
集成“船期查詢 API”和“匯率查詢 API”。
場景演示：
用戶：請幫我檢查一下客戶 “ABC公司” 的信用額度夠不夠下這個新訂單（預估運費 $5000）。
FMS-Ops-Agent (內部思考)：
1. 調用 db_query 工具查詢 customer_credit 表。
2. 獲取結果：credit_limit: 50000, used_credit: 48000。
3. 計算：可用額度 2000 < 5000。
FMS-Ops-Agent (回答)：警告：ABC 公司的可用信用額度僅剩 $2000，不足以支付本單預估的 $5000 運費。建議先走特批流程或要求客戶付款。
第三步：Skills (職業(yè)技能) —— 封裝“訂單驗證 SOP”
訂單錄入有很多繁瑣的檢查規(guī)則。我們把這些規(guī)則寫成一個 Skill，讓智能體自動執(zhí)行。
操作動作：創(chuàng)建一個名為 OrderValidationSkill 的技能文件（Markdown 格式），內容如下：
# Order Validation Skill (訂單驗證技能)
## 目的
在訂單提交審核前，執(zhí)行標準化的合規(guī)性檢查。
## 檢查清單 (Checklist)
1. **港口邏輯檢查**：起運港和目的港不能在同一個國家（除非是國內運輸）。
2. **危險品檢查**：如果 `dangerous_goods` 為 true，必須檢查是否上傳了 MSDS 文檔。
3. **貨值邏輯**：如果 `cargo_value` > $100,000，必須建議客戶購買保險。
4. **必填項完整性**：檢查 HS 編碼是否為 10 位數字。
## 輸出格式
以列表形式輸出檢查結果，標記 [PASS] 或 [FAIL]。
場景演示：
用戶：我對剛錄入的 ORD-005 號訂單做個檢查。
FMS-Ops-Agent：收到。正在加載 OrderValidationSkill…
(智能體讀取訂單數據，逐條比對 Skill 中的規(guī)則)
檢查報告：
– [PASS] 港口邏輯 (上海 -> 漢堡)
– [FAIL] 危險品檢查：訂單標記為危險品，但系統(tǒng)附件中未發(fā)現(xiàn) MSDS 文檔。
– [PASS] 貨值邏輯
– [PASS] HS 編碼
建議：請補充 MSDS 文檔后再提交審核。
第四步：Subagents (職能分身) —— 組建“專家團隊”
訂單拆解（Order Breakdown）是一個復雜過程，涉及關務、航線、車隊等多個領域。我們可以引入 Subagents 來分工協(xié)作。
操作動作：
定義三個專門的 Subagent：
1）關務專家 (Customs Agent)：
職責：負責 HS 編碼歸類、判斷監(jiān)管條件。
Prompt 設定：“你是一名資深報關員，精通各國海關編碼和進出口管制政策…”
2）航線規(guī)劃師 (Route Planner Agent)：
職責：選擇最優(yōu)船期、計算運費成本。
Prompt 設定：“你是一名物流調度專家，專注于優(yōu)化路徑和降低物流成本…”
3）單證專員 (Doc Specialist Agent)：
職責：生成提單 (B/L)、發(fā)票、裝箱單。
場景演示：
用戶：這批貨（電子元器件）要從深圳發(fā)往鹿特丹，請給出物流方案。
FMS-Ops-Agent (協(xié)調者)：收到任務。正在召集專家組…
1）呼叫 關務專家：請確認電子元器件出口歐盟的監(jiān)管要求。
關務專家回復：需要 CE 認證，HS 編碼建議 8542.31，關稅率 0%。
2）呼叫 航線規(guī)劃師：查詢下周深圳去鹿特丹的快船。
航線規(guī)劃師回復：推薦 CMA CGM 班輪，周三截關，航程 28 天，運費 $3200。
3）FMS-Ops-Agent 匯總：根據專家建議，已為您生成預案。注意：請?zhí)崆皽蕚?CE 認證文件，我們建議預訂 CMA 周三的船期。
第五步：Prompts (神經指令) —— 靈活的日常指揮
有了以上基礎，日常的 Prompt 就變得非常簡單且高效。
場景演示：
用戶：給客戶發(fā)封郵件，告訴他們 ORD-001 已經訂艙成功了，把剛才航線規(guī)劃師查到的船名航次告訴他們。
FMS-Ops-Agent：
(利用 Project 上下文知道 ORD-001 的客戶是誰，利用剛才 Subagent 的輸出知道船名航次)
郵件草稿：
主題：【訂艙確認】訂單 ORD-001 / 目的港：洛杉磯
尊敬的張經理：
您好！
您的訂單 ORD-001 已成功完成訂艙。
船名/航次：CMA CGM CGM CORTES / 0TMS5E1MA
…
3. 總結：從“工具”到“系統(tǒng)”
通過這個案例，我們可以清晰地看到各個組件是如何配合的：
這就是 FMS-Ops-Agent 的威力：它不再只是一個陪聊的 Chatbot，而是變成了一個能理解業(yè)務、能執(zhí)行流程、能連接系統(tǒng)的智能業(yè)務中臺。
