夜雨聆风
你已经学会了让 AI 读文件、写代码、跑命令。但某天你突然想问：「AI 能不能帮我查一下 Notion 里还有哪些待办任务？」「能不能让 AI 直接在 GitHub 上评论这个 PR？」「能不能让 AI 把消息发到 Slack 频道去？」
答案是：能。但需要一个转接头。
这个转接头的名字，就是 MCP。
///
PART 01
14.1 什么是 MCP：AI 时代的「USB 接口」
MCP（Model Context Protocol，模型上下文协议）是一种标准协议，用来让 AI 连接外部服务。打个比方：
没有 MCP 的时候，AI 和外部世界是隔离的。它只能操作本地文件系统，其他什么都碰不到。加上 MCP 之后，AI 像是多了无数只手，可以伸进各个平台去操作数据。
MCP 的核心三组件
MCP 架构里有三个核心概念：
MCP 服务器（Server）：提供工具的外部进程或远程服务。每个平台（Notion、GitHub）都有自己的 MCP 服务器，负责和那个平台通信。
MCP 工具（Tool）：服务器暴露出来的具体功能。比如 GitHub MCP 服务器会暴露 github_create_issue、github_review_pr 这样的工具，AI 可以直接调用它们。
MCP 客户端（Client）：OpenCode 内置的连接器，负责和 MCP 服务器通信，把工具注册进 AI 的工具集里。
用户提问 → OpenCode → AI 决定调用 MCP 工具 → MCP 服务器执行 → 返回结果
整个链路是：你说话 → AI 判断要用什么工具 → OpenCode 把工具调用转发给 MCP 服务器 → 服务器操作外部平台 → 结果返回给 AI → AI 继续处理。
///
PART 02
14.2 USB 接口类比：为什么「MCP 是 AI 时代的 API」
你可能听说过 REST API、Webhook、插件系统……MCP 和它们有什么不同？
传统 API 的工作模式：你要写代码、去调用 API、处理返回结果。是你在主动发起请求，API 只是被动等待被调用。
MCP 的工作模式：AI 是主动的。你告诉 AI「帮我把这个 PR review 一下」，AI 自己决定调用哪个工具、怎么调用、什么时候调用。AI 成了指挥者，外部工具成了它的「四肢」。
类比一下：
| 类比维度 | USB 接口 | MCP |
|---|---|---|
| 连接对象 | U盘、鼠标、键盘 | Notion、GitHub、Slack |
| 连接方式 | 即插即用 | 配置即可用 |
| 操作系统自动识别 | 是 | 是（OpenCode 自动发现工具） |
| 需要写代码吗 | 不需要 | 不需要 |
| 能同时连多少设备 | 多个端口 | 多个 MCP 服务器 |
所以为什么说「MCP 是 AI 时代的 API」？因为它让 AI 和外部世界的连接变得即插即用，不再需要开发者手写代码去对接每个平台。
///
PART 03
14.3 MCP vs Skill：厨房与菜谱的关系
第 8 章我们学了 Skill 系统，知道 Skill 是「把老员工的脑子复制进 AI」。现在有了 MCP，会有一个自然的问题：MCP 和 Skill 有什么区别？什么时候用哪个？
用一个生活类比来解释：
MCP 负责连通，它让 AI 有能力去操作 Notion、去发 Slack 消息。但 AI 具体怎么用这些能力，需要 Skill 来指导。
Skill 负责指导，它告诉 AI 「我们公司的收入定义是什么」「发 PR 的时候应该包含哪些检查项」。但 Skill 本身不连通外部，AI 有知识但没有手脚。
实际例子：发 Slack 消息
假设你想让 AI 在代码合并后自动发消息到 Slack 频道。
只用 Skill 不行：Skill 知道「消息应该怎么写」（比如包含分支名、提交摘要、审查结果），但 AI 没有能力真的把消息发出去。
只用 MCP 不行：MCP 有 slack_post_message 工具，AI 可以发消息，但不知道「什么时候发」「发什么格式」「包含哪些信息」。
MCP + Skill 才行：MCP 提供发送能力，Skill 提供发送规范。AI 在 Skill 的指导下，按正确格式调用 MCP 工具，把消息发出去。
Skill（菜谱） → 告诉我「消息要这样写」
MCP（厨房） → 让我能够「把消息发出去」
AI（厨师） → 根据菜谱，使用厨房的工具，把菜做出来
///
PART 04
14.4 常见 MCP 集成场景
MCP 生态已经非常丰富了。以下是几个常见场景的具体配置和用法。
14.4.1 Notion：AI 读写你的笔记数据库
Notion MCP 让 AI 直接操作你的 Notion 页面和数据库。你可以让 AI：
- 读取某个数据库的所有条目
- 更新一个页面的属性
- 创建一个新的任务条目
配置方式：
{
"mcp": {
"notion": {
"type": "remote",
"url": "https://mcp.notion.dev",
"oauth": {}
}
}
}
首次使用需要认证：
opencode mcp auth notion
使用示例：
帮我看看 Notion 里「产品路线图」数据库中优先级最高的三件事
AI 会调用 notion_query_database 工具，连接 Notion API，读取数据库内容并返回给你。
///
14.4.2 Linear：AI 管理你的任务
Linear 是一个项目管理工具，特别受工程师喜爱。Linear MCP 让 AI 可以：
- 创建 issue
- 更新 issue 状态
- 评论 issue
- 查看团队的工作量
配置方式：
{
"mcp": {
"linear": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-linear"],
"environment": {
"LINEAR_API_KEY": "{env:LINEAR_API_KEY}"
}
}
}
}
使用示例：
帮我把「登录页面样式修复」这个 Linear issue 的状态改成 Done，然后评论说「已修复」
///
14.4.3 Slack：AI 帮你发消息
Slack MCP 让 AI 可以：
- 读取频道消息
- 发送消息到指定频道
- 创建线程回复
配置方式：
{
"mcp": {
"slack": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-slack"],
"environment": {
"SLACK_BOT_TOKEN": "{env:SLACK_BOT_TOKEN}",
"SLACK_TEAM_ID": "{env:SLACK_TEAM_ID}"
}
}
}
}
使用示例：
代码已经合并到 main 分支了，帮我在 #releases 频道发一条消息，说：v2.1.0 已经发布，包含新登录功能和性能优化
///
14.4.4 GitHub：AI 帮你 review PR
GitHub MCP 应该是工程师最常用的之一。它让 AI 可以：
- 查看 PR 内容
- 评论 PR
- 审查代码
- 创建 issue
- 管理分支
配置方式：
{
"mcp": {
"github": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-github"],
"environment": {
"GITHUB_TOKEN": "{env:GITHUB_TOKEN}"
}
}
}
}
使用示例：
review 一下这个 PR：https://github.com/myorg/myrepo/pull/123
重点关注测试覆盖率和性能影响
AI 会调用 github_get_pull_request、github_review_pull_request 等工具完成 review。
///
14.4.5 Playwright：AI 帮你做 E2E 测试
Playwright MCP 让 AI 可以控制浏览器做端到端测试。这和 Chrome DevTools MCP 不同——Chrome DevTools 是「接管你当前的浏览器」，Playwright MCP 是「AI 控制一个全新的浏览器实例做自动化测试」。
配置方式：
{
"mcp": {
"playwright": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-playwright"]
}
}
}
使用示例：
帮我用 Playwright 跑一个 E2E 测试：打开登录页面，输入账号 admin@test.com，密码 Test123，然后验证是否成功登录并跳转到 /dashboard
///
PART 05
14.5 MCP 服务器配置基础
配置文件位置
OpenCode 按以下顺序加载 MCP 配置，后加载的会覆盖先加载的：
| 优先级（低→高） | 位置 | 用途 |
|---|---|---|
| 1（最低） | ~/.config/opencode/opencode.json | 全局配置，所有项目共享 |
| 2 | opencode.json（项目根目录） | 项目级配置 |
| 3（最高） | .opencode/opencode.json | 项目级配置（推荐） |
推荐使用 .opencode/opencode.json，因为它优先级最高，且和 agents/、commands/ 等其他配置放一起方便管理。
本地 MCP vs 远程 MCP
本地 MCP：MCP 服务器运行在你本地机器上，通过 stdio 通信。适合需要本地访问的服务（如 filesystem、postgres、playwright）。
{
"mcp": {
"my-local": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed"],
"enabled": true
}
}
}
远程 MCP：通过 HTTP/SSE 连接远程服务器。适合云服务（如 Notion、Linear、Sentry）。
{
"mcp": {
"my-remote": {
"type": "remote",
"url": "https://mcp.example.com/mcp",
"enabled": true,
"headers": {
"Authorization": "Bearer {env:MY_API_KEY}"
}
}
}
}
交互式添加 MCP
不想手动编辑 JSON？用交互式命令：
opencode mcp add
按提示操作：选择位置、输入服务器名称、选择类型（Local/Remote）、填入命令或 URL 即可。
查看连接状态
opencode mcp list
五种状态：
| 状态 | 含义 |
|---|---|
connected ✓ | 已连接，工具可用 |
disabled ○ | 配置中 enabled: false |
failed ✗ | 连接失败，看错误信息 |
needs_auth ⚠ | 需要 OAuth 认证 |
needs_client_registration | 需要预注册客户端 ID |
///
PART 06
14.6 性能考量：MCP 越多，AI 越慢
MCP 很强大，但有一个必须知道的问题：每个 MCP 都会增加上下文消耗。
具体来说：
- 每个 MCP 服务器在连接时，会向 AI 发送一份 schema 描述，大约 500 tokens 左右
- 启用的 MCP 越多，AI 的上下文 window 被这些 schema 占用得越多
- 如果你启用了 10 个 MCP，光 schema 就占掉了 5000 tokens，这已经是 Haiku 上下文窗口的相当一部分
实战建议
只启用必要的 MCP：不要「全都要」。只加载你当前工作流真正需要的 MCP。比如今天做 GitHub 相关任务，启用 GitHub MCP；明天做 Notion 任务，再启用 Notion MCP。
使用按 Agent 启用：在 permission 配置里全局禁用某些 MCP，只在特定 Agent 里启用。
{
"mcp": {
"github": { ... },
"notion": { ... }
},
"permission": {
"notion_*": "deny" // 默认禁用
},
"agent": {
"notion-writer": {
"permission": {
"notion_*": "allow" // 只在这个 Agent 里启用
}
}
}
}
优先用 Remote MCP：很多远程 MCP（如 Context7、Grep by Vercel）不需要本地进程，没有启动开销和维护成本。
///
PART 07
14.7 MCP vs CLI：什么时候用哪个
这是很多人都会问的问题。我已经有这些工具的 CLI 了，为什么还要用 MCP？
对比表
| 维度 | MCP | CLI |
|---|---|---|
| 谁来执行 | AI 自动判断并调用 | 你手动输入命令 |
| 执行时机 | AI 在对话中自主决定 | 你主动触发 |
| 使用门槛 | 不需要记命令，说人话就行 | 需要知道具体命令语法 |
| 适用场景 | 需要 AI 做判断的复杂任务 | 简单、明确、可预测的任务 |
| 灵活性 | 高（AI 可以根据上下文调整） | 低（命令是固定的） |
| 性能开销 | 有（额外 500 tokens/schema） | 无 |
选择决策树
遇到一个任务，按这个顺序判断：
1. AI 需要做判断吗？如果是 → MCP。AI 需要根据上下文决定怎么处理 GitHub PR、MCP 比 CLI 更适合。如果否 → 继续往下。
2. 任务简单且固定吗？比如「每天早上 pull 最新代码」这种自动化脚本 → CLI 更直接。如果是 → CLI。
3. 需要和其他 AI 能力组合吗？比如「先让 AI 读 Notion 任务，再让 AI 帮你规划开发顺序，再让 AI 更新 Linear 状态」→ MCP。因为 MCP 工具可以无缝和其他 AI 能力组合。如果是 → MCP。
4. 频率高吗？每天固定跑一次的 → CLI 更高效，不需要每次都让 AI 思考「要不要调用这个工具」。偶尔一次的 → MCP 更好，因为不需要记住命令语法。
典型例子
场景 1：定期汇报每天下午 5 点要把当天的工作汇总发到 Slack。→ CLI 更适合：写一个 cron 脚本，每天定时执行 /usr/local/bin/slack-report，固定流程不需要 AI 判断。
场景 2：PR review有人提了 PR，让 AI review 并评论。→ MCP 更适合：AI 需要读代码、做判断、按严重性分类问题，流程复杂且需要上下文理解。
场景 3：数据库查询偶尔需要查一下 PostgreSQL 里的数据。→ MCP 更适合：说「查一下过去一周新增的用户数」比记住 SQL 命令更自然。
场景 4：截图分析截了一张图，让 AI 看看页面有什么问题。→ Chrome DevTools MCP 更适合：AI 直接读页面 DOM 和控制台，比 CLI 强太多了。
///
PART 08
本章小结
MCP（Model Context Protocol）是 AI 连接外部世界的标准协议，类比来说就是「AI 时代的 USB 接口」。通过 MCP，AI 可以操作 Notion、Linear、Slack、GitHub、Playwright 等平台，真正成为你工作流的中心枢纽。
MCP 和 Skill 是互补关系：MCP = 厨房（提供工具能力），Skill = 菜谱（定义如何使用工具）。两者配合，AI 才能既有能力又有方向。
配置 MCP 有三个关键点：优先使用 .opencode/opencode.json、分清 local 和 remote 类型、用 opencode mcp list 检查连接状态。
但也要注意性能问题：每个 MCP 增加约 500 tokens 的 schema 开销，不要贪多，只启用当前任务需要的。
最后，MCP 和 CLI 各有适用场景：需要 AI 做判断、流程复杂、需要组合多种能力时用 MCP；简单固定、高频重复的任务用 CLI。
掌握 MCP，你就把 AI 从一个「只能操作本地文件的哑巴」，变成了一个「能连通一切的全能助手」。
THANKS FOR READING
🦐 龙虾 · OpenClaw 技术分享
