阿里千問 vs 字節豆包：當 AI 開始“點外賣”，Agent 的 0-1 終局已定？

阿里千問正在重新定義AI Agent的商業化路徑——不只是對話式交互的優化，而是直接打通底層業務流的權限壁壘。本文通過外賣場景深度拆解，揭示千問如何用3秒綁定的‘主場優勢’、意圖直達的決策短路、以及復雜參數的無損映射，完成字節豆包未能突破的0到1跨越。

———— / BEGIN / ————

阿里千問完成了字節豆包手機沒有完成的0-1。

“這不再是簡單的功能堆砌，而是交互邏輯的倒置：Agent 正在從一個‘對話框里的搜索引擎’，變成一個‘擁有業務權限的數字代辦’。”

此前，豆包也曾嘗試跨越這道門檻，卻因生態兼容和第三方阻斷而折戟。

而擁有地圖、外賣、購物全產業鏈的阿里，正在用千問展示一種“降維打擊的履約壁壘”：當 AI 能夠直接調動自家底層業務流時，“這種基于底層業務協議（Protocol）的直接調用，徹底殺死了第三方插件不得不面對的‘響應延遲’和‘跳端損耗’”。

其他廠商該如何追趕？是去做適配器，還是重新審視生態鏈？本文將深度拆解千問點外賣背后的 Agent 落地邏輯。

交互初體驗：從“搜索選擇”到“意圖直達”1.1 前置動作：權限委托的“一鍵化”記錄

在 Agent 的產品邏輯里，如果說大模型是“大腦”，那么垂直業務的 API 授權就是“入場券”。沒有這張票，Agent 表現得再聰明也只能是“紙上談兵”。

A.喚醒與觸發：從意圖到插件的“無縫握手”

不同于以往需要去插件市場手動“安裝”，千問對淘寶閃購/外賣能力的調用是意圖驅動的。

操作記錄：作為一個被各種‘由于政策原因無法訪問’彈窗虐過的產品經理，當我輸入‘想點外賣’時，千問給出的不是冷冰冰的鏈接，而是一個權限委派的‘確認按鍵’，這種交互的‘確定性’才是 Agent 真正落地的開始。”

PM 視角：這解決了 Agent 落地的一大難題——發現成本。用戶不需要學習如何開啟 Agent，意圖識別（Intent Recognition）直接完成了功能分發。

B. 綁定流程：阿里生態的“主場優勢”

這是整場測評中，最體現“親兒子”特權的地方。我記錄了整個綁定路徑，耗時僅需 3秒 左右。

C. 核心博弈：為什么極低的“摩擦成本”才是 Agent 落地的分水嶺？

作為產品經理，我們必須看透這個簡單“勾選”動作背后的硬核壁壘。在 2026 年，所有人都知道 Agent 強在邏輯推理，但落到實處，它更強在 API 背后那張“數字身份證”。

• 賬號體系的“免死金牌”：通義千問之所以能秒開下單，是因為它直接跳過了移動互聯網時代最令人煩躁的“驗證碼循環”。阿里底層賬號的打通，意味著用戶在千問里的一句話，能瞬間調動他在淘寶沉淀了十幾年的收貨偏好和支付信用。這不僅是數據的流動，更是特權級的訪問效率。

• 心理安全區的合圍：跨集團的信任成本是極高的。想象一下，讓用戶在抖音里綁定一個美團賬號，那種“信息被轉賣”的疑慮會直接勸退 50% 的轉化。而在阿里生態內完成閉環，用戶感知到的是原生系統的安全性，這種天然的心理舒適區，讓原本復雜的授權變得微不足道。

• 確定性交付：拒絕“脆弱的自動化”：很多廠商嘗試用 RPA（模擬點擊）去做 Agent，這在演示時很酷，但在實操中是運維噩夢——一個隨機彈出的雙 11 活動頁或驗證碼就能讓流程瞬間崩潰。而原生綁定的千問擁有“白名單級”的 API 訪問權，這種“VIP 通道”保證了即便在大促期間，下單流程依然穩如泰山。

本章小結

> “別總盯著參數看。千問的 3 秒綁定告訴我們一個扎心的事實：Agent 能跑多遠，不看大腦（模型）多聰明，先看雙腳（賬號和權限）踩得夠不夠實。”

> 這一步走得順不順（摩擦力是否足夠低），直接決定了用戶在“點外賣”這種高頻場景下，是選擇享受便利，還是在第二次看到登錄框時就憤而卸載。

1.2 交互初體驗：從“搜索選擇”到“意圖直達”

如果說綁定賬號是“入場券”，那么真正的交互體驗就是 Agent 的“基本功”。在傳統 App 中，我們被訓練成了“搜索專家”；而在千問里，我們正在變成“指令官”。

A. 路徑簡化：決策鏈路的“短路”

在傳統的 GUI（圖形用戶界面）下，點一次外賣意味著從用戶心理出發。

可以改為：“以前點外賣是在做‘選擇題’（面對幾百個商家），現在千問試圖幫你做‘判斷題’。這種從‘列表式’向‘結論式’的進化，本質上是把決策的心理壓力甩給了模型。”

傳統路徑：打開 App -> 首頁彈窗干擾 -> 搜索 -> 滿減/評分篩選 -> 進店選品 -> 確認結算。

千問路徑：輸入意圖 -> 彈出確認卡片 -> 支付。

PM視角：這本質上是將“選擇權”讓渡給“算法預過濾”。千問不再提供一個長長的列表，而是嘗試給出一個“最優解”。

B. 實測案例拆解

總結：千問在參數對齊能力出色，且通過“全網搜券”為用戶提供了實打實的體感價值，但是在交互上，僅提供單一選項，且缺乏顯性的推薦理由，易引發用戶的“踩雷”焦慮。技術上復雜任務邏輯斷層，無法完成，復雜任務（預約點餐），存在逆向流程的盲區，無法完成售后任務。

案例 1（紅榜）：基礎指令

在 Agent 的設計中，當用戶給出“我想喝杯奶茶”這種極度模糊（Ambiguous）的指令時，是對系統預過濾能力最大的考驗。

指令內容： “我想喝杯奶茶。”

交互表現： 千問幾乎在秒級時間內直接生成了一個具體的訂單卡片（例如：奈雪的茶 – 霸氣葡萄）。

效率看板：

• 路徑壓縮： 傳統 App 需要經歷“搜索-比價-選店-選品-加購”約 6-8 次點擊；Agent 模式下縮減為“輸入-確認”2 步，操作步數節省約 60%。

• 響應速度： 極快，省去了加載海量信息列表的白屏時間。

【作者總結：PM的批判性思考】

“雖然 2 步下單的爽感很足，但作為PM，我的第一反應是：‘憑什么推薦這家？’。如果 Agent 的邏輯只是在附近商家中隨機選一個，這不叫人工智能，這叫‘抽獎’。好的 Agent 應該是決策的翻譯官，而不是替用戶做主的獨裁者。”

雖然“2 步下單”的路徑壓縮在體驗上極度絲滑，但從產品深層邏輯審視，這種極致的效率掩蓋了一個致命的“信任黑盒”問題。

作為 PM，在驚嘆于響應速度的同時，我們必須保持警惕：

1. 推薦理由的缺位（Transparency）

通往下單的最后一公里是“信任”，而非“速度”。 通義千問直接給出的單選卡片缺乏“Why this”的解釋：

– 是基于我昨天的歷史訂單？

– 是基于該店發貨最快、距離最近？

– 還是全城銷量最高的爆款？

產品經理視角：缺乏透明度的推薦在用戶眼中往往等同于“強買強賣”。這種信息缺失會極大地拉高用戶的確認成本，甚至引發“算法陷阱”的疑慮，導致用戶為了求穩而跳回傳統 App 重新搜索。

2. 單一解的博弈：獨裁式交互的風險

奶茶是典型的“情緒化+多樣性”品類，只給一個選項往往無法命中真實意圖。

目前 Agent 的邏輯是“我猜你想要”，這是一種典型的“獨裁式交互”。

更合理的路徑應該是“聚合推薦 + 極簡 A/B 選單”：

– 優化邏輯： 給出“你常喝的（復購偏好）”與“附近最火的（潮流偏好）”兩個對比項。

– 核心價值： 通過增加 0.5 步的微操，用極低的認知成本換取極高的決策確定性。

3. 信息密度（Information Density）的失衡

減少操作步數 ≠ 犧牲決策信息。

目前的卡片信息（評分、月售、距離）過于精簡。在點外賣場景下，用戶的核心痛點是“快”與“不踩雷”的平衡。當 Agent 過濾掉過多的商家背景信息時，用戶實際上是失去了風險評估的能力。

案例 2（紅榜）：進階指令——多目標意圖下的“精細化參數對齊”

如果說“點杯奶茶”是基本功，那么“多份訂單 + 不同定制參數 + 特定地址”的組合指令，才是 Agent 真正能稱之為“辦事助手”的分水嶺。

測試指令： “幫我點 3 份去冰不加糖的伯牙絕弦，再要一份少糖的茉莉奶綠，送到公司前臺。”

千問表現：

• 前置地址校驗：第一時間反饋當前默認地址（XX 樓），并提供修改入口（安全確認邏輯）。

• 復雜 SKU 映射：準確提取了 2 個品類、4 個維度的參數（份數、冷熱、甜度）。

• 自動尋優執行：觸發淘寶閃購底層搜索，并在話術中體現“優先推薦附近門店”與“自動疊券”。

評價等級：優（進階功能）

效率看板：從“手動擋”到“全自動”

【作者洞察】：語義到參數的“無損壓縮”

1. 履約邏輯的深度拆解：為什么這很難？

在 2026 年，大模型聽懂“伯牙絕弦”這種專有名詞已經不稀奇了。真正的難點在于將模糊的自然語言強制映射為業務系統的硬性參數。

難點在于：系統后臺的 SKU 規格通常是成百上千的 ID 組合。

Agent 需要在理解“去冰不加糖”的同時，精準勾選后端對應的那條唯一屬性路徑，并同步計算門店庫存。

這背后不是簡單的聊天，而是語義（NLP）與業務接口（API）的強耦合。

2. “省掉 4 次點擊”的體感差

我們常說的“驚喜感”，本質上是用戶操作鏈路的劇烈壓縮。

在傳統 GUI 界面中，用戶為了省幾塊錢，往往要在各個頁面領券、比對滿減。

“這才是 Agent 的迷人之處：它把‘找券比價’這種折磨人的活兒變成了后臺靜默執行的插件，讓用戶只負責‘確認’，剩下的交給算法去薅羊毛 。”

這種“自動找券”帶來的不是虛幻的心理滿足，而是實打實地讓用戶跳過了繁瑣的營銷套路，直接拿到了最優解。

3. 確定性驗證（Verification Layer）

千問在執行前先確認地址并提示“點擊修改”，是一個非常成熟的 Safe-Guard（安全護欄） 設計。在涉及金錢與位置的場景下，Agent 不應追求“一步到位”的魯莽，而應在關鍵節點留出人工確認的窗口，防止“高效地辦錯事”。

4. 進化方向：UI 層的明細透明化

雖然內核表現優秀，但目前的 UI 反饋仍有提升空間。

建議在生成的訂單卡片上，直接標注出每份奶茶的具體定制明細（如：伯牙絕弦 x3 [去冰/不加糖]）。這樣用戶無需點擊進入詳情頁，就能完成最后一步的確定性驗證，進一步降低確認成本。

案例 3（黑榜）：語義沖突 —— 理解力在“非標準定義”下的失效

本案例旨在測試 Agent 處理用戶矛盾心理（既要……又要……）的深層推理能力。

指令還原

用戶指令： “我想吃點重口味的，但又不想長胖。”

測評表現：差（邏輯斷層）

執行失誤：Agent 雖能識別“重口味”與“低熱量”這兩個對立標簽，但在篩選邏輯上極其敷衍。它機械地將商家的“少油”標簽簡單等同于“低熱量”，并未考慮重口味帶來的高鹽、高醬料等隱形成分。

反饋結果：推薦的菜品既無法滿足用戶對“重口味”的心理補償，也未達成真正的“減脂”目標。

作者洞察：從“聽話”到“思考”的鴻溝

核心痛點：這里暴露了 Agent 目前最大的軟肋 —— 它在“聽話”，但沒在“思考”。

– 感性矛盾的理解缺失：用戶說出“重口味但不長胖”時，本質上是一種感性訴求與理性節制的對抗。

目前 Agent 的推理路徑過于線性，僅停留在標簽匹配（Tag Matching）階段。它會對著“低脂”標簽生搬硬套，這種“為了執行而執行”的邏輯，往往會推薦出一些讓用戶哭笑不得的方案（如：一份索然無味但貼著輕食標簽的冷餐）。

– 知識圖譜的薄弱點：Agent 缺乏對營養學常識的底層推理。在它眼中，“重口味”和“低熱量”是互斥的兩個點，因此它選擇犧牲一方或折中處理。

真正的“思考”應該是基于垂直領域知識圖譜，尋找能夠平衡兩者的帕累托改進方案（例如：高蛋白且富含天然辛香料的烤魚，而非單純的少油水煮菜）。

優化建議：構建“常識推理”引擎

– 深化垂直知識庫：引入更細粒度的營養學與烹飪知識，不再僅僅依賴商家的營銷標簽。

– 引入“用戶意圖解碼”：當檢測到用戶指令存在語義沖突（Conflict）時，優先進行“需求分級”，判斷用戶是更想解饞（重口味）還是更在意健康（不長胖），從而給出帶有解釋性的建議。

案例 4（黑榜）：Agent 是否具備“糾錯”與“回滾”能力？

如果說“幫我點單”體現的是 Agent 的執行力，那么“我不想要了，幫我退掉重買”考驗的則是 Agent 對業務狀態機（State Machine）的感知與干預能力。

測試指令： “在讓通義千問買了一杯咖啡后，要求：把它退了，買個新的。”

千問表現：差（無法處理售后閉環）。

執行失誤：“千問在‘搞破壞’（退款）這件事上還是顯得束手無策。它抓住了‘買新的’這個增量意圖，卻對‘退舊的’這種逆向業務流程選擇了裝傻 。” 它完全忽略了“退掉上一單”的指令，雖然捕捉到了“買新的”意圖，但給出的推薦（如冰美式）并非用戶想要的特定類型，且無法直接觸發已完成訂單的退款接口。

反饋結果：只是簡單詢問“要直接下單嗎？”，并未處理核心的退單訴求。

【作者洞察】：為什么“退款”是目前 Agent 的無人區？

通過這個案例，我們可以點出當前 AI Agent 落地最核心的痛點：這不完全是技術問題，更是“權力問題”。

業務邊界：權限與安全護欄（Security Guardrails）

下單是“支付流”，API 只需要完成單向寫入；而退款涉及“資金回退流”，是極其敏感的資產風險操作。

– 權力隔離：阿里顯然給 Agent 設置了極高的安全護欄。目前插件體系開放的權限大概率是“只讀”或“單向寫入”。

– 產品經理視角：在現階段，把涉及資產回流的操作交給 Agent 還是太激進了。

這種“高風險”操作目前仍被嚴格隔離在模型之外，必須由用戶手動跳轉到 App 內操作，這是為了防止誤操作導致的資損。

業務顆粒度的斷層：狀態機的黑盒

退款流程在后臺涉及復雜的業務判斷：商家是否已接單？是否已出餐？是否已配送？每一個狀態對應的退款邏輯和“撕逼”成本都不同。

– 信息差：目前的 Agent 顯然還沒能深度實時讀取訂單的完整生命周期狀態。它能幫你“跑腿”，但還沒學會處理“異常狀態”。

復雜任務的優先級沖突與確定性體驗

在處理組合指令時，千問選擇抓住更容易實現的“買新的”，而放棄了邏輯復雜的“退舊的”。

優化建議：

作為產品經理，我們需要思考：當 Agent 無法處理其中一個環節時，它不該“裝傻”或“選擇性執行”。誠實地告知用戶“我無法處理退款權限，請手動操作”并提供跳轉鏈接，才是更具確定性的用戶體驗。

案例 5（黑榜）：預約執行徹底翻車——只會“找得快”，不會“定得準”

這個案例旨在測試 Agent 是否具備強時間約束（Deadline）下的任務調度能力，以及它能否區分“搜索篩選”與“預約閉環”這兩個本質不同的業務動作。

測試指令： “我 17 點有個會，幫我訂一份 17:45 送到的輕食。”

千問表現： 差（典型的邏輯對沖）。

執行失誤： Agent 識別到了 17:45 這個時間點，但它在調用工具時，腦子里只有“搜索”和“篩選”，沒有“預約”這個原子能力。它試圖通過篩選“15分鐘內出餐”的商家，利用“出餐快”來強行對沖時間差。

在 PM 眼里，這屬于用“概率”去賭“確定性”，是典型的邏輯補丁。

【深度復盤：為什么說這是“AI 味”的失敗？】

1. “意圖與能力的錯位”

這里不是語義理解的問題，而是原子能力缺失。

Agent 將用戶的“預約意圖”降級處理成了“關鍵詞檢索”。它能理解你需要準時，但它的工具箱里沒有對接外賣平臺的預約 API，導致它只能在搜索環節“打補丁”，試圖靠縮短出餐時間來撞大運。

2. “搜索邏輯”無法覆蓋“履約閉環”

目前 Agent 更像是一個高級搜索引擎，而非真正的執行助理。

在處理外賣這類涉及三方配送（Logistics）的場景時，它完全忽視了配送距離、騎手調度等變量，僅靠“標簽匹配”給出的方案在現實中極易延誤。

這種“看似可行、實則無保障”的反饋，直接殺死了用戶的信任感。

3. 產品策略的進階方向

從“語義理解”轉向“業務專家” 針對這類任務導向（Task-oriented）的場景，優化方向不應是微調提示詞（Prompt），而是深度對接業務接口：

– 觸發式調用：當識別到明確的“送達時間”時，邏輯流應優先鎖定“預約單”API，而不是進入常規的商家篩選流。

– 變量前置：在推薦結果前，必須先將“起送時間+預計配送耗時”作為硬性過濾條件，而非把出餐速度當成唯一的救命稻草。

技術落地拆解：阿里巴巴全生態鏈條下的 Agent 進化論1. 為什么贏的是阿里？—— 資產的“顆粒度”決定了 Agent 的“絲滑度”

別被“生態”這個大詞唬住了，阿里的核心護城河其實就兩個字：“權限”。

當 Kimi 或豆包還在費勁地琢磨怎么用 OCR 繞過驗證碼、模擬真人點擊屏幕時，通義千問已經在后臺完成了底層協議的握手。這種“原子化資產”的重構，讓阿里在 Agent 時代完成了從“外掛”到“原生”的進化：

• 從“模擬點擊”到“協議握手”： 競品在教模型“如何像人一樣用 App”，而阿里是在教模型“如何直接調用數據庫”。當你說“點杯奶茶”時，千問不是打開餓了么網頁，而是直接向餓了么的供給端發送了一串代碼指令。

• UI 是累贅，權限是捷徑： 在 Agent 時代，華麗的界面反而是調用的阻礙。阿里將淘寶、支付寶、菜鳥拆解成了無數個最小化的 Atomic API。大腦（千問）調用肢體（履約網）時，跳過了所有視覺層，直接進入了執行層。

• 賬號體系的“信任平移”： 這種絲滑感源于阿里內部賬號的徹底擊穿。用戶不需要反復掃臉或跳出授權，基于支付寶的底層協議，Agent 在對話框內就完成了實名認證與支付清算。

產品經理視角：Agent 時代的競爭力，取決于“調用摩擦力”

傳統的 App 是封閉的“圍墻花園”，用戶是翻墻的人；而 Agent 時代的邏輯是：誰的摩擦力更小，誰就是入口。

• 從“功能集成”到“能力解構”： 我們不再把餓了么視為一個獨立 App，它被解構成三組原子：LBS（你在哪）、Shop_List（有什么）和 Order_Action（買單）。這種解構讓 Agent 可以像拼樂高一樣，在毫秒級時間內組裝出一次服務。

• 消滅“跳轉成本”： 轉化率的頭號殺手是“跳轉”。競品（如豆包、Kimi）在訂餐或購物時，往往需要喚起第三方 H5 或 App，每多跳一次，用戶流失率就增加 20%-30%。阿里的優勢在于“免跳轉的閉環”——你以為在聊天，其實你已經下單了。

• 解決“最后一公里”的支付僵局： Agent 落地最難的不是“想不想買”，而是“誰來付錢”。基于支付寶的支付協議，阿里 Agent 擁有了原生支付權。這種“信任平移”讓 Agent 真正具備了從決策到履約的完整民事行為能力，而不只是一個只會聊天的數字導購。

總結：“過去我們拼的是‘裝機量’，現在我們拼的是‘調用摩擦力’。當別人還在試圖理解UI界面時，我們已經通過協議級集成，把復雜的商業鏈路壓扁成了一次順滑的握手。”

2. 核心技術支撐：從“模擬操作”轉向“原子能力調用 (Primitives)”

阿里的邏輯非常務實：與其費勁教 Agent 像人一樣去“刷”App，不如把 App 拆碎成大模型能直接驅動的“原子組件”。 這種“去 App 化”的架構，本質上是把復雜的業務流轉變成了標準的數據交換。

1. 原生協議調用 (Function Calling)：業務邏輯的“確定性骨架”

• PM 視角：模型不再靠“肉眼”去猜 UI 按鈕，而是直接讀取業務 API。

• 落地邏輯：PM 的工作重心從“畫交互原型”轉向“定義 JSON Schema”。通過預設清晰的參數標準（如：下單地址、口味偏好、支付限額），確保模型輸出的結果是 100% 結構化的。

• 核心價值：徹底解決大模型的“幻覺”問題，讓 Agent 的每一次下單、轉賬都具備金融級的確定性。

2. MAI-UI 基座模型：長尾場景的“視覺兜底”

• PM 視角：并不是所有第三方商家（如路邊小店）都有完美的 API。這時候，Agent 需要像人一樣“看懂屏幕”。

• 落地邏輯：當 API 鏈路斷開或缺失時，MAI-UI 賦予 Agent 多模態感知能力，直接識別 UI 元素并進行模擬點擊。

• 核心價值：它是 API 失效時的“安全氣囊”，實現了從“感知-決策”到“動作執行”的全場景閉環，確保業務流程不會因為某個環節沒接口而中斷。

3. MCP (Model Context Protocol)：生態接入的“萬能插座”

• PM 視角： 解決“煙囪式”開發。讓自有業務接入通義千問，不應該是“一案一議”的定制開發。

• 落地邏輯： 阿里推行的這套標準，讓開發者可以像插拔 USB 一樣，將不同 App 的數據和功能快速“喂”給 Agent。

• 核心價值： 極大地降低了異構系統的對接成本。對 PM 而言，這意味著生態擴張的速度——你的業務邏輯可以瞬間同步給所有接入該協議的智能終端。

落地執行方案：如何構建一個類阿里的 Agent 閉環？

如果你正負責一個智能體（Agent）產品的落地，別把它當成一個“聊天功能”來做，而要把它當成一個“服務調度系統”。以下是實戰操作手冊：

第一階段：服務原子化（Definition Phase）

核心目標： 把 App 里的“巨石邏輯”拆成 Agent 聽得懂、調得動的“積木”。

• 梳理核心路徑：不要只給 Agent 一個“訂票”接口。你需要把流程拆解為最小單元：查詢、選座、支付。

• 定義 Tool-Use 規范： 給 API 寫注釋就像寫產品需求文檔。比如 price_limit 參數，不能只寫“價格限制”，必須注明：“單位為人民幣，默認值為 0 代表不限制，若用戶未提及則傳 null”。

?? 坑位預警：PM 最痛苦的不是拆解流程，而是去和研發吵架。你會發現原本 App 里的邏輯全寫死在前端或者中間層了。

比如訂票，你必須強行要求研發把“選座”和“支付”解耦。否則 Agent 調用時，會因為接口返回了一個“由于你未登錄，請先看 5 秒廣告”的彈窗而原地宕機。Agent 處理不了邏輯耦合的UI流程。

第二階段：交互協議化（Integration Phase）

核心目標： 解決 Agent “亂說話”和“亂執行”的問題。

• 引入 MCP 協議 (Model Context Protocol)： 別再為每個模型寫一套適配器了。優先采用 MCP 協議來標準化外部數據（如實時股價、庫存）。這不僅是技術選型，更是為了保證當你下個月想從 GPT-4 換成 Claude 3.5 時，不需要重寫整個后端。

• 構建“卡片式”反向確認機制： 絕對不要讓 Agent 在沒有確認的情況下直接扣款。

?? 坑位預警：很多產品死在“確認疲勞”。如果 Agent 查個天氣也要用戶點確認，用戶會煩死；如果買張 3000 元的機票不確認，用戶會殺掉你。

實戰經驗：必須設計“分級確認”。查詢類直接出結果，涉及真金白銀的操作，Agent 必須吐出一個“結構化確認卡片”，用戶點擊卡片上的按鈕才是最終指令，而不是在對話框里回一句“確定”。

第三階段：閉環履約（Execution Phase）

核心目標：解決“誰在買”和“買失敗了怎么辦”的最后 100 米。

• 身份映射 (Identity Mapping)： 解決 Agent 的身份危機。你需要建立一套安全映射，讓大模型賬號無縫關聯業務系統 Token，實現“免密靜默操作”。

• 異常監控與降級策略： Agent 報錯是常態。當接口返回 500 或者模型邏輯卡死時，系統要能自動接管。

?? 坑位預警：最大的坑在于“狀態不同步”。比如 Agent 以為付完錢了，但后臺支付網關超時了。這時用戶問“我票買好了嗎？”，Agent 可能會根據上下文瞎編說“已買好”。

實戰經驗：必須建立“Agent 審計日志”。系統需具備視覺模擬模式：當 API 調不通時，自動截取一張后臺狀態截圖交給視覺模型（VLM）判斷，或者干脆一鍵轉接人工，別讓 Agent 在那里反復跟用戶道歉。

PM總結建議

在 Agent 時代，產品的護城河不再是功能的多寡，而是服務被調用的便捷程度。

我們要做的不只是一個更聰明的聊天機器人，而是一個自帶商業閉環的服務調度中心。App 正在從“人點擊 UI”演變為“Agent 調用 API”。如果你的 API 還是為了前端展示而設計的，那么在 AI 時代，你的產品就是一塊不可用的“生肉”。

競品對壘：為什么豆包在“翻墻”，而千問在“開門”？

在 Agent（智能體）的競技場上，阿里千問與字節豆包展現了截然不同的兩種生存姿態。這不僅是模型智商的博弈，更是“主場主權”與“客場突圍”的策略對撞。

4.1 權力歸屬：拿到了房門鑰匙，還是在翻墻跑腿？

Agent 的核心價值在于“替用戶辦成事”。兩者的差距，本質上是“內部握手”與“外部闖入”的效率差。

千問：拿到鑰匙的“管家”（Home Court Advantage）

千問的優勢在于它是阿里的“長子”，手里握著餓了么、支付寶、高德等大廠資產的原生房門鑰匙。

• 絲滑入場：當你說“點杯咖啡”，千問是直接走內部協議通道。它調用的每一條數據都是阿里內部“握過手”的，不需要重新登錄，不需要跨越圍墻。

• 降維打擊：這種確定性源于它就在自家的客廳里活動，每一步操作都合規、透明且精準。

豆包：苦于翻墻的“跑腿”（External Infiltration）

豆包的尷尬在于，它想在別人的地盤（如美團、微信）里幫用戶辦事，這本質上是一種“翻墻”行為。

• 寄生困境：作為一個外來者，豆包只能通過安卓系統的“輔助功能”去模擬人的手指點擊。

• 進退兩難：只要宿主（美團或微信）改一下按鈕位置，或者加個驗證碼彈窗，豆包的 Agent 就像進了迷宮，瞬間“抓瞎”。它在別人的領地上建立規則，隨時面臨被清理出門的風險。

兩者的路徑選擇，決定了它們在交付成功率上的天壤之別。

4.3 為什么“確定性”是 Agent 的生死線？

對產品經理（PM）而言，AI 模型的能力是上限，而交付的確定性才是生存的底線。

• 豆包在玩“概率”： 它的邏輯是“我試試能不能幫你點準”。這種不確定性讓用戶在關鍵決策（如付錢、訂票）時產生巨大的心理負擔。

• 千問在給“結果”： 它是直接繞過錯綜復雜的手機 UI，與服務器握手。這種“確定感”才是真正能建立用戶依賴的降維打擊。

PM 總結：

在 Agent 時代，AI 無法僅靠算力暴力破解生態壁壘。誰擁有最完整的 API 資產，誰手里握著的“房間鑰匙”最多，誰就擁有了定義下一代交互入口的終極話語權。

4.4 豆包的“破局”方案：從“邊緣試探”到“生態截流”

面對阿里密不透風的“全家桶”閉環，豆包如果只滿足于“模擬點擊”這種邊緣戰術，無異于隔靴搔癢。字節真正的降維打擊，不在于復刻功能，而在于利用底層流量的“毛細血管”和端側硬件，在對手最堅固的堡壘側翼撕開裂口。

1）戰略核心：在阿里的“腹地”之外另辟戰場

豆包手里最硬的一張牌，并非單純的算法，而是抖音沉淀多年的“內容-交易”閉環。阿里千問守得住“餓了么”的剛需外賣陣地，卻未必擋得住字節在非標生活決策上的奇襲。

• 避開“紅區”肉搏，主攻“非標”心智： 豆包沒必要在“點外賣”這種阿里重兵把守的標準化場景里死磕。真正的破局點在于“種草-訂票-探店”這類充滿變數的非標生活場景。當用戶還在猶豫“周末去哪”時，豆包就已經通過分析用戶剛刷到的短視頻，完成了從興趣觸發到消費決策的引導。

• 從“看戲”到“入局”的秒撥截流： 最讓千問感到“威脅”的動作，是豆包能夠深度壓制抖音生活服務的原生API。想象一下：當用戶看完一段極具誘惑力的探店視頻，無需跳轉、無需搜索，豆包 Agent 直接在后臺把團購券核銷并規劃好出行路線。這種從“內容感知”到“交易閉環”的瞬間合圍，才是對阿里生態最狠的“截流”。

• 硬件加持的“端側奇襲”： 除了流量，字節在端側硬件（如智能耳機、穿戴設備）的布局，是讓 Agent 徹底擺脫手機屏幕束縛的關鍵。這種物理級別的侵入，能讓豆包在用戶產生念頭的瞬間就完成響應，搶在阿里 App 開啟之前，就消化掉用戶的意圖。

2）“如果說 App 是一座座緊閉大門的‘私人領地’，與其派特種兵翻墻（劫持 UI），不如直接由豆包牽頭修一套‘高速公路標準’。

當豆包背后站著抖音和耳機的億萬入口時，它就不再是求人開門的訪客，而是規則的制定者。

這種邏輯是：‘我可以不破解你，但你要想從我的流量池里分一杯羹，就必須換上我的插頭。’ 字節通過把流量分配權封裝進 MCP 協議，讓開發者從‘防賊’變成‘投誠’。這不再是技術上的博弈，而是一場基于流量籌碼的‘降維招安’。”

核心邏輯拆解

為了讓你更清晰地感受這種表達的力道，我們將其邏輯內核進一步具象化：

這里的“破局”洞察：

關于“修橋”：橋不是目的，“過橋費”和“檢查站”才是目的。定義協議本質上是搶占 AI 時代的“HTML 標準”。

關于“招安”：商業世界沒有永遠的敵人。美團、微信不給 API 是怕被“掏空”，但如果接入豆包協議能帶來精準的訂單和活躍，那么“被掏空”就變成了“新渠道”。

流量分發權：字節最強的武器永遠不是模型本身，而是“讓人上癮的注意力”。用注意力去置換開發者的 App 數據接口，是最高級的商業陽謀。

硬件突圍：繞過 App 的“端側 OS”戰略

豆包已在穿戴設備（如 Ola Friend 耳機）上深度布局。硬件是打破 App “圍墻花園”最有效的手段。

落地策略：強化 “AI-First 操作系統” 屬性。在硬件端，豆包不再是一個單純的 App，而是作為系統級交互層存在。

技術路徑（語義感知點擊）：核心邏輯是從傳統的“坐標驅動”進化為“語義驅動”。

從PM容錯視角看：傳統的模擬點擊最怕 UI 改版，哪怕按鈕只挪了 10 個像素，自動化腳本就會“抓瞎”。我們的解法是讓 Agent 像人一樣具備“認字”和“認圖標”的能力。

通過端側視覺大模型（VLM）的實時感知，Agent 并非在死記硬背點擊位置，而是在實時理解屏幕意圖。只要它能理解“購物車”或“下單”的語義，無論按鈕變成了什么樣、藏在哪個角落，都能點得準。這種“語義對齊”徹底取代了脆弱的“坐標對齊”，極大地提升了在第三方應用中執行任務的穩定性與確定性。

具體的落地執行方案

為了讓豆包的破局更具可操作性，建議 PM 團隊關注以下三個“顆粒度”：

第一步：從“坐標依賴”進化為“邏輯識圖”（語義感知點擊）

痛點：傳統的模擬點擊本質是“盲人摸象”，極其脆弱。UI 稍微改個版、廣告彈窗挪個位，Agent 的腳本就直接撞墻掛掉，維護成本是個無底洞。

方案：核心邏輯是從“找坐標”轉向“找意圖”。

落地：引入視覺大模型（VLM）作為 Agent 的“眼睛”，建立動態容錯層。Agent 操作前不再死記“第 3 行第 2 個按鈕”，而是實時掃一眼屏幕：“我要找的是‘結算’按鈕”。哪怕 UI 樣式從圓角變直角、位置從左邊挪到右邊，只要語義邏輯對得上，Agent 就能點得準。 這種“模糊匹配”能力，才是解決 Agent 落地“最后 100 米”穩定性的關鍵。

第二步：從“功能對接”進化為“流量分發”（Action-based SEO）

痛點：第三方 App 普遍存在“圍墻花園”心態，憑什么讓你無感調用我的核心功能？

方案：既然無法暴力破墻，就用流量杠桿誘導。

落地：建立 “Action 插件商店”。PM 需要定義的不是接口標準，而是利益分配機制。比如用戶說“打車回家”，豆包不再只是機械打開滴滴，而是根據各平臺的實時價格和響應速度，通過 Action 接口直接調起最匹配的服務。這本質上是把 Agent 變成了“意圖搜索入口”，誰的 API 接得好、服務質量高，豆包就給誰分發流量。

第三步：從“權限索取”進化為“信任隔離”（隱私沙盒）

痛點：“模擬點擊”天然自帶“流氓軟件”的既視感，用戶不敢放開系統最高權限。

方案：用技術手段把“操作權”與“隱私權”物理隔離。

落地：在安卓底層推動建立“Agent 專屬執行域（Sandbox）”。

在這個沙盒里，Agent 的所有點擊、滑動動作都被嚴格限制在業務流程內，且全程錄屏存檔、隨時可追溯審計。

我們要給用戶的安全感是：你可以信任這個“替身”去跑腿，因為它的手腳被關在籠子里，根本碰不到你的私人相冊和聊天記錄。

作者洞察

阿里的千問贏在“存量資產”的變現，這是一場防御戰，守住的是已有的賬號體系；字節的豆包必須贏在“增量協議”的制定，這是一場遭遇戰。

真正的 Agent 破局者，不應僅僅是“幫你點外賣的助手”，而應是能夠重塑 App 間流量分發邏輯的“新移動操作系統”。

商業思考：當大模型擁有了“手腳”，PM 的戰場在哪？

在 LLM 具備了調用工具（Function Calling）和自主規劃（Planning）的能力后，“當 LLM 開始擁有‘手腳’（Function Calling），我們這些做產品的人得先適應一種失落感：用戶可能再也看不見你精心設計的 UI 了 。

PM 的核心產出物正在發生質變，如果你還在糾結按鈕的交互動效，那你可能還沒意識到，真正的戰場已經轉移到了‘邏輯分發’的深水區。”

對于產品經理而言，這意味著我們不再是界面的裁縫，而是業務邏輯的架構師。以后判斷一個 PM 牛不牛，不看他畫的交互，看他拆解的業務原子夠不夠‘好用。

5.1 發展藍圖：PM 的三階進化路徑

Agent 時代的到來并非一蹴而就，PM 的工作重心將經歷從“外圍輔助”到“核心調度”的變遷：

5.2 方法論一：從 UI 原型到服務定義（API Spec）

別再糾結那幾個像素的色差了，現在的功夫都在“文檔”里。你能把業務邏輯說得多透徹，Agent 調用的效率就有多高。 核心挑戰已從“視覺引導”轉向了“業務邏輯的結構化輸出”。

1. 原子化拆解：引入“積木式思維”

PM 現在的核心任務是把原來捆綁在一起的業務邏輯進行“暴力拆解”。

• 傳統做法：關注的是一整個流程頁面。比如設計一個完整的“外賣下單頁”，用戶必須按部就班地走完 A -> B -> C。

• 積木思維：把“查詢附近門店”、“校驗滿減優惠”、“提交訂單支付”看作一個個獨立的樂高積木。

• Agent 邏輯：Agent 就像個聰明的孩子，它會根據用戶的一句話（意圖），自己決定先拿哪塊積木、再拿哪塊積木來完成任務。

2. 語義化標注：追求“零歧義”執行

在 API Spec（接口文檔）里，你寫給模型的描述字段，每一個字都是真金白銀。

• 文案即代碼：PM 的文案能力不再是為了優美，而是為了消除歧義。

• 實戰案例：比如定義一個“價格”字段，如果你不標注清楚是“券前原價”還是“實付金額”，Agent 在給用戶反饋或計算優惠時就會鬧出烏龍。

• PM 的新功底：你需要用極度精準的自然語言告訴 Agent：這個接口在什么場景下調用？入參的業務含義到底是什么？

3. 邊界設計（Guardrails）：給 Agent 裝上“剎車”

別指望 Agent 能處理所有極端情況。PM 需要從原來的“前端校驗”轉向“安全護欄”與“人機協作”的設計。

• 定義“禁區”： 明確哪些邏輯 Agent 可以自主決策，哪些必須停下來。比如：“如果用戶余額不足且未綁定免密支付，禁止發起調用”。

• 反向確認機制（Human-in-the-loop）： 涉及到地址或扣款這種敏感動作，必須把“確認鍵”交還給用戶。

• 防線思維： Agent 可以跑得快，但在“安全”這根紅線上，它必須學會剎車。這是防止 Agent 產生幻覺、導致業務資損的最后一道防線。

當用戶不再打開搜索框輸入品牌名，而是對手機說“幫我選最劃算的晚餐”或“訂一張去上海最便宜的機票”時，傳統的 SEO 將徹底失效。PM 的核心戰場將轉移到 AEO（Agent 引擎優化）。

1. 結構化數據：從“營銷軟文”轉向“機器硬通貨”

在 AEO 時代，別再給 Agent 投喂那些花里胡哨的營銷文案了，它不看這個。它要的是清晰的 JSON或 XML，是那種能直接吞下去并轉化成動作的“硬通貨”。

關鍵任務： PM 的角色要轉變為“首席翻譯官”，將品牌價值翻譯成機器能理解的語義標簽。數據定義越標準、Schema 越清晰，被 Agent 采納的權重就越高。

2. 意圖搶占：在語義維度完成“占位”

Agent 時代，傳統的關鍵詞競價正在消亡，語義標簽才是 2026 年的流量密碼。

實戰策略： 針對“宿醉想喝點熱的”這種模糊意圖，品牌方不再是競價“粥”或“湯”，而是通過 AEO 優化，讓自己在“解酒”、“溫和”、“暖胃”這些標簽下排到第一。誰能精準匹配意圖，誰就掌握了分發權。

3. 服務確定性：Agent 只看冷冰冰的指標

Agent 是極度“冷血”的決策者，它不會被煽情的廣告詞洗腦。在它的決策模型里，只有履約速度、投訴率和接口成功率這些硬指標。

博弈規則：傳統的營銷套路統統失效。PM 必須下沉到數據底座，管理好真實的業務表現。

在 Agent 面前，“服務確定性”的權重遠高于“廣告出價”。

SEO vs AEO 深度對比表

作者洞察

Agent 正在推倒 App 的圍墻。

我們的產品不再是一個封閉的孤島，而是變成了一組可被隨時調用的原子能力。

PM 的內核已經從“產品設計師”進化成了“業務架構師”。

結語：Agent 時代的臨界點

外賣 Agent 的走紅，不僅是一個功能的迭代，更是移動互聯網交互范式的一次“地震”。

6.1 從“畫圖”到“定義規則”：PM 的護城河重塑

Agent 時代的到來，確實讓傳統的畫圖 PM 感到焦慮，因為 UI正在消失。但換個角度看，我們終于從瑣碎的像素對齊中解脫出來了。

當用戶通過語音描述意圖時，PM 的戰場已經從前端的“像素級糾結”轉移到了后端的“邏輯級建模”。我們要做的，是去定義業務的邊界，去設計異常發生時的補償機制。邏輯，成了 PM 在 AI 時代唯一的護城河。

6.2 確定性勝過一切

產品的競爭力不再取決于 App 誰畫得更好看，而取決于誰的服務更確定。

• 原子化能力：誰能更早地將業務拆解為可被 AI 調用的 API，誰就能順滑地接入生態。

• 交付閉環：像通義千問這樣通過原生協議實現的“確定性交付”，將遠比不穩定的“模擬點擊”更具商業生命力。

品牌商家需要思考的不再是如何在搜索結果中排第一，而是如何讓 Agent 在理解意圖時選中你。掌握了 API 規范的定義權和場景觸發的邏輯優先級，就等于掌握了 Agent 時代的流量分配權。

Agent 的到來并非要取代產品經理，而是將我們從瑣碎的交互細節中解放出來，回歸到產品的本質——創造價值與解決問題。

只要商業邏輯還在，只要解決問題的需求還在，PM 就永遠是那個給 AI 注入“靈魂”的架構師。

本文來自微信公眾號：反方向的評 作者：Junliu

想要第一時間了解行業動態、面試技巧、商業知識等等等？加入產品經理進化營，跟優秀的產品人一起交流成長！