上一篇我們聊了 Agent 用摘要方式讀取東西時會漏掉細節。這篇來講一個更隱蔽的問題：Agent 在你不知道的地方做了一個假設，然後這個假設慢慢地、安靜地、把你的工作搞砸。
一個每天都在跑的 Agent
我們公司的團隊橫跨三到四個時區，比如台灣、美中、美西、美東，每天的信件往來量不小，如果全部手動看完再分類，一個早上就沒了。
所以我設計了一個 Agent，每天早上自動做這些事：
- 抓取從上次執行斷點到現在的所有工作信件
- 摘要每封信的重點、待辦事項、進度更新
- 把跟特定專案相關的內容分發給各專案底下的 Agent
- 幫所有的信件分類、分等級、分重要程度、分緊急程度、是否需要我 Action 或回信等等
- 按照上述的維度用權重計算分數之後，產出一份「今日總覽」給我，並把分數 Top10 的信件讀完給我處理建議
它就像一個分發員+秘書，把對的資訊送到對的地方，並且協助我在上班剛開始的這半小時掌握今天的工作全貌，這個流程跑了幾天，我一直覺得很很棒，直到有天，我在手動回信的時候發現：有一封兩天前同事寄給我的信，Agent 從來沒有跟我提過。
8 小時的誤差，怎麼變成 25 小時？
追查之後才發現問題：Agent 把台灣時區當作所有工作的基準。
每次 Agent 執行時，它會記錄一個「斷點時間」，下次執行就從這個時間往後抓信件，聽起來很合理對吧？
問題是，當你的信件來自美西（UTC-8），而 Agent 用台灣時間（UTC+8）記錄斷點，中間就有一個 16 小時的時差，一封美西晚上 11 點發的信，在台灣時間是隔天下午 3 點，如果 Agent 的斷點設在台灣時間的凌晨，那封信就會被跳過。
這不是我獨有的問題，一篇關於 OpenCLAW 的分析 [4] 指出，LLM 本身沒有內建時鐘，當 VM 跑在 UTC（雲端預設值）而使用者在其他時區時，Agent 會在晚上 9 點跟你說早安、把今天當成昨天，而修正這個問題需要對齊四個不同的層級：系統時區、gateway 環境變數、應用程式設定、以及 Agent 層級的指令。
但問題不只這樣，因為這個誤差不是一次性的，而是每次 Agent 執行時都會累積。
具體來說，Agent 每天早上 9 點跑，記錄斷點為「今天 09:00 UTC+8」，下次執行時，它查詢「從上次斷點之後的信件」，但 Gmail API 回傳的信件時間戳是寄件人的本地時間，比如一封美西下午 5 點（UTC-8）寄的信，時間戳是 17:00 PST，換算成台灣時間是隔天早上 9 點，如果 Agent 在比對時沒有統一換算成 UTC，這封信的時間就會落在斷點的邊界上，可能被跳過，也可能被重複抓取。
關鍵在於：每次的邊界誤差不會自我修正，反而會往同一個方向偏移，第一天漏掉一個 8 小時的窗口（台灣深夜到美西下班之間的空隙），第二天這個窗口因為斷點往前推進而擴大到 16 小時，第三天就超過了 24 小時。
我發現的時候，誤差已經累積到 25 小時，也就是說大約一到兩天的工作量就這樣安靜地消失了，而且因為超過了一整天，漏掉的不再只是邊界上的零星信件，而是整段完整的工作日通訊。一篇關於國際 SaaS 時區邊界的分析 [8] 描述了完全相同的現象：「這個 bug 的隱蔽之處在於它能安靜地、不被注意地傳播錯誤，初始偏移隨著時間不斷累積。」
Agent 為什麼沒有發現？
這才是最讓我在意的部分。
Agent 每天都會抓取我的寄件備份，在那些寄件備份裡，有些回覆引用了我從未看過的來信，也就是說，我自己回過的信裡，引用了 Agent 從來沒有索引過的信件。
證據就在那裡，如果 Agent 認真讀每封寄件備份的完整內容，它應該會注意到：「這封回覆裡引用的原始信件，我的索引裡沒有。」這是一個很明顯的異常。
但它沒有。
為什麼？因為跟上一篇 Tips 3 講的一樣，Agent 用摘要的方式讀取所有東西，對它來說，寄件備份裡的引用只是「之前的往來內容」，除非有特別的理由，它不會深入展開來讀，引用區塊被當成低優先級的重複內容，直接跳過。
所以 Agent 不但漏了信，而且連自己漏了信都不知道。
一篇關於 Agent 協作中 silent failure 的研究 [5] 精確地描述了這個現象：「LLM 的輸出看起來很權威，整齊的文字、合理的結構，但沒有任何訊號告訴你錯誤是在哪裡被引入的。」大部分的框架靠的是 prompt 層級的「請再檢查一次」，而不是結構化的驗證機制，一篇針對多 Agent 軌跡的研究 [7] 則證實，這類 silent failure 只有透過專門的外部監控系統才能被偵測到。
公平地說，這不代表 Agent 永遠無法自我檢測，如果一開始就在設計中加入一個獨立的驗證 Agent，專門負責比對索引和寄件備份的引用、檢查時區邊界的覆蓋率，這個問題是可以被自動捕獲的，所以問題不在於 Agent 做不到，而在於如果你沒有預先設計這個檢查機制，Agent 不會自己想到要做，他也不會建議你做，這個「預先設計」本身就需要一套方法論，我們在之後的文章會詳細討論。
但在我的這個案例裡，我並沒有設計這樣的機制(剛打造出來試用三天，等於還在試用期)，所以最後是人類發現的。
人類怎麼發現的？
很笨的方式：我自己手動讀信。
Agent 剛上線，我也是會擔心有遺漏的地方，所以我每天看完摘要，都還是會自己讀信，同時回覆信的草稿雖然是 Agent 起草框架，但很多前因後果 Agent 並不知道，所以最後都會是我補上 Context 來回覆，而某天回覆一封信的時候，我注意到同事在討論一個我完全不知道的決定，回去翻信箱才發現，相關的討論串 Agent 根本沒有抓到，這才觸發了我完整的 audit。
修正的過程
回頭追查，問題分成兩層：
第一層：時區處理。 斷點時間的記錄和比對需要統一用 UTC，不能用本地時區，月份歸屬也不能單看信件的顯示時間，比如一封顯示 2022-06-01T00:39:28+08:00 的信，實際上可能是美西時間 5/31 寄出的，它到底屬於五月還是六月，要看 Gmail 查詢的結果集，不是看時間戳的表面數字。一篇 Cron 排程的時區處理指南 [11] 也指出，日光節約時間的轉換會讓排程任務提前一小時、重複執行、或直接跳過，而 Cron 本身沒有內建的 DST 支援。
第二層：過濾規則。 在 audit 過程中還發現，信件過濾規則寫得太寬，原本只該根據寄件人和主旨過濾，但實際上連信件內文都在過濾範圍內，導致正常的工作信件因為內文提到了某些關鍵字而被漏掉。
這兩個問題加在一起，造成的結果就是：有些信因為時區被跳過，有些信因為過濾被誤殺，而 Agent 對這兩種情況都沒有察覺。一篇 AI Agent 靜默停機 6 小時的案例分析 [10] 描述了幾乎相同的情境：健康檢查跑了 180 次，每次都記錄「warning」但從未 escalate，47 則訊息延遲、3 個對話無回應，而系統「運作中但無效」。
我跟 Agent 討論修正之後建立了一套 audit 規則：
- 先比對信件 ID 集合 — 不要先看內容，先確認數量和 ID 是否一致
- 時間戳顯示差異視為次要 — 跨時區的顯示差異不代表抓取錯誤
- 過濾規則只看寄件人和主旨 — 不要碰信件內文
- 以 Gmail 查詢結果作為月份歸屬的唯一依據 — 不以儲存的時間戳判斷
隱性假設是最危險的 Bug
回頭看，這整個問題的根源不是 Code 寫錯或者 Agent 做錯事(雖然實際上就是做錯了)，而是一個 Agent 內部的 隱性假設 造成的，也就是 Agent 假設所有的工作都發生在同一個時區。
這個假設沒有被寫在任何地方，你不會在 plan prompt 裡看到我說「用台灣時間處理所有信件」這句話，它是 Agent 在實作時自然而然採用的預設值，因為建立 Agent 的人在台灣，session 的系統時間是 UTC+8，所以所有時間計算都用了 UTC+8。
Agent 不會主動質疑自己的假設(除非你叫他這麼作)。它不會問你：「你的團隊跨幾個時區？」也不會在抓取信件時檢查：「這些信件的寄件時區分佈是什麼？我的抓取範圍有沒有涵蓋所有時區？」
這就是第十三篇談的「已知陷阱」的另一種變體，而 Agent 把它在 session 中觀察到的環境條件當成普遍事實，然後基於這個「事實」去執行所有後續工作。
不只是時區的問題
這個案例的啟示不限於時區，任何 Agent 在以下情境都可能踩到類似的坑：
- 排程任務 — Agent 假設你的工作日是週一到週五，但你的團隊有人在週六工作
- 語言處理 — Agent 假設所有信件都是英文，但有些內部溝通用中文
- API 呼叫 — Agent 假設 API 回傳的時間是 UTC，但某些 API 回傳的是伺服器本地時間
- 檔案路徑 — Agent 假設你在 macOS 上工作，但專案的 CI 在 Linux 上跑
共通的模式是：Agent 從它被建立時的環境條件推導出一組假設，然後把這組假設當成永恆不變的事實。
一篇分析多 Agent 系統失敗原因的論文 [6] 發現，「帶著錯誤假設繼續執行，而不是停下來尋求澄清」佔了多 Agent 協調失敗的 6.8%，LLM 會不加質疑地接受有缺陷的輸入，缺乏根據情境判斷並挑戰同伴資訊的直覺。Stack Overflow Blog 的一項分析 [12] 也指出，AI 產生的 bug 是人類的 1.7 倍，其中邏輯錯誤多了 75%，而隱性假設正是邏輯錯誤的一個主要來源。Cloud Security Alliance 的報告 [13] 則顯示，只有 21% 的組織維護即時的 Agent 運作清單，這意味著大部分團隊根本不知道他們的 Agent 在做什麼假設。
我的觀察
或許這個案例最值得記住的不是時區的技術細節，而是兩件事：
第一，Agent 不會告訴你它做了什麼假設， 你必須自己去想：「這個 Agent 在什麼環境下被建立的？它可能把什麼環境條件當成了預設？」這跟 debug 程式碼不一樣，程式碼的 bug 會報錯，但假設的 bug 會安靜地執行，直到後果大到你不得不注意。
第二，Agent 不會預設自我驗證， 就算漏信的證據就在寄件備份裡，它也不會主動去核對、驗證，這不是 Model 的能力問題，因為如果你明確告訴它「請比對你索引的信件和寄件備份中引用的信件是否一致」，它做得到，但它不會自己想到要做這件事。
25 小時的誤差，累積了好幾天，最後是人類在手動回信時偶然發現的。
或許這就是目前 Agent 協作最需要警覺的地方：Agent 執行得越順暢、越安靜，你越需要定期抽查它到底在做什麼。 因為真正危險的問題，從來不會主動跳出來告訴你。
但「定期抽查」不是長久之計，如果你真的想讓 Agent 自動化地運作，你需要的不是一個更小心的 Agent，而是另一個 Agent 來檢查它，一個獨立的驗證機制，帶著明確的方法論，知道該檢查什麼、怎麼檢查、以及什麼程度的偏差需要警報。
這就是接下來四篇文章要談的事：怎麼從經驗中萃取方法論、怎麼把方法論轉成 Agent 可以執行的 Playbook、以及怎麼把 Playbook 落地成可靠的執行計畫，因為今天這篇踩到的坑，比如時區盲點、摘要遺漏、隱性假設，每一個都可以被系統性地預防，前提是你願意先把「怎麼預防」這件事本身變成一套方法論然後落地變成 System，所以從下一篇開始，我們回到思維轉變，也就是 Mindset & Workflow 章節繼續。
參考資料：
[1] 實戰 Tips 3：Agent 讀取的陷阱 — Agent 摘要讀取造成的細節遺失 /articles/15-tips-agent-reading-trap
[2] 實戰 Tips 1：Agent 的「已知」陷阱 — Agent 把 session context 當成理所當然的已知 /articles/13-tips-agent-context-trap
[3] 第三篇：Context Engineering — Context 的精確度決定 Agent 的品質 /articles/3-context-engineering
[4] AI Agents Getting the Date Wrong? — NZ365Guy — LLM 沒有內建時鐘，時區需要四層對齊 https://nz365guy.com/blog/ai-agents-timezone-configuration-openclaw
[5] Agent Orchestration Failure Modes: Silent Drift — Agent 間的 silent failure 與缺乏結構化驗證 https://glenrhodes.com/agent-orchestration-failure-modes-silent-drift-reconciliation-and-the-supervision-mindset-shift/
[6] Why Do Multi-Agent LLM Systems Fail? — arXiv — 6.8% 的多 Agent 失敗來自「帶著錯誤假設繼續執行」 https://arxiv.org/abs/2503.13657
[7] Detecting Silent Failures in Multi-Agentic AI Trajectories — arXiv — Silent failure 只有外部監控系統才能偵測 https://arxiv.org/html/2511.04032v1
[8] Timezone Edge Cases in International SaaS — DEV Community — 時區偏移會在每次存取時累積 https://dev.to/tomjstone/international-saas-nightmare-timezone-edge-cases-and-how-to-solve-them-once-and-for-all-57hn
[9] Google AI Overview Has a Timezone Bug — Shekhar Gulati — Google AI 因為 PST/IST 時差把星期六判斷成星期五 https://shekhargulati.com/2025/03/23/google-ai-overview-has-a-timezone-bug/
[10] AI Agent Silent Failures: 6 Hours of Undetected Downtime — DEV Community — Agent 跑空佇列 6 小時，180 次健康檢查都沒有 escalate https://dev.to/bobrenze/ai-agent-silent-failures-what-6-hours-of-undetected-downtime-taught-me-about-monitoring-3ja8
[11] Handling Timezone Issues in Cron Jobs — DEV Community — 日光節約時間讓排程任務提前、重複、或跳過 https://dev.to/cronmonitor/handling-timezone-issues-in-cron-jobs-2025-guide-52ii
[12] Are Bugs Inevitable with AI Coding Agents? — Stack Overflow Blog — AI 產生的 bug 是人類的 1.7 倍，邏輯錯誤多 75% https://stackoverflow.blog/2026/01/28/are-bugs-and-incidents-inevitable-with-ai-coding-agents/
[13] The Visibility Gap in Autonomous AI Agents — Cloud Security Alliance — 只有 21% 的組織維護即時的 Agent 運作清單 https://cloudsecurityalliance.org/blog/2026/02/24/the-visibility-gap-in-autonomous-ai-agents
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
