最近三个月，我至少被问了20次同一个问题。
“老师，我调了GPT-5，也用了Claude Code，为什么Agent做事还是乱七八糟？让它分析代码，它说一堆正确的废话。让它修Bug，它改出三个新Bug。Prompt改了几十版，没用。”
我把他的Agent日志拉出来看了一遍。
问题不在模型。问题在于，他的Agent裸奔了。
什么叫裸奔？就是Agent只有一个大模型大脑，但没有任何“技能插件”——不知道怎么读本地文件，不知道怎么执行shell命令，不知道怎么查数据库，甚至连“按照公司约定的JSON格式输出”都做不到。
模型知识截止于2025年，你公司的代码仓库是2026年的。模型不知道你们用什么日志格式，不知道你的测试框架怎么配置，不知道你们团队约定了哪些命名规范。
你让一个只有通识教育背景的实习生去干需要专业认证的活，不给工具书，不给操作手册，然后骂他能力不行。
不是他不行。是你不给工具。
目录
一、你写的Prompt再多，也填不满模型的知识缺口
二、大模型缺的不是推理能力，是“怎么做事”的上下文
三、Skill就是个“可执行的说明书”：MCP + 工具函数
四、两组对比：没Skill的Agent vs 装好插件的Agent
五、三步设计你自己的Skill，让Agent真正干活
六、Skill会成为新的数字资产，也会制造新的岗位
一、你写的Prompt再多，也填不满模型的知识缺口
一个典型的场景。
你想让Agent帮你审查代码里的SQL注入风险。你写了500字的Prompt，告诉它什么是SQL注入，给了一堆例子，要求它逐行分析。
Agent干了几件事。第一，它靠训练记忆里的SQL注入模式去匹配。第二，它不认识你项目里自定义的ORM封装函数，会把安全的调用误判为风险。第三，它不知道公司最新的安全规则库在哪里。
结果：误报率40%，漏报率20%。你花了一个小时写Prompt，又花了一个小时甄别Agent输出。效率还不如自己查。
问题出在哪？
你的Prompt是静态的。SQL注入的检测逻辑需要查最新的CVE规则库，需要知道项目里哪些函数是安全的封装，需要调用外部的静态分析工具。这些东西，你在Prompt里给不了，给了也维护不了。
本质是什么？
大模型的极限不在于推理，而在于可获取的上下文。 你把巨量信息塞进Prompt，有两个后果：一是Token成本爆炸，二是模型会被无关信息干扰，反而降低精度。
这就是为什么行业在疯狂搞Skill插件。
2025年底，Anthropic发布MCP协议，本质就是让Agent能“即插即用”各种能力模块。紧接着，腾讯上线SkillHub，超过28000个Skill被封裝成可调用的单元。Cursor、Claude Code、OpenClaw这些工具，全部支持Skill机制。
你的Agent输出垃圾，不是模型智力不够。是它手边没有趁手的工具。
二、大模型缺的不是推理能力，是“怎么做事”的上下文
换个角度理解。
大模型就像一个刚从斯坦福毕业的天才毕业生。推理能力一流，抽象思维顶级。但你要他去修一台柴油发动机，他不懂。
不是他智商不够。是他没摸过柴油机，不知道扳手放哪，不知道每个零件的扭矩参数。
你给他的“上下文”——也就是Prompt里的信息——相当于一本理论教材。但修发动机需要的是操作手册、零件目录、专用工具。
Skill就是那个操作手册加专用工具。
下图展示了一个Skill如何在Agent运行时被调用。Agent不直接执行Skill，而是通过MCP协议发现、加载、调用。
┌─────────────────────────────────────────────────┐
│ 用户请求 │
│ “帮我检查这段代码有没有SQL注入” │
└─────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ AI Agent (大脑) │
│ 理解意图 → 规划步骤 → 决定调用哪些Skill │
└─────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ MCP协议层 (总线) │
│ Skill注册中心 │ 协议适配 │ 路由分发 │
└─────────────────────────────────────────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│SQL注入 │ │代码解析 │ │规则库查询 │
│检测Skill │ │Skill │ │Skill │
└───────────┘ └───────────┘ └───────────┘
核心差异是什么？
没有Skill，Agent只能靠“记忆”工作。记忆是模糊的、过时的、没有业务细节的。
有Skill，Agent可以：
调用公司内部的安全规则API
执行本地的静态分析工具
读取项目配置文件中的特殊约定
把结果格式化为团队约定的JSON结构
Skill解决的是“怎么做”的问题。不是“应该做什么”。
三、Skill就是个“可执行的说明书”：MCP + 工具函数
技术上讲，一个Skill包含三部分。
第一部分：元数据。告诉Agent这个Skill是干什么的、什么时候该用它。比如“这个Skill用来检测SQL注入，输入是代码字符串，输出是风险列表”。
第二部分：指令。一段给模型的提示，说明“怎么用这个Skill”。包括输入格式、输出格式、常见的使用场景。
第三部分：工具函数。实际执行的代码。可以是一个本地脚本、一个API调用、一个数据库查询。
Agent调用Skill的流程是这样的：
第一步：Agent收到用户请求，分析意图。 第二步：Agent查找MCP注册中心，看哪些Skill的元数据与当前意图匹配。 第三步：Agent根据Skill的指令，构造正确的输入参数。 第四步：Agent通过MCP调用工具函数，拿到执行结果。 第五步：Agent把结果整合到回答中。
注意一个关键点：模型不执行工具函数。模型只做两件事——决定调用哪个Skill、解释调用结果。 真正的执行由本地代码完成。
这意味着什么？意味着你的Skill可以用任何语言写。Python、Go、Java、Bash，甚至是一个HTTP请求。Agent只管调度，不管实现。
解决了什么问题？
解耦。领域知识和执行逻辑从Prompt里抽出来，变成独立可维护的模块。你改Skill的实现，不需要改Agent的Prompt。升级安全规则库，Skill内部换API就行，Agent完全无感知。
另一个被解决的痛点：权限和安全。如果把执行代码写在Prompt里让模型自己去跑，风险极大。但Skill是预先封装好、签过名的安全模块，Agent只能以受限方式调用。
可以截图传播的观点句1：Skill把“怎么做事”从“应该做什么”里剥离出来，AI才能从顾问变成工人。
四、两组对比：没Skill的Agent vs 装好插件的Agent
用真实任务测试。任务：分析一个Python项目的依赖文件（requirements.txt），找出有已知安全漏洞的库，并给出升级建议。
没装Skill的Agent：
靠训练记忆，列出一份常见漏洞库列表。它说“requests 2.25.0有CVE-2023-1234”。但它不知道这个CVE是否已被标记为误报。它建议升级到2.28.0，但没检查2.28.0和项目代码是否兼容。
输出是一段自然语言，你需要自己复制粘贴、查漏洞库、手动验证。
耗时：你写复杂Prompt 30分钟，Agent跑完2分钟，你验证结果20分钟。总成本52分钟。准确率60%。
装了三个Skill的Agent：
Skill 1：依赖解析器。输入requirements.txt，输出所有库名和版本号的结构化列表。 Skill 2：安全漏洞查询器。调NVD API或公司内部漏洞库，返回每个版本的真实CVE状态。 Skill 3：兼容性检查器。快速扫描项目代码中用到的函数签名，判断升级后是否兼容。
Agent自动编排三个Skill：先解析依赖，再批量查漏洞，最后对有漏洞的库做兼容性检查。输出是一个结构化报告：哪些库必须升级、哪些库建议升级、哪些库因为兼容性问题暂时不动。
耗时：无Prompt编写（Skill已预置），Agent执行3分钟，你直接看报告5分钟。总成本8分钟。准确率95%。
差异在哪？不是模型变聪明了。是Skill让Agent“手上有活”。
可以截图传播的观点句2：一个没有Skill的Agent，是纸上谈兵的参谋；一个有Skill的Agent，是自带工具箱的施工队。
五、三步设计你自己的Skill，让Agent真正干活
如果你现在就想动手，路线不复杂。
第一步：拆解高频任务
拿你的日常工作，选三个最常做的任务。比如“解析日志”“查询数据库”“格式化输出”。
把每个任务拆成：输入是什么、输出是什么、中间需要查哪些外部信息、需要调用哪些本地工具。
第二步：封装成Skill
选一个MCP SDK（Python版或Node版都成熟了）。写一个类，至少实现三个方法：
describe()：返回元数据，告诉Agent这个Skill的能力边界
input_schema()：定义输入参数必须符合的JSON Schema
run(input)：真正的执行逻辑
写完后本地注册到MCP server。一行配置的事。
第三步：让Agent加载
在Agent的配置里，加上MCP server地址。不同的Agent框架方式不同，但本质就是告诉Agent：“这里有新Skill，拿去用。”
测试方法很简单。给Agent一个任务，问它“你打算怎么做”。看它列出的执行计划里，是否包含你写的Skill。不包含，检查元数据写的是不是够清晰。
有一个容易被忽视的原则：Skill只做一件事，并做好。 一个Skill负责“解析时间字符串”，另一个负责“查漏洞库”，不要揉在一起。细粒度的Skill更容易被Agent复用。
可以截图传播的观点句3：Skill设计的黄金法则：让Agent像搭积木一样组合你的能力单元。
六、Skill会成为新的数字资产，也会制造新的岗位
预测两个趋势。
第一，Skill会成为企业的核心数字资产。
就像十年前公司积累代码库一样，未来公司会积累Skill库。每个Skill封装了一条业务知识或一个操作流程。新员工入职，不是看文档，是继承一套Skill。Agent会了，人也就知道了。
SkillHub的出现只是个开始。企业内部私有Skill市场的爆发会在2026年下半年到来。
第二，“Skill工程师”会成为独立岗位。
不是AI工程师，不是测试工程师，是专门设计、开发、维护Skill的人。工作内容是：和业务方访谈，提取高频决策逻辑；封装成可被Agent调用的标准化模块；写元数据让Agent能“理解”这个Skill的能力；监控Skill的调用成功率和准确率，持续迭代。
这个岗位对测试从业者特别友好——测试的本质是验证“输入-输出”的正确性，Skill的本质也是定义清晰的输入输出边界。
最后一个问题，留给你：
你的业务里，最值得被封装成Skill的三个高频任务是什么？如果明天就要你做第一个Skill，你选哪个任务，输入输出怎么定义？
