聊天機器人與代理之間真正的差別
其中一個只是回答問題。另一個則會決定該做什麼、動手去做、檢查自己的成果,並自行進入下一步——不必等你開口要求。這個差異並不只是學術上的區分。它改變了可能出錯的地方,以及誰該負責發現這些錯誤。
聊天機器人接收你輸入的內容、生成一個回覆,然後就停下來。代理接收你輸入的內容後,會決定接下來該發生什麼事、採取行動去處理它、檢查那個行動是否成功,並自行決定下一步該做什麼——往往要經過好幾個步驟——然後才讓人看到任何結果。這就是兩者之間的全部差異。人們爭論「AI代理」時談到的一切——風險、系統需要的監督程度,以及大部分的行銷混淆——都源自這唯一的差異。
聊天機器人實際上在做什麼
聊天機器人是單次處理的系統。你給它文字,它生成文字回覆給你,互動就此結束。即使是擁有長期對話記憶的聊天機器人,每一輪也只是在做同一件事:讀取到目前為止說過的所有內容,並預測下一則訊息。它從不查詢資料庫來確認某個事實,從不代替你發送任何東西,也從不會事後回頭確認自己的答案是否經得起考驗。如果它錯了,造成的損害就是一個人讀到的一句話——而在正常情況下,這個人在依此行動之前,通常能夠察覺並攔下這個錯誤。
人們要求聊天機器人做的事,大多在不知不覺間都符合這個形態:總結這份文件、擬一則生日祝福訊息、解釋我們的退款政策、寫三個標題選項。這些都不需要系統去核對真實世界中的任何事,也不需要在聊天視窗之外採取任何行動。就算介面被包裝成「AI助理」或「Copilot」而不是「聊天機器人」,這一點依然成立——盒子上貼的標籤,並不會改變盒子裡面實際發生的事。
代理實際上在做什麼
代理運作的是一個迴圈,不是單次處理:規劃一個步驟、透過呼叫一個真正的工具來採取行動——查詢資料庫、發送訊息、編輯檔案、呼叫API——查看那個行動實際回傳了什麼,再利用這個結果來決定下一步。它會不斷重複這個過程,直到任務完成、卡住,或是被設計成要向人回報為止。重要的是,沿途沒有人核准每一個單獨的步驟。系統會根據上一次行動實際發生的結果,自行決定接下來要嘗試什麼——而它在每一個這樣的決策點上都可能出錯,不只是在最終答案上出錯。
這種迴圈並不新奇,也不特別。研究人員多年來已經描述過它的各種版本——推理該做什麼、採取行動、觀察結果、再次推理——而這正是那些自稱為代理的產品底層實際運作的方式,從自動申報費用的軟體,到會打開終端機並自行執行指令的程式碼工具都是如此。真正讓某個東西成為代理,而不只是很會講話的聊天機器人的關鍵,在於它會對這個世界採取行動、觀察發生了什麼事,並做出調整——一再重複這個過程,而不需要人類核准每一個動作。
同一個請求,用兩種方式執行
當兩個系統接到聽起來相似的指示時,這個差異看起來會是什麼樣子——以下就是實例。
「總結這份文件。」
- 1讀取你貼上的文字。
- 2生成一段摘要。
「找出三張逾期超過30天未付的未結發票,替每一張擬一封提醒信,並放進我的草稿夾。」
- 1查詢發票系統,篩選出逾期超過30天的未結發票。
- 2確認確實找到三張,不是兩張或五張——如果數字不符就標記出來,而不是隨便猜。
- 3為每張發票取得正確的金額、到期日與聯絡人,並擬出一封提醒信。
- 4透過郵件工具,把每一封草稿存進真正的草稿夾。
- 5回報它找到了什麼,又擬了什麼草稿。
如果你問聊天機器人同樣的第二個問題,它依然會給你看起來像答案的東西:三封聽起來合理的提醒信,是根據你剛好貼進對話裡的內容生成的。但它不會做的是,去查詢你真正的發票系統、核實數字,或把任何東西放進真正的草稿夾。輸出結果可能看起來很像。但系統實際做了什麼,卻完全不同。
這不只是語意上的爭論
這個區分之所以重要,是因為它改變了可能出錯的地方,以及誰該負責發現。聊天機器人最壞的情況,是給出一個錯誤的答案。有人讀到它,而在正常情況下,這個人會發現這個錯誤,或決定不依此行動——這個錯誤永遠不會離開對話本身。代理最壞的情況,則是在真實世界裡已經採取了一個錯誤的行動:提醒信寄給了錯的客戶,寄出的餘額還是錯的;紀錄被更新成錯誤的數值;退款被重複發放了兩次——而這些都發生在任何人審核之前。這時的錯誤已經不再是一句話了。它是一個已經發生的事件,而事件是無法收回的。
聊天機器人最壞的情況,是有人讀到一個錯誤的答案。代理最壞的情況,則是在任何人讀到任何東西之前,一個錯誤的行動就已經被執行了。
這正是為什麼代理需要一種和聊天機器人不同的監督方式。聊天機器人大致只需要有人不時檢查它的答案就夠了。代理則需要它的設計者,在它開始運作之前就先決定好:哪些行動可以不必詢問就執行,哪些行動需要有人先看過計畫,以及當它卡住時該怎麼辦。如果事後才去想清楚這些問題,你就只能透過代理已經做過的事來慘痛地了解答案。
你只能信任你能看見的東西
這正是FabricLoop的可判讀性概念背後的相同想法:你只能治理你真正能看見的存取權限與行為。對聊天機器人來說,這幾乎是自動成立的——它全部的輸出就是一則人會讀到的訊息,所以行動本身和行動的紀錄是同一件事。但對代理來說並非如此。它的行動發生在其他系統內部——CRM、收件匣、資料庫、檔案——除非有東西記錄下它接觸、變更或送出了什麼,否則事後根本沒辦法審查,更別說事先阻止。可判讀性對代理來說,不是疊加在上面、可有可無的合規功能。對代理而言,它就是整個問題的核心,因為它的「答案」不是一句你可以校對的話——而是一整組你可能永遠不會知道曾經發生過的行動,除非系統一開始就被設計成會讓你看見。
這就是這兩個概念之間實際的連結:代理承擔了比聊天機器人更多、也不同的風險,這正是為什麼它需要一條可見的行動軌跡,並且在風險較高的情況下,需要在行動前設一個檢查點——這也是FabricLoop的人為介入率概念所處理的問題:把它當成一個你要設計並測量的數字,而不是等出了問題之後才臨時補上的事後補救。
市場經常把這件事完全弄反
一旦你有了真正的檢驗標準,就會很清楚看到這個標籤在兩個方向上都經常說謊。許多被大力行銷成「AI代理」的產品——這個字出現在主標題、出現在定價方案裡——實際上底層只是一個調校得很好的單一提示詞:讀取輸入、生成輸出,結束。沒有獨立的工具呼叫,沒有迴圈,也沒有任何決策是在沒有人核准下一次點擊的情況下做出的。同時,許多從不使用「代理」這個字的軟體——一套自動化的發票流程、一個會自行重新導向流量的監控系統、一個會重啟失敗服務並檢查是否修好的維運腳本——卻正悄悄地在執行上述完全相同的那個迴圈。標籤上寫的字,完全無法可靠地告訴你,你實際上在使用哪一種機器。
1. 它完成這件事需要超過一個步驟嗎? 2. 下一步是它自己決定的,還是每一步都由人一次點擊一次來決定? 如果每一步都是人在選擇,你看到的就是一個多了幾個按鈕的聊天機器人——不管行銷頁面上怎麼稱呼它。如果系統在超過一個步驟的過程中,是自己選擇下一步,那你看到的就是一個代理,而它需要被當成代理來治理:可見的日誌、對它能在未經詢問下做什麼設下明確的限制,以及對「由誰審查、何時審查」有一個真正的答案。
FabricLoop自己的AI產品Loop Agent,運作的就是這個迴圈——在MCP連接的工具之間搜尋、擬稿、檢查自己的成果——但它被設計成會展示自己的工作內容,並在風險較高的步驟之前先詢問,而不是悄悄行動、事後才回報。它使用的每一個MCP連線,都以個人為單位設定範圍;在Enterprise版本中,它做過的事會出現在稽核日誌裡,而不是只存在於它自己對這場對話的記憶當中。
這正是可判讀性與人為介入率這兩篇文章談到的同一套邏輯——如果這是這三個概念中你第一次理解的一個,接下來很值得接著讀那兩篇。
要應用這一點,並不需要任何技術背景。下一次有廠商或同事把某個東西稱為代理時,問問看它在你的指示與最終結果之間實際做了什麼——以及其中有多少步驟是它自己決定的。