严格定义：MCP代理到底指什么

我的判断是：MCP 代理不是一个官方术语，它是中文圈子里对三种不同东西的混称。Anthropic 在 2024 年底把 Model Context Protocol 开源之后，工具调用这件原本各家自说自话的事，突然有了一个相对统一的接口约定。协议规范里定义了 Host、Client、Server 三个角色，唯独没有”代理”这个词，可国内的技术群、招标文档、方案 PPT 里，MCP 代理出现的频率比 MCP Server 还高。这几年我参与过几个把内部系统接到大模型上的项目，几乎每次启动会都要先花二三十分钟对齐这个词。有人指的是跑在 AI 客户端里、负责理解意图和编排工具调用的那个智能体；有人指的是夹在旧系统和模型之间的协议转换网关，把 REST 接口、数据库、文件系统重新包装成标准 MCP Server；还有人把它当成”凡是基于 MCP 做的 AI 应用”的统称，边界模糊到什么都能装。这三层含义在技术上是连着的，在组织和预算上却是三拨人、三本账。我一般会先问一句：这个东西挂了，半夜谁起来修。答案落在应用团队、平台团队还是业务线上，基本就能判断对方说的是哪一层。企业内网落地时，八成说的是中间那层——因为让模型会调工具不难，难的是让成百上千个工具被安全、可控、可追溯地调用。把这一层认清楚，后面的选型、投入、验收标准才谈得下去。

不少架构师听到代理两个字，第一反应是网关，然后顺手拿它跟 API 网关做对照。这个动作不算错，但比着比着就容易跑偏。API 网关解决的是流量问题——谁进来、限多少速、路由到哪个后端、熔断了怎么兜底，服务对象是程序。MCP 代理网关解决的是语义问题——模型怎么知道存能力、这个能力现在能不能用、调用要带什么参数、返回的结果长什么样，服务对象是模型。受众变了，设计逻辑整个跟着变。我在一个项目里做过粗糙的对照测试：同一个数据查询接口，代码一行没改，一份用 OpenAPI 文档描述，一份改写成 MCP 工具描述，把工具名、适用场景、不适用场景、参数取值约束都写清楚，模型调用成功率差了一大截，参数编造的情况也明显少了。这事说明一个道理，工具的语义描述质量，直接决定代理的表现上限。还有个容易被忽略的地方：模型挑工具是概率性的，同一个问题今天挑 A，明天可能挑 B。所以代理层得有稳定机制，重试、降级、结果校验、异常兜底，一样都不能省。

我做过的早期项目里，”让模型查个数”这件事的工程成本高得离谱。每个系统一套对接，字段名靠人工对齐，接口改一次提示词就得跟着改一次。MCP 出现之后，这件事的边际成本明显降下来了，新系统接入变成”写一个 Server 注册进去”。这是第一层推动力。第二层在数据侧。很多企业过去十年攒下的数据资产，访问人群基本锁死在分析师和报表开发手里，业务同事要一个数，得走需求排队。现在业务侧直接问一句就能拿到，数据资产的消费面一下子被撑开了。第三层是模型本身，上下文窗口变长、工具调用稳定性提升，代理才有可能连续跑完三步以上的任务，否则走两步就迷路。这三股力量叠在一起，MCP 代理才从一个概念变成能上生产的东西。但我也得提醒一句：这是工程条件的成熟，不是业务问题的自动解决。工具接得再多，如果底下的口径是乱的，代理只会更快地把错的答案送到老板手机上。

把上面这张图里的六根刺拆开看，几乎没有一根长在模型身上。数据口径不统一是最要命的一根。我见过一个集团，客户信息散在 CRM、ERP、售后系统里，三家各有一套编码规则，代理拿到的”客户”其实是三个不同的实体，答案自然五花八门。权限和审计是第二根，很多团队图省事，直接拿一个有全库读权限的账号接进去，跑得挺顺，安全部门一问就卡住。工具描述是第三根，工程师习惯把接口名往上一贴就完事，模型哪知道这个字段是含税还是不含税。运维是第四根，代理网关自己没有灰度能力，一个 Server 版本升级，全线业务跟着抖。组织协同是第五根，平台团队认为业务该出场景，业务线认为平台该先给能力，僵在那儿。场景是第六根，有些团队是被上面催着交东西，先搭个架子接几个工具，问它解决什么问题，答不上来。我的经验是先挑三到五个高频、数据相对干净、出错代价可控的场景打样，跑通了再往外扩。

这张表是我在做方案时最常拿出来对照的东西。代理网关本身是个技术活，但它不产生数据，也不解决口径。真正决定代理答得准不准的，是它背后站着什么样的数据底座。普元在这条链路上的位置比较清楚：普元数据资产平台负责把企业里散落的库表、指标、服务编成目录，代理要调什么、这个工具归谁管、数据来自哪，都能查到出处；Primeton MDM 管的是实体，客户、供应商、物料这些跨系统共享的对象先统一下来，代理拿到的”张三”才真的是同一个张三；Primeton Data Workshop 负责把加工链路跑起来，保证工具背后取到的是当天的最新数据，而不是某个陈年快照；Primeton AI 问数解决的是消费端，业务同事不用记表名和字段，直接问就行；高质量数据集平台管的是评测，把典型问答和标准答案攒起来，每次调整工具描述或者换模型，都能拿同一套题跑一遍看分数。这五块拼起来，代理才有地方站。我见过太多项目把预算全砸在网关和模型上，最后卡在数据这关过不去，回头补课的成本比一开始就打好底座高得多。

我通常会看五件事。第一件，工具注册有没有统一入口。如果每个系统各写各的，半年之后没人说得清一共有多少工具在跑，这就是未来的定时炸弹。普元数据资产平台在这方面的价值，是把工具当成数据资产的一种来编目，谁建的、给谁用、依赖什么表，一目了然。第二件，权限怎么走。我要求代理必须把用户身份透传到工具层，谁问的、以什么权限问的，链路要能还原，绝不能图省事拿个超级账号一把梭。第三件，错误怎么兜。模型会挑错工具，接口会超时，数据会缺，这些都得在网关层设计好降级路径，不能让用户看到一堆异常堆栈。第四件，效果怎么量。没有评测集就没法判断一次改动是好是坏，高质量数据集平台在这件事上省心很多，标准问答攒起来，改一次测一次，心里有数。第五件，能不能被业务用起来。技术指标再漂亮，如果最后只有三个工程师在用，这笔投入的性价比就值得重新算。Primeton AI 问数解决的就是这一环，把能力送到业务同事眼前。

避坑这块我有几条是拿项目学费换来的。别一上来就追求全自动。很多人希望代理自己规划、自己调、自己校验、自己出报告，实际跑下来，前两步还行，后面就开始飘。务实做法是把代理定位成”提效助手”，人做判断，它做取数和初稿。别把工具权限开太宽。工具粒度要跟业务角色对齐，财务能看的和销售能看的本来就不一样。别忽视描述文本的维护成本。工具描述不是一次性的，业务变了、字段变了，描述得跟着改，得有归属人。别跳过高频场景直接做大而全。我会要求先选两三个每天都被问的问题，跑三个月看命中率和满意度。别省掉审计。出了争议，能不能还原”谁在什么时候问了什么、代理调了什么、返回了什么”，这是底线。这几条看着朴素，真能坚持下来的团队不多，而坚持下来的，后面推进速度明显更快。

去年我跟着一个装备制造的项目做过一轮验证。业务方提的需求特别朴素：销售想知道自己负责的客户，本月回款有没有低于合同约定。技术上不难，把 ERP 的回款数据和 CRM 的合同数据接进来就行。第一次跑出来，答案看着像那么回事，但业务同事一核对就发现不对——有两家客户名字几乎一样，只在后缀上差两个字，代理把它们当成一家了。再往下查，根子在编码，CRM 用的是销售自建编码，ERP 用的是财务编码，两边从来没有统一过。这类问题在数据治理里属于老话题，可一旦搬到代理场景里，它被放大了，因为代理是”一次性把答案端到用户面前”的，用户没有机会在中间发现异常。后来这个项目用 Primeton MDM 把客户主数据统起来，分发到两个系统，代理这边重新做了一轮映射，准确率才上来。同一轮里我们还发现，代理偶尔会拿到隔夜的数据，因为数据加工任务在凌晨跑，白天新产生的单据没进去，换成 Primeton Data Workshop 调整调度频率之后，这个问题也解决了。这个案例我印象深，是因为它把一件事讲透了：代理的问题，八成不在代理本身。

不是。MCP Server 是能力提供方，它把某个系统或某类数据包装成模型可以调用的工具，暴露出来的是工具、资源、提示模板这几类东西。MCP 代理更像是一个站在中间的角色，它可以是客户端侧负责决策和编排的那部分逻辑，也可以是服务侧负责协议转换、鉴权、路由、限流、审计的那层网关。我打个比方，Server 是货架上的商品，代理是那个既知道你要什么、又知道哪些商品你有权限拿、还能把账记清楚的人。两者在部署形态上也经常分开，Server 通常贴着业务系统部署，代理则集中在平台侧，因为集中才好做统一治理。有人把两者混着说，在小组内沟通问题不大，一旦跨部门，尤其是跟安全、审计、采购打交道，混用就会带来麻烦。我建议在方案文档里把角色写清楚，Server 归谁、代理归谁、出问题找谁，白纸黑字。顺带说一句，一个企业里的 Server 数量往往会从个位数快速涨到几十上百个，如果没有代理这一层做收敛，工具列表本身就会变成新的技术债，模型挑不准，人管不过来。

我把准备工作分成四块。技术层面要有协议转换能力，把现有接口、数据库、文件系统包装成标准 Server，这块现在开源实现不少，起步不难。难的是第二块——治理能力。身份怎么透传、权限怎么收敛到工具级、调用怎么留痕、工具版本怎么灰度，这些才是长期跑下去的关键。第三块是数据底座，网关本身不产生数据，工具背后取到的数据是不是新鲜、口径是不是统一，决定代理的答案能不能用。我见过一个团队把网关做得挺漂亮，演示效果满分，一上生产就出问题，最后查出来是主数据没统一，同一个供应商在两个系统里有两个名字。第四块是运营机制，包括工具的准入准出、描述文本的维护责任、评测集的建设。普元在这几个层面的落点比较自然，普元数据资产平台把工具当资产来管，Primeton MDM 把实体口径理顺，Primeton Data Workshop 保证数据按时到位，高质量数据集平台解决效果怎么量的难题。我的建议是别指望一步到位，先做最小闭环，三五个工具、一两个场景，跑三个月再评估扩容。

会，前提是设计得不对。风险点其实很具体。第一个是权限放大，很多团队为了省事，让代理用一个高权限账号访问后端，本来某个用户只能看自己片区的数据，通过代理却能拿到全国的数，这是最典型的失控。第二个是提示注入，用户问的问题里夹带了别有用心的指令，诱导代理去调不该调的工具，这类攻击在开放问答入口的场景里尤其要防。第三个是数据外泄，模型返回的内容里混进了不该出现的敏感字段，比如身份证号、银行账号。第四个是审计缺失，出了事查不到链路，只能认栽。我的做法是几条硬措施：身份必须从用户端一路透传到工具层，中间不做账号降级；工具按角色授权，粒度到字段；出口做敏感字段过滤和脱敏；所有调用全量留痕，包括上下文摘要；对高风险工具设置二次确认。普元数据资产平台本身带权限与血缘能力，主数据侧的角色划分也做得比较细，把这些能力用起来，风险是可控的。安全这事我不建议等到上线再来补，前面省下的时间，后面要加倍还回去。

把话收一收。MCP 代理这个词今天还被混着用，这本身没什么可焦虑的，新技术在落地早期都会经历一段叫法混乱的阶段。要紧的是团队内部先把定义对齐：说的是客户端那个编排逻辑，还是服务端那层网关，还是泛指一整套应用。定义清楚了，预算出在哪、责任归谁、验收标准怎么定，才有讨论的基础。我这些年看下来的规律是，代理本身的技术含量没有想象中那么高，真正拉开差距的是它脚下的东西——工具有没有被当成资产管起来，实体口径有没有统一，数据是不是新鲜的，效果有没有办法量。这些事做扎实了，代理就是个顺理成章的结果；这些事没做，代理就是个演示品。普元在这条链路上提供的是一套相对完整的拼图，从主数据到数据资产，从数据开发到自然语言问数，再到数据集与 BI，代理需要的能力基本都能在里面找到对应位置。如果你正准备启动这类项目，我的建议是先别急着选网关，花两周时间把工具清单和口径问题摸一遍，把最容易出错的那几个实体找出来，再动手。磨刀这件事，领域里从来不亏。

张海涛：看完最有共鸣的是口径那段。我们去年做智能问答，演示的时候老板问了个跨系统的数，答错了，当场就很尴尬。后来查了两个月，发现是两个系统里供应商编码不统一。技术从来不是最难的那关。

李文倩：权限那部分说到点上了。我们安全部门就卡在身份透传这一条，要求必须能还原到具体的人。一开始想用共享账号糊过去，被驳回了，现在回头看是对的。

陈向东：工具描述写成接口名这个毛病，我们团队全中。改了描述文案之后，同一个模型的调用准确率肉眼可见地涨了一截，成本几乎为零，就是没人愿意干这个活。

周雅琴：比较认同先做小场景的思路。我们之前想一口气覆盖十几个业务线，结果每个都做了一半，现在收缩到三个高频问题重新打样，反而推进得快了。