你打造的每一個 AI agent，都有同一種病。
它越聰明、串接越多工具、處理越複雜的任務，就越會毒害自己的思考能力。越強大，表現反而越差。
沒什麼人在討論這件事。大家聊的是 benchmark 分數、新模型發布、哪個框架在 GitHub 上最火。但檯面下，每個認真做 AI 工程的人都在跟同一個隱形怪獸搏鬥：context window 汙染。
如果你現在正在用 AI 打造任何東西，不論是 Agent、自動化流程、產品，搞懂這個轉變，會決定你蓋的東西能不能撐過未來 n 個月。
2026 年 2 月 17 日，Anthropic 發布了 Claude Sonnet 4.6。
媒體標題都在講 Coding Benchmark 的進步。但我認為真正重要的東西被埋在裡面：Programmatic Tool Calling 從 beta 正式轉為 GA，同時上線了一套動態過濾系統，輸入 token 砍 24%，準確率拉高 11%。
這不是什麼漸進式小改良，是 AI agent 跟外部世界互動方式的根本性重構。
而且 Anthropic 不是唯一走到這步的。Cloudflare、Google、OpenAI 全部各自獨立地得出了相同結論。當多家實驗室在沒有互相對過答案的情況下收斂到同一套架構，那就可能得稱為解決方案而僅止於實驗性的風向而已了。
AI agent 可以想像成一個人在雜物間裡解題。
那個房間就是 Context Window，他定義了模型能夠同時持有和推理的全部資訊量。每個工具定義、每筆中間結果、每個 API 回傳的資料碎片，全部被丟進這個房間。就像一個人在堆滿雜物的空間裡試圖清晰思考，Agent 開始失去聚焦在真正重要資訊上的能力。
有多嚴重？Anthropic 自己的工程團隊發現，在處理第一則使用者訊息之前，光是工具定義就吃掉了 134,000 個 token。典型的五伺服器配置光定義就燒掉 55,000 token。再加個 Jira，你還沒開始做任何有用的事，就已經逼近 100K token 的開銷。
而定義只是開頭。每次工具調用都會產生輸入和輸出，全部被塞進 context。一個涉及五項工具的流程意味著五輪推論，模型得用自然語言一一解析每個結果。每個步驟都疊加更多 token。延遲爬升、成本飆高，模型在雜訊中找信號的能力隨著每一輪迭代持續衰退。
這就是當初大家興奮地把 AI 串接到所有東西時，沒有人算到的複合稅。
2025 年中業界開始把這個問題叫做 Context Engineering。Andrej Karpathy 和 Shopify 執行長 Tobi Lütke 幫忙帶紅了這個詞，但實務上大家早就默默在做了。核心紀律就一句話：Context Window 裡只留有用的資訊，其餘全部丟掉。
這不是什麼微調最佳化的事情，這是一次思維框架的優化。
曾經建構 AI agent 的預設做法是什麼？暴力堆積：把所有東西塞進 prompt、把視窗開更大、祈禱模型自己搞定。這就像是不管三七二十一什麼都吃，然後期待身體自己消化代謝。
Manus 團隊報告過，Agentic 工作流程中平均輸入與輸出 token 的比率可以高達 100:1。每產出一個 Token 的有用輸出，你就餵了模型一百個 Token 的輸入，其中大部分是雜訊。
答案可能不是更大的胃，而是更好的飲食，至少現在是這樣。
推動這整場轉變的核心技術洞察，簡單到一講出來你會覺得「早該這樣了」。
大型語言模型是在數十億行程式碼上訓練出來的。但它們從來不是為了吐出人為設計的 JSON 工具調用格式而生的。
傳統工具調用的流程大概是這樣：Agent 收到查詢，判斷需要某個工具，輸出一個 JSON 物件指定工具名和參數，收到結果後塞進 Context，然後重複。每次往返都要一輪完整推論。每一筆中間結果都會進 Context window，不管最後到底用不用得上。
程式化工具調用把這件事完全翻過來。Agent 不再一個一個吐 JSON，而是寫一段程式碼（通常是 Python）來協調多次工具調用、處理各自的輸出、精準控制哪些資訊真正進入 Context Window。程式碼在 Sandbox裡跑完，只有最終結果回傳給模型。
差距非常顯著，以一個費用分析任務為例：要撈 20 個員工的明細、彙總支出、逐一比對預算上限、產出摘要。傳統做法？二十幾趟往返，每趟把 50 到 100 筆明細灌進 Context。程式化做法？Agent 寫一段 Python 腳本迴圈跑完所有資料，回傳一張乾淨的摘要表。
讓模型去做它真正被訓練來做的事。
我們一直在逼這些系統走進人為的互動模式，不論是僵硬的 schema、結構化輸出、預定義格式等等，但模型最深層的能力就是寫程式碼和執行程式碼。說穿了程式化工具調用其實根本不是什麼聰明的變通方案，它是把一個本來就不該存在的限制拿掉而已。
讓這件事超越「某家公司的產品更新」層次的，是那條收斂的時間軸。
2025 年 9 月，Cloudflare 發表 Code Mode。他們的 Agent 直接生成並執行 TypeScript，而不是去調用工具。Token 節省幅度：簡單任務 32%，複雜批次操作 81%。
他們 demo 裡有個很有意思的細節，當被要求建立行事曆事件時，code-mode agent 正確地呼叫了 new Date() 來判斷當前日期。而傳統的 tool-calling agent 因為碰不到 runtime 函式，直接把事件排到了一年前。
程式碼執行讓 agent 拿到的是一整個程式語言的完整能力，而不只是一組預先定義好的 schema。
2025 年 11 月，Anthropic 各自獨立地得出幾乎一樣的結論。測試案例中 token 用量從 150,000 降到 2,000。同時發布了 Tool Search Tool 讓 Claude 搜尋工具庫而不需要預先載入所有定義，光這個功能就砍掉了工具定義 token 的 85%。
2025 年底到 2026 年初，開源社群迅速跟進。Block 的 Goose Agent 加了 code-mode MCP 支援，LiteLLM 新增了跨供應商的原生支援涵蓋 Anthropic、Azure 和 Amazon Bedrock。多個 GitHub repo 各自獨立地實作了相同模式。
2026 年 2 月 17 日，Anthropic 隨 Sonnet 4.6 正式 GA。
No 實驗！No beta！而是面向未來的預設路徑。
最直接能感受到效果的應用場景，是跟 Sonnet 4.6 一起推出的網頁搜尋動態過濾。
有實作過的開發者都知道，AI agent 做網頁搜尋時，原始結果整批灌進 Context Window。SEO 填充文字、過時資訊、沾到一點邊的片段，這些雜訊全部在那裡搶模型的注意力。模型得在這些雜訊裡翻找信號，一邊燒 Token 一邊掉效能。
動態過濾的做法是讓 Claude 寫一段程式碼來後處理搜尋結果，在它們進入 Context Window 之前就完成篩選。完整的搜尋結果永遠不會碰到模型的工作記憶，只有過濾後的乾淨內容才會通過。
Anthropic 拿兩個 benchmark 做了驗證。BrowserComp 測的是 Agent 能不能瀏覽多個網站找到刻意藏起來的資訊，Sonnet 4.6 從 33.3% 跳到 46.6%。DeepSearchQA 測的是多答案問題的找齊能力，F1 分數從 52% 進步到 59%。
有一個數字值得特別停下來看：11% 的準確率提升，通常是重大模型版本升級才會帶來的幅度。但這裡模型本身沒有變聰明。是它的資訊飲食變乾淨了。
如果每次搞砸效能的原因都不是模型不夠聰明，而是塞太多垃圾給它，那我們之前到底在追求什麼？
不過 Anthropic 很坦白地指出了一個重要的細節：token 成本不見得會下降。
以 Opus 4.6 為例，雖然輸入 token 減少了，但價格加權的 token 總量反而上升。原因是 Opus 為了執行過濾寫了大量程式碼，你本質上是拿比較便宜的輸入 token 去換比較貴的輸出 token，再加上程式碼執行的額外開銷。
Sonnet 4.6 有明確的 Token 節省。Opus 4.6 則是用成本換準確率。
這種取捨沒有標準答案。只有你手上的具體工作負載和成本敏感度才能決定。能分辨這種差異的，就是認真在做工程的人跟照著教學走的人之間的分水嶺。
退一步看全貌，你會看到一套三層架構正在成形，專門對付 agent 系統裡的 context 汙染。
- 第 1 層：工具定義最佳化：Tool Search Tool 解決的是「對話還沒開始，工具定義就吃光 context」的問題。不再預先載入全部，而是讓模型自己搜尋、只載入需要的。工具定義 token 砍 85%。
- 第 2 層：工具執行最佳化：程式化工具調用解決的是「多步驟流程中，中間結果不斷膨脹 context」的問題。協調邏輯丟進沙盒跑，只有最終摘要進 context window。Token 減少 37%，準確率同步提升。
- 第 3 層：結果過濾最佳化：動態過濾解決的是「原始工具輸出夾帶大量無關內容」的問題。用程式碼在結果進 context 之前先行篩選。輸入 token 砍 24%，準確率拉高 11%。
三層可以疊加使用。一個 Agent 可以先用 Tool Search 找到對的工具，在沙箱裡程式化調用它們，再在輸出進 context window 之前過濾一輪。最終產出的是一個大幅精簡、高度聚焦的上下文，讓模型有空間好好發揮。
這就是 context engineering 在實務上的樣子。不是某一招，而是一套分層的工程紀律。
如果你現在正在建構 agent，具體該做的事：
- 用 Anthropic 搜尋 API 的人：動態過濾在 Sonnet 4.6 上自動啟用。開啟資料擷取，24% 的 token 節省和準確率提升直接到手，不用改任何程式碼。
- 在做多工具 agent 的人：盤點你的工作流程，找出那些「連續調用多個工具、中間結果量大、但最終輸出精簡」的場景。這些就是程式化工具調用的首選目標。Anthropic cookbook 裡有完整的新舊做法對照範例。
- 管理多個 MCP 伺服器的人：Tool Search Tool 可以大幅壓低你的基線 token 開銷。讓模型自己探索並只載入每次請求需要的部分。
- 用其他供應商的人：確認對應功能是否已上線。OpenAI 的 GPT-5.2 custom tools 與 Code Interpreter、Google 的 Gemini 程式碼執行、LiteLLM 的跨供應商支援，都能通往同一套架構模式。
- 在選模型的人：針對你的具體工作負載跑一次成本計算。Sonnet 省 token，Opus 換準確率。正確選擇取決於你的場景。
Anthropic 有一個一再重演的模式值得注意。他們推出一個看起來像內部工程決策的東西，開源社群跟進採用，最後變成產業標準。
MCP 是這樣。Agent skills 是這樣。Chat completion API 也是這樣（雖然那個是 OpenAI 的）。程式化工具調用正走在同一條路上。開源實作已經上線，跨供應商工具已經在出貨，多家實驗室各自收斂到相同方向。
更深層的推力是經濟學。隨著 Agent 串接的工具越來越多，傳統工具調用的 token 成本是超線性增長的。到某個臨界點，把每筆中間結果都塞進 context window 的做法就會在經濟上撐不住。程式化工具調用的價值在於把執行過程和上下文累積解耦，打斷那條失控的成長曲線。
把所有東西一股腦灌進 context window 然後聽天由命的時代正在結束。
Context engineering 的時代已經開始。
而那些真正把這件事內化的建造者，不把 Context 垃圾場，而是當成一個需要精心策展的資訊環境來對待的人，會打造出比任何靠暴力堆積建起來的東西都更快、更便宜、更強大的 agent。
要記住的關鍵是，模型不需要更多資訊。它需要的是對的資訊。
這件事對人和機器都一樣，一直都是。
本文分析依據：Anthropic 針對 Sonnet 4.6 發布的官方工程部落格、API 文件與發布說明（2026 年 2 月 17 日）；Cloudflare 的 Code Mode 部落格文章（2025 年 9 月）；Google 的 ADK context engineering 技術文件（2025 年 12 月）；Manus 團隊的 context engineering 見解；以及包括 LiteLLM 與 Goose Agent 在內的多項開源實作。文中所有引用的基準測試數據均出自 Anthropic 的公開發布結果。
