Tool / Skill / MCP 选型方法论

来源：卡夫卡 @kafkaup《讲一下 tool、skill 和 MCP 的区别以及选型的问题》（2026-10-16）。原文：https://x.com/kafkaup/status/2111063860757057677。小沐整理为方法论文档。

一、三分法：它们分别是什么

	管什么	沉淀什么	一句话
Skill	怎么做	方法、流程、判断经验	可复用的”做法包”
Tool	具体动作	函数调用	agent 实际动手干活的工具
MCP	发现与调用	标准协议	能力怎么被 agent 发现、理解、调用

三者不互斥。典型调用链：agent 先通过 skill 确定”这事该怎么做” → 执行中调用 tool → 一部分 tool 在内部系统，另一部分通过 MCP 调用。

二、两种画法：边界划在哪

功能上看起来差不多，产品复杂度完全不一样：

白盒画法：skill 做成”做法包”——一个 skill 对应一个具体任务怎么做；tool 老老实实做函数调用；MCP 只做外部能力接入。

• 优点：debug、日志、版本管理都好做
• 适用：核心流程、多 agent 共享、需要审计的场景

黑盒画法：skill 做成”能力入口”——里面用 tool 还是 MCP 对 agent 透明。

• 优点：调用简单
• 代价：调试链条长，对内部/外部 agent 一致性要求更高
• 适用：对外分发、降低接入门槛

现实多为混搭：核心流程用白盒固定，非核心、易变的外部能力走 MCP。

三、选型方法论：三个问题

不要问”选哪个”，问：

1. 可复用的做法应该沉淀到什么粒度？ —— 太粗 agent 学不会，太细维护成本爆炸。skill 的粒度 = “一个能说清楚的做法”。

2. agent 和能力的耦合应该松到什么程度？ —— MCP 是能力，也是成本（协议调试、版本对齐）。@sisiliu517 启发式：”能不能用一个本地 skill 说清楚？能就别急着加 MCP。”

3. 能力既要被内部 agent 用、又要被外部 agent 用时，接口长什么样？ —— 接口现在就要按”内外都要用”设计，别等将来返工。

一句话：纠结名词定义没法指导选型；把三个问题想清楚，位置自然清楚。

四、应用检查表

给自己的项目做选型时，逐项打勾：

• 这个能力是”做法”还是”动作”？做法 → skill，动作 → tool
• 这个 tool 的 description 里有没有混进”何时调、怎么调好”？有 → 抽到 skill
• 一组 tools 是不是其实是一个工作流？是 → 考虑包成白盒 skill（或至少文档化调用顺序）
• 要不要上 MCP？先问”本地 skill 说得清楚吗？”——说得清楚就不上
• 接口将来要给外部用吗？要 → 现在就按内外兼容设计

五、在本工作流中的位置

• open-memex：MCP = 能力入口（黑盒），opencode plugin = 白盒；11 个 tools 待边界审计（见 open-memex-boundary-audit-2026-10-16.md）
• thinktank：skill = 做法包入口（白盒，agent-agnostic 逼的）；暂不上 MCP
• harness：AGENTS.md + 脚本 = 纯白盒；对外分发时包黑盒（harness init）
• 通用原则：白盒是生产方式，黑盒是交付方式，两者都要，但分层