Agent Skills 实战：从零构建可扩展的技能调度系统-平芜编程栈

做了半年 Agent 应用，我发现大部分团队遇到的瓶颈根本不在模型能力，而是卡在“能力组织方式”上：所有指令、工具、业务逻辑全部堆在系统提示词里，一个上千行的 prompt，改一处动全身，模型经常漏调用、乱调用，出了问题只能靠肉眼查提示词。

最近大家都在聊 Agent Skills，这个概念的传播度和讨论度确实很高，但它到底是一套新框架，还是把旧思路包装成了新名词？把它拆开之后，我们会发现它重新回答了三个问题：Agent 的能力怎么封装、怎么被调度、怎么在生产环境里落地。这篇文章不打算复述概念，而是用“一个人也能跑通的最小系统”把 Agent Skills 从头讲透，包括技能注册、意图路由、执行编排，以及真正上生产时容易踩的坑。

读完这篇文章，你会知道 Agent Skills 和普通 Tool 调用有什么区别，能自己写一个带技能注册表和调度器的最小 Agent，并且能判断出，什么样的项目值得全面技能化，什么样的项目暂时不需要。

1. 这篇文章真正要解决的问题

如果你已经在用大模型做应用，大概率遇到过这几类问题：

第一，提示词越来越大。每加一个功能就往 system prompt 里塞一段说明，最后 prompt 又长又碎，模型很容易混淆，甚至把不同功能的指令相互干扰。

第二，工具函数越来越多。写了一个又一个 function call，但函数只解决了“能调用”的问题，没有解决“什么时候该调用哪个函数”的问题，全靠模型自己猜。

第三，扩展能力到一定程度后，系统变成“面条代码”。一个新功能的接入要改动多个文件，可能要动 prompt、要动工具列表、要动后处理逻辑，回归成本很高。

Agent Skills 这套方法要解决的，正是这最后一公里的工程问题。它把“能力”从 prompt 和函数中拆出来，封装成独立、可描述、可复用、可调度的模块。在这个体系里，Agent 不需要在每一步都看到所有技能，而是通过一个调度层按需加载和调用技能。

这句话值得单独说一次：Agent Skills 真正降低的不是模型的“聪明程度”，而是 Agent 应用的扩展成本。它把“给模型加能力”这件事，从改 prompt 变成了“添加一个技能包”，让加功能变成增量操作，而不是重构操作。

什么样的读者最适合看这篇文章？如果你正在做 Agent 原型，但发现能力一多就失控；如果你在团队里维护 Agent 工具链，想找一种更规范的组织方式；如果你只是听说过 Skills 这个概念，想弄懂它和 Tool、插件到底有什么不同——这篇文章都适用。

2. Agent Skills 的核心概念与原理

2.1 什么是 Agent Skills

Agent Skills 的直观定义是：一组可被 Agent 按需加载和执行的“能力包”。

每个技能包不是裸的函数，而是一个完整的模块，通常包含：

技能的元信息，包括名称、描述、适用场景、触发条件。
技能的指令模板，告诉模型什么时候用、怎么用、注意什么。
技能的执行体，可以是一个函数、一组 API 调用、一段脚本，甚至一个子 Agent。
技能的输入输出约定，包括参数格式、返回值格式、错误处理方式。
技能的依赖与版本信息，方便做工程管理。

这个定义看起来很工程化，但它的思路很朴素。你想象一下，一个大型团队会为每个业务模块写 SOP 手册，而不是每次都临时给新人讲一遍流程。Agent Skills 就是给 Agent 写的 SOP 手册，模型是执行者，技能包是标准作业程序。

2.2 为什么不能只靠 Prompt 和 Tool

很多 Agent 框架已经提供了 Tool 或 Function Calling 的能力，为什么还需要 Skills？这里要区分三个概念：

对比项 Prompt 内嵌指令 Tool 函数调用 Agent Skills

能力组织方式写在 system prompt 里独立函数，但无上下文说明完整的能力包，包含说明和执行体

扩展方式改 prompt，有连锁风险加函数，同时要维护调用逻辑新增技能包，增量接入

是否可复用基本不可复用函数可以复用，但指令不可复用技能整体复用

是否可描述依赖自然语言，模型容易混淆只有函数签名，信息量少有结构化描述，便于调度和匹配

Tool 解决的是“模型能执行什么”，Agent Skills 解决的是“模型应该怎么理解和使用这个能力”。

举个例子，一个 get_weather 函数作为 Tool 存在时，模型只知道它能拿天气数据。但一个 weather_skill 技能包，会告诉模型：这个技能适合在用户询问当前天气时使用，需要先获取用户所在城市，如果城市缺失可以调用定位接口，如果查询失败应该返回怎样的兜底文案。这些上下文信息如果全塞 prompt，会越塞越混乱；封装成技能后，只在需要时加载，清晰且可维护。

2.3 吴恩达提出 Agent Skills 的核心判断

Agent Skills 这个方向之所以被广泛讨论，和吴恩达的公开推广有直接关系。他在关于 Agentic AI 的分享中提到过一个观察：单一模型很难同时做好所有事情，但通过组合多种技能，可以让同一个 Agent 在不同任务中表现出更强的能力。换句话说，未来 Agent 的竞争重点不再只是模型的参数规模，而是它能否高效地调用和组织专业技能。

从这套逻辑往下推，得出了一个对工程很有价值的结论：Agent 应该像人一样“按需调用技能”，而不是把所有人的能力都塞进同一套思维里。这也是 Agent Skills 和普通工具链最大的差异——它不是给模型更多函数，而是给模型一套可以按需选择的“职业能力库”。

3. 技能封装：从函数到标准化技能包

3.1 技能封装要解决的三个问题

如果把一个普通函数直接丢给 Agent，它会面临几个问题：

不知道这个函数什么时候该用。模型只知道函数签名，不知道业务上下文。
不知道参数怎么填。比如 get_weather 需要城市参数，但用户可能没说城市，函数本身不知道怎么处理。
不知道失败后怎么办。接口超时、数据为空，函数抛异常，Agent 只能给用户一个莫名其妙的结果。

技能封装就是把这几个问题一并解决。一个合格的技能包，至少要覆盖三层：

第一层是描述层。包括技能的名称、简述、适用上下文，这一层服务于模型的“意图识别”环节。

第二层是执行层。包括函数、API、脚本、数据库查询等实际执行逻辑，这一层负责真正干活。

第三层是约束层。包括参数 Schema、返回值格式、错误码、兜底文案，这一层保证技能在执行过程中稳定可控。

3.2 一个最小技能包应该长什么样

如果用一个 JSON 来描述一个技能包，它大概是这样的：

{ "name": "weather_query", "description": "查询指定城市的当前天气，适合用户询问天气、温度、降雨概率时调用", "version": "1.0.0", "params": { "city": { "type": "string", "required": true, "description": "城市名称，例如：北京" } }, "returns": { "type": "object", "description": "包含温度、天气状况、风力等级、温馨提示" }, "fallback": "抱歉，当前无法获取该城市的天气信息，请稍后再试。", "handler": "skills.weather.main" }

其中 name 和 description 是调度器匹配的核心，handler 指向实际执行的函数或模块，fallback 是失败时的兜底话术。这样一个技能包，既可以被人类读，也可以被模型读，还可以被程序结构化使用。

3.3 技能封装的常见误区

很多初学者会把 Agent Skills 理解成“写一个类，里面放个方法”。如果只做到这一步，那它还是 Tool，不是 Skill。

两者之间的差别在于：你是否有意识地提供了“调用时机”和“边界条件”。如果函数没有描述“什么时候不该用”，模型就容易在错误场景中强行调用它。比如一个计算器技能，没有说明“仅处理数学表达式，不处理自然语言问题”，模型可能把一个逻辑问题甩给计算器。

所以，技能封装表面上是在写函数，实际上是在写“模型的使用说明书”。一个好的技能包，应该像一份交接文档：不仅告诉模型怎么做，还要告诉模型什么时候不做、做不了怎么办。

4. Agent 调度：意图识别与技能路由

技能封装好之后，下一个核心问题是调度。Agent 不可能同时加载所有技能，也不应该让模型每次都在几十个技能里做选择，那样既浪费 token，又容易选错。调度的本质，是把“用户请求”路由到“最合适的技能”。

4.1 调度器的三种实现层次

Dispatcher 是中间的决定器。它不需要真的“理解”用户请求，只需要做一层匹配。

第一层是基于规则的关键词匹配。优点是实现简单、速度快、可解释性强；缺点是覆盖率低，用户换个说法就匹配不上了。

第二层是基于向量相似度的语义匹配。先给每个技能生成描述向量，再把用户请求向量化，算相似度，取 Top-K 个候选技能。这种方法覆盖率高，但需要引入额外的向量模型或嵌入接口，还会增加延迟。

第三层是基于大模型的选择。把技能列表和用户请求一起交给模型，让模型决定调用哪个技能。这种方式最灵活，但成本较高，而且如果技能过多，需要做摘要或分层。

在实际项目中，三层往往混合使用：先用规则做快速分流，再用向量做召回，最后用模型做精细化选择。下面是一个混合调度的伪代码思路。

4.2 调度器需要返回什么

调度器返回的结果，不只是一个技能名字。它需要为后续执行准备完整上下文：

命中的技能名。
从用户请求中抽取出的参数。
技能的版本号，方便日志追踪。
调度置信度，低于阈值时交给兜底逻辑。

这里有一个容易被忽略的重点：参数抽取也是调度的一部分。用户说“北京明天天气怎么样”，技能名是 weather_query，参数应该是 city=北京，date=明天。如果不做参数抽取，技能执行体拿到的是整段用户原话，等于把解析工作层层下推，最后还是要写一堆 if 分支。

4.3 调度失败怎么办

调度失败是必然会发生的情况，不用在代码里假设它永远成功。设计上要留三条路：

没有匹配到任何技能，走兜底回复，建议用户换一种说法。
匹配到技能但置信度低，可以返回候选技能列表，让用户确认。
匹配到技能但参数不全，触发技能内部的参数补齐流程。

这三条路都改到位了，调度器才算真正完成了“路由”的职责，而不是单纯做一个函数分发。

5. 环境准备与前置条件

5.1 运行环境

本文中的示例是一个最小可运行的 Python 项目，不依赖任何重量级框架，适合用来理解 Agent Skills 的调度机制。如果你已经用过 LangChain、LlamaIndex 等框架，也不冲突，这套结构可以迁移到你的框架里。

建议环境如下：

Python 3.10 或更高版本。
不需要 GPU，本地 CPU 即可运行。
不需要 API Key，示例中不调用真实大模型接口，用规则匹配代替模型选择。
操作系统不限，Windows、macOS、Linux 均可。

如果条件允许，后续可以接入一个嵌入接口做语义匹配，但这不是本节示例的运行前提。

5.2 项目目录结构

为了让示例更接近真实工程，我建议按下面的目录组织：

agent-skills-demo/ ├── main.py # 入口程序 ├── requirements.txt # 依赖声明（本次可为空） ├── core/ │ ├── __init__.py │ ├── skill_registry.py # 技能注册表 │ └── dispatcher.py # 调度器 ├── skills/ │ ├── __init__.py │ ├── weather.py # 天气查询技能 │ ├── calculator.py # 计算器技能 │ └── datetime_skill.py # 时间日期技能 └── skills_manifest.json # 技能描述清单

这样的结构把“核心调度”和“技能实现”分离开。以后加技能时，只需要在 skills/ 目录下新增文件，并更新清单，不需要改动调度器。

5.3 安装依赖

示例本身不依赖第三方库，所以 requirements.txt 可以是空的，也可以只写一个空文件。如果你在后续步骤中接入了向量匹配或大模型接口，再按实际需要安装依赖即可，比如：

pip install requests openai

这里不锁定具体版本，以实际项目安装时的最新版本为准。

6. 核心流程拆解：从零实现一个最小技能系统

下面把实现过程拆成四个步骤，每一步都有明确目标和常见坑。

6.1 第一步：定义技能注册表

技能注册表是整个系统的基础，负责维护“技能名字到技能实现”的映射。它必须支持三个操作：注册技能、列出全部技能、按名字获取技能。

这一步常见的错误是：把技能注册和技能实现写死在同一个类里。这样做的副作用是，每新增一个技能都要改注册表类，违背了开闭原则。更合理的做法是让每个技能模块提供一个统一的入口，注册表负责扫描或显式注册。

6.2 第二步：实现具体技能

每个技能模块对外暴露一个 handle 方法，接收一个字典参数，返回一个字典结果。这种“输入输出都是字典”的约定，是为了让调度器可以统一编排，不用为每个技能写不同的调分支。

技能内部可以包含自己的业务逻辑，比如查询数据库、调用外部 API、执行本地计算。对本文示例来说，技能内部先用模拟数据演示，重点放在结构而不是业务实现。

6.3 第三步：实现调度器

调度器的输入是用户请求，输出是技能执行结果。内部逻辑分为三步：先从技能清单中检索候选技能，再从用户请求中抽取参数，最后调用技能执行并捕获异常。

这一步的关键坑是：不要把所有用户请求直接塞给技能函数。技能函数只接收干净的参数，不做天然的语义理解。参数抽取放在调度层统一处理。

6.4 第四步：组装入口程序

入口程序读取用户输入，交给调度器，输出结果。这是最薄的一层，主要负责 IO 和用户体验。它不应该包含任何业务逻辑。

到这里，整个最小系统的结构已经很清晰了。下面直接看完整代码。

7. 完整示例与代码实现

7.1 技能注册表：core/skill_registry.py

# 文件路径：core/skill_registry.py from typing import Callable, Dict, Optional class SkillRegistry: """技能注册表：维护技能名称与执行函数之间的映射关系。""" def __init__(self) -> None: self._skills: Dict[str, Dict] = {} def register(self, skill_meta: Dict, handler: Callable) -> None: """注册一个技能。 Args: skill_meta: 技能描述字典，包含 name、description 等字段。 handler: 技能执行函数，接收 dict 参数，返回 dict 结果。 """ name = skill_meta.get("name") if not name: raise ValueError("技能 meta 中必须包含 name 字段") self._skills[name] = { "meta": skill_meta, "handler": handler, } def get(self, name: str) -> Optional[Dict]: """根据技能名获取注册信息。""" return self._skills.get(name) def list_skills(self) -> list: """返回所有技能的元信息列表。""" return [item["meta"] for item in self._skills.values()]

7.2 具体技能：skills/weather.py 与 skills/calculator.py

# 文件路径：skills/weather.py def weather_skill(params: dict) -> dict: """天气查询技能的模拟实现。""" city = params.get("city", "") if not city: return { "success": False, "fallback": "请告诉我你想查询哪个城市的天气。", } # 实际项目中，这里可以替换为真实天气 API 调用。 weather_data = { "北京": {"temperature": "18°C", "condition": "晴", "wind": "北风3级"}, "上海": {"temperature": "22°C", "condition": "多云", "wind": "东南风2级"}, "广州": {"temperature": "26°C", "condition": "小雨", "wind": "南风2级"}, } data = weather_data.get(city) if not data: return { "success": False, "fallback": "暂时没有该城市的天气数据，请检查城市名。", } return { "success": True, "message": f"{city}当前天气：{data['condition']}，" f"温度 {data['temperature']}，{data['wind']}。", }

# 文件路径：skills/calculator.py def calculator_skill(params: dict) -> dict: """计算器技能的模拟实现。""" expression = params.get("expression", "").strip() if not expression: return { "success": False, "fallback": "请提供一个数学表达式，例如：1 + 2 * 3。", } # 注意：eval 存在安全风险，仅用于本地演示。 # 生产环境务必使用安全的表达式解析库，或对输入做严格白名单校验。 try: result = eval(expression) except Exception: return { "success": False, "fallback": "表达式不合法，请检查后重试。", } return { "success": True, "message": f"{expression} = {result}", }

这里有两个值得注意的安全边界。第一个是 eval 的使用，示例代码里已经明确标注了风险，生产环境不建议直接使用 eval。第二个是技能函数的返回格式，统一使用 success + message/fallback，这样调度器和入口程序可以用同一套逻辑渲染结果。

7.3 技能描述清单：skills_manifest.json

调度器需要一份不依赖代码执行的技能清单，用来做意图匹配。这份清单就是所有技能的“简历”：

{ "skills": [ { "name": "weather_query", "keywords": ["天气", "温度", "下雨", "刮风", "气温"], "description": "查询指定城市的当前天气情况", "handler": "skills.weather.weather_skill" }, { "name": "calculator", "keywords": ["计算", "等于", "加减乘除", "数学"], "description": "计算用户提供的数学表达式", "handler": "skills.calculator.calculator_skill" } ] }

keywords 字段在本文示例中直接参与规则匹配。实际生产项目可以把这个字段替换为嵌入向量，但关键词字段仍然具备很强的可解释性，适合做旁路校验。

7.4 调度器：core/dispatcher.py

# 文件路径：core/dispatcher.py import json from typing import Dict, Optional from core.skill_registry import SkillRegistry class Dispatcher: """基于规则的调度器： 1. 遍历技能清单，通过关键词匹配候选技能。 2. 对候选技能做参数抽取。 3. 调用技能执行函数并返回结果。 """ def __init__(self, registry: SkillRegistry, manifest_path: str) -> None: self.registry = registry with open(manifest_path, "r", encoding="utf-8") as f: self.manifest = json.load(f) def _match_skill(self, user_input: str) -> Optional[Dict]: best_skill = None best_score = 0 for skill in self.manifest["skills"]: score = 0 for kw in skill.get("keywords", []): if kw in user_input: score += 1 if score > best_score: best_score = score best_skill = skill return best_skill if best_score > 0 else None def _extract_params(self, user_input: str, skill_name: str) -> dict: if skill_name == "weather_query": # 简单抽取：从输入中截取城市名，这里用白名单演示。 cities = ["北京", "上海", "广州"] for city in cities: if city in user_input: return {"city": city} return {} if skill_name == "calculator": # 简单抽取：去掉“计算”等指令词，剩余部分作为表达式。 expr = user_input.replace("计算", "").replace("等于", "").strip() return {"expression": expr} return {} def dispatch(self, user_input: str) -> dict: skill = self._match_skill(user_input) if not skill: return { "success": False, "fallback": "我没有理解你的需求，可以换个说法试试。", } registered = self.registry.get(skill["name"]) if not registered: return { "success": False, "fallback": f"技能 {skill['name']} 未注册，请检查代码。", } params = self._extract_params(user_input, skill["name"]) try: handler = registered["handler"] result = handler(params) return result except Exception: return { "success": False, "fallback": "技能执行出错，请稍后再试。", }

7.5 入口程序：main.py

# 文件路径：main.py from core.dispatcher import Dispatcher from core.skill_registry import SkillRegistry from skills.calculator import calculator_skill from skills.weather import weather_skill def build_registry() -> SkillRegistry: registry = SkillRegistry() # 这里演示两个技能的显式注册。 registry.register( { "name": "weather_query", "description": "查询指定城市的当前天气情况", }, weather_skill, ) registry.register( { "name": "calculator", "description": "计算用户提供的数学表达式", }, calculator_skill, ) return registry def main() -> None: registry = build_registry() dispatcher = Dispatcher(registry, "skills_manifest.json") print("Agent Skills 演示系统已启动，输入内容后按回车执行。") print("输入 exit 退出系统。\n") while True: user_input = input("你：").strip() if user_input.lower() == "exit": break result = dispatcher.dispatch(user_input) if result.get("success"): print("Agent：", result["message"]) else: print("Agent：", result["fallback"]) if __name__ == "__main__": main()

这个入口程序最核心的价值是演示了组装方式：先构建注册表，再构建调度器，然后循环处理输入。所有新增技能都不会影响这段代码，只要在 build_registry 中增加注册、在 manifest 中增加描述即可。

8. 运行结果与效果验证

在项目根目录执行：

python main.py

预期交互如下：

Agent Skills 演示系统已启动，输入内容后按回车执行。 输入 exit 退出系统。 你：北京天气怎么样 Agent：北京当前天气：晴，温度 18°C，北风3级。 你：计算 12 * (3 + 5) Agent：12 * (3 + 5) = 96 你：帮我订张机票 Agent：我没有理解你的需求，可以换个说法试试。

如何判断运行成功？三条验证路径：

第一，输入包含天气关键词的句子，能触发 weather_query 技能，说明关键词匹配生效。第二，输入包含“计算”关键字的数学表达式，能触发 calculator 技能，说明调度器能在多个技能之间正确路由。第三，输入完全不相关的句子，能走兜底分支，说明异常路径被覆盖。

如果某一步输出不对，先不要改代码，按顺序排查：

先看 skills_manifest.json 里的 keywords 是不是覆盖了你的测试句子。
再看 main.py 里是否调用了 registry.register 注册对应技能。
再看技能函数内部返回的是 success True 还是 False，判断是调度问题还是执行问题。

从工程角度看，运行一次只是开始。真正要验证的是“扩展性”：在 skills/ 下新增第三个技能，在 manifest 中加一段描述，在 main.py 中加一行注册，测试调度器能不能在不改核心逻辑的前提下路由到新技能。这一条验证通过，说明你的技能系统是相对干净的。

9. 常见问题与排查思路

问题现象	可能原因	排查方式	解决方案
输入“北京天气”没有触发技能	manifest 中的 keywords 没覆盖“天气”	打印 _match_skill 的返回结果	在 weather_query 的 keywords 中补充相应关键词
多个技能同时命中	不同技能 keywords 有交集	检查各技能 keywords 是否有重叠	把专用词抽出来，或用“权重”概念调整匹配优先级
技能函数接收到的参数为空	参数抽取逻辑未匹配到	打印 dispatch 中的 params	扩展 _extract_params，加入城市名和表达式抽取逻辑
技能执行时报错但入口无提示	异常被 Dispatcher 捕获，没有记录日志	在 except 分支中添加 logging	增加日志输出，记录技能名和异常堆栈
新增技能后调度器无法找到	只写了技能文件，没注册、没更新 manifest	检查注册表和 manifest 是否同步更新	新增技能时，注册表、manifest、技能文件三处同步修改
生产环境中技能运行超时	外部 API 调用未设置超时	检查技能函数是否有超时控制	为所有网络请求增加超时参数和重试策略
技能之间的参数命名冲突	不同技能使用同名但语义不同的参数	检查各技能入参约定	在技能描述文档中统一参数命名规则

这里的核心经验是：大部分问题不在模型，而在“描述层”和“接入层”。描述层写得不清楚，调度器就选不准；接入层没有日志，执行错误就不可追踪。

10. 最佳实践与工程建议

10.1 技能命名与描述规范

技能命名要做到“一看就知道用在哪”。推荐格式是：领域_动作，比如 weather_query、order_create、payment_refund。描述字段要写明两件事：什么时候该用、什么时候不该用。

反例是写“处理用户的问题”，这种描述没有任何调度价值。正例是“仅当用户明确要求创建新订单时调用本技能；如果用户只是查询订单状态，请调用 order_query 技能”。

10.2 技能版本管理

技能包一旦被多个 Agent 或服务引用，就必须引入版本管理。可以在 manifest 里增加 version 字段，并在调度日志中记录实际使用的技能版本。变更技能逻辑时不要直接覆盖老版本，建议发布为新版本，让下游消费者逐步迁移。

10.3 日志与监控

每次调度都应该记录：用户请求原文、命中的技能名、调度置信度、参数抽取结果、执行耗时、返回状态。这些数据是后续优化调度精准度的基础。没有日志，就没有资格谈优化。

在实现上，可以在 Dispatcher 的 dispatch 方法中加一个结构化日志，把关键字段以 JSON 形式输出，方便接入日志采集系统。

10.4 安全与权限边界

技能执行时应该遵守最小权限原则。一个技能只需要读取数据的权限，就不要给它写数据库的权限；一个技能只需要调用只读 API，就不要在环境变量里配置管理员密钥。

特别注意动态执行类技能，比如“执行用户传入的代码”。这类技能如果没有做输入校验，风险极高。如果业务上必须支持，至少要做到：使用白名单语言、限制运行资源、在沙箱环境中执行、禁止访问内网和敏感文件。

10.5 技能复用与团队协作

建议团队维护一个“技能仓库”，所有技能按照统一规范提交，包含文档说明、示例输入输出、依赖声明、负责人信息。新的 Agent 项目优先从技能仓库选技能，而不是每个项目都从零开始写。

这样做的好处是，技能的打磨可以跨项目积累。第一次封装可能比较粗糙，用过几次之后，大家对边界、异常、描述的理解都会加深，技能包的质量也会持续提升。

11. 总结与后续学习方向

从这篇文章你应该得到几个清晰结论：

Agent Skills 不是模型能力的替代品，而是模型能力的工程化组织方式。它把“告诉模型怎么做”和“让模型能执行”这两件事，统一封装成一个可描述、可调度、可扩展的模块。

技能封装的重点不只是函数实现，更是“描述层”和“约束层”。一个函数加上清晰描述和兜底逻辑，才称得上技能；一个函数丢给模型自由发挥，那还是 Tool 调用。

调度器的设计决定了系统能否扩展到几十个技能。从规则匹配、语义匹配到大模型选择，不同阶段用不同策略，不要让调度器成为单点瓶颈。

如果你想把这条路继续走深入，建议按这个顺序实践：

第一，给当前项目里最常用的 3 个工具函数补齐技能描述、参数约束和兜底文案，观察 Agent 的调用准确性变化。第二，给调度器增加日志和指标统计，用数据验证技能库是否在正向增长。第三，尝试接入嵌入模型做语义检索，把关键词匹配升级为向量匹配，看看意图路由的覆盖率能提升多少。

进入生产环境后，再逐步考虑技能仓库、权限隔离、灰度发布和监控告警。到这一步，你已经不是在“调用工具”，而是在建设一套可生长的 Agent 能力体系了。