最近在配置 AI 工作台的时候，被一堆名词绕了一圈：技能、插件、连接器、专家、MCP、CLI。它们是同一个东西的不同叫法，还是真的各管一段？
还有一个更值得聊的现象：到了 2026 年，一堆原本走 MCP 的能力，又在往 CLI 退回去。GitHub MCP Server 有人弃用，Perplexity CTO 公开宣布不用了，OpenClaw 的开发者直接说"MCP 是个错误"。
先把两件事的结论摆出来：
前者是层级问题，后者是成本问题。
一、先理清层级：谁装着谁
把这几件事按"谁包含谁"排一遍，混乱感立刻消失。
插件 Plugin：商店里的安装包
插件不是一个独立的能力类型，它是顶层容器。你在市场里点一下"安装"，装进来的东西在后台落地成一个插件，而它内部可能同时打包了技能、专家、连接器三种形态。
日常对话里说"装了个插件"，其实是在说"装了一组能力"，具体生效的永远是里面那三样。
技能 Skill：教 Agent 怎么做
本质是一个 SKILL.md 指令包，里面写的是领域知识、操作流程、工具用法。比如"生成 PPT"、"处理 PDF"、"按某份参考文档仿写"。
特点很鲜明：不需要任何账号授权，装完即可用。它改变的是模型的"工作方法"，不改变模型"能碰到什么"。
存储也分两级：
- 用户级
~/.workbuddy/skills/—— 所有项目通用 - 项目级
{项目}/.workbuddy/skills/—— 只在项目内共享
专家 Expert：角色 + 技能组合
专家是在技能之上再包一层人格与方法论。一个"投资分析专家"可能同时挂着财务数据检索、研报解读、估值建模三个技能，外加一套固定的分析框架和提问习惯。
它与插件是正交的：插件是分发单位，专家是组织单位。
连接器 Connector：把外部账号的钥匙交出去
连接器解决的是"我怎么碰到你的数据"。腾讯文档、QQ 邮箱、企业微信、GitHub、知识库——授权之后 Agent 可以直接读写，不用你再来回复制粘贴。
这里是整个体系里唯一需要 OAuth 授权的地方，也是安全边界真正所在。每个连接器都能按会话单独开关，这一点很重要。
MCP：藏在连接器下面的协议
连接器和 MCP 不是并列关系。连接器是产品化封装（负责账号授权、开关管理、作用域），MCP（Model Context Protocol）才是它底下的通信协议。
你在连接器管理页点"添加"，走到底都是往 ~/.workbuddy/mcp.json 写一段配置。反过来，你也可以手写一个 MCP Server 配置塞进去，然后在管理页点"信任"激活它。
一张表总结：
| 概念 | 本质 | 需要授权 | 典型例子 |
|---|---|---|---|
| 技能 Skill | 知识与流程（SKILL.md） | 否 | PPT 生成、PDF 处理 |
| 专家 Expert | 角色 + 多技能组合 | 否 | 投研专家、法律顾问 |
| 连接器 Connector | 外部账号接入 | 是（OAuth） | 腾讯文档、邮箱 |
| MCP | 底层通信协议 | 看配置 | 手写 MCP Server |
判断线：技能和专家影响的是"它怎么干活"，连接器和 MCP 影响的是"它能碰到什么"。后者才需要管权限。
二、MCP 到底能干什么
抛开产品外壳，MCP 是一套 JSON-RPC 协议，一个 MCP Server 能向外暴露四类东西：
| 能力 | 作用 | 举例 |
|---|---|---|
| Tools | Agent 可以调用的函数 | search_issues、create_doc |
| Resources | Agent 可以读取的数据 | 数据库表结构、在线文档正文 |
| Prompts | 预置的任务模板 | 按某个模板写周报 |
| Sampling | 反向请求模型生成内容 | Server 让模型补写一段文案 |
传输方式三种：stdio（本地子进程，最常见）、streamable-http、sse。
它真正解决的问题是标准化：任何服务只要实现一次 MCP，所有支持 MCP 的 Agent 就都能接，不必给每个"Agent × 服务"组合各写一遍适配层。这也是 Playwright、高德地图、Notion、GitHub 都在出 MCP Server 的原因。
三、CLI 是另一条路
CLI 不走协议层，直接让 Agent 在终端敲命令。它会自己执行 --help 探索语法，靠退出码判断成败，用管道把命令串起来：
rg "oldDeprecatedFunction" -l | xargs sed -i 's/old/new/g' && npm test一次搞定重构 + 回归测试，全程没有任何工具定义进入上下文。因为 rg、git、kubectl 这些命令，模型在训练时已经见过几百万次了。
四、为什么大家往 CLI 转
1. 上下文开销差两个数量级
这是最直接的杀伤力。
MCP 的工作方式是：Server 启动后先把 tools/list 发给客户端——包含所有工具的名称、描述、参数 JSON Schema——客户端把这些全部注入模型的上下文。也就是说，Agent 还没开始干活，先背了一本工具说明书。
公开 benchmark（ScaleKit，2026.3）的数据：GitHub MCP Server 注入约 55,000 tokens，而 gh CLI 约 200 tokens，差 275 倍。国内一份综述给出的口径是"MCP 约为 CLI 的 20 倍"——数值差异来自是否叠加多个 Server，结论是一致的。
关键在于：花在说明书上的 token，就没法花在思考上了。
2. 工具越多，反而挑得越差
这点和直觉相反。随着工具数量增长，模型的 tool-selection 准确率会从 43% 掉到 14% 以下。这就是"上下文衰减"——塞进来的候选越多，越容易挑错。连三个 Server，光工具定义就能吃掉十几万 token。
3. 可靠性
同一批任务的复现测试里，CLI 约 100% 完成率，MCP 约 72%。
原因在链路长度。MCP 一次调用要穿过：模型推理 → 协议转换 → 网络 → Server 进程 → 底层 API，任一环抖动就整条失败。CLI 失败的表现非常朴素：一条命令、一份 stderr、一个退出码，你复制出来在终端重跑一次就能复现。
4. CLI 是模型的母语
这条比效率更本质。
Cloudflare 在 Code Mode 的技术博客里说得直白：LLM 写代码调用 API，比直接做 tool call 效果更好，因为训练数据里有海量真实代码，而人造的 tool call 示例少得可怜。
training 数据里塞满了 shell 命令：Stack Overflow 的回答、项目的 README、git rebase -i、kubectl apply -f、各种管道组合。模型不仅知道命令存在，还知道惯用的 flag 组合、常见报错长什么样、出错后怎么救。
而 MCP 协议诞生到现在不到两年，模型在预训练时几乎没见过几个真实的 tools/call 样例，每次都得现场读 schema 猜语义。
CLI 是母语，MCP 是需要现场翻译的外语。
5. 可组合性与维护成本
管道是 Unix 白送的能力，MCP 里每次编排都得一个个工具串行调用。维护角度更悬殊：加一个新能力，CLI 可能是 5 行 bash，MCP 要重新起一个 JSON-RPC Server、处理鉴权、维护 schema。
6. 也说安全问题
CoSAI 2026 年的 MCP 安全白皮书点出了三个结构性风险：
- 间接提示注入：外部数据里藏指令，诱导模型调用危险工具
- 工具投毒：恶意 Server 注册一个和正常工具同名的假工具
- Rug Pull：Server 先获得信任，后续版本变脸
外加实测扫到的约 7000 个直接暴露在公网的 MCP Server，其中约一半没有任何访问控制。
当然 CLI 也有自己的问题：它的权限继承自 shell，给一台 shell 基本等于给了一切，rm -rf 那类风险只能靠沙箱兜，不靠协议兜。
五、但 MCP 没死，它赢在另外一头
行业正在收敛成一个分层路由的判断：
- 内循环（本地开发、快速迭代、单人工作流）→ CLI 赢
- 外循环（跨企业系统、多租户、合规审计）→ MCP 赢
MCP 不可替代的地方恰恰是 CLI 的软肋：
| 维度 | CLI | MCP |
|---|---|---|
| 认证 | 继承自 shell，粒度粗 | 原生 OAuth 2.1 |
| 多租户安全 | 靠人工隔离 | 协议级作用域管控 |
| 审计 | shell history | 结构化调用记录 |
| 输出格式 | 文本，需解析 | 结构化 JSON |
所以成熟的形态是两者混用。Claude Code 就是典型：本地文件系统、git、测试跑批全走 CLI；需要碰企业 SaaS、需要统一账号和权限边界的地方走 MCP。
一句话概括三者角色：
技能告诉 AI 知道什么，MCP 告诉 AI 连向哪里，CLI 告诉 AI 怎么动手。
六、CLI 和 MCP 能互相叫对方吗：A2A 在哪儿
还有一个很容易混淆的问题：既然都是"接入方式"，那 CLI 和 MCP 能不能支持 A2A（Agent to Agent）——也就是让两个 Agent 互相叫对方干活？
答案是：这两个都做不到，因为方向根本不一样。
要理解这件事，先分清"纵向"和"横向"：
- 纵向调用：Agent 调工具，工具是被动的
- 横向对话：Agent 找 Agent，双方是对等的
CLI 能搞 A2A 吗：能，但是个穷人版
CLI 的交互本质是同机进程 + 字节流：管道把上一个进程的 stdout 接到下一个的 stdin，用退出码传递成败。这确实是一种组件间交互，而且极其廉价高效。
但它有三个硬限制：
- 不能跨机器。 管道是内核级的本地文件描述符，出了这台机器就不存在了。而 A2A 想解决的是跨网络、跨组织的协作。
- 没有协商。 A2A 的起点是交换能力卡片（我要什么、你会什么、参数长什么样），管道是无脑转发，下游只能被动接受字节流。
- 没有任务生命周期。 A2A 支持长任务：提交 → 查状态 → 流式收进度 → 中途取消。CLI 是一次性调用，跑完就退出。
不过得承认，在"同一台机器上让两个程序协作"这个场景里，CLI 管道的廉价和可靠没有对手。所以很多团队的做法是：把 A2A 的语义套在 CLI 上——起子进程、约定 JSON 输出、用状态文件传递进度。够用。
MCP 能搞 A2A 吗：架构上就拧着
MCP 是星型拓扑，纵向调用：客户端（Agent）发一个 tools/call，Server 执行完返回结果。整个结构里——
- Server 是纯被动的，它不能反向要求客户端去做什么
- Server 之间互相不知道对方存在，都是围着客户端转的卫星
- 所以 Agent 和 Server 是主从关系，不是对等关系
MCP 后来补了 Sampling（Server 反向请求模型生成一段内容）和 Elicitation（Server 向用户追问补充信息），算是往"平级交互"迈了半步。但那个反向请求仍然必须经过客户端的许可和转发，它不是两个 Agent 之间的直接谈判。
真正的 A2A 是另一套协议
Google 在 2025 年推的 A2A（Agent2Agent）才是为横向协作设计的，和 MCP 不冲突，是互补的两层：
| 维度 | MCP | A2A |
|---|---|---|
| 拓扑 | 星型（客户端-服务端） | 网状（对等） |
| 方向 | 纵向：Agent → 工具 | 横向：Agent ↔ Agent |
| 能力发现 | tools/list 拿工具清单 | 拉取对方的能力卡片（Agent Card） |
| 任务模型 | 一次请求一次响应 | 长任务，有状态机、可取消、可流式推送 |
| 信任边界 | 单账号授权 | OAuth，跨组织还要处理身份与代表授权 |
| 典型场景 | 让 Agent 用上一个工具 | 让 A 公司的 Agent 委托 B 公司的 Agent 办事 |
一句话记：
MCP 是"Agent 怎么用手"，A2A 是"Agent 怎么跟别的 Agent 说话"。
但"搞 A2A 交互"这句话现在被用滥了
2026 年听到"A2A 交互"，通常指三种完全不同的东西，别被绕进去：
- 跨组织 Agent 互操作 —— 真正意义上的 A2A 协议，落地还很少，标准仍在拉锯
- 多智能体协作 —— 同一个主子 Agent 体系内互发消息、共享任务列表（这类根本不走 A2A 协议，就是内部消息总线，甚至干脆是进程调用）
- 人和 AI 对话 —— 那是 H2A，不是 A2A
所以当有人问"你的 CLI 支持 A2A 吗"，先反问他要哪一种。九成情况下他要的是第 2 种——而那种协作 CLI 完全撑得住，甚至比 MCP 更顺手：子进程之间可以互相传文件、共享工作目录、并行跑批。
七、落地到具体选择
给你我自己用的判断标准：
看这个能力本身有没有成熟 CLI。
- 有（git、docker、kubectl、psql、ffmpeg、各大云厂商 CLI）→ 用 CLI + 一份 Skill 描述用法。省 token、够稳、可调试。
- 没有（企业 SaaS、私有内部系统、需要统一账号授权的服务）→ 上 MCP / 连接器。多花的那些 token 买的是鉴权、作用域和审计。
举个实际例子：我机器上的腾讯云开发 tcb 就是 CLI 路线，配一个 Skill 说明命令用法就完事，没必要给它包一层 MCP Server；而邮箱、在线文档这类要碰个人账号的服务，只能走连接器——因为必须集中授权、必须能按次收回。
结语
回头看这场"去 MCP 化"的讨论，其实不是谁淘汰谁，而是行业终于开始按成本给能力分层了。
MCP 解决了"怎么让任意 Agent 接任意服务"这个标准化问题，这个贡献不会消失。但当大家真把它用在每一件小事上时，才发现为了统一接口付出的上下文税，比想象中贵得多。
而 CLI 赢的那部分，赢在一个很朴素的道理上：对一个天天在写代码的 Agent 来说，终端就是它最熟悉的母语环境。
参考来源：ScaleKit MCP vs CLI benchmark（2026.3）、r/ClaudeAI 相关讨论、Cloudflare Code Mode 技术博客、CoSAI 2026 MCP 安全白皮书、科普中国《大模型调用工具的三种路线》综述。
Comments | NOTHING