一个被低估的转型现场
在 QCon London 2026 上，摩根士丹利的两位技术负责人——架构师 Jim Gough 与自助能力团队负责人 Andreea Niculcea——分享了这家投行在智能体时代的 API 转型经验。这类分享通常不如产品发布吸睛，但它回答了一个更基础的问题：当智能体成为 API 的主要消费者，企业内部的接口体系要付出什么代价。
Gough 描述的变化很直观：过去让团队兴奋的是 OpenAPI 规格，现在让业务方兴奋的是 MCP 规格。原因是需求变了——用户希望用自然语言和自己的数据交互，而 AI 智能体是实现这件事的关键。换句话说，API 的调用者从「写代码的工程师」变成了「会说话的智能体」，接口的设计前提随之改变。
需要说明的是，本次分享披露的是经验与方向，缺少可对照的量化指标与同行验证，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
简单性会在规模化时崩塌
分享中一个很诚实的观察是：MCP 带来的简单性，在规模扩大后会失效。具体表现是消歧问题——当多个工具的描述彼此重叠时，智能体会分不清该调用哪一个。这在只有几个工具时不会出现，但当企业内部积累了成百上千个 MCP 服务，描述之间的语义边界就开始模糊，智能体的选择错误率随之上升。
解决方案是引入专门的 MCP 网关。这个判断值得记录，因为它承认了一件事：MCP 作为协议解决的是「怎么连接」，但不解决「怎么在大量相似连接中做对选择」。后者是治理问题，需要独立的组件来承担。这与业界把 MCP 网关、工具注册中心当作新基础设施的趋势是一致的。
CALM：把架构定义成代码
摩根士丹利给出的工程答案是 CALM，即 Common Architecture Language Model，一个开源项目。它的定位是让团队把架构本身定义成代码，为部署提供单一的事实来源。
Niculcea 演示了 CALM 模式如何让开发者快速部署 REST API 与 MCP 服务，并附带合规护栏等安全特性。最有说服力的对比是交付周期：摩根士丹利早年的一个 API 花了数年时间才进入生产环境；在 CALM 与自动化安全审批的支持下，这个过程被压缩到数周。
这个数量级的差异需要谨慎解读。它不意味着所有 API 都能数周上线，而是说明「流程摩擦」曾经是主要瓶颈——当架构定义、安全审批、部署配置都依赖人工协调时，周期会被非技术因素拉长。把架构写成代码，本质上是用可校验的声明替换掉部分人工评审环节。
配套的 CALM Hub 是一个开源可视化工具，提供架构信息的集中来源，支持集中控制与零停机升级。Gough 与 Niculcea 也描述了平台侧的运维工作：跨大规模部署环境管理滚动发布、补丁与安全轮换。这部分内容对企业架构师的价值可能高于协议本身——它说明智能体时代的基础设施挑战，很多时候仍然是传统的发布与运维问题。
一个容易被忽略的技术细节：A2A 与 MCP 并存
Gough 的收尾演示把 Google 的 Agent-to-Agent（A2A）协议与 MCP 并排运行。他的判断是：A2A 未必取代 MCP，真正的关键在于适配层的灵活性。
这个细节解释了两种协议的分工。MCP 标准化的是智能体与工具之间的连接，A2A 标准化的是智能体与智能体之间的通信。两者是互补关系，而不是竞争关系。摩根士丹利的做法是在同一个架构里同时支持，让适配层承担差异。
由此引出一个更宏观的判断：API 仍然是稳定的契约。只要把控制逻辑与流水线编码化，机构就能在交互层不断变化的情况下保持底层稳定——交互层可以从命令行换到自然语言，从 MCP 换到 A2A，而底层的服务定义与治理规则不需要推倒重来。对企业来说，这个「稳定性来自分层」的结论比追逐协议更有长期价值。
文化层面的变化
分享里还有一段关于组织文化的观察值得记录。开发者在使用这套体系时，可能需要牺牲一部分灵活性，换来的是一个可用的生产基线与从一开始就能聚焦业务逻辑的能力；而对控制团队来说，价值在于能看清实际部署了什么。
这两句话点出了企业 AI 落地的真实张力。工程师希望自由，风控希望可见，两者在过去往往对立。把架构声明化、把审批自动化，实质上是给双方提供了一个共同的沟通对象——不是互相说服，而是共同对着同一份可校验的定义工作。
中立思辨
需要辩证看待几件事。其一，「数年缩短到数周」是一个具体的对照案例，但它高度依赖该机构此前流程的基线水平，对流程本就轻量的团队，提升幅度不会这么大。其二，把架构定义为代码会引入新的技能门槛：团队需要理解这套声明语言及其工具链，学习成本是真实存在的。其三，MCP 网关能缓解消歧问题，但也新增了一层组件，网关本身的高可用与权限治理成为新的责任点。其四，金融机构的经验有很强的行业特殊性——强监管、高审计要求、长决策链，这些条件既催生了 CALM 这类方案，也限制了它的通用性。其五，同时支持 MCP 与 A2A 降低了锁定风险，但两套协议的维护成本会叠加，需要评估是否值得。其六，这类转型的成功高度依赖组织配套，而不是工具本身：如果安全审批的人工环节没有同步改造，把架构写成代码也不会自动变快。
趋势研判
短期看，MCP 网关与架构声明化会先在金融、医疗等强合规行业落地，因为这些行业最需要「可审计的连接」；中期看，如果这类实践成熟，企业内部可能出现专门的「智能体接入层」，统一管理工具注册、消歧、权限与审计，成为智能体与企业系统之间的标准中间件；长期看，智能体时代的竞争可能不完全发生在模型层，而是发生在「谁能把自己的服务最规范地暴露给智能体」这一层——接口的规范性会变成一种新的竞争力。
对正在接入智能体的团队来说，一个务实的起点是：先盘点现有接口中有多少是「人能看懂但智能体分不清」的——描述重叠、命名相近、职责交叉。这份清单往往比任何架构决策都更接近问题的核心。