聊天機械人同代理之間真正嘅分別

其中一個係答問題。另一個會決定要做咩、自己去做、檢查自己嘅成果，然後再去下一步——唔使等你開口。呢個分別唔係學術上嘅爭論。佢改變咗邊度會出錯，同埋邊個應該捉到個錯。

聊天機械人接收你打嘅字，生成一個回覆，然後就停低。代理接收你打嘅字之後，會決定接下來要發生咩事、採取行動去處理、檢查嗰個行動有冇成功，再自己決定下一步做咩——往往要行好多步——先至會有人睇到任何結果。呢個就係兩者之間嘅全部分別。人哋爭論「AI代理」嘅時候講嘅所有嘢——風險、一個系統需要幾多監督，同埋大部分市場推廣上嘅混亂——都係由呢一個分別帶出嚟。

聊天機械人實際上做緊咩

聊天機械人係單次處理嘅系統。你畀文字佢，佢生成文字返畀你，互動就到此為止。就算一個聊天機械人記得成段對話，每一輪仍然只係做一件事：讀晒到而家為止講過嘅所有內容，然後預測下一句訊息。佢唔會查資料庫去核對一個事實，唔會代你發送任何嘢，亦唔會之後返嚟睇自己嘅答案仲企唔企得住。如果佢錯咗，造成嘅損害就係一個人讀到嘅一句說話——而喺一般情況下，呢個人可以喺跟住去做之前捉到個錯。

人哋叫聊天機械人做嘅大部分嘢，其實都係呢個形態，只係冇人留意到：總結呢份文件、起草一則生日訊息、解釋我哋嘅退款政策、寫三個標題選項。呢啲都唔需要系統去對照真實世界核對任何嘢，亦唔需要喺對話視窗以外採取任何行動。就算介面被包裝成「AI助理」或者「copilot」，而唔係「聊天機械人」，呢一點仍然成立——盒上面嘅標籤，唔會改變盒入面實際發生緊嘅事。

代理實際上做緊咩

代理行嘅係一個循環，唔係單次處理：規劃一步、透過呼叫一個真正嘅工具去採取行動——搜尋資料庫、發送訊息、編輯檔案、呼叫API——睇吓嗰個行動實際返回咗咩，再用個結果決定下一步。佢會一路重複，直到任務完成、卡住，或者被設計成要同人確認為止。重要嘅係，沿途冇人逐個步驟批准。系統會根據上一次行動實際發生嘅結果，自己決定下一步試咩——而佢喺每一個呢啲決策點都可以錯，唔單止喺最終答案先至錯。

呢個循環唔新，亦唔特別。研究人員多年嚟已經描述過佢嘅各個版本——推理應該做咩、採取行動、觀察結果、再推理——而呢個正正就係嗰啲自稱代理嘅產品底層實際行緊嘅方式，由自動申報開支嘅軟件，到會打開終端機並自己執行指令嘅程式工具都係。令一樣嘢成為代理、而唔只係一個好能講嘢嘅聊天機械人嘅關鍵，係佢會對世界採取行動、觀察發生咗咩，然後調整——一次又一次，唔需要人批准每一個動作。

同一個要求，用兩種方式行

當兩個系統收到聽落相似嘅指示，呢個分別看起來會係點。

如果你問聊天機械人第二條問題，佢仍然會交一樣睇落似答案嘅嘢畀你：三封聽落合理嘅提醒電郵，係根據你剛好貼進對話入面嘅內容生成嘅。但佢唔會做嘅，係查詢你真正嘅發票系統、核實數量，或者將任何嘢放進真正嘅草稿資料夾。輸出可以睇落好似。系統實際做咗咩，就完全唔同。

點解呢個唔只係字面上嘅爭論

呢個區分之所以重要，係因為佢改變咗邊度會出錯，同埋邊個會捉到。聊天機械人最壞嘅情況，係一個錯誤嘅答案。有人讀到佢，而喺一般情況下，呢個人會捉到個錯，或者決定唔跟住去做——個錯永遠唔會離開對話本身。代理最壞嘅情況，係喺真實世界入面已經做咗一個錯誤嘅行動：提醒寄咗畀錯嘅客戶，餘額都係錯嘅；紀錄被更新成錯誤嘅數值；退款發放咗兩次——而呢啲全部發生喺任何人審閱之前。呢個時候嘅錯誤已經唔再係一句說話。佢係一件已經發生嘅事，而發生咗嘅事係收唔返嘅。

呢個正正係點解代理需要一種同聊天機械人唔同嘅監督。聊天機械人大概只需要有人不時檢查佢嘅答案。代理就需要設計者喺佢開始運作之前，就已經決定好：邊啲行動可以唔使問就做，邊啲需要有人先睇過個計劃，以及當佢卡住嘅時候點算。如果事後先至諗清楚呢啲問題，你就只能夠透過代理已經做過嘅事，用慘痛嘅方式先知答案。

你只可以信任你睇得到嘅嘢

呢個同FabricLoop嘅可判讀性概念背後嘅想法一樣：你只可以治理你真正睇得到嘅存取權同行為。對聊天機械人嚟講，呢樣幾乎係自動成立——佢全部輸出就係一則人會讀到嘅訊息，所以行動本身同行動嘅紀錄係同一件事。對代理嚟講就唔係。佢嘅行動發生喺其他系統入面——一個CRM、一個收件匣、一個資料庫、一個檔案——除非有嘢記錄低佢接觸過、改過或者送出過咩，否則事後根本冇辦法審查，更遑論事先阻止。可判讀性對代理嚟講，唔係疊加喺上面、可有可無嘅合規功能。對代理而言，佢就係成個問題嘅核心，因為佢嘅「答案」唔係一句你可以校對嘅說話——而係一組你可能永遠唔會知道曾經發生過嘅行動，除非個系統一開始就被設計成會畀你睇到。

呢個就係兩個概念之間實際嘅連結：代理承擔咗比聊天機械人更多、亦唔同嘅風險，呢個正正係點解佢需要一條睇得到嘅行動軌跡，並且喺風險較高嘅情況下，需要喺行動之前設一個檢查點——呢個亦都係FabricLoop嘅人為介入率概念所處理嘅問題：將佢當成一個你要設計並量度嘅數字，而唔係等出咗問題之後先至臨時補上嘅事後補救。

市場經常將呢件事完全倒轉

一旦你有咗真正嘅檢驗標準，就會好清楚見到呢個標籤喺兩個方向都經常講大話。好多被大力推銷成「AI代理」嘅產品——呢個字出現喺主標題、出現喺定價方案入面——底層實際上只係一個調校得好好嘅單一提示：讀取輸入、生成輸出，完結。冇獨立嘅工具呼叫，冇循環，亦冇任何決策係喺冇人批准下一次點擊嘅情況下做出嚟。與此同時，好多從來唔用「代理」呢個字嘅軟件——一套自動化嘅發票流程、一個會自己重新導向流量嘅監控系統、一段會重啟失敗服務並檢查有冇修好嘅維運腳本——卻靜靜雞行緊上面講嘅同一個循環。標籤上面嘅字，完全唔能夠可靠咁話畀你知，你實際上用緊邊一種機器。

要應用呢一點，並唔需要任何技術背景。下一次有供應商或者同事將某樣嘢叫做代理嘅時候，問吓佢喺你嘅指示同最終結果之間實際做咗咩——以及其中有幾多步係佢自己決定嘅。