Agent Skills 工程落地：技能封装与调度器实战解析

这套内容主要讲 Agent Skills 的工程落地思路技能的本质是什么、技能如何封装、调度器如何设计以及如何在一个具体项目里跑起来。1. 先搞清楚 Agent Skills 到底是什么在开始写代码之前先把概念理清楚。Agent Skills 这个词最近热度很高但网上的资料大多停留在“介绍层面”——告诉你它很好、很有用却不说怎么在自己的项目里真正落地。所以这篇文章会换一个角度直接围着“技能封装”和“Agent 调度”这两个核心点展开。1.1 技能不是 prompt也不是插件很多初学者会混淆几个概念Prompt、Tool、Plugin、Skill。从工程角度看它们确实有重叠但定位完全不同概念本质例子Prompt一段引导模型输出的文本“你是一位资深数据分析师”Tool / Function可供模型调用的外部函数查询天气、调用计算器Plugin插件体系通常是 Tool 的集合浏览器插件、代码解释器插件Agent Skills可复用的能力单元包含描述、参数、执行逻辑、甚至示例生成研究综述、清洗表格数据也就是说Agent Skills 更接近“封装好的能力模块”。它不只是给模型一段文本而是把“模型怎么理解这个能力”和“程序怎么执行这个能力”两者结合起来。1.2 它解决的核心问题实际开发中Agent 应用最头疼的问题不是模型不够聪明而是能力复用难同样的“数据清洗”逻辑在项目 A 里写一遍项目 B 里再写一遍没有沉淀。模型调用不规范不同开发者的函数风格不统一模型经常理解错参数。调度混乱Agent 不知道该在什么时候调用哪个能力常常一个任务从头到尾只用对话完成不调用任何外部能力。扩展成本高想给 Agent 加一个新能力得改代码、改提示词、重新测试牵一发动全身。Agent Skills 的核心价值就是把“模型理解层”和“代码执行层”标准化。模型只负责“根据技能描述决定什么时候调用”而具体的执行逻辑全部封装在技能内部。这样一来加技能、换技能、测试技能都变成了独立操作。1.3 它和 Agent 调度是什么关系Agent 可以理解成一个“调度中枢”它负责理解用户请求拆解任务目标选择合适的技能组合技能的执行顺序汇总结果并返回给用户而 Agent Skills 就是调度中枢可以调用的“能力库”。一个技能对应一类能力Agent 通过阅读技能描述来判断“当前任务是否需要这个技能”再通过参数定义来完成调用。可以这样理解如果把 Agent 比作一家公司那么 Agent Skills 就是公司里不同部门的职能。老板接单后决定把任务分给哪个部门部门内部怎么干活老板不需要知道细节。2. 环境准备与版本说明实操部分我们需要准备一套能跑起来的 Python 环境。2.1 基础环境本文示例以 Python 3.10 为例操作系统不限Windows / macOS / Linux 均可。建议使用虚拟环境隔离依赖# 创建虚拟环境示例目录名 venv python3 -m venv venv # 激活虚拟环境 # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate2.2 依赖安装本文的示例需要用到两个库openai用于调用 OpenAI 兼容接口的大模型。现在很多国产模型、开源模型也提供 OpenAI 兼容接口比如通义千问、DeepSeek、智谱 GLM 等使用方式基本一致。pydantic用于定义技能参数结构做数据校验。pip install openai pydantic版本说明OpenAI SDK 目前迭代较快本文示例以openai1.0的写法为准。如果你的项目还在用0.x版本接口差异较大建议直接升级。2.3 大模型接口准备为了演示完整链路你需要一个可用的模型 API Key。如果你本地没有可以使用 OpenAI 官方 API需要网络环境支持。使用国内云厂商的 OpenAI 兼容接口例如通义千问的dashscope兼容模式。使用本地部署的 Ollama 兼容代理。因为不同平台的 Base URL 和模型名不同本文的示例会通过环境变量读取配置export LLM_API_KEY你的_KEY export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini注意如果你用的不是 OpenAI 官方Base URL 和模型名需要按你的实际服务商调整。这是最保守、最不容易出错的用法。3. 技能封装的核心设计从“函数”到“技能”这一节是整个项目的核心。理解清楚这一节后面写代码就是顺水推舟的事情。3.1 技能的最小单元描述 参数 执行函数一个标准化的 Agent Skill在设计上至少包含三块技能名称name短横线命名例如># 文件路径skills/summarizer.py from pydantic import BaseModel, Field class SummarizerParams(BaseModel): 论文摘要技能的参数定义 text: str Field(..., description需要进行摘要的原文) max_length: int Field(300, description摘要最长字数) def summarize(text: str, max_length: int 300) - str: 真正的技能执行函数。 为了演示这里先简化为直接截断实际项目中可以调用大模型或抽取式算法。 if len(text) max_length: return text return text[:max_length] ...这里包含两层SummarizerParams是模型层的参数定义。模型通过阅读这个结构知道应该传text和max_length两个参数。summarize是执行层的具体实现。在真实项目中这里是调用算法、操作文件、请求数据库的地方。3.3 技能描述为什么决定调用成功率很多人调不好 Agent80% 的原因是技能描述写得太模糊。来看两种写法的对比# 不推荐的描述 description: 做摘要 # 推荐的描述 description: 对输入的文本内容进行提取式摘要适合论文、文章、长文档。当用户需要 快速了解一段长文本的核心信息或生成内容提要时应调用本技能。推荐写法包含能力范围能做什么适用场景什么情况下使用者应该调用它触发词出现哪些关键词可以联想调用限制说明什么情况下不该用它模型是概率推理的描述给得越具体它就越容易在正确的时机调用正确的技能。3.4 技能目录的组织方式在项目里不建议把所有技能堆在一个文件里。推荐按功能模块划分目录agent_project/ ├── skills/ │ ├── __init__.py │ ├── summarizer.py # 摘要技能 │ ├── data_cleaner.py # 数据清洗技能 │ └── literature_search.py # 文献检索技能 ├── agent/ │ ├── __init__.py │ ├── registry.py # 技能注册中心 │ └── dispatcher.py # 调度器 ├── main.py # 入口 └── requirements.txt这样的好处是每个技能独立提交、独立测试、独立升级互不干扰。4. 从零到一Agent 调度器实战理解了技能封装之后我们进入完整实战。这一节会构建一个最小但完整的 Agent 系统支持注册多个技能模型自动选择技能调用技能并返回结果处理参数校验和异常4.1 定义技能注册中心技能注册中心的作用是把所有技能统一管理起来。它维护一个“技能名字到下处理器”的映射关系同时维护所有技能描述方便后续塞给模型。# 文件路径agent/registry.py import inspect from dataclasses import dataclass, field from typing import Any, Callable, Dict, List dataclass class Skill: 技能统一数据结构 name: str description: str parameters_schema: Dict[str, Any] handler: Callable[..., Any] class SkillRegistry: 技能注册中心 def __init__(self): self._skills: Dict[str, Skill] {} def register( self, name: str, description: str, parameters_schema: Dict[str, Any], handler: Callable[..., Any], ) - None: 注册一个技能 if name in self._skills: raise ValueError(f技能 {name} 已经注册) self._skills[name] Skill( namename, descriptiondescription, parameters_schemaparameters_schema, handlerhandler, ) def get(self, name: str) - Skill: 根据名字获取技能 return self._skills[name] def list_openai_tools(self) - List[Dict[str, Any]]: 把技能转成 OpenAI 的 tools 格式。 这一步是关键模型通过这个结构感知到有哪些能力可用。 tools [] for skill in self._skills.values(): tools.append({ type: function, function: { name: skill.name, description: skill.description, parameters: skill.parameters_schema, }, }) return tools def list_skill_names(self) - List[str]: return list(self._skills.keys())这里把技能同时兼认为两种角色面向模型以 OpenAI tools 格式呈现模型能读到技能清单。面向程序以 handler 函数形式呈现调度器能真正执行它。4.2 实现调度器调度器是 Agent 的心脏。它负责接收用户问题把“系统提示词 技能清单 用户问题”发给模型解析模型的返回判断是否需要调用技能如果需要调用技能执行对应的 handler把工具结果返回给模型继续会话直到模型给出最终回答# 文件路径agent/dispatcher.py import json from typing import List, Dict, Any from openai import OpenAI from agent.registry import SkillRegistry class AgentDispatcher: Agent 调度器 def __init__( self, registry: SkillRegistry, api_key: str, base_url: str, model: str, system_prompt: str 你是一个智能助手可以在适当场景下调用技能来完成任务。, ): self.registry registry self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model self.system_prompt system_prompt def _run_skill(self, name: str, arguments: dict) - str: 执行技能并返回结果 skill self.registry.get(name) # 真实项目中建议加入参数校验逻辑 result skill.handler(**arguments) if isinstance(result, (dict, list)): return json.dumps(result, ensure_asciiFalse) return str(result) def chat(self, user_message: str, max_turns: int 5): 运行 Agent。 多次循环调用的原因模型可能先调用技能拿到结果后再组织最终回答。 messages [ {role: system, content: self.system_prompt}, {role: user, content: user_message}, ] tools self.registry.list_openai_tools() for _ in range(max_turns): response self.client.chat.completions.create( modelself.model, messagesmessages, toolstools, tool_choiceauto, ) message response.choices[0].message # 无工具调用直接返回最终答案 if not message.tool_calls: return message.content # 把模型的工具调用请求追加到会话历史 messages.append(message.model_dump()) # 依次执行工具调用 for tool_call in message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) try: result self._run_skill(fn_name, fn_args) except Exception as e: result f技能执行出错: {e} # 将工具结果返回给模型 messages.append({ role: tool, tool_call_id: tool_call.id, content: result, }) return 抱歉处理次数已达上限未能完成最终回答。这个调度器的核心逻辑就是一个循环模型决策 → 如果调用技能则执行 → 结果回传 → 模型继续决策 → 直到不再调用技能4.3 编写两个可用的业务技能为了演示效果我们封装两个技能generate_research_overview生成研究综述面向人文社科混合研究方法论文写作场景。clean_data对表格数据进行简单的清洗。# 文件路径skills/research_skills.py from pydantic import BaseModel, Field class ResearchOverviewParams(BaseModel): topic: str Field(..., description研究主题) method: str Field(混合研究方法, description研究方法例如定性分析、定量分析、混合方法) max_points: int Field(5, description最多生成几个要点) def generate_research_overview(topic: str, method: str 混合研究方法, max_points: int 5) - dict: 生成一个研究综述结构的技能。 演示版本只做模板化输出实际项目可以接入检索或大模型生成。 points [ f围绕【{topic}】这一主题已有研究主要集中在概念界定与维度划分但尚未形成统一框架。, f在研究方法上既有文献多使用单一方法而【{method}】能够提升结论的稳健性。, f现有研究较多依赖问卷或访谈缺乏对文本数据的系统挖掘。, f本研究拟结合定量指标与定性文本分析构建混合研究路径。, f通过多源数据交叉验证可以有效降低单一方法带来的偏差。, ][:max_points] return { topic: topic, method: method, overview_points: points, suggestion: 建议先进行文献检索再结合数据可得性确定具体研究路径。, }# 文件路径skills/data_cleaner.py from pydantic import BaseModel, Field from typing import List class CleanDataParams(BaseModel): raw_data: List[str] Field(..., description待清洗的原始文本列表每个元素代表一行数据) remove_duplicates: bool Field(True, description是否去重) strip_whitespace: bool Field(True, description是否去除首尾空白) def clean_data(raw_data: List[str], remove_duplicates: bool True, strip_whitespace: bool True) - dict: 简单数据清洗技能去空白、去空行、去重 cleaned [] for item in raw_data: if strip_whitespace: item item.strip() if item : continue cleaned.append(item) if remove_duplicates: # 去重并保持顺序 seen set() unique_rows [] for item in cleaned: if item not in seen: seen.add(item) unique_rows.append(item) cleaned unique_rows return { original_count: len(raw_data), cleaned_count: len(cleaned), cleaned_data: cleaned, }4.4 组装主程序入口有了技能和调度器剩下的就是组装。这一步也在示范“技能注册”这个动作。# 文件路径main.py import os from agent.registry import SkillRegistry from agent.dispatcher import AgentDispatcher from skills.research_skills import generate_research_overview, ResearchOverviewParams from skills.data_cleaner import clean_data, CleanDataParams def build_registry() - SkillRegistry: registry SkillRegistry() registry.register( namegenerate_research_overview, description( 生成研究综述要点。当用户需要完成论文选题分析、文献综述结构建议、 研究框架设计或者人文社科研究写作思路时调用本技能。 ), parameters_schemaResearchOverviewParams.model_json_schema(), handlergenerate_research_overview, ) registry.register( nameclean_data, description( 清洗文本表格数据支持去除首尾空白、空行和重复行。 当用户提供一段原始文本数据并要求整理、去重、清洗时调用本技能。 ), parameters_schemaCleanDataParams.model_json_schema(), handlerclean_data, ) return registry def main(): registry build_registry() dispatcher AgentDispatcher( registryregistry, api_keyos.environ.get(LLM_API_KEY, ), base_urlos.environ.get(LLM_BASE_URL, https://api.openai.com/v1), modelos.environ.get(LLM_MODEL, gpt-4o-mini), ) # 测试用例1触发写作技能 result1 dispatcher.chat( 我准备写一篇关于短视频平台对大学生阅读习惯影响的论文 采用混合研究方法请在开头给我一些综述要点。 ) print( 任务1 回答 ) print(result1) print() # 测试用例2触发数据清洗技能 result2 dispatcher.chat( 我这里有一段问卷开放题文本帮我清洗一下去重 [ 经常看短视频 , 经常看短视频, 偶尔看 , , 几乎不看 ] ) print( 任务2 回答 ) print(result2) if __name__ __main__: main()4.5 运行与验证运行前先确认环境变量是否已配置export LLM_API_KEY你的_KEY export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini然后启动python main.py预期结果分为两种情况模型根据用户问题自动判断出需要调用generate_research_overview或clean_data。模型拿到技能返回结果后组织一段完成的回答返回给用户。关键观察点技能注册是否生效、参数解析是否成功、工具调用是否被正确执行。5. 实战案例人文社科混合研究论文写作里的 Agent Skills上面的代码已经是一个最小可运行系统但真正的项目落地还需要看业务场景的完整编排。这里以“Agent Skills 赋能人文社科混合研究方法论文写作”为例演示多技能如何配合而不是单技能调用。5.1 场景拆解一篇混合研究论文的写作流程通常包括七个步骤选题分析文献综述研究设计问卷与访谈数据收集定量数据分析定性文本分析结论与建议把这些步骤投影到 Agent Skills 上就可以拆成一组技能论文阶段对应 Agent Skill核心能力选题分析research_overview生成选题要点、研究缺口文献综述literature_summarizer批量摘要文献摘要研究设计mixed_method_designer生成混合方法设计建议数据清洗data_cleaner问卷文本清洗、去重定量分析statistics_helper生成统计方案、解释指标定性分析qualitative_coder辅助主题编码与类属归纳报告生成report_writer按照论文结构组织内容5.2 多技能编排的关键任务拆解加入多个技能后调度策略就不只是“模型选一个技能”而是“模型规划多个技能的调用顺序”。例如用户提问我收集了300份问卷和15份深度访谈文本想用混合研究方法写一篇关于外卖骑手职业认同的论文接下来该怎么分析Agent 的理想调度路径是调用research_overview明确研究框架。调用data_cleaner清洗问卷中的开放题文本。调用statistics_helper规划定量分析步骤。调用qualitative_coder对访谈文本进行主题编码。调用report_writer汇总成初稿结构。这种多技能协作需要在调度器中支持更灵活的工具编排逻辑。业界常见做法有两种方案一纯模型驱动。模型在每一轮决策中自行决定调用哪个技能然后把结果带回上下文继续生成。上一节的实现就是这种简单直接适合技能数量少、任务线清晰的场景。方案二预先定义工作流 模型驱动混合。系统先按工作流模板执行固定阶段模型在每个阶段内做技能选择和参数填充。这种方式更可控适合业务逻辑固定的场景例如论文写作辅导系统、研究报告生成系统。在项目落地时大多数采用方案二。原因很简单纯模型驱动在多技能场景下容易“跳步”或“漏步”比如还没清洗数据就直接做统计。先定义阶段再在每个阶段内放权给模型效率和稳定性都会提升。5.3 技能封装粒度怎么设定人文社科论文写作这个场景中很容易把技能拆得太细。比如把“主题编码”拆成“编码初始类属”“编码主轴”“编码选择性类属”三个技能。但实际效果往往不好原因有两个模型难以精确区分相似技能容易选错。技能间存在强依赖单独调用没有意义。合理的粒度是一个技能应该能独立完成一个有意义的子任务。也就是说技能之间的边界应该是“可独立交付结果”的边界。推荐粒度 - 数据清洗独立交付干净的数据 - 摘要生成独立交付文本摘要 - 主题编码独立交付编码表 - 报告结构生成独立交付论文大纲 不推荐粒度 - 编码第1步 / 编码第2步 / 编码第3步5.4 场景化技能描述模板我们在给人文社科场景写技能描述时总结出一个通用模板技能用途一句话说明。 当用户具体场景/触发条件时应调用本技能。 输入参数包括核心字段输出为核心结果。 如果不适用条件请不要调用本技能。以qualitative_coder为例description ( 对访谈原始文本进行主题编码分析输出初始类属、主类属和典型引用片段。 当用户提供访谈记录、开放题文本并要求做质性分析、编码、类属归纳时应调用本技能。 如果用户只是要求生成访谈提纲则不应调用本技能而应使用 research_designer。 )这种模板之所以有效是因为它把模型最需要的三个决策信息都给了能力边界、触发时机、不适用场景。6. 常见问题与排查思路实际写代码时遇到的问题往往比想象中多。以下是 Agent Skills 实战中最高频的几个问题。6.1 模型始终不调用技能现象用户输入明显需要调用技能但模型直接给出通用回复没有触发工具调用。可能原因技能描述不清晰模型感知不到“需要调用技能”。参数 schema 定义错误模型无法生成合法参数所以放弃调用。大模型本身不支持工具调用或未开启相关参数。提示词里出现“请不要调用工具”之类的冲突指令。排查步骤打印registry.list_openai_tools()确认 tools 结构是否符合 OpenAI 格式。简化技能描述加入更明确的触发词。去掉 system prompt 中可能与工具调用冲突的内容。更换支持 function calling 的模型版本。6.2 参数解析失败JSON 格式错误现象模型返回的tool_calls.function.arguments无法用json.loads解析。常见原因模型输出了多余的解释文本。使用了不支持严格 JSON 输出的低版本模型。参数 schema 中存在复杂嵌套模型理解困难。解决方案import json def safe_load_args(arguments: str) - dict: 容错解析优先正常解析失败时尝试提取 JSON 片段 try: return json.loads(arguments) except json.JSONDecodeError: # 提取第一个 { 到最后一个 } 之间的内容 start arguments.find({) end arguments.rfind(}) if start ! -1 and end ! -1 and end start: try: return json.loads(arguments[start:end 1]) except json.JSONDecodeError: return {} return {}这个容错函数能解决大部分“JSON 解析失败”问题但不能完全依赖它。更根本的解法是选用工具调用能力更稳定的模型或者在请求时开启response_format约束。6.3 技能调用后结果没有回传给模型现象技能确实执行了但模型的最终回答没有基于技能结果生成。根本原因工具结果没有正确添加进messages或者tool_call_id不匹配。在 OpenAI 的会话协议里模型发起工具调用后你必须在后续消息中通过tool_call_id把结果对应的那次调用绑定在一起。很多初学者漏掉这一步导致模型感知不到工具结果。messages.append({ role: tool, tool_call_id: tool_call.id, # 必须与工具调用记录的 id 一致 content: result, })6.4 技能结果太长上下文超限现象技能调用一次后第二次调用时报错或模型开始丢失信息。原因技能返回内容过大例如把整份原始问卷塞进上下文。对策技能只返回汇总信息和必要摘要不返回原始全量数据。对长文本先做摘要再交给模型。设置单次技能结果的最大长度。必要时引入外部存储技能结果写入文件或数据库模型只拿到结果路径。6.5 多技能场景下模型“跳步”现象应该在清洗数据后再做统计但模型直接生成了统计结论。对策如果是纯模型驱动可以强化系统提示词明确调用顺序。更推荐在代码层加入工作流编排用阶段控制替代纯自由决策。对关键阶段做状态检查前置阶段未完成时不允许进入下一阶段。6.6 高频问题速查表问题现象常见原因解决思路模型不调用技能技能描述模糊 / 模型不支持工具重写描述、换模型JSON 解析失败模型输出不规范使用容错解析或不兼容兼容模型工具结果不生效tool_call_id 未对应检查 messages 序列上下文超限技能返回过长只返回摘要外置存储多技能跳步调度无约束引入工作流编排参数为空schema 定义有误打印 schema 并与 OpenAI 格式对照7. 最佳实践与工程建议7.1 技能命名规范推荐使用小写字母 下划线或中划线语义要明确优generate_research_overview、clean_data、literature_summarizer 劣skill1、do_thing、abc_func技能名称就是模型看到的能力标识必须让模型一眼判断出技能用途。7.2 参数设计要“少而准”每个技能的参数不要超过 5 个。参数越多模型生成合法参数的概率越低。参数设计原则必填参数尽量少能用默认值的都设默认值。参数名用通用英文词汇避免生僻缩写。每个参数在 description 中写明单位、格式和示例。避免参数之间有强依赖否则模型很难同时生成正确的组合。7.3 技能执行限时与超时真实项目中技能可能调用第三方 API、读写数据库、执行耗时操作。如果不加超时控制Agent 可能长时间挂起。import functools import signal def with_timeout(seconds: int): 简单超时装饰器仅适用于 Linux / macOS def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): def handler(signum, frame): raise TimeoutError(f技能执行超过 {seconds} 秒) signal.signal(signal.SIGALRM, handler) signal.alarm(seconds) try: return func(*args, **kwargs) finally: signal.alarm(0) return wrapper return decorator运行时将技能执行包进超时装饰器就可以避免单技能卡死拖垮整个 Agent 任务循环。7.4 技能执行结果的结构化输出技能的返回值最好统一为 JSON 结构并且都包含一个状态字段{ success: True, data: {...}, error: None, elapsed_ms: 123 }这样做的好处是模型更容易解析结果。调度器可以统一处理异常。日志和排查更清晰。7.5 权限与合法性边界技能是 Agent 的操作入口权限控制必须前置涉及外部 API 调用的技能API Key 必须通过环境变量或密钥管理服务注入不写死在技能代码里。涉及删除、更新、覆盖文件的操作执行前必须二次确认。涉及用户隐私数据的技能必须在技能描述中明确提醒边界不擅自采集和上传。涉及数据库操作的技能默认强制要求事务、备份和测试环境验证。7.6 日志与可观测性Agent 系统的调试难度远高于普通程序。核心原因是同样的用户输入模型决策可能每次都不一样。因此强烈建议在调度器的每个关键节点加结构化日志import logging logging.basicConfig(levellogging.INFO, format%(asctime)s | %(levelname)s | %(message)s) logger logging.getLogger(agent) # 在调度器关键节点插入日志 logger.info(Step: user_message%s, user_message) logger.info(Step: tool_calls%s, message.tool_calls) logger.info(Step: skill_result%s, result[:200]) # 防止日志太长这样当线上 Agent 出现错误决策时可以通过日志还原完整决策链路。7.7 技能的测试策略技能封装层虽然像函数但不是普通函数。它有两个测试维度测试类型验证内容做法单元测试参数合法时执行是否正确直接调用 handler断言输出调度测试模型能否正确选到技能构造不同用户问题验证 tool_call 名称调度测试尤其重要。建议每增加一个新技能就补充一批“用户问题 → 期望调用技能”的测试用例防止模型因技能增多而决策漂移。8. 总结与下一步学习路线写到这里整套 Agent Skills 的工程化链路已经通了从概念理解到技能设计再到注册中心、调度器、主程序组装最后到多技能业务场景编排和问题排查。如果你是从零开始学今天的核心收获可以概括为三点技能是“模型理解层 代码执行层”的组合不只是提示词。调度器负责让模型决定“何时调用技能、调用哪个技能、按什么顺序调用”。工程落地时真正花时间的不是写技能而是写技能描述、控制参数质量、设计调度流程。接下来可以往几个方向继续深入学习更复杂的多 Agent 协作模式把不同 Agent 配置成不同角色再通过调度器统一协调。掌握函数调用的进阶玩法例如并行工具调用、流式输出、多工具串联。研究结构化输出技术让技能返回值更稳定减少解析错误。做一个小项目练手比如把今天的代码改造成“论文写作助手”或“行业研究报告生成器”。这套代码本身也可以当作模板直接复用。想加新技能就写一个参数类、一个 handler 函数再注册进 registry调度器不需要大改。这种低耦合的扩展方式正是 Agent Skills 在实际项目中最大的价值。