AI 專案做到一半就忘記前面的決定？Context Compression 真正要管理的是上下文

公司讓 AI 協助完成一個跨部門專案，前幾天看似進展順利，到了第 15 次修改，卻重新問已經確認的需求，甚至把早已否決的方案寫回報告。問題不一定是模型突然變笨，而是長任務的工作狀態沒有被可靠保存。Context Compression（上下文壓縮）能降低長對話帶來的負擔，但要讓 AI 穩定做事，企業還必須建立決策紀錄、外部檔案與驗收制度。

專題編輯：Derek Chou｜AI 技術與架構編輯

一、AI 為什麼會忘記已確認的需求？

大型語言模型處理一次請求時，只能利用當次實際送入的上下文。這個上下文可能包含對話、系統指令、工具回傳、文件與前一次執行結果。隨著專案延續，原始內容會越積越多；有些系統因為上下文長度或成本限制，必須裁剪、清除或濃縮早期內容。使用者雖然看得到完整聊天紀錄，並不代表每一則訊息都會以原文重新提供給模型。

上下文壓縮是將較長的歷史工作內容轉成較精簡、仍能支持後續工作的狀態。OpenAI 與 Anthropic 的開發文件都提供了長任務壓縮機制，但具體啟用方式、保存內容與限制取決於模型及 API 版本，不應假定所有聊天產品會以相同方式運作。來源一、來源二

壓縮結果不一定是人能閱讀的摘要。例如 OpenAI 的 compaction 會回傳不透明的加密壓縮項；下文交接卡是另行保存的企業工作紀錄，不是該 API 輸出的替代品。來源一

企業要防止的不是「文字被縮短」，而是真正有決策效力的資訊在縮短過程中遺失、變形，或被未經確認的推論取代。例如，使用者曾決定「只能在公司內網部署」，壓縮稿卻寫成「偏好內網」，後續 Agent 便可能提出不符限制的公有雲方案。

二、壓縮、檢索、長期記憶與紀錄檔，其實是四回事

上下文壓縮的作用是縮短目前工作所需的歷史內容；檢索（Retrieval）是需要資料時從文件或資料庫找回原文；長期記憶是跨任務保存經確認的偏好與事實；執行紀錄則是保存操作、版本、錯誤及結果的證據。它們可以互補，卻不應互相冒充。

例如，為一家企業建立 AI 報價工作流時，產品折扣的正式授權規則應保留在受控規範文件中；當前客戶的報價版本應放在任務狀態；過去每次產生與修改報價的記錄應留在系統日誌。不能因為摘要寫得完整，就把原始授權規則和真實操作紀錄刪除。

一個實務上容易理解的架構，是把專案資訊分成三層：

1. 不可遺失的約束。 企業資安限制、業務規則、已核准的驗收標準、系統契約及責任人。它們應保存在版本管理或有權限控管的權威來源，不靠摘要當唯一副本。
2. 可更新的工作狀態。 現在做到哪裡、使用哪個版本、有哪些已完成任務、尚待決定的問題，以及下一個執行者該做什麼。
3. 可追溯的原始證據。 需求單、會議決議、來源文件、測試回執、程式提交與操作日誌。摘要只記錄索引和重要結論，必要時能回到原文。

這個三層架構是本文提出的企業工作設計方法，不是特定供應商保證實施的產品功能。

三、需要防止的三種壓縮錯誤

第一種是把決議與討論混為一談。會議曾討論「優先使用外部模型」，後來定案「敏感資料不得外傳」，壓縮稿如果只保留前者，後續選型就會出錯。應明確標示每項資訊的狀態，例如「提出、待確認、已批准、已否決」。

第二種是把摘要當證據。AI 說「資料已對帳完成」，卻沒有提供對帳檔案、資料期間或差異筆數，接手人員無法驗證。正確做法是保留 reconciliation.csv 的檔案版本、產生時間及驗收人；摘要只是入口。

第三種是讓不同期限的資訊共享一份摘要。正式授權規則可能有效一年，當日 API 錯誤訊息只對某個版本有效。兩者不應以相同優先級被永久記住，必須有來源、適用版本與失效條件。

四、可直接採用的「長任務交接卡」

以下是假設企業正在整合客服知識庫與 CRM 的示意模板，可複製成 Markdown 檔，放進受管理的專案資料夾。

# PROJECT_CHECKPOINT
任務代號：CRM-FAQ-014
更新時間：YYYY-MM-DD HH:mm（台北時間）
目標：讓客服能查詢核准的退款政策並產生回覆草稿
已批准限制：不得自動退款；不得傳送未遮蔽個資到外部服務
權威資料：policies/refund-policy-v3.pdf（版本與授權待核對）
已完成：需求表已確認；測試資料已整理
未完成：跨客戶查詢的權限負向測試
已否決方案：直接讓 Agent 寫入退款資料庫
下一步：先跑無寫入權限的查詢測試，再請主管審核
關鍵證據：tests/access-control-report.json
待確認問題：退款政策是否適用國際訂單
負責人：指定的專案 Owner

採用時須把示意內容替換為真正的文件與責任人；若檔案不存在，不能保留假的證據路徑。每次重大決議更新後，應重新生成交接卡並做版本比對。

五、如何驗收 Context Compression 沒有把專案帶歪？

與其詢問「摘要是否寫得流暢」，更有效的方法是從原始記錄抽出一份固定測試集。至少檢查四種能力：是否保留硬性限制、是否區分已決議與待確認、是否能提供原始證據位置、是否能指出下一步與責任人。

具體測試可在壓縮前選定 20 個具代表性的問題，例如「目前允許自動執行退款嗎？」「哪個文件是最新版？」「上次失敗的測試是哪一項？」，把人工核准的答案當基準。壓縮後讓新執行階段回答相同問題，逐題記錄正確、錯誤、缺漏及無法查證。20 題只是示範測試集規模，並非業界通用門檻。

如果壓縮後摘要看似簡潔，卻把「尚未核准」回答為「已完成」，就應判定失敗。尤其是涉及匯款、刪除客戶資料、對外發信、程式部署的任務，不得用簡化摘要代替實際授權確認。

六、什麼時候值得導入？

短時間、單次問答通常不需要額外建立完整狀態系統。當任務跨多天、多個人或多個 Agent，且會修改真實檔案與系統時，才有必要把壓縮、權威文件與交接卡做成標準程序。可以先挑選一個常出現「需求反覆重講」的流程，比較採用交接卡前後的重問次數、返工時間、錯誤率及交付周期。

企業最終需要的不是「AI 永遠記得」，而是「不論上下文如何變短，重要決議都能回到原始證據、被核對並持續執行」。

延伸閱讀與來源

1. OpenAI，Compaction。
2. Anthropic，Compaction overview。
3. Anthropic，Context editing。

本文工作情境及交接卡為教學示例，不代表已在客戶環境完成實測。主圖為原創生成概念插畫，非實際產品畫面。

可下載工作範本

下載長任務交接卡（ZIP）。範本為教學示例，採用前請填入經核准的真實資料。

相關閱讀

延伸閱讀：Session、State、Memory 到底差在哪裡？Agent 能不能續跑，取決於這三層