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 <library> [query]

这样既有直接控制权，又能把繁重的文档处理隔离在主上下文之外。

安装方法

在Claude Code中安装Context7插件：

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

设计上的本质差异

同样的Context7后端，两种用法在实际中产生的效果截然不同。

直连MCP：每次文档查询都会增加主上下文的负担。查三次下来，上下文窗口就被吃掉一大块。到会话中期，模型对你项目实际状态的记忆已经明显衰退。

Skill + 子代理：文档查询在隔离上下文中进行。只有提取出的答案 - 具体的函数签名、配置选项、用法示例 - 才会流回主上下文。原始文档根本碰不到它。

这个模式一举解决了两个问题。它通过拉取实时文档解决了知识截止日期的问题，同时又不会破坏长时间编码会话的稳定性。你得到了最新信息，却不用付出上下文膨胀的代价。

这个原则不仅适用于Context7：任何时候你要把大量外部内容拉进AI会话，都值得想一想 - 它是否真的需要留在主上下文里，还是可以在隔离环境中处理后只把摘要送回来。这一个架构决策 - 隔离与摘要 - 决定了你的会话是能保持数小时的清醒，还是用着用着就忘了你在做什么。