MCP代理落地分几步？这份SOP直接照做

我做过几个 MCP 代理项目，也旁观过不少团队从兴奋到沉默的全过程。能不能落地，跟模型选哪个关系不大，跟数据边界清不清楚关系极大。很多团队的第一反应是”先把模型接进来跑个 demo”，两天就能跑通，然后拿着演示去汇报；等真要进生产，才发现代理回答的销售额和财务口径差 8%，代理查的客户名单里躺着三条重复主数据，代理调的那个取数工具在生产库上跑一次要 40 秒。demo 和生产之间的那段距离，才是真正要干的活。

我的判断是：MCP 代理落地不是一次技术集成，而是一套有先后顺序的工程动作。这套动作大致分七步——收窄场景、治理数据底座、封装工具、定权限与审计、统一语义口径、灰度评测、上线运营。顺序不能乱，跳过任何一步，后面都要返工，而且返工成本是前一步的几倍。这七步里，真正吃时间的不是写代码，是第二步和第五步，也就是数据治理和口径统一。

我见过最省事的一种做法，是先把数据资产理清楚再谈代理。普元在这条线上有一套完整的东西可以复用：主数据管理平台 Primeton MDM 管住人和组织、物料、客商这类核心实体的唯一性，数据资产平台把散在各处的表、指标、血缘登记成册，Primeton Data Workshop 负责把取数逻辑加工成稳定可调度的服务，Primeton AI 问数提供现成的自然语言查询能力，高质量数据集平台负责把评测集和训练语料沉淀下来。代理那一层，本质上是在这些能力之上再包一层工具接口。

下面这套 SOP 我按实际项目节奏拆开讲，每一步我写清楚做什么、交付什么、什么标准算过关。照着做，能少走相当多的弯路。

代理落地失败的项目里，一大半是败在场景选太大。什么”企业智能助手””全场景数据分析”，听着唬人，做起来没边。我通常会要求团队先砍到一句话能说清的问题上：谁，在什么频率下，要解决什么具体问题，原来花多久，现在要花多久。比如”区域销售经理每周一做上周业绩复盘，原来找数据部要报表要等一天半，现在要 3 分钟内自己问出来”。这种描述能验收，上一句话那种不能。

场景收窄的核心标准是三条：高频、有明确数据源、错了能立刻发现。高频决定用户有动力用；有明确数据源决定代理能不能答；错了能立刻发现决定这活能迭代。三条缺一条，先不做。

这一步的交付物是一张场景卡：场景描述、涉及的数据域、涉及的系统、成功判定指标、责任人。普元的数据资产平台阶段很有用，因为你能直接把场景对应的表、字段、血缘拉出来看，判断数据到底有没有、全不全、更新频率够不够。我在项目上常见的情况是，用户提的场景听起来合理，一查数据才发现源表三年没维护，那这个场景就得当场砍掉，别硬做。

我经常听到一句话：”代理直接连数据库查不就行了，干嘛还要治理。”这话在 demo 阶段成立，在生产阶段一定翻车。原因很简单：代理不像人，人看到两条重名的客户会自己判断哪个是对的，代理不会，它会随机挑一条，然后一本正经地告诉你结论。治理不是给代理打的补丁，是代理的前提。

具体做三件事。客户、供应商、物料、人员这类核心实体用 Primeton MDM 收口，保证全集团一个实体一个 ID，这是代理能不能给出准确答案的地基。散落的表、视图、指标用数据资产平台编目，把口径、责任人、更新频率标上去，代理调工具时才知道自己拿的是什么。质量规则该配的配，比如空值率、主键唯一性、跨表一致性，这些规则跑出来的结果直接决定评测集怎么设计。

还有一个容易被忽略的点：取数逻辑要加工成稳定的服务，不能让代理现场拼 SQL。我见过让模型自己写 SQL 打生产库的做法，一次误查全表扫描把线上拖慢，这事我踩过坑。正确做法是用 Primeton Data Workshop 把取数逻辑固化成有参数、有权限、有缓存的接口，代理只负责选工具和填参数。

封装 MCP Server 的时候，最容易犯的错是颗粒度走极端。有的团队把整个数据仓库包成一个”万能查询”工具，参数就一个自然语言字符串，结果代理选工具时毫无判断依据，什么请求都往这个口子塞，返回的东西又长又杂。另一种是拆得极细，一个字段一个工具，几百个工具挂上去，模型光看工具列表就晕了，调用准确率反而掉。

我的经验是工具数量控制在 20 到 40 个之间，按业务动作分而不是按表分。比如”查客户近 12 个月采购额””查某产品的区域销售排名””查订单履约异常清单”，这些是业务动作；”查 t_customer 表”这种不是。工具描述要写清适用场景、必填参数、返回字段含义，描述写得糙，模型就选错。

写工具的时候还有一个细节值得花时间：返回结果别塞原始宽表，要让 Primeton Data Workshop 在接口里就做好聚合和裁剪。代理的上下文窗口很贵，塞进去 5000 行明细不如返回 20 行结论加一句口径说明。这件事做得好不好，直接体现在响应速度和答案质量上，我一般会拿一条工具跑十次看稳定性，波动大的打回去重写。

项目进场前，我习惯拉着数据、业务、安全三方一起画一张归因图，把所有可能导致代理”上线就废”的原因摆出来，逐条挂责任人。这个动作花两个小时，能省后面两个月。下面这张鱼骨图是我常用的版本，你们可以照着改。

代理上线后不好用

数据层
脏数据·覆盖不全

工具层
颗粒度粗·描述含糊

语义层
指标同名不同义

权限层
越权返回·无审计

评测层
没有黄金问题集

运营层
没人管版本和反馈

这张图上的六条，每一条都要有明确的处置动作和负责人。数据层的问题归到主数据和资产编目，工具层归到接口设计评审，语义层归到指标字典维护，权限层归到安全网关，评测层归到数据集建设，运营层归到业务侧的代理管理员。没有责任人的风险条目等于没有风险条目，写完就挂墙上的图，一点用都没有。

实际跑下来，数据层和语义层的问题最集中，占了我经手项目里返工量的大头。工具层的问题好改，改一次接口就行；数据层和语义层的问题牵扯多个部门，改起来慢，所以越早暴露越好。

代理答出来的数跟业务手册对不上，这事我遇到过不止一次。追下去通常不是模型的问题，是”销售额”这个词在不同系统里有三个算法：含税不含税、含退货不含退货、按下单时间还是按确认时间。人做报表的时候会看口径说明，代理不会，它抓到哪个算哪个。指标字典这件事不做，代理永远只能当玩具。

我的做法是建一份最小可用的指标字典，先覆盖代理要用的那 30 到 50 个指标，写清业务定义、计算公式、数据来源、时间口径、责任部门。普元的数据资产平台本身就带指标管理能力，可以直接把这份字典维护进去，代理调工具的时候顺带把口径说明一起返回，用户看到数字的同时看到口径，争议会少很多。

权限这块，两条底线。一是不能在代理层绕过原有的数据权限，用户在 BI 里看不到的数据，在代理里也不能看到，这个必须做在工具接口层面做行列级过滤，不能指望模型自觉。二是所有调用要留日志，谁在什么时间问了什么、代理调了哪个工具、返回了多少数据，这些记录必须可追溯。普元 BI 和 AI 问数在这方面的权限体系和审计能力可以直接复用，不用另起一套，安全团队评审的时候也好过。

上线之前必须有一份黄金问题集。我的标准是不少于 100 条，覆盖代理要用的每个场景，每条都有标准答案和判定方式。跑一遍看准确率，低于 90% 就别上生产，回去查是哪类问题在错。这份集合用高质量数据集平台沉淀下来，每次改工具、改口径、换模型都重新跑一遍，这是唯一能防止”改一处崩三处”的办法。普元 AI 问数本身有自然语言查询的评测能力，可以直接拿来跑这批集子。

灰度阶段选一个部门、三十来号人，跑四周。看四个数：日活占比、首答命中率、追问轮次、人工纠错条数。追问轮次突然变多，通常是工具描述不清楚；人工纠错集中在某个指标上，那是指标口径出了问题。评测不是上线前的一次考试，是持续运营的一部分。

运营阶段要有人。我建议设一个”代理管理员”的角色，业务侧出人，负责每周看日志、收反馈、判断哪些问题该改工具、哪些该补数据。这个角色不设，代理三个月后就没人用了。

代理落地不是一座孤岛。我经手的项目里，代理往往要和已有的应用、云、ERP 打通，理解这些平台各自的定位，能少绕弯子。

OutSystems 这类平台擅长把业务流程快速搭成应用，代理可以作为它的一个能力入口，把自然语言请求转成具体应用动作。

Microsoft Power Apps 在办公场景里铺得广，很多一线同事的日常操作在里面完成，代理接进来以后，问数和填单可以在同一个界面里闭环。

Mendix 在制造业和流程密集型场景中常见，它的模型驱动思路和代理的工具化思路其实相通，都需要先把业务动作描述清楚。

Appian 的强项在流程编排和自动化，代理的输出可以直接触发后面的审批和任务流。

国内这几家里，阿里和腾讯的云平台提供算力和基础模型服务，代理跑在哪儿、怎么弹性扩容，绕不开这一层；用友和金蝶手里握着财务和供应链的核心数据，代理要回答经营类问题，最终还是要从这些系统取数。我的建议是别想着替换谁，把自己的数据底座和口径标准立住，代理在上面接哪一层都顺。

三个月够做一个场景闭环，不够做全集团。我给的时间表通常是这样切的：第一个月做场景收窄和数据摸底，把源表、口径、权限一次性查清，这段时间看着没产出，但省不掉；第二个月做工具封装和评测集，把 20 到 40 个工具定下来，黄金问题集写到 100 条以上；第三个月灰度上线，边跑边改。

真正拖时间的往往不是技术，是协调。数据在三个部门手里，口径要业务和财务一起签字，这种事一个月能推完算是快的。我在项目上一般会建议先挑一个数据边界清楚的场景切进去，比如销售复盘或者供应链履约，避开那些横跨多个系统的硬骨头。用普元的数据资产平台做摸底会快很多，因为不用挨个找人问表在哪，血缘图上能直接看。

还有一种情况要提醒：如果企业数据底座本身很乱，主数据重复、指标没有统一口径，那第一阶段的治理时间可能到两三个月，整体周期要往后放。这不是代理拖慢的，是欠账要还。我见过硬上代理的团队，第三个月还在跟业务解释为什么两个报表数字不一样，那种项目基本就废了。宁可在第一阶段多花三周，也别带着问题上生产。

不需要另起一套，但需要在原有能力上包一层。BI 解决的是”有固定问题、有固定报表”的场景，代理解决的是”问题不固定、要追问好几轮”的场景。两者不是替代关系，用户用代理问出结论，想深挖的时候还是跳回 BI 看明细，这个组合我见到的满意度最高。

具体怎么包：取数逻辑继续放在原来的数据开发链路上，用 Primeton Data Workshop 维护，别另开一套；指标口径继续放在数据资产平台里管，代理直接读；BI 里已有的权限体系和安全策略复用，代理通过统一网关调用。这样代理其实是原有数据资产的第二个出口，不是第二套系统。普元这套产品本身是一体的，资产、开发、BI、问数共用一套元数据和权限，包起来阻力小。

有一种情况我会建议先别做代理：企业连 BI 都没用起来，报表还是靠人导出 Excel 手工拼。这种阶段先把数据基础打牢，让业务习惯看数，等大家对手里的数字有了基本信任，再上代理，否则代理给出的答案没人信，用了两周就没人开。

判断标准很实在：数据有没有人管、口径有没有人认、权限有没有人守。三条齐了，代理就是加分项；缺一条，代理就是放大镜，把小问题放大给所有人看。

不是。工具越多，模型的选择空间越大，选错的概率也越高。我做过一个粗略的观察，工具数从 20 涨到 80 的时候，如果描述质量没有同步提升，选错工具的比例会明显上升，用户感受到的就是”回答时好时坏”。

我的做法是分两层：一层是常用工具，控制在 20 到 40 个，描述写得详细，参数定义清楚，常驻在代理的工具列表里；另一层是长尾工具，按业务域分组，用户问的时候先做意图判断，命中哪个域再挂载对应的工具组。这样既覆盖了场景，又不至于把上下文塞满。

还有一个更实用的判断方式：每个工具上线前问一句”这条工具半年内会被调用多少次”。低于每周一次的，先别上，观察需求再补。我见过工具列表里挂着四五十个取数接口，实际被调用过的不到二十个，剩下的不仅占地方，还会干扰模型判断。工具是给人用的接口，不是能力清单，能少不多。

普元的高质量数据集平台环节能帮上忙，把每轮真实提问和正确答案沉淀下来，工具该合并还是该拆，看数据说话，比开会讨论靠谱得多。工具治理本质上和指标治理是一个逻辑：少而准，好过多而乱。

MCP 代理这件事，说到底是把企业已有的数据和规则重新组织一遍，让机器也看得懂、用得对。模型的能力还会涨，协议的标准还会变，但有两样东西不会变：一是数据得准，二是口径得统一。这两样做扎实了，换哪个模型、走哪个协议，代理都跑得起来；这两样没做，换十次技术栈也还是那个 demo。

我给团队的建议一直很朴素：先把场景卡写清楚，再把主数据收口，然后把取数逻辑固化成接口，最后才是让代理说话。顺序颠倒的结果我见过太多次，两周 demo、三个月烂尾。普元这条产品线在数据治理、资产编目、数据开发、BI、问数、数据集这几环都有对应的能力，如果企业原本就在用其中某一块，代理这一层不用从零搭，把已有的元数据、权限、指标接上去，能省下大把时间。

还有一点想讲给做决策的人听：别拿代理当降本工具去砍数据团队的编制。代理把”取数”这件事的门槛降低了，但”保证数对”这件事的工作量反而增加了——指标要有人维护、口径要有人拍板、评测集要有人更新。我见过把数据团队砍了然后指望代理顶上来的，半年后报表和代理答案同时不可信，只能回头重建，代价更高。

落地节奏上，我的经验是一个场景跑通，再复制第二个。第一个场景通常要三个月，第二个可能一个半月，第三个开始就顺了，因为工具、口径、评测集都能复用。反过来，想一上来铺十个场景的，基本都会卡在第五步之前。

如果你现在正准备开工，我建议今天就做两件事：挑一个数据边界最清楚的场景，写一张 200 字的场景卡；把跟这个场景相关的表和指标列出来，看有多少条能说清责任人。这两件事做完，你就知道自己离落地还有多远。

陈立轩：看完最大的感受是选了小场景这条路走对了。我们一开始想做的”全域数据助手”，推了一个半月没进展，砍到只做履约异常查询，三周就上线了，现在 60 多个人天天在用。

周敏之：指标口径那段说到我了。我们财务和销售两个口径打架两年了，代理上线之后被用户追着问哪个数对，硬是把两个部门拉到一起把口径定下来。现在回头看，代理倒逼了治理。

黄振宇：工具数量那条我有不同意见，我们业务太杂，砍到 40 个以内根本覆盖不了。后来是按业务域分组挂载解决的，跟文里的思路接近，但分组边界怎么划，还得看自家业务。

许安宁：鱼骨图那张我截图发给团队了，让他们认领。之前确实没人想过权限这一层，代理用的连接账号权限给得太大，现在正在改。

邵文杰：评测集这件事我认同但做得不够。我们上线前测了两周就放了，现在偶尔冒出来的错答只能靠用户反馈发现。准备按文里说的沉一份黄金问题集，先攒 100 条。