沂樾我最近在一个技术社群里看到个帖子，有人晒了一张截图：本地起了三四个 MCP Server，Claude 能直接查数据库、操作设计稿、发请求到内部接口。底下评论区一片“求教程”，但我的第一反应是另一件事——当一个人把整套工具权限交给 Agent 的时候，到底有没有人认真想过，这些工具之间组合起来的能力，已经远远超过他写的那段提示词本身？这就是 AI Agent 真正“破局”后首先要面对的安全问题，也是我这篇文章想聊透的东西。我会从 MCP（Model Context Protocol）和 A2A（Agent2Agent）这两个技术点入手，结合自己实际跑过的一些项目，把协议设计后的逻辑、常见的坑、以及怎么给 Agent 定义一个安全边界，一次性讲清楚。适合正在做 Agent 应用的开发者、大模型平台架构师，也适合那些刚学会调用 MCP、但还不确定纵深风险在哪的初学者。
我知道很多人的观点是“先把功能跑通再说安全”，但在这个领域里，安全从来不是后置需求，而是 Agent 是否真的能落地的前置条件。尤其当你开始接入 A2A，让 Agent 与 Agent 之间自动对话时，旧有的权限模型会被彻底打碎。你不再面对一个用户和一个按钮，而是面对一条完全自动化的调用链路。
1. 为什么大家的Agent“走不出去”：从Function Call到MCP再到A2A的演进逻辑
1.1 开发者和模型之间,横着一条“工具鸿沟”
这两年我见过太多团队演示 Agent Demo：问一句“帮我订杯咖啡”，模型就能给出正确的工具调用参数，全场鼓掌。但等到真要把 Agent 接到企业内部的 ERP、CRM、工单系统时，所有人都卡住了。原因不在于模型能力不够，而在于“模型怎么知道企业内部有什么工具，以及这些工具长什么样”。
早期的做法是把每个工具都注册成 Function Call。这个概念很多开发者都接触过——你在代码里定义一个 get_order_status 函数，写好参数结构，然后在请求里把这堆 JSON Schema 塞给大模型。Demo 里一两个函数没什么问题，可一旦工具数量超过几十个，每次请求都要把所有工具的定义塞进上下文，Token 消耗很快就失控了。更麻烦的是，每个平台都有自己定义 Function Call 的方言，OpenAI 的写法换到 Anthropic 上就要改一遍，换个模型等于重写一遍接入层。
这就是我理解中的“工具鸿沟”：模型只懂文本，而业务系统只认 API，中间缺少一个标准化的翻译层。MCP 出现的价值，恰恰就是把这个翻译层从应用代码里抽离出来，做成一个可以被任何模型复用的公共协议。
1.2 MCP其实是把“工具调用”做成了类似USB-C的公共接口
说起 MCP，很多人第一眼看到的是三个字母，但没意识到它本质上改写了 Agent 的架构。在 MCP 的模型里，一个完整的系统由三个角色组成：Host 是运行 Agent 的交互界面，比如 Claude Desktop 或者你写的一个 Python 进程；Client 是 Host 内部负责跟远端 Server 通信的组件；Server 则对外暴露工具、资源和提示词。打个比方，这很像 USB-C 接口：无论你插的是显示器、硬盘还是扩展坞，只要遵循同一个物理标准和协议，数据就能流通。
落到实际开发中，MCP Server 通常是这样一个 Python 或 TypeScript 进程，它通过 JSON-RPC 2.0 与 Client 通信，对外暴露三类能力：Tools 是让模型主动执行的函数，Resources 是让模型按需读取的数据文件，Prompts 是可以复用的提示词模板。大多数时候我们讨论的是 Tools，因为那是模型产生实际行动的入口。
那么 MCP 为什么会成为事实标准？我认为核心原因是它大幅降低了生态接入成本。你写一个 MySQL 的 MCP Server，所有支持 MCP 的客户端就都能用了；Cursor 可以用、Claude 可以用、Codex 也可以用。工具方只需要维护一个协议实现，模型方也只需要支持一套协议，两边都不需要为每一对组合定制适配器。这种“一次接入，随处可用”的模式，让它在很短时间里挤掉了各种私有工具调用方案，成为当前 Agent 连接外部世界的默认选项。
1.3 A2A把“人用工具”的协作，扩展成了“Agent用Agent”
MCP 解决的是 Agent 怎么调用工具的问题，但 AI 应用演进到今天，大家开始关心另一个问题：当多个 Agent 需要互相协作时，它们之间用什么语言对话？谷歌在 2025 年 4 月放出的 A2A（Agent2Agent）协议，就是冲着这个问题来的。
A2A 的出发点很朴素：Agent 不应该再是一个个孤岛。比如你有一个供应链分析 Agent，另一个是客服 Agent，当客户问“我的货为什么还没到”时，客服 Agent 如果能直接调用供应链 Agent 的能力，就可以给出准确答复，而不是预设一堆规则硬撑。A2A 协议定义了 Agent 之间如何发现彼此、如何建立通信、如何传递任务状态。每个 Agent 通过发布一个 AgentCard 来描述自己的能力和接入地址，其他 Agent 可以通过 Agent Directory 这种目录服务来找到它，然后通过任务、消息、工件（Artifact）这些概念来协作。
这里有一个容易混淆的点：A2A 并不替代 MCP。MCP 管的是“Agent 与工具之间的连接”，A2A 管的是“Agent 与 Agent 之间的连接”。在实践中它们往往是嵌套的关系——一个 Agent 通过 A2A 找到另一个 Agent，而另一个 Agent 内部又通过 MCP 调用一堆工具。两层叠加后，整个调用链的复杂度会呈指数级上升，安全边界也随之被重新定义。
1.4 为什么安全会成为这轮演进的“胜负手”
前面铺垫了这么多协议层面的演进，最后落脚点都在安全上。我的观点很明确：MCP 和 A2A 把 Agent 的能力边界扩大了，但也把攻击面从“单一入口”扩展成了“一张网”。在没有 MCP 的年代，你调用一个 API 只需要相信那个 API 的开发者。现在你的模型可以通过 MCP 调用几十个第三方工具，再通过 A2A 调用更多 Agent——每一个环节都可能被注入恶意指令，每一个工具返回的内容都可能被用来操纵模型执行一个本来不该执行的操作。
所以我说安全是“新的边界”，不是因为旧的 API 安全不重要了，而是因为 Agent 引入了一种全新的信任模型：模型本身既能理解指令、又能执行操作，这让攻击者不再需要攻破你的服务器，只需要想办法污染模型收到的“上下文”就够了。理解这个问题，是进入后面实操章节的前提。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 不要把新协议当万金油：MCP、A2A、Skill、Computer Use的边界
2.1 Function Call和MCP的区别,不是“二选一”而是“层不同”
我经常看到有人问“MCP 是不是要取代 Function Call？”这种问题本身就有点把两个不同层的东西拿来比较了。Function Call 是模型厂商提供给开发者的官方接口约定，它解决的是“模型如何按格式调用我注册的函数”这件事。而 MCP 是一种开放协议，它