正在加载，请稍候
2026年8月，Agent Plugins 1.0.0 与 MCP 无状态化更新同日指向一个趋势：AI 智能体开发基础设施从各自为战走向工程化收敛。
2026 年 8 月第一周，AI 智能体开发的基础设施层接连传出两个信号——它们指向同一个方向：收敛。
7 月 28 日，MCP（Model Context Protocol）发布了自诞生以来最大的一次规范更新：砍掉初始化握手，废除会话粘滞，每个请求必须独立携带完整上下文。一周后的 8 月 6 日，Google Developers Blog 宣布 Agent Plugins 1.0.0 发布——一个由 Google、Amazon、Microsoft 三方背书的统一插件规范，将 Skills 和 MCP 服务器打包为单一可移植单元。
两件事看似独立，实则指向同一个趋势：智能体开发的基础设施正在从「各自为战」走向「工程化收敛」。正如普林斯顿 6 天实验所揭示的，智能体的真实能力边界更多取决于工程基础设施而非模型本身。对正在评估或已经投入相关建设的企业技术团队来说，这不是「要不要关注」的问题，而是「多快跟上」的问题。
过去两年，企业构建 AI 智能体时面临一个隐性但昂贵的成本：每换一个框架或 IDE，插件都要重新适配。Cursor 的规则文件、Claude Code 的 skills、GitHub Copilot 的斜杠命令——同样的业务逻辑，要在不同平台上用不同格式维护多份。
Agent Plugins 1.0.0 试图终结这种局面。它定义了一个标准化的 plugin.json 清单和固定目录布局，开发者只需维护一份插件代码，即可在支持该规范的所有平台运行。Google 已经作为核心维护者加入，并在其 Agents CLI 和 Data Agent Kit 中提供原生支持。
对企业而言，这意味着两件事：一是「工具链锁定风险」大幅降低——不会因为选错框架而被迫重写所有集成；二是团队可以将更多精力从适配层转向业务逻辑本身。
MCP 最早的设计假设是「本地进程通信」——通过标准输入输出与桌面应用通信。持久连接、握手协商、会话粘滞在本地都不是问题。但当 MCP 服务器大规模部署到云端、需要水平扩展时，这些设计立刻变成了运维噩梦。
一个典型场景：部署三个 MCP 服务器副本，配置会话亲和性，滚动更新时所有客户端会话断开——这不是协议 bug，而是协议设计时就没考虑这种部署模式。这也解释了为什么五成企业的 AI 智能体在上线时即遇到故障——基础设施层面的设计缺陷比模型能力不足更致命。
7 月 28 日的最终版规范做了三件事：移除会话和初始化握手；每个请求通过 _meta 携带协议版本与客户端能力；引入 server/discover 方法按需查询服务器能力。核心原则被维护者称为「按需付费复杂度」——协议核心保持精简，有状态逻辑只在功能真正需要时引入。
对运维团队来说，这意味着远程 MCP 服务器终于可以像普通 HTTP 服务一样部署：轮询负载均衡、无亲和性配置、滚动更新不影响客户端。Mcp-Method 和 Mcp-Name 标头还让网关层可以做操作级速率限制和授权，而不需要解析 JSON 请求体。
但代价同样存在。会话状态被显式句柄（类似购物车的 basket_id 模式）取代——模型需要在 prompt 和对话历史中显式传递这些句柄，它们也会出现在日志中。这意味着安全策略必须跟上：句柄绑定到经过认证的主体，每次使用都要验证权限，绝不能把句柄当作授权凭证。
基础设施收敛的同时，Azure 首席工程师 Kishorekumar Pattabiraman 在 8 月 6 日的架构博文中提出了一个被很多团队忽视的观点：「第一个真正的抉择不是选哪个模型，而是你构建的是技能还是子智能体。」
他给出了四个判断维度，以下是两者的关键差异：
| 判断维度 | 技能（Skill） | 子智能体（Sub-agent） |
|---|---|---|
| 运行模式 | 在持续对话中运行，可读取文件、与用户交互 | 接收单个提示词，独立运行至完成，输出最终结果 |
| 上下文窗口 | 始终携带完整对话上下文 | 每次从干净、无污染的上下文开始 |
| 人工干预 | 过程中可多次介入 | 仅在任务完成后查看结果 |
| 适用频率 | 一次性手工制品、探索性任务 | 可重复的批量工作、需要隔离环境的任务 |
| 复用性 | 可在多个对话流中复用 | 需要独立上下文、权限或不同知识来源时更有意义 |
这个讨论之所以重要，是因为很多企业 AI 项目的失败并非模型不够好，而是架构层面选错了形态（关于最常见的落地误区，我们之前做过系统梳理）。用一个「全能的子单元」去处理需要持续交互的任务，或者用一个「巨型技能」去跑需要隔离的批处理，结果都是 prompt 膨胀、行为不稳定、排查困难。
我们在实际交付中也踩过这个坑：一个零售客户的客服系统最初用单个子智能体处理从意图识别到订单查询的全流程，prompt 长度很快就膨胀到 3000+ token，触发频率和准确率双双下降。拆分为一个路由技能 + 三个专项子单元后，单次调用延迟从 4.2 秒降到 1.7 秒，意图识别准确率从 76% 提升到 91%。
Agent Plugins 1.0.0 和 MCP 无状态规范都是 1.0，意味着它们已经足够「可用」但还会迭代。现在开始按规范设计内部插件和 MCP 服务器，比一年后追标准更省成本。Google、Amazon、Microsoft 三方背书意味着这些规范不会在短期内被推翻——它们已经是事实上的行业基线。
每个新功能在开工前，先走一遍四维判断：它是交互式还是独立运行？人工需要参与几次？多久执行一次？这三个问题回答清楚，架构方向就不会偏太多。如果你正在评估如何搭建生产级平台，腾讯 ADP 4.0 的 AgentOps 全生命周期管理是一个值得参考的实践案例。
如果你已经在用 MCP，检查现有实现中哪些依赖了会话粘滞，开始规划迁移路径。如果你还没用 MCP，从第一天就按无状态模式设计——这已经是官方推荐的生产级范式。缓存方面，关注 ttlMs 和 cacheScope：前者是新鲜度提示而非强保证，后者决定了缓存可以在哪些范围内共享。
问：Agent Plugins 1.0.0 和 MCP 是什么关系？
答：前者是一个打包规范，将 Skills 和 MCP 服务器统一为一个可移植单元。MCP 是通信协议，Plugins 是基于该协议的上层分发标准。两者互补而非竞争。
问：MCP 无状态化后，需要会话状态的场景怎么办？
答：用显式句柄模式。工具返回一个唯一标识（如 task_id），模型在后续调用中将其作为普通参数传递。这和 REST API 中的资源 ID 模式一致。关键安全约束：句柄必须绑定到经过认证的主体，每次使用验证权限，不要把句柄当作授权凭证。
问：小团队现在跟进这些标准会不会太早？
答：不会。Plugins 有 Google/Amazon/Microsoft 三方背书，MCP 无状态化是 Anthropic 主导的官方方向。现在跟进是「提前适配」，一年后跟进就是「技术债追缴」。而且无状态 MCP 服务器的部署成本更低——轮询负载均衡，无需会话亲和性配置，这对小团队反而是利好。
问：技能和子智能体能否混合使用？
答：可以，而且这是推荐做法。Pattabiraman 指出，两种模型可以无缝组合——技能可以构建在子单元之上。当问题需要时，这种分层方法代表了最成熟的设计。实际项目中常见模式：一个交互式技能负责路由和上下文管理，多个子单元并行执行专项任务。
这些基础设施的收敛，对已经在相关方向投入的企业团队是明确利好——选型风险降低、运维成本下降、人才技能的可迁移性提升。蓝曜炬辉（www.lanyaoai.com）在多个企业 AI 项目中已经按 MCP 协议设计和部署了生产级服务，如果你正在做技术选型或架构评审，欢迎到官网查看案例或直接联系技术团队讨论。