从"聊天窗口"到"任务管道"
这周Google I/O 2026上，Gemini Spark宣布将在几周内支持MCP（Model Context Protocol）以连接第三方应用，包括Canva、Instacart、OpenTable等。 几乎同时，Anthropic的Claude Managed Agents也基于MCP tunnels和自托管沙盒上线。两个巨头在同一个协议上押注，这不再是巧合。2026年的技术主线已经很清晰：基座模型的能力边际在递减，真正的战场转移到了编排层（Orchestration）——也就是如何让多个Agent像管道一样协作，而不是像孤岛一样各自为政。
MCP到底是什么？为什么它比Function Call更重要
如果你之前用过OpenAI的Function Calling，你会熟悉这个流程：模型判断需要调用某个工具 → 输出JSON参数 → 你的代码执行 → 结果塞回上下文 → 模型继续推理。MCP把这个模式往前推了一步：它标准化了Agent与外部世界之间的接口协议。Function Call解决的是"模型怎么调用我的代码"，MCP解决的是"不同的Agent、不同的服务、不同的沙盒之间怎么互相发现和调用"。
Google这次发布的Managed Agents API，核心就是一次API调用即可拉起一个带持久状态的完整Agent，而这个Agent通过MCP与Canva的Magic Layers、Adobe的Firefly等外部服务通信。
个人实验：我搭的一个极简MCP-like工作流
在我自己的项目里，我尝试用类似MCP的思路搭了一个三节点工作流，虽然没用官方SDK，但逻辑是相通的：复制
用户输入任务
↓
[Router Agent] —— 基于意图分类，输出结构化指令
↓
[Worker Agent A] —— 负责数据获取（搜索/数据库查询）
↓
[Worker Agent B] —— 负责内容生成（基于A的JSON输出）
↓
[Validator Agent] —— 检查格式与事实一致性
↓
输出关键设计点：
- 中间态全部用JSON Schema：Worker A输出Markdown表格，Worker B解析失败的情况我踩过太多次。
- 状态持久化：每个Worker的执行结果写入共享存储（类似MCP的context server），而不是塞在对话历史里。这避免了上下文爆炸。
- 失败回退：Validator如果检测到事实错误，不是让B重写，而是把任务踢回给A重新检索——这和MCP的"工具重试"语义一致。
对开发者的实际意义
- ** vendor lock-in在降低**：MCP是Anthropic发起、Google采纳的开放标准。这意味着你的Agent工具集可以在Claude和Gemini之间迁移，而不必重写调用层。
- 本地优先成为可能：Claude推出自托管沙盒（self-hosted sandboxes），配合MCP tunnels，意味着你可以在本地跑Agent，让它安全地操作你的文件系统、数据库，而不必把数据送到云端。
- 创意工作流的重构：Canva的Magic Layers集成是个很好的例子——在Gemini里生成图片，直接解锁到Canva的可编辑分层文件。这对个人创作者来说，意味着"生成"和"精修"之间的摩擦被大幅降低了。
结语
2026年不是"更大的模型"之年，而是"更聪明的管道"之年。MCP协议的出现，让我想起了当年HTTP标准化Web服务的过程——在协议统一之前，每个网站都是孤岛；在MCP普及之后，每个Agent或许都能成为可插拔的模块。如果你正在做Agent相关的开发，我的建议是：别只盯着Prompt Engineering了，开始设计你的工具接口和状态流转。因为接下来的竞争，不在模型能回答什么，而在模型能编排什么。