從 OpenAI 客服 Demo 看企業 Agent：關鍵不是會聊天，而是會辦事
整理版優先睇
企業客服 Agent 關鍵唔係識傾偈，而係識辦事：OpenAI 開源客服 demo 深度拆解
呢篇文章剖析咗 OpenAI 開源嘅航空公司客服 demo，指出好多企業做「智能客服」失敗嘅原因——唔係大模型唔得，而係佢哋只係將大模型套個聊天框，忽略咗真正嘅企業級 Agent 需要五層架構：路由層（多 Agent 分工）、執行層（工具調用）、狀態層（Context 管理）、保護層（Guardrails）同觀察層（可觀測性）。作者係一個有實戰經驗嘅開發者，親手拆過 demo 代碼，想解決嘅問題係：點樣先做到一個真正識辦事、安全可控嘅客服 Agent？結論係：Agent 唔係更聰明嘅 FAQ，而係一套由自然語言驅動嘅業務流程系統。
文章用一個完整案例（乘客 Morgan Lee 因航班延誤要改簽、選座、申請補償）示範呢五層點樣協作：從 Triage 路由、Flight Info 診斷、Booking 自動改簽、Seat 處理特殊需求到 Refunds 發補償，總共經歷 4 次 Handoff 同 6 次工具調用。成個過程冇一步要用戶重複講，因為上下文自動喺 Agent 之間傳遞。
最後作者冷靜點出 demo 離生產嘅距離：冇真實系統集成、冇持久化、冇用戶認證、冇高風險二次確認、冇人工接管、冇錯誤處理、冇評估體系。佢提醒：真正嘅難點唔係接入大模型，而係將內部系統封裝成安全、可控、可審計嘅工具。
- 多 Agent 係將企業真實部門權限拆成代碼，每個 Agent 只擁有對應工具，避免越權；Prompt 係軟約束，工具綁定先係硬約束
- Handoff 要顯式建模業務流程，有限制（每輪最多一次、前置回調、回退路徑），唔係自由跳轉
- Context 分公開同內部字段，Agent 全知全能，用戶只睇應該睇嘅嘢，避免洩露內部狀態
- Guardrail 要做成獨立安全層，用輕量模型快速攔截，唔應該塞喺主 Agent prompt 入面
- 可觀測性係上線前提，透過 Agent View 同 Runner Output 回溯完整執行鏈路，支援故障排查、質量監控同線上優化
五層架構：路由、執行、狀態、保護、觀察
呢個 demo 令我最深刻嘅唔係聊天框，而係佢嘅結構：後端用 Python + FastAPI + OpenAI Agents SDK，前端用 Next.js + ChatKit React。成個系統分五層，缺一不可。
- 路由層：Triage Agent 做入口分診，判斷用戶需求交畀對應專員
- 執行層：11 個模擬工具對應訂單、庫存、座位、知識庫、權益等系統
- 狀態層：AirlineAgentContext 結構化存儲會話，用 public_context() 過濾敏感字段
- 保護層：Relevance Guardrail 同 Jailbreak Guardrail，用輕量模型獨立執行
- 觀察層：左邊 Agent View 顯示當前活躍 Agent、上下文、Guardrails 狀態同完整 Runner Output
多 Agent 係企業真實職責邊界嘅代碼映射
Demo 定義咗 6 個 Agent，每個對應一個真實部門：Triage（客服入口）、Flight Info（訂單查詢）、Booking（訂單變更）、Seat（特殊需求）、FAQ（政策諮詢）、Refunds（售後賠付）。
關鍵係每個 Agent 嘅工具權限被鎖死：Booking Agent 有 book_new_flight 同 cancel_flight，Refunds Agent 只有 issue_compensation，FAQ Agent 只得 faq_lookup_tool。呢個比喺 prompt 寫「唔好越權」可靠太多，因為 prompt 係軟約束，工具綁定係硬約束。
對比好多企業做一個萬能客服 prompt，將所有規則塞曬入去，然後祈禱模型唔好亂嚟。一旦生產流量大咗，問題就會湧現：模型可能「解釋」取消流程然後真係 call 咗取消工具，因為佢有權限。
Handoff 係受控業務流程，唔係無限跳轉
多 Agent 之間點樣交接？Demo 顯式定義 handoff 關係：Triage 可以交畀任何專員，專員之間都可以互相交（例如 Flight Info 發現要改簽就交畀 Booking）。但唔係自由跳轉，有幾個關鍵約束。
- 1 每輪最多一次 handoff，避免 A → B → C → D 不可控鏈條
- 2 部分 handoff 有前置回調，例如轉 Booking 前先補齊行程上下文，接手方唔使再問用戶
- 3 受控回退路徑：每個專員可以交返畀 Triage，但 Triage 係唯一可以重新路由嘅入口，確保全局掌控
呢個設計對應企業裏面嘅工單流轉：唔可以畀用戶無限被踢皮球，交接要有明確觸發條件、上下文傳遞同回退機制。
Agent 之間嘅交接關係，應該係對企業業務流程嘅顯式建模，唔係由模型自己決定揾邊個。
上下文管理同獨立 Guardrail：安全同效率嘅平衡
AirlineAgentContext 保存會話關鍵信息（乘客、行程、補償 case ID 等），但 public_context() 會過濾敏感字段：行程細節、行李 claim ID、補償 case ID、未發放權益等。Agent 內部全知全能，用戶只睇應該睇嘅。
內部狀態同用戶可見狀態分離，避免洩露工單號、風控評分等敏感資訊，係安全設計基本盤。好多企業將 Context 全部塞畀前端，造成安全隱患。
Guardrail 方面，Demo 有兩個 input guardrail：相關性檢查同越獄檢測，都用輕量模型 gpt-4.1-mini 執行，主業務用 gpt-5.2。佢哋只檢查最新一條消息，快速但對跨輪攻擊防禦有限。
可觀測性係上線前提，唔係錦上添花
呢個 demo 前端最特別嘅係左邊 Agent View，展示：活躍 Agent、可用 Agent 列表、篩選後嘅上下文、Guardrails 狀態、Runner Output（時間線事件流：handoff、tool_call、tool_output、context_update、message）。
呢個嘅價值在於：出事之後唔使估 Agent 點解咁做，完整執行鏈路一目瞭然——由 tool call 參數到返回值到上下文變更，全部可回溯。
- 故障排查：Agent 做錯？可能係訂單系統返回過期數據，睇 tool output 就知
- 質量監控：質檢團隊睇執行鏈路，Agent 有冇 skip 步驟？有冇 call 唔應該 call 嘅工具？
- 線上優化：產品團隊睇高頻攔截問題、頻繁失敗嘅 tool call，針對性優化 prompt 同流程
可惜而家好多企業將預算都花喺令聊天更自然，可觀測性「之後先搞」。結果上線後出事無人知原因，團隊互相卸責，最終老細話 AI 唔靠譜。
唔係 AI 唔靠譜，係上線之前冇裝後視鏡。
客服系統係每個企業都避唔開嘅嘢。唔理你係電商、物流、金融定係 SaaS，只要用戶數一多，客服就係剛需。
但一個尷尬嘅現實係：大多數企業做嘅所謂「智能客服」，上線第一日就被用戶試穿咗。用戶問「我個訂單幾時到」，機械人答「你個訂單已簽收」，但實際上件貨仲喺中轉站。
你話佢係人工智障啦，佢又真係接咗大模型。你話佢係客服 Agent 啦，佢其實只係一個更聰明嘅 FAQ。
問題出喺邊？唔係大模型唔得，而係大部份企業將客服 Agent 理解成咗接大模型 + 寫個 prompt（提示詞） + 套個聊天框。上線之後發現嗰啲問題一個都唔少：幻覺（模型亂編信息）、越權、流程混亂、出事揾唔到原因。
咁企業級客服 Agent 到底應該點做？OpenAI 最近開源咗一個客服 demo（openai-cs-agents-demo），場景係航空公司客服。我花咗一個下午將啲 code 拆咗一次，發現佢最值得睇嘅唔係聊天框，亦唔係 prompt 技巧。佢係一個企業級客服 Agent 嘅最細完整樣板：多 Agent 分工、業務工具調用、上下文狀態管理、獨立安全檢查、可觀測前端，五樣嘢齊曬。
呢篇文章將佢拆開，我哋一齊睇下企業客服 Agent 到底應該點做。
先睇結構。成個倉庫分兩邊：
後端係 Python + FastAPI + OpenAI Agents SDK，核心 code 喺 airline/ 目錄下面：
- •
agents.py— 6 個 Agent 嘅定義、提示詞、工具綁定同移交關係 - •
tools.py— 11 個模擬業務工具，查航班、改簽、改位、補償等 - •
guardrails.py— 兩個安全檢查（安全護欄），相關性校驗同越獄檢測 - •
context.py— 對話上下文狀態管理 - •
demo_data.py— mock（模擬）嘅航班行程、備選航班同補償數據
前端係 Next.js + ChatKit React，左右分屏。右邊係客戶見到嘅聊天界面，左邊係 Agent 視角，睇到當前邊個 Agent 喺度做緊嘢、叫咗咩工具、上下文點樣變、安全檢查過咗未。
呢個結構本身就講咗好多問題。一個企業客服 Agent 唔係聊天框 + 大模型就搞掂，佢需要五個層：路由層（Agent 分工）、執行層（工具調用）、狀態層（上下文管理）、保護層（Guardrails）、觀察層（可觀測性）。
跟住落嚟每個部分，我就圍繞呢五個層去講。
多 Agent 唔係曬技，係將企業真實嘅部門拆出嚟
呢個 demo 裏面定義咗 6 個 Agent：
Triage Agent — 入口路由。判斷用戶想點，交俾對應專員。對應企業裏面嘅客服入口 / 一線分診。
Flight Information Agent — 查航班狀態、判斷轉機風險、揾備選航班。對應訂單查詢 / 物流狀態查詢部門。
Booking & Cancellation Agent — 預訂、改簽、取消。對應訂單變更 / 退訂團隊。呢個 Agent 仲可以調用 book_new_flight 和 cancel_flight，喺 demo 裏面呢兩把鎖匙只俾咗佢。
Seat & Special Services Agent — 改位、處理醫療或特殊座位需求。對應個性化服務 / 特殊需求支援。佢揸住 update_seat 和 assign_special_service_seat。
FAQ Agent — 回答行李政策、Wi-Fi、補償政策等問題。對應企業知識庫 / 政策諮詢。佢只有一個工具：faq_lookup_tool，俾人明確要求：唔好用模型知識回答。
Refunds & Compensation Agent — 創建補償 case，派酒店券、餐券、交通補貼。對應售後 / 賠付 / 權益團隊。只有佢可以調用 issue_compensation。
睇到門路未？
每個 Agent 唔係一個抽象角色，而係將企業裏面真實存在嘅部門、職責同權限拆成 code。Booking Agent 可以改簽但唔可以派補償，Refunds Agent 可以派補償但唔可以改簽，FAQ Agent 可以查政策但唔可以改訂單。
對比下大多數企業而家嘅做法：寫一個萬能客服嘅 prompt，將所有業務規則塞曬入去，然後祈禱個模型唔好越權、唔好搞亂流程、唔好俾唔應該俾嘅信息。呢個做法喺細規模試用嗰陣仲得，一旦上咗生產流量，問題就會密密出現。
點解呢？因為 prompt 係軟約束，tool 權限係硬約束。你寫一句唔好越權操作，模型可能遵守，亦可能唔遵守。但如果你根本冇將改簽工具俾 FAQ Agent，佢想越權都冇途徑。
所以呢個 demo 畀出嘅第一個關鍵設計原則係：多 Agent 唔係架構上嘅花招，佢係將企業真實嘅職責邊界、權限邊界同流程邊界，用 code 固定落嚟。
Handoff 係受控嘅業務流程，唔係無限跳轉
有咗多個 Agent，下一個問題就係：佢哋之間點樣交接？
demo 裏面嘅做法係顯式定義 handoff 關係。Triage Agent 可以交接俾五個專員嘅任何一個，專員之間亦可以互相交接，例如 Flight Info Agent 發現問題要改簽，就交俾 Booking Agent；Booking Agent 發現用戶有特殊座位需求，交俾 Seat Agent。
但呢個唔係一個全連接嘅自由跳轉網絡。demo 裏面做咗幾個關鍵約束：
第一，每輪最多一次 handoff。prompt 裏面反覆寫咗呢個要求。點解？因為唔限制嘅話，Agent 可能喺一輪對話裏面 A → B → C → D 咁一路跳落去，成個過程不可控、唔可以解釋。
第二，部分 handoff 有前置回調。例如轉去 Booking Agent 之前，會先補齊行程上下文；轉去 Seat Agent 之前，確保座位偏好已經俾人抽出嚟。呢個保證接手方攞到嘅係完整信息，唔會反覆追問用戶。
第三，受控嘅回退路徑。每個專員都可以交返俾 Triage Agent，但 Triage 係唯一可以重新路由嘅入口。呢個設計避免咗一線 Agent 被繞過後，客服入口喪失咗對全局嘅掌控。
喺企業客服場景裏面，handoff 對應嘅就係部門流轉同工單流轉。你唔可能俾用戶喺一線客服同售後賠付之間被無限踢嚟踢去，同樣，你都需要確保 Agent 交接時有明確嘅觸發條件、上下文傳遞同回退機制。
呢個 demo 嘅 handoff 設計仲好基礎，但佢畀出一條原則：Agent 之間嘅交接關係，應該係對企業業務流程嘅顯式建模，而唔係俾模型自己決定應該揾邊個。
工具權限比 Prompt 更重要
之前已經提到咗少少，呢度詳細講。
Demo 裏面有 11 個工具，覆蓋咗查航班、揾備選、改簽、取消、改位、特殊座位、顯示座位圖、FAQ 查詢、行李查詢、派補償。每個工具背後對應一個企業系統：訂單系統、庫存系統、座位系統、知識庫、工單系統、權益系統。
呢啲工具嘅分配係有講究嘅：
- • FAQ Agent 得一個
faq_lookup_tool。佢唔可以查航班、唔可以改簽、唔可以派補償。佢嘅能力邊界俾工具鎖死咗。 - • Booking Agent 有
book_new_flight和cancel_flight。得佢可以做訂單變更。 - • Refunds Agent 有
issue_compensation。得佢可以創建補償 case 同派券。 - • Seat Agent 有
update_seat和assign_special_service_seat。得佢可以鬱座位。
呢個比喺 prompt 裏面寫你唔好越權可靠得多。
我喺幾個企業項目裏面見過類似嘅坑。一個電商客服 Agent 嘅 prompt 裏面寫咗「你只能查訂單，唔可以取消」，結果測試嗰陣用戶話「我知你唔可以取消，但我只係想確認下，如果我㩒取消會點」，Agent 就開始「解釋」取消流程，解釋嚇解釋嚇就調用取消失敗咗。因為佢有嗰個工具嘅權限，prompt 攔唔住佢。
所以 demo 畀出嘅設計係：將權限邊界落實到工具綁定上。一個 Agent 可以做啲乜，睇佢有邊啲工具，唔係睇 prompt 裏面寫咗咩限制。
反過嚟都一樣。如果企業之後要幫某個 Agent 加能力，唔係改 prompt，而係俾佢加工具。呢個就好似俾員工開系統權限：做到啲乜取決於你個工號可以登錄邊啲系統，唔取決於你份崗位說明書。
上下文管理：Agent 知道嘅，用戶唔一定需要睇到
Demo 裏面有個設計我好鍾意：AirlineAgentContext。
呢個係一個結構化嘅對話狀態對象，保存咗當前對話入面所有關鍵信息：乘客姓名、確認號、航班號、座位號、行程詳情、行李 claim id、補償 case id、已派發嘅權益、特殊服務備註等等。
關鍵係，佢有一個 public_context() 方法。
呢個方法會過濾走部份字段：隱藏完整行程（itinerary）、隱藏行李 claim id、隱藏補償 case id、隱藏 demo 場景標記、隱藏未實際派發嘅權益。換句話講，Agent 內部可以用曬全部上下文嚟做決策，但用戶界面淨係展示應該俾用戶睇到嘅部份。
呢個設計對應企業客服中一個非常實際嘅訴求：內部狀態同用戶可見狀態係兩套嘢。
例如，一個補償 case 嘅創建邏輯入面可能有系統判定嘅賠付上限、風控標記、內部備註，呢啲信息 Agent 需要知道先可以做到正確決策，但絕對唔可以直接展示俾用戶。又例如，用戶嘅完整訂單鏈路可能包含多個狀態變更記錄，Agent 決策時需要全量信息，但用戶只需要睇到當前狀態同下一步。
好多企業做客服 Agent 嘅時候忽視咗呢一點。上下文一泡過塞曬俾前端，用戶睇到內部工單號、系統策略名、甚至風控評分。呢個唔單止係體驗問題，亦係安全隱患。
Demo 嘅做法好簡單但有效：用結構化狀態 + 公開/內部字段分離，做到 Agent 全知全能，用戶淨係睇應該睇嘅。
Guardrail 應該係獨立安全檢查層
Demo 裏面有兩個 input guardrail（輸入安全檢查，喺用戶消息到達業務 Agent 之前先過一次）：
Relevance Guardrail（相關性檢查）：用 gpt-4.1-mini 判斷用戶消息係咪同航空客服相關。用戶如果問幫我寫段 code，直接攔截。
Jailbreak Guardrail（越獄攻擊檢測）：同樣係 gpt-4.1-mini，判斷用戶係咪想繞過系統指令、攞 prompt（提示詞）或者進行攻擊。
兩個 guardrail 都係用輕量模型，主業務 Agent 就用 gpt-5.2。呢個係成本同延遲嘅取捨：安全檢查唔需要最強模型，但需要高頻執行。
更加有意思嘅設計係：guardrail 淨係檢查最新嗰條用戶消息，唔係成個對話歷史。咁樣做快啲，亦可以減少誤傷。但佢對跨輪上下文攻擊、漸進式指令注入嘅防禦力有限，demo 裏面冇解決呢個問題。
不過呢個 demo 嘅 guardrail 最重要嘅啟示唔係技術實現，而係架構原則：安全檢查唔應該係主 Agent prompt 裏面嘅一句請遵守安全規範，而應該係一個獨立嘅、可替換嘅、喺主 Agent 之前執行嘅安全層。
呢個獨立層嘅意義在於：
- • 安全檢查失敗咗，可以直接攔截，唔會消耗主模型嘅 token（大模型嘅調用按 token 計費，慳 token 就係慳錢）。
- • 安全策略更新唔需要改主 Agent 嘅 prompt，改咗 prompt 仲要重新測試業務表現。
- • 可以並行部署多個專用 guardrail，每個淨係檢查一個維度。
但呢個 demo 嘅 guardrail 離生產仲好遠。真實企業客服至少仲需要：
- • 身份校驗：呢次對話請求嘅用戶係邊個？有冇登入？
- • 權限校驗：呢個用戶有權做呢個操作嗎？呢個訂單係呢個用戶嘅嗎？
- • PII 脱敏（個人敏感信息脱敏）：對話記錄同日誌入面唔可以出現身份證號、電話號碼、銀行卡號呢啲敏感信息。
- • 高風險操作二次確認：退款、取消、改簽呢類操作，需要明確確認，唔可以一句說話就執行。
- • 人工接管條件：Agent 連續三輪搞唔掂、用戶情緒明顯激動、涉及投訴同賠付爭議，應該自動轉人工。
- • 審計日誌：邊個喺幾時做咗啲乜，邊條 guardrail 放行或攔截咗，一定要可以追溯。
- • 工具調用結果校驗：guardrail 唔單止檢查用戶輸入，都應該檢查工具返嚟嘅數據係咪合法、完整。
簡單講：demo 嘅 guardrail 係概念驗證，生產級 guardrail 需要覆蓋輸入、輸出、工具調用同人工接管成條鏈路。
可觀測性唔係錦上添花，係上線前提
呢個 demo 嘅前端最特別嘅地方：佢唔係得一個聊天框。
右邊係客戶視角，普通 ChatKit 聊天界面，用戶淨係見到正常嘅客服對話。
左邊係 Agent 視角，一個叫 Agent View 嘅面板，裏面展示：
- • 當前邊個 Agent 活躍緊
- • 所有可用嘅 Agent 列表
- • 對話上下文（篩選後嘅公開版本）
- • Guardrails 狀態（通過/攔截）
- • Runner Output（運行日誌）：一個按時間線排列嘅事件流，包括
handoff（Agent 移交）、tool_call（叫咗咩工具，參數係乜）、tool_output（工具返咗乜）、context_update（上下文邊啲字段變咗）、message（Agent 講咗啲乜）
呢樣嘢嘅價值，做過客服系統嘅人一睇就明。
Agent 上線之後，你最常俾人問嘅問題唔係佢嘅回覆準唔準，而係：佢點解退咗錢？佢點解取消咗訂單？佢點解將用戶轉咗去投訴部門？佢查到嘅訂單信息係咪啱？
如果你得聊天記錄，呢啲問題一半答唔到。因為用戶淨係見到 Agent 嘅最終回覆，見唔到中間過程。
但如果你有 Runner Output，你就可以回溯成個執行鏈路：用戶問咗乜 → Triage 路由去邊個 Agent → 叫咗邊個工具 → 工具返咗咩數據 → 數據觸發咗咩上下文更新 → Agent 根據呢啲數據做咗咩決策。
呢個唔再係估佢點解咁回答，而係還原佢每一步做咗啲乜。
將呢個能力放入企業客服系統，佢至少支撐三個場景：
故障排查：用戶投訴 Agent 做錯嘢，客服主管打開 Agent View，睇工具調用記錄，發現問題唔係 Agent 錯，係訂單系統返咗過期數據。問題定位由幾個鐘縮到幾分鐘。
質量監控：質檢團隊唔再淨係睇對話文本，而係睇成個執行鏈路。Agent 有冇跳過必要步驟？有冇叫咗唔應該叫嘅工具？handoff 決策啱唔啱？
線上優化：產品團隊睇高頻被攔截嘅問題、頻頻失敗嘅 tool call、成日回退嘅 handoff，針對性優化 prompt 同流程。
可惜嘅係，而家大多數企業嘅客服 Agent 項目，預算同時間都放咗喺令聊天更自然度，可觀測性俾人當成之後再講。結果就係 Agent 上線後，出咗問題冇人知原因，團隊開始互相卸膊，最後老細話AI 唔可靠，暫時停咗先。
其實唔係 AI 唔可靠，係上線之前冇裝後視鏡。
一個案例行曬所有設計
講咗一堆設計原則，用一個 demo 裏面嘅完整流程將佢哋串返埋。
場景：用戶 Morgan Lee 由巴黎經紐約飛奧斯汀，第一程航班 PA441 因為天氣延誤咗 5 個鐘。
用戶輸入：I'm flying Paris to Austin via New York and my first leg is delayed.
然後發生嘅事：
第一步，路由。 Triage Agent 收到消息，識別為航班異常問題。佢調用 get_trip_details，從 mock 數據中配對到 Morgan Lee 嘅行程（確認號 IR-D204），寫入上下文。然後 handoff 去 Flight Information Agent。
呢度有三個設計點喺度起作用：Triage Agent 嘅路由判斷、工具調用填補上下文、handoff 傳遞完整信息。
第二步，診斷。 Flight Information Agent 調用 flight_status_tool，發現 PA441 因天氣延誤 5 個鐘，預計 19:55 起飛。系統計算後發現，咁會 miss 咗喺紐約嘅轉機航班 NY802。
呢度體現嘅係：Agent 唔係淨係回答狀態，而係執行緊業務判斷：佢需要知道延誤會導致 miss 轉機。
第三步，揾方案。 Flight Information Agent 調用 get_matching_flights，揾到兩個備選航班：NY950（第二日 9:45，座位 2A）同 NY982（第二日 13:20，座位 3C）。
留意呢度有個細節：兩個備選航班嘅座位信息已經有咗。呢個就為之後自動改簽同揀位鋪好路。
第四步，執行。 Flight Information Agent 將結果 handoff 俾 Booking & Cancellation Agent。Booking Agent 直接調用 book_new_flight，改簽去 NY950，座位 2A。
呢一步係關鍵：用戶冇話幫我改簽，Agent 自己主動做咗。因為上下文裏面已經有曬需要嘅信息（確認號、而家航班、備選航班），Agent 唔需要再問多次「要唔要幫你改」。
呢個設計嘅來源係 prompt 裏面一句指令：「數據齊全時自動串聯工具，唔好每一步都停落嚟問用戶」。
第五步，特殊需求。 用戶提到有醫療原因，需要前排座位。Booking Agent 將呢個需求 handoff 俾 Seat & Special Services Agent。Seat Agent 調用 assign_special_service_seat，分配咗 1A。
呢度有一個隱式嘅上下文傳遞：改簽後嘅航班信息已經喺上下文裏面，Seat Agent 唔需要再查多次。
第六步，補償。 用戶抱怨過夜延誤。Seat Agent handoff 去 Refunds & Compensation Agent。Refunds Agent 調用 faq_lookup_tool 查咗補償政策，然後調用 issue_compensation，創建補償 case，派發酒店券（最高 180 美金）、餐券（60 美金）、地面交通補貼（40 美金）。
留意：Refunds Agent 只係叫咗 FAQ 工具查政策，佢冇 FAQ Agent 咁受限，佢可以查政策同派補償兩樣嘢都做，但改簽同改位就絕對唔掂。
成個流程行落嚟，用戶見到嘅係：一個客服全程幫佢搞掂咗延誤、改簽、揀位、補償。而 Agent 內部經歷咗 4 次 handoff（Triage → Flight Info → Booking → Seat → Refunds），叫咗 6 個工具（查行程、查狀態、揾備選、改簽、特殊座位、查政策 + 派補償），上下文被更新咗多次，每個操作都有工具權限約束。
呢個邊係回答問題，呢個明明係喺多個業務系統之間跑流程。
生產落地仲爭啲乜
拆完之後，一定要講句：呢個 demo 明確標註咗係演示用途，唔係生產系統。客觀指出佢嘅不足，比一味追捧更有價值。
1. 真實系統集成。 Demo 裏面所有業務數據都係 mock 嘅。生產環境需要對接 CRM（客戶管理系統）、訂單系統、工單系統、支付系統、庫存系統、用戶身份系統、權益系統。每一個對接都係真實工程量嘅來源。
2. 持久化。 目前用 in-memory store（內存儲存，服務重啟後數據會冇曬）。生產需要數據庫、對話存儲同完整嘅審計日誌。
3. 權限體系。 Demo 冇用戶認證，冇區分用戶、客服、管理員、系統角色。真實客服系統裏面，用戶見到嘅數據、Agent 可以做到嘅操作、管理員可以睇到嘅日誌，係三層唔同嘅權限。
4. 高風險操作確認。 取消訂單、退款、修改個人信息呢類操作，demo 裏面 Agent 可以直接執行。生產中需要二次確認、額度限制同審批流程。
5. 人工接管。 Demo 裏面冇人類客服接管嘅機制。真實客服系統一定要設計轉人工嘅條件：連續 N 輪搞唔掂、情緒識別、投訴關鍵詞、高價值用戶、賠付爭議。
6. 錯誤處理。 真實系統會遇到 API 超時、返異常數據、庫存變化、支付失敗、並發衝突。Demo 裏面工具都係同步 mock，唔存在呢啲問題。生產需要重試、回滾、冪等設計。
7. 評估體系。 點樣知道呢個 Agent 做得好唔好？淨係睇對話記錄唔夠。需要建立一套指標：問題解決率、轉人工率、誤操作率、平均處理時間、客戶滿意度、賠付成本。而且要分開 Agent 嘅問題同業務系統嘅問題。
8. 行李 Agent 缺失。 Code 裏面有 baggage_tool，prompt 裏面多次提到 Baggage Agent，但實際冇定義同接入獨立行李 Agent。說明呢個 demo 自己都未做完。
所以如果要用呢套樣板做企業客服 Agent，補齊嘅順序應該係：先接真實數據源（等 Agent 有用），再做持久化同審計（等系統可靠），然後上權限同確認機制（等系統安全），最後建評估體系（等系統可以量度）。
最後
回過頭嚟睇呢個 demo，佢展示嘅唔係一個客服聊天機械人，而係一個 Agent 操作系統嘅雛形。
路由層（Triage + Handoff）決定件事交俾邊個辦 執行層（Tool calling）決定可以辦到咩程度 狀態層（Context）保證辦事過程唔會唔見信息 保護層（Guardrails）防止唔應該辦嘅事被辦咗 觀察層（Agent View + Runner Output）確保出事可以查到點解。
呢五層裏面，大多數企業而家只係關注咗聊天體驗嗰一小部分。
真正難嘅唔係接入大模型。ChatGPT 嘅 API 駁通只要五分鐘。真正嘅難點係將企業內部系統封裝成安全、可控、可審計嘅工具，令 Agent 既可以辦到事，又唔會搞出禍。
OpenAI 呢個 demo 俾咗一個可以參考嘅起點。佢唔完美，但佢至少講清楚咗一件事：企業客服 Agent 唔係更聰明嘅 FAQ，而係一套可以被自然語言驅動嘅業務流程系統。
下一步，就睇邊個先將呢五層落返生產。
客服系統是每個企業都繞不開的東西。不管你是電商、物流、金融還是 SaaS，只要用戶數上來，客服就是剛需。
但一個尷尬的現實是：大多數企業做的所謂「智能客服」，上線第一天就被用戶測出原形。用戶問「我的訂單什麼時候到」，機器人回「您的訂單已簽收」，實際上物流還在中轉站。
你說它是人工智障吧，它確實接了大模型。你說它是客服 Agent 吧，它其實就只是個更聰明的 FAQ。
問題出在哪？不是大模型不行，是大部分企業把客服 Agent 理解成了接大模型 + 寫個 prompt（提示詞） + 套個聊天框。上線後發現該有的問題一個不少：幻覺（模型瞎編信息）、越權、流程混亂、出了事查不到原因。
那企業級客服 Agent 到底該怎麼做？OpenAI 最近開源了一個客服 demo（openai-cs-agents-demo），場景是航空公司客服。我花了一個下午把代碼拆了一遍，發現它最值得看的不是聊天框，也不是 prompt 技巧。它是一個企業級客服 Agent 的最小完整樣板：多 Agent 分工、業務工具調用、上下文狀態管理、獨立安全檢查、可觀測前端，五樣東西一個不少。
這篇文章把它拆開，我們一起看看企業客服 Agent 到底該怎麼做。
先看結構。整個倉庫分兩塊：
後端是 Python + FastAPI + OpenAI Agents SDK，核心代碼在 airline/ 目錄下：
- •
agents.py— 6 個 Agent 的定義、提示詞、工具綁定和移交關係 - •
tools.py— 11 個模擬業務工具，查航班、改簽、改座、補償等 - •
guardrails.py— 兩個安全檢查（安全護欄），相關性校驗和越獄檢測 - •
context.py— 會話上下文狀態管理 - •
demo_data.py— mock（模擬）的航班行程、備選航班和補償數據
前端是 Next.js + ChatKit React，左右分屏。右邊是客戶看到的聊天界面，左邊是Agent 視角，能看到當前哪個 Agent 在幹活、調了什麼工具、上下文怎麼變的、安全檢查過了沒。
這個結構本身就說明了很多問題。一個企業客服 Agent 不是聊天框 + 大模型就完事了，它需要五個層：路由層（Agent 分工）、執行層（工具調用）、狀態層（上下文管理）、保護層（Guardrails）、觀察層（可觀測性）。
接下來的每個部分，我就圍繞這五個層展開。
多 Agent 不是炫技，是把企業真實的部門拆出來
這個 demo 裏定義了 6 個 Agent：
Triage Agent — 入口路由。判斷用戶想幹什麼，交給對應專員。對應企業裏的客服入口 / 一線分診。
Flight Information Agent — 查航班狀態、判斷轉機風險、找備選航班。對應訂單查詢 / 物流狀態查詢部門。
Booking & Cancellation Agent — 預訂、改簽、取消。對應訂單變更 / 退訂團隊。這個 Agent 還能調用 book_new_flight 和 cancel_flight，在 demo 裏這兩把鑰匙只給了它。
Seat & Special Services Agent — 改座位、處理醫療或特殊座位需求。對應個性化服務 / 特殊需求支持。它握着 update_seat 和 assign_special_service_seat。
FAQ Agent — 回答行李政策、Wi-Fi、補償政策等問題。對應企業知識庫 / 政策諮詢。它只有一個工具：faq_lookup_tool，被明確要求：不要用模型知識回答。
Refunds & Compensation Agent — 創建補償 case，發酒店券、餐券、交通補貼。對應售後 / 賠付 / 權益團隊。只有它能調用 issue_compensation。
看出門道了嗎？
每個 Agent 不是一個抽象角色，而是把企業裏真實存在的部門、職責和權限拆成了代碼。Booking Agent 能改簽但不能發補償，Refunds Agent 能發補償但不能改簽，FAQ Agent 能查政策但不能改訂單。
對比一下大多數企業現在的做法：寫一個萬能客服的 prompt，把所有業務規則塞進去，然後祈禱模型不要越權、不要搞混流程、不要給不該給的信息。這個做法在小規模試用時還行，一旦上了生產流量，問題會密集出現。
為什麼呢？因為 prompt 是軟約束，tool 權限是硬約束。你寫一句不要越權操作，模型可能遵守，也可能不遵守。但如果你根本沒把改簽工具發給 FAQ Agent，它想越權都沒途徑。
所以這個 demo 給出的第一個關鍵設計原則是：多 Agent 不是架構上的花活，它是把企業真實的職責邊界、權限邊界和流程邊界，用代碼固定下來。
Handoff 是受控的業務流程，不是無限跳轉
有了多個 Agent，下一個問題就是：它們之間怎麼交接？
demo 裏的做法是顯式定義 handoff 關係。Triage Agent 可以交接給五個專員中的任何一個，專員之間也可以互相交接，比如 Flight Info Agent 發現問題需要改簽，就交給 Booking Agent；Booking Agent 發現用戶有特殊座位需求，交給 Seat Agent。
但這不是一個全連接的自由跳轉網絡。demo 裏做了幾個關鍵約束：
第一，每輪最多一次 handoff。prompt 裏反覆寫了這個要求。為什麼？因為如果不限制，Agent 可能在一輪對話裏 A → B → C → D 一路跳下去，整個過程不可控、不可解釋。
第二，部分 handoff 有前置回調。比如轉到 Booking Agent 之前，會先補齊行程上下文；轉到 Seat Agent 之前，確保座位偏好已經被提取出來。這保證了接手方拿到的是完整信息，不會反覆追問用戶。
第三，受控的回退路徑。每個專員都可以交回給 Triage Agent，但 Triage 是唯一可以重新路由的入口。這個設計避免了一線 Agent 被繞過後，客服入口喪失了對全局的掌控。
在企業客服場景裏，handoff 對應的就是部門流轉和工單流轉。你不可能讓用戶在一線客服和售後賠付之間被無限踢皮球，同樣，你也需要確保 Agent 交接時有明確的觸發條件、上下文傳遞和回退機制。
這個 demo 的 handoff 設計還很基礎，但它給出了一條原則：Agent 之間的交接關係，應該是對企業業務流程的顯式建模，而不是讓模型自己決定該找誰。
工具權限比 Prompt 更重要
前面已經提到了一點，這裏展開說。
Demo 裏有 11 個工具，覆蓋了查航班、找備選、改簽、取消、改座、特殊座位、顯示座位圖、FAQ 查詢、行李查詢、發補償。每個工具背後對應一個企業系統：訂單系統、庫存系統、座位系統、知識庫、工單系統、權益系統。
這些工具的分配是有講究的：
- • FAQ Agent 只有一個
faq_lookup_tool。它不能查航班、不能改簽、不能發補償。它的能力邊界被工具鎖死了。 - • Booking Agent 有
book_new_flight和cancel_flight。只有它能做訂單變更。 - • Refunds Agent 有
issue_compensation。只有它能創建補償 case 併發券。 - • Seat Agent 有
update_seat和assign_special_service_seat。只有它能動座位。
這比在 prompt 裏寫你不要越權靠譜太多了。
我在幾個企業項目裏見過類似的坑。一個電商客服 Agent 的 prompt 裏寫了「你只能查訂單，不能取消」，結果測試的時候用戶說「我知道你不能取消，但我就是想確認一下，如果我點取消會發生什麼」，Agent 就開始「解釋」取消流程，解釋着解釋着就調用取消失敗了。因為它有那個工具的權限，prompt 攔不住它。
所以 demo 給出的設計是：把權限邊界落實到工具綁定上。一個 Agent 能做什麼，看它有哪些工具，不看 prompt 裏寫了什麼限制。
反過來也一樣。如果企業後續要給某個 Agent 增加能力，不是改 prompt，而是給它加工具。這就像給員工開系統權限：能幹什麼取決於你的工號能登錄哪些系統，不取決於你的崗位說明書。
上下文管理：Agent 知道的，用戶不一定需要看到
Demo 裏有一個設計我特別喜歡：AirlineAgentContext。
這是一個結構化的會話狀態對象，保存了當前對話中的所有關鍵信息：乘客姓名、確認號、航班號、座位號、行程詳情、行李 claim id、補償 case id、已發放的權益、特殊服務備註等等。
關鍵是，它有一個 public_context() 方法。
這個方法會過濾掉部分字段：隱藏完整行程（itinerary）、隱藏行李 claim id、隱藏補償 case id、隱藏 demo 場景標記、隱藏未實際發放的權益。換句話說，Agent 內部可以使用全部上下文做決策，但用戶界面只展示應該讓用戶看到的部分。
這個設計對應企業客服中一個非常實際的訴求：內部狀態和用戶可見狀態是兩套東西。
比如，一個補償 case 的創建邏輯裏可能有系統判定的賠付上限、風控標記、內部備註，這些信息 Agent 需要知道才能做正確決策，但絕不能直接展示給用戶。再比如，用戶的完整訂單鏈路可能包含多個狀態變更記錄，Agent 決策時需要全量信息，但用戶只需要看到當前狀態和下一步。
很多企業做客服 Agent 時忽視了這一點。上下文一股腦全塞給前端，用戶能看到內部工單號、系統策略名、甚至風控評分。這不僅是體驗問題，也是安全隱患。
Demo 的做法很簡單但有效：用結構化狀態 + 公開/內部字段分離，做到 Agent 全知全能，用戶只看該看的。
Guardrail 應該是獨立安全檢查層
Demo 裏有兩個 input guardrail（輸入安全檢查，在用戶消息到達業務 Agent 之前先過一遍）：
Relevance Guardrail（相關性檢查）：用 gpt-4.1-mini 判斷用戶消息是否和航空客服相關。用戶如果問幫我寫段代碼，直接攔截。
Jailbreak Guardrail（越獄攻擊檢測）：同樣是 gpt-4.1-mini，判斷用戶是否在嘗試繞過系統指令、索要 prompt（提示詞）或進行攻擊。
兩個 guardrail 都用的輕量模型，主業務 Agent 用的是 gpt-5.2。這是一個成本和延遲上的折中：安全檢查不需要最強模型，但需要高頻執行。
更有意思的設計是：guardrail 只檢查最新一條用戶消息，不是整個對話歷史。這樣做更快，也能減少誤傷。但它對跨輪上下文攻擊、漸進式指令注入的防禦力有限，demo 裏沒有解決這個問題。
不過這個 demo 的 guardrail 最重要的啓示不是技術實現，而是架構原則：安全檢查不應該是主 Agent prompt 裏的一句請遵守安全規範，而應該是一個獨立的、可替換的、在主 Agent 之前執行的安全層。
這個獨立層的意義在於：
- • 安全檢查失敗了，可以直接攔截，不消耗主模型的 token（大模型的調用按 token 計費，省 token 就是省錢）。
- • 安全策略更新不需要改主 Agent 的 prompt，改了 prompt 還得重新測試業務表現。
- • 可以並行部署多個專用 guardrail，每個只檢查一個維度。
但這個 demo 的 guardrail 離生產還很遠。真實企業客服至少還需要：
- • 身份校驗：這通對話請求的用戶是誰？有沒有登錄？
- • 權限校驗：這個用戶有權做這個操作嗎？這條訂單是這個用戶的嗎？
- • PII 脱敏（個人敏感信息脱敏）：對話記錄和日誌中不能出現身份證號、手機號、銀行卡號等敏感信息。
- • 高風險操作二次確認：退款、取消、改簽這類操作，需要明確確認，不能一句話就執行。
- • 人工接管條件：Agent 連續三輪無解、用戶情緒明確激動、涉及投訴和賠付爭議，應該自動轉人工。
- • 審計日誌：誰在什麼時候做了什麼，哪條 guardrail 放行或攔截了，必須可追溯。
- • 工具調用結果校驗：guardrail 不只檢查用戶輸入，也應該檢查工具返回的數據是否合法、完整。
簡單說：demo 的 guardrail 是概念驗證，生產級 guardrail 需要覆蓋輸入、輸出、工具調用和人工接管整條鏈路。
可觀測性不是錦上添花，是上線前提
這個 demo 的前端最特別的地方：它不是隻有一個聊天框。
右邊是客戶視角，普通的 ChatKit 聊天界面，用戶只看到正常的客服對話。
左邊是 Agent 視角，一個面板叫 Agent View，裏面展示：
- • 當前哪個 Agent 在活躍
- • 所有可用的 Agent 列表
- • 會話上下文（篩選後的公開版本）
- • Guardrails 狀態（通過/攔截）
- • Runner Output（運行日誌）：一個按時間線排列的事件流，包括
handoff（Agent 移交）、tool_call（調了什麼工具，參數是什麼）、tool_output（工具返回了什麼）、context_update（上下文哪些字段變了）、message（Agent 說了什麼）
這個東西的價值，做過客服系統的人一看就懂。
Agent 上線之後，你最常被問到的問題不是它的回覆準不準，而是：它為什麼把錢退了？它為什麼把訂單取消了？它為什麼把用戶轉到了投訴部門？它查到的訂單信息是對的嗎？
如果你只有聊天記錄，這些問題一半答不上來。因為用戶只看到了 Agent 的最終回覆，看不到中間過程。
但如果你有 Runner Output，你就能回溯完整的執行鏈路：用戶問了什麼 → Triage 路由到哪個 Agent → 調用了哪個工具 → 工具返回了什麼數據 → 數據觸發了什麼上下文更新 → Agent 基於這些數據做了什麼決策。
這不再是猜它為什麼這麼回答，而是還原它每一步做了什麼。
把這個能力放進企業客服系統，它至少支撐三個場景：
故障排查：用戶投訴 Agent 做錯了事，客服主管打開 Agent View，看工具調用記錄，發現問題不是 Agent 錯了，是訂單系統返回了過期數據。問題定位從幾小時縮到幾分鐘。
質量監控：質檢團隊不再只看對話文本，而是看完整的執行鏈路。Agent 有沒有跳過必要步驟？有沒有調用不該調的工具？handoff 決策對不對？
線上優化：產品團隊看高頻被攔截的問題、頻繁失敗的 tool call、經常回退的 handoff，針對性優化 prompt 和流程。
可惜的是，現在大多數企業的客服 Agent 項目，預算和時間都花在了讓聊天更自然上，可觀測性被當成了後續再說。結果就是 Agent 上線後，出了問題沒人知道原因，團隊開始互相甩鍋，最後老闆說AI 不靠譜，先停了吧。
其實不是 AI 不靠譜，是上線之前沒裝後視鏡。
一個案例走完所有設計
說了一堆設計原則，用一個 demo 裏的完整流程把它們串起來。
場景：用戶 Morgan Lee 從巴黎經紐約飛奧斯汀，第一段航班 PA441 因為天氣延誤了 5 小時。
用戶輸入：I'm flying Paris to Austin via New York and my first leg is delayed.
然後發生的事情：
第一步，路由。 Triage Agent 收到消息，識別為航班異常問題。它調用 get_trip_details，從 mock 數據中匹配到 Morgan Lee 的行程（確認號 IR-D204），寫入上下文。然後 handoff 到 Flight Information Agent。
這裏有三個設計點在起作用：Triage Agent 的路由判斷、工具調用填充上下文、handoff 傳遞完整信息。
第二步，診斷。 Flight Information Agent 調用 flight_status_tool，發現 PA441 因天氣延誤 5 小時，預計 19:55 起飛。系統計算後發現，這會錯過在紐約的轉機航班 NY802。
這裏體現的是：Agent 不只是回答狀態，而是在執行業務判斷：它需要知道延誤會導致錯過轉機。
第三步，找方案。 Flight Information Agent 調用 get_matching_flights，找到兩個備選航班：NY950（第二天 9:45，座位 2A）和 NY982（第二天 13:20，座位 3C）。
注意這裏有一個細節：兩個備選航班的座位信息已經有了。這就為後續自動改簽和選座鋪好了路。
第四步，執行。 Flight Information Agent 把結果 handoff 給 Booking & Cancellation Agent。Booking Agent 直接調用 book_new_flight，改簽到 NY950，座位 2A。
這一步是關鍵：用戶沒有說幫我改簽，Agent 主動做了。因為上下文裏已經有了所有需要的信息（確認號、當前航班、備選航班），Agent 不需要再問一遍「要幫你改嗎」。
這個設計的來源是 prompt 裏一句指令：「數據齊全時自動串聯工具，不要每一步都停下來問用戶」。
第五步，特殊需求。 用戶提到有醫療原因，需要前排座位。Booking Agent 把這個需求 handoff 給 Seat & Special Services Agent。Seat Agent 調用 assign_special_service_seat，分配了 1A。
這裏有一個隱式的上下文傳遞：改簽後的航班信息已經在上下文裏了，Seat Agent 不需要再查一遍。
第六步，補償。 用戶抱怨過夜延誤。Seat Agent handoff 到 Refunds & Compensation Agent。Refunds Agent 調用 faq_lookup_tool 查了補償政策，然後調用 issue_compensation，創建補償 case，發放酒店券（最高 180 美元）、餐券（60 美元）、地面交通補貼（40 美元）。
注意：Refunds Agent 只調了 FAQ 工具查政策，它沒有 FAQ Agent 那麼受限，它可以查政策和發補償兩件事都做，但改簽和改座絕不碰。
整個流程走下來，用戶看到的是：一個客服全程幫他解決了延誤、改簽、選座、補償。而 Agent 內部經歷了 4 次 handoff（Triage → Flight Info → Booking → Seat → Refunds），調用了 6 個工具（查行程、查狀態、找備選、改簽、特殊座位、查政策 + 發補償），上下文被更新了多次，每個操作都有工具權限約束。
這哪是在回答問題，這明明是在多個業務系統之間跑流程。
生產落地還差什麼
拆完之後，必須說一句：這個 demo 明確標註了是演示用途，不是生產系統。客觀指出它的不足，比一味吹捧更有價值。
1. 真實系統集成。 Demo 裏所有業務數據都是 mock 的。生產環境需要對接 CRM（客戶管理系統）、訂單系統、工單系統、支付系統、庫存系統、用戶身份系統、權益系統。每一個對接都是真實工程量的來源。
2. 持久化。 當前用 in-memory store（內存存儲，服務重啓後數據全丟）。生產需要數據庫、會話存儲和完整的審計日誌。
3. 權限體系。 Demo 沒有用戶認證，沒有區分用戶、客服、管理員、系統角色。真實客服系統裏，用戶看到的數據、Agent 能做的操作、管理員能看的日誌，是三層不同的權限。
4. 高風險操作確認。 取消訂單、退款、修改個人信息這類操作，demo 裏 Agent 可以直接執行。生產中需要二次確認、額度限制和審批流。
5. 人工接管。 Demo 裏沒有人類客服接管的機制。真實客服系統必須設計轉人工的條件：連續 N 輪無解、情緒識別、投訴關鍵詞、高價值用戶、賠付爭議。
6. 錯誤處理。 真實系統會遇到 API 超時、返回異常數據、庫存變化、支付失敗、併發衝突。Demo 裏工具都是同步 mock，不存在這些問題。生產需要重試、回滾、冪等設計。
7. 評估體系。 怎麼知道這個 Agent 做得好不好？只看對話記錄不夠。需要建立一套指標：問題解決率、轉人工率、誤操作率、平均處理時長、客戶滿意度、賠付成本。而且要區分 Agent 的問題和業務系統的問題。
8. 行李 Agent 缺失。 代碼裏有 baggage_tool，prompt 裏多次提到 Baggage Agent，但實際沒有定義和接入獨立行李 Agent。說明這個 demo 自己也沒做完。
所以如果要用這套樣板做企業客服 Agent，補齊順序應該是：先接真實數據源（讓 Agent 有用），再做持久化和審計（讓系統可靠），然後上權限和確認機制（讓系統安全），最後建評估體系（讓系統可度量）。
最後
回過頭來看這個 demo，它展示的不是一個客服聊天機器人，而是一個 Agent 操作系統的雛形。
路由層（Triage + Handoff）決定這件事交給誰辦 執行層（Tool calling）決定能辦到什麼程度 狀態層（Context）保證辦事過程中不丟失信息 保護層（Guardrails）防止不該辦的事被辦了 觀察層（Agent View + Runner Output）確保出了事能查到為什麼。
這五層裏，大多數企業現在只關注了聊天體驗那一小塊。
真正難的不是接入大模型。ChatGPT 的 API 調通只要五分鐘。真正的難點是把企業內部系統封裝成安全、可控、可審計的工具，讓 Agent 既能把事辦了，又不會辦出事。
OpenAI 這個 demo 給了一個可參考的起點。它不完美，但它至少說清楚了一件事：企業客服 Agent 不是更聰明的 FAQ，而是一套能被自然語言驅動的業務流程系統。
下一步，就看誰先把這五層落進生產了。