如果你最近关注 AI 编程、AI Agent 或者大模型应用开发大概率会反复看到一个词Skill。这次我们直接把这个概念讲清楚Skill 在 AI Agent 体系里到底扮演什么角色它和 Function Calling、Prompt 模板、Plugin 有什么区别实际开发中怎么定义一个 Skill以及一个带 Skill 的 Agent 工作流跑起来是什么样子。先说结论Skill 不是新的模型也不是新的训练方式而是一种把“完成特定任务所需的能力”打包成可供 Agent 调用单元的方法。它本质上是在给大模型配一套“可复用的方法论 工具集 执行流程”。如果你写过传统软件里的模块化代码再来看 Skill接受成本会低很多。这篇文章会用文字描述、代码示例、调用流程和排查思路尽量把 Skill 这个概念拆到能直接上手的程度。1. 核心能力速览能力项说明项目类型AI Agent 技能封装与调用机制属于应用层能力设计核心价值将复杂任务拆解为可复用、可编排、可验证的技能单元主要功能技能定义、技能调用、技能编排、技能复用、技能测试与大模型关系依赖 LLM 做推理和生成Skill 负责提供上下文、规则、工具与输出格式与 Function Calling 区别Function 更偏向单次结构化调用Skill 偏向包含多步流程和领域知识的完整能力包支持平台不依赖特定平台可在 OpenAI、Anthropic、开源模型、本地部署框架中设计实现启动方式无独立启动程序通常在 Agent 框架中加载或作为 API 服务的一部分运行是否支持 API取决于承载 Skill 的 Agent 框架可封装为 HTTP 接口或内部函数调用是否支持批量任务可通过批量请求、异步队列、任务编排实现需结合实际框架设计适合场景代码生成、文档处理、数据分析、自动化测试、客户支持、知识库问答等从表格可以看出Skill 并不是一个开箱即用的软件产品而是一种工程模式。你真正需要做的是在自己的 Agent 应用里设计、实现、注册并调用 Skill让大模型在特定任务上表现得更稳定、更专业。技能调用这个概念在 AI Agent 开发中之所以重要是因为大模型本身有明确短板上下文有限、对私有工具一无所知、输出格式不稳定、复杂任务容易中途跑偏。Skill 通过“把任务流程和领域规则显式写出来”来缓解这些问题。2. 适用场景与使用边界2.1 适合谁用Skill 最适合以下几类同学正在做 AI Agent 应用开发的工程师希望让 Agent 在特定任务上有稳定输出。想在企业内部落地知识库问答、报表生成、自动化文档处理等场景的技术负责人。研究 Agent 架构和模型工作流的算法工程师需要一种可复用的任务抽象方式。使用 Claude、GPT 等模型做复杂任务编排的进阶用户想让模型按固定步骤执行。2.2 能解决什么问题Skill 的价值集中体现在四个方面第一让复杂任务可拆解。比如“根据财报生成分析报告”这个任务可以拆成数据提取、指标计算、图表生成、结论归纳四个子技能。每个技能单独开发和测试最后用编排逻辑串起来比让模型一次性完成更可控。第二让领域知识可沉淀。模型训练时并不知道你们公司的报销制度但你可以写一个“报销审核 Skill”里面包含制度规则、审核步骤、常用话术、退回原因枚举等。这样模型执行这个任务时就不再是自由发挥。第三让输出格式更稳定。Skill 可以在定义里指定严格的 JSON 结构、Markdown 模板或代码风格大幅减少“返回了一堆能看但不能用的内容”的情况。第四让工具调用更规范。把外部 API、数据库查询、文件读写等操作封装在 Skill 内部统一处理异常和重试Agent 主逻辑会干净很多。2.3 不适合什么场景简单的单轮问答没必要用 Skill直接 Prompt 就够。对实时性和随机性要求极高的场景Skill 的固定流程可能反而成为限制。如果任务本身没有明确步骤和规则强行抽象 Skill 会很痛苦。不要指望 Skill 能替代模型本身的推理能力它做的是“约束和增强”不是“无中生有”。2.4 使用边界与合规提醒Skill 本质上是给大模型“配上执行手册和工具箱”本身不存在安全问题但在实际使用中必须注意涉及人脸、声音、隐私数据、企业内部资料时要确保数据来源合法避免侵犯个人隐私和商业秘密。如果 Skill 被设计用于自动操作外部系统例如发邮件、提交订单、发布内容必须增加人工确认机制。不要用 Skill 自动化生成违法、侵权、虚假信息或绕过安全限制的内容。对外提供服务前需要对 Skill 的输出做审核和测试尤其是面向公众的场景。发布 Skill 或开源 Skill 时注意检查其中是否包含敏感数据、密钥、内网地址等信息。3. 环境准备与前置条件Skill 本身不是一个大模型不需要 GPU也不需要特定服务器。它的运行环境取决于你把它放在哪个 Agent 框架里。3.1 操作系统Windows、macOS、Linux 都可以。如果你主要在本地做实验Windows 和 macOS 足够如果要部署为线上服务建议使用 Linux 服务器。3.2 语言与依赖目前主流的 Agent 开发语言是 Python 和 TypeScript。Python 生态在 AI 领域最完整TypeScript 则在 Web 集成和前端工具链上更顺手。你可以根据自己的技术栈选择。以 Python 为例常见的依赖包括# 通用依赖具体版本按实际框架调整 pip install openai anthropic pydantic fastapi uvicorn如果你使用本地模型还可能需要pip install transformers torch accelerate3.3 模型服务Skill 的推理部分依赖大模型接口。你可以选择OpenAI 系列模型Anthropic Claude 系列模型本地部署的开源模型例如 Qwen 系列、Llama 系列各类兼容 OpenAI 协议的模型服务如果你在本地测试更稳妥的做法是先跑通一个支持 OpenAI 兼容接口的模型服务再在 Agent 中把 base_url 指向本地地址。这样可以反复调用、调试 Skill而不产生额外费用。3.4 硬件门槛如果你只是开发 Skill 逻辑调用云端模型 API普通开发机就够CPU 即可不需要独立显卡。如果你想本地运行开源模型并让模型稳定执行 Skill 流程建议至少 16GB 内存显卡显存则以实际模型规模为准。比如 7B 级别的模型量化后大概需要 6GB 到 8GB 显存14B 以上则建议 16GB 起步。这个数据只是参考实际占用需要根据模型格式、推理框架、上下文长度来测试。3.5 其他前置条件准备好模型 API Key或者本地模型服务的地址和端口。确认网络环境能访问模型 API或在局域网内部署模型服务。预留磁盘空间存放代码、模型缓存和日志文件。了解基本的 JSON 和 Markdown 结构因为 Skill 定义通常用这两种格式编写。4. 从概念到落地理解 Skill 的完整定义在写代码之前我们先用一个完整抽象来理解 Skill 到底是什么。Skill 的定义可以拆成五个部分技能名称告诉 Agent 这个技能叫什么用于触发和路由。技能描述用自然语言描述这个技能适合什么任务模型会依据描述决定是否调用。参数定义声明调用该技能需要哪些输入类似函数签名。执行逻辑技能内部做了什么包括调用工具、操作数据、生成内容。输出规范返回值是什么格式后续流程如何继续。一个 Skill 的完整生命周期包括定义、注册、触发、执行、输出、反馈。Agent 在实际任务中会根据用户请求判断调用哪个 Skill然后把控制权交给 Skill等 Skill 返回结构化结果后再继续主对话。这里要特别区分 Skill 和常见的 Function CallingFunction 是一个独立可执行函数一般描述清楚参数就能调用。Skill 通常包含多个步骤需要依赖外部工具、领域知识或上下文状态。Function 是“一次性动作”Skill 是“一整套方法”。Function 适合天气查询、计算器等确定性操作Skill 适合代码审查、报告生成、数据分析这类过程性操作。下面给出一个 Skill 定义的通用 JSON 示意{ name: code_review_skill, description: 对一段 Python 代码进行静态审查识别错误、隐患和可读性问题并给出修改建议, parameters: { type: object, properties: { code: { type: string, description: 待审查的代码文本 }, language: { type: string, enum: [python, javascript, java, go], default: python }, strictness: { type: string, enum: [low, medium, high], default: medium } }, required: [code] }, execution_steps: [ 解析输入代码判断语言类型, 检查语法错误和常见反模式, 评估代码复杂度和可读性, 生成审查建议按严重程度分类, 输出结构化报告 ], output_format: { type: object, properties: { summary: {type: string}, issues: { type: array, items: { type: object, properties: { severity: {type: string}, line: {type: integer}, message: {type: string}, suggestion: {type: string} } } } } } }这段 JSON 描述了一个“代码审查技能”。注意它的重点不在具体实现代码而在于告诉模型和框架这个技能是什么、需要什么输入、内部怎么执行、最终返回什么。真正的代码逻辑由 Skill 函数实现。5. 实现一个可运行的 Skill入门实例接下来我们用一个 Python 示例演示 Skill 的最小实现。这里不绑定任何特定框架直接用模型 API 加简单的函数分发来模拟 Agent 调用 Skill 的过程。5.1 场景说明我们定义一个“会议纪要生成 Skill”。输入是会议记录的原始文本输出是结构化的会议纪要包含会议主题、讨论要点、决策项、待办事项。5.2 核心代码import json from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlYOUR_BASE_URL ) SKILLS {} def register_skill(name, description): def decorator(func): SKILLS[name] { description: description, func: func } return func return decorator register_skill( meeting_minutes, 将会议原始文本整理为结构化会议纪要包含会议主题、讨论要点、决策项和待办事项 ) def generate_meeting_minutes(text: str, language: str zh) - dict: 执行会议纪要生成 Skill。 实际工程中这里可以调用大模型、模板引擎或外部工具。 prompt f 你是一个会议纪要整理助手。请根据以下会议记录生成结构化纪要。 输出格式要求 {{ meeting_topic: 会议主题, discussion_points: [讨论要点1, 讨论要点2], decisions: [决策1, 决策2], action_items: [ {{task: 待办事项, owner: 负责人, due_date: 截止日期}} ] }} 会议记录 {text} response client.chat.completions.create( modelYOUR_MODEL_NAME, messages[ {role: system, content: 你负责根据输入生成结构化会议纪要。}, {role: user, content: prompt} ], temperature0.2 ) content response.choices[0].message.content # 实际项目中需要做健壮解析这里简化处理 return json.loads(content) def route_to_skill(skill_name: str, **kwargs): 根据技能名称分发给对应的 Skill 函数 skill SKILLS.get(skill_name) if not skill: raise ValueError(fSkill not found: {skill_name}) print(f[Agent] 调用技能: {skill_name}) result skill[func](**kwargs) print(f[Agent] 技能返回结果: {json.dumps(result, ensure_asciiFalse)}) return result if __name__ __main__: meeting_text 项目周会记录 1. 讨论了用户反馈模块加载慢的问题。 2. 决定在下一版本中引入缓存机制。 3. 张三负责后端缓存开发预计周五完成。 4. 李四负责前端加载体验优化下周一交付。 route_to_skill(meeting_minutes, textmeeting_text)在这个例子中Skill 被封装成一个注册函数。Agent 拿到用户输入后先判断应该调用哪个 Skill再通过route_to_skill分发执行。这是 Skill 机制最简单的形态生产环境通常会用更完整的 Agent 框架来做意图识别和参数提取。5.3 与真正的 Agent 框架结合上面的例子是手动路由。在更成熟的 Agent 框架里模型会根据函数描述自动决定调用哪个 Skill。伪代码思路如下tools [ { type: function, function: { name: meeting_minutes, description: 将会议原始文本整理为结构化会议纪要, parameters: { type: object, properties: { text: {type: string, description: 会议记录原文}, language: {type: string, enum: [zh, en]} }, required: [text] } } } ] response client.chat.completions.create( modelYOUR_MODEL_NAME, messages[ {role: user, content: 请把这个会议记录整理成纪要... } ], toolstools, tool_choiceauto )当模型认为当前任务需要会议纪要技能时会返回一个 tool_call其中包含技能名称和参数。应用层收到 tool_call 后执行对应函数再把结果追加到对话中形成一次完整的工具调用闭环。这种模式是当前 AI Agent Skill 最常见的基础形态。6. Skill 在真实 AI Agent 工作流中的位置很多人搞不清 Skill 和 Agent 的关系。一句话说明Agent 是决策者Skill 是执行者。Agent 负责理解目标、拆分任务、决定调用顺序Skill 负责把具体任务高质量地完成。一个典型的 Agent 工作流是这样的用户提出目标。Agent 对目标做意图理解和任务拆分。Agent 根据任务选择合适 Skill。Skill 内部执行工具调用、数据计算、内容生成。返回结构化结果给 Agent。Agent 汇总结果组合成最终回复。如果某个 Skill 执行失败Agent 可能选择重试或换一条路径。在这个工作流中Skill 的价值是“可插拔”。你要增加新能力不需要改 Agent 主逻辑只需要注册一个新 Skill。这个设计让 Agent 的能力边界可以持续扩展。从架构上看Skill 层通常位于模型层和业务系统之间。模型提供推理能力业务系统提供数据和操作入口Skill 则承载“知道在什么场景下怎么做”的知识。这也是它比单纯 Function Calling 更重、更复杂的原因。7. Skill 的分类与设计模式Skill 不是只有一种写法。根据任务特点我们可以把 Skill 分成几类。7.1 内容生成类这类 Skill 主要依赖大模型本身的能力任务是把用户输入转化为特定格式的内容。例如产品文案生成技术文档编写代码注释生成报告摘要生成设计重点Prompt 模板、输出格式、风格控制、语言控制。7.2 工具操作类这类 Skill 需要调用外部系统或 API。例如发送企业微信通知查询数据库调用第三方翻译接口操作文件系统设计重点参数校验、错误处理、鉴权方式、超时重试、幂等性。7.3 数据加工类这类 Skill 以结构化数据处理为主。例如清洗 CSV 数据转换 JSON 格式计算关键指标生成图表设计重点输入输出 schema、处理流程、异常值处理、结果预览。7.4 组合编排类这类 Skill 内部包含多个子技能。例如“生成周报”可能包含收集本周提交记录统计任务完成情况生成文本总结生成附件设计重点子任务顺序、上下文传递、部分失败处理、幂等和重试。推荐的做法是让 Skill 小而专然后在编排层组合成更大能力。这样测试和迭代成本最低。如果把所有逻辑塞进一个巨大 Skill一旦输出不稳定排查会非常痛苦。8. Skill 的接口 API 与批量任务设计Skill 本身可以是一个 Python 函数也可以暴露成一个 HTTP 服务。为了便于工程集成推荐把 Skill 封装为 API 接口然后用批量任务队列处理大规模请求。8.1 封装为 FastAPI 服务from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class MeetingMinutesRequest(BaseModel): text: str language: str zh class MeetingMinutesResponse(BaseModel): meeting_topic: str discussion_points: list[str] decisions: list[str] action_items: list[dict] app.post(/skill/meeting_minutes, response_modelMeetingMinutesResponse) def meeting_minutes_api(req: MeetingMinutesRequest): result generate_meeting_minutes(req.text, req.language) return result启动方式uvicorn main:app --host 127.0.0.1 --port 8000这样 Skill 就变成一个可调用的接口服务。前端、后台、自动化脚本都可以直接调用。8.2 批量任务设计批量任务最常见的方式是把输入放到队列中逐个调用 Skill 接口并保存结果。这里给出一个使用 Python 脚本批量处理文本的示例import json import requests import time input_items [ 会议记录A..., 会议记录B..., 会议记录C... ] results [] for idx, text in enumerate(input_items): try: resp requests.post( http://127.0.0.1:8000/skill/meeting_minutes, json{text: text, language: zh}, timeout60 ) resp.raise_for_status() results.append(resp.json()) print(f[{idx 1}/{len(input_items)}] 成功) except Exception as e: print(f[{idx 1}/{len(input_items)}] 失败: {e}) results.append({error: str(e), input: text}) time.sleep(0.5) with open(outputs.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这个示例虽然简单但包含了批量调用的基本要素遍历输入、逐个请求、异常捕获、结果落盘。生产级任务队列通常还要引入 Redis、Celery 或异步消息中间件但原理是一样的。更稳妥的批量任务设计建议每个任务要有唯一 ID方便追踪状态。失败任务要自动重试但需要设置最大重试次数。写入结果时采用追加模式避免全部任务结束后才发现某个结果丢失。控制并发数避免把模型服务打满导致超时。保存输入快照便于复现和排查。9. 资源占用与性能观察Skill 本身不消耗太多资源真正的资源消耗来自三部分模型推理、工具调用、数据读写。9.1 观察哪些指标当你测试一个带 Skill 的 Agent 应用时建议重点观察单次 Skill 调用的延迟从触发到返回结果的时间。模型推理的 Token 消耗Skill 定义越长、上下文越大Token 成本越高。外部 API 的响应时间如果 Skill 内部调用了第三方服务这部分往往是性能瓶颈。并发请求时的资源占用CPU、内存、网络连接数。9.2 如何降低开销Skill 的 Prompt 模板尽量精简不要把所有历史知识都塞进去。工具调用结果要缓存尤其是数据不经常变动的查询。批量任务使用异步方式避免串行等待。对模型输出做缓存相同输入直接返回历史结果。如果模型服务支持流式输出优先开启流式提升用户体验。9.3 显存与推理资源使用云端模型 API 时本地不承担推理压力普通开发机足够。使用本地模型时显存占用主要由模型大小和输入长度决定。如果你发现显存占用过高可以通过减少上下文长度、使用量化模型、降低 batch size 来缓解。不要轻信“某个模型实际占多少 G 显存”的说法同一模型在不同推理框架、不同量化精度、不同显卡驱动下表现可能差很多。最可靠的方式是自己在目标机器上跑一次真实任务用nvidia-smi观察峰值占用。10. Skill 常见问题与排查方法问题现象可能原因排查方式解决方案模型不调用 SkillSkill 描述不清晰模型无法判断何时使用检查 Skill 描述是否包含触发场景、输入示例重写描述增加具体场景关键词模型调用 Skill 时参数缺失参数定义不合理或模型理解偏差查看模型返回的 tool_call 参数内容增加必填参数校验补全省略规则Skill 返回 JSON 解析失败模型输出包含多余文本或格式不规范打印原始输出检查前后缀使用结构化输出约束或增加清洗逻辑本地模型执行 Skill 不稳定模型指令遵循能力偏弱对比云端强模型是否正常简化 Skill 步骤降低指令复杂度API 调用超时模型推理慢或网络延迟查看服务日志和调用链耗时增大超时时间开启流式减少并发批量任务中途失败输入数据异常或服务崩溃检查失败任务日志保留输入快照增加重试机制导入断点续跑端口冲突多个服务占用同一个端口查看监听端口更换端口或复用统一服务入口密钥泄露风险Skill 定义中包含硬编码密钥代码审计和扫描使用环境变量和密钥管理服务调试 Skill 有一个通用思路先固定输入再逐步放宽。先用一个最简单的输入测试 Skill 是否被触发确认触发后再测试参数提取最后测试完整流程。这样定位问题时能把模型问题、代码问题和外部依赖问题分开。11. Skill 最佳实践与工程化建议11.1 Skill 命名与描述规范Skill 描述是模型判断是否调用的核心依据要具体不要抽象。比如不要写“帮助用户处理文件”而要写“将用户上传的 CSV 文件按指定列聚合统计并生成表格适用于数据清洗和报表场景”。描述里可以包含输入示例和典型触发词这会明显提高触发准确率。11.2 输出格式强约束在 Skill 的设计阶段就确定输出 Schema用 JSON 或 Markdown 模板约束模型输出。输出格式不稳定是 Skill 在生产环境失败的主要原因不能等到上线后再补救。11.3 日志与可观测性每个 Skill 调用都要记录输入参数模型返回的原始内容解析后的结果耗时是否重试失败原因没有日志Skill 出问题就是黑盒。建议从一开始就建立结构化日志而不是等事故出现后再补。11.4 版本管理Skill 同样需要版本管理。你修改一个 Prompt 模板或工具调用逻辑可能会影响所有下游任务。建议把 Skill 定义文件纳入 Git 管理并在发布时记录版本号。11.5 灰度与回滚上线一个新 Skill 前先用小流量测试。如果效果稳定再逐步放大。出现问题时要能快速回滚到上一个版本。不要在生产环境直接大批量替换核心 Skill。11.6 合规与安全这是最容易忽略的一条。Skill 可能让模型访问企业内外部系统、读取敏感文件、执行代码。权限设计要遵循最小化原则。涉及外部操作时要有人工确认环节。涉及用户数据和肖像内容时必须获得合法授权。对外输出内容需要经过审核尤其是生成公告、合同、法律文书等高风险场景。12. 总结与下一步Skill 是 AI Agent 从“会聊天”走向“会干活”的关键设计。它的核心思路不复杂把大模型的任务执行经验、领域规则、工具调用过程封装成可复用单元。难的是工程化落地包括描述设计、参数定义、稳定性测试、批量处理和权限安全。如果你刚开始了解 Skill建议先做三件事第一在现有模型 API 的 tools 机制里定义两个最简单的 Skill比如“会议纪要生成”和“JSON 格式化输出”跑通一次完整的 tool_call 调用闭环。第二找一个实际工作中的高频任务尝试拆解成子步骤写成 Skill 描述和执行逻辑验证它是否比直接写 Prompt 更稳定。第三逐步把 Skill 从单函数调用升级为 FastAPI 接口再接入批量任务队列为生产环境做准备。最容易踩的坑是“一上来就想把所有任务都做成 Skill”。Skill 的数量不是越多越好每个 Skill 的设计、测试和维护都有成本。先从两三个高频、边界清晰的任务开始验证流程跑通后再逐步扩展。后续扩展方向可以是让 Agent 根据用户反馈自动优化 Skill 模板、把常用 Skill 发布到团队内部共享仓库、把 Skill 执行结果接入数据报表系统、以及把 Skill 和 RAG 知识库组合形成更完整的企业级智能应用。Skill 的本质是把“怎么做好一件事”沉淀为可复用的软件资产。这个概念理解透了后面再接触 Claude Skill、OpenAI 自定义工具、各类 Agent 框架时会顺畅很多。