本文总结一种防止 MCP 工具输出“淹没”主上下文窗口的模式：子代理隔离 + 摘要/全文模式 + 读写分离。
当主代理直接调用 MCP 工具时，工具返回的完整响应会被注入到主上下文窗口。常见会带来两类问题：
不要把主上下文当作“存储”，而是把读操作放到隔离上下文的子代理中执行，只把蒸馏后的结果带回主上下文。
[Main] “帮我看 PR #123”
-> spawn
[Subagent（隔离上下文）]
-> PR 元信息
-> diff
-> 文件列表
-> review/评论/状态
-> 去噪 + 模式分析 + 结构化
<- 只返回摘要（或全文）
这可以视为把 上下文/Token 管理（韩文） 的“progressive disclosure”原则下沉到工具层。
给“只读查询”子代理写能力，会放大 prompt injection 或误操作的影响范围。
Context7 风格的文档检索通常把 Resolve 和 Fetch 分开：
resolveLibraryId 将模糊名称解析为精确的库 IDqueryDocs 用“ID + 问题”只拉取所需内容这种结构不仅适用于文档，也可以推广到其他 MCP 集成。
子代理可以把这些打包成一次“复合查询”，返回 变更摘要 + 风险点 + 下一步行动。
因此“Resolve（搜索）-> Fetch（读取详情）”往往兼顾 token 与质量。
这里的“upstream”并不是指 MCP server 仓库，而是指 Atlassian/GitHub 这类产品厂商发布一个实现“子代理隔离”模式的 官方插件。
技术上完全可行，但官方发布往往激励不足，且维护与责任成本显著更高：
此外，MCP 本身聚焦“上下文交换”，并刻意把 上下文预算管理（摘要/缓存/复合查询） 交给 host/中间层，因此该模式更常以用户/社区 middleware 的形式出现，而不是厂商官方插件。
这个想法更适合 以非结构化信息获取（read）为主的 MCP 集成，而不是直接操控/写入（write/actuation）的场景。
通用模板：
通用例子：
关键不是让 server 更聪明，而是让中间层 管理上下文预算。
以“注入主上下文的字符数”对比直接调用 vs 子代理中转。
| 类型 | 直接 MCP | 子代理 | 节省 |
|---|---|---|---|
| 文档（routing） | 12,800 字符 | 3,800 字符 | 70% |
| 文档（hooks） | 15,000 字符 | 3,200 字符 | 79% |
| 单条 issue | 1,200 字符 | 600 字符 | 50% |
| 搜索（10 条） | 12,000 字符 | 1,100 字符 | 91% |
| 文档搜索（5 条） | 3,000 字符 | 2,000 字符 | 33% |
| PR 摘要 | 14,500 字符 | 2,500 字符 | 83% |
| PR diff（大） | 30,000 字符 | 3,500 字符 | 88% |
| PR 复合查询 | 59,500 字符 | 3,500 字符 | 94% |