上一篇我們聊了怎麼把 Skill 打包成 Plugin，這篇來談一個更基礎、但很多人沒意識到的問題：你的 Agent 真的有讀完你給他的東西嗎？
前幾天我從 Claude Code 外洩的原始碼 [3] 中拆解了 /insights 指令 [1]，主程式碼有 3,200 行 TypeScript。在拆解的過程中，我踩了一個很經典的坑：同樣的檔案，用三種不同的方式讓 Agent 讀取，產出了三種截然不同的結果。
Agent 怎麼讀東西？
先講一個很多人可能不知道的事實：Agent 讀取大量內容時，預設都是用摘要的方式。
不管對象是網頁還是檔案，當內容超過一定長度，Agent 不會逐字閱讀，他會把內容拆成多個 section，對每個小區塊做摘要，然後把摘要拼起來當作「讀完了」，就算你明確告訴他「請完整讀取」，他很多時候還是會用 subagent 對小區塊做摘要，只是摘要的精細度會提高一些。
這不是某一家的特例。Cursor 的 Agent 預設只讀取檔案的前 250 行 [7]，Claude Code 的 Read tool 預設上限是 2,000 行，WebFetch 則是用較小的模型（Haiku）對抓回來的網頁做摘要後才交給主模型 [8] — 你拿到的從來不是原始內容。
這個行為在大部分場景下是合理的，你讓 Agent 讀一篇部落格文章、掃一份文件、或者用 Web Fetch 抓一個網頁的重點，摘要完全夠用。
但當你的目的是要 Agent 基於讀到的內容來「建構」東西時，這個行為就會變成一個隱形的陷阱。
三種讀取深度，三種結果
拆解 /insights 的時候，我對同一份 3,200 行的 insights.ts 嘗試了三種指令：
第一種：「讀取這個檔案，告訴我他在做什麼」
最自然的指令，Agent 會快速掃過整個檔案，產出一份結構化摘要：這個檔案大概在做什麼、有哪些主要函式、流程是什麼，很大一部分跟讀取動作採用降級的模型有關係。
結果： 提取出來的邏輯不能用，關鍵的 prompt 內容被跳過，函式之間的依賴關係被簡化，很多重要的條件判斷直接消失了。
第二種：「強迫完整讀取」
明確告訴 Agent：「請逐段讀取，不要跳過任何部分。」Agent 會更認真地處理每一段，但仍然會對細節做一定程度的壓縮。
結果： 提取出來的邏輯可以用，但產生出來的報告怪怪的，格式對、結構對，但內容的精準度差了一截，有些分析維度被混在一起，有些 prompt 的微妙差異被抹平了。
第三種：「不要摘要，一行不漏地讀」
最極端的指令。Token 用量暴增，但 Agent 終於真正看到了每一行程式碼。
結果： 提取出來的邏輯跟原始的一樣。所有 prompt 的細微差異都被保留，函式的依賴關係完整，條件判斷一個不漏。
三種方式，Token 用量差距巨大，產出品質也天差地遠。
為什麼 Agent Prompt 特別容易被摘要害到？
自然語言有冗餘，同一個意思可以用不同的句子表達，省掉幾句話不影響理解。但精煉過的 Prompt 的密度極高，每一個詞都有明確的目的，省掉一行可能就直接忽略掉了一個關鍵的邊界條件。
Factory.ai 在一項針對 Context 壓縮的研究中發現 [4]，通用摘要會系統性地丟棄 Agent 需要的資訊：檔案路徑、技術細節、決策脈絡都會被當成「低熵內容」消失，artifact tracking 的評分只有 2.19-2.45（滿分 5.0）。Chroma 的研究則指出 [5]，在典型的 20,000 token context 中，真正相關的程式碼只佔約 2.5%，而當摘要壓縮把這 2.5% 的關鍵資訊再打折，品質自然直線下降。
/insights 的原始碼裡有一個很好的例子：它在讀取 session 對話紀錄做分析時，使用了多組不同的 prompt。乍看之下這些 prompt 很像，都是要 LLM 分析對話內容，但仔細看，每一組都有細微差異：有的強調摩擦點的分類，有的強調使用模式的歸納，有的聚焦在建議的可行性。
當 Agent 用摘要方式讀取時，這些 prompt 會被歸納成「多組分析 prompt」，在這裡細微差異被摘要平均掉了，結果就是前面說的「第二種」：報告會出來，但品質差了一截，因為那些被抹平的差異正是每組 prompt 存在的理由。
換個角度想，這其實很合理，如果這些 prompt 不需要細微差異，Anthropic 的工程師何必拆開？直接用同一組 prompt 加參數就好了，何必要寫多組？ 刻意拆開，就表示每組的差異是有意義的，而摘要把這些意義抹掉了。
從 Anthropic 的設計學到的事
拆解一家開發 AI Runtime 和 AI Model 的公司怎麼設計自己的 AI 工具，其實是一個非常好的學習機會。
他們在 /insights 裡做的事情，某種程度上就是在示範 Context Engineering 的實戰應用，把不同的分析任務用不同的 prompt，每組 prompt 精確控制 LLM 的注意力方向，而不是用一個萬用 prompt 試圖處理所有情況。
這跟我們在第三篇 Context Engineering [2] 裡討論的原則是一致的：Context 不是越多越好，而是越精確越好， Anthropic 自己在實作時也是這麼做的。
什麼時候摘要 OK，什麼時候要完整讀取？
這不是說摘要讀取不好，它在很多場景下是最佳策略：
摘要讀取適合：
- 快速掌握一個方向（「這個 repo 大概在做什麼？」）
- Web Fetch 抓取網頁重點
- 初步評估一份文件是否相關
- 瀏覽 changelog 找特定版本的變更
完整讀取必要時：
- 要基於讀到的內容建構東西（寫程式碼、提取邏輯、重構架構）
- 原始碼密度高、且細微差異有意義
- 多個相似但不同的設定檔或 prompt
- 之前用摘要讀取後產出的結果「怪怪的」— 這通常是一個訊號
實務上的判斷原則：如果你要 Agent「理解」就好，摘要夠了，如果你要 Agent「重現」或「建構」，就需要完整讀取。
當你發現 Agent 漏了東西
最後一個實務觀察：當你發現 Agent 的產出漏了某個東西，比如少了一個條件判斷、忽略了一個邊界情況、混淆了兩個相似但不同的概念，很高機率不是 Agent 的推理能力有問題，而是他在建立基礎知識的階段就因為摘要而丟了細節。(或者踩到了 Agent 的”已知”)
Claude Code 的 GitHub Issue #7533 [6] 記錄了一個典型案例：經過 2-3 次 context compaction 後，Agent 不再完整讀取檔案，改用 grep 和部分讀取拼湊資訊，然後用「模式匹配假設」填補空缺。開發者的結論是：「寧可正確編輯然後用完 context，也不要為了保留 context 而做出錯誤的編輯。」
這時候不要急著 debug 產出，回頭看看他讀了什麼、怎麼讀的。很多時候，問題不在後面的推理，而在前面的輸入。
東西不大的時候，你可以靠事後 debug 來修，Agent 漏了什麼就補什麼，但東西大的時候，像 3,200 行的原始碼，這種事後修的成本比一開始就讓他完整讀取高太多了。
或許這就是跟 Agent 協作最容易忽略的一件事：我們花很多時間在校準 Agent 的輸出，卻很少回頭檢查他的輸入，而有時候輸入的品質，往往在他「讀」的那一刻就已經決定了。
參考資料：
[1] 從外洩原始碼拆解 Claude Code /insights — 實際拆解案例 /resources/claude-code-source-insights
[2] 第三篇：Context Engineering — Context 不是越多越好，而是越精確越好 /articles/3-context-engineering
[3] 新聞：Claude Code 原始碼全面外洩 — 外洩事件報導 /news/claude-code-source-leak
[4] Evaluating Context Compression for AI Agents — Factory.ai — 通用摘要如何系統性丟棄 Agent 需要的資訊 https://factory.ai/news/evaluating-compression
[5] Context Rot — Chroma Research — 18 個模型的 context 退化實測 https://www.trychroma.com/research/context-rot
[6] Claude Code Issue #7533 — Context preservation vs correctness — 摘要讀取導致錯誤編輯的實際案例 https://github.com/anthropics/claude-code/issues/7533
[7] Dynamic Context Discovery — Cursor Blog — 為什麼截斷工具回應會造成資料遺失 https://cursor.com/blog/dynamic-context-discovery
[8] Inside Claude Code’s Web Tools — Mikhail Shilkov — WebFetch 永遠不會回傳原始內容 https://mikhail.io/2025/10/claude-code-web-tools/
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
