Agent Skills实战：从工具调用到技能封装与调度

如果有人问你“Agent 应用开发最头疼的是什么”做过实际项目的同学大概率会说出同一个词不确定性。模型输出不稳定、工具调用格式飘忽、换个业务场景就要重新写一遍调度代码、提示词稍微调一下就可能把整个链路带崩。这些问题不是靠“把 Prompt 写得更好”就能解决的它需要一个更结构化的东西来承担“能力复用”和“行为约束”。这个被越来越多人提到、也开始被主流 Agent 开发框架反复强调的方案就是 Agent Skills。这篇文章不打算只停留在概念层面。我会从“Agent 开发到底乱在哪”开始讲清楚 Agent Skills 究竟是什么、它和 Tool/Plugin/Function Calling 的区别在哪里再通过一个可运行的代码示例演示技能封装、Agent 调度和项目落地这三个关键环节。目标很直接让你看完之后能回到自己的项目里立刻动手把现有 Agent 重构出一版带 Skills 的架构。1. 这篇文章真正要解决的问题先看两个开发场景。第一个场景你负责公司内部的智能客服 Agent。业务方今天说“需要支持查订单”你写了一个查询订单的 Tool明天说“需要支持退换货”你又写一个退换货 Tool。功能是都上线了但很快你会发现每个 Tool 背后跟着一堆 Prompt、参数校验逻辑、异常回退逻辑和上下文处理代码。新同学接手时根本分不清哪些 Prompt 是给模型看的、哪些逻辑是给业务用的。第二个场景你基于某个开源 Agent 框架做了一个文档分析助手核心能力是“读 PDF、提取关键信息、生成摘要”。过了一个月产品经理说“能不能也支持 Word 文档”你发现要改动的不只是一个文件读取函数而是整个 Agent 的提示词、工具注册列表、结果解析逻辑甚至是模型调用参数。这类问题是纯写代码解决不了的结构问题。Agent Skills 要解决的就是这种“能力如何在 Agent 体系里被标准化定义、被稳定调用、被低成本复用”的问题。它不是一个新的模型也不是一个新的框架而是一套组织 Agent 能力的方案。你可以把 Skill 理解为“一个带自描述信息的原子能力包”它既包含让模型知道怎么用它的提示词也包含真正执行任务的 Python 代码还包含对输入输出的校验逻辑。读完这篇文章你会得到三个东西一套判断标准知道什么能力适合封装成 Skill什么能力应该继续留在 Agent 主流程里一套代码模板能直接照着写自己的 Skill一套工程思路知道在真实的项目里Skill 的注册、调度、监控和版本管理应该怎么设计。2. Agent Skills 的核心概念与适用场景2.1 从 Tool 到 Skill能力抽象层级的变化过去两年Agent 开发最普及的模式是 Tool工具模式。开发者定义一组函数把函数名、参数描述和 JSON Schema 告诉模型模型在需要的时候选择调用哪个函数。这个模式有效但它有天花板Tool 本质上是“函数级别的能力声明”它适合处理简单、边界清晰的单次任务。一旦任务涉及多步骤、需要领域知识、需要处理特殊输入格式Tool 就会变得非常单薄。举例来说一个“获取天气”的 Tool 很容易写函数接收城市名返回天气数据完事。但一个“撰写技术博客初稿”的能力如果做成 Tool你需要定义多少参数文章主题、目标读者、篇幅、风格倾向、参考资料、是否包含代码示例……任何一个参数的解析错误都可能导致输出质量断崖式下滑。Skill 的思路是把这些参数、逻辑、提示词和校验规则打包在一起像“插件”一样挂到 Agent 身上。它解决的不是“怎么把函数描述写得更好”而是“怎么让 Agent 具备某项完整能力且能力内部的细节不污染主流程”。2.2 Agent Skills 的组成结构一个标准的 Agent Skill 通常包含三个核心部分组成部分作用类比技能描述Skill Description让模型知道这个技能在什么场景下使用、输入输出是什么、有什么限制招聘 JD提示词与规则Prompts Rules约束模型在执行该技能时的行为方式、输出格式、注意事项员工手册执行代码Implementation实际完成任务的 Python 代码负责处理输入、调用外部 API、返回结构化结果具体干活的人理解这个结构就理解了一个关键问题Skill 和 Function Calling 到底什么关系答案是Skill 建立在 Function Calling 之上它是对 Function 的进一步封装。底层仍然是“模型输出结构化的函数调用参数”但上层多了提示词管理和上下文控制。模型先通过技能描述来决定“是否选用这个技能”再由技能内部的提示词规则来指导“怎么调这个技能”最后才落到具体函数的执行。2.3 什么场景最适合用 Agent Skills从项目实践看Agent Skills 在以下场景收益最大第一高频复用的垂直能力。比如代码审查、SQL 生成、文档格式化、数据清洗。这类能力在不同项目里都会用到封装成 Skill 之后可以跨 Agent 复用。第二强规则约束的业务流程。比如银行开户信息校验、医疗文本脱敏、法律文书格式检查。这类任务不允许模型自由发挥Skill 里的规则可以强制输出符合规范。第三多 Agent 协作场景。主 Agent 负责理解用户意图把任务分发给不同的 Skill Agent 执行。Skill 的标准化接口可以让调度方不关心内部实现。第四领域知识密集的任务。比如前文提到的“人文社科混合研究方法论文写作”。这类任务通常需要 AI Agent 掌握方法论、文献综述、数据分析和论文写作规范如果把这些能力拆成不同的 Skill论文写作 Agent 就可以按需调用而不是把所有知识塞进一个超长系统提示词里。3. 环境准备与前置条件为了把后面的示例跑通你需要准备以下环境。版本以实际项目为准本文重点演示通用思路。3.1 基础环境Python 3.10 或更高版本。Agent Skills 的实现用到了较多类型标注和异步编程特性低版本 Python 会遇到兼容问题。一个可用的 LLM API。本文示例以 OpenAI 兼容接口为例你可以替换成任何兼容 OpenAI SDK 的模型服务包括本地部署的模型网关。已验证的 Python 依赖如下openai1.30.0 pydantic2.0.0 pyyaml6.0 rich13.7.0安装命令pip install openai pydantic pyyaml rich3.2 项目目录结构我们用一个最小可运行的 Agent Skills 项目来演示。项目名称叫skill-agent-demo结构如下skill-agent-demo/ ├── skills/ │ ├── __init__.py │ ├── base.py │ ├── markdown_formatter/ │ │ ├── __init__.py │ │ ├── skill.py │ │ └── prompts.py │ └── sql_expert/ │ ├── __init__.py │ ├── skill.py │ └── prompts.py ├── agent/ │ ├── __init__.py │ ├── registry.py │ ├── dispatcher.py │ └── runner.py ├── config/ │ └── skills.yaml ├── main.py └── requirements.txt这个结构对应了 Agent Skills 项目落地时的三个关键模块技能定义层skills 目录、技能注册与调度层agent 目录、配置层config 目录。4. 核心流程拆解技能从定义到被 Agent 调用在写代码之前先把核心流程讲清楚。只有理解了流程你才能根据自己的业务场景做裁剪。4.1 第一步定义技能基类所有 Skill 都应该继承同一个基类。这个基类定义了 Agent 框架需要的最小接口。这里真正容易出现的问题是接口定义太细导致新技能接入成本高接口定义太粗又导致调度器无法统一处理。一个平衡的方案是基类只定义四个东西——技能名称、技能描述、执行入口、输入参数模型。4.2 第二步为技能编写提示词提示词是 Skill 和普通 Python 函数最大的区别。一个 Skill 的提示词不是给用户看的而是给模型看的。它要回答三个问题什么时候用这个技能怎么把用户请求转换为标准化调用输出应该遵循什么格式好的技能提示词会让模型在调用技能时“进入角色”。比如 SQL 生成技能提示词就会约束模型“只生成 SELECT 查询不生成 INSERT/UPDATE/DELETE”“不要捏造不存在的字段”“如果字段不确定在注释里标注”。4.3 第三步实现技能内部逻辑技能内部逻辑可以很简单也可以很复杂。简单到调用一个字符串格式化函数复杂到调用一个多步骤的数据处理流水线。关键在于内部逻辑对外部不可见Agent 调度方只需要传入参数、拿到结构化结果。4.4 第四步注册技能到调度器技能写完之后需要注册到 Agent 调度器。注册的本质是把技能的描述信息暴露给模型让模型在做 Function Calling 决策时能看到这个选项。4.5 第五步Agent 调度与执行最后Agent 收到用户消息后会执行一个循环把用户消息和所有已注册技能的描述发送给模型模型判断是否需要调用技能如果需要输出结构化的调用请求Agent 解析调用请求从注册表中找到对应技能执行技能代码拿到结构化结果把结果返回给模型模型基于结果生成最终回复。这个循环就是 Agent 调度的最小闭环。5. 完整示例代码实现下面进入实战。我们实现一个带两个技能的 Agent一个是 Markdown 格式整理技能一个是 SQL 查询生成技能。这两个技能覆盖了“文本处理型”和“结构化生成型”两种典型场景。5.1 技能基类实现文件路径skills/base.pyfrom abc import ABC, abstractmethod from typing import Any, Dict, Optional from pydantic import BaseModel class SkillInput(BaseModel): 技能输入的统一包装。 query: str context: Optional[Dict[str, Any]] None class SkillResult(BaseModel): 技能输出的统一结构。 skill_name: str success: bool data: Any None error: Optional[str] None meta: Optional[Dict[str, Any]] None class BaseSkill(ABC): 所有 Agent Skill 的基类。 name: str description: str parameters: dict {} def __init__(self, config: Optional[Dict[str, Any]] None): self.config config or {} abstractmethod def execute(self, query: str, context: Optional[Dict[str, Any]] None) - Any: 执行技能核心逻辑。 pass def run(self, query: str, context: Optional[Dict[str, Any]] None) - SkillResult: 统一入口封装异常处理和结果包装。 try: data self.execute(query, context) return SkillResult( skill_nameself.name, successTrue, datadata, meta{skill_name: self.name} ) except Exception as e: return SkillResult( skill_nameself.name, successFalse, errorstr(e) )这个基类的设计要点是run方法已经做了异常兜底。无论技能内部抛出什么异常Agent 主流程都不会中断而是拿到一个结构化的失败结果然后由模型决定如何向用户解释。5.2 Markdown 技能实现文件路径skills/markdown_formatter/prompts.pySKILL_DESCRIPTION 这是一个 Markdown 格式整理技能。 当用户提供的内容包含非标准 Markdown 格式、排版混乱、或需要统一风格的标题层级时 使用本技能进行整理。 输入规范 - query 字段传入原始文本内容。 - context 可以传入 format_style可选值为 github / csdn / default。 输出规范 - 返回整理后的 Markdown 文本。 - 不改变原始语义只调整格式。 文件路径skills/markdown_formatter/skill.pyimport re from typing import Any, Dict, Optional from skills.base import BaseSkill from skills.markdown_formatter.prompts import SKILL_DESCRIPTION class MarkdownFormatterSkill(BaseSkill): name markdown_formatter description SKILL_DESCRIPTION parameters { type: object, properties: { query: { type: string, description: 需要整理的原始 Markdown 文本 }, context: { type: object, description: 可选参数包含 format_style 等配置 } }, required: [query] } def execute(self, query: str, context: Optional[Dict[str, Any]] None) - Any: content query.strip() # 统一标题层级将 H1 降到 H2 lines content.split(\n) new_lines [] for line in lines: if line.startswith(# ): line ## line[2:].strip() elif line.startswith(### ): line line.replace(### , #### , 1) new_lines.append(line) # 确保列表前后有空行 text \n.join(new_lines) text re.sub(r\n{3,}, \n\n, text) # 去掉行尾多余空格 text \n.join([line.rstrip() for line in text.split(\n)]) return text这个技能看似简单但它演示了一个重要理念技能内部是纯本地逻辑不依赖模型。即使 Agent 框架退出这个技能也可以被其他 Python 项目直接使用。这是一种“可脱离 LLM 运行”的 Skill 实现方式适合处理规则明确的格式化任务。5.3 SQL 专家技能实现文件路径skills/sql_expert/prompts.pySKILL_DESCRIPTION 这是一个 SQL 查询生成技能。 当用户需要编写 SQL 查询、分析数据库表结构、或优化查询语句时使用本技能。 输入规范 - query 字段传入用户的自然语言需求或已有 SQL。 - context 可以传入 table_schema即表的字段定义。 生成规则 - 默认只生成 SELECT 查询。 - 如果用户没有明确要求增删改绝不生成 INSERT、UPDATE、DELETE 语句。 - 生成的每条 SQL 必须包含注释说明查询目的。 - 如果字段名不确定在注释中标注字段需确认。 文件路径skills/sql_expert/skill.pyimport json import random import re from typing import Any, Dict, Optional, Union from skills.base import BaseSkill from skills.sql_expert.prompts import SKILL_DESCRIPTION class SQLExpertSkill(BaseSkill): name sql_expert description SKILL_DESCRIPTION parameters { type: object, properties: { query: { type: string, description: 用户的自然语言需求或已有 SQL }, context: { type: object, description: 可选参数包含 table_schema 字段定义 } }, required: [query] } def execute(self, query: str, context: Optional[Dict[str, Any]] None) - Any: schema if context and table_schema in context: schema str(context[table_schema]) # 构建一个安全提示词交给 LLM 生成 SQL prompt f你是一个严格的 SQL 专家。请根据用户需求生成 SQL 查询。 用户需求{query} { 表结构信息如下\n schema if schema else } 硬性要求 1. 只生成 SELECT 查询。 2. 不生成任何可能导致数据变更的语句。 3. 输出格式为 JSON包含 sql 和 explanation 两个字段。 4. explanation 简要说明这个查询解决了什么问题。 # 这里通过外部模型 API 生成 SQL # 生产环境中请替换为你自己的模型客户端 sql_text self._call_llm(prompt) try: result json.loads(sql_text) if not isinstance(result, dict): raise ValueError(模型输出不是合法的 JSON 对象) # 安全校验只允许 SELECT 开头 sql result.get(sql, ) if not re.match(r^\s*SELECT, sql, re.IGNORECASE): raise ValueError(生成的 SQL 不是 SELECT 查询已拦截) return result except json.JSONDecodeError: # 如果模型没有按 JSON 输出做兜底解析 return { sql: sql_text.strip(), explanation: 模型未按 JSON 格式输出已原样返回 } def _call_llm(self, prompt: str) - str: 通过 LLM 生成 SQL 语句。实际项目中接入你自己的模型服务。 # 这里只做演示生产环境替换为真实的 OpenAI SDK 调用 # 为了示例可运行我们演示一个确定性返回 if 用户 in prompt and 查询 in prompt: return json.dumps({ sql: -- 查询用户表中前 10 条记录\nSELECT * FROM users LIMIT 10;, explanation: 查询用户表中的前 10 条记录 }) return json.dumps({ sql: -- 生成的 SQL\nSELECT 1;, explanation: 默认查询 })这个 SQL 技能里有一个非常关键的工程点技能内部既有“模型调用”的部分也有“规则校验”的部分。SELECT开头检查、JSON 解析兜底、异常拦截这些逻辑不会出现在 Agent 主流程里而是作为技能自身的防护层存在。这就是 Skill 和裸函数调用的本质区别——Skill 自带防护边界。如果你不想让技能内部调用模型也可以自己实现 SQL 字符串拼接逻辑。核心思路是一样的技能的输入是自然语言需求输出是结构化的 SQL 和解释说明。5.4 技能注册表实现文件路径agent/registry.pyfrom typing import Dict, Type from skills.base import BaseSkill from skills.markdown_formatter.skill import MarkdownFormatterSkill from skills.sql_expert.skill import SQLExpertSkill class SkillRegistry: 技能注册表负责维护所有可用技能的列表。 def __init__(self): self._skills: Dict[str, BaseSkill] {} self._register_defaults() def _register_defaults(self): self.register(MarkdownFormatterSkill()) self.register(SQLExpertSkill()) def register(self, skill: BaseSkill): if not skill.name: raise ValueError(Skill 必须有名称) self._skills[skill.name] skill def get(self, name: str) - BaseSkill: if name not in self._skills: raise KeyError(f技能 {name} 未注册) return self._skills[name] def list_skills(self): return [ { name: skill.name, description: skill.description, parameters: skill.parameters } for skill in self._skills.values() ]注册表的作用是把所有技能收集起来统一提供给调度器。这里有几个设计决策值得注意技能在程序启动时就完成注册避免运行期动态注册带来的竞争问题。注册表只存实例不存类。这样技能可以在初始化阶段加载配置、建立连接池。list_skills方法输出的结构直接就是 Function Calling 需要的工具列表。5.5 Agent 调度器实现文件路径agent/dispatcher.pyimport json from typing import List, Optional from agent.registry import SkillRegistry class AgentDispatcher: Agent 调度器将用户请求分发到对应的技能。 def __init__(self, registry: SkillRegistry): self.registry registry def dispatch(self, intent: str, query: str, context: Optional[dict] None): 根据意图识别结果分发到具体技能。 ## 这里演示一个简单的意图映射 intent_map { format: markdown_formatter, sql: sql_expert } skill_name intent_map.get(intent) if not skill_name: # 默认使用 markdown 技能 skill_name markdown_formatter skill self.registry.get(skill_name) result skill.run(query, context) return result def build_tool_schemas(self) - List[dict]: 生成 OpenAI Function Calling 需要的工具列表。 schemas [] for skill in self.registry.list_skills(): schemas.append({ type: function, function: { name: skill[name], description: skill[description], parameters: skill[parameters] } }) return schemas调度器是 Agent 编排的核心。它要做的事是把“用户的意图”和“已注册的技能”做一个适配。这里我演示的是最简单的意图映射但真实项目中意图识别通常也是由模型完成的。def build_tool_schemas(self) - List[dict]: 生成 OpenAI Function Calling 需要的工具列表。 schemas [] for skill in self.registry.list_skills(): schemas.append({ type: function, function: { name: skill[name], description: skill[description], parameters: skill[parameters] } }) return schemas这段代码尤其重要它将一个技能的内部实现完全抽象成了模型视角下的 Function Schema。模型不需要知道 MarkdownFormatterSkill 内部是怎么排版、怎么处理空格的它只需要知道“有个技能叫 markdown_formatter输入是原始文本输出是整理后的文本”。5.6 主程序入口文件路径main.pyimport json from agent.dispatcher import AgentDispatcher from agent.registry import SkillRegistry def demo_format(): print( * 60) print(场景一Markdown 格式整理技能) print( * 60) registry SkillRegistry() dispatcher AgentDispatcher(registry) # 模拟一段格式混乱的 Markdown messy_markdown # 项目总结 ## 一、背景 为了提升开发效率,我们引入了 Agent Skills。 ### 二、目标 - 减少重复劳动 - 提升代码质量 - 降低维护成本 ## 三、结论 Agent Skills 值得在项目中推广。 result dispatcher.dispatch(format, messy_markdown) print(格式化后的 Markdown) print(result.data) def demo_sql(): print( * 60) print(场景二SQL 查询生成技能) print( * 60) registry SkillRegistry() dispatcher AgentDispatcher(registry) context { table_schema: json.dumps({ users: { id: bigint, name: varchar, created_at: datetime } }) } result dispatcher.dispatch(sql, 查询用户表中前 10 条记录, context) print(生成的 SQL) print(result.data.get(sql)) print(解释) print(result.data.get(explanation)) if __name__ __main__: demo_format() demo_sql()5.7 配置文件示例文件路径config/skills.yamlskills: - name: markdown_formatter enabled: true config: format_style: github - name: sql_expert enabled: true config: max_sql_length: 2000 only_select: true配置文件的意义在于技能的可调参数不应该写死在代码里而是通过配置下发。这样同一个技能在不同环境里可以采用不同的行为测试环境放开输出长度限制生产环境收紧。6. 运行结果与效果验证运行主程序python main.py预期输出 场景一Markdown 格式整理技能 格式化后的 Markdown ## 项目总结 ## 一、背景 为了提升开发效率,我们引入了 Agent Skills。 #### 二、目标 - 减少重复劳动 - 提升代码质量 - 降低维护成本 ## 三、结论 Agent Skills 值得在项目中推广。 场景二SQL 查询生成技能 生成的 SQL -- 查询用户表中前 10 条记录 SELECT * FROM users LIMIT 10; 解释 查询用户表中的前 10 条记录观察输出你会发现几个细节原文本中的 H1 标题被降为 H2符合我们预设的格式风格列表之间的空行被规范化段落间距统一SQL 技能返回的是 JSON 结构后续主流程可以直接用result.data[sql]提取语句所有输出的格式都是统一的SkillResult主程序不需要针对每个技能写不同的解析逻辑。如果运行失败第一步检查requirements.txt中的依赖是否安装完整第二步检查 Python 版本是否不低于 3.10。当前示例不涉及真实模型调用所以不需要配置 API Key。7. 常见问题与排查思路问题现象可能原因排查方式解决方案导入skills包报 ModuleNotFoundError当前目录不在 Python 路径中使用python -m main代替python main.py在项目根目录创建.env或在 main.py 头部添加 sys.path 修正Skill 返回的数据为None技能内部 exception 被基类捕获查看result.error字段在技能 execute 方法内添加日志输出模型不调用已注册的 Skill技能描述不够清晰或参数 Schema 有误打印build_tool_schemas()返回值重写技能描述确保参数类型与 JSON Schema 规范一致配置文件不生效YAML 缩进错误使用python -c import yaml; print(yaml.safe_load(open(config/skills.yaml)))修复缩进确保config:下必须有缩进技能执行耗时太长内部可能同时调用了多个外部 API在run方法中增加耗时统计对技能内部逻辑做缓存或异步化改造同一个技能重复注册注册表初始化时被调用多次检查注册表是否在模块导入期间被实例化使用单例模式或依赖注入容器管理注册表这里要特别说明一个新手容易踩的坑技能描述description写得太抽象。比如“这是一个格式化技能”模型并不知道什么时候该用它。正确写法是“当用户提供的内容包含非标准 Markdown 格式……使用本技能进行整理”。描述里要包含触发条件、输入规范和输出规范尽量让模型不产生歧义。8. 最佳实践与工程建议8.1 技能封装的粒度控制Skill 的粒度是一个权衡题。拆得太细每个技能做的事情太少Agent 调度成本高拆得太粗技能内部逻辑过重复用性变差。一个可行的参考标准如果一个技能超过 500 行代码或者需要调用三个以上的外部服务就考虑拆分成多个子技能。8.2 技能描述的编写规范从 Function Calling 的实践经验看技能描述应该包含以下信息技能适用场景输入参数的具体含义和合法范围输出结果的结构化说明注意事项和禁止行为。一个反例是“这个技能处理信息”。这种描述对模型毫无帮助。8.3 安全与权限控制Agent Skills 在实践中必须考虑安全边界。核心原则是技能默认没有权限显式授权才能执行高风险操作。具体落地时技能代码中不允许出现明文密钥统一从环境变量或密钥管理服务读取对于可能修改数据的技能如 SQL 写操作必须在技能内部加二次确认机制技能执行过程要有完整的日志审计。8.4 技能的可观测性生产环境里技能运行情况必须可见。建议每个 SkillResult 都带上耗时、调用链 ID、当前模型版本等信息。这样当用户反馈“Agent 答错了”时你能快速定位是技能选择错误、参数解析错误还是技能内部执行错误。8.5 配置与版本管理技能是代码也是配置。建议将技能的提示词和参数配置与主代码一起纳入 Git 管理。每次修改技能的 description都应该走代码评审。因为技能描述直接决定了模型是否调用它任何修改都可能影响线上行为。8.6 从单体技能到技能市场当项目里的技能数量超过十个你会自然产生“技能市场”的需求。团队内沉淀的通用技能可以做成一个内部 PyPI 包。通过版本号引用这样不同项目间就能共享技能能力这就是 Agent 从“一个定制系统”走向“一个平台能力”的过程。9. 总结与后续学习方向通过这篇文章你看到了 Agent Skills 从概念到落地的全过程。它不是一套复杂的理论而是一组工程决策把什么样的能力放进 Skill、如何处理技能与模型的边界、如何通过注册表统一管理技能、如何让技能的运行结果对主流程可见。建议你接下来做三件事第一把你现有项目里最常用的一个功能比如文本纠错、代码格式化、数据抽取改造成一个 Skill用本文的基类和注册表模式接入你的 Agent感受一下改造前后的差异。第二尝试让一个技能内部调用多个模型比如先调用小模型做意图判断再调用大模型做内容生成。关注这种级联调用对响应延迟的影响。第三关注主流 Agent 框架对 Skills 的官方支持方式。无论你用 LangChain、LlamaIndex还是自研框架技能注册、调度和配置管理的思路都是相通的。Agent 应用的复杂度正在从“模型能力”转移到“工程组织能力”。谁把工具、知识、规则封装得好谁的 Agent 就更能应对真实业务里的混乱与变化。把 Skill 这套结构用起来你的 Agent 项目会少很多“今天改一下 Prompt 明天又崩了”的尴尬。