字节面试官问：Claude Code 接几十个 MCP 工具，为什么不撑爆？
我给内部 agent 接到第三个 MCP server 就撞墙：接得越多越笨。可换成 Claude Code，同样接几十个外部工具偏偏不撑爆——这课就拆它的接入架构怎么做到，以及你自造 agent 怎么抄。
先把术语翻成人话
MCP：让 agent 标准化接外部工具和数据的协议
MCP server：把一个系统的能力暴露成工具的服务端
tool schema：一个工具的说明书（名字、干啥、要什么参数）
上下文窗口：模型一次能看的内容，塞满了就开始变笨
延迟工具：工具名先登记进来，说明书用到再取
Tool Search：模型按需把某个工具的完整说明书取出来的机制
server instructions：server 自我介绍的一段话（我管什么、什么时候搜我）
一、面试现场
面试官提问
“接几十个 MCP 工具，Claude Code 怎么没被撑爆？”
字节面试官让我讲一次真实对接：我给一个内部 agent 接了 8 个 MCP server——代码仓库、工单、数据库、监控、文档。图省事，想着接得越全越好。
结果接到第 5 个，工具列表几十条，问题全来了：每轮对话光工具说明书就占掉一大截上下文，响应肉眼可见变慢，模型还开始在一堆长得差不多的工具里挑错。这题看似问「怎么接 MCP」，实考你能不能区分"把工具接进来"和"把所有说明书塞进上下文"——前者是接入，后者把窗口喂爆。
**直接回答：**接入不是全塞 schema，先给名片，用到再展开。
二、大多数人怎么答的
典型翻车回答
“把 server 配好、工具都列出来，模型自然会挑着用，接得越全 agent 越强。”
**能列出来不等于用得好。**几十个工具的 schema 一次性进上下文，三件事会一起恶化：
① 常驻 token 和延迟，随工具数往上涨
② 模型在一长串相似工具里，更容易挑错
③ 真正干活的对话，被工具说明书挤掉位置
我认为，瓶颈不是接不通，是接进来后上下文预算怎么管——接得越多越笨，是预算问题，不是连通问题。
那顶级 harness 是怎么躲过这一刀的？Claude Code 的做法反直觉：默认不让外部工具常驻上下文——先保留名片索引，真正需要时再展开 schema。下面把它的接入架构拆开看。
三、拆开 Claude Code 接 MCP：几十个工具为什么没把它撑爆
**关键机制只有一个：索引 + 按需展开。**外部工具默认只露「名片」，说明书用到才取。这一节按「要解决什么 → CC 实测怎么做 → 你自造怎么复刻」拆。
① 外部工具默认进「延迟区」，schema 不占上下文
外部工具不立刻把完整 schema 摊进上下文，而是先以「延迟工具」登记——上下文里（Claude Code 的<system-reminder>块）只列一排工具名，比如mcp__github__create_issue，说明书并不加载；真要用，才取那一个的 schema。
这不是省事，是 CC 的上下文预算决策：常驻的只有一小撮高频核心工具，外部 MCP 工具一律打入延迟区。
**违反后果：**几十个 schema 一次性进窗口，模型还没干活就被工具说明书淹没，每轮都在为没用上的工具付 token 和延迟。
② 取说明书走 Tool Search，按当前任务现取
延迟工具靠 Tool Search 变成能用的工具。Claude Code 里它有具体接口：select:<工具名>精确取某几个、关键词搜一批、+词限定来源。模型按当前任务去搜，取回那几个工具的完整 schema。
**违反后果：**没有这一层，要么全量加载撑爆上下文，要么干脆接不进来；按需取，才能让「接很多」和「上下文干净」同时成立。
③mcp__server__tool：命名空间一眼看出来源
外部工具进来会带 server 前缀：mcp__<server>__<tool>。8 个 server 里都有个叫search的工具也不会撞，模型和你都能一眼看出这是哪个 server、是不是外部来源。这点很小，但少了它，长工具列表立刻变成一锅粥。
**违反后果：**不带前缀，同名工具互相覆盖，模型调了 A 的 search 以为在搜 B，排错都难。
④resources不占工具位：只读资料别做成工具
MCP 不只给tools，还给resources——只读数据入口（Claude Code 里走ListMcpResources/ReadMcpResource，或@server:...引用）。查文档、读 issue、拿 schema 走 resource，不挤工具空间，也不算有副作用的动作。
**违反后果：**把「读数据」硬塞成工具，工具数凭空膨胀，权限和审计还更难管——动作和资料混在一起最容易出事。
**我的优先顺序：**先让外部工具能被索引、按需展开，再谈接多少。这套和第 5 课记忆的MEMORY.md索引、第 9 课技能的 name/description 索引是同一招——顶级 harness 控上下文预算的统一签名，不是 MCP 专属。
四、面试官追问链
追问 1
工具就几十个，schema 全塞进上下文的开销看起来不大。
几十个工具的 schema 轻松几千上万 token，而且每一轮都在——挤掉对话、抬高延迟、还让模型在更长列表里选错。我认为，上下文里每个不干活还常驻的工具，都在持续交税。
追问 2
Tool Search 按需取，真正风险是该用的工具可能没被搜出来。
风险真实，所以server instructions（名片）的质量是关键：它要说清「我管什么、什么时候该搜我、哪些动作有副作用」，模型才搜得到。名片写烂，工具接了等于没接。这也是为什么接入治理的根子在 server 端——呼应第 3 课：描述就是写给模型的说明书。
追问 3
工具越多不代表越该上 MCP，拆 server 要看边界。
不是按数量，是按「来源 × 复用 × 副作用」。同一外部系统、要被多 agent 复用、有副作用要管——值得独立 server；一两个固定只读调用、就一个 agent 用，内建更省。小场景硬上协议，是另一种过度设计（第 12 课收口）。
五、给 agent 接多个 MCP，怎么不被撑爆
落地别先狂接 server，先立「接进来不撑爆」的规矩。四步：
STEP 1 · 按来源拆 server，不按工具拆
一个外部系统对应一个 server，工具归拢在它名下，靠mcp__server__前缀天然隔离。别把五个系统的工具堆进一个 server。
↳ 关键：撞名和来源混乱，都是从拆错边界开始的。
STEP 2 · 每个 server 写好 instructions（名片）
名片说清解决什么、什么时候搜、哪些有副作用——这直接决定 Tool Search 搜不搜得到你的工具。工具多时，不要指望模型自己猜。
↳ 关键：名片写烂，延迟工具永远展不开，等于没接。
STEP 3 · 只读走resources，动作走tools
查资料、读文档、拿 schema 用resources；能改状态的才进tools。别把所有东西都硬塞成工具。
↳ 关键：动作和资料分开，工具数不膨胀，权限审计才好管。
STEP 4 · 用可观察行为验收「撑没撑爆」
别只看 server 起没起。看外部工具是不是以延迟工具登记、用到才取 schema、mcp__server__tool正确隔离、常驻上下文有没有随 server 数暴涨。
↳ 关键：验收标准不是「server 通了」，是「再接一个，agent 不会更慢更笨」。
我会照抄的验收 trace
① 每次工具选择记录mcp_server、tool_name、schema_loaded、selection_reason、latency_ms。
② 每接 1 个新 server，抽 20 条真实任务，看常驻上下文有没有明显变长、错调工具有没有上升。
③ 有副作用的工具补user_confirmed和rollback_action；没有回滚口径的，先不要暴露给 agent 自动调。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～