你的 AI 團隊為什麼越跑越慢？因為上下文太重了

很多管理者都遇過同一個現象：AI 團隊剛開始上線時很快，回應乾脆、產出也有感；但跑一陣子之後，速度開始下滑，成本往上，連簡單任務都拖泥帶水。這時很多人直覺會怪模型不夠強、提示詞失效，或工具組合選錯。其實更常見的問題不是 AI 能力下降，而是它背著越來越重的上下文在工作。

所謂上下文重量，說白了就是：每次啟動都讀太多不必要的東西。明明只要處理一個客服分類任務，卻順手掃進一堆舊專案筆記、過期規則、沒人維護的資料夾，甚至把上週就失效的狀態一起帶進來。這些內容不只讓 agent 變慢，也會直接燒掉 token、增加判斷噪音，最後讓輸出品質一起下滑。AI 不是看得越多越厲害；對管理來說，關鍵是它每次看的是不是剛好夠用。

要幫團隊減重，先抓 3 件事。

第一，工作目錄只留正在用的。正在跑的流程、當前版本的規則、最近會被引用的文件留下；結案資料、舊草稿、廢棄流程搬走。很多團隊把工作區當倉庫，結果 agent 每次開工都像在舊辦公室翻箱倒櫃。

第二，啟動讀取範圍要固定，而且越小越好。不要讓每個 agent 一上來就自由掃描整個專案。你應該明確定義：這個任務只讀哪些檔、哪些目錄、哪些規則。範圍固定，速度才穩，錯誤才好追。

第三，超過 50 個檔的目錄，通常就該清了。這不是美感問題，是管理訊號。檔案一多，命名開始重複、版本開始混亂、規則開始分散，agent 讀取成本一定上升。只要一個目錄已經大到沒人能快速說清楚每份檔案的用途，那它對 AI 也不會友善。

管理者怎麼判斷自己團隊是不是中了這個問題？你不用先看模型參數，先看三個數字。

第一，agent 啟動時到底讀了幾個檔？如果每次任務都要先讀十幾二十個檔，還包含大量背景材料，速度慢幾乎是必然。

第二，有多少檔是 3 天沒動過，卻還留在核心工作區？這些檔案如果不會被當前流程實際使用，就不該繼續占據上下文。

第三，有沒有重複規則散在不同檔裡？同一件事如果在 A 文件寫一次、B 筆記改一次、C 指南又補一次，agent 很容易讀到互相衝突的版本。這種混亂，比模型本身還容易造成失誤。

結論其實很硬：上下文輕量化不是整理癖，也不是工程師潔癖，而是管理紀律。你不是在幫 AI 收桌面，你是在控制成本、縮短延遲、降低噪音，讓團隊維持穩定產能。AI 團隊跑得快，不是因為塞了最多資訊，而是因為每次都只帶著最必要的資訊上場。