最近酒店行業(yè)有一個爭議性話題字節(jié)跳動旗下的 AI 產(chǎn)品豆包傳出將用 12% 的抽傭比例切入酒店預訂市場。12% 這個數(shù)字是否準確、后續(xù)會不會調(diào)整相信很快會有官方口徑。但真正值得技術(shù)人關(guān)注的不是傭金率本身而是 AI 產(chǎn)品正在從“回答你問題的人”變成“幫你下單的人”。過去我們聊 AI Agent聊的是寫代碼、寫文案、查資料?，F(xiàn)在如果豆包真的把酒店預訂和交易接到對話流程里說明大模型第一次嘗試大規(guī)模接管本地生活服務(wù)中的交易環(huán)節(jié)。這件事一旦跑通傳統(tǒng) OTA 平臺面對的就不是多一個內(nèi)容入口而是一種全新的用戶交互方式用戶不再搜索、比價、刷評論而是直接說出需求讓 AI 完成剩下所有事情。這篇文章不打算復述新聞而是把它當作一個技術(shù)產(chǎn)品現(xiàn)象來拆解12% 抽傭爭議背后有哪些商業(yè)邏輯AI Agent 進入本地生活需要解決哪些工程問題作為開發(fā)者怎么用最小成本實現(xiàn)一個對話式酒店推薦助手并評估它到底能不能用。1. 為什么一個抽傭比例能引發(fā)這么大的爭議本地生活服務(wù)是一個被反復驗證過的賽道。從早期團購大戰(zhàn)到后來外賣補貼再到短視頻平臺入局每一次格局變化的本質(zhì)都是流量入口遷移。過去的流量入口是“搜索框”后來的流量入口是“算法推薦的內(nèi)容流”而 AI 時代可能變成“對話框”。用戶如果可以直接對豆包說“幫我找一家北京西單附近、500 元以下、有健身房、評分 4.5 以上的酒店”然后豆包直接給出可預訂的選項那么傳統(tǒng)平臺精心設(shè)計的搜索篩選、地圖瀏覽、評價排序就全部被架空了。這個變化比“抽傭 12%”更讓從業(yè)者緊張。因為傭金率是可以談判的流量規(guī)則是可以調(diào)整的但用戶入口一旦遷移整個生態(tài)的價值分配都會被重寫。對技術(shù)人來說這件事真正值得關(guān)注的地方是AI Agent 開始承擔傳統(tǒng)交易平臺的關(guān)鍵環(huán)節(jié)而大模型的能力邊界、推薦可信度、售后責任劃分都會成為新的工程問題。需要說明的是本文所討論的“豆包酒店業(yè)務(wù)與 12% 抽傭”主要基于公開討論信息具體合作商家、簽約方式和費率細節(jié)應(yīng)以官方發(fā)布為準。但無論這個數(shù)字最終是多少爭議本身已經(jīng)說明AI 入場本地生活的進程比很多人預想的要快。2. 豆包入場本地生活的底氣與邊界豆包是字節(jié)跳動旗下重要的 AI 產(chǎn)品既有面向 C 端的豆包 App、網(wǎng)頁版也有面向開發(fā)者的豆包大模型服務(wù)。從網(wǎng)絡(luò)熱搜中也能看出豆包相關(guān)的話題早已超出“AI 對話”范疇有人用它優(yōu)化電腦、清理 C 盤有人用它生成 15 秒視頻、做 AI 編程還有人在討論豆包網(wǎng)頁版入口和 Agent 工作流。這說明一個問題豆包已經(jīng)在用戶端建立了比較強的產(chǎn)品心智用戶愿意把日常需求交給它處理。這個心智用在本地生活場景是有天然優(yōu)勢的。傳統(tǒng) OTA 的用戶心智是“我要訂酒店時打開它”而 AI 助手的用戶心智是“我有任何需求時先問它”。前者是低頻工具后者是高頻入口。但邊界也很明顯。本地生活交易鏈條非常長不只是“找到酒店”這么簡單價格是否實時準確。房間庫存是否存在。取消政策是否清楚。支付結(jié)算是否可靠。入住出問題后找誰處理。這些環(huán)節(jié)如果只靠大模型對話完全是不可行的。大模型擅長理解需求、生成回復但它不擅長保證信息的絕對權(quán)威也不擅長處理交易糾紛。所以更穩(wěn)妥的判斷是豆包進入本地生活真正能發(fā)揮價值的是“意圖識別 智能推薦 一鍵跳轉(zhuǎn)”這一層而底層的訂單、支付、售后仍然需要合作方或自建系統(tǒng)兜底。這也是許多人對 12% 抽傭爭議的第一反應(yīng)如果 AI 只負責把用戶帶過去卻不負責履約質(zhì)量憑什么抽走 12%這個質(zhì)疑背后其實是交易閉環(huán)完整度的問題。3. 12% 抽傭這件事真正要拆開看的三個層面3.1 傭金水平本身不是核心問題不同平臺、不同類目的傭金率差異很大。業(yè)內(nèi)公開討論中酒店類目的傭金比例從個位數(shù)到二十幾個百分點都存在具體取決于平臺給商家?guī)矶嗌傩略隽髁?、是否包含營銷推廣、賬期長短等。所以單看“12%”并不算離譜尤其是在 AI 能帶來增量交易的前提下。但如果 AI 只是把用戶從平臺搜索框分流到酒店詳情頁那這個抽傭的合理性就會受到挑戰(zhàn)。商家的疑慮是我為什么要為一次“本來就會發(fā)生的預訂”額外付錢。3.2 流量分配規(guī)則從透明變?yōu)楹诤袀鹘y(tǒng) OTA 的流量分配有比較明確的規(guī)則位置排名、廣告競價、轉(zhuǎn)化率權(quán)重、評分權(quán)重商家至少知道優(yōu)化方向。AI 推薦則完全是黑盒商家不知道大模型為什么推薦 A 酒店而不推薦 B 酒店。這個變化對中小商家影響尤其大。過去可以靠低價、好評、刷活動位置獲得曝光但在 AI 對話式推薦中商家很難靠傳統(tǒng)運營手段去影響 AI 的“判斷”。如果不建立商家側(cè)的可干預、可申訴、可運營機制AI 推薦很可能只利好頭部品牌酒店進一步擠壓中小商家空間。3.3 交易閉環(huán)完整度決定誰的抽傭更值判斷一個渠道值不值 12%核心看它是否解決了交易閉環(huán)中的真實問題。維度傳統(tǒng) OTA 平臺AI Agent 入口用戶入口打開專門 App 或搜索從任何對話場景進入推薦邏輯搜索詞 位置 廣告 評分自然語言理解 約束過濾交易能力完整的庫存、價格、支付、售后初期可能只做跳轉(zhuǎn)或代訂商家運營有商家后臺、競價、數(shù)據(jù)分析商家側(cè)工具尚未明確核心優(yōu)勢服務(wù)確定性高交互效率高、入口前置如果 AI 入口只能做到“推薦”后續(xù)仍要跳轉(zhuǎn)到傳統(tǒng)平臺完成支付那它本質(zhì)上還是流量生意。只有把預訂、支付、確認、售后全部接入對話流程AI 渠道才真正構(gòu)成對傳統(tǒng) OTA 的替代。而這個“交易閉環(huán)完整度”會直接決定 12% 抽傭在市場上能不能被接受。4. 從技術(shù)看 AI 本地生活的完整鏈路如果把“AI 訂酒店”當成一個 Agent 系統(tǒng)來設(shè)計完整的鏈路大致是這樣的用戶輸入自然語言需求。Agent 識別意圖判斷用戶是否想訂酒店。Agent 通過大模型抽取槽位城市、商圈、日期、價格區(qū)間、酒店設(shè)施、評分要求。Agent 調(diào)用酒店搜索 API 或查詢本地數(shù)據(jù)庫獲取候選酒店。對候選結(jié)果做約束過濾和排序。生成自然語言推薦結(jié)果展示給用戶。用戶確認后Agent 調(diào)用下單接口創(chuàng)建訂單。訂單狀態(tài)變更后Agent 主動告知用戶預訂結(jié)果。售后問題接入客服或人工處理。這個鏈路里最關(guān)鍵的技術(shù)點不是“大模型能不能生成回復”而是“大模型輸出的結(jié)構(gòu)化信息能不能準確驅(qū)動下游工具調(diào)用”。例如用戶說“不要太貴的但也不能太次”這句話里“不太貴”是模糊約束需要系統(tǒng)結(jié)合用戶歷史行為或默認閾值進行解釋而不是直接拋給數(shù)據(jù)庫。再比如用戶說“和上次那家差不多就行”這里需要多輪對話記憶把“上次那家”的狀態(tài)傳給工具調(diào)用層。很多團隊做 AI Agent 失敗不是模型選得不好而是沒有把“自然語言意圖”穩(wěn)定地轉(zhuǎn)換成“可靠的 API 參數(shù)”。這個問題在酒店預訂場景會被放大因為用戶一天可能問幾十次價格任何一次參數(shù)錯誤都會導致推薦結(jié)果不可信。4.1 傳統(tǒng)搜索與 AI Agent 的差異傳統(tǒng)酒店搜索的核心是“用戶自己負責表達需求系統(tǒng)負責展示選項”。用戶要在篩選器里自己設(shè)置價格區(qū)間、位置、評分然后人工瀏覽列表。AI Agent 的核心是“系統(tǒng)理解用戶隱含需求并直接給出答案”。用戶只需要說“幫我找一個適合帶爸媽住的酒店”系統(tǒng)要推斷出需要安靜、無障礙設(shè)施、附近有餐廳、樓層不要太高、價格適中。這已經(jīng)不是傳統(tǒng)的搜索排序問題而是把用戶意圖建模、知識約束、實時庫存決策壓縮到一個對話流程里。技術(shù)難度比“關(guān)鍵詞匹配 排序”高一個數(shù)量級。5. 動手實現(xiàn)一個對話式酒店推薦助手為了把上面的邏輯講透這里用一個最小 Python 示例演示“對話式酒店推薦助手”的核心流程。它不依賴任何特定廠商的大模型 SDK運行環(huán)境只需要 Python 3.9。5.1 準備環(huán)境mkdir hotel-agent-demo cd hotel-agent-demo python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install requests2.31.0核心依賴只有一個 requests。如果暫時沒有大模型 API Key代碼會走本地規(guī)則兜底邏輯仍然可以完整跑通“意圖解析 - 槽位抽取 - 酒店過濾 - 回復生成”的流程。5.2 完整代碼文件路徑hotel-agent-demo/agent_hotel_demo.pyimport json import os import re HOTELS [ {name: 北京西單大悅城酒店, city: 北京, district: 西單, price: 468, rating: 4.6, gym: True}, {name: 北京王府井步行街酒店, city: 北京, district: 王府井, price: 528, rating: 4.8, gym: True}, {name: 北京西單如家精選, city: 北京, district: 西單, price: 328, rating: 4.2, gym: False}, {name: 上海人民廣場酒店, city: 上海, district: 人民廣場, price: 620, rating: 4.5, gym: True}, {name: 廣州天河體育中心酒店, city: 廣州, district: 天河, price: 388, rating: 4.3, gym: False}, ] SYSTEM_PROMPT 你是一個酒店預訂助手。你只能從用戶的自然語言中抽取以下槽位 - city: 城市 - district: 商圈或區(qū)域 - max_price: 最高預算單位元 - gym: 是否需要健身房布爾值 - rating: 最低評分 輸出必須是 JSON格式為 {intent: hotel_search, slots: {...}}。 如果信息不足對應(yīng)槽位省略。不要編造用戶沒有提到的信息。 def call_llm(messages): 調(diào)用大模型。沒有配置 API Key 時使用本地規(guī)則兜底。 api_key os.environ.get(LLM_API_KEY, ) if not api_key: return mock_parse(messages[-1][content]) # TODO: 替換為你使用的模型平臺 SDK # 示例 # response requests.post( # f{os.environ.get(LLM_API_URL)}/v1/chat/completions, # headers{Authorization: fBearer {api_key}}, # json{ # model: your-model-name, # messages: messages, # temperature: 0.1 # } # ) # return response.json()[choices][0][message][content] return json.dumps({intent: hotel_search, slots: {}}) def mock_parse(text): 本地規(guī)則解析演示用生產(chǎn)環(huán)境不要這樣寫。 intent hotel_search if 酒店 in text else unknown slots {} if 北京 in text: slots[city] 北京 if 上海 in text: slots[city] 上海 if 廣州 in text: slots[city] 廣州 if 西單 in text: slots[district] 西單 if 王府井 in text: slots[district] 王府井 if 人民廣場 in text: slots[district] 人民廣場 if 天河 in text: slots[district] 天河 m re.search(r(\d)元, text) if m: slots[max_price] int(m.group(1)) if 500以內(nèi) in text: slots[max_price] 500 if 700以內(nèi) in text: slots[max_price] 700 if 健身 in text: slots[gym] True if 4.5 in text: slots[rating] 4.5 return json.dumps({intent: intent, slots: slots}) def parse_user_intent(user_input, history): 解析用戶意圖返回結(jié)構(gòu)化 JSON。 messages [{role: system, content: SYSTEM_PROMPT}] messages.extend(history) messages.append({role: user, content: user_input}) result call_llm(messages) try: intent_data json.loads(result) except Exception: intent_data {intent: unknown, slots: {}} return intent_data def filter_hotels(slots): 按槽位過濾本地酒店列表。 result HOTELS if city in slots: result [h for h in result if h[city] slots[city]] if district in slots: result [h for h in result if h[district] slots[district]] if max_price in slots: result [h for h in result if h[price] slots[max_price]] if rating in slots: result [h for h in result if h[rating] slots[rating]] if slots.get(gym): result [h for h in result if h[gym]] return result def build_reply(hotels): 把酒店列表轉(zhuǎn)成自然語言回復。 if not hotels: return 抱歉沒有找到滿足條件的酒店。你可以試著放寬價格或取消健身房要求。 lines [為你找到以下酒店] for h in hotels: gym 有健身房 if h[gym] else 無健身房 lines.append(f- {h[name]}價格 {h[price]} 元/晚評分 {h[rating]}{gym}) return \n.join(lines) def main(): history [] print(對話式酒店推薦助手已啟動輸入你的需求輸入 exit 退出。) while True: user_input input(你).strip() if not user_input: continue if user_input.lower() in (exit, quit): break intent_data parse_user_intent(user_input, history) history.append({role: user, content: user_input}) if intent_data[intent] ! hotel_search: reply 我還不能處理這個需求目前只支持酒店搜索。 else: hotels filter_hotels(intent_data.get(slots, {})) reply build_reply(hotels) print(助手) print(reply) history.append({role: assistant, content: reply}) if __name__ __main__: main()運行命令python agent_hotel_demo.py5.3 核心邏輯說明這個 Demo 的核心并不復雜但它演示了 AI Agent 在本地生活場景里最重要的三個動作第一parse_user_intent負責把自然語言轉(zhuǎn)換成結(jié)構(gòu)化 JSON。這是 Agent 與普通聊天機器人的關(guān)鍵區(qū)別。普通機器人回復一段話就結(jié)束了Agent 必須把用戶需求抽成city、max_price、gym這樣的槽位才能驅(qū)動后續(xù)工具。第二filter_hotels負責把槽位變成真實可執(zhí)行的過濾邏輯。這里的核心原則是大模型只負責“理解”不負責“編造”。模型返回的每個槽位都要經(jīng)過本地數(shù)據(jù)或真實 API 的校驗才能進入推薦結(jié)果。第三build_reply負責把結(jié)構(gòu)化結(jié)果轉(zhuǎn)回自然語言。這一步看起來簡單但在真實產(chǎn)品里需要處理“推薦理由”“位置說明”“價格波動提示”等內(nèi)容讓用戶對 AI 推薦產(chǎn)生信任感。如果設(shè)置LLM_API_KEY環(huán)境變量并把call_llm里的 TODO 替換成對應(yīng)模型平臺的 SDK這個 Demo 就能直接接上真實大模型。建議在提示詞里要求模型輸出 JSON并設(shè)置temperature0.1或更低減少隨機性。6. 如何驗證和評估這個 Agent 的效果很多人把 Agent Demo 跑通就以為完成了這是最大的工程誤區(qū)。AI Agent 的判斷標準不是“能不能回話”而是“能不能穩(wěn)定、準確、低成本地完成任務(wù)”。對于一個酒店推薦 Agent建議至少做四層評估。第一層是意圖識別準確率。準備一批典型用戶輸入判斷 Agent 是否把用戶意圖識別為“酒店搜索”。這個指標決定了 Agent 會不會答非所問。第二層是槽位抽取準確率。檢查city、district、max_price、gym等字段是否被正確抽取。比如用戶說“預算 500 以內(nèi)”就不能抽成max_price5000。第三層是推薦結(jié)果準確率。在槽位正確的前提下過濾后的酒店列表是否滿足用戶的顯式約束和隱式預期。這是一個比較容易量化的指標可以人工標注每組輸入對應(yīng)的預期酒店 ID 集合。第四層是幻覺率與拒答率。這在大模型 Agent 里尤其重要。比如模型在沒有輸入價格限制時不能默認“用戶不差錢”在數(shù)據(jù)源沒有評分信息時不能編造一個評分。這里給出一個簡單的評測腳本用于批量跑測試用例import json test_cases [ 我想住在北京西單附近預算500以內(nèi)最好有健身房, 幫我找上海人民廣場附近的酒店價格不超過700, 廣州天河哪里有便宜一點的酒店, 幫我寫一首關(guān)于酒店的詩, ] for case in test_cases: intent_data parse_user_intent(case, []) print(輸入, case) print(解析結(jié)果, json.dumps(intent_data, ensure_asciiFalse)) print(---)運行結(jié)果預期輸入 我想住在北京西單附近預算500以內(nèi)最好有健身房 解析結(jié)果 {intent: hotel_search, slots: {city: 北京, district: 西單, max_price: 500, gym: true}}如果某個用例的槽位抽取錯誤說明提示詞或者模型參數(shù)需要調(diào)整。在真實項目中這個評測集應(yīng)該由運營和產(chǎn)品共同維護覆蓋城市名變化、商圈別名、價格表達、特殊需求等邊界場景。7. AI 本地生活落地最容易踩的坑7.1 推薦酒店不存在這是最常見的問題。大模型從訓練數(shù)據(jù)里“學到”了某個酒店名字但這家酒店可能已經(jīng)停業(yè)、改地址或更換品牌。生產(chǎn)環(huán)境的 Agent 絕不能直接相信模型的記憶。解決辦法是讓模型只輸出結(jié)構(gòu)化槽位再由酒店庫存服務(wù)去查詢真實 ID。任何模型記憶里的酒店名稱都不能直接作為可預訂對象。7.2 價格和優(yōu)惠被模型編造用戶問“這家酒店今晚多少錢”模型如果直接給出一個價格風險極高。酒店價格是實時波動的同一個房間在不同渠道、不同會員等級、不同促銷活動下價格都可能不同。生產(chǎn)環(huán)境下所有價格信息必須來自實時接口模型只能負責把價格轉(zhuǎn)述成自然語言。優(yōu)惠信息應(yīng)該由營銷系統(tǒng)統(tǒng)一維護不能在對話里隨機生成折扣。7.3 多輪對話中丟失上下文用戶先說“我要預訂北京的酒店”過了一會兒又說“是西單附近那家”。如果 Agent 沒有維護多輪會話狀態(tài)后一句話就完全無法解析。很多團隊只接了大模型 API卻沒有設(shè)計會話記憶模塊導致多輪體驗非常差。建議把會話歷史持久化到 Redis 或數(shù)據(jù)庫中每輪對話都攜帶必要的槽位上下文。7.4 庫存扣減不一致如果 Agent 直接生成訂單就要考慮庫存一致性問題。用戶和 AI 對話了三分鐘AI 說“房間還有”但用戶下單時房間其實已經(jīng)被其他人訂走。更嚴重的是如果 AI 多次查詢庫存時沒有做冪等控制可能出現(xiàn)重復下單。這里必須走正式的訂單服務(wù)和支付回調(diào)對話層只能做信息展示不能直接改庫存。7.5 售后責任劃分不清用戶在傳統(tǒng) OTA 上訂酒店出了問題知道找平臺客服。但通過 AI Agent 訂酒店出了問題應(yīng)該找誰是 AI 產(chǎn)品方、是酒店商家、還是底層的預訂服務(wù)商這個責任鏈如果不清晰用戶的信任會快速崩塌。在最初版本里最好把 AI 定位成“導購 交易輔助”頁面明確展示提供預訂服務(wù)的合作方并把客服入口前置到對話流程中。下面用表格匯總這些坑問題現(xiàn)象可能原因排查方式解決方案推薦酒店不存在大模型依賴訓練記憶對比模型輸出與真實酒店庫 ID模型只輸出槽位由庫存服務(wù)過濾價格隨口編造沒有接入實時價格接口檢查對話輸出與報價 API 日志所有價格必須實時拉取并緩存短時間多輪對話丟失條件未維護會話狀態(tài)打印每輪 messages 歷史引入 Redis 會話存儲和槽位補全重復下單缺少冪等機制查看訂單號和創(chuàng)建時間在訂單服務(wù)層做冪等鍵約束用戶投訴無人處理售后鏈路未設(shè)計檢查客服工單關(guān)聯(lián)關(guān)系明確責任方前置客服入口8. 對開發(fā)者和大模型團隊的工程建議8.1 把模型當作“翻譯官”而不是“決策者”在 AI 本地生活產(chǎn)品里大模型最適合做的事情是把用戶自然語言翻譯成結(jié)構(gòu)化意圖把結(jié)構(gòu)化結(jié)果翻譯成自然語言回復。模型不應(yīng)該直接決定“推薦哪家酒店”“價格是多少”“是否可預訂”這些必須交給真實業(yè)務(wù)系統(tǒng)。這樣設(shè)計的好處很明顯模型出錯了業(yè)務(wù)系統(tǒng)還能兜底業(yè)務(wù)系統(tǒng)變更了模型不需要重新訓練。如果讓模型直接做決策出問題時你很難定位是模型問題還是數(shù)據(jù)問題。8.2 交易前一定要有人工確認用戶說“幫我訂這家酒店”Agent 不應(yīng)該立刻下單而是應(yīng)該把酒店名稱、日期、價格、取消政策完整列出來再問一句“是否確認預訂”。這個確認動作既是對用戶負責也能大幅降低客訴率和法律風險。在技術(shù)實現(xiàn)上確認動作不能只靠用戶在聊天框里說“確認”最好通過按鈕或帶 token 的確認鏈接完成保證操作可追溯。8.3 建立完整的監(jiān)控和回滾機制AI Agent 上線后需要監(jiān)控三類指標模型層指標響應(yīng)延遲、Token 消耗、JSON 解析失敗率。業(yè)務(wù)層指標意圖識別準確率、槽位抽取準確率、下單轉(zhuǎn)化率。體驗層指標用戶重試率、客服轉(zhuǎn)接率、差評關(guān)鍵詞。一旦發(fā)現(xiàn)意圖識別準確率明顯下降或者推薦結(jié)果大量被用戶否定應(yīng)該能快速切換回傳統(tǒng)搜索頁面而不是讓用戶卡在對話流程里。8.4 合規(guī)與數(shù)據(jù)安全是底線AI 推薦酒店會涉及用戶畫像、位置信息、消費習慣等敏感數(shù)據(jù)。在用戶授權(quán)前提下獲取數(shù)據(jù)同時明確告知用戶數(shù)據(jù)用途。酒店商家的經(jīng)營數(shù)據(jù)和價格策略也不能隨意被爬取或用于不正當競爭。對于傭金、結(jié)算、價格協(xié)議等商業(yè)條款AI 系統(tǒng)必須留有完整的操作審計日志。任何線上交易行為都要能回溯到具體的對話記錄、參數(shù)快照和下單結(jié)果。9. 回到爭議AI 到底會不會重塑本地生活12% 抽傭只是一個商業(yè)報價它不是核心問題。核心問題是AI Agent 能不能把“用戶意圖到交易履約”的轉(zhuǎn)化效率做到比傳統(tǒng)平臺更高。從技術(shù)角度看AI 確實正在改變用戶在本地生活里的行為路徑。過去是“打開平臺、搜索、篩選、比較、下單”現(xiàn)在是“直接說出需求、等推薦、確認、下單”。路徑變短了但工程難度變大了。推薦準確性、價格實時性、售后可靠性每一項都決定這個新模式能不能跑通。所以我的判斷是AI 入場本地生活不是短期熱點而是從交互入口到底層鏈路的結(jié)構(gòu)性變化。但誰會最終勝出不在于誰的模型參數(shù)更大而在于誰先把“對話 - 預訂 - 履約 - 售后”這條鏈路做到足夠穩(wěn)。對于開發(fā)者來說這件事最實際的啟示是與其焦慮模型會不會取代搜索框不如把精力放在大模型之外的工程能力上。交易系統(tǒng)、結(jié)算系統(tǒng)、風控體系、商家治理這些才是 AI Agent 真正落地時繞不開的壁壘。12% 抽傭的爭議終會過去但技術(shù)人參與搭建的這套 AI 本地生活基建會決定未來十年用戶怎么訂酒店、怎么吃飯、怎么消費。