1. 核心概念拆解1.1 什么是 Agent Skills这两年提到大模型应用大家翻来覆去绕不开那几个词RAG、Function Calling、Fine-tuning。但真到了生产环境里你会发现单靠这些还不够——模型能理解你的指令不等于它能把一件事从头做到尾。这里缺的是一个把“理解”转化为“执行”的中间层。Agent Skills 解决的就是这个问题。你可以把 Agent Skills 理解成一组可复用、可组合、可管理的能力模块。每个 Skill 定义了一个具体的操作能力比如“查天气”“生成图表”“操作数据库”“发送邮件”“解析日志”。它不是让模型自己凭空想出来的动作而是把动作标准化、接口化让模型按既定流程去调用和执行。换句话说Skills 是一套给大模型的“操作手册工具箱”模型负责判断该做什么Skills 负责把事情做出来。我最早接触这个概念是从 LangChain 的工具定义开始的。你定义一个函数写清楚参数和描述模型就能根据用户意图去调用它。这本质上就是 Skill 的雏形。但到后面你会发现单个工具太零碎了真正落地的时候你需要的是整套能力——工具可能十几个、几十个它们之间有依赖、有先后顺序、有权限边界甚至要组合成更复杂的任务流。把这一层抽出来统一管理就是 Skills 体系要做的事。1.2 它解决了什么问题如果你写过大模型应用大概率遇到过这么几种尴尬场景。第一种意图能识别执行拉胯。模型告诉你它要调用搜索功能但你的搜索函数返回的数据格式变了或者搜索逻辑有更新模型还在用旧的方式去调。这种问题用 Fine-tuning 去解决纯属杀鸡用牛刀成本高不说模型生命周期短几个月一换你训练的速度根本追不上。第二种能力不可复用。项目里 A 模块写了一个 PDF 解析函数B 模块又写了一个功能基本一样参数都对不上谁也不愿意去动谁的代码。到最后维护成本越来越高大家只能靠复制粘贴过日子。第三种权限和安全没法统一管。有的调用需要鉴权有的调用需要限流有的调用只能内部用。你把这些逻辑散落在各个业务代码里出问题的时候排查到你怀疑人生。Agent Skills 的思路是把这些零散的工具调用整合成一个规范化的能力层。每个 Skill 有统一的描述格式、输入输出定义、版本管理、错误处理逻辑。模型层只跟 Skills 层交互不直接依赖底层实现。这样你换模型也好、扩能力也好、加权限也好改动都很集中不会牵一发动全身。2. 技能库的设计思路2.1 如何设计一个易扩展的 Skill 格式我做过几套不同风格的 Skill 方案折腾到最后觉得最稳的还是把 Skill 的定义拆成四块元信息、输入输出 Schema、执行逻辑、描述文档。元信息解决“这个 Skill 是谁、能干什么、要怎么被调用”的问题。包含 Skill 名称、版本号、用途说明、依赖关系、超时时间和安全等级。版本号尤其重要Skill 的迭代和业务代码不一样它经常要和模型版本绑定出问题要能回溯。输入输出 Schema 解决的是“模型怎么理解调用规则”。我强烈建议用 JSON Schema 格式来定义不光是规范主要是很多模型框架原生支持 JSON Schema 校验模型输出的参数可以直接过校验非法调用直接拦截不必跑到执行的时候才发现参数传错了。执行逻辑就是具体的 Python 函数或者命令行封装。描述文档则是一段面向模型优化过的自然语言告诉模型什么时候该用这个 Skill、参数怎么写、结果怎么解读。很多团队忽略这个但实际经验是模型选技能选得准不准80% 靠的是这段描述质量。写得含糊模型就乱调用写得太啰嗦模型在长上下文里容易抓不住重点。我的经验是一般控制在 100 到 200 字之间把关键的触发条件、限制条件说明白就行。2.2 为什么选这种分层结构可能有人问直接画个类、定义几个方法不就行了吗搞这么复杂干什么原因有二。第一现在的架构里大模型调用 Skills 和传统程序调用函数是不同的逻辑——传统程序是确定性的你知道会走到哪个分支大模型是不确定性的它可能选错 Skill、传错参数、甚至反复调用同一次操作。你必须在各个位置设立明确的约束和反馈机制否则就等于纵容模型自由发挥出了错你无从下手。分层结构最大的价值是让每一层各司其职约束各自管好一段出问题能快速定位。第二可组合性。Agent Skills的设计重点不在单个 Skill 多强而在于组合。我很早之前写过一套三步走的技能先检索文档、再总结要点、最后生成报告。如果我把它写成一个大函数也不是不行但拆成三个 Skill 之后我可以在其他地方复用其中任何一步也可以替换其中某一步的实现而不影响其他部分。分层设计天然鼓励这种“拆开再组装”的思维方式。2.3 目录结构与命名规范技能库维护到后期最大的敌人不是写代码是找代码。一套好的目录结构能让你少掉一半头发。我用的比较多的是按能力域分目录skills/ ├── datasource/ │ ├── mysql_query/ │ ├── mongodb_aggregate/ │ └── oss_download/ ├── document/ │ ├── pdf2text/ │ ├── docx_generate/ │ └── markdown_convert/ ├── network/ │ ├── http_request/ │ ├── image_download/ │ └── rss_fetch/ └── analysis/ ├── sentiment_score/ ├── keyword_extract/ └── trend_statistics/每个 Skill 命名用小写下划线目录内固定放四个文件skill.yaml存元信息schema.json存参数定义main.py存执行逻辑description.md存面向模型的描述。目录结构固定之后加载逻辑就简单了遍历目录、解析 yaml、注册到技能管理器新加一个 Skill 完全不用改框架代码。3. 核心实现方案3.1 技能注册与加载机制实现 Agent Skills 的第一步是设计一个技能加载器。你得告诉系统有哪些技能可用、分别在哪里、怎么实例化。这块我建议做一个 SkillRegistry 类统一管理而不是让上层业务到处 import 技能。import os import yaml import json import importlib.util from typing import Dict, Any, Optional from pydantic import BaseModel, ValidationError class SkillMeta(BaseModel): name: str version: str description: str timeout: int 30 requires_auth: bool False dependencies: list [] class Skill: 一个可执行的技能单元 def __init__(self, meta: SkillMeta, schema: dict, handler): self.meta meta self.schema schema self.handler handler async def run(self, **kwargs) - Any: # 这里的实际场景中可以从 Redis 或消息队列读取任务 return await self.handler(**kwargs) class SkillRegistry: def __init__(self): self._skills: Dict[str, Skill] {} def load_from_dir(self, skills_root: str): for domain_dir in os.listdir(skills_root): domain_path os.path.join(skills_root, domain_dir) if not os.path.isdir(domain_path): continue for skill_name in os.listdir(domain_path): skill_dir os.path.join(domain_path, skill_name) if not os.path.isdir(skill_dir): continue self._load_single_skill(skill_dir) def _load_single_skill(self, skill_dir: str): meta yaml.safe_load(open(os.path.join(skill_dir, skill.yaml), encodingutf-8)) schema json.load(open(os.path.join(skill_dir, schema.json), encodingutf-8)) spec importlib.util.spec_from_file_location( main, os.path.join(skill_dir, main.py)) module importlib.util.module_from_spec(spec) spec.loader.exec_module(module) skill Skill(SkillMeta(**meta), schema, module.execute) self._skills[skill.meta.name] skill def get_skill(self, name: str) - Optional[Skill]: return self._skills.get(name) def list_skills(self) - list: # 在真实服务里这一步还可以做一些权限过滤 return [ {name: s.meta.name, version: s.meta.version, description: s.meta.description} for s in self._skills.values() ] async def dispatch(self, name: str, **kwargs): skill self.get_skill(name) if not skill: raise KeyError(fSkill {name} 未注册) # 按 schema 精简参数避免模型传输多余字段 allowed_keys skill.schema.get(properties, {}).keys() filtered {k: v for k, v in kwargs.items() if k in allowed_keys} return await skill.run(**filtered)注册器这块有几个细节值得留意。importlib.util.spec_from_file_location虽然直观但如果技能太多、需要频繁热加载路径冲突管理会变得繁琐。真实项目中我建议用标准 Python 包的格式每个 Skill 目录下放一个__init__.py把main.py包进去。另外pydantic的ValidationError捕获不能只写在调度层更要在执行层做一次兜底。加载完成之后是给模型用的。模型需要知道当前环境里有哪些 Skills、参数长什么样。这块一般有两种做法一是把所有技能描述合并成一个大 Prompt 里的一部分二是启用 Function Calling 机制把技能定义注册为可用的工具。前者对模型上下文要求比较宽松但技能多了会吃掉大段 token我见过最多的项目跑到二三十个技能的时候就扛不住了后者更省 token但模型必须支持 Function Calling对开源模型来说需要额外评估。3.2 模型如何选择正确的技能这一步是整个 Agent Skills 设计的核心难点没有之一。你用脚本调用函数是人手写的你一定知道调哪个但模型会根据用户输入动态决定调哪个技能这意味着你必须在模型、技能描述、历史对话、用户意图四者之间建立一套可靠的映射规则。我先说一个不推荐的做法把全部技能塞给模型让它自由选择。在小规模 demo 的时候这完全没问题但技能一旦超过十五到二十个准确率会明显下滑模型经常出现“张冠李戴”——比如用户想查数据库里的订单量模型却调了日志搜索的技能。原因是通用模型的工具选择能力有限技能描述之间的区分度不够它就容易混淆。所以我目前的方案是分级调度。第一级是意图路由——先让模型判断用户请求属于哪个大类比如数据查询类、文档处理类、网络请求类。第二级才是精确技能选择只在对应的大类里面挑具体技能。这样每个选择器面对的技能列表都不长准确率就好很多。路由的返回可以考虑用结构化 JSON 而不是自然语言自然语言会有解析误差JSON 稳定得多。{ domain: data_query, intent: retrieve_order_count, confidence: 0.91, fallback_skills: [mysql_query, es_query] }如果模型返回的confidence低于预设阈值我会调用兜底策略先让模型换一种表述重新路由不行就直接提示用户“这个请求比较复杂建议先选择以下场景”。这个流程实测下来能解决掉很大一部分误调用问题。补充一点很多团队会在技能描述里写一堆“你需要什么就调用我”这种话术但实际上模型对这种模糊表述并不敏感。反而你写清楚“如果用户提到 XXX 或者 YYY请调用本技能但如果是 ZZZ 场景请优先考虑其他技能”这种明确的约束模型更容易遵循。我在 description.md 里花了大量篇幅做正反例说明用下来效果立竿见影。从执行效率的角度分级调度分层模型还带来一个额外好处路由模型可以用小参数模型比如 Qwen-7B 或者 LLaMA-8B 甚至更小规模的模型足够处理分类问题只有真正具体的执行过程才需要大模型。这样算力成本可以分摊不会所有请求都走最大的模型整体延迟也能压低不少。3.3 技能并发与异步调度一旦你的技能库面向真实服务并发问题就会浮现。最简单的做法是同步执行串行跑。但用户同时发起多个技能请求比如既查库存又查物流那就得做异步编排。我在一个生产环境里的做法是引入任务编排层叫 SkillOrchestrator。它负责把一个复杂请求分解成多个技能调用步骤并管理它们之间的依赖关系。比如“查询订单状态并通知用户”这一流程拆解为先调用order_query获取订单状态再调用notification_send发送结果。后者依赖前者。这两步之间有一个依赖关系图编排器就是维持这个图的调度中枢。import asyncio from typing import Callable, Awaitable class SkillOrchestrator: 轻量级的技能编排调度器 def __init__(self, registry: SkillRegistry): self.registry registry self._deps: dict[str, set[str]] {} def add_dependency(self, skill_a: str, depends_on: str): self._deps.setdefault(skill_a, set()).add(depends_on) async def run_sequence(self, plan: list[str], context: dict): results {} # 分批次执行无依赖的技能 staged self._topological_sort(plan) for batch in staged: tasks [ self._exec_with_retry(name, context, results) for name in batch ] batch_results await asyncio.gather(*tasks, return_exceptionsTrue) for name, res in zip(batch, batch_results): results[name] res return results async def _exec_with_retry(self, name, context, results, max_retry3): skill self.registry.get_skill(name) payload self._inject_context(name, context, results) for attempt in range(max_retry): try: return await skill.run(**payload) except Exception as e: if attempt max_retry - 1: raise await asyncio.sleep(2 ** attempt)现实里有几类依赖关系结果依赖、状态依赖、资源依赖。结果依赖简单上一个输出是下一个输入的一部分。状态依赖要注意比如“调用某 API 之前必须先初始化认证”这种是运行时状态不能依赖函数参数传值。我把这些依赖信息也写进 skill.yaml 里作为requires字段由编排器在启动前做一次静态校验。3.4 参数校验与容错设计Agent Skills 的参数校验和普通 API 不同普通 API 的调用方是前端前端参数一般是有固定格式的Agent 调用的参数是模型生成的模型生成的东西天然不稳定同一个字段不同时候可能是字符串也可能是数字。我在 schema.json 里定义了类型但模型不一定遵守。因此我强烈建议引入两步校验。第一步是软校验在把参数传给 Skill 之前用 JSON Schema 校验器做一次检查不合法的参数能自动转换的先转换比如把二十三转成 23不能转换的直接丢弃。第二步是硬校验在 Skill 内部执行时再做一次防御性检查防止脏数据跑到数据库查询语句里def execute(order_id: str None, user_id: str None, **kwargs): if not order_id and not user_id: raise ValueError(order_id 或 user_id 至少提供一个) # 防注入只允许字母数字 if order_id and not re.fullmatch(r[A-Za-z0-9_-], str(order_id)): raise ValueError(f非法 order_id: {order_id}) ...模型传参不像人那么敏感给个日期范围它可能给你传“2023年1月到2月”也可能传“2023-01-15 到 2023-02-28”。我见过比较靠谱的解决办法是给每个 Skill 的 schema 里加上枚举或 format 约束再配合少量 few-shot 示例把输入格式要求固化下来。模型学这类约束特别快给两三个例子就够了。4. 实操过程与核心环节实现4.1 从零构建一个简单技能库现在撸一个最小可运行的例子让大家感受一下这个体系跑通是什么感觉。目标技能库包含两个能力一个查询当前天气一个把查询到的天气信息整理成简短播报。场景很日常用来理解整个链路刚好。# skills/network/weather_query/skill.yaml name: weather_query version: 1.0.0 description: 根据城市名称查询实时天气情况 timeout: 15 requires_auth: false dependencies: - http_request# skills/network/weather_query/schema.json { type: object, properties: { city: { type: string, description: 城市名称如 北京、上海、广州 }, unit: { type: string, enum: [celsius, fahrenheit], default: celsius } }, required: [city] }# skills/network/weather_query/main.py import aiohttp async def execute(city: str, unit: str celsius, **kwargs): # 示例实现真实场景请替换为天气服务商 API url https://api.example.com/weather params {city: city, unit: unit} async with aiohttp.ClientSession() as session: async with session.get(url, paramsparams) as resp: resp.raise_for_status() data await resp.json() return { city: city, temperature: data[current_temp], condition: data[condition], humidity: data[humidity], }第二个技能weather_report依赖weather_query的结果把结构化数据转成一句自然语言的播报。模型层面的描述写成这样# weather_report 根据天气查询结果生成一段适合语音播报的简短天气说明。 输入城市名、温度、天气状况、湿度。 输出一段50字以内的中文播报文本。 注意不要编造数据只描述输入中包含的信息。然后我用注册器加载再模拟一次模型调度过程。实际跑起来之后的链路是这样的用户输入“北京今天天气怎么样适合跑步吗?”意图路由判断请求属于 weather domain焦点在 query 和 report 两类。模型决策调用weather_query获取北京天气数据。拿到结构化结果后再决策调用weather_report生成播报文本。将最终文本返回给用户。这段流程如果靠手工写死也能跑但一旦技能数量上来、技能之间出现依赖关系手工写死的代价就变得不可控了。而按上面这套结构整个系统是数据驱动的模型在线动态决策每次调用的入参、出参、依赖关系都是可观测的。4.2 技能描述优化的实战经验很多团队在技能描述这块严重偷懒直接写一句“查询天气”剩下的全靠模型自己悟。我吃过亏后来摸索出来一套写法分享给大家。描述文档要分成三个段落。第一段是触发条件用正反例说明“什么情况下用我什么情况下别用我”。第二段是参数规则解释参数含义和格式配合两三个示例。第三段是输出规范告诉模型返回结果的结构。第三段虽然看起来是废话但对上游消费结果的流程特别重要。如果模型不知道输出要带temperature字段它可能直接输出“今天22度”然后下游字段就断链了。# 触发条件 当用户询问某个城市的实时天气、气温、风力、湿度等信息时调用本技能。 如果用户询问的是空气质量指数请改用 air_quality 技能。 如果用户询问的是天气预报未来一周请改用 weather_forecast_week 技能。 # 参数规则 - city: 中文城市名如 北京、苏州、成都。 - unit: 温度单位celsius默认或 fahrenheit。 示例 - { city: 北京, unit: celsius } - { city: 成都 } # 输出格式 返回 JSON { city: 城市名, temperature: 数值, condition: 天气状况描述, humidity: 湿度百分比 }这样写下来模型基本不会选错技能、传错参数。我建议每个技能描述控制在 150 行以内超过这个量不是不行但你得反复验证模型有没有漏掉关键信息。通用的描述模板当然能减少工作量但如果所有技能的描述都长成一个模板样模型反而容易混淆它们所以每个场景的反例说明尽量具体一点。4.3 热加载与版本管理真实场景里技能库不可能每次都随主应用一起发版。你想快速上线一个新技能而不影响已有服务就必须支持热加载。我在注册器里加了一个reload_skill方法传入新的技能包路径校验通过后替换旧实例。替换时需要注意一个坑如果有长连接或者运行中的任务正在使用旧技能直接替换会有资源泄露或状态不一致的风险。稳妥的做法是先注册新版本等旧任务全部结束后再下线旧版本类似蓝绿发布。from datetime import datetime class VersionedSkillRegistry(SkillRegistry): def __init__(self): super().__init__() self._versions {} def activate_skill(self, name: str, version: str): if version ! self._versions.get(name, ): # 标记新版本 self._versions[name] version # 这里实际还需要更新缓存标记挂载到配置中心等 self._reload_from_registry_center(name) def _reload_from_registry_center(self, name: str): # 从配置中心拉取该技能最新内容并更新 pass def list_active_versions(self): return { name: {version: v, updated_at: datetime.now().isoformat()} for name, v in self._versions.items() }版本管理我建议直接用 Git 打 tag。每个技能包对应一个 tag发布流程走 CI/CD构建产物上传到对象存储运行时从存储拉取加载。这套方案的优点是你随时能回溯到任何一个历史版本排查线上问题的时候极其有用。我现在维护的线上技能库共管理着四十多个技能版本历史全部依赖 Git几乎没有出过因为技能变更导致的事故出过的两次也都是因为变更后没刷新缓存后来加了缓存一致性检查就稳了。4.4 一个完整调用链的配置示例给你看一套完整可跑的配置这是生产环境提取出来的简化版足够你照葫芦画瓢搭建自己的首版。# config/skills.config.yaml server: port: 8701 workers: 10 registry: scan_paths: - /data/skills/datasource - /data/skills/document - /data/skills/network - /data/skills/analysis redis: host: 127.0.0.1 port: 6379 db: 3 auth: enabled: true token_url: http://internal.auth/api/v1/token scheduler: max_concurrency: 8 default_timeout: 15 retry_times: 3# 启动入口 import asyncio import aiohttp from skills import SkillRegistry, SkillOrchestrator async def main(): registry SkillRegistry() registry.load_from_dir(/data/skills) orchestrator SkillOrchestrator(registry) orchestrator.add_dependency(order_query, depends_onuser_auth) orchestrator.add_dependency(notification_send, depends_onorder_query) # 模拟一个带编排的业务请求 plan [user_auth, order_query, notification_send] context {user_id: u12345, order_id: ord67890} result await orchestrator.run_sequence(plan, context) print(result) if __name__ __main__: asyncio.run(main())这套配置里scan_paths支持多个目录扫描方便把不同团队的技能目录挂进来auth开启后所有 Skill 调用前会先校验 token校验逻辑可以统一封装在注册器里不污染业务技能逻辑。5. 常见问题与排查技巧实录5.1 模型总选错技能怎么办这个问题是 Agent 应用上线后最常遇到的反馈没有之一。先不要急着骂模型大多数情况下是技能定义的问题。排查分四步走第一步看命名是否有歧义。比如有两个技能分别叫db_query和es_query模型可能困惑于“查询用户订单”到底应该调哪个。如果业务上确实分不清边界那就要在描述里把边界写清楚。第二步看描述是不是太笼统。我见过一份技能描述写的是“支持各类数据查询操作”这种说法模型完全抓不住重点。第三步看是不是技能数量过大。超过十几个技能强行让模型精确匹配失误率就是会飙升所以优先考虑前面说的分级路由。第四步看是不是缺少示例对话。有些模型对工具选择的 few-shot 依赖很强你可以准备几条用户提问和期望技能选择的示例放进系统 Prompt 里稍微引导一下。我还有一个压箱底的经验上线初期把所有模型的技能选择日志全部打开哪怕是错误的调用也记录下来。攒一个星期的日志之后拉出来分类你会发现大部分错误集中在少数几个技能上针对性优化这几个技能的描述准确率很快就能从 70% 拉到 90% 以上。5.2 技能调用超时和依赖失败超时是另一个高频问题。Agent 技能调用牵涉网络请求、数据库操作、外部 API任何一个环节卡住都会让整体流程失败。这里有两个原则第一每个技能必须有独立的超时配置不能默认都用一个值。外部 API 调用 15 秒还等得数据库查询 15 秒可能就太长了。第二编排器在技能超时后要有明确的返回策略。是重试是跳过还是带着部分结果继续往下执行这要看具体业务对完整性要求有多高。依赖失败时的处理我一般按两种场景分开设计如果是强依赖比如获取用户 token 失败后面什么都做不了直接返回失败结果并告知用户重新授权如果是弱依赖比如天气服务商的湿度字段拿不到不影响温度展示就返回降级结果删掉缺失字段同时标记partial_result: true让模型知道这不是完整数据。async def run_skill_with_fallback(skill_name: str, fallback_name: str, **kwargs): try: return await registry.dispatch(skill_name, **kwargs) except Exception as e: logging.error(fSkill {skill_name} 失败降级到 {fallback_name}: {e}) return await registry.dispatch(fallback_name, **kwargs)依赖失败的链路上我最常踩的坑是跨技能的上下文传递。A 技能的返回结果需要传给 B 技能做输入但 A 的返回字段名是order_idB 的参数名是orderNo字段对不上调度器传参直接全崩。后来我在每个技能的 schema 里统一加了输出字段别名映射的概念所有技能之间的数据交换走统一格式内部字段可以不一致但对外暴露的接口保持一致这类问题才真正消停。5.3 安全边界与权限控制技能一旦开放给模型调用安全问题就成了大问题。模型可以自主决定调用技能的时间、顺序和频率如果技能本身有权限漏洞那等于给外部攻击者开了一扇代理门。我总结出来几条实操原则第一技能不要直接暴露到公网。所有技能的出入参在网关层做统一的鉴权、审计、限流再转发给内部执行。第二技能的鉴权信息绝不能让模型自己携带。比如查询数据库要用的连接串放在技能的配置环境变量里不在参数列表中暴露。模型都不知道自己有权限访问数据库它也就没办法尝试越权传输这些敏感数据。第三对模型可触发的技能做白名单控制。每个用户角色、每个会话只能访问部分技能超出范围的调用直接拒绝。这个控制和技能本身的注册解耦独立维护一套 ACL 规则。第四技能的敏感操作要设置二次确认。比如“发送邮件”“转账”“删除订单”这类操作不能模型说调就调必须回传一个确认指令等用户回复确认后才真正执行。这一步非常关键能帮你拦住一大批模型误操作导致的事故。5.4 长流程任务的进度追踪与恢复有些技能调用链路特别长比如“汇总上周销售数据并发送报表邮件”可能需要一分钟甚至更久。这时候同步等待结果对用户很不友好而且中途断连就全没了。我的做法是把任务拆成 Job每个 Job 记录到存储里技能执行过程中持续更新状态用户可以通过查询接口随时了解进度。{ job_id: job_202501151230, status: processing, steps: [ {skill: sales_data_query, status: completed, duration_ms: 2300}, {skill: report_generate, status: processing, progress: 60}, {skill: email_send, status: pending} ], current_error: null, result: null }任务恢复这个需求一般不太起眼但做企业级应用时必须考虑。比如某个技能在等待外部 API 反馈时进程宕机了重启后这个任务是不是要重新跑如果重新跑用户看到的状态就乱了。我在这块用了任务状态持久化配合唯一任务 ID执行前检查状态表跳过已完成步骤。这个方案的复杂度可控但对整体稳定性的提升非常明显。6. 扩展方向从单技能到多 Agent 协作6.1 Skills 如何支撑多 Agent 架构单个 Agent 的技能库解决的是“一个模型怎么能做更多事”的问题。但当你接触多 Agent 协作时技能的重要性会进一步提高。多 Agent 架构里不同的 Agent 有各自擅长的领域比如一个负责聊天对话、一个负责搜索信息、一个负责执行业务操作。而 Agent 之间的能力共享绕不开 Skills 层。举个例子对话 Agent 在回答用户问题时发现需要查询数据库它自己不用懂数据库但它需要具备调用db_query技能的能力。这时候技能就不是某个 Agent 的私有财产而是团队共享的基础设施。每个 Agent 对外暴露自己允许使用的 Skill 列表Agent 之间通过消息通道互相请求帮忙执行技能调用。这套玩法在复杂企业场景里特别高效因为它的职责边界非常清晰Agent 管决策和表达Skills 管执行和产出。如果你想深入了解可以去看一下熟悉的开源项目在工具调用tool use层面怎么拆分的很多思路是相通的。6.2 技能市场与生态化技能积累多了之后你会发现很多技能是可以在项目间复用的这个项目写了 PDF 解析下个项目也用到那个项目做了 OCR 识别别的项目也想接。既然这样不如直接把技能做成独立的服务统一注册到技能市场里。每个技能申请独立的存储、独立的鉴权、独立的调用次数配额新项目上线时直接从市场拉一份技能清单配置好权限就能用。我之前维护过一个内部技能市场注册了几十个技能来自五个不同的业务团队。一开始大家也担心标准不统一、代码质量参差不齐。后来我们用统一的测试集做验收每个技能上线前要跑通固定的场景用例代码评审由专门的 Infra 团队负责质量和稳定性才有保障。实践证明技能市场带来的收益远大于管理成本——相同需求再次出现时可以做到两小时内完成接入不必重复造轮子。6.3 与工作流 / RPA 的结合Agent Skills 和传统 RPA 的结合是我认为潜力很大的方向。RPA 擅长处理有明确规则、重复性的桌面操作但它不懂语义不懂泛化。Agent 恰好相反能理解用户意图但一步到位的操作能力受限。把两者拼在一起Agent 负责理解任务、拆解目标把操作步骤映射到 RPA 流程模板上RPA 负责执行具体的点击和输入。这块落地有个很自然的路径把每条 RPA 流程封装成一个 Skill技能描述里写清楚这条流程做什么、前置条件是什么、输出什么。用户在对话里说“帮我导出今天的对账单”Agent 识别意图后匹配到对应的 RPA 导出流程调起来就行。这种模式既填补了 Agent 在自动化闭环上的短板也让已有的 RPA 资产重新焕发生机。7. 总结与个人经验分享Agent Skills 这个概念本质上是把大模型的能力边界从“理解”推进到“执行”。它的价值不在某个具体的 API 封装而在于你能否构建一套规范化的、可扩展的、可观测的技能管理体系。很多团队一上来就追求一大堆高端技能难度很高上线后怪模型不够聪明其实问题往往出在技能定义、描述质量、调用链路上。我个人在多次落地中形成的几个经验第一技能库的规范和骨架要先定下来再填充内容。先花两天搭好注册器、Schema 校验、编排调度、日志采集这套骨架后面每加一个新技能都是填空。如果你一开始就急着写技能后面大概率要返工。第二技能的选择机制要分阶段搭建。初期技能少直接在模型初始化时全部注入即可中后期技能超过二十个一定要上分级路由或者独立的技能检索层否则准确率和 token 开销都会失衡。第三日志和追踪时间要尽早建好。Agent 调技能的每一个环节都要有日志包括模型决策的理由、参数全貌、返回结果、耗时、重试记录。这些日志在你排查大部分线上问题时都是核心线索。最后再分享一个小技巧给模型看到的技能描述不要一股脑堆全部信息试试把“触发条件”“参数规则”“输出规范”三段式写好。你会发现模型的调用准确率提升得比自己预期快得多。这个方法我每次分享给团队同事基本上都能在当前任务下一周内看到明显改善。项目往后期走技能越来越多、Agent 之间的协作越来越复杂这份底子会让你轻松太多了。