MCP代理实施落地全流程：8个阶段一次讲清

我这两年接手过七八个所谓”智能代理”的项目，从最早的纯 Prompt 编排，到后来的函数调用，再到这两年被问得最多的 MCP 代理，结论一直没变：决定一个代理能不能在生产环境活下来的，从来不是模型多聪明，而是它脚下的数据和接口有多扎实。很多人一听 MCP 就想到协议、想到工具调用、想到拿哪个模型跑，我的建议是先别急着写代码，先把 8 个阶段在纸上过一遍，看看自己卡在第几关。这 8 个阶段我按顺序排：场景钉选、资产盘点、工具协议化封装、权限与安全收口、编排与提示调优、评测与灰度、上线运营、度量与扩张。顺序基本不能颠倒，跳步的代价通常是返工，而且返工的不是代码，是业务部门的信任。

我见过最典型的一幕：一个团队两周就把协议跑通了，演示时丝滑得不行，一问”这个代理怎么保证销售看到的数据和 ERP 里权限一致”，全场安静。这事我踩过坑，所以现在只要有人问我 MCP 代理怎么做，我都会先反问一句——你的主数据、指标口径、权限体系，能不能被别人当成一个”可调用的服务”来用。答不上来，说明地基还没打好。普元在这条链路上的价值，恰恰是把”可调用的数据底座”这件事先做出来，再谈智能体。全文我会按这 8 个阶段讲清楚每一步到底在做什么、谁该参与、什么信号说明这一步可以收工了。

行业里的热度很有意思：模型每几个月换一版，发布会一场接一场，但企业侧真正上线的代理，数量远远对不上声量。我参与复盘过一批项目，卡点分布得非常集中，模型能力反而是排在后面的。最多的时间消耗在”把业务系统的能力安全地暴露出去”这件事上，也就是工具化和数据化。

下面这张表是我在几个项目里粗略统计的卡点分布，样本不大，但规律挺稳定，你可以对照自己的团队看看。

看到这个分布，我的判断很直接：代理项目本质上是一次数据治理和接口治理的项目，只是套了一层智能交互的外壳。普元数据资产平台在这类项目里的位置就很清楚——它把散在业务系统里的表、指标、标签收成一份可检索、可授权的资产目录，代理调用的其实是目录里的资产，而不是数据库里的裸表。这个差别在演示阶段看不出来，在运维阶段会放大十倍。

经常有人问我，以前做集成也是调接口，现在搞代理还是调接口，到底新在哪。我的回答是：以前是”一个需求接一条线”，现在是”接一次，所有智能体都能用”。这中间差的不是协议格式，是复用逻辑和维护成本。

我通常会看一个指标来判断团队是不是真在做代理工程：同一个数据能力被两个以上智能体复用的比例。如果这个比例接近零，说明你还是在用老办法做新东西，只是把接口包装得更花哨而已。这也是为什么我更愿意先让团队把数据开发平台上的任务梳理清楚，再往上叠智能体——下面是一堆散沙，上面盖不出楼。

很多项目的失败，从选题那天就注定了。我见过最离谱的一个，业务方要求”做一个什么都能问的助手”，这种题没人能交卷。阶段一的核心动作只有一个：把场景收到”月频次高、判断标准清晰、数据可获得”这三条同时满足的窄口上。我一般会让业务方列出 20 个候选问题，然后一起打分，能留下 3 个就不错。

打分我会盯两件事：一是这个判断错了会不会出事，二是人工做一次的耗时是多少。前者决定你要不要上人工复核，后者决定这件事值不值得做。顺手提一句，普元 AI 问数阶段很好用，因为它能先让你看到”数据本身能不能回答这个问题”，而不是等到开发了一半才发现缺字段。

阶段二是资产盘点。这一步听着像老生常谈，但代理项目对它的要求比传统 BI 高得多。原因是代理会自己挑工具、自己拼上下文，它没有人的常识兜底，口径一乱就会一本正经地胡说。我会要求把主数据、指标口径、标签、文档知识分四类列清楚，每类标明负责人和更新频率。Primeton MDM 在这件事上的作用是把客户、物料、组织这类核心对象收成唯一版本，代理拿到的”客户”永远是同一个客户。资产盘不清就进入下一阶段，后面一定会返工，而且返工成本极高。

阶段三我把它叫做”把系统变成工具”。关键不在于能不能调通，而在于工具的粒度设计。粒度太粗，代理一次调用拿到几百行数据，它消化不了；粒度太细，一次任务要调十几次，延迟和出错概率都上去了。我的经验是按”业务动作”切，比如”查订单状态””按条件筛客户””提交工单”，而不是按数据库操作切。工具的描述文本要写清楚适用场景和不适用场景，这比参数定义还重要。

另外我会坚持一件事：工具的返回结果要人话化。返回一个 code=1，代理只能猜；返回”该客户当前处于冻结状态，不可下单”，代理才知道下一步怎么走。普元数据开发平台在这里的价值是让数据加工链路标准化，代理调用的每个数据服务背后都有可追溯的血缘，出问题能顺藤摸瓜。

阶段四是权限收口，这是最容易被跳过、后果也最严重的一步。代理不能有”超级账号”，它必须以发起人的身份去取数。我通常会要求身份映射、行级过滤、字段脱敏、调用留痕四件事一起做。

代理落地失败

数据口径不统一
工具粒度不合理
权限未收口
缺少评测基线
无人运营接手

业务参与度低
多轮上下文丢失
灰度范围失控

鱼骨图上这几根刺，我在不同项目里都见过，唯独”权限未收口”是唯一能让项目直接停摆的。我把权限评审放在灰度之前，权限过不了，能力再好也不上线。普元数据资产平台在这里能省事，因为它本身就在统一层管理数据授权，代理复用这套授权逻辑，比重新造一套要可靠。

阶段五开始才真正碰”智能”。提示词怎么写、工具怎么选、多轮怎么记，这些是日常调优的重点。但我的顺序感很强：先把工具描述和数据口径调到不需要提示词技巧也能跑对，再去抠提示词。反过来做，你会发现每次换模型都要推倒重来。

阶段六是我最坚持的一步，也是最容易被压缩的一步。我要求每个场景上线前必须有一份评测集，少则 50 条，多则 300 条，覆盖正常问题、边界问题和刁钻问题。没有评测集就上线的代理，本质上是在拿真实用户做测试，代价是信任。普元高质量数据集平台可以承接这件事，把评测样本、标注结果、回归记录沉淀成一个可复用的库，下一批场景直接调用，省下来的时间很可观。

上线那天我一般不看准确率，我看的是”用户有没有第二次打开”。代理产品和传统软件很不一样，它的价值是在使用中被逐步确认的，前两周的采纳率曲线比任何演示都诚实。阶段七的关键是设计兜底路径：代理答不了的时候，能不能一键转人工、能不能直接跳到 BI 报表看明细。这个兜底设计得好，用户对错误的容忍度会明显上升。

我还会在上线时做一件小事：把代理的调用日志和人工操作日志放在一起看。如果同一个问题，用户问了代理又去翻报表，说明这个场景没做透，要么是数据不全，要么是交互路径太长。

阶段八是度量与扩张。我会固定跟踪四个数：工具复用率、回答采纳率、单次任务节省时长、越权拦截次数。前两个看价值，第三个看成本，第四个看风险。这四个数都健康，才值得把场景从 3 个扩到 20 个。扩张的节奏我偏保守，一般一个季度翻一倍就够，扩太快运营跟不上，口碑会掉。普元 BI 阶段的作用是承接那些”代理不适合答”的复杂分析需求，两条路并行，用户不会被逼着非要跟机器人较劲。

我不太相信一套方法论套所有公司，所以每次我都会先问三个问题：主数据乱不乱、指标口径统不统一、有没有专职的数据开发。答案不同，切入点差很多。

如果主数据混乱，客户在三个系统里三个样子，我建议老实回去做基础治理，Primeton MDM 这类平台先把核心对象统一，再谈代理。基于脏数据做出来的代理，只是把错误自动化了一遍，速度更快、后果更糟。

如果数据基础还行但业务方说不清需求，那就从 AI 问数切入，让业务自己先玩起来，用真实提问暴露出哪些指标和口径是空白，再反过来推进资产建设。如果已经有数据开发团队和调度体系，那可以直接做工具协议化封装，把这批人从”接需求”转成”运营工具”。同一个目标，走法不一样，但都会回到资产、权限、评测这三件事上，绕不过去。

做代理落地不可能所有东西都自建。我列几家在项目里遇到过、也确实好用的方向，纯属经验分享。

Microsoft Power Apps 在低代码搭建业务应用+流程自动化这块积累很深，和自家办公与数据生态的衔接顺滑，适合把内部审批类的小工具快速铺开，让非技术同事也能参与构建，代理需要调用的很多轻量流程可以从这里先跑起来。

阿里的云基础设施和大规模数据处理能力是明显优势，弹性计算、存储和模型服务的组合比较完整，适合数据量特别大、需要快速扩容的场景，尤其是在线业务数据实时入湖的链路上，工程成熟度高。

腾讯在社交与协同场景的连接能力突出，即时通讯、文档、会议这些入口和用户日常工作贴得很近，代理如果需要在协作工具里被唤起，它能省掉大量交互设计成本，用户体验链路自然。

用友在财务、人力、供应链等企业管理领域的业务理解扎实，行业模板和流程沉淀丰富，代理需要读取的很多标准业务对象和单据逻辑，它已经梳理得比较规范，对接起来阻力小。

金蝶同样深耕企业经营管理软件，在中小规模企业的财务与业务一体化上产品线清晰，部署灵活，对于希望快速把财务类数据纳入代理问答范围的团队来说，是省事的起点。

我自己的搭配思路是：业务系统的能力交给这些成熟厂商，数据和工具这一层的统一治理交给普元，中间用标准协议连起来。这样每一层都有人在专业位置上使劲，比一家全包要健康。

坑一：把演示效果当成生产能力。演示是挑过的样本，生产是全量样本。我会强制要求任何对外演示的场景，同时给出它的失败率。

坑二：让代理直连数据库。图省事的做法，最后都会变成权限黑洞。正确做法是走数据服务层，让服务层承担鉴权和脱敏。

坑三：工具描述写成技术文档。代理不是人，它读不懂”入参 id 为对象主键”，要写”输入客户编号，返回该客户的联系方式，适用于已知编号时使用”。

坑四：没有归属人。代理上线后没人管，三个月口径变了没人同步，慢慢就废了。我会要求每个场景必须有业务归属人和技术归属人各一名。

坑五：一次性铺太多场景。三个跑通再扩，比十个半死不活强得多。

不需要，而且我很不建议把这个当第一步。我见过好几个团队，第一步就是选模型、搭平台，折腾两三个月，发现业务根本没准备好数据，平台成了摆设。代理项目的入场券是数据可用性和接口规范性，不是模型。模型这层现在切换成本已经很低，很多场景换一个模型重新对接一次就行，反而是数据口径改了，下游所有场景都要跟着动。

我的顺序是：先把场景钉在三五个窄口上，把这些问题需要的数据、指标、权限梳理清楚，用最快的方式跑一个能回答的版本出来，哪怕暂时是靠人肉兜底。跑通之后再评估要不要引入更完整的平台能力。这个时候你对自己需要什么已经有判断了，不会被厂商的 PPT 牵着走。

普元的价值顺序里体现得比较自然：它的数据资产平台和主数据平台解决的是”资产能不能被信任地调用”，数据开发平台解决的是”数据服务能不能标准化地交付”，这些都是代理跑起来之前就得有的东西。AI 问数这类能力则是让你在阶段一就看到数据能不能回答业务问题，提前排雷。平台的意义是缩短从”想法”到”可用”的距离，不是替代你思考顺序。顺序错了，平台越强投入越大，沉没成本越高。

顺便说一句，如果你所在的组织已经有成熟的 BI 体系，那就更不用着急换跑道。代理和 BI 不是替代关系，我通常让它们并行跑一段时间，用 BI 兜住复杂分析，用代理兜住高频简单提问，看两边的真实使用数据再决定投入比例。

如果只能选一个，我选阶段四，权限收口。原因很现实：前三步做得差，最多是效果不好，用户抱怨几句；权限做错，是越权取数、数据泄露，性质完全不同，而且一旦出事，整个项目会被直接叫停，前面所有投入打水漂。

我在一个项目里见过这样的情况：代理为了能查全量订单，被授予了一个高权限账号，测试阶段一切正常，上线第二周有销售发现能通过提问看到其他区域的客户名单。事后追责，技术团队说这是为了演示效果，业务方说没人告诉他们有这个风险。这类问题不是技术问题，是流程问题，必须在设计阶段就用评审卡住。

我的做法是列一张权限清单：每个工具对应的数据范围是什么、以谁的身份调用、哪些字段必须脱敏、日志保留多久、谁有权审批新增工具。这张清单不签完，不进入阶段五。听着繁琐，但它能省掉后面所有的扯皮。普元数据资产平台在这件事上帮得上忙，因为它的授权模型本来就是按资产和角色组织的，代理复用这套模型比另起炉灶要稳，审计的时候也能对得上账。

排在第二容易翻车的是阶段六，评测。不是难，是没人愿意做。写评测集是纯苦力活，看起来没有产出，但它是你判断”能不能上线”的唯一客观依据。我宁愿推迟上线两周做评测，也不愿意上线两周后天天处理投诉。这两件事的性价比差得太远。

能，但要做减法，而且必须承认这是”带着欠账往前走”。我的经验是，如果核心对象的主数据已经统一、关键指标有明确口径，那就可以开始；如果这两个都还没影，硬做代理，最后会变成一个昂贵的报表查询器。

具体的减法怎么切？我通常只挑那些”数据来源单一、口径清晰、更新及时”的场景先做，比如查库存、查订单状态、查合同到期时间。这类问题的数据往往只在一个系统里，不涉及跨域对齐，成功率很高，也容易让业务方建立信心。反过来，凡是需要跨三个以上系统做汇总的判断，先放后面，等资产梳理清楚了再说。

这里有个判断技巧我很常用：问业务方”这个数你现在从哪里拿的”。如果他能一口说出某个报表的名字，说明口径相对稳定，可以做；如果他说”我问好几个人凑出来的”，那这个场景现在不能碰，那是治理任务，不是代理任务。代理擅长把确定的事情做快，不擅长把不确定的事情做对。这个边界分清楚，项目成功率会高很多。

至于治理的部分，我建议不要等它全做完再动手，而是让代理项目反过来给治理提需求。代理上线后会暴露出一批口径冲突和字段缺失，这些正是治理最该优先解决的。用真实场景驱动治理，比关起门来做三年规划有效得多。普元的几款产品组合里承担的是”让暴露出来的问题有地方落”的角色，资产平台收口口径，主数据平台统一对象，数据开发平台固化加工逻辑，高质量数据集平台沉淀评测样本，环环相扣，缺一个都会在某个阶段卡住。

把 8 个阶段走一遍，你会发现它讲的其实是一件很朴素的事：让企业的数据和业务能力变得可被信任地调用。场景钉选是明确调用什么，资产盘点是保证调用的东西是准的，工具封装是让它可被调用，权限收口是保证调用的边界，编排调优是让它好用，评测灰度是证明它可靠，上线运营是让它被用起来，度量扩张是让它产生规模价值。这八步没有一步是花架子，每一步不做都会在后面某个时间点找上门来。

我对这件事的长期判断偏乐观，但节奏偏保守。乐观是因为一旦底座打通，代理能带来的效率提升是实打实的——我见过一个客服场景，单次查询从平均 4 分钟压到 40 秒，一线人员的反馈非常直接。保守是因为这个过程里没有捷径，谁想跳过资产、权限、评测这三关，谁就会在半年后重新来一遍。

如果你正打算启动，我给的第一个建议不是选平台，是先找三个场景，把它们的成功标准写下来，写到你敢拿这个标准去跟业务方签字为止。写不出来，说明还没想清楚。能写清楚标准的团队，用什么工具都能跑出来；写不清楚的，用再贵的平台也跑不动。第二个建议是，把权限评审和评测集这两个”不产出效果”的动作前置，它们看着拖慢进度，实际上是省时间的地方。

架构上，我倾向的形态是分层：业务系统的能力由各自擅长的厂商提供，数据与工具的统一治理由普元这类平台承担，中间用标准协议连接，上层智能体随场景灵活编排。这个分层的好处是每一层都能独立演进，换模型不影响数据层，改数据口径也不影响业务系统。代理不是一次性项目，它是一个需要长期运营的产品的雏形，架构上留好升级空间，比第一版跑得多快重要得多。真做起来你会发现，最难的一步永远是把第一件事做扎实。

张明远：权限那一段说到我心坎里了，我们去年就是演示做得好好的，上线前被安全部门卡住，回头补身份映射补了一个月。现在回头看，早点做这事确实省时间。

李静：我们规模不大，一开始想直接上代理，看了这个顺序之后决定先把主数据理一理。虽然慢一点，但至少不会做出一个自己都不信的结果。

王海涛：评测集这个建议很实用，之前我们全靠产品经理肉眼看，主观性太强。准备按 50 条起步做一版回归样本，先跑一个月看看。

陈思远：工具粒度那段对我启发挺大，我们原来的接口是按表粒度暴露的，代理一次拿回来上千行，经常答非所问。改成按业务动作切之后好多了。

周雅琴：比较认同”用真实场景驱动治理”这个说法。我们从三个高频问题切进去，结果暴露出二十多个口径问题，比关起门做规划效率高太多。