制缰者的困境

把时钟拨回2025年11月。古晋的立法议会大厅里，砂拉越总理正在宣读一份工程进度报告。蓝线——古晋城市交通系统的第一、第二配套工程——已进入全面施工阶段。从冷布斯总站到实都东Northbank路段的铁轨铺设按计划推进，试运营预计在2026年第四季度启动。这是一条物理轨道，它的规格、轨距、信号系统都在图纸上被精确标定。施工方按图作业，偏差以毫米计。

八千英里之外，另一场关于“轨道”的战争正在进入白热化。这场战争的标的物没有物理形态，没有标准图纸，甚至没有公认的度量单位。它的战场分布在GitHub的issue列表、开发者大会的圆桌讨论、以及各大云厂商的合作伙伴闭门会议上。参与方争夺的东西比铁轨更抽象，却也更具战略价值：智能体调用工具的接口标准——缰绳层最底层的协议定义权。

当缰绳层从技术工具演进为生态基础设施时，一场关于控制权的隐性战争在2025年全面爆发。这不是偶然。每当一个技术层积累足够厚度的价值，定义它的权力就从工程问题变成政治经济问题。

浏览器标准战争、USB与FireWire之争、蓝牙协议栈的博弈——每一代平台生态都经历过类似的时刻。智能体缰绳层在2025年抵达了它的临界点。这场战争的导火索是MCP（Model Context Protocol，模型上下文协议）的发布。

2024年11月25日，Anthropic公开了这套协议。在此之前，每一个想给智能体装上“手”的开发者，都不得不自己处理工具描述语言、调用格式、状态管理、错误处理和安全校验。MCP提供了一个统一的接口规范：工具提供方按协议暴露服务，模型通过标准化的请求-响应格式调用它们。一端是模型，一端是工具，协议定义了针脚排列和信号时序。

在最初的几个月里，MCP被广泛视为一项解决工程痛点的技术福音。Claude模型原生支持MCP，开发者社区迅速涌现出数百个MCP服务器的开源实现——从GitHub API到邮件客户端，从数据库查询到浏览器自动化。

到2025年春季，MCP已经成为Claude生态中占据主导地位的工具调用协议，并且开始向其他模型厂的外围辐射：一些第三方模型为了接入已经在MCP协议下构建的工具生态，也开始提供兼容层。

但问题恰恰出在“占据主导地位”这个事实上。MCP的治理结构从一开始就引起了一些参与者的不安。协议由Anthropic主导设计，虽然以开放标准的形式发布，但核心规范的演进方向、安全模型的设定、以及围绕协议构建的开发者工具链，都深度绑定在Anthropic的技术栈和商业利益上。一家依赖MCP构建其智能体编排平台的企业，实际上是在为Anthropic的生态贡献工具和用户，而自己对协议演进的投票权却微乎其微。

这种焦虑在2025年春季具体化为一次非公开的行业会议。三家头部SaaS公司——其核心业务分别覆盖客户关系管理、人力资源自动化和供应链优化——与两家全球云服务商的代表在一次闭门晚宴上达成了一项共识：必须创建一个能与MCP竞争的、更“开放”的替代协议。

这三家SaaS公司并非小角色。它们的市值总和超过两千亿美元，旗下的代理编排平台各自管理着数以万计的智能体实例，每天执行的工具调用量以亿计。它们拒绝将自己的平台绑定在单一模型厂商的协议栈上，不是出于技术偏好，而是出于对结构性从属地位的战略恐惧。而那两家云厂商则有自己的算盘：它们希望成为所有智能体流量的中立通道，而不是被迫在Anthropic生态和其竞争对手之间选边站队。

2025年6月，这个联盟正式公开了其提案：泛在代理接入协议（Universal Agent Access Protocol，UAAP）。草案的发布选择在旧金山的一家酒店会议厅，而不是任何科技巨头的开发者大会。这个选择本身传递了一种姿态——UAAP是一场行业联盟的集体行动，不是一个厂商的生态发布会。UAAP的核心论点简洁而有力：智能体调用工具的接口应当像HTTP一样，是无状态、无厂商偏好、无特定模型绑定的中立层。

协议草案提出了一个基于RESTful风格的调用模型，工具按照URI模式注册，请求和响应使用JSON格式，认证采用OAuth 2.0的扩展。它强制要求所有实现方支持多模型后端——一个UAAP兼容的工具服务器，必须能够同时为Claude、GPT、Gemini以及任何其他大模型提供服务，而不得在协议层对模型厂商进行差异化。

UAAP的治理结构也刻意与MCP形成对比。它提出了一个由发起企业和后续加入的社区成员共同组成的委员会架构：三分之一席位留给应用厂商，三分之一留给云平台和基础设施提供商，三分之一留给独立开发者社区代表。模型厂商在委员会中没有常设席位。这个设计明确传递了一个信息：UAAP的治理权属于应用层和基础设施层，不属于模型层。

UAAP联盟的一位发起人在发布会上表达了这一立场。他的核心论点是：智能体的接口标准不应该由模型厂商单方面定义，就像HTTP不应该由服务器厂商来定义一样。

这个类比听起来有理有据，但仔细推敲，它暴露了一个深刻的概念混淆。HTTP的标准化组织IETF确实不是服务器厂商控制的，但HTTP的标准化过程发生在Web已经是一个多厂商、多实现、充分竞争的生态之后。而智能体工具调用协议在2025年仍然处于市场形成的早期阶段，唯一的完整实现就是MCP。UAAP的诉求不是在一个成熟生态中引入竞争，而是在起飞阶段更换引擎。

Anthropic对UAAP的回应来得很快，而且直指要害。2025年7月，Anthropic的开发者关系团队发布了一篇技术博客。博文的核心论点凝结在一句话里：没有强约束的协议就不是协议，而是互操作性的幻觉。

这句话值得拆开来看。Anthropic的论证是：智能体工具调用不是简单的请求-响应，而是一个涉及状态管理、安全上下文、工具选择权重的复杂过程。

一个真正能够保证多模型兼容的协议，要么必须对模型的行为施加严格约束——比如规定工具返回结果的格式、定义模型在工具调用失败时的回退策略、设定安全校验的强制步骤——要么就必须接受“兼容”只是表面上的：不同模型在同一个工具上表现截然不同，协议层并没有真正解决互操作性，只是把复杂性推给了应用开发者。

Anthropic的工程师们指出了一个具体的技术争议点：工具调用上下文的归属。在MCP的设计中，一个工具调用的上下文——包括调用历史、中间结果、权限状态——被绑定在会话级别，由MCP服务器管理。这意味着当模型发起一个新的工具调用时，服务器可以基于完整的上下文进行安全校验和状态验证。而UAAP的初始草案将工具调用定义为无状态操作：每个请求自包含所有必要信息，服务器不保留跨调用的会话状态。

UAAP的设计者认为，无状态是HTTP成功的核心原则，它降低了服务器的复杂度，增加了扩展性。

但Anthropic的反驳是：智能体工具调用不是获取网页，而是一个多步骤的、有因果依赖的、需要安全边界的操作序列。一个智能体如果先查询了用户的日历，然后基于结果发起了会议邀请，最后又试图修改与会者名单——这三个步骤之间存在安全上下文的传递：第一步的结果决定了第二步的权限是否合理，第二步的执行又影响了第三步的授权范围。如果协议层是无状态的，这个安全上下文就必须由应用层自己维护，而应用层恰恰是最容易出安全漏洞的地方。

Anthropic的技术博客进一步指出，UAAP的安全责任被推给了最没有能力处理安全的那个层级——应用开发者。它的无状态设计在纸面上很美，但在第一起提示注入导致跨步骤权限泄露的事故之后，每一个应用开发者都将被迫重新发明MCP已经内置的状态管理机制。

这场技术辩论在2025年秋季的多个开发者大会上公开上演。最引人注目的一次交锋发生在9月的SaaS开发者大会上。

大会组织者专门安排了一场关于智能体协议标准之争的圆桌讨论，邀请了UAAP联盟的技术负责人与Anthropic的API平台总监同台。这场讨论的录像在会后被广泛传播。

UAAP方的代表是一位资深分布式系统架构师，曾在两家发起公司担任过首席技术官。他的发言集中在治理结构上。他表达的核心观点是：UAAP联盟不是在质疑MCP的技术质量，而是在质疑一个由单一模型厂商控制的标准，是否应该成为整个行业的基础设施。他援引了浏览器战争的历史教训——如果微软一直控制着IE的渲染引擎标准，Web就不会是今天的样子。标准需要多元治理，这是产业史的教训。

Anthropic的代表没有直接回应治理问题。他选择了一个不同的角度。他请在场的开发者回忆USB标准是怎么赢的。USB不是由一个多元治理委员会设计的。它是由英特尔主导，联合了微软、康柏等少数几家，提供了完整的参考实现和芯片组，让硬件厂商可以零成本接入。

USB的成功不是因为它的技术比FireWire好——实际上FireWire在很多指标上更优秀——而是因为它提供了一条从规范到实现到产品的完整路径，而且这条路径上有明确的、有动力去推动它的人。标准战争不是靠委员会投票赢的，是靠形成既成事实赢的。这个回答绕开了UAAP的治理论点，却把问题推向了一个更根本的方向：协议政治的胜利者不一定是技术上的最优解，而是那个能通过治理结构、开发者关系和集成深度将标准锁定为既成事实的一方。

UAAP的瓦解不是一蹴而就的，但它的失败轨迹在2025年秋季已经清晰可见。问题出在三个层面。

第一个层面是技术分歧。UAAP联盟内部在安全与状态管理规范上始终无法达成一致。那三家SaaS公司在各自的产品中已经实现了不同版本的状态管理机制——有的用数据库持久化会话，有的用缓存层，有的依赖客户端维护上下文。当UAAP工作组试图将状态管理写入协议规范时，每一家公司都希望标准符合自己已有的实现，而不是反过来。

三家SaaS公司提出了三种不同的状态管理方案，两家云厂商则主张将状态管理完全排除在协议之外，交给更高层的框架处理——这恰恰是Anthropic已经预见到的陷阱。到2025年10月，UAAP的安全规范部分仍然停留在草案的早期版本，而MCP已经提供了完整的沙箱权限模型和审计日志标准。

第二个层面是推动力缺失。MCP的推进速度得益于Anthropic的全栈集成：Claude原生支持，开发者工具链免费提供，MCP服务器生态有明确的激励——那些开发了流行MCP服务器的开发者，可以优先获得Claude的API配额和商务合作机会。

UAAP没有一个对标的推动者。那五家发起企业各自有自己的主营业务，协议标准化不是它们任何一家的核心战略，而是防御性的联盟行动。防御性联盟的典型弱点在这里暴露无遗：没有人愿意为推进协议投入足够的资源，因为协议成功的收益是公共的，但投入的成本是私人的。

当UAAP的开发者文档在GitHub上停滞了三个月没有更新时，社区已经开始流失。第三个层面，也是最致命的层面，是市场不需要两个标准。到2025年秋季，MCP已经积累了足够多的工具服务器和开发者惯性。主要的代码托管平台、数据库厂商、API服务商都已经发布了官方的MCP服务器实现。开发者如果选择UAAP，意味着他们需要放弃已经集成好的工具生态，同时等待UAAP自己的生态从零开始构建——而UAAP的生态构建速度，被其联盟内部的协调成本拖累得举步维艰。

2025年11月，就在古晋立法议会宣布蓝线全面施工的同一周，UAAP的GitHub仓库在经历了两个月的低活跃度之后，悄然将状态标记从活跃开发改为维护模式。联盟没有正式宣布解散，但开发者社区已经读懂了信号。Hacker News上的一条评论获得了大量赞同：UAAP的失败证明了一个委员会不能设计协议，但业界早已知道这一点。

UAAP的失败方式恰恰验证了一个更深层的判断：协议政治的胜利者不一定是技术上的最优解，而是那个能通过治理结构、开发者关系和集成深度将标准锁定为既成事实的一方。Anthropic在MCP上投入了充分的集成资源，提供了完整的参考实现，确保了开发者从读到规范到跑通第一个工具调用的时间不超过十五分钟。UAAP提供了一个更公平的治理结构，但公平不等于效率，效率往往才是标准竞争的决定性变量。但这场短暂的协议战争也留下了一个重要的遗产。它迫使Anthropic在MCP的治理上做出了让步。2025年12月，Anthropic宣布成立MCP的独立技术指导委员会，引入了两家第三方云厂商和一家独立研究机构的代表，模型的治理投票权从绝对多数调整为相对多数。这个调整不足以让MCP变成UAAP式的中立标准，但足以削弱单一厂商控制的批评火力。UAAP死了，但它的幽灵活在了MCP的治理改革中。

对于那三家发起UAAP的SaaS公司而言，协议战争的失败带来了一个艰难的选择。它们必须面对一个现实：不接入MCP，就意味着放弃一个快速增长的工具生态；接入MCP，就意味着接受在一个由Anthropic主导的协议栈上构建自己的业务。这个选择没有好的答案，只有代价的权衡。其中一家公司的CTO在2025年11月末的一次内部技术评审会上，给出了一个冷静的计算。这家公司的人力资源自动化平台的智能体每天执行大约三百万次工具调用，涉及员工数据查询、排班调整、薪资计算和合规审查。如果继续自行维护多个模型专用接口，工程师团队需要为每一个模型厂商适配不同的工具调用格式、管理不同的安全上下文、处理不同的错误恢复逻辑。维护成本大约占平台工程资源的百分之十五。

如果切换到MCP统一接口，维护成本可以降到百分之五，但代价是：所有工具调用的元数据——调用频率、工具类型、失败模式——都将在MCP协议层被记录，而这些元数据对于Anthropic优化其模型和工具推荐算法具有战略价值。这位CTO在评审会上指出，公司实际上是在用调用数据为Anthropic训练竞争对手。记录只到这一步。他没有当场给出决定。评审会结束时，他要求团队在两个选项上同时准备技术方案：一个是全面接入MCP，另一个是构建一个内部的协议抽象层，在MCP之外保持对多个模型后端的直接支持。这个抽象层本质上就是一个小型的UAAP——只是它不对外公开，不追求成为标准，只服务于一家公司的生存需求。这个选择本身就是一个微型的历史判决。UAAP作为联盟失败了，但UAAP试图解决的问题并没有消失。应用层对模型层结构性权力的焦虑，不会因为一次协议战争的结束而消散。

它只是从公开的战场退回到了各家公司内部的技术选型中，变成了一个持续的、沉默的、没有标准答案的权衡。协议战争的终局是MCP的胜利，但这个胜利的代价正在由整个生态的演化速度来支付。当缰绳层的底层协议被单一厂商锁定，上层创新的方向就不可避免地受到协议演进方向的引导。那些与MCP设计哲学不符的智能体架构——比如完全去中心化的代理协作、基于发布-订阅模式的工具发现、或者跨模型联合推理——在协议层得不到支持，在应用层就难以生长。标准的锁定效应从来不只是技术问题，它是生态多样性的隐性税收。到2025年底，这个判断在开发者社区中开始形成共识，尽管表达方式各不相同。一位开源智能体框架的维护者在Hacker News上写道：MCP赢了，不是因为它是最好的协议，而是因为它是唯一一个提供了完整路径的协议。开发者接受它，就像接受JavaScript的怪癖一样——不是因为喜欢，而是因为它在所有地方都能跑。标准战争从不奖励纯洁，只奖励先到。

2025年秋季的那场SaaS开发者大会，圆桌讨论被安排在下午四点——通常是与会者精神最涣散的时段。但这场讨论的座位在开场前二十分钟就已经坐满，后排站了三层人。UAAP方的技术负责人在开场陈述中做了一个精心设计的类比。他把MCP比作一条私人修建的高速公路：路面平整，标识清晰，但收费站的位置、收费标准、以及哪些车辆可以通行，都由筑路者单方面决定。UAAP的愿景，则是把这条路变成公共道路——由使用道路的人共同制定交通规则。这个类比在会场上赢得了掌声，但它也暴露了UAAP论证中的一个结构性弱点：公共道路的比喻预设了一个已经存在的、有共同利益的社区，而UAAP试图在创建标准的同时创建这个社区。这两件事的顺序是致命的。标准可以催生社区，但社区不能凭空设计标准——标准需要在一个具体的、可运行的、有反馈循环的生态中演化出来。

Anthropic的API平台总监在回应时抓住了这一点。他没有用比喻，而是直接展示了一组数据：截至2025年9月，MCP的公开工具服务器数量已经超过一千二百个，覆盖了从云服务API到企业内部系统的广泛工具类别。这些服务器不是Anthropic开发的——其中百分之八十来自第三方开发者。他们选择MCP，不是因为治理结构的承诺，而是因为MCP提供了从规范文档到SDK到测试沙箱的完整路径。这位总监的表达很克制，但意思很清楚：UAAP在讨论如何修路的时候，MCP的路上已经有车在跑了。开发者不会等待一个委员会达成共识，他们会选择现在就能用的东西。这是标准战争中最残酷的法则：时间不是中立的裁判，时间是先发者的盟友。

UAAP联盟内部的分歧在大会之后加速公开化。争议的焦点最终集中在状态管理的实现规范上，但分歧的根源比技术更深。那三家SaaS公司中的一家——客户关系管理平台的开发商——在其产品中实现了一套基于数据库持久化的会话管理机制。当一个智能体在CRM系统中执行一系列操作时，每一步的上下文都被写入一个事务日志，后续步骤的权限校验依赖于这个日志的完整性。这套机制已经在生产环境中运行了两年，经过了数十亿次调用的验证。当UAAP工作组提出将状态管理标准化时，这家公司自然希望标准采纳其已验证的方案。但另一家发起公司——人力资源自动化平台——采用了完全不同的架构。它的状态管理依赖客户端维护上下文，服务器端保持无状态，理由是人力资源数据涉及更严格的合规要求，将状态持久化在服务器端会增加数据泄露的暴露面。第三家公司则主张折中方案：协议层只定义状态传递的格式，不规定状态的存储位置和管理方式。

这三家公司的技术分歧并非不可调和，但调和需要时间，而时间恰恰是UAAP最缺乏的资源。更关键的是，这个分歧揭示了一个UAAP联盟从未公开讨论的问题：这三家SaaS公司之所以对状态管理有截然不同的需求，是因为它们的业务场景对安全、合规和性能的权重排序完全不同。一个统一的协议必须在这些权重之间做出选择，而每一个选择都会让某些成员的利益受损。MCP避开了这个问题，因为它的设计者不需要在相互竞争的应用厂商之间寻求妥协——Anthropic根据自己的技术判断和安全哲学做出了选择，市场可以选择接受或不接受。UAAP的委员会结构本应更民主，但民主在标准设计的早期阶段往往意味着决策瘫痪。

到2025年10月中旬，UAAP的安全规范工作组已经召开了七次会议，仍然没有就工具调用上下文的归属达成一致。

这个评论下面有人回复：问题不在于先到，而在于先到者可以在后来者面前设置一个接一个的既成事实。每一个新集成的工具、每一个新发布的MCP服务器、每一个围绕MCP构建的开发者教程，都在提高后来者的进入门槛。这不是技术竞争，这是事实堆叠。2026年1月，一家中型SaaS公司的CTO坐在办公桌前，桌面摊着两份技术方案文档。左边是MCP全面接入方案，预估切换周期六周，之后维护成本降低十个点。右边是自建协议抽象层方案，预估开发周期四个月，之后维护成本降低五个点，但保留了多模型后端的选择权。他盯着两个数字反复计算，不是在计算成本，而是在计算权力——将自己的平台绑定在MCP上，意味着把未来五年的技术路线图的一部分决策权，无偿让渡给Anthropic的协议迭代计划。窗外是旧金山一年中最冷的日子。但硅谷的智能体产业正在进入一个比天气更冷的现实：协议战争结束了，但制缰者的困境才刚刚开始。

当底层协议被锁定，缰绳层的价值创造将被迫向上迁移——从协议层到编排层，从编排层到行业解决方案层，从行业解决方案层到垂直合规层。每一次迁移都在缩小缰绳公司的生存空间，同时也在考验它们在一个由模型厂商定义底层规则的生态中，还能在多大程度上保持独立创造价值的能力。Conductor选择了垂直行业深耕。OpenGrid选择了开源引擎加企业服务。其他公司将在各自的缝隙中做出各自的判断。但所有判断都共同面临一个约束：MCP已经成为智能体工具调用的既成事实的轨道，就像铁轨的轨距一样，一旦被铺设，就难以改变。你可以选择不在上面跑，但你的选择将付出更高的成本，到达更少的目的地。这位CTO最终在方案上写下了什么，记录没有保留。但在2026年春季，这家公司的平台上出现了一个新的功能标签：支持MCP协议。标签下面有一行小字，用灰色字体标注了同时保留对自定义协议后端的兼容性。这是后话，而此刻，他只是在两份文档之间，计算着一个行业在标准锁定之后，留给独立制缰者的时间和空间。