为你的 AI Agent 选择合适的工具层：MCP、CLI 还是 Skills？
在软件工程中，选择正确的抽象层从来不是新问题。太抽象会让用户跳太多圈子（想想那些让人崩溃的 MiddlewareManagerAbstractFactoryProvider），太具体又会让重复代码满天飞。现在，AI Agent 领域也遇到了类似的问题：我们该怎么让 Agent 执行任务——用 MCP？用 Skill？还是直接上 CLI？
全 MCP 方案：超级 Agent 路线
启动时加载所有可能需要的 MCP 服务器。好处是可发现性——你不确定 Agent 可能需要做什么，给它全套工具的描述，它就能灵活组合、并行获取数据。
但有个隐藏陷阱：MCP 服务器的 schema 会疯狂吃掉你的上下文窗口。Nikita 提到过一个例子：5 个 MCP 服务器、55 个工具的 schema，大约占用 16,500 token，而且这些 token 常驻在你的上下文中。
Skills 和 CLI 方案：开发者路线
这是上一个方案的完全反面。让 Agent 知道自己有哪些 skill 可用，用这些 skill 来指导它调用哪些 CLI 工具以及如何使用。
CLI 工具相比 MCP 有两个巨大优势：没有额外的网络调用到 MCP 服务器，几乎不消耗上下文，输出也可预测。如果 Agent 在本地运行，你对它的环境了如指掌，卡住时还能伸手帮一把。
缺点是安全。CLI 工具是 Agent 能使用的最高风险工具——如果它能访问 CLI 工具，本质上就能访问 Shell。但这不是不可控的风险，做好沙箱和权限管理就行。还要注意证书问题：Agent 能访问哪些凭据文件？这些凭据的角色是否匹配它的操作？
混合方案：两者都要
如果 MCP 服务器和工具太多，吃掉了大量上下文，可以把两种方式结合：把 MCP 工具的使用打包进 skill，避免 token 膨胀。现代客户端不一定把所有 schema 都注入上下文——它们会做缓存和压缩/索引，只注入最少的量，需要时才加载完整的工具 schema。
如果你把流程包装在一个 skill 中，描述清楚需要哪些工具以及如何使用，客户端就能更完整地解包这些工具的 schema，节省上下文和加载时间。如果值得多花一点配置工作，这通常是最佳选择。
结论：视情况而定
所以哪个方案才是正确的？我们以一个经典的计算机科学问题开头，也以一个经典的计算机科学答案结尾：视情况而定。
取决于你的环境、你要完成的任务类型、你要的功能有没有 CLI 工具可用、以及你所在组织的认证/治理要求。
MCP 更安全、更可治理。
CLI 更快、更可靠。
答案可能介于两者之间。
最重要的结论可能是：能够编写和维护高质量的 Skills 是一个巨大的优势。
