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