Amp Code 創辦人、同時也是 “How AI Is Built” podcast 主持人 Nicolay Gerold 寫了這篇 Kirby Is Eating Context Engineering，用任天堂角色「卡比」來比喻前沿模型正在發生的事: 卡比吸入敵人就能複製對方的能力——劍、火焰、槌子，吃什麼就變什麼。現在的 LLM 也是如此，上個月還需要精心設計的功能和 prompt，這個月只要給點基本指示就搞定了。

這篇文章把 context engineering 的全貌講得蠻清楚的: 從問題本質、現有解法、到接下來的趨勢，是一份很好的 coding agent 技術地圖。以下順著他投影片的脈絡來整理重點:

做 LLM 產品的「恐懼感」

Nicolay 說他在 Amp 工作時，耳邊永遠迴盪著同事 Thorsten 的聲音: Everything is changing。在 LLM 產品這個領域，他經常問自己的問題是: 什麼時候卡比會把我們整個產品吞掉?

Amp 團隊以「刪得快」聞名——他們會積極砍掉不符合未來方向的功能:

  • Plan mode 被砍了
  • Thread 分叉功能被砍了
  • VSCode extension 是下一個

但他強調: 前沿(frontier)永遠不會消失，它只是不斷移動。 在 LLM 能力的邊界上，永遠有東西需要被建出來。而現在正在被吞噬的，就是 context engineering。

Context Engineering 入門

從最底層來看，LLM 的世界其實很單純: 模型權重 + 一坨 token + next-token prediction。你又不能去訓練模型，所以對你來說，整個輸出就是輸入的函數。

如果只是聊天，輸入就是你貼進去的文字。但 Agent 加了一層 runtime: tool calling。模型吐出結構化的 JSON 呼叫工具 (read_file、grep、bash 等)，runtime 執行後把結果回傳到 context window，模型再根據新資訊預測下一個 token。

所以有效輸入 = 你的 prompt + 所有工具呼叫帶回來的結果。

對 Amp 這樣的 coding agent 來說，模型對你的 codebase 一無所知——它知道的只有你放進 context window 的東西，加上它自己透過工具呼叫發現的東西。

Context Rot: 問題不是太長，而是累積了什麼

理論上聽起來不錯，但每次工具呼叫都會往 context 裡塞更多東西: 讀到的檔案內容、指令輸出、錯誤訊息、重試紀錄。有些有用，有些沒用。模型讀錯檔案、grep 到不相關的結果、做出錯誤判斷。

Chroma 的研究把這個現象叫做「Context Rot」: 隨著 context 累積，模型表現反而變差。Nicolay 認為問題不只是長度，而是「累積了什麼」。他列出七種 context 汙染:

🔹 錯誤資訊 — 模型幻想一個不存在的函數，以為叫 getUserById，實際上叫 findUserById

🔹 模糊資訊 — 「更新 config」有十幾種可能的解讀，.env? helm/values.yaml? config/prod.yaml?

🔹 無關資訊 — 內容是對的，但沒用。例如問 auth 系統的問題，結果 agent 找到的是 system prompt 裡的 auth 相關資訊

🔹 不完整資訊 — 有些片段存在，但關鍵細節缺失，模型就會用猜的來補洞

🔹 遺漏資訊 — 關鍵資訊根本不在 context 裡 (正確的 repo 路徑、環境變數、特定檔案)，後續步驟全都是猜測

🔹 冗餘資訊 — 重複的需求、log、幾乎一樣的文件，把真正重要的細節擠出窗口

🔹 矛盾資訊 — README 說一套、程式碼做一套、CI 又用第三套，模型只能隨機選一個

關鍵在於: 模型沒有遺忘的能力。窗口裡的所有東西——不管對錯、不管相關不相關——都會影響下一個 token 的生成。

Nicolay 附了一個具體的例子: 一個 27.6k token 的 context window 裡，有將近一半 (49%) 是 rot——錯誤、無關、冗餘、矛盾的資訊佔了 13.4k token。

使用者端的 Context Engineering 手法

Context engineering 的本質就是手動控制 context rot: 決定什麼該進 context window、什麼不該。這一開始是使用者自己的工作流程，後來逐漸被內建到 coding agent 裡。

1. 頻繁刻意壓縮 (Frequent Intentional Compaction)

Dex Horthy 是最早分享這套手法的人之一。他不是去對抗 context rot，而是直接清除它。工作流程分三步:

  • Research: Agent 讀 codebase、追蹤相關路徑，把發現寫進 research.md。這一步只找「現狀是什麼」——有哪些元件、程式碼引用、使用的 pattern、架構。在這裡抓到錯誤最便宜，一個錯誤假設會在後面滾成幾千行垃圾程式碼
  • Plan: 把 research.md 餵給模型，產出從現狀到目標的 step-by-step 計畫。計畫裡的一行錯誤會變成幾百行錯誤程式碼，在這裡抓到只花五分鐘
  • Implement: Agent 用乾淨的 context window 開始寫程式，手上只有精煉後的計畫

每一步之間傳遞的只有一份壓縮過的 .md 文件。每一步都是在「修剪」對話。

2. Plan Mode

Amp 早期就內建了 Plan mode: 強制在實作之前先做規劃。模型只有讀取和寫計畫的工具，不能做別的。計畫完成後，交給新的 thread 去實作。

但他們在正式發布之前就砍了這個功能。

3. Handoff

Handoff 是 Nicolay 自己做的功能，但他預期這個功能也快被砍了。它會從當前對話中做結構化萃取: 挑出相關檔案、重要決策和限制條件、使用者目標，然後打包成一個新 thread 的起點。

重點是: Handoff 不是把完整記錄搬過去，也不是做全文摘要。它是針對性的 context 轉移——只帶「繼續工作需要的東西」到新 thread。

4. Subagents

另一個解法是按範圍切割工作。不讓一個 agent 又搜尋又實作又 review，而是拆成多個子 agent: 一個負責 review diff，一個負責搜尋 pattern，一個負責實作。主 agent 只拿到精簡的輸出，不需要承載每個子 agent 的完整 context 歷史。

Nicolay 的例子: 子 agent 們總共用了 21.8k token，但主 agent 只看到 590 token 的結果。

但卡比正在吞噬這些

以上這些手法都有共同的問題:

  • 非常依賴使用者主動操作
  • 可以被訓練進模型裡
  • 學到的東西僅限於當前 thread，下次什麼都不記得

Nicolay 分享了他最近用 Codex 5.3 和 MiniMax M2.5 的體驗: 他刻意不寫 .md 檔案、不用 handoff、不碰 subagent，但模型自己就會做這些事。它會暫停、檢查 codebase、在腦中勾勒計畫，然後才開始改程式碼。它會在大改動前跑小的驗證迴圈，從錯誤的讀取中自己恢復，還能記住 thread 裡前面提過的事。

Context engineering 正在被訓練進模型裡。 透過在更長的軌跡上訓練，模型學會了自己做 context 管理。

編按: Nicolay 的論述主要是針對 coding agent 這個領域。寫程式有明確的驗證訊號 (測試通過、build 成功、lint 乾淨)，模型可以透過大量 coding 軌跡來學習更好的 context 管理策略。但對於其他類型的 AI 應用——RAG 系統、客服 agent、資料分析 pipeline——context engineering 的各種手法恐怕還遠遠沒有被「吞噬」，仍然是開發者需要花心力設計的核心工程。

另外，Nicolay 說「被訓練進模型裡」，但他舉的例子是 Codex 5.3 這樣的完整 coding agent 產品，不只是裸模型。像 /compact、subagent 拆分、context 搬移這些能力，更多是 coding agent 框架在做的事，不純粹是模型本身學會的。模型透過 longer trajectories 訓練確實會學到更好的 tool use 策略 (先看再改、小步驗證)，但把這些全歸功於「模型進步」可能稍微簡化了一點。更準確地說，是 coding agent 這整個系統 (模型 + 框架) 在進步。

從 Context Engineering 到 Codebase Engineering

既然模型越來越擅長管理自己的 context，新的瓶頸就變成: 模型仍然無法可靠推斷或自己搞定的那些東西。

不管你叫它 compound engineering、agentic feedback loops 還是 factory，概念都一樣: 把知識外化、把能力加進 repo，讓 agent 不用從零開始。

順著模型的紋理走

如果 agent 一直用 .flush() 而不是你命名的 .clear()，別跟它硬槓——重新命名你的方法。Agent 會被訓練資料引導，傾向用統計上最常見的名稱。你用個人偏好去覆蓋它，只是讓每次搜尋都更困難。順著模型的直覺，讓它靠肌肉記憶導航，而不是猜測。

重構以利於 Agent 搜尋

如果 agent 一直讀錯檔案，問題不在 agent，在 codebase。為了 greppability 重構: 重新命名讓 agent 的搜尋 pattern 能對上你的程式碼。

如果 agent 在一個巨大檔案裡 read_file 二十次才找到重要的部分，把檔案拆開。如果你的 fuzzy-finder 放在叫 hound 的目錄裡（因為你覺得很幽默），改名。一個對齊常見 pattern 和標準命名的 codebase——模型在訓練時看過幾百萬次的慣例——在它讀第一個檔案之前就已經贏在起跑點了。

還有一點: 確保 codebase 內部一致。如果 README 說一套、程式碼做一套、config 註解又指向第三種做法，agent 只能隨機選一個。更新過時的文件、移除過時的註解、刪掉互相矛盾的重複設定檔。

外化知識

每次你發現自己在跟 agent 重複解釋同一個 pattern、慣例或限制，停下來問: 為什麼這個不在 repo 裡? 加到 AGENTS.md 裡，用簡短精確的規則寫。隨著累積，agent 就能在一個檔案裡找到答案，而不是讀五十個檔案還搞不清楚。太大了就放到 docs/ 資料夾，在 AGENTS.md 保持索引。

增加能力，但要讓工具便宜

有時 agent 需要一個還不存在的能力——驗證 migration 的腳本、包裝內部 API 的 wrapper、不會撐爆 context window 的建置方式。把它做成 CLI、腳本或工具，check-in 到 repo 裡。

但要注意: 工具是昂貴的。它們一次全部載入，在 agent 寫第一行程式碼之前就佔滿 context window。他舉了一個例子: 光是加上 GitHub、Notion、Linear、Postgres 四個 MCP server，就要吃掉約 28k token。

解法是把工具打包成 Skills——agent 按需載入的模組，任務需要時才載入。或者把工具變成可搜尋的檔案，模型搜到後再透過 CLI 呼叫。

讓 Context 撐得更久

長時間的 session 會被噪音填滿。解法有幾種:

🔹 主動修剪: 把失敗的工具呼叫、找不到的檔案、已經修好的 lint 錯誤從窗口中移除，騰出空間給有用的 context

🔹 Session 壓縮: 移除重複的檔案讀取（只保留最新一次）、摘要巨大的輸出（10k+ token 的測試結果壓縮成重點）。Session 縮小但不失去關鍵決策

🔹 Context 搬移: 當 thread 太重，分叉到新的 thread，只帶走重要的東西。Nicolay 展示了兩種策略: 一種是「摘要 + 保留最近訊息」，把舊的對話壓縮成摘要，保留最近幾輪的完整內容 (85k→14k)；另一種是「針對性萃取」，只抽出相關檔案和關鍵決策帶到新 thread (82k→10k)，更像是 agent 層級的 Handoff

建立 Feedback Loops

沒有 feedback loop，agent 就是在盲目工作——看不到自己行動的後果。

  • 把核心邏輯包成 CLI 讓 agent 可以直接執行
  • 接上截圖能力讓它看到剛改的 UI
  • 設 tmux session 讓它能啟動、操作、檢查跑起來的 process
  • 讓 agent 去改 GitHub Action、push、檢查結果，反覆迭代直到成功
  • 給它一個資料庫副本和要最佳化的 SQL query，搭配 benchmark 腳本讓它自己跑
  • 建 高擬真的 mock (不是回 200 OK 的 stub)，讓 agent 可以在本地端跑完整流程
  • 加 確定性的 hook: pre-commit 跑 linter、post-edit 驗證型別、stop hook 在 agent 繼續之前檢查它的工作

Nicolay 觀察到最新的模型已經聰明到可以自己做這些: 把商業邏輯變成 CLI、用 API 做 fuzzer、寫 custom linter 在每次編輯後執行。

他總結的 pattern 是: 原本活在你腦袋裡的、部落知識裡的、上週導致失敗的東西，被萃取出來編碼進系統。 Codebase 變更乾淨，agent 變更能幹。明天的執行比今天更好——不是因為模型進步了，而是它周圍的一切都進步了。

卡比也會吞噬這些

Nicolay 認為模型最終也會學會自己做 codebase engineering。模型可能會強到能一次完成大部分任務，或者變成夠強的工具建造者，能在執行過程中自動生成驗證工具、腳本、mock 和 eval loop。

Codex 的 /compact 已經好到 session 修剪和 context 搬移在某些工作流程中不再那麼重要了。

目前 Agent 仍未解決的問題

最後他指出兩個還沒被解決的缺口:

🔹 自動記憶萃取: Agent 不記得昨天做了什麼、做了什麼決策、什麼東西壞了。他提到 Openclaw 的做法: Agent 在 session 結束前把關鍵洞察寫成日記 (diary entries)，存在 memory/ 目錄裡。經過時間累積，agent 會反思這些日記，把它們蒸餾成 AGENTS.md 的更新。觀察 → 記憶 → 規則，一條完整的學習鏈。

🔹 自動觸發的 Agent: 目前還是大量人工複製貼上——把 bug report 貼給 coding agent、把 log 複製過去讓它診斷。Nicolay 想要的是能被 log、CI 失敗、告警、bug report 自動觸發的 agent，它們自己重現問題、開始在 codebase 裡工作、push 到 main。有些任務可以自動解決，有些應該升級給人類處理。

以上，這篇文章涵蓋面很廣: 從 context rot 的本質、使用者端的 context engineering 手法、到模型如何吞噬這些手法、再到 codebase engineering 的轉向。小編覺得最有價值的洞見是那句話: 「前沿永遠不會消失，它只是移動。」你今天精心設計的 context 管理策略，明天可能被模型內化了——但新的邊界問題又會浮現，而那才是值得投入的地方。