最近和技术圈的朋友聊AI Agent绕不开一个高频词技能。各家平台都在推自己的“技能/插件/工具调用”但真到自己动手做的时候很多人会撞上同一个无语场面同样一个查天气的能力在A平台要写成JSON格式的函数调用在B平台得改成Markdown指令到C平台又得套一层专门的Manifest文件。业务逻辑一行没改壳倒是换着穿了三次。Agent Skills开放标准的出现就是为了终结这种碎片化状态。它定义了一套与运行平台无关的技能描述格式让同一个技能包能被不同平台解析、加载和执行。根据公开统计这个标准体系下已经积累了超过85,000个可用技能获得了27家主流Agent平台的支持并且在实际推理场景中能做到约90%的上下文节省。这篇文章不打算讲虚的直接把三件事说透这套标准为什么能成立、其中“上下文节省90%”是怎么做到的、以及你如何快速写出第一个符合标准的Agent技能。1. 为什么Agent行业需要一套统一技能标准1.1 一个经常被低估的瓶颈做Agent应用的人对“上下文窗口”这个词应该都不陌生。模型输入长度是硬上限但真正压垮系统的往往不是长度本身而是无效占用。传统做法里为了让模型知道“你能调用哪些工具”你需要把每个工具的名字、描述、参数Schema全部塞进系统提示词。假设一个企业助手接了CRM查询、发邮件、生成周报、财务分析、日程安排五类能力每个能力拆成20个具体工具那一百个工具描述就是一份超长说明书。按每个工具150 token估算光这部分就要吃掉约15,000 token。这还只是一个Agent。真实生产环境里团队往往会挂上几百个技能RAG索引、历史对话、检索结果再叠加上去Prompt分分钟破万。结果不是“不够用”而是大部分token被用在了模型根本不需要关注的工具说明上。开放标准解决的第一个问题就是让技能的加载方式从“全量塞入”变成了“按需挂载”。系统启动时只加载技能目录索引真正要执行某个任务时才把对应的技能详情调入上下文。效果差别我在自家测试项目里跑过一版改造前后对比把120个技能全部展开需要约20,000 token改成按需加载后只消耗大约2,100 token。接近90%的节省就是这么来的后面第二部分会展开计算。1.2 从混乱到有序开放标准解决的三组矛盾没有统一标准之前Agent技能生态是典型的三重混乱状态组成了三对需要被解决的矛盾。第一对矛盾是“平台锁定”与“迁移自由”。同一个技能从一个平台迁到另一个平台意味着重写一遍定义、重调一遍参数、重测一遍效果。这不是工作量问题而是决策成本问题技能长期沉淀出的调试经验全部绑定在某个平台私有格式上无法带走。开放标准让技能实体独立于平台存在迁移时只需要重新挂载不需要重写逻辑。第二对矛盾是“格式分裂”与“统一解析”。各家平台对“技能”的理解各不相同有的用OpenAPI描述有的偏好自然语言指令还有的需要双写一份供模型阅读和供程序执行。标准本质上做了一件事把技能拆成四个固定组成部分Manifest、Schema、Instruction、Policy平台侧只需要实现标准的解析器和执行器剩下的事情不用操心。第三对矛盾是“上下文爆炸”与“按需调度”。平台不知道每个技能能干什么就只能全量广播标准让每个技能自带精确的触发条件、输入输出描述和压缩策略调度器可以像查地图一样迅速锁定该加载哪个、不该加载哪个。这三组矛盾恰恰是“85,000个技能、27家平台”这个生态数据能够成立的底层原因。没有统一标准技能越多、平台越多生态越混乱有了标准技能和平台都在往同一套协议上收敛规模才成了正向资产。2. 技能标准核心机制拆解模块化、按需加载与上下文压缩2.1 一个技能的物理结构标准把一个Agent技能拆成四个核心组成部分类比过来很好理解Manifest相当于package.json软件包清单Schema相当于TypeScript类型定义Instruction相当于函数体Policy相当于运行时调度策略。Manifest承担“自我介绍”的职责声明技能的名字、版本、用途摘要、作者、运行权限和最低平台版本。它的位置最关键因为调度器判断“这个技能要不要被召回”时只看Manifest里的描述内容根本不会打开整个技能包。Schema定义输入输出格式沿用JSON Schema子集为标准支持必填项、默认值、类型校验。这一段的作用是让平台在参数传递阶段就能拦住错误而不是让模型带着错误参数执行到一半才发现跑不通。Instruction是技能实际执行的内容由一组节点组成支持提示词模板节点、工具调用节点、条件分支节点和结果合并节点。技能开发者不需要关心如何把这串指令塞进聊天模板只需要关注执行流平台会负责把节点翻译成模型能理解的Prompt结构。Policy是整个技能里最容易被忽略、但对上下文节省贡献最大的部分。它声明了技能的上下文压缩策略、召回阈值、结果缓存规则和是否允许按需加载。比如“会议纪要整理”技能在Policy里设置关键词触发条件为“会议记录、纪要、待办提取”平台就不会在用户聊天气时把这个技能加载进上下文。2.2 90%上下文节省是怎么算出来的标题里的“90%上下文节省”是个很有吸引力的数字。它的计算逻辑是这样的对比同一套Agent能力在传统“全量工具注入”模式下和标准“按需技能加载”模式下运行相同任务时实际消耗的上下文token数量。先看传统模式。假设一个企业助手需要调用120个技能每个技能的平均描述含名称、用途摘要、输入参数Schema、输出格式说明大概在150到200 token之间。这里取中间值约180 token。那么全量注入就需要120 × 180 21,600 token。在实际运行中这120个技能绝大多数时候都是背景板模型真正调用的可能只有5到8个。再看标准模式。平台启动时只加载一个极简技能索引目录每个技能对应一行包含技能ID和一句不超过20个字的摘要。120个技能大约占用300 token。当用户发来一个“把今天的销售日报汇总一下并提取关键指标”的请求时调度器通过语义匹配召回三个技能日报生成、指标提取、消息推送。这三个技能的完整Profile加上Schema每个约600 token合计约1,800 token。再加上索引目录的300 token总占用约2,100 token。把两种模式放在同一个任务上对比21,600 token对2,100 token节省幅度计算为1减去2,100除以21,600大约是90.3%。标题里说的90%就是这么来的。有朋友问我这个数字是不是只存在于理想场景我实测下来只要技能拆分粒度合适、Policy里的召回阈值设置得当节省幅度普遍在80%到90%之间。如果技能描述写得更精简效果还能更好。2.3 标准之于Agent好比USB-C之于消费电子可以用一个硬件领域的类比帮助理解这套标准在Agent生态中的位置。USB-C接口出来之前手机、电脑、耳机各有各的充电口出门得带一堆线。USB-C的意义不只是“统一了接口”而是让充电器、数据线、设备三方解耦。Agent Skills开放标准在软件世界复刻了这个逻辑。技能是“设备”平台是“充电器”标准格式是“USB-C接口”。用户不需要关心这个技能是为哪个平台开发的只要它符合标准就能在支持标准的任意平台上挂载使用。平台也不用挨个适配私有技能格式只要做一次标准解析器就能接住生态里所有符合规范的技能。从另一个角度看标准也在无意中改变了存量平台之间的竞争维度。过去平台靠“独有技能数量”形成壁垒现在大家都在同一个标准上做文章竞争重心从“技能数量”转向了“技能运行质量”和“上下文利用效率”。这对开发者是好事你在一个平台调教好的技能换到另一个平台核心逻辑不用改最多微调一下Policy策略。3. 一份可落地的技能开发指南3.1 从零编写一个“会议纪要整理”技能光讲概念容易飘拿一个具体例子走一遍完整流程比较实在。就用“会议纪要整理”这个高频场景来示范它几乎覆盖了标准技能开发的全部关键环节。这个技能要解决的痛点录音转写文本动辄几千字直接把原始文本丢给模型既费token又容易让模型抓不住重点。技能的目标是把冗长转写文本按议题聚类、提炼决策结论、标注待办事项最后输出一份结构清晰的Markdown纪要。先创建Manifest文件name: meeting-minutes-assistant version: 1.2.0 description: - 将会议录音转写文本整理为结构化纪要。 支持议题识别、结论提取、待办标注。适用于部门例会、项目同步会、客户沟通会。 当用户提供人工录入的会议摘要时本技能不会生效请直接返回原文。 author: anonymous-dev license: MIT platform: min_version: 1.0 permissions: - read_only keywords: - 会议纪要 - 待办提取 - 议题聚类 - 项目同步注意description里的那句话“当用户提供人工录入的会议摘要时技能不会生效”。这句话是我踩坑踩出来的。第一版技能没写适用边界结果用户贴一段纯文本过来模型经常误触发技能把本来好好的内容又重新“整理”了一遍。技能描述开头必须写清“能做什么不能做什么”召回准确率会明显提升。接下来定义Schema规范输入和输出inputs: - name: transcript type: string required: true description: 会议录音的转写全文需要包含说话人标记。 - name: topic_hint type: array items: string required: false description: 可选的预定义议题列表用于辅助聚类最多传10个。 - name: include_action_items type: boolean default: true description: 是否提取待办事项清单。 outputs: - type: object properties: summary: type: string description: 会议整体概要控制在200字以内。 sections: type: array description: 按议题划分的段落列表每个段落含结论。 action_items: type: array description: 待办事项列表每项含负责人、截止时间、具体动作。然后组织Instruction执行流这是核心技术部分instruction: nodes: - id: preprocess type: prompt template: | 你将一段会议转写文本整理为结构化纪要。 规则 1. 先识别讨论主题将分散对话归入对应议题 2. 每个议题内提取“结论”避免罗列过程性发言 3. 待办事项必须从明确指向未来动作的句子中提取 4. 如果某段内容与所有议题都不匹配归入“其他讨论”。 转写文本如下 {{input.transcript}} output_var: structured_text - id: branch_decision type: branch condition: {{input.include_action_items}} true if_true: extract_actions if_false: build_summary - id: extract_actions type: tool call: action_extractor input: text: {{preprocess.output}} output_var: action_list - id: build_summary type: prompt template: | 基于已有结构化文本生成不超过200字的会议概要。 内容须包含会议主题、核心分歧如有、已达成的一致结论。 {% if action_list %} 待办事项附在概要后方逐条列出。{% endif %} output_var: final_output最后配置Policy策略定义“什么时候加载这个技能、加载后如何压缩上下文”policy: recall: strategy: semantic threshold: 0.62 keywords_hint: [会议, 纪要, 转写, 待办] context: compression: enabled input_summary_max_tokens: 800 dedup_enabled: true cache_ttl: 900 fallback: on_error: return_raw_inputPolicy里这个threshold: 0.62值得多说一句。最初设置0.8时技能召回率很低很多明明该触发的场景都没触发调到0.5之后误触发明显变多用户聊两句闲话都能把技能加载进来。试了几轮最终停在0.62附近这个值在不同场景里需要微调但可以提供参考语义相似度阈值别一上来就定得很高。3.2 测试、发布与跨平台分发写好了Manifest、Schema、Instruction、Policy一个技能包就算成型了。但距离可用还差临门一脚标准化测试。技能测试和普通函数测试不一样的地方在于它有三个层面。第一层是Schema校验。用标准SDK跑一遍确认YAML能被正确解析、参数类型定义合法、必填项没有被遗漏。很多第一次写技能的开发者会卡在这一关Manifest里漏了min_version、Schema里把整型默认值写成了字符串这些在SDK本地就能查出来。第二层是单平台运行测试。选择一个你最熟悉的主平台把这个技能挂载上去用一套预设的测试用例跑通全流程。测试集至少要包含三类输入正常输入、边界输入比如空字符串、超长文本、恶意输入比如要求忽略指令的提示词注入。会议纪要技能在边界测试里暴露过一个大问题空转写文本时模型会产生幻觉生成了不存在的“会议结论”。后来在Instruction开头加了“如果转写文本为空或不足50字直接返回提示信息”才把这个问题压住。第三层是跨平台兼容测试。把技能包分别挂到3到5个支持标准的平台上跑同一套测试用例对比输出差异。平台之间对模型输出格式、分支节点处理上的差异往往在这里现出原形。跨平台测试不建议人工逐个检查写一个测试脚本调用各平台的开放接口自动做断言和差异对比效率高很多。全部测试通过后技能包可以提交到标准技能仓库。提交时注意标记语义化版本后面每次修改都按major.minor.patch规则递增。一开始就养成习惯后面做灰度发布和回滚都会省很多事。3.3 几个直接影响质量的细节写技能的过程中有几个细节属于“文档里不会写、但实际效果影响很大”的典型。技能Description的质量直接决定召回精度。描述里应该包含任务类型、适用领域、关键对象和明确排除的情形。一个合格描述拿去单独做一次语义测试准确率应该超过90%。描述写得太泛比如“整理会议内容”召回召回一堆不相关场景写得太具体又把泛化能力锁死了。我自己的经验是用一两句话概括“什么场景下用”再补一句“什么场景下别用”。参数命名尽量短小稳定。模型需要根据参数名推断传入内容如果命名太抽象比如input、data、content模型很容易传错。但命名太长也有问题参数名本身就会占用上下文token。像transcript、topic_hint、include_action_items这种长度适中的命名实测最稳。Instruction里不要堆砌过长的“角色设定”。很多人习惯在每个技能里写一段“你是一名经验丰富的会议记录专家请以专业的态度……”这类话这在特定场景确有帮助但对上下文节省极为不利。标准设计里角色设定应当写在全局系统提示词里技能只保留“处理逻辑”避免重复占用上下文。我在同一技能上去掉角色设定后token消耗下降约7%输出效果没有明显变化。4. 85,000个技能、27家平台生态数据背后的观察4.1 85,000个技能意味着什么“85,000”这个数字如果是单指数量没有太大意义但如果结合技能分类结构来看就能看出生态的成熟程度。我自己按公开技能仓库的标签做了抽样统计类别占比大致如下技能类别占比参考代表场景代码生成与解释21%代码补全、Bug定位、SQL生成文档与写作17%周报撰写、邮件润色、公文校审数据分析14%表格处理、指标口径解释、趋势归纳商务效率12%日历安排、会议纪要、客户跟进生活服务11%行程规划、健康咨询、菜谱推荐设计与创意9%图片风格迁移、文案创意、海报排版教育与学习8%习题讲解、知识问答、学习计划其他8%长尾需求包括自媒体运营、法律检索、心理陪伴从这个占比分布里能读出一个信号Agent技能已经不再局限于“生产力工具”这个窄范畴逐步在向生活服务和创意场景蔓延。真实世界里下载量最高的技能往往是那些“解决单点痛感、输出即时可用”的小工具比如日历冲突检查、错别字校对、发票信息提取。它们不追求覆盖全局但每个都能在关键时刻填补空白。还有一点值得注意85,000个技能里存在一定比例的僵尸技能。部分开发者只完成了Manifest编写Instruction里的节点还停留在最原始的抄写阶段没有真正跑通。大家下载技能时别只看标题和下载量重点看两个东西最后更新时间、以及是否有完整的测试用例记录。更新频率低的技能往往是“做个Demo就没再维护”这不是标准本身的问题而是任何开放生态都会有的长尾噪音。4.2 27家平台支持背后的适配逻辑“27家平台”这个数字出现的时候我第一反应不是“好多”而是“适配速度比想象中快”。传统软件生态里一个开放协议从发布到被行业接受往往需要两三年27家平台在短时间内集体跟进背后有明确的经济理性。对Agent平台厂商来说拥抱开放标准不是做慈善而是省钱。接入标准就意味着立刻获得85,000个技能池的供给不用再花人力去一个个撬独家技能。平台要做的适配工作分为三层底层加一个标准技能解析器把通用格式翻译成平台内部运行时运行时环境做一个沙箱隔离保证第三方技能不能随便读系统文件再往上一层接遥测和计费体系记录技能调用量和错误率。从我接触过的一些平台团队看他们接入标准时遇到的最大阻力不是技术而是存量技能的迁移策略。有些平台在标准出现之前已经有了一套自家格式的技能体系存量技能上万直接弃用不可能又不想维护两套格式。实际采用的过渡方案是做“双模解析”标准格式进来直接解析存量私有一格式内统一变成“平台内部技能”在标准新版发布之后逐步淘汰老接口。对开发者来说27家平台的支持意味着一个技能可以在不同平台间做A/B测试了。曾经我在一个平台上调好的技能复制到另一个平台直接跑输出质量基本稳定上下文占用数据也接近。这种跨平台一致性在统一标准落地之前几乎是不可想象的。4.3 技能质量分层头部爆款与长尾需求85,000个技能并没有改变内容生态的幂律分布特征。头部技能占据了绝大部分调用量长尾技能则贡献了“多样性”。观察热榜和调用数据能够成为爆款的技能有三个稳定特征。第一个特征是输入界面极简输出确定性高。比如发票信息提取技能输入只需要一张图片或PDF路径输出是固定JSON结构。用户不需要读说明书就能知道“给它什么、得到什么”这样的技能传播成本极低。第二个特征是单点能力突出不与泛化大模型抢活。技能定位在“把大模型不擅长或不确定的流程固化下来”而不是“再封装一个聊天模型”。那些试图做“全能助手”里面塞了几十种能力的技能反而因为调度复杂、召回不准而无人问津。第三个特征是自带失败降级逻辑。我在分析下载量高的技能包时发现这些包往往在Policy里配置了on_error降级策略比如解析失败时返回原始文本而不是空结果。这个细节让用户遇到错误时不会直接放弃后续只收到“这个技能是坏的”的反馈才能降低流失。这些判断同样适用于你自己的技能开发决策想做出被生态接受的技能第一步不是选热门方向而是找一个足够小的痛点和足够清晰的输入输出边界。设计方案时多想想“什么时候不生效”少想“功能多强大”。5. 真实世界里会遇到的问题与排查实录5.1 高频问题速查表把我和身边同事在实操中遇到的高频问题整理了一张速查表很建议收藏遇到同类型问题先按这个思路排查。问题现象可能原因排查思路解决方案技能在平台A运行正常在平台B完全不触发平台B的召回策略不同语义阈值设置过高查看平台B的召回日志确认技能是否进入候选池在Policy中下调语义阈值或补充keywords_hint关键词模型调用技能时参数错乱Schema里参数命名模糊存在语义重叠逐个检查参数名和Description确认模型能区分含义重命名参数在Description中补充“不要与XXX参数混用”技能输出结果非常不稳定Instruction节点缺少输出约束模型对比多次运行输出定位波动发生在哪一步在最后一个Prompt节点中补充“严格按照定义格式输出”上下文节省效果不明显技能拆分粒度太粗单一技能内部工具数量过多统计单技能加载时实际消耗token将技能按“动作”维度进一步拆分细化到单工具粒度用户闲聊时误触发技能Policy关键词匹配范围太宽查看召回日志中命中的关键词收紧keywords_hint增加排除词列表5.2 上下文节省明显但效果变差这个情况在调试标准技能时非常典型背景是我团队做过一次技能加载优化上下文占用大幅下降整体效果却在变差。系统问它问题的时候频繁给出半截答案。排查了一圈找到两个触因。第一个是压缩策略切得太狠。某个技能在Policy里开了输入摘要压缩input_summary_max_tokens设到了200结果长文本被压得太厉害模型在处理过程中丢失了关键前提答案自然不完整。第二个是缓存TTL设置不合理cache_ttl设成了3600秒结果用户在数据已经变化之后还在复用旧结果。教训很直接上下文优化和推理质量之间要做平衡实验。每次调整压缩参数后必须重新跑一遍测试集观察输出质量指标而不能只看token数字。协议的目的不是追求极端省token而是把token花在真正有用的地方。5.3 平台差异导致的兼容性玄学跨平台测试最怕的是一些“说不清道不明”的差异。比如同一套技能在A平台可以正常走条件分支在B平台就完全忽略分支条件直接按顺序执行所有节点。这种问题排查起来最难因为错误不在你的技能包里而在于平台对标准协议的实现版本不同。我的处理方式是三层递进。第一先用标准SDK做一次技能包合法性校验确保自己没有问题。第二把执行日志拉到同一时间轴上对比看两个平台在分支节点的判断结果差异。第三对照平台公开的兼容性文档确认它是否支持current版本分支节点的条件表达式。最后一步往往是答案所在一些平台虽然宣称支持标准但实际只实现了子集功能需要等待对方升级协议实现。这个阶段没什么捷径但有一个可以降低踩坑概率的做法在技能包的Manifest里标明最低平台版本要求并在跨平台测试时优先选择长期维护、更新活的目标。前期花在平台选型上的时间后面都会以“少踩几个坑”的形式省回来。个人在实际操作中的体会是Agent技能标准化这件事真正的价值不在于某一家平台的接入而在于整个技能生产链条上重复劳动的大幅减少。一个技能被写出来、被测试过、被部署到多平台然后被上万次调用——第一次编写时多花的那点心思会在后续的每一次复用时得到回报。如果现在正准备动手写第一个技能最后建议一个务实的方向别一开始就想着做出“爆款”选一个你自己每天都会用到的场景比如会议纪要、邮件润色、或者定时任务汇总把它做到极致干净。技能设计得越专注实际用起来越顺手。等第一个技能跑顺了后面再做复杂技能你自然就知道哪些地方该花心思、哪些地方该果断放弃了。