skill、agent、mcp、workflow 到底怎么分

摘要skill、agent、mcp、workflow——AI 编程文章里这四个词出镜率最高却最容易被混为一谈。本文用你每天写的代码作参照讲清它们各是哪一层、实际长什么样、怎么按自己的真实工作流搭起来以及单条提示词到底怎么写才不白写。你有没有这种体验刷 AI 编程文章满屏都是 skill、agent、mcp、workflow。每个词单看都眼熟合在一起就懵——“我到底要不要给我项目搞个 skillagent 和 workflow 是一回事吗mcp 又是来凑热闹的”先给结论省得你往下读还绕这四个词是四层不同的东西不是同义词也不是递进关系。skill是一段能复用的提示词像给 AI 的操作手册agent是一个会读上下文、调工具、跑循环的执行实体像那个真正干活的同事mcp是让 agent 接上外部系统数据库、issue、CI的插头标准workflow是把多步、甚至多个 agent 按流程串起来的编排层。一句话skill 给 agent 当手册agent 通过 mcp 接外部workflow 决定先跑谁后跑谁。下面挨个拆。图skill / agent / mcp / workflow 各自是一层混着说才是根上没分清。Skill一段能复用的操作手册skill 最小也最容易理解。它本质上就是一段写好的提示词 约定你不用每次都重复说同一套指令。比如我写技术博客有一套固定流程标题≤20字、摘要50~100字、写完跑评价协议。我把它写成一个 SKILL.md 文件下次直接说按 tech-blog-writer 规范写AI 就会去读那个文件照着来。skill 不是新能力是把你已经说腻的话固化下来。实际长什么样一个 SKILL.md 大概是这样--- name: tech-blog-writer description: 当用户要求写技术博客、公众号文章时触发 --- 写作原则 - 每篇解决一个真实问题 - 标题口语化≤20 字 - 正文 2500~4000 字关键是description那一行——它决定了什么时候加载这份手册。AI 看到用户说写篇公众号文章匹配到这个 description就把整份 skill 读进来当行为约束。你不用每次手敲一遍规则。skill 解决的是重复劳动你每次都要交代的背景、规则、格式固化成一份文件AI 加载即用。国内这块已经很热闹WorkBuddy 有技能市场你刚看的 DSH 项目把 skill 和插件体系打通通义灵码、CodeBuddy 也都有各自的指令集。但记住一点skill 不是越多越好。我之前踩过坑——装了一堆 skill结果两个 skill 对摘要字数的规定互相矛盾一个说≤25一个说≤20AI 直接懵不知道听谁的。这一点后面讲提示词时再展开。Agent一个会跑循环的执行实体agent 比 skill 大一圈。如果说 skill 是手册agent 就是那个照着手册干活的同事。它的关键特征不是更聪明的聊天框而是三件事读上下文、调工具、跑循环。Claude Code、Codex CLI 都是 agent——你给它一个任务它自己去读代码、跑测试、改文件、再跑循环到完成。这个循环才是 agent 和一次性问答的本质区别问答是你说一句它回一句agent 是自己跟自己较劲直到任务结束。agent 和 skill 的关系是agent 加载 skill 当操作手册。你用 Claude Code 时它背后有一套技能体系你用 DSH它按cordis.patch.yml把插件加载进来当行为约束。agent 是执行者skill 是它手里的工作指南。这里有个常见误解要拆掉agent 不是有情商会聊天的人。它接到明确指令就闷头干干完结果可能对也可能错不会委婉拒绝也不会看一眼再回答——需要表现它的局限就写它做了什么、结果如何别编它怎么想。把 AI 写成有犹豫、有情绪的人类助手读者一眼看出是假的全文可信度直接崩。MCP让 agent 接上外部系统的插头mcp 是另一层的东西专门解决工具不通用。AI agent 想真正干活得能碰你的数据库、issue 系统、CI 日志。但这些外部系统每家接口都不一样。MCPModel Context Protocol就是个标准插头外部系统按规范实现一个 MCP server暴露出一组 toolsagent 就能统一调用不用为每个系统单独写适配。实际形态是一个 server 提供一份 tools 清单{tools:[{name:query_database,description:执行只读 SQL},{name:create_issue,description:在 issue tracker 建工单}]}agent 看到这份清单就知道能叫哪些工具、分别干什么。你之前写的 DSH tool 插件那个greet工具走的就是这条路线——把能力以工具形式暴露给 agentagent 不必懂后端细节只管调。MCP 现在是 Linux 基金会托管的开放标准接一次就能跨 provider 用。但它也带来新的安全面第三方 MCP server 一旦被投毒agent 调它时就会执行恶意指令。所以别为了用而用——你只在真的需要 agent 碰外部系统时才加 MCP纯粹写业务代码用不上如果 agent 要持续读数据库、建工单、查 CI 日志这类会被反复调用、且接口可能变动的外部能力才是 MCP 该登场的时候。Workflow把步骤串起来的编排层workflow 是最大的一层但它常被误解。workflow 不是多开几个 agent而是把多个步骤按确定流程串起来。比如先写规格 → 再写代码 → 跑测试 → 审查 → 合并这就是一个 workflow。它管的是顺序、条件、产物怎么流转。这里必须点一条红线workflow、Multi-Agent、Git Worktree 是不同层次的东西别糊在一起。Multi-Agent 是执行层几个 agent 并行干不同的活Worktree 是隔离层每个 agent 在独立分支互不干扰workflow 是流程层谁先谁后、产物怎么交。说我用 workflow 就是多 agent会把读者带偏——你用单个 agent 配一个循环脚本照样是 workflow。层次清楚了才知道自己缺的是哪一层。四者串起来看skill 给 agent 当手册agent 通过 mcp 接上外部系统workflow 决定这些步骤怎么编排。它们各管一段合起来才是一套能用的 AI 编程环境。图skill 给 agent 当手册agent 通过 mcp 接外部workflow 来编排——各管一段合起来才是一套能用的 AI 编程环境。怎么按自己的流程搭别一上来搞舰队讲了四个词落到实操你怎么给自己搭原则就一条从最痛的一个环节开始别一上来搞多 agent 舰队。举个真实例子。你每次写单元测试都要重复交代用 JUnit5、覆盖边界值、命名用 should_ 前缀。这活重复、有明确标准——它就是个做 skill 的绝佳候选。你把这套要求写成一个 test-writer skill以后说一句按 test-writer 写单测就行。进阶一点如果单测要连测试库、查真实数据那才考虑加一个 MCP server 把数据库暴露给 agent。再进一步如果你有一堆写单测 → 跑测试 → 修失败的循环要反复跑才值得用 workflow 把这几步串起来自动跑。顺序很重要skill 先解决重复说 → mcp 在要接外部时才加 → workflow 等单步跑顺了再串。反过来一上来就编排多 agent九成会卡在单个步骤都没跑明白最后舰队飞不起来人还得更累。怎么写好一条提示词最后落到最落地的问题提示词到底怎么写才不白写结合我踩过的坑几条实用规则图一条提示词的四条底线——具体、给上下文、给验收、一次一件事。具体别抽象。写好代码是废话用 Java 17 的 switch 表达式替换旧 if-else保持方法≤30行才是能执行的指令。越具体AI 跑偏的space越小。给上下文。AI 不知道你项目的约定。把我们团队用 MyBatis-Plus、禁止手写 XML SQL写进 skill 或前置说明它才不会自作主张。给验收标准。“单测要通过、覆盖率不降、不引入新 warning”——让 AI 知道什么叫干完了而不是它自己觉得行就行。一次只说一件事。一条提示词塞五个不相关的要求它顾此失彼。拆成多条或将关联要求固化进 skill 让它一次性加载。写清边界比写多更重要。这是我踩过最大的坑之前装了一堆 skill两个 skill 对摘要字数的规定互相矛盾AI 直接懵。skill 之间必须有清晰的触发条件和责任边界否则越多越乱。提示词也是同理——把做什么和不做什么都写清楚比堆砌要求有效。收尾黑话本身不重要。skill、agent、mcp、workflow 这些词说到底都是为了解决一件事把你已经会做、但不想重复做的活交给 AI 稳妥地干。想清楚我要让 AI 帮我解决哪类重复劳动比背熟这些名词有用得多。需要手册就做 skill需要碰外部系统就加 mcp需要串多步才上 workflow——工具是手段你的真实工作流才是主角。参考资料Anthropic Skills 文档skill 概念与 SKILL.md 形态MCP 官方 specprotocol 定位与 tools 暴露机制GitHub Copilot Agent Mode 文档agent / workflow 官方表述作者唐悦玮 | 从后端出发用 AI 拓展到全栈的工程师。