AI Agent 不需要記住所有事

讓 AI agent 產生一個像樣的答案，已經不是最難的問題了。模型夠好，一段寫得用心的 prompt 加上兩三個工具，就能做出一個 demo 起來很漂亮的東西。

真正的考驗從隔天開始。

它得撐過更長的對話、失敗的工具呼叫、改來改去的業務規則、轉交給人的環節，以及做到一半被打斷的流程。這是另一個工程問題，而且大部分難處跟模型無關。

我在做企業流程和 AI 客服系統的過程中，愈來愈確信一件事：

AI agent 不需要記住所有事，它需要保留重要的那些。

對話一複雜，直覺反應就是往前多帶一點東西——把上一次的工具輸出接上去、把政策文件再塞一次、把完整逐字稿留在 context 裡。感覺上這叫謹慎。實際上這是最快的一條路，通往一個貴、難查、而且在你最需要它穩定的場合最不穩定的系統。

四種東西，不是同一回事

Agent 設計上大部分的混亂，都來自把這四件事當成一件：

	裝什麼	形態	誰讀
對話歷史	逐字的來回紀錄	只增不減、沒有上限	模型，在相關的時候
記憶	跨對話仍然成立的事實	小、經過挑選、可修改	模型，選擇性地
工作流狀態	這件事現在走到哪	有界、可變、結構化	調度層
稽核紀錄	發生過什麼、為什麼	只增不減、不可修改	人、稽核與合規

對話歷史不是記憶。 逐字稿是原料；記憶是你判斷過值得留下的東西。一段對話走到第四十輪，裡面大半是雜訊——澄清、重試、模型為一次逾時的工具道歉。

記憶不是工作流狀態。 「這位客戶偏好用 email 而不是電話」是記憶。「他的退款卡在第三步、等主管核准」是工作流狀態。前者是關於一個人的事實，後者是流程裡的一個位置——而後者才是你要從中恢復的東西。

工作流狀態不是稽核紀錄。 狀態告訴你現在在哪，紀錄告訴你怎麼走到這裡。狀態隨著任務推進被覆蓋掉，紀錄永遠不會——這正是為什麼只有它能回答監理機關或一個生氣的客戶真正會問的問題。

把這四件事壓進同一個大 context window，你就同時失去了它們各自有用的性質。

結構化狀態裡裝什麼

與其反覆把整段對話往前帶，我傾向維護一份結構化的作業狀態，回答一組固定的問題：

• 使用者想達成什麼？
• 哪些已經完成？
• 蒐集到哪些證據？
• 套用了哪些決策與政策規則？
• 什麼失敗了、已經重試過哪些？
• 還有什麼沒解決？
• 下一步需不需要人工核准？
• 接下來該做什麼？

寫下來就是一個很小的物件——幾百個 token，不是幾十萬個：

interface TaskState {
  goal: string
  completed: Step[]
  pending: Step[]
  evidence: EvidenceRef[]        // 存指標，不存內容
  decisions: { rule: string; outcome: string; at: string }[]
  failures: { step: string; error: string; attempts: number }[]
  blockedOn: 'human_approval' | 'external_system' | null
  nextAction: Action | null
}

值得特別講的是 evidence。原始訊息、文件、工具輸出不會放進狀態物件裡，放進去的是指向它們的參照。原料留在儲存層當證據，只有某一步真的需要時才取出來。一個退款決策不需要完整訂單歷史待在 context 裡，它需要的是訂單金額、購買日期，以及適用的那一條政策。

這就是「長對話會退化的 agent」和「不會退化的 agent」之間的分水嶺。一份回答八個問題的狀態，在第五輪和第五百輪的大小差不多。逐字稿不是。

一個大 context window 為什麼會壞

三種方式，而且會互相加乘：

它會變貴。 成本跟著你帶的東西走。什麼都帶，就等於每一輪都在為整段歷史付錢——包括其中對下一個決策毫無影響的那九成。

它會變得難查。 出事的時候，「去看逐字稿」不是一個除錯方法。有明確狀態，你看一個物件就知道目標、已完成的步驟、以及失敗在哪。只有 context window，你是在從一大片文字裡反推當初的意圖。

它會變得不可預測。 長 context 會稀釋注意力。第三輪講過的一條政策，等到它真的重要的時候，要跟四十輪閒聊競爭。模型不算是忘了它——只是把它跟你堅持要一起帶進來的其他所有東西放在一起秤重。

Prompt 和模型呼叫之外

Demo 需要的是一段 prompt 和一次模型呼叫。生產系統需要的是它們周圍的那些機制：

• 檢查點——每個有意義的步驟後落一次持久化寫入，讓當機的代價是一步，而不是整個任務。
• 可恢復的狀態——幾小時後、重啟後、交接後，能把任務載回來接著做，而不是重來。
• 驗證——每次工具呼叫、每次狀態轉換都做 schema 檢查，讓格式錯誤的模型輸出在邊界上大聲失敗，而不是安靜地污染整個流程。
• 可觀測性——能依任務、步驟、結果過濾的追蹤。不是 log 行，是綁定在它所改變的狀態上的結構化事件。
• 政策控制——業務規則寫在程式碼裡、在模型之外求值、記進 decisions。
• 人工介入的路徑——一個明確的 blocked 狀態、一個人看得到的佇列，以及人處理完之後把流程接回去的方法。

這些沒有一項是 AI 功能。它們是可靠商業軟體的一般要求。跳過它們，就是為什麼一個 agent 在模型表現正常的時候，用起來還是覺得脆。

誰有權做什麼

我一直回到的原則，是一條權責分界：

AI 可以理解語言、提出建議。系統必須掌控錢、庫存、權限、政策，以及最終的執行。

拿一筆退款請求來說。Agent 真正擅長的是難的那一半：讀懂一則語氣不佳、講得不清楚的訊息，判斷出這是針對某一張訂單的退款請求，而且客戶引用的理由是配送延遲。這是語言理解，這就是模型該做的事。

Agent 不該做的是決定這筆退款。訂單在不在退款期限內、延遲是不是物流方的責任、這位客戶這一季是不是已經拿過兩次善意補償、超過多少金額要往上簽——這些是對真實紀錄做的政策求值，屬於程式碼：每次都用同樣的方式跑，而且留下痕跡。

所以 agent 提出建議：退款 #1042，RM 84，理由：配送延遲。系統求值政策，發現金額超過自動核准門檻，把狀態設成 blockedOn: 'human_approval'，丟進佇列。主管核准。系統執行退款，把決策寫進稽核紀錄，再把控制權交回給 agent 去回覆客戶。

模型全程沒有碰到錢。它做了它擅長的那部分，而分界劃在「正確與否不再是詮釋問題」的地方。

真正的轉變

一個好的 demo 會產生一個令人印象深刻的答案。

一個生產系統還必須能解釋發生過什麼、從停下來的地方接著走，以及在出錯時安全地恢復。可解釋、可恢復、可回復——這三件事不是最後才加上去的功能，它們是你在第一天決定怎麼保存狀態所帶來的後果。

這才是真正的轉變：不再把 AI agent 當成聊天機器人，而是把它當成可靠的商業軟體來工程化。