agent 上不了線,卡的不是模型,是治理層

每次有人問我「agent 還差什麼才能進公司」,預期的答案多半是「再聰明一點」。但我盯著真正卡在門口的那些案子,瓶頸幾乎都不是模型不夠強——是它一旦從「我私下用的助理」變成「會自己排程、跨頻道替全隊行動的同事」,你突然發現公司根本沒有一套規矩可以管它。模型再強也繞不過這層。我把它叫治理層。

值得先講清楚的是,這不只是「更會聊天的 bot」,是互動拓樸先變了。當一個頻道裡只有一個 agent、跟所有人互動、誰都能接手別人交辦到一半的任務,體感就從「我問 AI」變成「我跟一個 teammate 協作」——脈絡與進度成了團隊共有財,不再鎖在某個人的對話視窗裡。它還會為自己排程,半夜跑分析、明天去查部署紀錄,把時間軸從一次對話拉長到「持續在背景替你工作」。聽起來很好。問題是,一個會自己動手、跨天推進、動別人系統的東西,你拿管聊天框的那套是管不住的。下面這四件,每一件都是模型強度補不上的。

身分:它得用自己的帳號,不是借你的

第一個門檻是身分。最偷懶的做法是讓 agent 繼承某個員工的全部權限——它就帶著那個人的鑰匙到處走。這在出事那天會很難看:到底是誰做的?責任接不回人。對的設計是給 agent 一個自己的 service account,一個可以被獨立授予、收回、稽核的非人主體。它以自己的身分發文、開 PR,權限不再跟某個離職就失效的人綁在一起。這條看起來只是工程細節,其實是 agent 能進企業的第一道解鎖。

可問責:每個動作都要答得出「誰叫它做的」

有了獨立身分,才談得上乾淨的問責。它會自主跨天行動,「它做了什麼、為誰做的」就是治理的命門。光記下 agent 做了什麼不夠——你要能回答「這是誰請求的」,責任鏈才接得回人。動作對得上發起人,稽核才不是一堆查不到源頭的日誌。背景跑得越久、越自主,這條軌跡越不能省。

控好炸裂半徑:記憶與權限按邊界分艙

第三件是我最在意的。共享同事一旦會累積記憶,危險就是「什麼都記、到處串」——在業務頻道養出的脈絡漏進工程頻道,或反過來。預設不該是全域可見,而是按組織邊界分艙:能跨頻道學習,但只在你明確授權時;它也不該從私人頻道往外回報。把「可學的範圍」當成「可控的炸裂半徑」來治理,洩漏才不會隨記憶累積而擴散。這正是讓「持續記憶」能進企業、而不是變資安惡夢的那道閘。

花費要封頂:把不確定的成本變預算

自主 agent 的成本天生不確定——它可能跑幾小時、自己排好幾個任務。所以計費要走消費型(按用量,不是按人頭),再配上能事前框死的花費上限:組織層一個、單一頻道一個,達標就停。我一向主張鼓勵讓 agent 多花算力去換更強的產出——同一批人因此能扛更大的事——但「鼓勵燒」跟「給它一個封頂的閘」是一體兩面。沒有那個閘,沒有 admin 敢放手。

結論:治理是一級設計,不是事後補丁

你當然可以直接買一套把這些都做好的 SaaS,讓共享同事跟著頻道對話自己長出脈絡,快、又現成。但這也把「公司的腦」鎖進別人的邊界裡:記憶受廠商管、綁特定方案、到期就刪。要快、要現成,就買;要耐久、要主權、不想被鎖住脈絡,就把真正長期的知識沉澱回你自有、可搜尋可遷移的庫——兩條路不互斥。

不論你選買還是自建,我的立場只有一句:押注 agent 上線能力時,先把治理當一級設計。身分、問責、分艙、封頂——這四塊不是等模型變強就會自動消失的麻煩,它們是你敢不敢放手的前提。模型再強,也替你決定不了該不該信任它;那個決定,得由治理層來扛。