数据分析这条线上AI 相关的东西这两年更新得太快快到什么程度我上个月刚把一套基于 MCP 的取数流程跑顺这个月就发现身边人已经在用 Skill 把同样的活儿封装成可复用模块了。MCP、Skill、Agent、Prompt 这四个词现在几乎每天都会在各种技术群里被提起但真正能把它们之间的关系讲清楚、并且落到数据分析场景里用起来的人其实并不多。很多人是四个词都听过但一问这四个到底谁管谁、什么时候该用哪个就卡壳了。这篇内容我打算把这四个概念彻底拆开讲一遍重点不是给你背定义而是讲清楚它们在数据分析工作流里各自扮演什么角色、边界在哪、怎么配合。不管你是刚接触 AI 工具的数据分析师还是已经在搭 Agent 流程的工程师看完应该都能对这套体系有一个能落地的认知。我会尽量用我自己踩过的坑和实际跑通的流程来说明而不是停留在概念层面。1. 先把四个概念摆到同一张桌子上1.1 为什么这四个词总是被混着用我观察到一个很普遍的现象很多人在讨论 AI 应用的时候会把 MCP、Skill、Agent、Prompt 当成四个并列的功能觉得它们是同一层级的东西选一个用就行。这个理解从根上就偏了。它们其实处在不同的抽象层级上解决的是完全不同的问题。打个比方如果把一个 AI 数据分析系统比作一家餐厅Prompt 是你给厨师的点菜单写清楚要什么菜、什么口味Agent 是那个能自己看单、自己决定先炒哪个菜、发现食材不够还会主动去冰箱找的后厨主管Skill 是厨师练熟的一套标准刀工或者一道招牌菜的做法可以反复调用MCP 则是连接厨房和外部供应商的那条标准化采购通道让厨房能稳定地拿到外面的食材。这四个东西不是替代关系而是协作关系。你不可能用 MCP 代替 Prompt也不可能用 Skill 取代 Agent它们各自负责一段。理解这一点后面所有的讨论才站得住脚。1.2 一张表看清四者的定位差异我把这四个概念的核心定位整理成了一张表方便你快速建立坐标系概念抽象层级核心职责典型形态数据分析场景举例Prompt指令层告诉模型要做什么、怎么做一段文本指令把这份销售数据按区域聚合输出环比Skill能力层封装一套可复用的标准操作函数/模块/脚本数据清洗 Skill、指标计算 SkillAgent调度层自主规划、决策、调用工具一个运行中的智能体自动完成取数-清洗-分析-出图全流程MCP连接层标准化对接外部工具和数据源协议服务端让 Agent 通过统一协议访问数据库这张表建议你存下来。我见过太多人把 Skill 和 Agent 搞混本质上就是没分清能力和调度这两个层级。Skill 是死的是被调用的Agent 是活的是主动调度的。一个 Agent 可以调用多个 Skill一个 Skill 也可以被多个 Agent 复用。1.3 从一次真实的数据分析任务看四者如何串起来光说定位还是抽象我拿一个具体任务走一遍。假设老板丢给你一句话帮我看看上个月华东区的销售为什么下滑了。如果只有 Prompt你会怎么做你手动把数据导出来然后写一段提示词让模型帮你分析。这个过程中取数是你做的清洗是你做的模型只负责最后那一段分析。Prompt 在这里的作用是表达需求。如果加上 Skill你可以把取华东区销售数据这个动作封装成一个 Skill把计算同比环比封装成另一个 Skill。下次再遇到类似需求直接调用就行不用每次重新写取数逻辑。如果再加上 Agent你只需要把老板那句话丢给 Agent它会自己判断需要先取数那就调用取数 Skill数据有缺失那就调用清洗 Skill算完指标发现异常它会自己决定要不要再下钻一层看明细。整个过程你不需要一步步指挥。而 MCP 在这里的作用是Agent 要取数得连数据库吧传统做法是每个数据源写一套对接代码数据库、API、文件系统各写各的。MCP 把这些对接方式标准化了Agent 通过统一的协议就能访问不同的数据源换一个数据源不用重写整套逻辑。这么一拆四个概念的关系就非常清楚了Prompt 是入口Skill 是积木Agent 是装配工MCP 是接口标准。2. Prompt 不只是会说话它是整个链路的起点2.1 Prompt 在数据分析场景里的真实分量很多人觉得 Prompt 就是跟 AI 聊天没什么技术含量。这个认知在数据分析场景里是要吃亏的。我做过对比同一个分析任务Prompt 写得好和写得差输出质量能差出一个量级。举个我自己的例子。早期我让模型帮我分析一份用户留存数据Prompt 就写了一句分析一下这份留存数据。结果模型给我输出了一堆正确的废话留存率有波动、建议关注用户流失、可以进一步分析。全是套话没有任何可执行的信息。后来我把 Prompt 改成这是一份 12 个月的用户留存数据按注册渠道分组。请计算每个渠道的次月留存率找出留存率低于 30% 的渠道并对比这些渠道在获客成本上的差异。输出格式用表格每个渠道一行。同样的模型输出直接变成了可用的分析结论。差别在哪差在我把任务边界、计算口径、筛选条件、输出格式这四件事说清楚了。Prompt 的本质不是说话而是精确地定义任务。2.2 一个高质量数据分析 Prompt 的拆解结构我现在写数据分析类 Prompt基本遵循一个固定结构你可以直接拿去用角色与背景告诉模型它是什么角色面对的是什么数据。比如你是一名电商数据分析师面前是一份订单明细表。任务目标明确要解决什么问题一句话说清。比如找出导致本月 GMV 下滑的主要品类。计算口径这是最容易被忽略但最关键的部分。GMV 是按支付时间还是下单时间算退款要不要扣口径不说清楚结果就是错的。约束条件时间范围、数据范围、排除项。比如排除测试订单时间范围是自然月。输出格式表格、JSON、还是分点结论。格式定死后续处理才方便。我踩过最大的坑就是计算口径没写清楚。有一次让模型算复购率它按同一用户下单两次以上算但业务方的定义是同一用户在不同月份下单。两个口径算出来的数字差了将近一倍差点在汇报上出洋相。从那以后我写任何涉及指标的 Prompt都会把口径单独列一段。2.3 Prompt 的常见失效场景与应对Prompt 不是万能的有些场景下它天然会失效你得提前知道。第一种是数据量超出上下文。你不可能把一张百万行的表塞进 Prompt 里模型根本处理不了。这时候 Prompt 的作用就退化成描述任务真正的计算得交给 Skill 或者代码。第二种是需要多步推理的任务。你让模型一步到位完成取数-清洗-建模-出图它很容易在中途跑偏。这时候应该把任务拆成多个 Prompt或者直接上 Agent 来调度。第三种是需要实时数据的任务。Prompt 本身不连接任何数据源它只能处理你喂给它的内容。要拿实时数据就得靠 MCP 这类连接层。我一般的判断标准是如果任务能用一段话说清楚、数据量在可控范围内、不需要多步决策那就用 Prompt否则就该考虑往上叠加 Skill 或 Agent 了。3. Skill把重复劳动变成可复用的积木3.1 Skill 到底解决了什么痛点做数据分析的人应该都有体会日常工作中大量时间花在重复劳动上。每个月都要取同样的几张表每次都要做同样的清洗步骤每个季度都要算同样的那套指标。这些活儿不难但特别耗时间而且容易出错。Skill 就是冲着这个痛点来的。它把一套固定的操作流程封装成一个可复用的单元下次遇到同样的需求直接调用不用重新写一遍。你可以把它理解成数据分析领域的函数——你写一次到处调用。我自己的做法是把日常最高频的几个操作都封装成了 Skill一个是标准取数 Skill固定了几个常用数据源的取数逻辑一个是数据清洗 Skill处理缺失值、异常值、格式统一这些常规操作还有一个是指标计算 Skill把公司内部定义的几十个核心指标的计算逻辑固化下来。封装完之后效率提升非常明显。以前做一份月度分析报告光取数和清洗就要花大半天现在调用 Skill十几分钟就能拿到干净的数据剩下的时间全用来做真正的分析。3.2 Skill 的封装粒度怎么把握封装 Skill 最容易犯的错是粒度不对。粒度太粗一个 Skill 干太多事复用性差粒度太细Skill 数量爆炸管理成本高。我的经验是按一个完整的、有明确输入输出的操作单元来封装。判断标准很简单如果这个操作你能用一句话描述清楚它的输入和输出那它就是一个合适的 Skill 粒度。比如清洗数据这个粒度就太粗了因为清洗包含太多步骤不同场景清洗逻辑还不一样。但填充数值型字段的缺失值为中位数这个粒度就刚好输入是一列数据输出是填充后的数据逻辑清晰复用性强。再比如计算指标太粗计算次月留存率就合适。前者是个筐什么都往里装后者边界清晰谁都能看懂它是干什么的。我一般会把 Skill 分成三层最底层是原子操作 Skill比如去重、填充、格式转换中间层是业务操作 Skill比如计算某个指标最上层是流程 Skill把多个操作串起来完成一个完整任务。这样分层之后复用和维护都方便很多。3.3 一个数据清洗 Skill 的落地示例光说理论没意思我拿一个实际的数据清洗 Skill 来说明。假设我们经常要处理从业务系统导出的订单数据里面常见的脏数据包括金额字段有负数、时间字段格式不统一、用户 ID 有重复。这个 Skill 的逻辑大概是这样def clean_order_data(df): # 1. 金额字段剔除负数异常大值标记 df df[df[amount] 0] df[amount_flag] df[amount] df[amount].quantile(0.99) # 2. 时间字段统一转为标准格式 df[order_time] pd.to_datetime(df[order_time], errorscoerce) df df.dropna(subset[order_time]) # 3. 用户 ID去重保留最新记录 df df.sort_values(order_time).drop_duplicates(user_id, keeplast) return df这个 Skill 封装好之后任何一份订单数据进来调用一下就能得到干净的结果。注意我在里面加了amount_flag这个标记字段而不是直接删掉异常值——因为异常值有时候恰恰是业务上需要关注的点直接删掉可能丢失信息。这个细节是我踩过坑之后加的早期直接删异常值结果漏掉了一批大额异常订单后来被业务方追问才发现。提示封装 Skill 时尽量保留原始信息用标记字段代替直接删除。数据分析里为什么异常往往比异常本身更有价值。4. Agent从你指挥它到它自己干4.1 Agent 和普通脚本的本质区别很多人第一次接触 Agent会觉得这不就是个自动化脚本吗。表面上看确实像都是自动完成一系列操作。但本质区别在于脚本的流程是你写死的Agent 的流程是它自己决定的。脚本是这样的第一步取数第二步清洗第三步计算第四步出图。每一步都是你预先定义好的数据变了、需求变了脚本就得改。Agent 是这样的你告诉它分析一下销售下滑的原因它自己判断需要哪些数据、该调用哪些 Skill、发现异常该不该下钻、结果不理想该不该换个角度再试。流程是动态生成的不是写死的。这个区别在数据分析场景里特别重要。因为真实的分析需求往往是模糊的、变化的你不可能预先穷举所有情况。Agent 的价值就在于它能应对这种不确定性。4.2 Agent 的核心能力拆解一个能干活的数据分析 Agent至少需要具备四种能力任务规划能力。拿到一个模糊需求能拆解成可执行的步骤。比如分析销售下滑它能拆成确定下滑的时间范围和区域、取对应数据、计算关键指标、对比历史、定位异常品类、输出结论。工具调用能力。知道在什么情况下调用什么 Skill 或工具。这一步依赖前面说的 Skill 封装Agent 本身不干活它负责调度。结果判断能力。拿到中间结果后能判断是否合理、是否需要进一步操作。比如发现某个品类数据缺失严重它能决定先去补数据而不是硬着头皮往下算。自我修正能力。发现走不通的时候能换个思路重试。这个能力最考验 Agent 的设计水平也是最容易出问题的地方。我实测下来前两个能力现在的框架基本都能做到后两个才是真正拉开差距的地方。很多 Agent 跑着跑着就卡死或者跑偏问题往往出在结果判断和自我修正上。4.3 Agent 在数据分析流程中的实际编排我拿一个实际跑通的 Agent 流程来说明。需求是监控核心指标异常并自动归因。Agent 的工作流大概是这样首先它按固定周期调用取数 Skill 拿到最新数据然后调用指标计算 Skill 算出核心指标接着对比历史数据判断是否有异常波动。如果没有异常流程结束。如果有异常它会启动归因流程先按维度下钻区域、品类、渠道找出波动最大的维度再针对这个维度进一步下钻定位到具体的原因。整个过程里Agent 做的是决策Skill 做的是执行。比如要不要下钻是 Agent 决定的怎么下钻是调用 Skill 完成的。这里有个我踩过的坑早期我让 Agent 无限制地下钻结果它在一个维度上反复下钻钻到最细粒度还在钻浪费了大量资源。后来我加了约束最多下钻三层每层只保留贡献度前 20% 的维度。这个约束一加Agent 的行为就稳定多了。注意Agent 的自主性是把双刃剑。给它自由它能应对复杂情况但不加约束它可能陷入无效循环。设计 Agent 时一定要设置明确的终止条件和资源上限。5. MCP让 Agent 稳定对接外部世界的连接层5.1 MCP 要解决的核心问题在没有 MCP 之前Agent 要访问外部数据源每个数据源都得单独写一套对接代码。连数据库写一套调 API 写一套读文件又写一套。数据源一多代码就乱成一团维护成本极高。MCP 的思路是把这些对接方式标准化。它定义了一套统一的协议数据源只要按这个协议实现一个服务端Agent 就能通过统一的方式访问它。换数据源的时候Agent 这边的逻辑不用改只需要换一个 MCP 服务端。这个思路其实和 USB 接口很像。以前每个设备都有自己的接口现在统一成 USB插上就能用。MCP 就是 AI 应用领域的USB 标准。对数据分析来说这个价值很直接。我们日常要对接的数据源太多了业务数据库、数据仓库、各种 API、本地文件、云存储。如果每个都单独对接工作量巨大。有了 MCP这些数据源可以统一接入Agent 的取数逻辑就能保持稳定。5.2 MCP 在数据分析链路中的位置MCP 处在整个链路的最底层是连接层。它不参与分析逻辑只负责把数据拿进来和把结果送出去。具体来说MCP 在数据分析场景里主要干三件事一是让 Agent 能访问数据库执行查询二是让 Agent 能调用外部 API获取实时数据三是让 Agent 能把分析结果输出到指定位置比如写回数据库、生成文件、发送通知。我自己的配置里MCP 服务端主要接了三类数据源内部数据仓库用于取历史数据、业务系统 API用于取实时数据、文件系统用于读写中间结果。Agent 通过统一的协议访问这三类数据源代码逻辑完全一致只是配置不同。5.3 MCP 配置中的常见坑与排查思路MCP 用起来不难但配置阶段有几个坑特别容易踩。第一个是权限问题。MCP 服务端访问数据源需要权限权限没配好Agent 调用的时候就会报错。我遇到过好几次本地测试好好的一上生产就报权限错误排查半天发现是服务端的账号权限没开全。第二个是连接超时。数据源响应慢的时候MCP 调用会超时。默认超时时间往往偏短需要根据实际情况调整。我的经验是取数类操作超时设长一点比如 30 秒写入类操作可以短一点。第三个是数据格式不一致。不同数据源返回的数据格式可能不一样MCP 服务端需要做一层转换统一成 Agent 能处理的格式。这一步如果没做好Agent 拿到的数据就是乱的。排查这类问题的思路是先确认 MCP 服务端本身能不能正常访问数据源用命令行或工具单独测再确认 Agent 到 MCP 服务端的连接是否正常最后确认数据格式转换是否正确。一层层往下查基本都能定位到问题。常见问题可能原因排查方向调用报权限错误服务端账号权限不足检查数据源账号权限配置调用超时超时时间设置过短调整 MCP 服务端超时参数数据格式错乱格式转换逻辑有误检查服务端的数据转换代码连接不上服务端未启动或地址错误确认服务端状态和连接配置6. 四者协同搭一套能真正跑起来的数据分析体系6.1 从需求到落地的完整链路设计把四个概念串起来一套完整的数据分析体系大概是这样运转的用户提出需求自然语言Agent 接收需求并规划任务通过 MCP 连接数据源取数调用 Skill 完成清洗和计算Agent 判断结果并决定下一步最终输出分析结论。Prompt 贯穿始终既用于 Agent 的任务理解也用于 Skill 内部的模型调用。这个链路里每一层都有明确的职责Prompt 负责表达Skill 负责执行Agent 负责决策MCP 负责连接。四者各司其职缺一不可。我实际搭这套体系的时候最大的体会是不要一上来就追求全自动。先把 Prompt 写好再把高频操作封装成 Skill然后逐步引入 Agent 做调度最后用 MCP 打通数据源。一步步来每步都跑通了再往下走。想一步到位搭一个全自动 Agent大概率会卡在半路。6.2 不同规模团队的落地建议这套体系的落地方式跟团队规模关系很大。小团队1-3 人建议从 Prompt 和 Skill 入手。先把日常分析的 Prompt 模板化把最高频的几个操作封装成 Skill。这个阶段不需要 Agent人工调度就够了。投入小见效快。中型团队5-15 人可以引入 Agent 做半自动调度。把重复性最高的分析流程交给 Agent人工负责审核和异常处理。MCP 可以开始接入核心数据源减少手动取数的工作量。大型团队可以搭建完整的 Agent MCP 体系实现端到端的自动化。但这个阶段重点要放在治理上Skill 的版本管理、Agent 的行为监控、MCP 的权限控制这些不做好的话系统越大越乱。6.3 我踩过的三个典型坑最后分享三个我实际踩过的坑都是真金白银换来的教训。第一个坑Skill 封装过度反而降低效率。我早期特别热衷于封装 Skill恨不得每个操作都封一个。结果 Skill 数量爆炸调用的时候光找 Skill 就要找半天维护起来更是噩梦。后来我做了减法把低频的、一次性的操作从 Skill 里剔除只保留真正高频复用的。Skill 不是越多越好够用就行。第二个坑Agent 没有明确的终止条件。前面提过Agent 自主性太强会陷入无效循环。我有个 Agent 曾经在一个归因任务里反复下钻跑了半个多小时还没停。后来我给它加了硬性约束最多执行 N 步超过就强制输出当前结果。这个约束救了命。第三个坑MCP 权限给太大。图省事我给 MCP 服务端配了一个权限很大的账号。结果有一次 Agent 误操作差点改动了生产数据。从那以后我严格遵循最小权限原则MCP 服务端只给必要的读权限写操作单独走审批流程。这三个坑的共同点是都是过度导致的。过度封装、过度自主、过度授权。做这套体系克制比激进更重要。每加一个东西之前先问自己真的需要吗不加会怎样想清楚再动手能省掉很多返工。这套 MCP、Skill、Agent、Prompt 的体系说到底不是让你追求技术上的炫酷而是实实在在解决数据分析里的效率问题。我自己的感受是把这四样东西理解透、用对地方日常分析工作的效率至少能翻一倍。但前提是别贪多一步步来每步都跑稳了再往下走。