北京
一個按鈕按下，頁面中央轉出圓圈，整個產品隨之“凍住”——這是太多智能體產品正在重復的交互模式。用戶不知道此刻調用的是哪個工具，系統里發生了哪些變更，又牽涉到哪些子智能體。事后團隊只能翻看冗長的事件記錄來復盤，這比空白好一點，但對于被真實截止時間追趕的人而言，幾乎沒用。
單次模型調用的體驗，靠令牌流式輸出確實緩解了一部分：模型逐字輸出答案時，界面“活”了起來。但智能體產品面對的是更寬泛的問題：它產出結果的過程橫跨多種工具、子智能體、工作流檢查點、狀態補丁、審批關卡、后臺任務、可重連會話，以及用戶盯著看的各個應用。單純在聊天框里吐出幾行字，遠遠折射不出整個服務路徑。
LangChain 在一篇題為《從令牌流到智能體流》（From Token Streams to Agent Streams）的文章中，為這類現象命了名。文章認為，生成式用戶界面不能只是讀取記錄的漂亮外包裝，界面與運行時的邊界需要一份契約。流不再是一條文本管道，它成為了界面的契約。記錄只能呈現文字，而智能體產品必須呈現“工作過程”。
舊的聊天界面之所以行得通，是因為用戶發一條消息，然后等助手回復。生成過程中，令牌不斷追加到當前線程，直到助手寫完。一旦把實際任務注入智能體，這種簡單的聊天框形態立刻崩壞。設想一個支持工單的場景：智能體需要查詢賬戶信息、檢查單點登錄配置、創建工單、請求變更套餐的批準、往 Salesforce 加備注，再等待計費接口返回數據。在這一長串動作中，智能體輸出的文本只占整個請求處理工作的極小部分。真正重要的是那筆請求穿過產品后端的完整路徑——計費調用、審批卡片、變動的賬戶信息、工單編號，最后才到對問題的回答。面對這種體驗，一個旋轉圖標配上空白的輸入區和零星的令牌流，界面表達能力貧弱得可憐。
反方或許認為，聊天式界面配合流式輸出已經足夠處理智能體交互，畢竟最終響應的正確性才是關鍵。但這種看法忽略了一個事實：在高延遲場景下，單線程逐個處理請求的聊天機器人本身就是架構上的壞味道，而事件流只是同一問題的界面呈現。前端需要在智能體并行處理事件時，實時看到產品界面隨之演進，而不是等到一切結束再以一條日志的方式獲知結果。LangChain 的事件流文檔清晰描述了這一接口邊界，推薦使用 stream_events(..., version="v3")，它能返回結構化的投影，包括消息、工具調用、狀態值、子圖、自定義投影和最終輸出。應用接下來要做的，就是渲染所獲得的投影，而不是去解析最底層的原始事件流。
所以，哪一種路線更接近事實？舊聊天界面把智能體的工作壓縮成一段文本記錄，本質上是為人類閱讀做了最后一步總結，卻舍棄了過程的實時可見性。而將事件流作為界面契約，則要求運行時系統把“正在發生什么”實時投影給用戶——工具調用、狀態切換、審批節點、子智能體的介入，都成了界面的一部分。判斷在于：當智能體不再是單次問答的機器，而成為一條跨系統、跨狀態的執行流水線時，再讓用戶盯著轉圈等待，無異于在告訴他“系統正在撒謊”。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
