拓冰网站定制 
从OpenClaw的“两只手”到MCP协议标准化引子同一句指令两种工具调用方式你在用OpenClaw执行一个常见任务“帮我把Jira上本周未完成的任务同步到本地周报文档里。”任务顺利推进Agent识别到Jira有开放API直接通过API拉取了任务列表——这是第一只手走的是“正规军”通道。然后它需要打开本地的Word文档并写入内容但WPS没有提供可编程接口。于是Agent切换到第二只手——“模仿秀”模式它像人一样移动鼠标点击“打开文件”按钮在弹出的对话框中输入文件路径定位到文档末尾把任务列表逐条粘贴进去。这个双通道设计回答了Agent工具调用的第一个问题当Agent需要操作真实世界的软件时它从哪里获得这些能力而当你换一个场景需要让Agent同时操作Jira、Confluence、Slack和内部人事系统时新的问题就出现了如果每个Agent产品都自己定义一套工具接入方式那么每接入一个新系统开发者就要重写一遍适配代码。工具调用的第二个问题由此浮现这些能力能不能标准化这就是MCPModel Context Protocol要解决的问题。本文将沿着“产品实践 → 协议标准化 → 最新进展与争议 → Java落地”的主线拆解Agent工具调用的完整图景。一、OpenClaw的“两只手”工具调用的工程实现要理解工具调用先从最具体的产品案例入手。OpenClaw小龙虾的工具调用架构是当前开源Agent产品中最清晰的教学样本。API通道与UI自动化通道OpenClaw的工具调用设计遵循一个核心原则优先走结构化接口API不可用时降级到UI自动化。在API通道一侧OpenClaw的工具与服务层是一个完整的“外设层”把现实世界的各种能力——浏览器控制、画布渲染、媒体处理、语音合成、定时任务、记忆检索——统一包装为AI可调用的工具接口。以浏览器工具为例它基于Playwright Chrome DevTools ProtocolCDP实现完整的浏览器自动化提供导航、截图、点击、表单填写等标准化操作AI通过browser.navigate、browser.screenshot、browser.click等高层接口调用。在UI自动化通道一侧OpenClaw引入了Peekaboo bridge。这是一个本地运行的、感知权限的UI自动化代理。OpenClaw.app作为PeekabooBridge的宿主peekaboo CLI作为客户端复用macOS应用的TCC权限来执行截图、点击、菜单操作、对话框交互、Dock操作和窗口管理。值得关注的是OpenClaw维持了四条独立的桌面控制路径PeekabooBridge宿主路径、Agent驱动的computer use路径、Codex Computer Use路径以及直接注册的cua-driver MCP路径——它们刻意保持隔离各有明确的适用场景。从“预定义工具”到“MCP原生化”OpenClaw在2026年的一个重要演进是工具能力的MCP原生化。以Chrome浏览器工具为例新增的Chrome MCP模块将Chrome浏览器本身作为MCP服务器暴露给Agent提供基于标准MCP协议的浏览器操作接口支持多Profile、多标签页管理、DOM快照、JS执行等能力。这意味着OpenClaw的浏览器工具不再是“自定义工具”而是一个标准的MCP Server。任何支持MCP协议的Agent都可以连接并使用这些工具不再需要为OpenClaw单独编写适配代码。此外OpenClaw还通过A2UIAgent-to-UI框架实现了另一种工具调用模式Agent不需要调用外部工具而是自己生成带有特殊语义属性的HTML来构建交互界面。当用户点击界面上的按钮时客户端通过WebSocket发送操作事件到Canvas服务器服务器将其转换为标准化的工具调用转发给Agent运行时Agent处理后调用Canvas Update生成新界面内容通过WebSocket推送到客户端自动重新渲染。这种模式把“用户交互”本身也变成了工具调用的一种形式——用户点击按钮等价于触发了一次工具执行。Java视角OpenClaw的“API优先UI自动化兜底”双通道和Java中“优先调用内部gRPC服务降级走REST HTTP”的容错策略完全一致。四条桌面控制路径的隔离设计相当于Java中不同通信协议gRPC、HTTP、WebSocket、Message Queue服务于不同场景——不是互斥的而是各有适用边界。A2UI的事件驱动流程则和Java中Spring事件驱动模型ApplicationEvent EventListener的设计思路一致。二、工具调用的“N×M”困境为什么需要MCPOpenClaw的工具调用设计很精巧但它面临一个根本性的扩展问题。假设你有N个Agent产品Claude Desktop、Cursor、Windsurf、OpenClaw……M个外部工具Jira、Confluence、Slack、数据库、文件系统……在传统模式下你要为每一个Agent×工具的组合编写定制化的适配代码——总共N×M个适配器。这就是所谓的“N×M集成悖论”。MCP通过定义一套通用的双向连接规范将复杂的集成方程简化为线性的“NM”模式工具提供方只需实现一个MCP ServerAgent提供方只需实现一个MCP Client二者通过标准协议通信。MCP被业内形象地比喻为“AI领域的USB-C接口”——一个工具插口所有Agent都能用。MCP的架构设计MCP采用“客户端-宿主-服务器Client-Host-Server”三层物理隔离模型基于成熟的JSON-RPC 2.0消息流规范。Host宿主最终用户使用的AI应用如Claude Desktop、Cursor IDE。它扮演最高级别的协调者角色管理多个MCP Client实例的生命周期并作为全局安全策略的实施决策点。Client客户端嵌入在宿主应用内负责与特定的MCP Server建立一对一的隔离连接。核心职能是“提示词组装”——收集来自Server的上下文数据构建出LLM能够理解的高质量提示流。Server服务器协议的功能供给端将外部能力文件系统、数据库、API包装为标准化组件。Server通过三大核心基元暴露能力资源Resources提供静态上下文类似REST的只读终端工具Tools赋予模型执行实际操作的能力提示词Prompts提供可复用的交互模板。这个架构借鉴了语言服务器协议LSP的成功经验。LSP为代码编辑器定义了一套标准协议使得VS Code、IntelliJ、Vim等不同编辑器都能通过同一协议连接不同语言的Language Server。MCP把这个思路搬到了AI领域不同Agent产品通过同一协议连接不同工具Server。Java视角MCP的三层模型和Java Web应用的分层架构高度对应。Host≈Spring Boot Application管理整体生命周期Client≈Service层编排和组装请求Server≈Repository/DAO层提供数据访问能力。MCP的“资源/工具/提示词”三大基元和Java中“只读查询/写操作/模板方法”的分工一致。三、MCP的2026从“能用”到“生产就绪”MCP自2024年11月由Anthropic提出后经历了快速演进。2025年12月Anthropic将MCP捐赠给Linux Foundation旗下的Agentic AI FoundationAAIF使其成为社区驱动的开放标准。2026年7月28日MCP发布第五版规范MCP 2026-07-28被Anthropic称为“迄今为止最重要的规范发布之一”。核心变化从有状态到无状态2026规范最重大的架构变化是从双向有状态协议转向无状态请求/响应模型。在旧版规范2025-11-25中MCP维护协议级的会话状态Server需要保持与Client的连接以跟踪上下文。新规范删除了协议级会话每个请求都是自包含的不依赖之前的连接状态。这意味着MCP Server现在可以部署在Serverless和边缘基础设施上大幅简化了扩展和运维。此前开发者实测发现MCP在某些任务上的失败率接近30%主要卡在超时和连接不稳定上。无状态化正是对这些工程痛点的直接回应。扩展生态与授权硬化新规范同时引入了标准化的扩展框架。MCP Apps扩展支持在对话中内联渲染交互式UI元素图表、表单、视频播放器Tasks扩展支持异步执行长时间运行的操作支持轮询、中途输入和持久化句柄。授权方面MCP的认证机制从草案进入正式版对齐生产级OAuth 2.0和OIDC部署标准使MCP Server可以直接对接Entra、Okta等企业身份系统。生态规模截至2026年中MCP生态已拥有超过32,600个服务器暴露超过229,800个工具。MCP的SDK月下载量超过4亿次较一年前增长4倍。OpenAI的Agents SDK、Google的Gemini、Microsoft的GitHub和Azure都已集成MCP支持。Java视角MCP从有状态到无状态的变化和Java生态中从Stateful Session Bean到Stateless Session Bean再到RESTful无状态服务的演进路径惊人相似。无状态化带来的好处——易于水平扩展、部署简化、故障恢复——也正是Java开发者从EJB时代迁移到Spring Boot微服务时体验过的价值。四、MCP真的准备好了吗安全争议与效率质疑MCP在快速标准化的同时也暴露出了不容忽视的问题。作为技术专栏有必要把这些争议呈现给读者。安全一个架构级的裂缝2026年4月以色列安全研究团队OX Security发布了一份研究报告指出MCP存在架构级设计缺陷波及约20万台服务器可能导致系统被完全接管。问题的根源在于MCP将STDIO作为本地传输机制用于AI应用程序生成MCP服务器子进程。研究人员发现“在实际操作中这实际上允许任何人运行任意操作系统命令如果该命令成功创建了STDIO服务器则返回句柄若传入其他命令则在命令执行后返回错误”。该漏洞已衍生出四类攻击方式未经身份验证的命令注入、带防护绕过的未授权命令注入、零点击提示注入以及MCP市场投毒。影响范围包括LangFlow、Flowise等多个主流项目涉及下载量超1.5亿次的软件包。受影响的产品列表涵盖了Windsurf、Claude Code、Cursor、Gemini-CLI和GitHub Copilot等主流AI编程工具。更值得关注的是Anthropic的回应。研究人员多次要求从协议层面修复但Anthropic“以该行为属于‘预期表现’为由拒绝修改协议架构”。研究团队在一份30页技术报告中写道“这一变更并未解决任何实质问题”。IEEE随后发表了一篇跨实体安全研究论文分析了6个公共注册表中的67,057个MCP服务器发现了大量可被利用的安全隐患。效率“吃上下文”的代价安全之外MCP在效率上也面临严峻质疑。2026年初Perplexity CTO Denis Yarats在公司内部宣布放弃MCP转而使用API和CLI方案。Y Combinator CEO Garry Tan更是在30分钟内构建了一个CLI替代方案。Hacker News上的讨论呈现出强烈的反MCP倾向。批评的核心在于MCP的Token消耗。有开发者测试发现当一个MCP Server绑定的工具太多时例如43个工具光工具描述就能占用55,000个Token——“AI还没开始干活上下文预算就先花掉了一半”。Cloudflare的实测数据显示将MCP的工具调用机制替换为代码生成后Token使用量降低了244倍。有实测表明CLI方案比MCP方案便宜17倍可靠性接近100%。2026年1月CoSAI发布的《MCP安全白皮书》指出“MCP引入的架构级安全风险无法通过补丁或配置修改来解决”。如何看待这些争议当前行业对MCP的态度正在分化。实用主义派如Perplexity选择放弃MCP回归CLIAPI的轻量化方案。标准化派如Anthropic、OpenAI、Google继续推动MCP的规范演进认为无状态化、授权硬化和扩展框架正是对批评的回应。务实派如Workato则认为“放弃MCP的人在解决错误的问题”——基础MCP缺少防护当然会失败但加上适当的工程护栏后MCP在企业环境中仍然有价值。从企业落地看Pinterest已经搭建了内部MCP生态系统用于驱动AI Agent实现复杂工程任务自动化AWS推出了SAP MCP服务器用于编排企业级集成场景Moody‘s通过专用MCP服务器将信用与合规工作流接入AI助手。这些案例表明MCP在受控的企业环境中仍然具有实际价值前提是配套足够的安全和效率护栏。Java视角MCP当前面临的“安全 vs 效率”争议和Java社区早期对EJB vs Spring的争论有结构性相似之处。EJB提供了标准化的企业级能力但太重、太复杂、性能开销大Spring用更轻量的方式实现了类似的能力代价是标准化程度降低。MCP的标准化优势是真实的但“轻量化替代方案”的竞争压力同样真实。Java开发者的经验告诉我们标准化的价值只有在生态足够大、切换成本足够高的时候才会显现——MCP能否走到那一步取决于它能否在安全和效率两个维度上补齐短板。五、Java开发者的工具调用实践Spring AI的MCP支持对于Java开发者Spring AI已经提供了MCP的完整支持。通过McpTool注解可以用很少的代码将一个Spring Bean的方法暴露为MCP工具。一个典型的实现是用McpTool注解47行代码即可暴露10个方法作为MCP工具这些方法既可以作为传统REST API被调用也可以通过MCP协议被Agent消费。双轨策略REST API MCP工具更值得推荐的模式是双轨暴露同一个Spring Boot应用既对外提供REST API供传统客户端调用又通过MCP Server暴露工具能力供Agent调用。Microsoft提供的一个多Agent银行助手示例展示了这种模式业务API同时以REST和MCP工具的形式暴露Agent通过MCP消费工具传统客户端通过REST消费服务。RestControllerpublicclassAccountController{// 传统REST端点GetMapping(/api/accounts/{id})publicAccountgetAccount(PathVariableStringid){...}// 同一个业务逻辑同时暴露为MCP工具McpTool(nameget_account,description根据ID查询账户余额)publicAccountgetAccountAsTool(StringaccountId){...}}这种双轨策略的核心价值是业务逻辑只写一次但可以从两个入口被消费。这和你不会为Web端和移动端各写一套后端服务是同一个道理。Java视角MCP的工具注册机制和你熟悉的JMX MBean注册有结构上的相似性——都是把已有的方法暴露为可被外部调用的管理接口。区别在于JMX的调用方是运维平台MCP的调用方是AI Agent。Spring AI的McpTool注解则相当于RequestMapping在AI工具领域的对应物——一个注解声明框架自动处理协议适配。小结工具调用的三个关键判断第一工具调用是Agent从“对话”走向“执行”的开关。没有工具调用Agent只能输出文本建议有了工具调用Agent才能读文件、发邮件、调API、操作界面。OpenClaw的“两只手”设计API通道UI自动化通道揭示了工具调用的根本工程原则优先走结构化接口不可用时降级到UI模拟——这和Java中“优先调用内部服务降级走HTTP”的容错策略一脉相承。第二MCP正在完成工具调用从“私有实现”到“公共协议”的标准化。它用“NM”模型替代“N×M”适配器困境用USB-C式的统一接口降低了Agent接入外部工具的成本。2026年的无状态化改造和扩展框架发布标志着MCP正在从“能用”走向“生产就绪”。第三标准化不等于完美。MCP当前面临的安全争议和Token效率质疑是真实的工程问题。作为Java开发者你在引入MCP时应该同时评估其收益标准化接入、生态丰富和代价安全风险、Token开销而不是因为“MCP是行业标准”就无条件采用。你在Java中评估任何第三方框架时积累的判断力——看生态、看安全、看性能、看维护活跃度——在Agent工具调用领域同样适用。下一篇进入1.4 Agent的规划能力从ReAct的基础循环出发拆解H-V-R假设-验证-反思范式如何让Agent具备自我纠错能力以及Manus的CodeAct架构如何让Agent从“从菜单点菜”进化到“自己下厨”。 系列专栏导航 专栏导航 大模型学习其他专栏衔接 《若依框架全攻略从入门到项目实战》 《深入浅出Mybatis》 全面掌握MySQL工具 《深入浅出Maven》 《深入浅出Kafka》 《全面掌握Swagger从入门到实战》 《Lombok高效Java开发的秘密武器完全解读》 博客概览《程序员技术成长导航专栏汇总》建议按系列顺序阅读从基础到进阶逐步掌握核心能力避免遗漏关键知识点全景导航博文系列《一口气学完fastJson》《一文搞懂PageHelper》《一文搞懂MyBatis》 Agent的工具调用
从OpenClaw的“两只手”到MCP协议标准化引子同一句指令两种工具调用方式你在用OpenClaw执行一个常见任务“帮我把Jira上本周未完成的任务同步到本地周报文档里。”任务顺利推进Agent识别到Jira有开放API直接通过API拉取了任务列表——这是第一只手走的是“正规军”通道。然后它需要打开本地的Word文档并写入内容但WPS没有提供可编程接口。于是Agent切换到第二只手——“模仿秀”模式它像人一样移动鼠标点击“打开文件”按钮在弹出的对话框中输入文件路径定位到文档末尾把任务列表逐条粘贴进去。这个双通道设计回答了Agent工具调用的第一个问题当Agent需要操作真实世界的软件时它从哪里获得这些能力而当你换一个场景需要让Agent同时操作Jira、Confluence、Slack和内部人事系统时新的问题就出现了如果每个Agent产品都自己定义一套工具接入方式那么每接入一个新系统开发者就要重写一遍适配代码。工具调用的第二个问题由此浮现这些能力能不能标准化这就是MCPModel Context Protocol要解决的问题。本文将沿着“产品实践 → 协议标准化 → 最新进展与争议 → Java落地”的主线拆解Agent工具调用的完整图景。一、OpenClaw的“两只手”工具调用的工程实现要理解工具调用先从最具体的产品案例入手。OpenClaw小龙虾的工具调用架构是当前开源Agent产品中最清晰的教学样本。API通道与UI自动化通道OpenClaw的工具调用设计遵循一个核心原则优先走结构化接口API不可用时降级到UI自动化。在API通道一侧OpenClaw的工具与服务层是一个完整的“外设层”把现实世界的各种能力——浏览器控制、画布渲染、媒体处理、语音合成、定时任务、记忆检索——统一包装为AI可调用的工具接口。以浏览器工具为例它基于Playwright Chrome DevTools ProtocolCDP实现完整的浏览器自动化提供导航、截图、点击、表单填写等标准化操作AI通过browser.navigate、browser.screenshot、browser.click等高层接口调用。在UI自动化通道一侧OpenClaw引入了Peekaboo bridge。这是一个本地运行的、感知权限的UI自动化代理。OpenClaw.app作为PeekabooBridge的宿主peekaboo CLI作为客户端复用macOS应用的TCC权限来执行截图、点击、菜单操作、对话框交互、Dock操作和窗口管理。值得关注的是OpenClaw维持了四条独立的桌面控制路径PeekabooBridge宿主路径、Agent驱动的computer use路径、Codex Computer Use路径以及直接注册的cua-driver MCP路径——它们刻意保持隔离各有明确的适用场景。从“预定义工具”到“MCP原生化”OpenClaw在2026年的一个重要演进是工具能力的MCP原生化。以Chrome浏览器工具为例新增的Chrome MCP模块将Chrome浏览器本身作为MCP服务器暴露给Agent提供基于标准MCP协议的浏览器操作接口支持多Profile、多标签页管理、DOM快照、JS执行等能力。这意味着OpenClaw的浏览器工具不再是“自定义工具”而是一个标准的MCP Server。任何支持MCP协议的Agent都可以连接并使用这些工具不再需要为OpenClaw单独编写适配代码。此外OpenClaw还通过A2UIAgent-to-UI框架实现了另一种工具调用模式Agent不需要调用外部工具而是自己生成带有特殊语义属性的HTML来构建交互界面。当用户点击界面上的按钮时客户端通过WebSocket发送操作事件到Canvas服务器服务器将其转换为标准化的工具调用转发给Agent运行时Agent处理后调用Canvas Update生成新界面内容通过WebSocket推送到客户端自动重新渲染。这种模式把“用户交互”本身也变成了工具调用的一种形式——用户点击按钮等价于触发了一次工具执行。Java视角OpenClaw的“API优先UI自动化兜底”双通道和Java中“优先调用内部gRPC服务降级走REST HTTP”的容错策略完全一致。四条桌面控制路径的隔离设计相当于Java中不同通信协议gRPC、HTTP、WebSocket、Message Queue服务于不同场景——不是互斥的而是各有适用边界。A2UI的事件驱动流程则和Java中Spring事件驱动模型ApplicationEvent EventListener的设计思路一致。二、工具调用的“N×M”困境为什么需要MCPOpenClaw的工具调用设计很精巧但它面临一个根本性的扩展问题。假设你有N个Agent产品Claude Desktop、Cursor、Windsurf、OpenClaw……M个外部工具Jira、Confluence、Slack、数据库、文件系统……在传统模式下你要为每一个Agent×工具的组合编写定制化的适配代码——总共N×M个适配器。这就是所谓的“N×M集成悖论”。MCP通过定义一套通用的双向连接规范将复杂的集成方程简化为线性的“NM”模式工具提供方只需实现一个MCP ServerAgent提供方只需实现一个MCP Client二者通过标准协议通信。MCP被业内形象地比喻为“AI领域的USB-C接口”——一个工具插口所有Agent都能用。MCP的架构设计MCP采用“客户端-宿主-服务器Client-Host-Server”三层物理隔离模型基于成熟的JSON-RPC 2.0消息流规范。Host宿主最终用户使用的AI应用如Claude Desktop、Cursor IDE。它扮演最高级别的协调者角色管理多个MCP Client实例的生命周期并作为全局安全策略的实施决策点。Client客户端嵌入在宿主应用内负责与特定的MCP Server建立一对一的隔离连接。核心职能是“提示词组装”——收集来自Server的上下文数据构建出LLM能够理解的高质量提示流。Server服务器协议的功能供给端将外部能力文件系统、数据库、API包装为标准化组件。Server通过三大核心基元暴露能力资源Resources提供静态上下文类似REST的只读终端工具Tools赋予模型执行实际操作的能力提示词Prompts提供可复用的交互模板。这个架构借鉴了语言服务器协议LSP的成功经验。LSP为代码编辑器定义了一套标准协议使得VS Code、IntelliJ、Vim等不同编辑器都能通过同一协议连接不同语言的Language Server。MCP把这个思路搬到了AI领域不同Agent产品通过同一协议连接不同工具Server。Java视角MCP的三层模型和Java Web应用的分层架构高度对应。Host≈Spring Boot Application管理整体生命周期Client≈Service层编排和组装请求Server≈Repository/DAO层提供数据访问能力。MCP的“资源/工具/提示词”三大基元和Java中“只读查询/写操作/模板方法”的分工一致。三、MCP的2026从“能用”到“生产就绪”MCP自2024年11月由Anthropic提出后经历了快速演进。2025年12月Anthropic将MCP捐赠给Linux Foundation旗下的Agentic AI FoundationAAIF使其成为社区驱动的开放标准。2026年7月28日MCP发布第五版规范MCP 2026-07-28被Anthropic称为“迄今为止最重要的规范发布之一”。核心变化从有状态到无状态2026规范最重大的架构变化是从双向有状态协议转向无状态请求/响应模型。在旧版规范2025-11-25中MCP维护协议级的会话状态Server需要保持与Client的连接以跟踪上下文。新规范删除了协议级会话每个请求都是自包含的不依赖之前的连接状态。这意味着MCP Server现在可以部署在Serverless和边缘基础设施上大幅简化了扩展和运维。此前开发者实测发现MCP在某些任务上的失败率接近30%主要卡在超时和连接不稳定上。无状态化正是对这些工程痛点的直接回应。扩展生态与授权硬化新规范同时引入了标准化的扩展框架。MCP Apps扩展支持在对话中内联渲染交互式UI元素图表、表单、视频播放器Tasks扩展支持异步执行长时间运行的操作支持轮询、中途输入和持久化句柄。授权方面MCP的认证机制从草案进入正式版对齐生产级OAuth 2.0和OIDC部署标准使MCP Server可以直接对接Entra、Okta等企业身份系统。生态规模截至2026年中MCP生态已拥有超过32,600个服务器暴露超过229,800个工具。MCP的SDK月下载量超过4亿次较一年前增长4倍。OpenAI的Agents SDK、Google的Gemini、Microsoft的GitHub和Azure都已集成MCP支持。Java视角MCP从有状态到无状态的变化和Java生态中从Stateful Session Bean到Stateless Session Bean再到RESTful无状态服务的演进路径惊人相似。无状态化带来的好处——易于水平扩展、部署简化、故障恢复——也正是Java开发者从EJB时代迁移到Spring Boot微服务时体验过的价值。四、MCP真的准备好了吗安全争议与效率质疑MCP在快速标准化的同时也暴露出了不容忽视的问题。作为技术专栏有必要把这些争议呈现给读者。安全一个架构级的裂缝2026年4月以色列安全研究团队OX Security发布了一份研究报告指出MCP存在架构级设计缺陷波及约20万台服务器可能导致系统被完全接管。问题的根源在于MCP将STDIO作为本地传输机制用于AI应用程序生成MCP服务器子进程。研究人员发现“在实际操作中这实际上允许任何人运行任意操作系统命令如果该命令成功创建了STDIO服务器则返回句柄若传入其他命令则在命令执行后返回错误”。该漏洞已衍生出四类攻击方式未经身份验证的命令注入、带防护绕过的未授权命令注入、零点击提示注入以及MCP市场投毒。影响范围包括LangFlow、Flowise等多个主流项目涉及下载量超1.5亿次的软件包。受影响的产品列表涵盖了Windsurf、Claude Code、Cursor、Gemini-CLI和GitHub Copilot等主流AI编程工具。更值得关注的是Anthropic的回应。研究人员多次要求从协议层面修复但Anthropic“以该行为属于‘预期表现’为由拒绝修改协议架构”。研究团队在一份30页技术报告中写道“这一变更并未解决任何实质问题”。IEEE随后发表了一篇跨实体安全研究论文分析了6个公共注册表中的67,057个MCP服务器发现了大量可被利用的安全隐患。效率“吃上下文”的代价安全之外MCP在效率上也面临严峻质疑。2026年初Perplexity CTO Denis Yarats在公司内部宣布放弃MCP转而使用API和CLI方案。Y Combinator CEO Garry Tan更是在30分钟内构建了一个CLI替代方案。Hacker News上的讨论呈现出强烈的反MCP倾向。批评的核心在于MCP的Token消耗。有开发者测试发现当一个MCP Server绑定的工具太多时例如43个工具光工具描述就能占用55,000个Token——“AI还没开始干活上下文预算就先花掉了一半”。Cloudflare的实测数据显示将MCP的工具调用机制替换为代码生成后Token使用量降低了244倍。有实测表明CLI方案比MCP方案便宜17倍可靠性接近100%。2026年1月CoSAI发布的《MCP安全白皮书》指出“MCP引入的架构级安全风险无法通过补丁或配置修改来解决”。如何看待这些争议当前行业对MCP的态度正在分化。实用主义派如Perplexity选择放弃MCP回归CLIAPI的轻量化方案。标准化派如Anthropic、OpenAI、Google继续推动MCP的规范演进认为无状态化、授权硬化和扩展框架正是对批评的回应。务实派如Workato则认为“放弃MCP的人在解决错误的问题”——基础MCP缺少防护当然会失败但加上适当的工程护栏后MCP在企业环境中仍然有价值。从企业落地看Pinterest已经搭建了内部MCP生态系统用于驱动AI Agent实现复杂工程任务自动化AWS推出了SAP MCP服务器用于编排企业级集成场景Moody‘s通过专用MCP服务器将信用与合规工作流接入AI助手。这些案例表明MCP在受控的企业环境中仍然具有实际价值前提是配套足够的安全和效率护栏。Java视角MCP当前面临的“安全 vs 效率”争议和Java社区早期对EJB vs Spring的争论有结构性相似之处。EJB提供了标准化的企业级能力但太重、太复杂、性能开销大Spring用更轻量的方式实现了类似的能力代价是标准化程度降低。MCP的标准化优势是真实的但“轻量化替代方案”的竞争压力同样真实。Java开发者的经验告诉我们标准化的价值只有在生态足够大、切换成本足够高的时候才会显现——MCP能否走到那一步取决于它能否在安全和效率两个维度上补齐短板。五、Java开发者的工具调用实践Spring AI的MCP支持对于Java开发者Spring AI已经提供了MCP的完整支持。通过McpTool注解可以用很少的代码将一个Spring Bean的方法暴露为MCP工具。一个典型的实现是用McpTool注解47行代码即可暴露10个方法作为MCP工具这些方法既可以作为传统REST API被调用也可以通过MCP协议被Agent消费。双轨策略REST API MCP工具更值得推荐的模式是双轨暴露同一个Spring Boot应用既对外提供REST API供传统客户端调用又通过MCP Server暴露工具能力供Agent调用。Microsoft提供的一个多Agent银行助手示例展示了这种模式业务API同时以REST和MCP工具的形式暴露Agent通过MCP消费工具传统客户端通过REST消费服务。RestControllerpublicclassAccountController{// 传统REST端点GetMapping(/api/accounts/{id})publicAccountgetAccount(PathVariableStringid){...}// 同一个业务逻辑同时暴露为MCP工具McpTool(nameget_account,description根据ID查询账户余额)publicAccountgetAccountAsTool(StringaccountId){...}}这种双轨策略的核心价值是业务逻辑只写一次但可以从两个入口被消费。这和你不会为Web端和移动端各写一套后端服务是同一个道理。Java视角MCP的工具注册机制和你熟悉的JMX MBean注册有结构上的相似性——都是把已有的方法暴露为可被外部调用的管理接口。区别在于JMX的调用方是运维平台MCP的调用方是AI Agent。Spring AI的McpTool注解则相当于RequestMapping在AI工具领域的对应物——一个注解声明框架自动处理协议适配。小结工具调用的三个关键判断第一工具调用是Agent从“对话”走向“执行”的开关。没有工具调用Agent只能输出文本建议有了工具调用Agent才能读文件、发邮件、调API、操作界面。OpenClaw的“两只手”设计API通道UI自动化通道揭示了工具调用的根本工程原则优先走结构化接口不可用时降级到UI模拟——这和Java中“优先调用内部服务降级走HTTP”的容错策略一脉相承。第二MCP正在完成工具调用从“私有实现”到“公共协议”的标准化。它用“NM”模型替代“N×M”适配器困境用USB-C式的统一接口降低了Agent接入外部工具的成本。2026年的无状态化改造和扩展框架发布标志着MCP正在从“能用”走向“生产就绪”。第三标准化不等于完美。MCP当前面临的安全争议和Token效率质疑是真实的工程问题。作为Java开发者你在引入MCP时应该同时评估其收益标准化接入、生态丰富和代价安全风险、Token开销而不是因为“MCP是行业标准”就无条件采用。你在Java中评估任何第三方框架时积累的判断力——看生态、看安全、看性能、看维护活跃度——在Agent工具调用领域同样适用。下一篇进入1.4 Agent的规划能力从ReAct的基础循环出发拆解H-V-R假设-验证-反思范式如何让Agent具备自我纠错能力以及Manus的CodeAct架构如何让Agent从“从菜单点菜”进化到“自己下厨”。 系列专栏导航 专栏导航 大模型学习其他专栏衔接 《若依框架全攻略从入门到项目实战》 《深入浅出Mybatis》 全面掌握MySQL工具 《深入浅出Maven》 《深入浅出Kafka》 《全面掌握Swagger从入门到实战》 《Lombok高效Java开发的秘密武器完全解读》 博客概览《程序员技术成长导航专栏汇总》建议按系列顺序阅读从基础到进阶逐步掌握核心能力避免遗漏关键知识点全景导航博文系列《一口气学完fastJson》《一文搞懂PageHelper》《一文搞懂MyBatis》