[讀者回函] 看懂物流、結算層與 Agent 市集的真終局：Agentic App Store 在物流業怎麼長
Skin Deep: Why an Agentic App Store in Logistics Is a Ledger Problem, Not a Shop Problem
序言：如果你想看懂 Agentic App Store 的終局，別看 GPT Store，去看每天都在處理算錯帳、派錯車、違反 SLA 的出行與物流業。
作者補充：討論 AI Agent 的未來時，多數人看的是前端的對話能力與市集外掛。但把目光轉向物流車隊、維修派單和跨境運輸，Agentic App Store 的真實形狀才會顯現出來。在那裡，Agent 的錯誤會直接導致真金白銀的賠償。
本篇收斂兩條軸線：投資人看層級與退出，營運者看結算與究責—同一個標的，兩套時間尺度。
為什麼是物流，而不是另一個聊天場景
Agentic App Store 不會先在最泛用的消費端對話成熟，而更可能先在出行、運輸與物流這類 高頻、可量化、可審核 的場景長出第一批可持續的 B2B 市場。原因可以拆成三點：
任務結構清楚：從 last-mile routing、dispatch、field service，到承運商配置與退貨，都能拆成可觀測的 decision loop。每一次路線、派工、改派、選承運商、結算與例外處理，都直接對上成本、SLA、燃料、人力與客訴。
Agent 若能嵌進決策鏈，就不只是「省一點工」，而是有機會成為 operational control point。
多工具整合剛好是協議層的位子：地圖、GPS、ERP、TMS、WMS、CRM、客戶通知、承運商 API、支付與保險—這些節點正是 connector、plugin、MCP 這類「能力封裝」最該發揮之處。
平台演進上，「插件＝skills＋整合＋MCP server 的安裝單位、再用 marketplace 分發」已從概念變成產品語言；若投影到物流，路線優化、技師技能匹配、承運商選擇、中斷處理、ETA 溝通等 高頻能力，天生適合做成垂直 agent module，再由工作台式平台統一調度。
信任邊界較容易用數字建立：物流裡的決策幾乎都能對上成本與結果，比起純內容生成或泛用辦公助手，企業與使用者較能定義「什麼叫做對」。這裡賣的不是聊天能力，而是 可被審核、可被治理、可被計費的營運決策。
市場對 AI 新創的判準已經拆成兩套：一邊追「超高速成長與單位經濟」，一邊追「是否咬得住真實營運預算」（Bessemer Venture Partners, 2025）。
垂直 AI 敘事常強調能否對到 勞動力與營運成本池（調度、客服、現場例外），而不是只卡在 IT 或創新預算 的採購上限—這會直接影響天花板與估值倍數。
Dispatch 類產品若真能替代或大幅縮減調度員、客服、值班經理的反覆判斷，價值就不再只是「軟體效率」，而會更接近 operational labor replacement。
能力怎麼打包：Skill、瀏覽器外掛、Connector、MCP，以及五階梯策略
讀到這裡如果不把「上架單位」講清楚，很容易把 App Store 想成只有一種形狀。實務上，物流／出行場景會同時出現好幾層 封裝，它們的 權限邊界、審計粒度、計價方式 都不同；短期待辦與 長終局 也不一樣。
幾種常見「安裝單位」各管什麼
Connector：偏向 純資料與 API 對接—把 TMS、WMS、承運商、地圖、通知通道接進同一條管線。沒有 agent 也能叫 connector；重點是有沒有 穩定 schema、錯誤語意、重試與稽核欄位，而不只是「能連上」。
Skill（各家命名不一：skill file、指令包、可版控的 playbook）：偏 人類可讀／可分享的「怎麼做」；好處是迭代快，壞處是 容易被複製或蒸餾—上公開市集前，要想清楚 更新頻率 與 組合性 是不是護城河。
瀏覽器外掛／Browser plugin：掛在 瀏覽器執行環境，擴充的是 人的觸點 或 半自動迴圈（表單、後台、追蹤頁）。它跟 MCP 的差別往往不是「誰比較潮」，而是 信任邊界：cookie、站點隔離、可見 DOM、是否繞過既有 API 合規—治理上常更像「shadow IT」與正式 connector 的拉扯。
MCP（Model Context Protocol）：Anthropic 2024 起推的 開源協議面，讓 agent 用相對標準的方式 發現工具、呼叫工具、帶上下文（Anthropic, 2024）。它解決的是 互通與整合成本，不自動解決 授權語意、計價、究責—後三者仍要落在結算層。
Plugin 作為「一鍵安裝單位」：平台產品語言正在把 skills、既有 app 整合、MCP server 收成 同一個可上架、可版本管理的 plugin，再走 marketplace 分發（典型如開發者工具鏈的敘事）。
對物流的含義是：路線、承運商選擇、中斷處理、ETA 溝通等高頻能力，適合做成可被工作台式 agent 統一調度的模組—但 調度權與帳本 仍誰屬，要另議。
五階梯：你此刻在賣第幾格、證據又到第幾格
專欄裡反覆用的一條軸是：Connector → MCP → API → SaaS → Platform。
實務上 多數新創 pitch 在 Platform（第 5 格），可是證據只到 Connector–MCP 或 API–SaaS（約第 2–3 格）—這就是投資人「第四道閘」要對齊的原因。對 亞洲非中國 團隊，常見 較健康的賭注 是先在 MCP + 可計量 API 兩格站穩（組件化、客戶甚至可以是潛在競對）；硬爬成全套 SaaS 往往正面撞上垂直寡頭與中國完整套件。
雲端 marketplace：短期到長期，該期待什麼
短期（約 0–18 個月）：目標通常 不是「做一個公開下載的物流 App Store」，而是 讓自己有資格 談市集—Connector／MCP 上線、可被審計的 action、少數 design partner 的營運閉環。
公有雲上的 agent runtime（例如 Bedrock Agents、Azure AI Foundry、Vertex Agent Engine 等產品線）與附帶 目錄／市集，提供的是 算力、執行容器、上架通道；它們 普遍缺乏 終端履約網路與消費者觸點，比較像 賣鍋鏟與櫥窗 給上面四類玩家（運力平台、OTA、Orchestration、垂直 SaaS），而不是自己變成 出行層級的 App Store 主控者。
中期（約 18–36 個月）：第一個垂直 wedge 跑通後，較典型路徑是 同一批付費客戶 橫向加第二個 wedge（同一帳戶體系與稽核欄位），再開 curated marketplace（精選少量插件、強治理），比一次對全世界開房間安全。
長期（約 36 個月以上）：當 settlement layer（身分、審批、帳本、結果驗證、分潤、責任切分）真的接上 企業採購與審計，雲端或垂直平台的 marketplace 才從 插件目錄 變成 可交易的市場。
產業敘事常提到 雲市集對交易／上架抽成落在單位數到十幾個百分點區間（按品類、是否走下單閉環、是否綁企業採購合約而差很大）；對你真正該問的是—抽成扣在誰能把「授權＋計價＋究責」閉環寫進合約與產品。
三層地圖：誰在吃哪一種預算、誰站得到結算層
出行／物流的 Agent 應用，在市場成熟度上大致沿三條路徑長出來；對投資人而言，這不只是分類，而是 護城河形狀、預算來源、退出方式，以及未來能不能長成「垂直版 Agentic App Store」的差異。
Route Planner：最快驗證價值，也最先被壓縮
這一層回答「今天怎麼跑」：多站點、多車輛、多時間窗底下，壓里程、拉準時率、減少人工排程。市場上 Route4Me 等產品早已不只做路線，而是把 planner、dispatcher、司機與管理者的工作流串進同一層，顯示 單點工具正在往平台模組滑。
OptimoRoute 等在 SMB 配送場景與前者直接競價，第三方評測也常在 Route4Me、OptimoRoute、Onfleet 這類名單裡做比較—客戶眼中 可替換性很高。
投資邏輯上，這層 ROI 好講、導入快（少跑多少里程、少加多少班、排程少花多少時間），但長期容易 被商品化，或被上一層平台 內建成 feature。
除非握有強垂直籌碼（區域交通資料、冷鏈／醫療約束、極端成本算法＋執行閉環），否則結局多半是：往上爬成 dispatch／orchestration，或 被平台與物流巨頭收編。
從 結算層 來看，Route Planner 通常只掌握局部任務—路徑排序、ETA、排程建議—交易面與例外處理面不夠大，很難自然變成整個生態的 settlement owner。除非刻意往承運商選擇、派工執行、客戶通知延伸，否則仍停在 很強的功能層，而不是「平台秩序」。
Dispatch Platform：最先變成工作台的地方
這一層開始回答「誰去跑、什麼時候出發、遇到例外怎麼重排」。
Autofleet 公開的 field service routing 敘事很典型：系統同時吃 appointment window、班表、服務時長、設備條件、客戶優先級、SLA、急件，再透過 API、webhook、司機端、追蹤連結與自動化溝通，把決策推進執行層。
LogiNext 類產品則把 autonomous dispatch、儀表板、司機指派、客戶溝通與動態改派 收在同一套持續運轉的流程裡—dispatch 已是 decision engine，不是單一功能。
它和傳統 SaaS 的差別不在「多一張報表」，而在 系統逐步吃掉你每天現場做的 operational judgement；且天然需要 human-in-the-loop：工單、位置、交通、司機狀態與 SLA 即時進站，系統建議或局部自動執行，人在高風險與例外時覆核。歐盟主管機關對自動化決策的提醒在這裡特別尖銳：人類監督是否有效，取決於監督者看不看得到前序決策脈絡；若核准介面只剩「同意／否」而沒有脈絡，治理會流於形式（European Data Protection Supervisor, 2025）。
這一層 整合深、銷售週期長、責任切分與治理設計要求高；一旦出錯，代價可能是 SLA、客訴、加班甚至安全。投資人若要在這層下注，無法只聽故事，而要追：自動決策比例、哪些動作必須人工批准、錯誤如何回退、是否有足夠深的 operational data 閉環。
從結算層來看，Dispatch 是第一個真正有機會長出 execution ledger 的層級：每次派工的建議、批准、變更與結果若被記下來，你其實已經在養 帳本；再往下一步才是 third-party module 的計價 與 責任切分。
Logistics Orchestration：終局雛形與最可能的「戰略收編」
這一層把 多倉、多車型、自營與外包、多承運商、carrier management、可視性、動態改道、結算與永續追蹤 一起編排。
業者對外常描述的「階梯式改善」敘事是：先做 dispatch 與路線優化 → last-mile 成本常聽到約 10%–15% 量級的目標；再掛 可視性與承運商管理 → mid-mile 8%–12%；最後進 full orchestration（動態改道、多式、永續追蹤）→ 累積可超過 20%—這類數字應讀作 銷售與方法論敘事，不是鐵律，但足以說明 為什麼客戶願意把「營運中樞」交出來。
這層開始具備平台的兩個條件：control point 與 modularity。當 orchestration 成為企業物流的中樞，平台就能定義插件邊界—承運商競價、關務／合規、倉儲 slot、例外處理、對帳等。
真正的企業級 Agentic App Store 未必從公開商店開始，而更可能是 先在 orchestration 內部長出插件結構，再對合作夥伴與開發者逐步開放。
缺點也明顯：資本密集、靠近核心營運；一旦價值被證明，獨立 IPO 往往不是預設劇本，而是 IKEA、FedEx、Element Fleet、Uber Freight 這類戰略買家的收編標的—對基金而言，這可能是 高價戰略併購，而不是長年公開市場複利。
在結算層意義上，Orchestration 最接近終局：多承運商、多流程、跨部門指令一進來，多方交易與多方責任 會把 settlement 的必要性拉到最高。
橫向 × 中度深度的「死亡地帶」
若把 業務廣度 與 整合深度 放在同一張圖上，又橫向、又只有中等深度 的產品往往最難落腳：不像純 Route Planner 可明確當 feature 賣，也不像深耕單一垂直的 dispatch 可吃到勞動力預算，更不像 orchestration 能賭戰略價值。
缺乏營運資料閉環、又沒有垂直護城河 的橫向工具，最容易在 2026 年的嚴格判準下被掃出場。
商店是皮，結算層是骨：真正的順序是 control layer → market layer
從皮相上看，Agentic App Store 很容易讓人聯想到 GPT Store、plugin marketplace、Salesforce AgentExchange 這類「安裝能力」的入口—它們共同說明：模型平台與企業工作流一旦穩定，市場會要一個分發位。
但物流與出行的第一個難題不是 discovery，而是 trust：你能不能交代清楚「這個 plugin 能碰哪些資料、能下哪些指令、誰批准、怎麼留 log、做錯誰負責」？若答不出來，再漂亮的開發者計畫也很難變成 enterprise adoption。
這個領域的合理 順序 是 先有 control layer，才有 market layer。
企業軟體裡這不新奇：AWS Marketplace、Salesforce AgentExchange 的價值不在「長得像商店」，而在它們站在既有 帳號、採購、治理、權限與計費 之上。
物流與出行要複製的，是 可被企業接受的治理與交易基建，而不是 iOS App Store 的類比。
結算層（settlement layer）至少五塊
在此 結算 不只是金流分潤，而是讓多方 agent／plugin 能 協作、被授權、被計價、被究責 的底層秩序：
Identity & permissions：每個 agent、plugin、connector、人類操作者在租戶、站點、車隊、承運商或工單範圍內的授權。能不能看全地址、能不能改路線、能不能改派、能不能觸發退款或折價，都不該是灰區，而是精準的 action scope。
Execution audit：建議了什麼、最後執行了什麼、誰在何時批准、下游回傳什麼—要能還原。沒有審計，客戶不會把高價值動作交給平台，企業也不敢拉高自動化比例。
Result verification：不能只看模型聲稱完成；要有可對帳的 outcome—ETA 是否在 SLA 內、派工是否進下游系統、承運商是否接住訂單、通知是否送達、現場是否簽收。沒有這層，就很難用 action／result 計價，也很難對第三方模組做 依真實營運結果的排名。
Pricing & revenue split：若真有第三方技能，平台要知道 哪些模組參與了任務、哪一步創造價值、抽成與計價是 seat、action、成功結果、省下的成本，還是 enterprise 合約分帳。沒有這一層，marketplace 往往淪為 免費插件櫃。
Liability partitioning：做錯時 平台、第三方 skill、承運商、現場或客戶設定 誰扛—若產品與合約沒寫清楚，就很難走向 規模化交易。
{合作廣告}
🧑🎓 UX 訂閱制學習計劃：把 human-in-the-loop 變成你的日常。這也是我會特別推薦 #UX訂閱制學習計劃 的原因：它不是一次性的 bootcamp，而是把借位、補位、入位拆開來，串成 3 月到 12 月的一條學習軸線。透過每月 Podcast 和專欄，先向不同領域的 UX / 產品 / AI / 服務設計講師「借位」
透過直播與 Circle 社群討論，在你的真實案子與問題上進行「補位」
