要点 1：三代演进——Function Calling → MCP → Skills 不是替代，是分层#

Function Calling（底层执行）：让 LLM 从”缸中之脑”变成”指挥官”——模型输出 JSON 格式调用指令，告诉程序调哪个函数、传什么参数。工作三步走：①契约定义（JSON Schema）→ ②大脑决策（模型输出 tool call）→ ③闭环执行（结果喂回模型）。

局限：工具从 3 个变 300 个时，重复造轮子（不同模型需写不同格式）、紧耦合（工具定义硬编码在代码里）、工具描述占上下文（每个 Schema 塞进窗口，挤压对话空间）。

MCP（标准化连接）：Anthropic 2024.11 发布的开放协议，核心理念是”写一次，到处用”。采用 Host/Client/Server 三层架构：Host（如 IDE）运行 AI → Client（内嵌 Host）对接 Server → Server（独立进程）提供工具/资源/提示。通信用 JSON-RPC 2.0 over stdio（本地）或 HTTP+SSE（远程）。

解决的问题：集成点从 N×M 降到 N+M。10 个 Agent 接 20 工具，原 200 集成点；用 MCP 后，工具内部变更只需改 Server，不影响各 Agent 配置。

Skills（上层决策）：标准化”程序性知识封装格式”——MCP 给”手”，Skills 给”操作手册”。核心创新是渐进式披露三层加载：①元数据（~100 Token，启动扫描）②完整指令（匹配才加载 1-5K Token）③附加资源（执行才读）。解决 MCP 上下文爆炸和”能连≠会用”的能力鸿沟。

分层架构：三者不是替代关系，而是分别对应底层执行（FC）、标准化连接（MCP）、上层决策（Skills）。场景示例：Skills 层加载 mysql 分析技能定义维度 → MCP 层调数据库 Server 执行 SQL → Function Calling 层底层驱动跑 SQL。

要点 2：MCP 的成本危机——Token 烧钱的真相#

MCP 的 Token 消耗是真实且严重的：

根本原因：MCP 的设计是”全量加载工具定义”——所有工具的 Schema 必须塞进上下文窗口，Agent 才能知道有哪些工具可用。工具越多，上下文越拥挤，留给真正推理的空间越少。

替代方案及节省比例：

Cloudflare 的 Code Mode 案例：2,500+ API 端点，Token 从 1,170,523 降到约 1,000，节省 99.9%。Anthropic 自家的 Tool Search：Token 从 ~134K 降到 ~5K，Opus 4.5 准确率反而从 79.5% 升至 88.1%。

💡 反共识观点：MCP 的”全量加载工具定义”模式正在被证明是反模式。Agent 不需要知道所有工具的细节，只需要知道在需要时去哪里找——这和人类不需要记住所有 API 文档，只需要知道怎么查文档一样。

要点 3：MCP 的安全黑洞——协议的”暗面”#

MCP 的安全问题是系统性的：

根本原因：MCP 的设计哲学是”上下文共享”——让 Agent 能自由访问工具和数据。但”自由访问”恰恰是安全问题的根源。昨天（8-05）学过的 Sandlock 观点在此完美呼应：安全的核心是策略而非隔离，MCP 的安全漏洞本质上是”权限配置过于宽松的策略”。

要点 4：三大通信协议——MCP/A2A/ANP 的分工#

三者不是竞争而是互补：MCP 解决”手”（工具连接），A2A 解决”嘴”（智能体间通信），ANP 解决”地图”（大规模网络中的发现与路由）。在 AgentOS 的分层架构中，MCP 位于 L3（执行与工具层），A2A 位于 L5（编排与治理层），ANP 位于 L6（基础设施层）。

要点 5：从协议到 AgentOS——MCP 的终局不是”更好的协议”#

WebMCP 的通信生命周期：连（Connect）→ 取（Get Endpoint）→ 握（Handshake）→ 用（Usability）→ 断（Terminate）。双通道传输：SSE（Server→Client 推送）+ HTTP POST（Client→Server 请求）。

AgentOS 的范式迁移：从传统 OS（确定性业务、管理应用/进程）到 AgentOS（概率性推理、管理 Agent/AI 资源）。交互从 GUI/CLI”怎么做”变为 LUI”想要什么”，运行从被动响应到主动决策。

AgentOS 六层架构：L1 接口与感知层 → L2 认知与决策层（LLM 内核）→ L3 执行与工具层（MCP） → L4 记忆与状态层 → L5 编排与治理层 → L6 基础设施层。

MCP 的定位跃迁：MCP 是标准化”连接器”（AI 时代 USB-C），解决”能做什么”的接入；AgentOS 是系统级”调度与治理平台”，解决”该如何做、与谁协作、安全可控”。MCP 被内化为 AgentOS 的执行层”系统调用”接口——就像 POSIX 系统调用对应用程序的意义。

“用 Token 换架构”的本质：Agent 是用更多的运行时成本（多轮推理 + 多次工具调用 + 更高延迟/Token），换开发与维护成本的下降（分支更少、扩展更快、长尾更适配）。MCP 在这个框架里是”连接成本”的标准化——用少量 Token 换取 N×M 到 N+M 的架构简化。

1. MCP 的”全量加载”vs”按需发现”#

MCP 的核心设计是让 Agent 在调用前就知道所有可用工具（全量加载 Schema），但 Token 成本证明这是不可持续的。替代方案（CLI/Code Mode/Tool Search）走的是”按需发现”路线——Agent 不知道所有工具的细节，但知道怎么去查。

深层矛盾：全量加载让模型有”全局视野”做更好的决策，但 Token 成本太高；按需发现节省成本，但可能遗漏最佳工具选择。这本质上是”信息完备性”和”成本效率”的权衡——Anthropic 的 Tool Search 数据表明，按需发现反而提升了准确率（79.5%→88.1%），暗示”信息过载”比”信息不足”更影响决策质量。

2. MCP 是”USB-C”还是”SOAP”？#

乐观派认为 MCP 是 AI 界的 USB-C——统一标准，一旦普及就不可逆。悲观派认为 MCP 可能重蹈 SOAP 的覆辙——过于复杂，最终被更轻量的 REST 取代（CLI/Code Mode 就是 REST）。

作者的观点：MCP 短期内仍是事实标准，但长期可能退缩为底层传输协议，上层被 Code Mode/SDK 包裹——类比 SOAP 退缩至企业内部，REST 成为互联网主流。关键取决于 Agent 自主能力增长速度：如果 Agent 能自读文档、写代码、处理认证，“工具声明”层就多余了。

3. MCP 的安全问题是”协议问题”还是”实现问题”？#

43% 的命令注入漏洞是”协议设计缺陷”还是”开发者实现不严谨”？答案可能是两者都有：MCP 的”上下文共享”设计哲学天然鼓励宽松权限，而协议本身缺乏强制安全机制（如认证、授权、审计）。昨天学过的 ClawLess 的”形式化验证”思路或许能给 MCP 协议层提供安全补丁。