AI Agent的Skill是什么？从工具到技能，一文读懂智能体灵魂

1. 先聊聊我自己的翻车经历你就懂 Skill 干嘛用的了我最早鼓捣 AI Agent 的时候走了很长一段弯路。当时我照着网上教程搭了个 Agent能联网搜索、能读文档、能调一堆工具自己感觉挺像那么回事。结果真让它干点正事比如“把这几篇技术文章读一遍然后按主题整理成一份带链接的周报”——它就卡壳了。要么搜半天抓回来一堆残缺信息要么格式输出得乱七八糟连个正常表格都排不好。更气人的是每次让它干同一个活儿它都能在同一个地方迷路就像从来没干过一样。后来我去找一位做过不少生产级 Agent 的朋友请教。他问我一句话“你的 Agent 有自己的 Skill 吗”我当时就愣住了。那会儿我根本不知道 Skill 是什么还以为只要模型够聪明、工具够多就够了。他指着一个项目目录说“你那些工具是零件。Skill 是训练好的发动机。没有发动机零件再多也跑不起来。”这句话之后我重新把 Agent 从里到外拆了一遍。这篇稿子就是想把这段折腾的经验讲明白尤其是给刚入坑、看到“Skill”这个词觉得高深莫测的小白朋友。我尽量用大白话把它说透它到底是什么、为什么它被称为 Agent 的灵魂、以及你自己动手写一个的时候有哪些坑是必然要踩的。如果你是那种已经被教程里术语砸到头晕的初学者这篇按顺序看就行。如果你已经玩了几天 Agent、想找一个合适思路来组织自己的代码和配置可以直接跳到第 3、4、5 节实操和排错都在那儿。2. Skill 到底是什么别被名词吓到它就是给 Agent 装上的“职业训练”2.1 拆掉概念墙从“工具”到“技能”的本质差别很多教程喜欢把“工具调用”和“Skill”混在一起讲。这也难怪它们在外形上确实有交集。但你要真把它俩当成一回事后面一定会吃亏。用大白话区分工具Tool是单个动作。比如“打开网页”“搜索关键词”“把这段文本翻译成英文”。你可以把它想成一把螺丝刀。技能Skill是完成一件具体事情的整套流程、判断规则和动作组合。比如“自动收集资料并生成日报”它需要判断哪些链接值得读、读完后提取什么、标题怎么拟、分类标准是什么全部揉在一个流程里。这不是一把螺丝刀能解决的它是一条完整的生产线。一个典型的 Skill至少包含三层东西第一层一套可被执行的动作序列。也就是一个脚本、一个函数或者一组逻辑判断告诉 Agent 遇到什么情况先做什么再做什么什么情况要停下来。第二层一个供语言模型理解的“操作手册”。它告诉模型这个技能是用来干什么的、需要哪些输入、输出格式长什么样、有哪些边界条件和禁忌。说白了就是给模型一张“产品说明书”。第三层一组经验参数与默认值。比如超时时间、重试次数、输出语言、是否写日志、是否要求人工确认。这些配置往往是从真实运行里调出来的不是写死在代码里的。结合起来Skill 就是一个“动作说明书配置”的独立包。模型在运行时先读说明书然后按配置把动作一条条跑完最后用约定好的格式把结果交回来。如果你用过一些带插件机制的纯文本编辑器或者搞过邮件过滤规则那这种感觉你应该很熟规则一旦建立它就变成一种“不用重新思考也能完成”的能力。Skill 对 Agent 的意义正是这种“不用重新思考”的肌肉记忆。2.2 为什么说它是 Agent 的“灵魂”一个人要是没有职业训练给他再好的设备也操作不了。Agent 也一样。一个没有 Skill 的 Agent空有大模型的理解力但它不知道“怎么完成一件事”的具体路径。我给你讲个特别直观的类比。你雇了一个新人当编辑助理。这个新人名校毕业、脑子灵光、记忆力超强但你对他的“训练”为零。你让他做一份采访提纲他可能给你三个版本你再让他筛一下留言里哪些值得回复他可能抓起一把就看心情回复了。但如果你把一套标准的“采访提纲操作手册”交给他里面写清楚采访对象定位如何判断、问题层级如何设计、每个板块控制在什么问题密度、什么情况下需要追问确认他上手就快得多。Skill 扮演的就是这个操作手册训练过程的打包产物。模型本身有知识、有推理、有语言能力但它缺一个“岗位训练”。Skill 恰好补上这个缺口。没有它Agent 永远停留在“什么都懂一点、但什么都干不利索”的状态。这一点也解释了为什么同一个模型你给它配不同 Skill它表现出的专业水平可以天差地别。模型还是那个模型灵魂不一样了干活的质感也就不一样。2.3 Skill 不是越多越好而是越“粒度高”越好刚开始玩的时候我犯过一个经典错误很兴奋觉得 Skill 多多益善就把搜索、总结、翻译、表格生成、文件读写、邮件格式、周报、日报……全塞进去搞了十几个。结果就是Agent 每次选技能的时候比干活还纠结。模型在复杂选择面前出现判断漂移有时候选了搜索却不搜有时候该走格式化却跑去生成摘要最后输出结果乱七八糟。后来我逐渐认识到一个原则Skill 的粒度应该对齐到“一个完整任务”而不是“一个便捷动作”。什么叫完整任务比如“把指定链接列表抓取正文、提取要点、按固定格式生成摘要、输出成 Markdown 文件”。它从输入到输出一条龙有边界有验收标准。什么叫便捷动作比如“格式化当前文本”“翻译当前段落”。这种更适合做工具而不是 Skill。如果一个 Skill 承担太多杂七杂八的事它的说明书会膨胀模型在执行时也会混乱。好的 Skill 是“小而完整”一件事一套规则一个明确输出。你可以围绕同一类目标搭建五六个独立 Skill但别让一个 Skill 内部塞五六个目标。3. 核心机制拆解一次 Skill 调用模型到底在脑子里经历了什么要理解 Skill 为什么值得认真对待得先把一次调用的链路看明白。这里我用 OpenClaw 这类框架的思路讲其实主流 Agent 框架的机制大同小异。3.1 从用户请求到“找到老熟人”当你给 Agent 说了一句“帮我把昨天收藏的文章整理成今日早报”框架内部并不直接执行任何动作。它先做一次检索把用户请求语义化然后去 Skill 列表里匹配“哪一个技能最像能干这件事的”。这个过程你可以理解成一个大厨接到了客人点菜“来份下饭的辣味小炒”。大厨不会立刻翻锅他会先在脑内过一遍菜单宫保鸡丁辣子鸡水煮肉片还是小炒肉然后锁定最接近的那道菜取出对应菜谱开始做。框架也是一样。它要先找到一个和当前需求最匹配的 Skill再去读那个 Skill 的“菜谱”而不是让模型现场发挥、即兴决定每一步逻辑。这一步的价值是把“怎么做”从模型脑子里抽出去固化到一套可复用的流程里。模型不需要每次重新设计任务路径它只需要按既有成熟路径来走。这大大提高了执行稳定性。3.2 执行阶段说明书、状态、动作循环选定 Skill 后框架会把该 Skill 的“说明书”整体塞进模型上下文与用户请求合并然后进入运行循环。这个循环可以概括成三个词读说明书、做动作、汇报结果。读说明书是指模型理解该 Skill 定义的输入结构、处理逻辑、输出格式。比如“今日早报生成器”的说明书会写输入是链接数组输出是分组列表来源一句话摘要可复制 Markdown 文本。做动作是模型一边执行逻辑里的步骤一边调用外部工具或脚本。比如抓取网页正文、清理 HTML 标签、调用摘要接口。框架会在这一步提供“脚手架”允许代码运行时读取环境变量、读写临时文件、发 HTTP 请求。汇报结果是模型把最终产出按照说明书要求的格式返回给用户。这里有一个很多人忽略的细节Skill 内部既可以是“脚本直出”也可以是“模型在脚本辅助下生成内容”。多数情况下它是混合的脚本负责获取原始材料、做工程化处理模型负责提炼、重组、润色、排版等需要理解力的工作。这种分工非常合理。模型不能可靠地算正则表达式但脚本可以脚本不能妥帖地改写一段晦涩的技术论述但模型可以。各干各擅长的活Skill 才真正好使。3.3 退出与记忆干完一件事得让人接管Skill 跑完并不是把结果往屏幕上一丢就完事了。真正成熟的 Skill 会考虑“交接”。什么叫交接就是返回结构化结果同时附上过程状态比如哪些链接抓取失败、哪些步骤超时、有没有生成临时文件在哪个位置、是否需要人工复核。这些信息会被 Agent 拿到用于最终回复用户或者追问下一步。还有一个关联问题Skill 要不要把所有状态都写进长期记忆我的建议是一开始不要。长期的记忆沉淀更适合做成“一个 Skill 完成后把关键产出摘要写入一处轻量记录文件”。因为记忆条目一旦过多模型翻找信息时反而会被干扰。Skill 的职责是“干好当下这件事”不是“成为整个记忆系统的中心”。这就像你公司里的标准化作业部门它负责按流程产出结果但公司知识库另有专岗管理。别把两者搅在一起。4. 从零手写一个 Skill完整实操记录这一节我拿出一个真实做过的练习来走一遍。它没有用到什么花哨技术但对刚入门的你来说刚好能把整个流程看通。目标做一个“链接收藏整理器” Skill。用户丢给它一批网址它能把每个网页的标题、摘要、分类整理出来最后生成一份 Markdown 日报文件。4.1 目录结构与文件准备一个 Skill 通常以独立目录存在命名要体现功能。我习惯的结构link-brief-skill/ ├── MANIFEST.yaml ├── run.py ├── skill.md └── config.json四个文件职责各不同MANIFEST.yaml元信息写清楚这个技能叫什么、描述什么、需要什么依赖、入口文件是哪个、参数有哪些、输出文件写到哪。run.py核心执行脚本负责任务中偏工程化的部分。它可以从标准输入或参数文件读输入做一些数据清洗然后输出中间结果。skill.md给模型看的说明文档。这一步特别关键它不是给人读的注释而是会被模型阅读的“员工手册”。config.json运行参数。比如并发数、超时、是否允许脚本访问网络、默认语言等。4.2 先写 MANIFEST把“身份证”立好下面是一个贴近实际写法的示例。不必完全照搬字段名结构合理即可。name: link-brief description: 将用户提供的网址列表转换为结构化简报输出标题、摘要与分类。 version: 0.1.0 entrypoint: run.py parameters: links: type: array required: true description: 网址数组例如 [https://example.com/a, https://example.com/b] category_rules: type: object required: false description: 可选的自定义分类规则 output: format: markdown path: output/brief.md dependencies: - requests - beautifulsoup4MANIFEST 是给框架调度层用的。框架靠它决定“这个技能要不要被召出”。所以描述字段别写什么“一个工具集合”要写清楚“能完成什么任务、需要什么输入、产出什么结果”。4.3 写 skill.md相当于给模型做岗前培训这是我最想强调的部分。很多新手写 Skill写完代码就跑完全不给模型写“说明书”结果模型根本不知道怎么配合脚本工作。一个好的 skill.md至少要回答这几个问题这个技能用来做什么用户可能以什么方式提出需求执行前需要向用户确认什么信息内部脚本怎么调用输出格式长什么样什么情况算失败失败后怎么处理下面是简化示例# 链接简报生成技能 ## 用途 接收一组网页链接读取每个网页的标题、描述性内容并按用户要求分类最终生成 Markdown 格式简报。 ## 输入样例 - 用户可能说“看看这些链接给我生成一个技术早报” - 也可能直接提供链接列表逗号分隔或换行 ## 执行步骤 1. 从用户消息中提取全部链接。 2. 调用 run.py传入链接数组。 3. run.py 会返回一个 JSON包含每篇网页的 title, summary, source。 4. 检查 JSON 中 failed 字段如有失败项向用户说明。 5. 按分类规则分组生成 Markdown 简报。 6. 将简报写入 output/brief.md。 ## 注意事项 - 分类默认按关键词匹配AI、前端、后端、工具、商业、其他。 - 若链接少于 3 个直接输出未分组清单不要硬造分类。 - 摘要控制在三句话以内第一句必须回答“这篇文章讲了什么”。 - 不要把原始网页全文复制进简报。这份文档写得好不好直接影响 Agent 的执行质量。你可以试出来一个规律文档写得越细模型的动作越稳。4.4 用 Python 写执行脚本承担脏活累活run.py 的职责是接收链接、抓取页面、清理 HTML、尽量提取标题和摘要片段把结构化结果写出来。大致逻辑import argparse import json import requests from bs4 import BeautifulSoup def fetch_meta(url, timeout10): resp requests.get(url, timeouttimeout, headers{ User-Agent: Mozilla/5.0 (compatible; BriefBot/1.0) }) soup BeautifulSoup(resp.text, html.parser) title soup.title.string.strip() if soup.title else desc_tag soup.find(meta, attrs{name: description}) summary desc_tag[content].strip() if desc_tag and desc_tag.get(content) else return {url: url, title: title, summary: summary} def main(links): results [] for link in links: try: results.append(fetch_meta(link)) except Exception as e: results.append({url: link, title: , summary: , failed: str(e)}) return results if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--links, typejson.loads, requiredTrue) args parser.parse_args() print(json.dumps(main(args[links]), ensure_asciiFalse))这里有个细节脚本只负责抓取和提取基础信息不要让它承担“整理成漂亮日报”的工作。让模型去思考分类逻辑和排版脚本只保证“原材料是干净的”。4.5 本地调试的几种姿势写完以后不要急着一上来就丢给 Agent 用。先在终端里单独验证脚本。一种手动验证方式python run.py --links [https://example.com/post1, https://example.com/post2]脚本会打印 JSON。确认抓到的标题正常、编码不混乱、超时能捕获。然后你再去调 Agent 接口让模型尝试按 skill.md 的步骤走几轮。我强烈建议你把调试分成两段先验脚本再验联动。脚本都跑不稳的 Skill加再多模型也别想稳。5. Skill 开发避坑记录五个最容易翻车的地方这部分是我自己的血泪教训如果你打算长期做 Agent能帮你省下好几晚的排查时间。5.1 陷阱一把 Skill 写成一个“上帝函数”新手最容易犯的错是希望一个 Skill 包罗万象。举个例子我有一个朋友做了个“全能写作助手”Skill既能写公众号又能写周报又能写邮件还兼职做 PPT 大纲结果就是每个功能都不稳定。原因很简单模型在读说明书的时候要同时理解多个场景的规则执行路径变多判断负担变重。一旦遇到两个场景边界重叠的情况模型很容易张冠李戴。正确做法一个 Skill 只对应一个明确任务域。宁可拆成“公众号文章生成”“周报生成”“邮件撰写”三个独立 Skill也别合三为一。5.2 陷阱二忽略上下文窗口的物理限制有人写 skill.md 时特别嗨洋洋洒洒三千字把自己所有经验都写进去。结果模型一加载说明文档连用户的原始请求都快放不下了。上下文窗口是有限的。Skill 文档不要追求“详尽”要追求“关键信息密度高”。一件事怎么写最省 token是基本功。我的习惯skill.md 控制在 800 到 1500 字以内用短句、列表和紧凑示例把路标立好。5.3 陷阱三密钥和敏感信息直接写进脚本这个坑我劝所有读者都别碰。Skill 代码里如果出现硬编码的 API Key、内部系统地址、密码一旦被以 Skill 的形式分享出去等于把钥匙挂在大门口。正确做法一律从环境变量或框架的配置中心读取。比如import os api_key os.getenv(API_KEY)如果你要提交到公共仓库做示例这一步更要严格。曾经就有团队因为“内部演示用 Skill”里带着真实密钥结果仓库公开后酿成不小的事故。5.4 陷阱四不写异常出口失败时模型当场表演“人工智障”没有异常处理的 Skill最典型的表现是URL 打不开、接口超时、字段缺失模型不知道怎么办只能胡编一个结果或者干脆卡死。在 skill.md 里一定要写清楚“失败路径”## 异常处理 - 如果某个链接抓取超时不要编造内容标记为“抓取失败”。 - 如果一条链接没有正文可以跳过但要在输出中保留该链接。 - 如果所有链接全部失败输出“无可用内容”建议用户检查网络或链接有效性。你给模型留了后路模型才不会在紧急关头给你写一篇“用爱发电”。5.5 陷阱五版本管理意识缺失Skill 也是代码它也会迭代。今天改一个抓取逻辑明天加一个摘要规则过两周你就忘了哪个版本是能用的。所以我建议一个 Skill 目录里保留 CHANGELOG 文件或者至少把版本号写进 MANIFEST。每次改动都要更新版本号这样出问题的时候能快速回退。别嫌麻烦等你在生产环境里被一个隐性改动坑到凌晨两点就会明白版本号的价值了。6. 如何规划你自己的 Skill 库从“会写”到“会设计”理解了 Skill 的机制会写一个 Demo下一步就是考虑怎么给自己的 Agent 规划一组恰到好处的 Skill6.1 先盘任务再盘技能很多人是先做一堆 Skill再想它们能干嘛这是反的。正着走应该是先列任务清单。找一个连续三天把你打算让 Agent 干的活全部记下来哪些是你每天都重复的哪些是每周一两次的哪些是需要标准流程的哪些是即兴发挥也能接受的。以我自己的经历一份可以落地的清单可能长这样每天早上收集指定领域的新文章生成摘要列表把长文章按固定结构拆成知识点笔记把零散想法整理成每周复盘稿把会议记录转成待办事项把收集的数据快速生成对比表格然后你就能很自然地分出优先级高频且流程固定的先做 Skill。6.2 “效率优先”还是“通用优先”两个设计取向做 Skill 的时候有两个方向可以走一个是效率优先。意思是把默认参数、输出模板、偏好风格全部提前固化让 Agent 一步到位直接产出。适用场景你非常清楚自己需要什么格式。比如周报必须有“本周进展、问题、下周计划”三个板块那就写死在规则里。另一个是通用优先。意思是 Skill 只负责“核心动作 结构化输出”但具体风格、格式、详略程度由模型根据用户需求临时调整。适用场景你还在探索自己的需求不确定哪种输出最顺手。如果你刚开始我建议先做成效率优先的一周后再看哪个地方卡住、哪个地方不灵活再适当放宽。松弛感太早Research 阶段就会无限拉长。6.3 命名与标签这也是 Skill 库运营的一部分Skill 多了以后检索和调度会出现一个新问题名字像、功能近模型容易混淆。我复盘过一个案例一位开发者做了“网页摘要”和“网页简报”两个 Skill结果描述高度相似导致模型经常把用户需求路由到错误的那边。所以命名阶段就做区分摘要偏向“单篇内容提炼要点”简报偏向“多篇汇总分组并生成报表”。写 description 的时候要刻意覆盖自己的边界明确写出“这个技能不做什么”。这种负向描述有时比正向描述更有效。6.4 定期淘汰Skill 也会过气最后Skill 库要定期清理。有些 Skill 你曾经很兴奋用了一个月后发现流程变了它就没用了。与其当一个永远不动的“收藏品”不如删掉或者归档。我自己的周期是每月底翻一遍 Skill 清单看调用频率和效果。连续 30 天没被调用、或每次调用都需要大量修正的 Skill直接标记为待废弃。这样做不只是节省空间更是为了保证 Agent 在做技能选择时不因那些冗杂项分散注意力。你给模型留的选项越精简它做出的判断就越可靠。7. 一点个人体会Skill 是慢功夫但它值得投入如果说这段时间玩 Agent 给了我什么最深刻的教训那就是别迷信模型本身的神通别迷信工具的丰富度真正决定一个 Agent 好不好用的是你有没有耐下心来给每一个任务铺设扎实的执行路径。Skill 的打磨过程很像传统软件工程里“代码重构”的感觉第一版往往能跑但很脆你不断修剪颗粒度、补异常路径、调文档措辞它才会越来越皮实。这个过程中你不只是在写代码你是在把你对“怎么做一件事”的隐性理解一点点外化成 Agent 能跟随的路标。最后分享一个小技巧每次你为一个 Skill 写好 skill.md 以后不妨自己先假扮“那个被培训的模型”按文档走一遍流程把不理解、有歧义的地方标出来改掉。这个过程很笨但效果出奇地好比自己对着终端跑十遍测试更能发现设计上的漏洞。Skill 不是银弹它不会让你的 Agent 变成全能超人。但如果你正在为“Agent 动不动跑偏”发愁认真梳理一圈 Skill 设计大概率能解决其中八成问题。这活儿急不来但它绝对是值得你投入时间的地方。