北京
“沒有上下文的AI代理只是猜得更快。”供應鏈可視化公司project44的CEO杰特·麥坎德利斯，在最近一次《FW Today》的對話中，直白地捅破了這層窗戶紙。這句話聽著有點刺耳，但如果你看過一些物流公司興沖沖部署了AI機器人，結果客戶收到的回復牛頭不對馬嘴，就知道他說的全是業內每天都在流的血。
麥坎德利斯跟《FW Today》的克雷格·富勒聊的大框架，是貨運行業到底該怎么擁抱AI：一邊把它當成內部效率的杠桿，一邊還得做成面向客戶的產品。而project44自己給出的答卷，是一個叫“代理式工作流管理器”的東西，下面還墊著一層AI編排引擎。這套設計的起點非常務實——解決托運人和物流服務商最頭疼的兩個問題：數據質量不靠譜，和日常操作自動化跑不通。
這里有一個很反常識的設計邏輯，按條目拆開看，更能聞出里面的吐槽味兒：
一、先別急著買Agent，先看看數據地基打沒打平
麥坎德利斯的觀點很堅決：你讓一個AI代理去處理貨運異常，但它連這批貨上次是被哪家承運商提走的、這條線路的歷史準點率怎么樣都拿不到，那它可不就是逮著什么說什么。project44的做法是把自己手里已有的第一方上下文數據——通過收購LunaPath獲得——和第三方代理提供者（比如Happy Robot、Vooma）全部串在一套引擎上。也就是說，上下文是鋪好了的水電網，代理只是插進來的電器。沒有這個前置步驟，再智能的代理上線都得被客服罵回來。
二、沒有哪個單一大模型能包打天下，嘴硬的已經被內部跑分教做人
他們干了一件非常工程師思維的事情：把多家代理供應商的模型放在引擎里，實打實地并行跑了一年多。比對維度不光看任務類型，還把語種、溝通渠道這些變量全拉滿。跑出來的結論一點都不浪漫：“有些代理在某些任務上比另一些強，語言本身就能拉開差距。”說人話就是，你在英文郵件場景里表現好的代理，遇到西班牙語的電話調度可能就拉胯。所以project44的應對不是去賭哪家王炸，而是死死攥住上下文的分發權——“我們有觸達客戶的渠道，有客戶的信任，客戶接進來，真正關心的是我們最終能交付什么結果。”
三、“點擊，不是代碼”背后，是對“要雇一群提示詞工程師”這種荒唐事的精準補刀
麥坎德利斯特意強調了一句話，聽著像懟人：“因為這些東西已經嵌在平臺里了，是點擊，不是代碼，你不需要提示詞工程師，也不需要自己去搭數據庫。”這話要是讓過去兩年瘋狂招聘prompt engineer的公司聽見，可能得有點扎心。project44的邏輯是，上下文這個最臟最累的活他們提前干完了，所以托運人那邊不需要搞集成項目，不需要做自定義數據庫的苦力，上來就點兩下開始用。調度核對這個場景被當成典型用例推了出來，尤其針對跑零擔貨運的那批人——麥坎德利斯說這個功能在客戶里產生了不小的共鳴。
四、競爭護城河不在算法紙上談兵，而在那些又厚又黏的運營數據
全篇最實在的概念，是麥坎德利斯定義的“上下文”到底包括什么：貨物級別的數據、承運商關系、調度歷史、歷史的線路和承運商分析，還有跟特定運輸模式掛鉤的工作流。這些東西沒有一個是光鮮亮麗的技術新詞，全是一個物流平臺跑了十幾年才能攢下的臟活數據。而他明說這就是護城河。這就解釋了為什么project44敢讓不同代理在引擎里賽馬——模型是可以換的，但讓模型變聰明的那層上下文，是換不走的。
所以回到開頭那句“沒上下文的AI代理只是猜得更快”，其實整件事聽起來更像是一個老手在勸同行：別被那些生成漂亮郵件的演示視頻哄上頭了，先回去把你家訂單、運單、調度單里的歷史數據洗干凈、接順了，再談接下來的智能化。不然，在客戶發飆的速度這件事上，你們倒是很可能跑出個行業新紀錄。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
