企業導入 AI 第三階:會讀資料的 agent

這是系列的第三篇。系列從第 0 篇的完整參考架構圖開始,第 1 篇講身份與 gateway,第 2 篇講資料與檢索。第三階對應圖上編號③的那幾格:AGENTS & TOOLS 裡面的 Agent runtime 與 Read connectors。Agent runtime 方塊上標的是「sandboxed execution」,這一階只接唯讀連接器。這一階排在資料與檢索之後,因為 agent 要先有東西可讀才有事可做,而它能讀多少,由第二階做好的範圍決定。這一階不改外部系統也不送出訊息,出錯不會留下外部痕跡。

公司沿用第 1、2 篇的晴川,約 40 人,8 個工程師、2 個行銷。晴川是編的,只用來把這一階走一遍。第二階做完之後,所有人都從身份提供者登入,每通 call 都帶著角色走 gateway,問內部材料回來的答案都按提問者分過範圍。晴川還沒有的是自己會動的東西。每一次讀取,還是一個人問一句、回一個答案。

Agent runtime:沙箱執行

第一個方塊是 agent 開始自己跑步驟的地方,不再由人一步一步帶。方塊上的標註是「sandboxed execution」。在晴川就是一支會自己讀 repo、自己查工單系統的 agent,跑在有邊界的執行環境裡:能碰什麼有一份固定的清單,每一次跑都有時間上限。

這裡真正要緊的性質只有一個,就是 containment。一個 run 出錯有很多種樣子,中途停住、繞進迴圈、照著壞計畫走到底,每一種都出不了這個盒子。它碰不到清單之外的系統,時間上限到了就停。沒有這個方塊,每一次 agent 跑起來都帶著它借來的機器或憑證的全部權限,一次跑壞就能讀到任務之外很遠的地方。這裡只是裝得住。政策層面的 run-level halt,帶 scope 與預算跳閘的那種,歸第五階。做完的樣子是:一份寫下來的可及清單,一個預設就開著的時間上限,超限的 run 停下來並留下是哪條線觸發的紀錄。

Read connectors:沿用同一套角色範圍

第二個方塊把這個 runtime 接上內部系統,只讀。在晴川就是一條接 repo 的連接器、一條接工單系統的連接器,每條都帶著第二階給檢索索引做好的同一套角色範圍。用行銷的身份問的 agent,看到的是行銷看得到的東西。用客服的身份問同一支,看到的是客服看得到的東西。

第二階定下來的順序原封不動搬過來。範圍由系統執行,agent 看到東西之前就已經分好了。連接器當初就沒切緊,跟 agent 使壞是兩件不同的事,而 agent 會在照吩咐做事的同時讀到超過預期的東西。做完的樣子是:每條連接器寫明它讀哪些系統、服務哪些角色,同一個問題由兩種角色來問回來的材料不一樣,而把 prompt 裡所有跟權限有關的句子刪掉,結果一點都不變。

Agent 說的不算紀錄

Agent 自己跑起來之後,對它做了什麼會有兩種說法。一種是 agent 自己說的。一種是系統在旁邊獨立記下的。兩種不一定對得上,而落差很安靜,因為 agent 講得很篤定。

我在這件事上跑過一個很小的本地實驗,20 次(N=20,單組),用本地小模型,題目是做完一個檔案操作並回報完成。20 次裡 18 次 agent 回報做完了,檔案不在。把落差關起來的辦法,是在 agent 之外加一道檢查:先確認檔案真的存在,才接受那句做完了。數字來自一份 lab gate 報告,只描述那個設定。我帶走的是形狀,數字留在那個設定裡:做完是要在 agent 之外查證的事實,不是從它嘴裡接受的一句話。做完的樣子是:每一次跑都留下讀了什麼、何時讀的 log,放在 agent 改不到的地方,而 log 跟 agent 自己的說法逐行對得上。

進第四階前的檢查

拿真的 agent 和真的連接器來跑。挑一個任務放手讓它跑,然後不問 agent,只憑系統 log 重建它讀了什麼、何時讀的。重建結果跟 agent 自己的說法對不上,記 log 的方塊還沒做起來。

第二半是為第四階做的準備度探針,寫法跟第 0 篇同形。挑 agent 做過的一個動作,只憑紀錄回答是哪條政策、在哪個版本、用哪組輸入放行的。只寫「這通 call 發生了」的 log 行,回答不了這個問題。兩半都得由系統本身執行才算過。沒過之前,第四階不是下一件該做的事,因為第四階的核准紀錄會原封不動繼承這一階沒記下來的東西。完整的政策版本化與 run-level halt 在第五階。

自架版的圖上,AGENTS & TOOLS 這一欄畫得一樣,託管方式在這一階幾乎沒有差別。讀的路徑走的還是同一批系統。第 4 篇講寫入與送出連接器,中間隔著人審,到那裡出錯會留下外部痕跡,而這一階記下來的東西,會變成核准時引用的對象。