Context7：善用Skill和子代理，不要只靠MCP

很多開發者透過MCP連接Context7來查最新的函式庫文件。確實能用 - 在編碼過程中直接拿到最新文件。但有個代價：每份拉進來的文件都直接落在主上下文視窗裡。查個兩三個函式庫，上下文就快滿了。長時間編碼下來，效能明顯下降，前面討論過的細節也開始被遺忘。

我一直在想怎麼用Claude Code的Skill和子代理來解決這個問題，實際用起來差異相當大。

單純MCP連線的瓶頸

直接透過MCP呼叫Context7時，完整的文件內容會直接串流進主上下文。偶爾查一次沒問題。但實際工作中，你很少只查一樣東西。

先查個React Hook的文件，再查Tailwind的工具類別，然後又查Astro的API。每次回應都疊在前一次上面。上下文視窗越來越滿，模型開始忘記前面的對話 - 你真正的程式碼、你的需求、三輪對話前做的架構決策。

就像Manus團隊在架構筆記裡強調的，一個巨大的上下文並不是解答。關鍵洞察是：不是所有東西都需要放在同一個上下文視窗裡。

Skill與子代理：隔離式上下文查詢

Context7外掛提供了兩個機制，讓文件查詢不會汙染你的主上下文。

• Skill：當你問到某個函式庫或API的問題時，Context7會自動觸發。它去抓最新文件然後回應，不需要你寫任何特殊提示。整個查詢在背景完成。
• docs-researcher代理：這是架構上的核心。文件查詢在隔離的上下文中執行 - 由獨立的子代理處理查詢、擷取相關內容，只把答案傳回來。你的主上下文完全不會碰到原始文件。

想要明確查詢文件時，可以用這個指令：

/context7:docs <函式庫> [查詢內容]

這讓你掌握主導權，同時把繁重的工作隔離在主上下文視窗之外。

安裝方法

在Claude Code中安裝Context7外掛：

/plugin marketplace add upstash/context7
/plugin install context7-plugin@context7-marketplace

設計上的差異

同樣的Context7後端，兩種做法在實際使用上產生截然不同的結果。

單純MCP：每次查文件都會增加主上下文的負擔。查個三次，上下文視窗就被吃掉一大塊。到了工作中段，模型對你專案狀態的記憶力已經明顯衰退。

Skill + 子代理：文件查詢在隔離的上下文中進行。只有擷取出的答案 - 特定的函式簽名、設定選項、使用範例 - 才會回到主上下文。原始文件完全不會碰到它。

這個模式一次解決兩個問題。它透過拉取即時文件來解決知識截止日期的問題，同時不會破壞長時間編碼的穩定性。你拿到了最新資訊，卻不用付出上下文的代價。

更廣泛的原則不只適用於Context7：任何時候你要把大量外部內容拉進AI對話，都該想一下它是否需要放在主上下文裡，還是可以在隔離環境中處理再摘要回來。這個架構決策 - 隔離與摘要 - 就是讓一個對話能持續數小時保持精準，還是開始忘記你在做什麼的關鍵分水嶺。