AI Agent 工具对比：MCP 为什么只是个过渡产物

Mon, 20 Apr 2026 12:37:00 +0800

如果你做过 AI Agent 开发，大概率已经用过 MCP，也可能接触过 Agent Skill 的概念。我们不需要再解释它们是什么——这篇文章要回答的问题是：当两者都能实现"让 AI 调用工具"这件事时，为什么我认为 MCP 是一个会被淘汰的过渡态方案。

MCP 的根本局限：协议层无法承载语义

MCP 的设计逻辑是：给 AI 一个结构化的工具调用协议，工具发现、调用、解析全部走固定格式。

问题在于，这个协议设计是给人看的，不是给 AI 看的。

JSON Schema 能定义参数类型、返回值结构，但它无法传达这些信息：为什么这个参数通常传这个值、这个工具在什么前置条件下才能正常工作、它的失败模式大概是什么样子的。这些上下文才是 AI 在真实场景里做决策时最需要的东西，但 MCP 协议层根本承载不了。

结果是：用 MCP 构建的工具调用能力，体验高度依赖 prompt engineering——你需要在 prompt 里额外补充协议定义里没有的东西。这说明协议层设计有缺口，而这个缺口不是靠完善 schema 能解决的，因为它本质上是一个语义损失的问题，不是格式问题。

另一个现实问题是维护成本。每个新能力都需要一个独立的 MCP server，你需要维护 server 代码、schema 定义、网络连接。协议版本更新的时候，所有 server 可能都要跟着改。这套复杂度对于个人开发者或小团队来说，负担不轻。

Skill 为什么更接近 AI 真正需要的东西

Agent Skill 用 Markdown 作为能力封装的核心格式——用人类语言描述这个能力是什么、在什么场景下用、怎么用，附带脚本和参考模板。

AI 读取一个 Skill 文档，获得的不只是"这个工具叫什么名字、接受什么参数"，而是完整的决策上下文：什么时候该用它、什么时候不该用它、边界情况怎么处理。这些信息本来就需要给人类开发者看，现在直接给 AI 用，不需要二次转化。

对工程师而言，文件系统作为 Skill 管理的基础带来了一个额外的好处：这套工作流和工程师的日常完全对齐。Git 管理 Skill 目录，天然支持版本控制、分支、PR review。AI 需要什么能力就读什么文档，不需要理解任何协议层，也不需要维护一个运行中的 server 进程。

对普通用户而言，Skill 的优势更加直接。现在的 Agent 越来越完善，“harness engineering"已经出现——用户不需要理解技术细节，只需要描述自己需要什么能力。安装一个 Skill，可能就是一句话的事：AI 自动读取 Skill 文档，理解这个能力做什么、怎么配置，然后自动完成依赖安装、API 配置、权限验证这些原本需要技术人员才能搞定的事情。对用户来说，Skill 就是一个能力的说明书，而 Agent 是那个读完说明书就能执行的执行者。MCP 做不到这一点，因为它要求用户先理解 server、schema、协议版本这些概念——这些是工程师的语言，不是普通用户的语言。

Skill 的语义化封装让这种"零门槛安装"成为可能。当能力是用人类语言描述的文档时，Agent 才能真正替用户做那些技术决策。协议层越厚，这个代理成本就越高，而 Skill 恰恰是把这一层压缩到了最小。

	MCP	Agent Skill
新增一个工具	写 server + schema + 配置	写一个 Markdown 文件
语义表达能力	受 JSON Schema 限制	Markdown 自由格式
上下文信息	需要 prompt engineering 补充	写在文档里，AI 直接读取
协议版本维护	需要	不需要
普通用户安装	需要理解 server 和协议概念	Agent 读文档自动完成配置
调用方配置	需要配置 server 连接	直接读文件

MCP 的云端优势是一个伪命题

MCP 常被提及的一个优势是云端部署——server 独立运行，多个 Agent 可以共享。

这个优势是真实的，但它属于"网络调用"这个能力范畴，不属于 MCP 协议本身。Agent Skill 完全可以建立在 REST API 调用之上，Skill 文档里的脚本本来就能调任何 HTTP endpoint。云端部署这件事，Skill 并不缺失。

对于已有 REST API 的 SaaS 服务，这个对比更清晰：

用 MCP：写一个 server 把 REST API 包一层，维护 schema，跟 MCP 协议版本保持同步
用 Skill：写一个 Markdown 描述清楚这个 API 做什么、怎么调用，AI 读完直接用

MCP 要求你额外维护一套协议系统和 server 进程，而 Skill 用更少的成本覆盖了所有这些需求。 当一个更简单的方案能做到所有同样的事的时候，复杂的方案就该退场了。

Skill 的形态本身也在演进

但我必须承认，Markdown + 文件系统可能也不是终点。

这个方案有一个还没解决好的问题：Skill 的动态性。当一个 Skill 依赖的外部 API 变了，或者需要实时状态的时候，文件系统里的静态文档怎么跟上变化？目前的解法是靠脚本和模板，但脚本的执行环境、安全边界、状态管理这些问题都还没有标准答案。

另外，Skill 之间的依赖关系、优先级排序、以及多个 Skill 同时适用一个请求时的决策逻辑，这些也都是开放问题。

我的判断是：Skill 会演进，可能不再以文件系统的静态文件为核心，而是出现某种更动态的能力注册与发现机制。但这个机制大概率会是 Skill 设计思路的延续，而不是回到 MCP 的协议设计方向。

写在最后

MCP 不是坏设计。它在 AI 工具调用这个课题上迈出了重要的第一步，让"AI 连接外部世界"这件事从不可能变成了可能。

但可能和正确之间还有距离。当我们发现一种更符合 AI 认知方式的能力封装方案时，过渡态就应该退出舞台。

Agent Skill 是不是最终答案？我不确定。但它比 MCP 更接近 AI 真正需要的东西——语义、上下文、灵活性，以及一个不需要额外协议层的调用体验。这种封装方式对工程师友好，对普通用户更友好，因为它把技术复杂性藏进了文档层，让 Agent 替用户处理那些本不该需要人类操心的事。

这个方向的探索，值得认真对待。

最后贴上 2025 年我对 MCP 这个概念的剖 (tu) 析 (cao)。

AI Agent + 产品经理 = 产品测试工程师

Wed, 08 Oct 2025 20:39:15 +0800

9 月公司组织讨论 AI 在工作场景中的应用。正好我在研究 E2E 测试相关的话题，于是尝试了一下 OpenCode 和 Playwright，发现效果惊人的好。

用 OpenCode 而没有选其他 AI Agent 框架（如 Claude Code）是因为它可以集成公司的企业版 Github Copilot 账号，这样我们在公司内网可以无限量调用 GPT-4 和 Claude Sonnet 等大语言模型。

其次微软做的 Playwright 是一个可以调用浏览器 API 的自动化测试框架。相比于 Selenium 更轻量，社区维护更积极，和大模型结合也更好（有官方的 MCP Server）。Playwright 还内置了 webdriver，免去了很多环境配置的麻烦。

基于 OpenCode 和 Playwright-MCP-Server，稍加少量提示词模板，就可以不写一行测试代码，完整跑通一组 Web UI 的 E2E 测试用例。这在过去简直无法想象。

一直以来我都认为，让程序员去编写 E2E 测试代码费事费力，实属弊大于利的行为。对于边界情况和性能，单元测试和 API 测试可以满足90%以上的需求。E2E 测试的价值主要在于发现UI交互和集成方面的问题。用自动化 E2E 测试代码去覆盖集成测试和 UI 测试场景，不但维护成本极其高昂，每个微小的 UI 调整，都可能破坏测试代码，而且统计下来，测试组合中失败的用例有一半以上并不是功能异常引起，而是 UI 加载延迟、前端修改了变量名称、测试环境网速慢等原因。而对于一些真正威胁集成环境的特殊情况，比如网络中断造成的请求重试、接口修改造成的参数越界，编写 E2E 测试的效率都不如 UT 和 API 测试。因此我一直鼓励团队招聘一名全职的测试开发工程师，而不是让开发每个迭代都留出一部分时间去维护 E2E 测试用例。

另一方面，站在团队项目负责人的角度，我更关心需求是否真正被理解和落地，如何去验证程开发工程师实现的结果。

AI Agent 的出现让敏捷开发的工作流程有了变化。如上文提到的 OpenCode + Playwright-MCP-Server 的组合，AI 只需要阅读用户文档了解一些 UI 操作的基础知识，就能根据测试用例的自然语言描述，自动打开浏览器，根据提示词的要求一步步点击页面元素完成整个业务功能的操作，如果稍加指导，还能给出具体的执行步骤、结果、遇到的问题，生成完整的测试报告。这并不亚于聘请了一名初级测试工程师。

因为维护成本的极大降低（只需要维护一组测试用例的 markdown 描述文件），过去很多细节的 UI 测试场景可以用 AI Agent 来覆盖。最重要的是，这种工作完全不依赖研发人员，作为产品经理或者 PO、BA，都可以直接用自然语言编写测试用例，使编写用户故事 - 验证功能形成闭环，消除了业务 - 研发 - 测试三者之间互相转述需求带来的歧义。

丰田模式的原则中提到生产中造成浪费的几种情况：

过度生产
等待
不必要的运输
过度加工
过多的库存
不必要的移动
缺陷

AI Agent 一定程度上解决了“过度生产（要重复编写测试代码）”，“等待（从需求实现到测试用例实现，最后才能验证功能）”，“不必要的运输（业务需求在不同人员之间的传递）”三个方面的浪费。