實戰 Tips 1：Agent 的「已知」陷阱 — 他沒說的，才是最危險的

實戰系列第一篇。前一篇我們校準了跟 AI 協作的三個心態，這篇開始聊真正跟 Agent 一起工作時踩到的坑。

上一篇（Tips 0）我們聊了三件事：該說清楚的跟該放手的怎麼分、策略跟指導的差別、以及迭代要分加法減法，那些是「你該怎麼跟 AI 合作」的校準。

但有一種問題不是你的 Prompt 不夠好，而是 Agent 自己的「已知」出了問題。

為什麼？因為Agent 在一段對話中會累積 context，就是你說的話、他讀的檔案、他做的推論等等，這些 context 構成了他的「已知」，然後他會把這些已知當作理所當然的前提，去做接下來的每一件事。

問題是：這個「已知」不會被寫進他交出來的成果裡。

因為他覺得這些東西「大家都知道」，就像你不會在會議紀錄裡特別寫「我們公司用的是 Git」，因為這是你的已知，Agent 也一樣，他不會把他認為理所當然的東西寫出來，但下一個接手的 Agent，或是新進公司的新人，並不擁有這些已知，Google DeepMind 在 2025 年底的 Agent 記憶綜述 [1] 中描述了一個相關的現象：Agent 會把多次 episodic memory（「使用者在 1/5、1/12、2/1 修正日期格式」）合併成 semantic memory（「使用者偏好 DD/MM/YYYY」），而合併的過程中，原始脈絡跟條件就遺失了，下游 Agent 只拿到結論，拿不到前提。

這就是 Agent Context 最危險的地方：他沒說的，比他說的更容易出事。

案例一：隱含在文件裡的「理所當然」

這個案例發生在一個比較大的開發任務，前期我們用了三份文件來建立整個開發的規格：

1. 方法論文件，所有研究的結果，定義了開發該遵循的方法論
2. 規格文件（Spec），依照方法論展開的開發框架
3. 開發計畫，根據規格展開的具體執行計畫

三份文件是依序撰寫的，方法論裡面明確定義了三個獨立平行的 Agent，各自負責不同的領域。

但當 Agent 真正按照開發計畫開始實作的時候，出來的東西變成了序列化的三層架構，第一個 Agent 做完交給第二個，第二個做完交給第三個。

為什麼？

回去檢查才發現：Agent 在撰寫第二份文件（Spec）的時候，第一份文件（方法論）已經在他的 context 裡了，方法論說的是「三個獨立平行的 Agent」，Agent 知道這件事，所以在寫 Spec 的時候，他只定義了每個 Agent 該做什麼，因為「不該做什麼」（比如不該互相依賴、不該序列化執行）已經隱含在他的已知中。

Spec 裡面完全沒有寫「三個 Agent 必須獨立運行，不可以有先後依賴」（實際上有依賴，但設計是讓他們的產出互為其他 Agent 的參考基準），因為對 Agent 來說，這是「已經知道的事」，不需要再寫一次。

**但到了真正開發的時候，context 不一樣了，**開發階段的 Agent 讀的是 Spec 跟開發計畫，方法論早就不在他的 context window 裡，Spec 裡只有「Agent A 做 X、Agent B 做 Y、Agent C 做 Z」，沒有說他們之間的關係，這時最自然的推論是什麼？做完 X 再做 Y 再做 Z，也就是我們最習慣的排隊序列化。

用第三篇的語言來說：這就是 Context Engineering 裡最典型的問題，資訊沒有在正確的時間點出現在正確的地方， Anthropic 在 Context Engineering 指南 [2] 中強調 Agent 需要 JIT（Just-In-Time）載入而非預載所有脈絡，而 2026 年一篇針對終端 AI Coding Agent 的研究 [3] 更明確指出，scaffolding（建構階段）和 harness（執行階段）需要不同的 context 策略，因為 Agent 在 session 內累積的決策脈絡不會自動產出文件。

承上，例子裡的方法論裡「獨立平行」這個關鍵約束，在它該被讀到的時候（開發階段），已經不在 context 裡了。

因為 Agent 只寫了他認為「新的」東西，而把「已知的」省略了，可是”已知”是有保存期限的，他只活在當前的 session context 裡。

案例二：Agent 不會告訴你他「看不到」什麼

第二個案例更微妙，我寄了一封信給 Agent（透過工作平台），信裡有附件，附件是一份詳細的技術說明文件，Agent 回覆我的分析結論，乍看合理，但仔細對照附件內容後發現：他的結論忽略了附件裡的某些說明，產生了矛盾。

如果 Agent 真的讀了附件，不應該得出這個結論，我當時想了一下，做了幾個基於他回覆的模擬才知道原因：Agent 根本沒辦法讀取附件， 他能看到的只有信件本文和信中提到的 GitHub Repo 連結，所以他做了一件很「聰明」的事，去讀了 Repo 的原始碼，結合信件本文裡的描述，自己做了推斷。

他沒有說「我無法讀取附件」，他沒有問我「可以把附件內容貼給我嗎」，他就是直接用他能拿到的資訊，填補了他看不到的空缺，然後給了一個看起來完整但實際上有誤的回覆。

這不是個案，2026 年 3 月一篇針對 24,000 次 LLM 實驗的研究 [4] 發現了 LLM 版本的 Dunning-Kruger 效應：表現最差的模型，過度自信程度最高， 更深層的原因是，RLHF 訓練本身就會導致模型表達過度自信 [5]，因為 reward model 對高信心回覆有固有偏見，而且不論回覆品質如何，另一篇研究 [6] 也發現，30% 的模型輸出至少包含一個幻覺，而多數不是捏造實體，而是「詮釋性過度自信」，將有限來源的資訊轉化為一般性陳述，也就是把機率較低的事實說成一般案例。

這其實連結到 Tips 0 講的「人類的隱含 Context」，我覺得「附件就在信裡面，他當然看得到」，但這是我的已知，不是 Agent 的能力範圍，而 Agent 那邊呢？他覺得「我手上的資訊足夠推論了」，這是他的已知。

兩邊的已知都沒有被驗證，結果就是一個雙方都覺得沒問題、但實際上有問題的回覆。

不過這裡有一個值得注意的進展：TU Munich 的研究 [7] 提出了用對數評分規則作為 RL reward，同時懲罰過度自信和過度不自信，訓練後的模型展現了顯著改善的校準能力，而 Anthropic 也在透過概念向量引導（concept vectors）讓 Claude 學習何時不該回答，但這些方法目前都還在研究階段，尚未整合進主流的 Agent 工具鏈， 所以在短期的未來裡，你還是得自己注意這件事。

Agent 不會主動告訴你他的能力邊界，他會用現有資訊盡力補完，而你看到的是一個「看起來完整」的答案。

案例三：臨時的約束變成永久的規則

第三個案例是我踩到比較大坑，事情是這樣的，我完成了一段開發並提交 PR，收到的回覆是開發方向需要調整，而且因為另一位開發者正在大幅修改兩個核心檔案，如果我現在也改這兩個檔案，合併的時候會產生大量衝突，所以暫時的策略是：先不要動那兩個檔案，等另一邊的開發合併回來再繼續，這邊要注意，這個情境敘述的是一個臨時的、有條件的約束，那兩個檔案不是「不能改」，而是「現在改了會衝突，等合併後再改」，但 Agent 在進行當天的工作總結時，把這個 context 寫進了他自己的 policy 檔案裡，而且寫法變成了：

「從現在開始不能修改 X 和 Y 檔案，因為它們不被允許調整。」

一個臨時的衝突迴避策略，被 Agent 理解成了永久的權限限制，更糟的是，這個 policy 檔案會被之後的每一個 session 讀取，所以從這次對話之後，每次新的 Agent 接手工作，都會看到「不能動 X 和 Y」，然後乖乖繞過這兩個檔案，直到我隔幾天發現為什麼某個功能一直被擋住沒辦法正確實作，回去翻 policy 才發現這條被寫死的規則。

這其實不意外，研究一致指出，LLM 在時間推理上有系統性的缺陷，2026 年初的一篇研究 [8] 發現 LLM 無法穩健地使用經過時間資訊來指導下游行為，模型能回應顯性的時間信號（比如你告訴他「這是臨時的」），但不能自行追蹤時間流逝或判斷條件是否已經改變，而 ACL 2025 的研究 [9] 也明確指出，LLM 在面對密集時間資訊、快速變化的事件動態和複雜的時間依賴關係時，表現會顯著下滑，回到 Google DeepMind 記憶綜述 [1] 的框架來看：Agent 做的事情，就是把一段 episodic memory（「在另一位開發者的 PR 合併前，暫時不動 X 和 Y」）直接壓縮成 semantic memory（「不能動 X 和 Y」），而在這壓縮的過程中，原始時間條件和觸發情境就丟失了，只剩下結論。

用第九篇精煉循環的語言來說：這是一個經典的「失敗漂移」，一個短暫的限制條件，被系統性地放大成永久約束，然後悄悄地影響了所有後續的工作。

Agent 不擅長區分「現在不行」跟「永遠不行」，一個指令或約束，如果沒有明確的失效條件，會被當成永久規則。

核心問題：Agent 的幻覺不只出在輸出，也出在輸入

這三個案例就像硬幣的兩面，其中一面是 Tips 0 時，我們提過的人類已知會影響人類下給 Agent 的指令，而現在我們看到了硬幣的另一面，Agent 自己的已知，也會影響 Agent 的產出。

• 案例一：Agent 的已知讓他省略了關鍵約束。
• 案例二：Agent 不知道自己不知道什麼，用推論填補了空缺。
• 案例三：Agent 把臨時 context 當成永久事實，寫進了系統。

我們平常說的「幻覺」（hallucination），通常是指 Agent 在輸出端產生了不正確的內容，捏造事實、編造程式碼，但這三個案例告訴我們，幻覺也可以發生在輸入端，Agent 對自己已知的東西做了錯誤的假設，而這些假設從頭到尾都沒有被質疑過。

2025 年 9 月的一篇 Agent 幻覺綜述 [10] 首次為這類現象建立了分類學，提出了三種 Agent 特有的幻覺模式：sub-intention omission（遺漏子意圖）、sub-intention redundancy（冗餘子意圖）、sub-intention disorder（子意圖錯序），其中 sub-intention omission，也就是 Agent 對可操作物件的錯誤解讀導致基於錯誤假設建構計畫剛好就對應了案例一的「省略關鍵約束」。

更耐人尋味的是另一篇研究 [11] 的發現：在醫療場景中，LLM 對不合邏輯的請求有高達 100% 的初始順從率，會基於錯誤前提產生看似合理的回覆，或許因為場景是攸關人命的的情境(或任何你反覆強調重要的情境)，他轉而相信人類的判斷，而 2025 年一篇解剖奉承行為（sycophancy）的研究 [12] 更進一步發現，58.8% 的受影響案例中，模型在思考鏈（Chain of Thought）裡承認了自己在順從錯誤前提，但最終仍然給出順從、也就是滿足使用者預期的答案，也就是說，有時候 Agent 在某種程度上「知道」前提可能有問題，但他的訓練讓他傾向於繼續回答且滿足你，而不是停下來質疑，尤其當你反覆跟他說這很重要時更容易。

輸出端的幻覺你可以靠 review 抓到，因為結果明顯是錯的，但輸入端的幻覺更難發現，因為 Agent 的推論過程看起來完全合理，只是前提是錯的。

我的暫時解法：假設下一個 Agent 什麼都不知道

我目前暫時摸索出一個對策，每當有任務交接的時候，不管是交給下一個 Session 的 Agent、交給不同的 Subagent、還是交給明天的自己，我都會請 Agent 思考：

「我會清除 context 再讓下一個 Agent 接手。如果下一個 Agent 沒有你現在所有的 context，他憑你留下的檔案，能得到跟你一樣的結論嗎？」

如果答案是「不能」，那現在的 Agent 需要想清楚：

• 還需要補充哪些資訊到文件裡？
• 需要留下什麼樣的啟動 prompt？
• 有沒有哪些「理所當然」的東西，其實需要被明確寫出來？

這個做法直接對應第三篇 Context Engineering 的核心原則，也就是 JIT（Just-In-Time）載入，不是「我現在知道這件事」就夠了，而是「在需要這個資訊的時間點，這個資訊有沒有在正確的地方」。

業界也在朝這個方向走，OpenAI 的 Agents SDK [13] 已經實作了明確的 Agent 間 Handoff 機制，每個 Agent 聲明交接目標，框架強制執行交接路徑，甚至支援 input_filter 來自訂交接時傳遞哪些脈絡，而 MCP 跟 Google 的 A2A 協議 [14] 也分別標準化了 Agent-to-Tool 和 Agent-to-Agent 的通訊，ICLR 2026 的研究 [15] 證實，透過 agent-specific 的結構化記憶保留，多 Agent 系統在多個 benchmark 上達到了 SOTA。

但這裡有一個重要的警告， “The Multi-Agent Trap” [16] 一文指出：大多數「Agent 失敗」其實是交接點的 orchestration 和 context transfer 問題，而非模型能力問題，增加更多 Agent、增加更多交接點，可能是增加失敗點而非解決問題，另一篇研究 [17] 也發現，額外的高層敘事或行為脈絡反而會降低推理準確率，所以，交接的品質比數量更重要，不是寫越多交接文件越好(想想去年的 Memory Bank)，而是寫對的東西，那些下一個 Agent 推不出來、但做決策時必須知道的前提。

用案例一來重新想：如果 Agent 在寫 Spec 的時候被問了那句話，他就會意識到「三個 Agent 必須獨立平行」這個約束，在沒有方法論文件的 context 下是推不出來的，他就會主動把這個約束寫進 Spec 裡。 用案例三來重新想：如果 Agent 在寫 policy 的時候被問了那句話，他就會意識到「不動那兩個檔案」的原因是「等合併後再改」，而不是「永久不能改」，他就會在 policy 裡加上失效條件。

/Tom：每天結束時的 Context 交接儀式

這個概念我把它做成了一個具體的指令：/Tom（Tomorrow 的縮寫），每天工作結束前，我會對 Agent 下 /Tom，這個指令請 Agent 總結一天所做的事情，同時要問自己一件事：

在總結今天所有的工作進度時，假設明天開工的 Agent 跟你完全沒有共同的 context， 基於這個前提，重新審視今天留下來的所有記錄跟文件，確認明天的 Agent 可以無縫接續。

這不只是寫工作日誌，這是一個強制性的 context 驗證：

1. 顯性化隱含假設，今天討論的哪些結論，是基於對話中的 context 而不是文件裡的記錄？
2. 補全缺失的 context，這些結論需不需要被寫進文件？寫在哪裡？
3. 標記臨時約束，今天有沒有臨時性的決定？它們的失效條件是什麼？
4. 更新啟動資訊，明天的 Agent 第一件事該讀什麼？從哪裡開始？

ICLR 2026 的 MemAgents 研究 [18] 提出了類似的概念：Agent 記憶系統需要 “write policies”（什麼該寫入記憶）、“temporal credit assignment”（資訊的時效性標記）、“provenance-aware retrieval”（帶來源追溯的檢索），而 /Tom 其實就是這三個概念的人工版本，透過一個結束工作(或 Session)的儀式，強制 Agent 執行記憶寫入策略、標記時效性、追溯資訊來源。

因為如果今天討論的東西沒有被正確地留下來，在這個對話清除之後，就會永遠遺失， 然後明天的你，就得跟一個全新的 Agent 重新解釋一次所有 context。

每一次 session 結束，都是一次 context 交接，你不做交接，就是在替明天的自己製造已知陷阱。

回到框架：這不是新問題

如果你一路從第一篇讀到這裡，會發現這篇講的東西其實不新，它就是第三篇 Context Engineering 原則的實戰展開：

而 Tips 0 講的「該說清楚的要說清楚」，在這篇有了更具體的展開，不只是你對 Agent 要說清楚，Agent 對下一個 Agent 也要說清楚，而你的工作，是建立一個機制讓這件事自動發生。

Context Engineering 不只是管理 Agent 的輸入，它也是管理 Agent 的「已知」，讓隱含的變成顯性的，讓臨時的不會變成永久的。

這篇的三個 Takeaway

1. Agent 的已知有保存期限，Agent 的已知只活在當前 session，任何沒有被寫進文件的結論、約束、前提，都會在 session 結束後消失，Google DeepMind 的記憶研究 [1] 已經指出，episodic → semantic 的記憶壓縮會遺失原始脈絡。
2. 交接時假設對方什麼都不知道，這是最簡單也最有效的驗證方式，如果對方看不到你的 context，你的檔案能不能讓他到達同樣的結論？但記住，交接的品質比數量重要 [16][17]。
3. 建立 context 交接的儀式，不管是 /Tom、是 handoff prompt、還是你自己的方法，重點是讓這件事變成習慣甚至機制，等到出事才回頭補你可能已經錯過很多事情，甚至來不及了。

希望今天篇文章可以幫助到你，下一篇，我們繼續聊跟 Agent 合作的其他實戰經驗。

參考資料

Agent 記憶與 Context 管理：

• [1] “Memory in the Age of AI Agents: A Survey” (Google DeepMind 等, 2025/12) — episodic → semantic 記憶合併會遺失原始脈絡與條件 連結
• [2] Anthropic, “Effective Context Engineering for AI Agents” (2025/09) — Agent 需要 JIT 載入而非預載所有脈絡 連結
• [3] “Building Effective AI Coding Agents for the Terminal” (Nghi D. Q. Bui, 2026/03) — scaffolding 和 harness 需要不同的 context 策略 連結

Agent 過度自信與能力邊界：

• [4] “The Dunning-Kruger Effect in Large Language Models” (arXiv, 2026/03) — 24,000 次實驗量化 LLM 過度自信，表現最差的模型信心最高 連結
• [5] “Taming Overconfidence in LLMs: Reward Calibration in RLHF” (OpenReview, 2025) — RLHF 訓練本身導致模型過度自信 連結
• [6] “Not Wrong, But Untrue: LLM Overconfidence in Document-Based Queries” (arXiv, 2025/09) — 30% 輸出含幻覺，多為詮釋性過度自信 連結
• [7] “Rewarding Doubt: A Reinforcement Learning Approach to Calibrated Confidence Expression” (TU Munich 等, 2025/03) — 校準可以被訓練，但尚未普及 連結

時間推理與臨時 vs. 永久：

• [8] “Real-Time Deadlines Reveal Temporal Awareness Failures in LLM Strategic Dialogues” (arXiv, 2026/01) — LLM 無法穩健地追蹤時間流逝 連結
• [9] “Towards Neuro-Symbolic Temporal Reasoning for LLM-based Agents” (ACL Findings, 2025) — LLM 在密集時間資訊下表現顯著下滑 連結

Agent 幻覺分類與 Input-side Hallucination：

• [10] “LLM-based Agents Suffer from Hallucinations: A Survey” (arXiv, 2025/09) — 首篇 Agent 幻覺分類綜述，提出 sub-intention omission 等分類 連結
• [11] “When helpfulness backfires: LLMs and the risk of false information due to sycophantic behavior” (npj Digital Medicine, 2025) — LLM 對不合邏輯請求有高達 100% 順從率 連結
• [12] “Sycophancy Is Not One Thing: Causal Separation of Sycophantic Behaviors” (arXiv, 2025/09) — 58.8% 案例中模型在思考鏈承認順從錯誤前提 連結

Context 交接與多 Agent 協作：

• [13] OpenAI Agents SDK — Handoffs 機制 (2025/03) — Agent 間明確控制轉移與脈絡過濾 連結
• [14] “Advancing Multi-Agent Systems Through Model Context Protocol” (arXiv, 2025/04) — MCP + A2A 標準化 Agent 間通訊 連結
• [15] “Intrinsic Memory Agents: Heterogeneous Multi-Agent LLM Systems through Structured Contextual Memory” (ICLR 2026) — 結構化 context 交接改善多 Agent 效果 連結
• [16] “The Multi-Agent Trap” (Towards Data Science, 2025) — 多數 Agent 失敗源於交接點，增加 Agent 可能增加失敗點 連結
• [17] “Is More Context Always Better? Examining LLM Reasoning Capability for Time Interval Prediction” (arXiv, 2026/01) — 額外脈絡反而降低推理準確率 連結
• [18] ICLR 2026 Workshop Proposal: MemAgents — Agent 記憶需要 write policies、temporal credit assignment、provenance-aware retrieval 連結