說同一種語言:用 NLIP 達成 Agent 互通

TL;DR

• 問題是 Tower of Babel:agent 各說各話時,你只能寫 custom glue code 與 adapter,而這條路不可能規模化。
• NLIP 的定位是「意圖的 HTTP」:HTTP 是在異質 client 與 server 之間搬運資源的中立統一方式;NLIP 是在異質 agent 與 client 之間搬運意義與意圖的中立統一方式。
• 它鬆綁了協定最根本的假設:傳統協定要求 A = P = B(兩端語言與線路格式相同);NLIP 允許 A ≠ B ≠ P,代價是兩端必須有智慧可以翻譯——而以現在的趨勢,這個前提只會越來越成立。
• 刻意極簡:訊息模型是輕量 JSON、只有五個欄位(三個必填);相較之下 A2A 或 MCP 的完整資料模型有 166–480 個欄位。
• 它不是要取代 A2A / MCP,而是共存:NLIP 適合異質協定互通、語意彈性、跨協定中介;A2A 適合治理稽核、任務中心、嚴格 schema 與決定性執行;也可以混用,NLIP 在協調層、A2A 在治理層。

重點整理

問題與定位(約 04:14–04:16)

Sinha 開場一句話就把問題講完:當 agent 講不同語言時,你得寫 custom code、glue code、adapter,而這根本不 scale。這就是 Tower of Babel 問題。

NLIP(Natural Language Interaction Protocol)是那個讓無縫互通成真的通用握手:只要 agent 會講 NLIP,它就能跟所有會講 NLIP 的東西對話。他給的類比貫穿全場——把 NLIP 想成「意圖的 HTTP」,而且它刻意採取和 HTTP 一樣的做法:極簡、中立。HTTP 是在異質 client 與 server 之間傳輸資源的中立統一方式;NLIP 是在異質 agent 與 client 之間傳輸意義或意圖的中立統一方式。

出身背景:由學界與業界研究者、實務者組成的工作組,由 Enterprise Neurosystems Group 與 AI Alliance 贊助;現已是 ECMA 標準,由技術委員會 TC56 推動(他順帶提醒:JavaScript 也是由 ECMA 這個組織標準化的),並已送交 ISO 標準化,目前進行中。

核心設計:鬆綁 A = P = B(約 04:16–04:18)

他用一組左右對照的圖說明整個協定的關鍵洞見。

傳統協定(左):agent 1 講語言 A、agent 2 講語言 B、線路上跑的是 P。傳統協定要求 A = P = B——三者必須相同。任何 schema 或欄位的改變都會讓它斷掉,結果就是 hard-coded integration 與緊耦合,並衍生出互通性與版本管理的麻煩。

NLIP(右):同樣是 A、B、P 三者,但 A 不必等於 B、也不必等於 P。這帶來彈性,而條件是:兩端必須有智慧,能在這些訊息之間翻譯。他認為以現在的趨勢,你本來就可以預期解決方案與系統裡有智慧存在,而且它只會持續變好。

在這個基礎上,NLIP 提供的是一個非常簡單、開放、共通的標準協定,讓應用、agent 與服務彼此溝通。它假設兩端都有智慧以達成語意理解,並採取 request–response 範式,確保意義或意圖在 agent 真正行動之前先被釐清並確認。他特別點出這個範式的好處:訊息如果語意模糊,agent 不會直接失敗,而是回頭要求澄清。

同時它是為企業現實打造的:必須安全、要有 safeguard;transport agnostic 且沿用既有基礎設施,不重造輪子;支援多媒體;通訊高效;可用多種語言實作;是由 ECMA 治理的開放標準(ISO 審查中)。

訊息模型:五個欄位(約 04:19–04:21)

NLIP 刻意極簡。訊息模型是輕量 JSON,只有五個欄位,其中三個必填:

• content:承載被交換資訊的輕量 JSON 信封
• format:是 text、structured 還是 binary
• subformat:format 的細化——若是 text 就標明語言,若是 binary 就標明編碼
• 另外兩個選填欄位:一個 parsing hint,以及可放額外內容的 sub-message

核心資料模型就這五個欄位。他直接拿現行熱門協定對比:A2A 或 MCP 的完整資料模型有 166 到 480 個欄位。

實作上它在標準傳輸協定上都很簡單:HTTP、WebSocket、AMQP 的 binding 都已在 ECMA 規格中定義,可從 GitHub 頁面取得。安全性是 secure by design 且為強制:提供從基本到嚴謹企業級的三種 profile,並且處理的不只是傳輸層安全,還包含各種 AI 特有的風險。

與單一廠商協定共存的兩種模式(約 04:21)

NLIP 可以用兩種模式與各種單一廠商協定互通:

• 模式 A:NLIP 當 northbound API、單一廠商協定當 southbound API,中間用一個 translation agent 與 LLM pod 做兩者之間的翻譯。
• 模式 B:跨多個 domain 互通。每個 domain 內可以有多個 agent,各自用不同的 agent framework、講自己的語言;只要它們是 NLIP-aware,就都能彼此溝通。

PoC 與效能實驗(約 04:21–04:24)

已有企業與大學在多個領域做出 PoC:電信、購物、永續、多模態客服等,多數也放在專案頁面上。

他挑客服那個 PoC 深入講:顧客送出一段語音請求 → 用語音轉文字模型(NVIDIA ASR)轉成文字 → 以 NLIP over HTTP 送給 channel recommender,由它挑出與該提問最相關的 subreddit 頻道 → 再以 NLIP over HTTP 送給 search agent,由它從那些頻道挑出最相關的主題、排序後回傳給顧客。整體就是:一個顧客提問,從 Reddit 撈出最相關的主題回覆。

接著是效能比較:同一個 workflow,拿 NLIP 對比 A2A,使用對稱、完全相同的計時 harness,並取三種 A2A 變體(A2A SDK、cache 最佳化版 A2A、輕量 Python A2A)。他們做了階段層級的儀器化——message creation、connection、send 三個階段,總延遲是三者之和——並在兩台機器、兩份含多筆顧客提問的資料集上測。結果在兩台機器上的平均總延遲,NLIP 都比較低,他把這歸因於其訊息信封的極簡本質。他自己強調這是初步實驗,更複雜的 workflow 與實驗還待做,也歡迎外界參與。

給實務者的選型建議(約 04:24–04:26)

他把問題收斂成「什麼時候該用哪個協定」:

但他強調真正的原則是:協定選擇應該由 workload 特性來決定。 現實是協定會有長尾——支付、購物等領域都在推出自己的 domain-centric 協定——所以問題變成如何跨這些協定以可互通的方式溝通,而那正是 NLIP 的位置。

收尾:NLIP 已整合進 AG2 framework(他說 AG2 每天被下載數萬次、每月可能達百萬次)。委員會每週開會、持續開發,歡迎回饋、實際 use case、參與評測或直接貢獻,聯絡方式都在專案頁面上。

金句

"Think of NLIP as the HTTP of intent."(約 04:15)

整場演講的核心比喻,也解釋了為什麼它刻意做得這麼小。

"In a traditional protocol they all have to be the same. A is equal to P is equal to B."(約 04:17)

一句話點出既有 agent 協定的脆弱點,以及 NLIP 要鬆綁的到底是什麼。

"If a message is ambiguous, the agent doesn't just fail — it will ask for clarifications."(約 04:18)

request–response 範式的用意:意圖要先被確認,agent 才動手。