1. 当“接口数量”成为汇报里的漂亮数字我见过太多团队在MCP这里指的是企业内部的模型能力平台Model Capability Platform不是某个具体协议缩写下文统一用MCP代称项目立项时把“已接入XX个接口”当成核心KPI来宣传。季度汇报的PPT上接口数量从30涨到120曲线一路向上会议室里掌声雷动。但真正落到业务侧一线同学用起来还是那老三样查个数据、调个摘要、生成一段文案。剩下那一百多个接口要么没人知道要么调一次报错三次要么返回的结果根本没法直接用。这个现象背后是一个很朴素的道理接口数量是供给侧的自我感动能力数量才是需求侧的真实体感。一个接口只要能被稳定调用、返回可用结果、并且有人真的在用它才算一个“能力”。否则它只是一个躺在文档里的URL和一行没人维护的代码没有本质区别。我写这篇东西是想把“接口数量”和“能力数量”之间的那道鸿沟拆开来看。适合两类人读一类是正在负责企业MCP平台建设、被接口数量指标压着的技术负责人另一类是要在MCP上做上层应用、被一堆“看起来能用”的接口坑过的开发者。我会从指标失真、能力封装、治理成本、评估体系几个角度把这件事讲透并且给出可以直接抄的落地做法。先给一个我自己的判断标准后面所有内容都围绕它展开一个接口要被称为一个“能力”必须同时满足可发现、可调用、可信任、可复用四个条件。缺任何一个它就只是接口不是能力。这个标准我会在第三节展开讲怎么落地。2. 接口数量虚高的三个真实来源2.1 把底层原子接口直接暴露成平台能力最常见的情况是MCP平台的建设方式就是给内部各个业务系统的API做一层代理转发。用户系统有查询接口、订单系统有列表接口、风控系统有评分接口每个系统贡献十几个加起来轻松破百。这种做法的技术成本极低一个网关配置就能批量注册所以接口数量涨得特别快。但问题在于这些原子接口是面向系统设计的不是面向任务设计的。比如“查询用户基础信息”这个接口返回的字段有四十多个包含内部ID、创建时间戳、各种状态码。一个业务同学想做的事是“判断这个用户是不是高价值客户”他需要的是把用户信息、订单记录、风控评分三个接口串起来自己写判断逻辑。平台给了他三个接口但没给他“判断高价值客户”这个能力。我做过一个粗略统计在某次内部调研里120个已注册接口中真正被两个以上不同业务方调用过的只有23个占比不到20%。剩下97个接口调用方只有一个甚至有些接口从上线到现在调用量为零。这些零调用接口在汇报里依然是“已接入能力”但它们对业务没有任何贡献。2.2 同一能力的多版本并存被重复计数第二个来源更隐蔽。一个“文本摘要”能力因为模型迭代先后上线了v1、v2、v3三个版本每个版本一个接口。汇报的时候按接口数算这就是3个能力。但实际上业务方只需要最新的那个旧版本除了少数历史调用方基本处于废弃状态。类似的还有“按不同参数组合拆出来的接口”。比如一个搜索接口支持按标题搜、按内容搜、按标签搜本来是一个接口的三个参数但为了“让调用方更简单”拆成了三个独立接口。调用方是简单了但平台的能力数量被注水了。这种重复计数带来的直接后果是团队会误以为自己覆盖了很多场景实际上场景覆盖的广度并没有增加只是同一场景的入口变多了。等到要做能力盘点、规划下一步建设方向的时候这份被注水的清单会给出完全错误的信号。2.3 为了凑指标而“预接入”的僵尸接口第三个来源是主动注水。季度末要冲接口数量指标于是把一些还没验证过的、甚至还没确定要不要长期维护的接口先注册上去。注册这个动作本身很简单但注册之后没有人负责它的文档、没有人负责它的稳定性、没有人负责它的结果质量。我见过一个极端案例某团队为了完成“本季度新增50个接口”的目标把一个内部测试环境的接口批量同步到了生产环境的MCP平台上。这些接口在文档里看起来正常但实际调用时要么超时要么返回测试数据。更麻烦的是因为它们是“已注册”状态业务方在能力市场里能搜到搜到之后尝试调用失败然后对整个平台失去信任。提示接口注册这个动作如果没有配套的负责人机制和质量门禁它带来的不是能力增长而是信任透支。每多一个不可用的接口平台的可信度就下降一分。这三个来源叠加起来就造成了“接口数量很好看能力数量很难看”的局面。要解决这个问题第一步不是去砍接口而是先建立一套区分“接口”和“能力”的判断标准然后把现有接口按这个标准重新盘一遍。3. 可发现、可调用、可信任、可复用能力的四道门槛3.1 可发现搜得到且搜到的是对的可发现听起来简单但在接口数量上百之后它变成一个搜索质量问题。业务方在能力市场里搜“用户画像”返回结果里排在前面的可能是一个三年前上线的、基于旧模型的老接口而真正在维护的新接口排在第五页。搜得到不等于搜得对。我建议的做法是给每个能力打三类标签业务域标签如用户、订单、风控、任务类型标签如查询、判断、生成、转换、输入输出类型标签如文本到结构化、结构化到文本、文本到文本。搜索时按标签组合过滤而不是只靠关键词匹配。同时每个能力必须有一个明确的“负责人”字段没有负责人的能力在搜索排序里降权。另外能力的命名要统一规范。我见过一个平台里同时存在“getUserInfo”“查询用户”“user_query”“用户信息获取”四种命名风格搜索体验极差。统一成“业务域_任务类型_对象”的格式比如“用户_查询_基础信息”虽然看起来死板但搜索准确率会大幅提升。3.2 可调用文档能跑通错误能看懂可调用的最低标准是一个没接触过这个能力的开发者照着文档能在15分钟内完成第一次成功调用。这个标准听起来低但实际达标率很低。常见问题包括文档里的示例参数是过期的、鉴权方式没写清楚、返回结果的字段含义没有解释、错误码只有数字没有说明。我自己的做法是给每个能力配一个“可执行文档”。文档里的示例请求不是静态文本而是一个可以直接点击运行的按钮运行结果实时返回。这样文档永远不会过期因为它是从真实调用生成的。错误码方面每个错误码必须对应一句人话解释和一条建议操作比如“40103当前账号没有该能力的调用权限请联系能力负责人开通”。还有一个容易被忽略的点是超时和重试策略。很多接口文档不写超时时间调用方只能猜。猜短了频繁超时猜长了拖慢整个链路。能力文档里应该明确标注P99延迟和推荐超时时间让调用方有据可依。3.3 可信任结果稳定质量可预期可信任是四道门槛里最难的一道。一个能力今天返回的结果和明天返回的结果质量差异很大调用方就不敢把它用在正式业务里。造成不稳定的原因很多底层模型更新了但没通知、依赖的数据源变了、并发高了之后结果质量下降。要建立信任需要做三件事。第一版本化管理。能力的每次变更包括模型更新、提示词调整、依赖数据源切换都要产生新版本旧版本保留一段时间调用方可以选择锁定版本。第二质量监控。对每个能力的关键指标做持续监控比如返回结果的空值率、格式错误率、人工抽检合格率。第三变更通知。能力有重大变更时主动通知所有调用方而不是等调用方自己发现。我见过一个做得比较好的实践某团队给每个能力定义了一个“健康分”由调用成功率、结果合格率、延迟达标率三个指标加权计算。健康分低于阈值的接口在能力市场里会被标记为“维护中”调用方看到标记就会谨慎使用。这个机制倒逼能力负责人主动维护质量而不是上线就不管了。3.4 可复用能被不同业务方用在不同的场景里可复用是区分“接口”和“能力”的最终标准。一个接口如果只有一个业务方在用它本质上是一个定制化接口不是平台能力。可复用的能力应该能被至少两个不同业务方用在至少两个不同场景里。要做到可复用能力的设计就要从“满足某个具体需求”转向“解决某一类问题”。比如“从合同文本里抽取关键条款”这个能力如果只针对某一种合同模板设计那它只能被一个业务方用。如果把它设计成支持多种合同类型、输出结构化的条款列表那法务、采购、财务三个部门都能用。这里有一个反直觉的点可复用性往往要求能力在输入输出上更“笨”一点。太聪明的能力会把很多业务逻辑封装在里面导致换个场景就不适用。比如一个“智能判断用户是否流失”的能力如果把判断规则写死在内部那换个业务线就不行了。更好的做法是输出一组特征值让调用方自己决定判断规则。能力的边界要清晰不要越界做调用方该做的事。4. 从接口清单到能力地图一次真实的盘点过程4.1 盘点的第一步是给每个接口打标假设你手里有一份120个接口的清单第一步不是砍而是给每个接口打上四个维度的标签调用方数量、调用频率、结果合格率、负责人是否明确。这四个维度可以快速筛出哪些接口是“真能力”哪些是“僵尸接口”。具体操作上调用方数量和调用频率可以从网关日志里直接统计按过去90天的数据算。结果合格率需要一点人工可以抽样调用每个接口看返回结果是否符合预期。负责人是否明确查一下能力注册时填的负责人字段如果为空或者负责人已经离职就算不明确。打完标之后用下面这个矩阵来分类调用方数量调用频率结果合格率分类处理建议≥2高高核心能力重点维护优先展示≥2低高长尾能力保留降低展示权重1高高定制接口评估是否可泛化1低高边缘接口考虑下线或合并任意任意低问题接口限期整改或下线任意零调用任意僵尸接口直接下线这个矩阵不是绝对的但能帮你快速把120个接口分成几类而不是一视同仁地维护。4.2 合并同类项把三个接口变成一个能力盘点过程中最常见的发现是有大量接口其实是同一个能力的变体。比如“查询用户基础信息”“查询用户扩展信息”“查询用户标签信息”三个接口完全可以合并成一个“查询用户信息”能力通过参数控制返回哪些字段。合并的时候要注意向后兼容。不能直接把旧接口下线而是把旧接口标记为“已合并”调用时自动转发到新能力并在返回结果里加一个提示字段告诉调用方“此接口已合并至XXX建议迁移”。给调用方一个迁移窗口期比如三个月窗口期结束后再真正下线。合并带来的好处不只是数量减少更重要的是调用方的心智负担降低。原来要记住三个接口的差异现在只需要记住一个。而且合并后的能力通常更稳定因为维护力量集中了。4.3 给每个保留的能力配一个“能力卡片”盘点之后保留下来的能力每一个都要有一张标准化的能力卡片。卡片包含以下字段能力名称统一命名规范业务域_任务类型_对象能力描述一句话说清楚这个能力解决什么问题不超过50字输入输出输入参数列表和输出字段列表每个字段有类型和说明调用示例可直接运行的示例请求和返回结果性能指标P50/P99延迟、推荐超时时间、并发上限质量指标过去30天调用成功率、结果合格率负责人姓名和联系方式版本历史版本号、变更内容、变更时间依赖说明依赖哪些底层系统或数据源这些依赖的稳定性如何这张卡片是能力对外的唯一接口。业务方不需要看底层实现只需要看这张卡片就能判断能不能用、怎么用。卡片的信息要自动更新不能靠人工维护否则很快会过期。4.4 盘点的产出不是清单是地图盘点做完之后不要输出一个平铺的接口清单而要输出一张能力地图。地图按业务域划分区域每个区域里列出该域下的能力能力之间用箭头标注依赖关系和数据流向。这样业务方在看地图的时候能快速找到自己需要的区域也能看到能力之间的组合可能性。能力地图还有一个好处是暴露空白区。如果某个业务域下只有查询类能力没有判断类和生成类能力那这个域的能力覆盖就是不完整的。地图上的空白区就是下一阶段的建设方向比拍脑袋定规划靠谱得多。5. 治理成本为什么接口越多维护越难5.1 每个接口都是一个持续的维护负担接口注册只是开始后面的维护才是大头。一个接口上线之后需要有人负责它的文档更新、依赖变更、模型迭代、故障处理、调用方答疑。这些工作不会因为接口调用量低就消失。一个零调用的接口和一个高调用的接口在维护成本上可能差不多但产出完全不同。我算过一笔账一个接口的年维护成本按人力折算大概在0.1到0.2人天之间。听起来不多但120个接口就是12到24人天相当于一个人大半年的工作量。如果其中有一半是僵尸接口那就是6到12人天被浪费掉了。这些人力本来可以用在真正有价值的能力建设上。更麻烦的是接口越多变更影响面越难评估。你要改一个底层数据源需要排查哪些接口依赖它这些接口又有哪些调用方调用方里有没有关键业务。这个排查过程在接口数量少的时候是小时级在接口数量多的时候是天级而且很容易漏。5.2 能力负责人机制是治理的核心治理接口泛滥最有效的机制是能力负责人制。每个能力必须有一个明确的负责人负责人对这个能力的全生命周期负责上线、维护、迭代、下线。没有负责人的能力不允许注册已注册但没有负责人的能力限期整改整改不了就下线。负责人机制要跟考核挂钩。负责人的考核指标不是“接入了多少接口”而是“负责的能力被多少业务方使用、调用成功率多少、结果合格率多少”。这样负责人的利益和能力的实际价值绑定在一起而不是和数量绑定。我见过一个团队的做法是每季度做一次能力负责人述职每个负责人讲自己负责的能力这季度被谁用了、解决了什么问题、下一步怎么优化。讲不出来的能力下季度直接下线。这个机制运行了两个季度接口数量从150降到了80但业务方的满意度反而上升了因为留下来的都是真正有用的。5.3 下线比上线更需要勇气和流程大部分团队的上线流程很完善下线流程却很随意。一个接口没人用了就放在那里不管既不维护也不下线。时间长了平台上堆满了“薛定谔的接口”——你不知道它还能不能用也不知道有没有人在用。我建议建立一套标准的下线流程连续90天零调用的接口自动进入下线候选名单通知负责人确认负责人确认后进入30天公示期公示期内如果有调用方提出异议则暂缓下线公示期结束后正式下线并从能力市场移除。这套流程的关键是自动化触发不能靠人工定期盘点。零调用检测应该是平台的一个内置功能每月自动跑一次生成下线候选名单推给负责人。负责人只需要做确认动作不需要自己去发现哪些接口没人用。注意下线接口之前一定要确认没有隐藏调用方。有些调用方不走网关直接调底层服务这种情况下网关日志里看不到。下线前要做一次全链路的调用排查确保没有遗漏。6. 怎么衡量MCP的真实能力水平6.1 用“能力覆盖度”替代“接口数量”衡量MCP做得好不好第一个要换掉的指标就是接口数量。替代指标是能力覆盖度定义是在目标业务场景清单里有多少场景有对应的能力可以支撑且该能力通过了可发现、可调用、可信任、可复用的四道门槛。具体算法是先列出目标业务场景清单比如“用户增长分析”“合同风险审查”“客服工单分类”等每个场景标注需要哪些能力。然后逐个检查这些能力是否达标。达标场景数除以总场景数就是能力覆盖度。这个指标的好处是它直接跟业务价值挂钩。接口数量涨了但覆盖度没涨说明在做无用功。覆盖度涨了但接口数量没涨说明在做合并优化是好事。6.2 用“能力复用率”衡量平台化程度第二个指标是能力复用率定义是被两个以上业务方调用的能力数量占总能力数量的比例。这个指标反映的是平台化程度。复用率高说明能力设计得好能跨业务线使用复用率低说明大部分能力还是定制化的平台价值有限。我观察到的规律是一个健康的MCP平台复用率应该在40%到60%之间。太低说明能力太定制化太高说明可能过度抽象有些场景需求没有被满足。这个区间不是绝对的但可以作为参考。6.3 用“调用方满意度”做定性校验定量指标之外还要做定性校验。每季度找几个典型调用方做深度访谈问三个问题你最近用MCP解决了什么问题过程中遇到的最大障碍是什么如果MCP只能保留三个能力你希望是哪三个这三个问题能挖出很多定量指标看不到的信息。比如调用方可能告诉你某个能力虽然调用量高但每次都要做大量后处理才能用实际体验很差。或者某个能力调用量低但它是某个关键业务链路里不可替代的一环。这些信息对能力规划很重要。6.4 指标要少而准不要做成仪表盘最后提醒一点衡量MCP的指标不要太多。我见过一些团队做了几十个指标的仪表盘结果没人看。指标多了等于没有指标。建议核心指标控制在五个以内能力覆盖度、能力复用率、调用成功率、结果合格率、调用方满意度。这五个指标每月更新一次在团队内部同步足够了。7. 一个可以照着做的季度治理节奏7.1 第一个月盘点和打标季度第一个月做全面盘点。把现有接口清单拉出来按第4节的矩阵打标分类。同时启动能力负责人确认没有负责人的接口限期认领。这个月不追求产出追求的是把家底摸清楚。盘点的具体操作可以分三步第一步从网关拉过去90天的调用日志统计每个接口的调用方数量和调用频率第二步对调用频率不为零的接口做抽样调用评估结果合格率第三步把三个维度的数据合并按矩阵分类。这个月结束时你应该有一份清晰的分类清单哪些是核心能力、哪些是长尾能力、哪些是定制接口、哪些是僵尸接口。7.2 第二个月合并和下线第二个月做合并和下线。把同类接口合并成统一能力把僵尸接口走下线流程。合并的时候注意向后兼容给调用方迁移窗口期。下线的时候注意排查隐藏调用方避免误伤。这个月的工作重点是沟通。合并和下线都会影响调用方提前沟通比事后通知重要得多。建议在月初发一个变更公告列出所有受影响的接口和对应的迁移方案然后每周跟进迁移进度。7.3 第三个月建卡片和上地图第三个月给保留下来的能力建能力卡片并绘制能力地图。能力卡片的信息尽量自动生成减少人工维护。能力地图按业务域划分标注能力之间的依赖关系。这个月还要做一件事把能力覆盖度和能力复用率两个指标算出来作为下季度规划的基线。同时找几个典型调用方做访谈收集定性反馈。7.4 下季度循环把治理变成常态一个季度的治理做完之后不要停下来。下季度继续循环但节奏可以放缓。盘点可以改成每季度一次合并和下线改成每月一次小批量处理能力卡片和地图持续更新。关键是把治理变成常态流程而不是一次性运动。一次性运动做完之后接口数量又会慢慢涨回去。只有变成常态流程才能持续保持能力数量的健康。8. 几个我踩过的坑和对应的解法8.1 坑一为了合并而合并把不同场景的能力强行统一我早期做过一次合并把“查询订单状态”和“查询物流状态”合并成了一个“查询订单全链路状态”的能力。结果发现订单状态的调用方只关心订单本身物流状态的调用方只关心物流合并之后返回的字段变多了两个调用方都要做额外的过滤反而更麻烦。解法是合并的前提是输入输出高度重叠。如果两个能力的输入参数和输出字段重叠度低于70%就不要合并。强行合并只会增加调用方的处理成本。8.2 坑二下线接口时没有排查直接调用方有一次下线一个零调用接口网关日志显示过去90天零调用于是直接下线了。结果下线后第二天一个业务方找过来说他们的定时任务挂了。排查发现他们的定时任务不走网关直接调底层服务所以网关日志里看不到。解法是下线前做全链路调用排查不只看网关日志还要看底层服务的访问日志。如果底层服务有访问记录即使网关没有也要先联系调用方确认。8.3 坑三能力卡片写完就没人更新了能力卡片刚建的时候信息很全但过了一个月模型更新了、依赖数据源换了、负责人离职了卡片上的信息还是旧的。调用方照着卡片调用发现对不上信任度下降。解法是能力卡片的信息尽量自动生成不要人工维护。调用示例从真实调用生成性能指标从监控系统拉取负责人从HR系统同步。只有能力描述和标签需要人工维护这部分工作量小容易坚持。8.4 坑四把接口数量指标换成能力数量指标但本质没变有一段时间我们把KPI从“接口数量”改成了“能力数量”但能力的定义没有变还是注册即算。结果只是换了个名字数量注水的问题依然存在。解法是指标的定义要跟质量门槛绑定。能力数量只统计通过了四道门槛的能力没通过的不算。这样指标才有区分度才能引导团队做正确的事。9. 写给正在做MCP的你如果你正在负责一个企业MCP平台我建议你做的第一件事不是去接更多接口而是把现有接口按四道门槛重新盘一遍。盘完之后你可能会发现真正能称为“能力”的可能只有你想象的一半甚至更少。这不是坏事这是把问题暴露出来了。第二件事是建立能力负责人制。没有负责人的能力不允许注册已注册的限期认领。这个机制一开始会有阻力因为大家习惯了“注册完就不管”的模式。但坚持两个季度之后你会发现平台的健康度明显提升。第三件事是把衡量指标从数量转向质量。能力覆盖度、能力复用率、调用成功率、结果合格率、调用方满意度这五个指标足够反映平台的真实水平。指标少了团队反而更清楚该往哪个方向使劲。最后说一个我自己的体会MCP的价值不在于它连接了多少系统而在于它让多少业务方少写了多少重复代码。一个业务方原来要花三天做的功能因为MCP上有一个现成能力现在只要三小时这才是平台的价值。接口数量只是这个价值的一个粗糙代理指标而且是一个很容易失真的代理指标。把注意力从接口数量上移开放到业务方的实际使用体验上很多决策会变得清晰很多。如果你现在手里正好有一份接口清单不妨今天就打开看看里面有多少接口在过去90天里被两个以上业务方调用过。这个数字可能会让你意外但它是你下一步所有决策的起点。