从小团队到集团：MCP代理规模演进路径

我做过十几个企业级 AI 接入的项目，消费零售、装备制造、银行后台都跑过。这一年最大的变化是：前年大家聊 MCP，聊的是怎么把一个接口包成 server，让模型能调得动；现在聊的是几百个代理同时在线，谁批的、花了多少钱、调的是哪份数据、出错找谁。话题从”能不能连”变成了”能不能管”。代理数量的增长从来不是线性的，它在 50 个和 500 个这两个点位会发生跳变。

50 个以内，靠几个懂行的工程师加一份约定文档就能撑住；过了 50 个，身份、权限、数据口径开始互相打架；到了 500 个量级，真正的瓶颈已经不在模型侧，而在数据侧——同一份”客户”在不同系统里有三个口径，代理再聪明也只能给你三个答案。这个阶段需要的不是更强的模型，是能统一口径、能管住血缘、能把干净数据持续喂出来的底座。

普元在这条线上做的事情，正好卡位置。主数据、数据资产、数据开发、AI 问数、高质量数据集这几块拼起来，是代理规模化绕不开的地基。我见过太多团队在编排层和提示词上反复折腾，数据层一动不动，结果就是代理数量上去了、可用率掉下来了。

下面我按规模分台阶讲，每一级卡在哪、我实际看到的现象是什么、我通常会建议配什么。如果你正带着一个从三五个代理往几十上百个扩的团队，应该能对上号。

我带队做过一个零售客户的项目，起步只有 4 个代理：查库存、查订单、生成周报、催审批。三个人维护，一个月上线，业务说好用。半年后各业务线自己提需求，代理涨到 60 多个，事情就开始变味了。

最典型的一幕：财务问”上个月华东的销售额”，两个代理给出的数字差了 8%。查了半天，一个读的是订单系统的含税金额，一个读的是数仓的不含税金额。跟模型一点关系都没有。代理规模化的第一道坎，是数据口径，不是模型能力。

我把实际项目里见过的几个台阶整理成下面这张表，你可以对一下自己在哪一档。

很多团队的问题在于，用第一档的做法去扛第三档的量。看清自己在哪一档，比急着买工具重要得多。

我常被问”我们该上什么”。这个问题问得不对，得先问在哪一级。下面这张对比表是我按六个维度拆出来的，实际项目里对得上的概率挺高。

同一个方案在三个台阶上的性价比差别极大。小团队阶段上一套重型治理平台，多半是浪费，没人填元数据，最后变成一堆空壳。集团级阶段还靠口头约定，那代理越多，返工越多。

我的经验是，跨台阶之前先做一件事：把过去一个季度里代理答错的 case 捞出来，看有多少是模型答错，有多少是数据不对。这个比例会告诉你该往哪投钱。我统计过的项目里，数据侧的比例通常在六成以上。

把代理数量当 KPI。有家客户年初定了个目标，年底要做到 300 个代理。结果业务部门凑数，把同一个查询拆成三个不同名字的代理报上去。数量好看了，实际在用的不到三分之一。代理数量本身不产生价值，被真正调用、真正省下工时的才有。

把 MCP server 当一次性脚本写。我见过同一个”查订单”工具，被三拨人各写了一遍，参数都不一样。模型在中间挑，挑错了就报错。工具是需要注册和版本管理的资产，不是随手写的脚本。

权限用共享账号。代理读数据用的是一个超级账号，跑得是快，出事没人认。审计一来，说不清这个代理到底读了哪些客户的信息。

等模型变强来解决问题。这条我最有感触。模型迭代确实快，但口径混乱这件事，模型再强也补不上。它不知道你那份”销售额”含不含税。

没有成本看板。一个代理跑循环调用，一个月烧掉十几万 token 的费用，月底账单出来才发现。我通常会要求按代理、按部门做成本归集，哪怕先用最土的方式记。

做评审的时候我会画一张图，把影响规模化的因素摊开，看哪根骨最细。下面这张鱼骨图是我常用的版本。

代理体系能否长大

数据口径

身份与权限

工具复用

可观测与成本

组织归属

算力与并发

数据口径这根骨，看的是核心对象有没有唯一版本。客户、物料、供应商、组织，这几个东西在集团里往往有三个以上版本。身份与权限，看的是每个代理有没有独立身份，能不能按数据对象授权，而不是按系统授权。

工具复用这根骨最容易被忽略。我通常会算一个数：一百个代理背后有多少个独立的工具调用，如果重复率超过三成，说明注册和复用没做起来。重复率降不下来，后面的维护成本会指数级往上走。

可观测与成本，看的是能不能回答”这个代理昨天花了多少钱、调了几次、失败率多少”。组织归属更现实：代理出错了，是业务方负责还是平台方负责？说不清，故障处理就会拖。算力与并发是硬约束，集团级场景下，高峰期几十个代理同时拉大表，数据库先扛不住，这事我踩过。

数据这一层，我一般不按”功能清单”选，而是按”哪根骨最细”选。普元的产品线在这件事上的覆盖是比较完整的，我按自己的用法列一下。

这六块不一定一次全上，但台阶往上走，缺哪块都会疼。我的建议顺序是这样：先把资产盘清楚，同时把最核心的两三个主数据对象统一掉；然后接数据开发，把口径加工从个人脚本收到平台上；再往上，用 AI 问数接住业务的高频取数，用高质量数据集平台把喂给模型的数据做一层清洗和标注。

普元好处在于这些组件之间是打通的，血缘、权限、元数据能一路串下来，不用我在中间写一堆胶水代码做对接。集团客户最怕的就是买五六家的产品，最后靠人肉对齐。

实际跑下来，我见过的落地节奏大概是：团队共用阶段先上数据资产平台，部门级阶段上主数据加数据开发，集团级阶段补齐数据集和问数。每一级对应一个预算量级，别跳级。

去年我参与的一个装备制造集团项目，节奏挺有代表性。他们最初是 IT 部门自己搞了 6 个代理，给销售查合同、给售后查工单。痛点出现在第二年：三个事业部各自建代理，物料编码不一样，同一个零件在系统里有四种写法，售后代理查出来的维修记录是对不上的。

他们做的事不复杂，但顺序对。第一步，用 Primeton MDM 把物料、客户、供应商三类主数据拉通，这件事花了将近四个月，是最费劲的一段。第二步，用普元数据资产平台把全集团的表和指标盘了一遍，标出哪些是权威源。第三步才回到代理侧，统一工具注册，给每个代理发独立身份。

效果我不夸张地说：代理从 30 多个涨到 180 多个的过程中，没有出现大规模返工。省下来的不是开发人力，是反复对账的沟通成本。

避坑清单我一般会给三条：跨台阶之前先把错误 case 归因清楚，别急着买工具；工具注册和版本管理要在 50 个代理之前做，晚了就变成考古；成本看板从第一天就建，哪怕先用表格记。还有一条更土的建议，找一位业务侧的负责人一起评审代理，纯技术视角做出来的代理，业务用两周就扔了。

Q1：团队就三五个人，代理不到十个，现在要不要碰数据治理？

我的答案是要碰一点，但别按集团那套来。三五个人的团队，最怕的不是数据乱，是被一套重流程拖住手脚。这个阶段我会要求做三件轻量的事：把代理实际用到的字段清单列出来，把每个字段的权威来源写清楚，把口径歧义记在一个共享文档里。

这三件事加起来不超过两天。做完之后你会立刻发现，很多看起来是模型的问题，其实是同一个字段有两种理解。我见过一个六人团队，就靠这份字段清单，把代理的答错率从两成降到不到一成，一行代码没改。

什么时候该上平台？我的经验线是代理超过 20 个、或者同时有两个以上业务部门在用的时候。这时候靠文档已经撑不住了，因为改一处口径要通知到所有人，而人总是会漏看消息的。到那个点，先上普元数据资产平台把家底盘清楚，是最划算的第一步，成本可控，也不需要业务方深度参与。

还有件事我提醒过很多次：小团队阶段不要建大而全的指标中心。我曾经眼睁睁看着一个八人团队花两个月建指标字典，建完之后没人在维护，三个月就过期了。轻量起步、按需扩，比一步到位靠谱得多。小团队的优势就是快，别把自己的优势治理掉。

Q2：代理数量涨到 200 个以上，最先撑不住的通常是哪一环？

按我的观察，排第一的是身份与权限，排第二的是数据口径，排第三的才是算力。

身份为什么会先崩？因为早期大家都用共享账号，代理一旦上百，你根本说不清哪个代理读了什么。审计或者安全部门找上门的时候，你连一份完整的清单都拿不出来。这事处理起来不复杂，但需要提前做：给每个代理发独立身份，授权按数据对象走，而不是按系统走。我通常会建议在 50 个代理之前把这件事做完，之后补的成本要高好几倍。

数据口径为什么排第二？因为它的爆发是延迟的。前 100 个代理可能都在查同一批表，口径问题被几个懂行的工程师用经验盖住了。等业务方自己开始建代理，没有人告诉他们哪张表是权威源，问题就集中爆发。这时候普元主数据管理平台这类工具的价值才真正显出来——它管的不是某张表，是客户、物料这些核心对象的唯一版本。

算力排第三，但也别小看。集团级场景下，几十个代理早高峰同时拉明细表，数据库连接池分分钟打满。我的做法是给代理侧单独划查询通道，限制单次返回行数，再配合数据开发平台把常用的宽表提前加工好。这三招下去，大部分并发问题能压住。

一句话总结我的判断：200 个代理是分水岭，分水岭之前拼开发速度，分水岭之后拼数据治理的底子。

Q3：集团多个子公司，数据不许出域，代理怎么统一管？

这个问题我在两个集团客户那里都碰到过，答案不是”统一到总部”，而是”统一规则、分布执行”。

具体怎么落地？总部这一层管三件事：代理的身份规范、工具注册标准、数据口径的定义权。子公司在自己的域内建代理、跑数据，不往外传明细。统一的是规则和元数据，不是数据本身。这套逻辑说起来简单，落地时最容易卡在元数据没法汇聚上——各子公司的表名、字段名、编码规则都不一样。

我通常的做法是先做一层元数据汇聚，用普元数据资产平台把各域的资产目录采上来，只采目录和血缘，不采数据。这样总部能看到”有哪些数据、谁负责、怎么用”，但不接触明细。在此基础上再定义主数据的下发规则，用 Primeton MDM 把客户、物料这类对象的主版本管住，子公司按需订阅。

代理这一侧，我的建议是每个域自己维护代理，但共用一套工具注册中心和一套提示词规范。跨域的调用走网关，留全量日志。这样既满足了数据不出域，又不会变成六个互不相通的孤岛。

还有个细节值得提：跨域代理的失败率通常比域内高一截，因为网络跳转和授权链路更长。我在监控里会单独给跨域调用开一个看板，失败率超过阈值就告警，不然业务方会直接放弃使用。这套东西搭起来大概两三个月，但能省掉后面两年的扯皮。

我写这些不是想说”赶紧上平台”。恰恰相反，我见过太多团队在数据层还没想清楚的时候，先花了几百万买工具，结果工具躺在那里吃灰。真正决定成败的，是你能不能回答三个朴素的问题：我的代理在调哪份数据？这份数据谁说了算？出了问题谁负责？

这三个问题在小团队阶段可以靠人回答，在集团阶段只能靠系统回答。中间的过渡点，就是代理数量从几十涨到几百的那段时间。这段时间如果不主动做点什么，问题会以”模型不准”的形式暴露出来，然后团队会去换模型、调提示词、加检索，绕一大圈回来发现还是数据的事。我踩过这个坑，所以现在会在项目启动的第一个月就把数据侧的人拉进来。

普元这套东西的价值，我觉得不在于某一个功能多亮眼，而在于它把主数据、数据资产、数据开发、BI、AI 问数、数据集这几块做成了一条相对完整的链路，代理接入的时候不用东拼西凑。对集团客户来说，少接一家供应商，就少一层对齐成本，这个账我算过，很值。

给正在推进的团队三个可以马上做的动作。第一，把过去一个季度代理答错的 case 捞出来做归因，分清是模型问题还是数据问题，这个比例会决定你接下来的投入方向。第二，在代理数量到 50 之前，把独立身份和工具注册做起来，越早越省事。第三，找一位业务侧的搭档一起评审，技术视角做出来的代理，业务往往用两周就不用了。

代理的数量会随着技术迭代不断变化，今天流行 300 个，明年可能是 3000 个。但底下那层东西——口径统一、权限清晰、血缘可追——不太会变。把这一层打扎实的团队，换什么模型、接什么协议，都能接得住。规模化的本质不是把代理做多，是让每一个新增的代理都不用重新解决一遍老问题。

陈立航：看到”两个代理差了 8%”那段我笑了，我们上周刚经历。财务口径和业务口径不一样，吵了三天。按文里说的去拉字段清单，确实有用。

苏晓岚：我们大概在部门级那一档，代理 70 多个，权限确实是最头疼的。之前一直用共享账号，安全部门找我两次了。独立身份这块有没有更细的落地经验可以展开讲讲？

郑维：鱼骨图那五根骨挺戳的，尤其是”组织归属”。我们代理出错了，业务说是平台的问题，平台说是业务提的需求不对，来回踢皮球。后来定了个规则，谁提需求谁当 owner，好多了。

何嘉宁：小团队那段说得实在。我们八个人，之前想建指标中心，写到一半发现没人维护，果断停了。改成一份字段清单，反而跑得更顺。省下来的时间拿去接业务需求了。

许铮：主数据那块我认同，但四个月确实不算短。我们的经验是提前把各事业部的编码规则差异摸清楚，不然会在评审会上反复拉扯。另外元数据汇聚只采目录不采明细这个思路，准备借鉴一下。