Model Context Protocol 从 Anthropic 发布到现在快两年了，回头看这个协议在 Agent 工具接入领域的渗透速度比大多数同类标准快得多。最初发布时社区里不少人把它类比成 OpenAPI for LLMs，把大模型调用外部工具和数据的接口标准化，每个工具提供者不需要为每个 Agent 框架单独写适配器，MCP Server 写一次，所有支持 MCP 客户端的 Agent 都能接。这个类比其实比"AI 的 USB 接口"更准确，USB 解决的是硬件接口的物理和协议标准，MCP 解决的是 Agent 和工具之间的会话层协议，工具怎么注册、参数怎么声明、返回结果怎么结构化、资源怎么读取、提示词模板怎么分发，这些在 MCP 之前每个框架都有自己的一套写法，LangChain 有 LangChain Tools，AutoGen 有 AutoGen 的 function calling 格式，各家 Agent 平台之间工具基本不互通。

两年间协议本身经历了多轮迭代。从最初的 tools 和 resources 两个核心能力域开始，到 prompts 模板分发，到 sampling 让 Server 反向请求 LLM 推理能力，到 elicitation 让 Server 在需要额外信息时主动向用户发起表单或 URL 形式的信息收集请求，再到 completions、logging、roots 这些配套能力的补齐，目前最新 schema 版本是 2025-11-25，协议覆盖的交互类型已经从最初"Agent 调用工具"这个单向动作扩展到了双向会话的大部分场景。elicitation 是个比较关键的补充，它承认了一个早期版本没处理好的事实：Agent 在执行工具调用的过程中经常需要更多信息，不是所有参数都能在任务开始时一次性收集完整，允许 Server 主动回问比让 Agent 猜参数靠谱得多。

MCP 解决的问题有明确的边界。

协议标准化的是"Agent 如何发现和调用结构化工具"，工具以函数签名的形式注册，参数通过 JSON Schema 声明，返回结构是文本或 JSON。这一类工具调用覆盖了搜索、数据库查询、API 访问、代码执行等场景，在这些场景里 MCP 确实大幅降低了集成成本，Octo 在规划中的 Skill 层就支持从 MCP 市场导入可复用技能包，Mano-P 的 mano-skill 也在 ClawHub 生态里用类似的思路分发可复用能力。Agent 生态需要这样的标准，否则每个新工具都要为五六个框架各写一遍适配代码，工具作者和框架维护者都在做重复劳动。

MCP 覆盖不到的交互是纯视觉 GUI 操作。Mano-P 走的就是这条路，屏幕截图作为视觉输入，模型直接识别界面元素、预测鼠标键盘动作，不依赖任何 API 或 DOM 解析，不需要被操作的软件提供 MCP Server 或任何形式的接口。操作系统桌面、遗留企业软件、网银客户端、手机 App，这些系统要么没有 API，要么 API 不对外开放，要么每个版本 API 都在变，纯视觉方案在这些场景里的不可替代性已经被反复验证过了。Cider SDK 的量化加速让 4B 模型在 M5 Pro 上跑到 7.9 秒每步的推理速度，这种响应速度下纯视觉 GUI 操作从 demo 进入了日常可用的范围，Mano-CUA-4B-Thinking 在 100 个 macOS 真机任务里拿到 56% 成功率，超过 Qwen3-VL-Plus 云端模型的 39%。两种路线并不对立，MCP 解决有 API 的工具怎么标准化接入，纯视觉解决没有 API 的界面怎么操作，实际工作流里两种能力经常同时存在，一个研究任务可能一边通过 MCP 调用搜索 API 拉取资料，一边通过 GUI 操作去没有开放 API 的网站上截图核实数据。

当前版本里有几个设计上的取舍在社区讨论里被反复提及。采样（sampling）能力允许 MCP Server 向客户端请求 LLM 推理，这意味着工具本身可以是智能的，不只是被动执行函数调用，这为复合工具和工具链内的推理留出了空间，但也引入了权限和成本控制的新问题，一个恶意的 MCP Server 理论上可以通过 sampling 接口消耗大量推理 token。elicitation 支持表单和 URL 两种形式，解决了参数收集的问题但交互模式仍然比较受限，复杂的多轮对话式信息采集还需要客户端自己实现。资源订阅和进度通知这类能力在长任务场景下很有用，但协议层只定义了消息格式，具体的可靠性保证和重连机制留给了实现方，不同客户端在这块的行为可能不一致。

生态采用方面，Cursor、Windsurf、Claude Desktop 等主流 Agent 客户端已经支持 MCP，社区里的 MCP Server 实现数量从几百涨到了几千，从数据库连接到 GitHub 操作到浏览器控制几乎覆盖了开发者常用的工具类别。数量增长很快，质量参差也是事实，相当一部分社区 MCP Server 只是对现有 API 做了一层薄薄的包装，错误处理、参数校验、重试机制都很粗糙，生产环境里直接用会遇到不少稳定性问题。协议标准解决了互通性，但工具本身的可靠性没有捷径，只能靠使用量和反馈慢慢磨。

Octo 和 Mano-P 在工具接入层面走兼容并包的路线。Octo 的 Skill 层在规划中同时支持自建可复用提示词包和从 MCP 市场导入外部技能，运行时层不绑定特定模型厂商，可以接入 OpenClaw、Codex、Claude Code、Hermes 等不同后端，六种多智能体编排模式（Roundtable、Critic、Pipeline、Split、Swarm）在上层控制协作结构，工具调用在下层通过标准协议接入，两层解耦。Mano-P 在纯视觉 GUI 操作方向上持续推进，Cider SDK 的 W8A8/W4A8 量化把端侧推理速度推到了实用水平，Mano-AFK 的自主开发 pipeline 在 CUA Benchmark 上 W8A16 配置跑到 58% 准确率，W8A8 Cider 配置 54% 准确率但 prefill 速度到约 1453 tok/s。端侧推理加速在多 Agent 场景下的价值比单 Agent 更明显，多个模型实例同时推理时 prefill 的排队延迟直接影响整体任务完成时间，Cider 的加速在这种场景下带来的体验提升比单 Agent 场景更大。

协议标准的成熟往往走一个 S 曲线，早期采用者靠热情推动，中间段靠工具生态的网络效应拉起来，后期靠企业场景的稳定性要求兜底。MCP 大概处在第一个阶段向第二个阶段过渡的位置，协议本身已经覆盖了主流交互类型，客户端采用率在涨，但生产级 Server 的数量和质量都还有差距，安全模型和权限管控也需要更多真实场景的打磨。USB 从 1.0 到真正成为通用接口用了将近十年，MCP 大概率不需要那么久，但也不会像社交媒体上某些声音说的那样已经尘埃落定。Agent 工具接入的需求是真实的，标准化是必然趋势，纯视觉 GUI 操作作为互补能力同样有明确的应用场景，两条路线会长期共存各自覆盖不同的问题域。

https://github.com/Mininglamp-OSS