考察点
开放题，面试官想看你是否持续关注生态、有自己的判断，而不是只会背八股。面渣系列里 CLI 热潮那组问题就是这类。答题结构建议：先说格局，再说问题，最后给落地建议。追问方向：是不是泡沫、普通开发者怎么参与。
参考答案
格局：MCP 跑赢了标准之争
2024 年底 Anthropic 发布 MCP 时，它只是众多工具接入方案之一；一年多后格局已经很清楚——OpenAI、Google、微软都宣布支持，主流 IDE、Agent 框架、云服务厂商跟进，公开 registry 上的 Server 数量从零涨到数千量级。工具接入层的标准之争基本结束，MCP 成了事实标准，类似当年容器编排里 Kubernetes 的位置。这对开发者的意义很实际：写一个 MCP Server，主流 Agent 应用都能接，投入不白费。
同期 Skills 的走红补上了另一块拼图：MCP 管「能力接入」，Skill 管「知识复用」，两者合起来覆盖了 Agent 工程化最痛的两点。各大模型厂商和 IDE 相继支持 Skill 机制，社区开始出现公开共享的 Skill 库。
CLI 热潮是怎么回事
飞书、网易云音乐这类产品发 CLI，看起来复古，逻辑却很新：CLI 天然是给「会执行命令的 Agent」准备的接口——文本进文本出、可组合、有退出码，比让 Agent 点 GUI 或解析复杂网页靠谱得多。这波热潮的本质不是 CLI 复兴，而是产品开始为 Agent 准备第三种接入面（GUI 给人、API 给程序、CLI/Skill 给 Agent）。判断一个产品要不要做 CLI，就看它的核心动作能不能被命令行表达、目标用户里 Agent 使用占比有多大。
繁荣背后的四个问题
质量参差：公开 registry 里大量 Server 是个人周末项目，没有测试、没人维护、文档残缺。企业接入前的尽调成本不低，「有」和「能用」之间差距很大。
安全治理滞后：第三方 Server 能看到你传入的全部数据、能返回带注入的内容，供应链攻击面真实存在。签名、审计、权限声明这些机制还在补，现在接入第三方 Server 本质上靠信任。
协议仍在演进：MCP 的传输方案一年里换过代（HTTP+SSE 到 Streamable HTTP），鉴权规范也是后补的。Skills 格式各厂商有细微分叉。跟着生态走要接受一定的变动成本。
重复建设与泡沫：同一个 SaaS 有十几个社区 Server；「万物皆可 MCP」的阶段过去后，会淘汰掉一大批没人用的。CLI 也一样，最后留下来的只会是核心动作高频的产品。
给落地者的建议
我们自己的策略是：标准坚定跟随（新工具一律 MCP 化，知识沉淀一律 Skill 化），第三方谨慎引入（只用官方或审计过的 Server，隔离部署），自建聚焦差异化（通用能力等生态，公司特有的业务工具自己写好 schema 和描述，这恰是护城河所在）。对普通开发者，红利在于「给自己常用的产品写高质量 Server/Skill」这件事仍有大量空白，比再做一个 Agent 应用实在。
可能的追问
- MCP 会不会被模型厂商内化、最后消失？ 接入层可能被平台托管（API 直接填 Server 地址），但协议本身作为交换格式会留下来——就像 JDBC 之于数据库，看不见了但无处不在。
- A2A 会复制 MCP 的轨迹吗？ 更难。Agent 间协作的需求密度远低于工具调用，且涉及跨组织的信任和商业边界，落地周期会明显更长，短期看好在大型企业内部先跑通。
- Skills 和 MCP 会合并成一个标准吗？ 职责正交，合并没有收益。更可能的演化是 Skill 里声明依赖哪些 MCP Server，打包分发时一起装，出现「Skill 包管理器」这类基础设施。