4.2 支持 MCP 的智能体开发平台 · 波仔的 AI 编程实战课

📄 一句话概括

平台侧把 MCP 当成了插件市场：Server 上架、别人订阅、按次收费。所以这一类的关键动作不是「写配置」，是「选服务、填 Key、上架时把元数据填齐」。自建还是上架，分界线只有一条：数据在哪，就在哪跑。

📝 本章和前面几章的关系

上一节那五个工具，配置写在文件里，跑在你机器上。这一节的七个平台反过来：Server 跑在人家服务器上，你只是订阅一个服务。形态一变，要操心的事也变了：不操心进程，开始操心元数据、额度、审核。

一、平台侧为什么会接这个

对平台来说，MCP 解决的是一个老问题：能力不够用。平台自己能提供的工具就那么几十个，用户要的东西千奇百怪——查快递、读股票、连公司内网。自己一个个接，接不完。有了 MCP，第三方可以自己写 Server 上架，平台只做目录和审核。 这是把「做功能」外包出去，同时收一层通道费。

所以这一类的重心不在协议，在运营：目录怎么排、额度怎么算、审核卡在哪。你作为使用者，感受到的是「这里有个广场，里面有一堆服务」。第 5 章会专门讲这些广场，这一节先讲它们各自的路子。

二、七个平台，三种路子

第一种是自家生态里加一个广场。扣子空间、阿里云百炼、百度智能云千帆 AppBuilder、百宝箱，都属于这一种：本来就有智能体搭建能力， MCP 是新增的一类节点。第二种是搜索框加工具。纳米 AI 走的是这条，把它当成给搜索加插件的手段。第三种是开源可自建的编排工具。 n8n 和 Dify 都属于这一类：Server 可以自己挂，整个平台也能跑在自己机器上。

三种路子对使用者的意义不同。第一种最省事但要按平台的规矩来；第三种最自由，代价是自己运维。 选哪一种，先回答一个问题：数据能不能出你的网络。 能，就用平台；不能，就自建。

三、上架要填的元数据

演示里那份元数据十个字段：name、title、description、icon、version、auth、pricing、quota、 visibility、tools。技术上跑起来只需要最后一项——工具列表。前面九项全是「给人看的」和「给审核看的」。可这九项决定了别人敢不敢用。最容易漏的是 version 和 auth。

漏了 version，用户不知道该不该更新；漏了 auth，用户装完才发现要 Key，第一反应是「被坑了」。演示里对比了「认真填」和「赶工填」两份，赶工那份缺六个字段，两份都能跑，但审核会卡在后面那份上。

四、工具描述在这一层比在本地更重要

上架之后，用户看不到你的代码，只能看到工具的描述。描述写得含糊，模型就不会调它，而【这一步没有客服能帮上忙】——用户只会说「这个工具有问题」，你说不出哪里有问题。演示里两种写法对比：「查天气」对「查某城市某天的天气」。前者模型不知道参数是什么、能查几天；后者一看就知道是城市加日期，一次一天。

参数说明也一样。「day 是 string」和「day 是 string，取值只能是今天、明天、后天」，后者的填错率明显低。 这一条在第 6 章还会再出现一次。 自己写 Server 的时候，你既是作者又是用户，更该按后一种写。

五、自建还是上架：四个判据

演示里给了四条判据，按顺序问，第一个「是」就定了。一、要读本机文件吗？是，就只能本地跑。二、别人也要用吗？是，就得托管或者把配置发给人家。

三、要无人值守吗？是，得放服务器上常驻——本地宿主电脑一关就没了。四、数据敏感吗？是，本地且不出网。顺序很重要。别一上来比功能列表：功能都能补，数据在哪不能改。

这张表第 7 章讲上线的时候还要用一次，那时候是把本地的搬到服务器上。

六、动手 Demo：自建还是上架，差在哪一层

先摆两条路的区别，再看一份上架元数据长什么样、缺字段会缺在哪。最后比同一个工具的两种描述写法，看模型能不能判断。这一节的输出全是文本比对与字段计数，不需要任何平台账号。

META = {'name': 'weather-mcp', 'title': '天气查询',
        'description': '按城市和日期查天气，覆盖国内 300 个城市。',
        'icon': 'https://cdn.example.com/weather.png',
        'version': '1.2.0', 'auth': 'api_key',
        'auth_note': '需要在设置里填一个 KEY',
        'pricing': 'free_quota', 'quota': '每天 100 次',
        'visibility': 'public', 'tools': [...]}

NEED = ['name', 'title', 'description', 'icon', 'version',
        'auth', 'pricing', 'visibility', 'tools']

rush = {k: META[k] for k in ('name', 'title', 'visibility')}
for one in (META, rush):
    miss = [k for k in NEED if k not in one]
    print('缺 %d 个' % len(miss), miss)

# 同一个工具，两种描述
print(scan_desc('查天气'))
print(scan_desc('查某城市某天的天气'))

实跑输出：

--------------------------------------------------------------------
自建还是上架，差在哪一层
--------------------------------------------------------------------


  ① 两条路
  --------------------------------------------------------------------

|  | 自己跑（stdio） | 上架到平台（托管） |
|---|---|---|
| 谁执行 | 你的电脑 | 平台的服务器 |
| 谁能用 | 只有你 | 所有拿到链接的人 |
| 配置怎么写 | command 加 args | 填一个地址，选一个服务 |
| 要管什么 | 进程、依赖、日志 | 基本不管，按量付费 |
| 能不能读本地文件 | 能 | 不能 |

  分界线很清楚：【数据在哪，就在哪跑】。
  要读你本机文件的 Server，上不了云；要给全公司用的，别装在自己电脑上。

  ② 上架要填的元数据
  --------------------------------------------------------------------
    {
      "name": "weather-mcp",
      "title": "天气查询",
      "description": "按城市和日期查天气，覆盖国内 300 个城市。",
      "icon": "https://cdn.example.com/weather.png",
      "version": "1.2.0",
      "auth": "api_key",
      "auth_note": "需要在设置里填一个 KEY",
      "pricing": "free_quota",
      "quota": "每天 100 次",
      "visibility": "public",
      "tools": [
        {
          "name": "forecast",
          "description": "查某城市某天的天气",
          "inputSchema": {
            "type": "object",
            "properties": {
              "city": {
                "type": "string",
                "description": "城市名"
              },
              "day": {
                "type": "string",
                "description": "日期"
              }
            },
            "required": [
              "city",
              "day"
            ],
            "additionalProperties": false
          }
        }
      ]
    }

  ③ 这份元数据齐不齐
  --------------------------------------------------------------------

把一份「急着上线、字段随便填填」的版本放在一起比：

| 字段 | 为什么必须有 | 认真填的 | 赶工填的 |
|---|---|---|---|
| name | 唯一标识，不能和别人的撞 | 有 | 有 |
| title | 给人看的名字 | 有 | 有 |
| description | 一句话说清干什么 | 有 | 缺 |
| icon | 列表里的图 | 有 | 缺 |
| version | 更新了要能看出新旧 | 有 | 缺 |
| auth | 要不要 Key，要哪种 | 有 | 缺 |
| pricing | 免费还是收费 | 有 | 缺 |
| visibility | 谁能看见 | 有 | 有 |
| tools | 工具列表，至少一个 | 有 | 缺 |

  上面那份缺 0 个，下面这份缺 6 个：description、icon、version、auth、pricing、tools。
  两份在技术上都能跑起来——【可上架审核会卡在下面这份】。
  【最容易漏的是 version 和 auth】——漏了 version，用户不知道该不该更新；
  漏了 auth，用户装完发现要 KEY，第一反应是「被坑了」。

  ④ 工具描述在这一层更重要
  --------------------------------------------------------------------
上架之后，用户看不到你的代码，只能看到工具的描述。
描述写得含糊，模型就不会调它——【而这一步没有客服能帮上忙】。

同一个工具，两种写法：

| 写法 | 描述 | 模型能判断吗 |
|---|---|---|
| 含糊 | 查天气 | 不知道参数是什么、能查几天 |
| 具体 | 查某城市某天的天气 | 能：城市加日期，一天一次 |


参数说明也一样，两种写法差很多：
  差：day -> string
  好：day -> string，取值只能是 今天 / 明天 / 后天
  后者把枚举写进描述，模型填错的概率会明显降下来。
  ! 这一条在第 6 章还会再出现一次，那时是自己写 Server，道理一样。

①第一张表五行，最关键的是最后一行「能不能读本地文件」。这一行决定了后面所有选择，别的差别都是从它推出来的。 ②第二段那份元数据十项，只有 tools 是技术上必须的。剩下九项是给人看、给审核看的，但它们决定别人敢不敢用。 ③第三段数出两个数：认真填的缺 0 个，赶工填的缺 6 个。两份在技术上都能跑起来，区别只在审核会不会卡。 ④第四段两组描述对比，差别不在字数，在「模型能不能据此判断参数长什么样」。参数说明里写清枚举值，填错率就下来了。 ⑤最后那句提醒值得记住：这一条在第 6 章还会出现。自己写 Server 的时候，你就是那个「上架的人」。

30 秒实验

把你用过的一个智能体平台打开，找它的 MCP 或插件市场。数一数首页有几个服务。
拿演示里那份元数据，删掉 auth 字段，想想用户装完会怎么样。
按四个判据给自己手上的一件事做一次选择：本地跑还是托管。写下第一个「是」出现在第几条。

常见误区

「平台上的 Server 更可靠，因为有人在维护。」可靠性看维护状态，不看它在不在平台上。目录站上也有半年没更新的。
「元数据填个名字就行。」缺 auth 和 version 是最招人烦的两种。前者让人装完才发现要 Key，后者让人不知道要不要更新。
「功能列表比一比就知道选哪个。」先问数据在哪。功能都能补，数据在哪不能改。

自测三问（点开对答案）

1. 平台侧接 MCP 的动机是什么？ —— 把「做功能」外包出去：第三方写 Server 上架，平台做目录和审核，顺带收通道费。 2. 上架元数据里最容易漏的是哪两个？ —— version 和 auth。前者让用户不知道要不要更新，后者让人装完才发现要 Key。 3. 自建还是上架，第一个要问的问题是什么？ —— 要读本机文件吗。是就只能本地跑，后面三条都不用问了。

平台类看完了，下一节收个尾：桌面端、手机助手、百宝箱那一类，它们离用户最近，也最容易被低估。

☐ （本篇完，下一篇 4.3 其他特色平台）