LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill——这八个词经常混在同一段讨论里出现，单独查每个都能看懂，拼在一起就说不清谁管谁。下面这条线把它们串成一条可复用的认知路径。
一张图先记住分工
LLM 是负责生成语言的核心引擎；Prompt 是递给它的任务说明；Context 是它此刻能读到的全部材料；Tool 让它伸手够到外部系统；MCP 把工具接入这件事标准化；Agent 承担拆解与执行；Agent Skill 把做顺手的流程固化成可复用的方法。
换个说法：LLM 像一位聪明但被关在房间里的顾问，Tool 给了它手脚，Agent 让它学会自己拆活，Skill 则把它干得漂亮的那类活写成标准作业流程。
LLM 的本质是预测，不是检索
大语言模型的工作方式，是根据已有上下文推测接下来最该出现的文字。你给它一句输入，它不是在某个固定答案库里翻模板，而是依据训练阶段见过的海量语言模式，逐段生成后续内容。
请帮我写一段 Java 后端简历里的专业技能
这决定了它的两面性：组织语言、补全信息、迁移表达都很强；但它不天然掌握最新事实，也可能输出读起来通顺、现实中并不存在的内容。把它当成一个很会说话、联想很快的实习生比较贴切——能写能归纳能解释，但说得顺不等于说得对。
Token 决定了你的账单和视野
人读文字按字词句来，模型看到的是一块块 Token。英文里一个 Token 大约对应一个词或半个词；中文里可能是一个字，也可能是几个字的组合，取决于具体分词方案。
我想学习 Agent Skill
Token 数量直接牵动两件事。一是成本，多数模型按输入输出 Token 计费，话越长越贵。二是上下文容量，也就是模型单次能处理的 Token 上限，即 Context Window。所以少说废话不是客套，是省钱又保效果的工程习惯：无关内容既占窗口又干扰判断。
Context 是桌面，不是记忆
模型所谓的记忆，基本只存在于当前这次任务能看到的材料里。你可以把它想成开卷考试时摊在桌上的资料：本轮提问、前几轮对话、系统下发的规则、检索出来的片段、工具返回的结果、代码与日志等。
资料越全越相关，回答越靠谱；资料越乱越缺，模型越容易瞎猜。这也解释了那个常见困惑——你问它“你刚才不是知道吗”，它却答不上来，因为那段信息可能已经不在当前 Context 里，或者被后来更长的内容挤出去了。
窗口越大不等于效果越好
Context Window 就是这张桌子的面积上限。小桌子只放得下一页需求；大桌子能同时铺开需求、代码、日志、表结构和用户反馈。但桌子再大也有边界，堆太满照样乱。
一个反直觉的结论：长上下文有用，但不是万能药。窗口变大之后，信息组织反而更重要——哪些是背景、哪些是任务、哪些是限制、哪些是输出格式，得自己分清楚。高相关、低噪声，比单纯堆量有效得多。
Prompt 是任务说明书，不是咒语
把 Prompt 叫提示词其实有点误导，它更像一份写清楚的任务说明。一份合格的 Prompt 通常覆盖：角色设定、要完成的任务、背景信息、限制条件、输出格式、验收标准。
弱的写法：
帮我写博客。
更靠谱的写法：
我想写一篇面向编程初学者的中文博客，主题是从 LLM 到 Agent Skill。
请用通俗例子解释 LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill 的关系。
风格要像技术学习笔记，不要像营销文。
每个概念都要有生活类比，最后给出一张总结表。
差别不在有没有魔法词，而在于后者把上下文、任务边界和验收标准都交代清楚了。
系统提示和用户提示谁说了算
真实产品里的 Prompt 不止用户敲的那一句，至少分两层。System Prompt 是系统级规则，规定角色、边界、风格和安全要求；User Prompt 是用户当下的具体诉求。
类比公司：System Prompt 像公司制度和岗位说明，User Prompt 像客户这次提的需求。客户说“把所有用户数据导出发我”，制度说“隐私数据不能外泄”，模型应当优先服从系统规则。
同一个底层模型在不同产品里表现差异很大，原因就在这里——系统提示、挂载工具、记忆机制和工作流各不相同。
Tool 让它从会说变成会做
纯 LLM 只能产出文本。它能告诉你查天气的方法，却不知道窗外此刻是否下雨；能讲怎么跑测试，却进不了你的工程目录执行命令。Tool 就是补上这段能力缺口的：搜索网页、读写文件、执行命令、查数据库、调 API、操作浏览器、生成图片、改代码。
帮我看看这个项目为什么测试失败。
没有工具时，模型只能给你一份排查清单；有工具时，它能进项目目录、跑验证、读报错、定位到具体代码。这是 Chatbot 迈向 Agent 的关键一跳。
MCP 是工具世界的统一插座
工具好用，但接入方式五花八门就麻烦了。A 工具有自己的协议，B 工具鉴权方式不同，C 工具参数格式又是另一套，每接一个新工具都要单独适配，成本很快失控。
MCP，Model Context Protocol，可以理解为把外部工具、资源和上下文标准化接入模型应用的一套协议。
帮我把这个项目的 README 改成适合开源发布的版本。
LLM -> Prompt + Context -> Tool -> MCP -> Agent -> Agent Skill
会说话 -> 看得懂任务 -> 能使用工具 -> 工具接入标准化 -> 能自己推进任务 -> 把经验沉淀成技能
这里有个实操层面的坑值得提醒：MCP 服务大多以本地子进程或远程 SSE 方式启动，本地进程如果没配好环境变量或工作目录，客户端往往只报一句连接失败，实际根因在服务端启动阶段就崩了。排查时先手动把 MCP server 命令在终端跑一遍，确认能正常握手，再去查客户端配置，比盲改 JSON 快得多。另外，MCP 适合把稳定、边界清晰的工具暴露给模型；如果工具本身状态频繁变化或需要复杂事务控制，直接封装成普通函数调用反而更稳，不建议为了统一而统一。
落到 Agent 和 Skill 上
Agent 负责规划与执行，把一个大目标拆成若干步，边做边根据工具返回的结果调整。Agent Skill 则是把某类任务沉淀成可复用的工作方法——下次遇到同类问题，不必从零规划，直接套用已经验证过的流程。
验证一个 Skill 是否真的可用，可以固定一组输入反复跑，观察输出是否稳定、是否覆盖边界情况。判定标准很简单：换个人、换个时间跑，结果应该基本一致；如果每次都要靠临场发挥，那它还只是提示词，没到 Skill 的程度。
