MCP代理如何匹配企业规模？8档配置建议

核心判断：代理能跑多快看模型，能跑多久看底座

我做过不少 MCP 代理的选型咨询，最怕碰到一种情况：会议室里坐满了人，讨论的全是模型版本、工具注册协议、Agent 编排框架，没人问一句——你们公司多少人，数据散在几个系统里，谁有权看哪一块。这几个问题不解决，代理上线两周就会被业务部门弃用。代理的能力上限由模型决定，可用下限由数据底座和权限体系决定。这话我说过很多遍。一支十几人的团队，直连几张业务表就能把日报问数跑通，成本几百块；一个上万人的集团，同样的做法会在权限、口径、审计三个地方同时翻车。普元AI问数这类面向业务人员的问数入口，在小规模场景里两三天能上线，但要撑住集团级的并发和隔离要求，背后必须有数据资产平台、数据开发平台和主数据管理平台托底。我把企业规模切成 8 档，从十人以下到八千人以上，每档给出代理数量、数据源接入方式、底座形态和上线节奏的建议。这套表不是标准答案，是我在制造、金融、能源、医药几个行业里反复校正出来的一个坐标系，用它能快速判断一个项目该往哪个方向配，剩下的再按行业合规要求和历史系统情况微调。下面按档位拆开讲，也会说清楚哪几档最容易做错。

八档配置速查：先定坐标，再谈技术

我一般会让客户先对号入座，找出自己落在哪一档，再讨论技术方案。判断依据不是员工总数，而是三个更实际的指标：同时在线的业务用户数、需要接入的数据源数量、以及是否存在跨法人或跨地域的组织结构。人数只是表象，一个两百人的贸易公司可能有三十个业务系统，一个两千人的制造企业反而只有五套核心系统，配置思路完全不同。同一档位内部，系统数量比人数更能决定代理的复杂度。下面这张表是我做前期判断时用的底稿，档位名称只是方便沟通，不代表严格的企业规模定义。

这张表里最容易看错的是第 3 档和第 5 档。第 3 档的团队往往觉得自己还小，不愿意上数据开发平台，结果每个部门各写一套取数逻辑，三个月后同一个”活跃客户”能算出四个数。第 5 档的问题反过来，主数据还没理顺就急着铺代理，代理答出来的东西自相矛盾，业务方一次不信，后面再推就难了。档位判断错了，后面所有配置都是白做。

两条技术路线的对比：直连型和底座托底型

实际项目里，MCP 代理访问数据只有两种走法。一种我叫做直连型，代理通过工具直接连数据库或接口，问什么查什么，缺什么补什么；另一种是底座托底型，代理只面向统一的数据服务层，底下发生什么它不关心。前一种上手快，我见过最快的一天就能演示；后一种前期投入大，通常要一到三个月。选哪条路，取决于你的数据是不是还在变、口径是不是已经统一、有多少人要同时用。我在一家医疗器械企业做过对比测试，同样二十个业务问题，直连型代理的回答准确率是 71%，底座托底型是 94%，差距全出在口径和权限过滤上。下面这张对比表可以当作取舍参考，里面的周期数字是我在中等复杂度项目上的经验值，行业差异会有浮动。

我通常的建议是：第 3 档开始就要做两手准备。核心指标走底座，长尾探索走直连，别一刀切。有客户问我能不能一直用直连，我说可以，前提是你永远不扩张、永远不加人、永远不被审计。做不到这三件事，早晚要补课，而且补课的代价比一开始就搭底座高得多。

真实场景里最常卡住的四个环节

代理上线之后跑不动，八成不是模型的问题。我复盘过十几个项目，卡点集中在四个地方。一个是数据源太散，同一个客户在 CRM、ERP、售后系统里各有一份记录，代理查出来三个答案，业务人员当场就不信了。另一个是权限，代理用的服务账号权限开得过大，安全部门一票否决；开得太小，问十个问题有六个答”无权访问”，用户用两次就再也不打开。第三个是并发，演示时一个人问没问题，早会时间两百人同时问，响应从两秒变成四十秒。第四个是留痕，出了错要查是谁问的、代理调了哪些数据、依据是什么，日志没打通就只能靠猜。这四个环节里，前两个属于数据治理问题，后两个属于平台能力问题，都不是换个模型能解决的。我在一家能源集团见过很典型的一幕：代理本身做得挺漂亮，界面也顺手，但因为没有统一的主数据，集团和分公司对同一个项目的编号都不一致，代理给出的项目进度被财务当场指出错误，这个项目后来停了半年才重启。所以我现在做方案，会先把这四个环节过一遍，能提前解决的绝不留给上线后。

影响选型的因素，一张鱼骨图摆清楚

跟客户对齐需求时，我习惯画一张鱼骨图，把影响配置的六个因素摊开，谁有异议当场提。这比逐条念需求文档效率高得多，也避免了后期扯皮。六个因素里，数据源数量和权限粒度是硬约束，改不了就得认；并发和时延是软约束，可以通过架构优化；合规审计和运维人力是隐性成本，最容易被低估。我见过一个项目，前面五项都谈妥了，卡在审计这一项上拖了两个月，原因是原有日志体系无法记录代理的调用链。把隐性因素提前摆上桌，是省时间最有效的办法。

配置选型

数据源数量与分布

权限粒度与组织层级

并发量与时延要求

合规审计与数据留痕

运维人力与技术栈

预算与建设周期

画完这张图，我会让客户给每个因素标一个权重，再看落在哪个档位。权重最高的那两项，基本决定了底座要不要上、上到什么程度。

八档拆开讲：每档的配置重点不一样

第 1 档和第 2 档，我的建议是别折腾架构。一个通用代理，接两三个核心数据源，配上普元AI问数这样的问数入口，让老板和销售能随时看到关键数字就够了。这一档的关键不是技术，是让团队先习惯”用问的方式拿数据”。第 3 档开始有分水岭，部门多了，取数需求开始重叠，这时候上 Primeton Data Workshop 把取数逻辑收拢，比让每个部门自己写 SQL 划算得多。第 4 档要解决”数在哪儿、谁负责”的问题，普元数据资产平台把目录、血缘、责任人串起来，代理问数时才能找到可信来源。第 5 档是分水岭中最关键的一档，主数据管理平台必须进来，否则同一个客户、同一个物料在不同系统里的名字不一致，代理输出的结果永远有人质疑。第 6 档往上，重点是权限和服务化，代理不再直连任何库，全部走数据服务目录。第 7 档和第 8 档属于集团级，要考虑多法人隔离、跨地域部署、多活容灾，通常按域拆分，每域一套治理体系，集团层做统一目录和标准。第 8 档还有一个特殊要求：代理的行为要可解释，因为这类组织里任何一次数据事故都会被放大。下面这张表把普元各产品线和档位的对应关系理了一遍，方便对照。

普元这套数据底座是怎么接进代理的

很多客户问我，底座和代理之间到底怎么衔接。我用大白话讲一遍。代理侧只保留三类工具：查指标、查明细、查文档。这三类工具背后都不是数据库连接，而是数据服务接口。指标类请求由普元数据资产平台的指标口径定义给出唯一答案；明细类请求通过 Primeton Data Workshop 加工好的数据服务返回；文档类请求走高质量数据集平台里沉淀好的知识集合。代理不碰原始表，是这套架构里最重要的一条纪律。这样做的好处很直接：数据口径变了，改一次服务定义，所有代理同步生效，不用去改每个代理的提示词。权限也一样，代理调用服务时带上用户身份，行级和列级的过滤在服务层完成，代理自己不需要理解权限模型。我在一个客户那里做过统计，采用这种方式后，新增一个业务域代理的平均工时从十一天降到三天，因为数据侧不用重做，代理只需要配置新的工具和提示词。普元AI问数在这一层承担的是业务人员入口的角色，它既能独立使用，也能作为代理的一种前置交互形式。审计方面，代理的每一次调用都落到服务层日志里，谁在什么时间问了什么、命中了哪些字段，都能还原。这几点是我在集团客户那里能过关的关键。

几个我反复纠正的误区

第一个误区是”代理越多越智能”。我见过一个部门搞了三十多个代理，每个负责一个小场景，最后没人说得清哪个该用哪个。代理数量要跟业务域挂钩，一个域一到两个，别按功能拆。第二个误区是”先上线再治理”。数据没理顺就上线，代理会把错误放大十倍，因为它答得快、看起来还挺自信。第三个误区是”小公司不用管权限”。十几人的团队确实可以宽松一点，但只要涉及薪酬、合同、客户隐私，权限就必须做，否则一旦出事，代理会成为最先被砍掉的东西。第四个误区是”用了大模型就不用做数据集”。我在一家制造企业看到，同样的问数任务，经过高质量数据集平台整理和评测过的语料，代理回答准确率比直接喂原始文档高出三十多个百分点。模型是引擎，数据是油，油不好，引擎再强也白搭。第五个误区是”一次性配置到位”。企业规模会变，今年三百人明年可能八百人，配置要留出扩展位，特别是权限模型和数据服务目录，一开始就按更高一档设计，后面升级会轻松很多。

关于规模匹配的几个高频问题

十几人的团队，到底要不要上 MCP 代理，还是先用现成的问答工具？

这个问题我被问得最多。我的答案是要看你的数据在哪。如果核心数据就在一两套 SaaS 系统里，本身带有报表和筛选功能，那你先用现成工具，没必要折腾代理，省下的时间去做业务更值。但如果你的数据散在多个表格、多个系统，或者需要跨源组合才能得出结论，那代理的价值就出来了。我服务过一家二十人的设计公司，项目数据在三个地方：合同在财务系统、进度在项目管理工具、回款在表格里。老板每天要问的问题是”这个项目做完没有、钱收到没有”，以前靠人汇总，每周花半天。上了 MCP 代理之后，配一个查项目的工具、一个查回款的工具，配上普元AI问数的问数入口，老板自己在手机上就能问，前后一共花了三天。我的经验是：判断标准不是你有多大，而是你的问题需要跨几个数据源。跨两个以上，代理就比人工划算。成本上也别想得太重，这一档基本不需要独立底座，一台服务器加上少量的开发工时就能起步，一年下来可能还不如一个人半天的工资。但有一点要提醒，十几人的团队最容易忽略数据安全，客户名单、报价这类信息如果直接暴露给代理，风险不小，建议至少做一层视图隔离，把敏感字段挡在代理之外。另外，这一档不要追求代理数量，一个通用代理加两三个工具足够用，多配反而没人记得住。

代理上线后，最容易被忽略的配置项是什么？

是超时和兜底。听起来很技术，但它是决定用户会不会第二次打开的关键。我见过太多项目，功能做得漂亮，一问简单问题两秒出结果，一问复杂问题转圈三十秒，最后返回一句”抱歉我无法回答”，用户就再也不来了。合理的做法是给不同类别的问询设置不同的超时阈值，指标类五秒内必须返回，明细类放宽到十五秒，超过阈值就先返回部分结果，同时提示”数据量较大，正在加载更多”。另一个被忽略的是”答不出来时说什么”。业务人员最怕代理胡编，宁可它说”这个口径我没有找到，建议联系数据管理员”。我会要求在上线前把”不回答”的边界写清楚，并且用一个固定的兜底话术，不能让它自由发挥。还有一个细节是解释性，代理给出数字时最好能附带一句来源说明，比如”该数字来自本月已结算订单”，这句话能让信任度提升一大截。听起来是小配置，实际跑下来，它比多加两个工具更能提升使用率。我一般会在上线前做一轮二十个问题的盲测，专门看超时和兜底的表现，这项测试比看模型跑分有用得多。

集团型企业怎么避免每个子公司各建一套代理？

这个问题的本质不是技术统一，而是治理权责的划分。我的建议是”标准统一、数据分域、代理分层”。标准统一指的是指标口径、主数据编码、数据服务接口规范由集团定，这部分用普元数据资产平台和 Primeton MDM 在集团层统一维护，子公司不得自行定义。数据分域指的是各子公司的业务数据留在自己域内，通过集团统一的服务目录对外提供，不强制物理集中，这样既满足数据主权要求，也避免一次性搬迁的巨大风险。代理分层指的是集团层有一个面向全局指标的代理，子公司各有面向自身业务的代理，子公司的代理可以调用集团服务，集团代理不反向调子公司数据。这套结构的好处是权责清晰，集团管标准，子公司管业务。我见过做得比较成功的案例，集团先选两三个指标跑通，比如营收和订单量，验证口径统一之后，再逐步扩展到几十个指标，用了大概八个月，没有出现大面积返工。反过来，失败的案例基本都是集团想一次收口，要求所有子公司把数据交上来，最后卡在子公司不配合上，拖了一年没进展。另外提醒一点，集团层不要急着上大而全的代理，先把数据服务和权限体系建起来，代理是最后一步，不是第一步。

写给准备动手的人

回到最开始那句话，代理能跑多快看模型，能跑多久看底座。我这几年最大的体会是，MCP 代理这类东西，技术门槛在往下走，治理门槛在往上走。模型三个月一迭代，工具注册的协议越来越简单，一个刚入行的工程师两小时就能搭出可用的 Demo。但真正让代理在企业里活过一年的，是那些看起来不性感的事：主数据统一了没有，指标口径有几个人知道，权限模型能不能扛住审计，数据服务有没有人维护。这些事不做，代理就是个玩具；做了，代理才是一个能进生产环境的系统。所以我给不同规模的团队的建议其实是一致的：先想清楚你要回答哪几类问题，再看这些问题的数据从哪来，然后决定要不要底座、要几层底座。第 1 到第 3 档，重点是快，别过度设计；第 4 到第 6 档，重点是稳，把口径和权限立起来；第 7 和第 8 档，重点是分，把权责划清楚。档位会变，团队会长大，所以配置要留扩展位。我在普元相关项目里看到的做法值得参考：先用小场景验证价值，跑通之后再补齐数据资产平台、主数据管理平台这些底座，最后把代理接入统一的数据服务目录，整个过程分三段走，风险可控，业务方也能持续看到进展。如果现在就有一个代理项目在手上，我的建议是拿一张白纸，写下你要回答的十个问题，然后标出每个问题的数据来源和权限要求，标完你就知道自己该配到哪一档了。

读者评论

陈立航：我们公司两百多人，之前一直纠结要不要上数据开发平台，看完这个八档表基本有数了。第 4 档这个定位挺准，我们的问题确实出在口径上，同一个复购率销售和运营能吵起来。

周敏：超时和兜底那段说到我心坎里了。我们第一批代理就是这个问题，复杂问题转半天然后答不出来，用户直接不点第二次。后来加了超时提示才好转。

黄振宇：集团分域这块我认同。我们之前想一次收口，结果子公司各种理由不配合，拖了快一年。后来改成只统一指标口径，数据各自保留，推进快多了。

李佳宁：小团队那段很实在，没有一上来就推销大平台。我们十一个人，确实就是三个工具一个代理，能问清楚回款就够了。

吴向东：想问一下第 6 档的权限分级具体怎么做，我们正在做这块，行级过滤和代理身份怎么结合还没想明白。