Skill、MCP 和 Agent 有什么区别？从文章检查说起
想让 AI 帮忙检查一篇文章，往往会遇到几种不同的麻烦：它不知道你的写作要求，查不到文章涉及的最新信息，或者给了一堆建议，却没有把问题对应到文件里。
这几件事看起来都叫“AI 不好用”，需要补的东西却不一样。把写作要求整理成 Skill，可以减少反复解释；接入合适的 MCP 服务，可以让它读取原本拿不到的资料；让 Agent 调用工具、检查结果并继续处理，才能把多步任务往前推进。
我会先判断任务卡在哪里，再决定用什么。装齐三个名词，并不会自动得到一套可靠的工作流。
三者各管哪一部分
先把范围说清楚：这里的 Skill 指以 SKILL.md 为核心的 Agent Skills，Agent 指由模型参与决策、能调用工具推进任务的执行系统。
| 名称 | 在任务里的作用 | 文章检查的例子 |
|---|---|---|
| Skill | 保存可复用的任务说明、判断标准及配套资料，必要时附带脚本 | 检查哪些问题、按什么格式报告、如何保留作者的观点 |
| MCP | 用约定的协议连接客户端与服务，提供工具、资源等能力 | 查询外部资料库，读取某项服务返回的内容 |
| Agent | 根据目标和工具结果选择下一步，在指定范围内推进任务 | 读取文章、运行检查、核实疑点，最后交付检查报告 |
它们可以组合，也可以单独发挥作用。一次本地文章检查，可能只需要现有的文件读取和命令行工具。要查询外部资料时，才有必要考虑额外接入服务。
Skill：把每次都要解释的要求留下来
假设我希望 AI 检查文章时遵守这些要求：保留技术术语，不把他人的经历写成作者亲历，指出缺少依据的数字，修改建议要说明具体位置。
这些要求可以放进 Skill。下一次做同类任务时，支持该格式的工具可以加载这份说明。SKILL.md 写明适用情形和处理要求，较长的规范或示例另放在配套文件里；需要固定校验时，也可以附带脚本。
它没有重新训练模型，也不保证模型每次都照做。文件已经放进去、工具确实加载了、输出符合要求，是三件需要分别确认的事。
我更愿意把 Skill 写成一份能检查执行情况的说明。例如，“检查事实”太宽泛；“把文中的价格、版本号和效果数字逐项列出，注明已核实或待核实”，才方便我验收。对于缺少资料的判断，还应该规定怎么报告，避免 AI 用一句肯定的语气把空缺补过去。
MCP：让工具和资料有可调用的入口
MCP 的全称是 Model Context Protocol。它约定客户端与服务如何沟通，服务可以提供工具、资源和提示模板等内容。具体能做什么，仍取决于服务实现和客户端支持。
在文章检查里，一个资料查询服务可以返回搜索结果或原文。模型拿到结果后，还要判断它是否相关、时间是否合适、能否支持文章中的说法。MCP 负责连接，不替资料背书。
连接成功也不等于获得所有权限。只读查询、修改文件、发布内容是不同操作，需要由实际工具、账号权限和执行环境控制。把“不得发布”写在提示词里有用，但涉及重要账号时，我还会选择只读工具或限制实际权限。
另外，MCP 并非接入能力的唯一方式。现成的命令行工具、脚本、API，或者应用自带的功能，也可能完成任务。如果 AI 已经能读项目文件，我不会为了检查一篇本地文章再安装一个文件服务。
Agent：根据执行结果继续做事
Agent 的关键在于执行过程：理解目标，选择工具，读取返回结果，再决定继续、重试、交付或请求人工处理。
比如，它发现文章里的内部链接对应文件不存在，就把这个问题记入报告；如果外部资料查询失败，应当保留“未核实”状态，而不能直接写“没有问题”。这比一次性生成检查建议多了对实际结果的处理。
Agent 可以在当前会话中运行，也可以由定时任务或事件触发。它不必常驻后台，不必接聊天机器人，更不必由多个智能体组成。具体需要哪种形式，要看任务频率和运行环境。
用一篇文章把关系串起来
如果要为博客做发布前检查，我会先把输入限定为一篇文章，以及与它直接有关的配置。输出是一份检查报告，列出问题位置、判断依据和建议处理方式。
报告里要区分三种状态：已经检查且通过、发现问题、未完成检查。第三种尤其容易被漏掉。链接无法访问、资料版本不明、某条命令没有运行，都应该留下明确记录。
然后把检查分开处理。发布日期格式、必填字段、站内链接目标这类规则明确的项目，适合用解析器或脚本检查。观点是否被改偏、例子能否支撑结论、段落是否重复，则需要模型阅读和判断。固定检查也可能有程序缺陷，所以脚本结果仍要对照实际文件，不能因为输出了一行“通过”就停止验收。
Skill 保存这些检查要求，Agent 负责读取文章并调度执行。如果文中有一项需要核实的最新功能，再通过可用的资料工具查询；这个工具可以由 MCP 服务提供。整个流程并不要求每一步都使用 MCP。
首次尝试时，我会把任务写成这样：
检查我指定的这篇博客文章，读取与它直接相关的项目规则。
本次只检查，不修改文件，不提交代码，不发布内容。检查文章元数据、站内链接、重复标题，以及正文中的事实性说法。规则明确且已有校验工具的项目，运行工具后再报告结果。需要外部资料的说法，使用已授权的查询工具核实；查不到就标记待核实。不要添加作者经历，也不要为了顺口改变技术含义。
交付时列出问题所在文件及位置、依据、建议，并单独说明哪些检查实际完成，哪些没有完成及原因。这段指令只定义检查任务。等报告能稳定反映问题，再考虑让它修改指定内容。检查通过与批准发布之间，仍由我做决定。
我会先复用流程，再提炼 Skill
第一次做某项工作，我通常还说不清哪些要求值得固定。此时直接写一个包办选题、研究、写作、排版和发布的 Skill，很容易把尚未验证的设想写成规则。
更合适的做法是先完成一个范围小的任务，记录人工纠正了什么。例如，AI 把“建议测试”写成了“已通过测试”，那么以后检查文章时，就要核对完成态与证据是否一致。这条要求有明确的由来，也能用样例验证。
因此，可以先在 Agent 的执行过程中整理出稳定的规则，再提炼成 Skill。反过来，成熟的 Skill 也可以被不同 Agent 复用。迁移时还要检查配套脚本、路径、工具和权限，不能只复制文件就假定到处能运行。
我也不会马上把检查流程拆成多个智能体。对一篇文章来说，读稿、核实和整理报告的依赖关系很紧，单个 Agent 顺序处理通常更容易追踪。等任务中出现可以独立处理的部分，再考虑并行，并明确谁负责修改文件、谁负责最终验收。
怎样判断这套流程值得保留
一次输出看起来不错，还不足以证明规则已经生效。旧对话里可能存着刚刚补充的要求，因此我会在新对话中，用保存下来的输入重新测试，并查看实际结果。
文章检查至少要覆盖：正常文章、故意留有问题的文章，以及资料不足的文章。第二种要能指出问题；第三种要能承认检查没有完成。还要试一次工具失败，确认它不会把失败悄悄转换成“通过”。
修改规则后，先重跑暴露问题的那份输入，再检查原本正常的输入是否受到影响。新对话能减少对旧聊天记录的依赖，但不会自动隔离共享文件、工具和日志；权限问题需要在执行环境里处理。
最后我会看人工返工有没有减少：是否还要反复解释相同要求，能否迅速找到问题位置，未核实的内容有没有被误报为通过。工具调用次数和 Skill 数量，都不能代替这些结果。
对这个博客，我会从文章检查这一项开始。先让它交付可核对的报告，再逐步加入经过确认的修改动作。什么时候值得自动触发，要等这项工作在不同输入下都能按要求完成后再决定。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或打赏支持！