真实面经题目 · 原创解析
这道题考察对 Agent 工具接入方式和上下文成本的工程理解。好答案要区分 Function Call 是模型请求内的工具 schema，MCP 是客户端和外部工具服务器之间的协议，Skill 是把说明、脚本和资源按能力打包并按需加载的机制。回答不能简单说 MCP 一定比 Skill 大，而要说明上下文占用取决于客户端暴露了多少工具描述、schema 是否冗长、是否做动态路由和懒加载。高质量答案还应给出降低 token 成本的方法，包括工具分层、候选工具筛选、描述压缩、结果引用、prompt caching 和按任务加载。
Function Call、MCP 和 Skill 的上下文成本不是同一个层面的东西。Function Call 通常是把可用工具的 name、description、parameters schema 放进当前模型请求，模型要靠这些描述决定是否调用，所以活跃工具越多、schema 越复杂，占用越高。MCP 本身是连接外部工具服务器的协议，它把 tools、resources、prompts 等能力标准化，真正进入模型上下文的仍然是客户端选择暴露给模型的工具描述；如果客户端一次注册几十个 MCP tool，成本会很高，如果先做路由和按需 list，就可以控制。Skill 更像能力包，通常只把 skill 的名称和简短触发描述放在常驻上下文，命中后再加载详细说明、脚本或模板，因此适合把长操作手册和复杂流程做 progressive disclosure。降低成本的核心是少暴露、短描述、按阶段暴露：先用轻量路由选出 3 到 5 个候选工具，再给模型必要 schema；工具结果传引用和摘要；常用静态说明用缓存；长资源放外部存储，只有需要时读取。
Function Call 的主要成本来自当前请求中暴露给模型的工具定义，包括工具名、自然语言描述、参数 JSON Schema、枚举值和约束说明。模型需要看到这些内容才能规划调用，因此把一组庞大工具全量放入每轮请求，会直接增加输入 token，并可能降低工具选择准确率。
MCP 是客户端与工具服务器之间的标准协议，解决工具发现、调用、资源读取和提示模板暴露等接口问题。它不等于模型每轮都读取完整服务器文档。上下文占用取决于 Agent 客户端如何把 MCP server 返回的 tool metadata 编排进模型请求。
Skill 通常用于把一类任务的操作说明、脚本、模板、参考资料打包，常驻部分只需要短名称和触发描述。等任务路由命中后，再加载具体 SKILL 内容或脚本。它的优势是把长说明延迟到真正需要时进入上下文，特别适合复杂但低频的工作流。
不能绝对说 MCP 或 Skill 哪个更大。若 MCP 客户端一次暴露大量工具和长 schema，成本会明显大；若 Skill 命中后加载很长的手册和样例，也会变大。通常在未命中阶段，Skill 的常驻成本较小；在执行阶段，成本取决于加载内容是否被裁剪。
降低 Function Call 和 MCP 工具成本时，优先压缩 description 和参数 schema。描述要说明何时用、输入输出和关键限制，不要塞完整文档。枚举值很多时用短码或分级工具；复杂对象拆成少数高价值字段，剩余细节通过资源引用或二次查询获取。
比较稳的工程方案是先做工具路由：根据用户意图、当前状态和权限，筛出少量候选工具，再把这些工具 schema 放入模型请求。多阶段任务中，每一阶段只暴露下一步可能用到的工具，例如搜索阶段不暴露写入工具，确认阶段再暴露提交工具。
token 成本不只来自工具描述，也来自工具结果。无论 Function Call 还是 MCP，都应避免把长结果原文塞回上下文。工具返回应结构化、分页、摘要化，并把大文件或完整响应放资源存储，模型只拿引用、关键字段和需要继续推理的片段。
优化是否有效要看每轮输入 token、工具选择准确率、无效调用率、平均轮次、延迟和失败恢复率。不能只追求 token 变少，如果描述压得过短导致模型误用工具、漏掉权限限制或反复追问，整体成本和风险反而会上升。
MCP 更像工具服务器协议，定义客户端如何发现和调用外部工具；Function Call 更像模型侧的调用接口和输出格式。一个 Agent 可以通过 MCP 获取工具列表，再把筛选后的工具以 Function Call 或类似机制暴露给模型。二者不是互斥关系。
不要把上百个工具全塞给模型。先用规则、embedding 路由、意图分类或轻量 LLM 选择工具域，再在域内暴露少量工具 schema。执行过程中根据状态逐步切换工具集合，并把权限、环境和风险级别作为路由条件。
Skill 的关键是 progressive disclosure。常驻上下文只需要告诉模型有哪些能力和何时触发，详细步骤、示例、脚本和参考资料可以等命中后再读。这样大量低频能力不会在每次普通对话中消耗 token。
会，所以压缩不能只删字。保留何时使用、必填参数、返回含义、危险副作用和权限限制，删除冗余背景、长示例和实现细节。压缩后要用工具选择集测试无效调用率、漏调用率和参数错误率。
可以缓存稳定 system prompt 和工具说明，工具结果只回传摘要和引用，长文件按需检索片段，历史对话定期结构化压缩，多阶段任务只保留当前决策所需状态。最终用每轮输入 token、延迟和成功率一起评估。
