夜雨聆风我最初把 Skill 理解成一个“大号 Prompt”。
理由并不奇怪：Skill 被加载以后，里面的说明也会进入 AI 这一次能看到的信息。单看这一步，它确实很像一段更长、更完整的 Prompt。
后来我发现，我混淆的不只是 Skill 和 Prompt。我还下意识地把 Prompt、RAG、MCP、Agent、Skill 排成了一条升级路线：Prompt 不够就上 RAG，接了 MCP 就算 Agent，方法再打个包就成了 Skill。
这两种误解背后，其实是同一个直觉：名词越新、组件越多，系统就越高级。
现实里恰恰容易反过来。明明只是少给了一份文件，最后却做了一个知识库；明明每一步都能提前写好，偏要让模型临场决定；明明只接一个接口，也先搭一层 MCP。架构图热闹了，问题未必更好解决。
这些词总在一起出现，是因为一个 AI 系统在长大的过程中，会陆续遇到不同的麻烦。它们处理的是不同问题，并没有一条从低到高的顺序。把它们排成升级路线，反而掩盖了各自的职责。
沿着这些麻烦走一遍，名词反而没那么难了。
一开始，AI 只需要听懂一句要求
最简单的 AI 使用方式，就是你交代一件事，它给出一次回答。
这次交代通常叫 Prompt，也就是提示词。它可以只有一句话，也可以包括任务目标、输入材料、不能碰的边界，以及怎样才算完成。
如果回答不稳定，人们自然会研究：怎样把任务说得更清楚？怎样给例子？怎样用一组代表性输入反复测试？这就是提示词工程，Prompt Engineering。
这里容易出现第一个误会：以为 AI 回答不好，都是 Prompt 写得不够漂亮。
可 AI 真正用来回答的，并不只有你最后输入的那句话。系统规则、之前的对话、上传的文件、刚搜索到的网页、工具执行后的结果，只要这一次模型能看到，都在影响输出。
这次它实际能看到的全部信息，技术上叫上下文，也就是 Context。
于是问题分成了两种：
• 任务没有说清楚，要改 Prompt。
• 关键材料没放进来，旧规则和新规则打架，或者信息多到把重点淹没了，要整理 Context。
负责选择“放什么、什么时候放、怎样避免冲突和过期”的工作，叫上下文工程，Context Engineering。
名字听起来很新，问题其实很朴素：别只顾着把要求写漂亮，也要确认 AI 手里拿的是不是正确材料。
说清楚了，资料还是可能不够
假设你问 AI 今天的新闻、公司的最新制度，或者某位客户刚刚更新的订单。再好的 Prompt，也不能凭空把这些事实写进模型。
这时要补的是外部资料。继续加强指令，补不出模型从未拿到的事实。
资料少而且就在手边，直接把文件交给它就行。需要公开网页上的当前信息，就去搜索或浏览。资料很多，先从文档库或数据库里找出当前问题相关的部分，再交给模型，这类做法通常叫 RAG，也就是“先检索，再根据检索结果生成”。
如果要保留跨轮次的偏好、历史事实或任务状态，应用还会使用 Memory，也就是记忆。它依靠系统决定保存什么、何时取回，以及怎样处理过期和隐私，远没有“模型全都记住了”那么省心。
这几种办法有一个共同点：都没有改变模型本身，只是在本次运行时，把需要的信息拿给它看。
只有当你希望某种相对稳定的能力或行为直接进入模型参数，才会考虑后训练或微调。新闻、价格、版本这类经常变化的事实，显然不适合靠微调保存。
所以，资料不够时，先问一句：缺的东西是不是已经明确、数量也不大？如果是，直接提供往往比先建 RAG 更省事。
会回答，不等于真的会做
AI 可以写出“查询这笔订单”“发送这封邮件”“把文件改好”。但生成这几个字，不会让数据库自动返回结果，邮件也不会自己飞出去。
要让动作真的发生，系统必须给 AI 一项可以执行的能力，例如读文件、查数据库、调用业务接口、运行代码。这种提供给模型选择和请求调用的能力，叫 Tool，也就是工具。
模型通常负责选工具、给参数；宿主程序负责检查权限、真正执行，再把结果交回模型。Function Calling 或 Tool Calling，说的就是模型怎样用结构化方式表达“我要调用什么、参数是什么”。
当外部系统越来越多，新的麻烦又来了：每个 AI 应用都要分别接一遍文件、数据库、GitHub、Notion；每个系统也要为不同 AI 产品重新做一套连接。
MCP 就是在解决这种重复连接。它是一套统一协议，让 AI 应用更一致地发现和连接外部工具、资料与提示模板。
因此，Tool 和 MCP 不是同一件事。
Tool 回答“具体能做什么”，MCP 回答“这些外部能力怎样用统一方式接进来”。只有一个简单接口时，直接接 Tool 完全合理；连接对象多、重复适配明显时，MCP 的价值才会真正出现。
会做几步以后，轮到“谁来决定下一步”
有了工具，AI 已经能动手了。可一个真实任务往往不只做一次动作。
如果步骤和分支都能提前写清楚，就让程序按固定路径运行。这叫 Workflow，也就是工作流。它稳定、容易测试，也更容易知道失败发生在哪里。
即使某一步调用了大模型，只要整体路线还是代码预先规定的，它仍然是带 AI 的 Workflow。
另一类任务没法提前写完所有分支。排查故障时，读完代码才知道该查哪张表；查完数据，可能又要回头看日志；发现条件互相冲突，还得暂停向人确认。
这时需要一个运行主体持续拿着目标，根据刚看到的结果决定下一步，并判断什么时候结束。这才是 Agent，也就是智能体。
判断一个系统是不是 Agent，关键看任务路径的控制权交给了谁，工具数量和名字都说明不了这个问题：
• 下一步由预先写好的规则决定，更接近 Workflow。
• 下一步由模型结合目标和现场结果动态决定，更接近 Agent。
Agent 当然更灵活，但灵活不是免费的。它更难预测、更难测试，也更需要权限、暂停、恢复和人工接管。能用固定流程可靠完成的部分，没有必要为了“智能”再绕一圈。
当系统里同时有模型、工具、工作流、一个或多个 Agent，还要安排调用、并行、交接、重试和状态传递，就需要编排，也就是 Orchestration。它负责把运行组织起来，但并不等于一个更大的 Agent。
同一套教法总在重复，Skill 才有了位置
Agent 已经会看结果、选工具、继续做事，为什么还需要 Skill？
因为“有能力做”与“知道这类任务通常怎样做好”，中间还隔着一套方法。
第一次做代码审查，你可以把检查步骤完整写进 Prompt。可同类任务不断出现后，每次复制同一段说明就会越来越麻烦：适用条件、参考资料、脚本、失败处理、输出模板和验收标准全挤在一起，Agent 也不知道什么时候该加载哪套方法。
Skill 就是把一类任务中已经验证过的工作方法，整理成 Agent 能发现、按需加载的能力包。
它回答的是“遇到这一类任务，通常应该怎样完成”；当前这一次具体做什么，仍由 Prompt 和宿主 Agent 决定。
所以 Skill 被加载后确实会进入 Context，这也是我当初觉得它像“大号 Prompt”的原因。但它多出来的价值，在于适用条件、发现方式、配套资源、异常处理和验收可以作为一个整体维护。
再往旁边看，几个容易混淆的东西也能分开：
• Prompt 服务当前这一次任务。
• Prompt Template 保存一段以后还要重复填写的输入模板。
• Skill 保存一类任务的完整方法。
• 项目里始终要遵守的安全、目录、编码规则，更适合放进项目规则，例如 AGENTS.md。
• Plugin 负责把 Skill、MCP 和其他集成能力组合、安装和分发。
方法第一次出现时，也别急着做成 Skill。先实际使用，发现失败，改过几轮，确认它确实可复用，再沉淀更值钱。
系统越能做事，越不能只谈“聪明”
当 AI 只生成文字，出错主要影响答案质量。等它能发消息、改文件、操作数据库，错误就会直接落到外部世界。
这也是 AI 系统演化中经常被漏掉的一步：能力变强以后，权限、沙箱、规则校验、人工确认、评测、运行记录和断点恢复必须跟着长出来。
这些东西不会让模型显得更聪明，却决定系统能不能放心运行。
Skill 可以写清高风险步骤，MCP 服务可以做鉴权，Agent 也可以在关键动作前暂停，但真正的权限和保护仍要由系统执行。把“请务必安全”写进 Prompt，不等于已经有了安全边界。
新名词还会出现，先问任务缺什么
现在回头看，一个 AI 系统从一句 Prompt 走到 Agent 和 Skill，并不是一路“升级打怪”。它只是每解决一个问题，又暴露出下一种问题。
要求说不清，才有提示词工程；本次信息越来越复杂，才有上下文工程；资料不够，才有搜索、RAG 和记忆；需要真实动作，才有 Tool；连接开始重复，才需要 MCP；步骤能写死，用 Workflow；必须临场判断，才轮到 Agent；方法反复验证，才值得沉淀为 Skill。
以后再遇到一个新的 AI 名词，我会先把名字放一边，问五个问题：
1. 它是在改变模型本身，还是只影响这一次运行？
2. 当前缺的是要求、资料、动作、方法，还是决定下一步的控制权？
3. 它服务一次任务、一类任务，还是整个项目？
4. 路径能否提前确定，还是必须根据现场结果再判断？
5. 它是一项实际能力，还是连接、编排、治理或分发职责？
这样做不够酷，却很省系统。
技术选型真正的风险，是还没看清任务缺什么，就先把最重的答案装了上去。少记住几个名词，倒没那么要紧。
