在 agent 中， mcp 和 skill+cli 是“互补”还是“竞争”关系

mcp 能做的，cli + skill 都能做。

cli 可以做的，mcp 有些很难做。比如利用管道，实现一次调用执行多个命令。

mcp 被 skill cli 碾压

MCP 可以是 long running 的，只有这个场景，是 cli 与 skill 做不到的

我请教个问题我觉得 mcp 调用是确定的。但是 skill 的调用是确定吗？

比如我写了一个很复杂的 skill 要先调用 1-10 工具

然后再调用 10-40 工具或者执行部分操作。

模型的好坏会直接影响 skill 的执行吗？

举个例子我用本地的一个 30B 的模型去执行一个复杂的 skill 他会怎么样？执行是不确定吗？比如做了 1-2-3 然后直接跳过后面的？

4 楼说的没问题，mcp 可以按照既定代码去跑，skill 不一定，很看大模型的能力

@Clannad0708
这确实算得上是一个 skill 的缺点，就是结果不唯一。
大部分情况下 skill+cli 都可以替代 mcp 。两者的重叠性很大，并且前者因为渐进式披露，节省很多 token

绝大部分情况是竞争，且是 skills 压倒性优势的竞争。某些特殊情况下 mcp 可以做补充

有一点我觉得是 MCP 的优势，就是 MCP server 能跑在远端服务器上。
我在工作中就给一个内网的服务做了 MCP 接口，把本来的 web app 转换成了 MCP app 。当然你说 CLI+Skill 走 curl 硬做能不能做，那当然是能做的，但 MCP 来实现我感觉更好一些。

@hamsterbase #1 你用 skill 做个 context7 试试。
skill 目前无法完整覆盖 mcp 的所有用例，稳定性也更差。
原本大家在疯狂滥 mcp ，现在 skill 出来的又开始滥用 skill ，潮水退去剩下还坚挺的 mcp 才是有代表意义的，而这些很难被其他手段替代。
skill 也是如此，等下一波潮水把里面的垃圾再掏一遍，才能确立 skill 的实际场景。

@Ketteiron

让 ai 调研了一下。context7 官方已经有 skill 了。
且没有找到什么官方 mcp 可以做到，但是 skill 做不到的。

@hamsterbase #10
想了下，mcp 和 skill 确实可以等价互换，一切 server 逻辑都能用脚本实现。
但依赖于远程有状态服务的 skill ，我还是觉得应该用 mcp ，特别是对于稳定性要求高的用例。

@Ketteiron

我现在倾向于远程服务封装成 cli 。 然后为 cli 写一份使用文档。

这样无论是人和 ai 都可以用。AI 不需要关系 cli 实现的具体细节。cli 调用会比 mcp 灵活。