行业终于不再忽视这个问题
在生产法学硕士周期的前两年，每个基础模型提供商都采用了自己不兼容的方式将模型连接到工具中。每个供应商都有自己的函数调用格式、自己的工具使用模式、自己的 SDK 约定，以及自己关于状态、重试和流式处理如何工作的微妙假设。云平台以略有不同的方式对这些原语进行分层。结果是可以预见的：企业团队最终将代理框架通过定制适配器粘合在一起，并且每次模型迁移都意味着重写有意义的应用程序代码。
那个时代正在结束。一小组开放协议和新兴的运行时约定已经汇聚到一个共同的思维模型上：模型通过定义明确的、与传输无关的协议与工具进行对话；工具可以存在于任何地方；并且运行时的互换性越来越强。整个生态系统中的规范尚未完全相同，但它们可以以重要的方式进行互操作，并且社区工具将它们视为堆栈中的补充层，而不是竞争性的替代层。
接下来的框架详细介绍了模型上下文协议的实际含义以及它为何成为汇聚点、现代代理运行时 API 在其上添加的内容、代理到代理协议适合的地方、企业团队应致力于的架构移动、区分可防御部署与易受攻击部署的安全模型、2026 年为代理架构添加的监管维度，以及在面向客户的部署之前构建肌肉记忆的 90 天试点计划。
模型上下文协议实际上是什么
模型上下文协议 (MCP) 于 2024 年末作为开放规范发布，此后已成为法学硕士如何使用工具和数据的事实上的汇聚点。该协议定义了 LLM 可以与之交互的三个原语：工具（模型可以调用的操作）、资源（模型可以读取的结构化数据）和提示（可重用模板）。通信在支持 stdio、HTTP 和服务器发送事件的 JSON-RPC 传输层上运行。
结构上重要的设计选择是 MCP 服务器独立于模型。公开 Jira 工具、PostgreSQL 资源、Slack 工作流程或自定义内部 API 的服务器可以连接到任何使用该协议的 LLM 客户端。到 2026 年第一季度，公共 MCP 注册表列出了数百台服务器，涵盖数据库、文件系统、SaaS API、可观察性工具、版本控制系统、票务平台和内部企业系统。架构的结果是：工具表面成为一种便携式资产，而不是特定于模型的集成。
该协议是开放的并且由社区维护。多个商业AI供应商和开源项目已经提供了一流的MCP支持；该规范本身位于 modelcontextprotocol.io 并独立于任何单一供应商进行管理。对于企业团队来说，这是关键属性：针对 MCP 而不是针对任何单一供应商的函数调用格式编写工具意味着这些工具无需重写即可在下一次模型迁移中生存。
现代代理运行时 API 添加了什么
在工具协议层之上，现代代理运行时 API 处理多轮工具循环、内置功能（网络搜索、文件搜索、计算机使用、代码执行）、跨模型调用的推理状态连续性、流式传输和可观察性等更高级别的问题。这些运行时 API 比 2023 年至 2024 年为处理相同问题而编写的应用程序代码团队要精简得多。
封装这些运行时 API 的代理 SDK 提供了额外的结构：护栏、专用代理之间的切换逻辑、跟踪、评估原语以及生产部署的框架约定。竞争格局中有多个供应商和开源项目在这一层展开竞争，但底层 API 正在汇聚成一个可识别的形状——工具循环编排、结构化输出、流媒体、可观察性钩子——跨实现的可移植性越来越强。
对于企业团队来说，实际指导是将运行时视为可替换层。选择适合当前堆栈和团队熟悉程度的运行时；将业务逻辑集中在其下面的MCP服务器中；期望在 24 个月的部署窗口内至少迁移一次运行时，并为该迁移设计架构。
代理到代理协议和两层图
MCP 标准化了单个模型如何到达工具，而新兴的代理到代理 (A2A) 协议族则标准化了代理如何跨组织边界访问其他代理：能力发现、任务委派、结果流、身份验证和信任建立。该设计明确假设未来企业将发布专门的代理（采购、调度、研究、数据提取），其他代理无需定制集成即可调用。
将这些规范视为堆栈而不是竞争对手，可以澄清架构图。 MCP 是工具访问层（多个工具的单一代理）。 A2A 是代理间层（一个代理到其他代理）。运行时 API 位于顶部并协调两者。 2026 年，大多数企业对话不再是“我们应该选择哪个代理框架？”。它们是“我们致力于将这个堆栈的哪些部分作为持久架构，以及我们保持可插入性？”。
对于 2026 年初的大多数企业计划，答案是：在工具访问层致力于 MCP（标准成熟且迁移成本较低），保持运行时可插拔（该层仍在搅动），在组织扩展实际适用的跨团队工作流程中试点 A2A，并将整个堆栈视为摆脱供应商锁定的重构机会，而不是更努力地向特定供应商做出承诺。
企业团队应该围绕什么构建
2026 年企业人工智能团队的架构指南假设协议层稳定，而运行时层不稳定。这种不对称性转化为一些具体的建筑动作：
- 将工具构建为 MCP 服务器，而不是特定于框架的插件。即使团队今天致力于单一基础模型提供商，针对 MCP 编写工具也会为下一次迁移购买可移植性 - 根据我们的经验，在大多数生产部署中迁移会在 18 个月内发生。
- 保持代理运行时精简且可显式替换。无论团队使用商业代理 SDK 还是内部包装器，都期望在 24 个月内更换运行时。将业务逻辑集中在MCP服务器和共享库中；将运行时视为脚手架而不是承载架构。
- 将工具目录视为 API 表面。对它进行版本控制、记录它、测试它、限制它的速率、审核它。工具目录是代理架构的持久资产——底层模型不是，运行时也不是。
- 将提示和指令层与工具层分开。当团队交换模型或运行时时，提示几乎总是需要调整；工具定义不应该。这种分离使得模型交换增量而不是单一的。
- 对于多团队部署，即使团队保留 MCP 供同一团队工具使用，也可以针对跨团队工作流程试点 A2A 或等效的代理间协议。跨团队形状（能力发现、身份验证、委派）是架构上的难点，A2A 抽象已成为合理的默认锚点。
- 对源代码管理中的每个工具、每个提示、每个模型选择以及每个代理拓扑决策进行版本控制。代理架构的发展速度足够快，以至于审计跟踪成为区分可防御生产系统和无人能在一年内推理的系统的人工制品。
安全性是大多数代理部署出错的地方
MCP 服务器是代码。具体来说，LLM 可以使用从（可能是对抗性的）用户输入派生的参数来调用它的代码。安全模型必须考虑幼稚部署通常会忽略的三种故障模式：
- 提示注入到达特权工具。用户提示（或用户提供的文档）旨在强制模型调用不应调用的工具，或使用攻击者控制的参数来调用它。执行写入或删除操作的特权工具需要明确的确认，而不仅仅是置信阈值路由。
- 工具权限范围过大。可以修改任何记录的“更新”工具是避免数据完整性事件的单提示注入。将写入功能分解为范围狭窄的、单独确认的工具，而不是将它们滚动到通用突变操作中。
- 来自社区 MCP 服务器的供应链风险。将社区 MCP 服务器投入生产会带来任何其他开源依赖项的所有供应链风险，以及服务器是主动 LLM 调用的攻击面的额外风险。将批准的服务器列入白名单、签署版本、审核代码并固定到特定版本。
生产代理部署的基线安全控制
实际控制应该是操作基线而不是可选的附加组件：
- 使用最低权限凭据在沙盒环境中运行 MCP 服务器。服务器只能访问其特定功能所需的内容，而不能访问更广泛的企业环境。
- 将每个写入、删除或外部影响操作视为单独的、明确确认的工具。通用“更新”或“执行”工具是 OWASP LLM Top 10 特别标记的过度代理设计模式。
- 维护已批准的 MCP 服务器的许可名单，其中包含已签名和固定的版本。按发布节奏审核允许名单的更改。
- 使用模型输入、解析的参数、结果以及触发代理调用的用户身份记录每个工具调用。审计追踪是监管证据和事后调查的基础。
- 每个用户每个工具的速率限制。环路检测和失控成本保护都取决于速率限制层的到位。
- 在工具输出重新进入模型上下文之前验证工具输出。对抗性工具输出（中毒的数据库行、被操纵的搜索结果）是绕过提示输入验证的二阶注入向量。
- 对于受监管的工作负载，请确保代理操作日志与模型评估和数据集文档一起成为监管证据管道的一部分。
2024-2026 年新增的监管维度
代理架构已通过多个已于 2024 年至 2026 年生效或成熟的框架进入监管范围。
- 欧盟人工智能法案将高风险应用中使用的代理系统视为受第 9-15 条有关风险管理、数据治理、技术文档、透明度、评估和人工监督要求的约束。每个工具的审计跟踪和评估套件都是监管证据。
- NIST 人工智能风险管理框架明确解决了代理系统的问题，包括工具使用、多步骤操作和自主决策的额外风险。该框架是面向美国的项目的事实上的参考。
- OWASP LLM Top 10（2025 版）对生产部署需要针对的特定于代理的漏洞（过多的代理、通过工具链接的提示注入、工具插件中的供应链风险）进行了编纂。
- 亚太地区的个人数据保护制度（新加坡 PDPA、泰国 PDPA、越南第 13 号法令、韩国 PIPA）均针对自动化决策制定了具体规定，适用于代理对个人数据采取行动（特别是写入操作）时。
未来 90 天内试点什么
对于尚未致力于标准化代理架构的企业团队，我们在 2026 年推荐的 90 天计划是小而具体的，旨在在面临客户压力到来之前建立团队肌肉记忆：
- 第 1-30 天：建立一个内部 MCP 服务器，公开一个高价值但低风险的工具——通常是内部知识源、票务系统或结构化数据查询的只读包装器。从单个代理运行时端到端驱动它，包括基本评估和跟踪。
- 第 31-60 天：将相同的工具移植到第二个运行时，以证明堆栈的可移植性是真实的。重点不在于可移植性本身，而在于可移植性。它是团队围绕工具版本控制、跟踪分析以及跨运行时回归集进行评估的肌肉记忆。
- 第 61-90 天：在显式确认安全模式下添加具有写入功能的第二个工具，以及对代理的工具选择和轨迹质量进行评分的评估工具。写功能工作是安全模型变得具体的地方。
常见问题
致力于 MCP + 代理运行时 + A2A 堆栈的企业架构师提出的常见问题：
- MCP 是否真正与供应商无关，还是与特定供应商相关？具有多供应商实施的开放规范。多个商业人工智能提供商和开源项目支持它是一流的；该规范的管理独立于任何单一供应商。在架构决策中将其视为供应商中立是有道理的。
- 我应该使用 AI 提供商的官方代理 SDK 还是开源框架？两者都是可行的。该决策与框架选择无关，而更多是将框架视为架构中的可替换层。选择适合团队熟悉程度的内容；不要过度向其提交业务逻辑。
- 如何处理生产中 MCP 服务器的身份验证？用于人工启动代理的 OAuth 风格流程；自动化代理的服务帐户凭证；明确的每个工具范围，因此受感染的服务器无法升级。身份验证模型是架构的一部分，而不是事后的想法。
- 我什么时候应该采用 A2A 或类似的代理间协议？当组织有多个团队拥有代理并且代理需要跨团队边界进行交互时。对于单团队部署，工具层的 MCP 通常就足够了，而 A2A 则过于复杂。
- 到 2026 年，这个领域的发展速度有多快？协议层（MCP）正在稳定。运行时层仍然每季度更新一次。 A2A 层处于早期阶段，值得关注，但尚未承担大多数部署的负载。围绕不对称性进行架构设计（遵守协议，保持运行时可插入）是持久的策略。
