上周末我一直在龙蜥社区的 SkillHub 线下 Workshop 现场。说实话这两年 Agent 相关的活动我参加过不少但大多数都在讲概念、讲趋势唯独这次不太一样——整场都在跑真东西。龙蜥社区把 8 个 Skill 拉到现场逐一演示从代码审查到 GIS 空间分析从日志诊断到 AI 短剧脚本生成每个都是在 Linux 环境里直接执行、直接出结果。这篇文章不写新闻稿我从一个开发者的视角把这次 Workshop 里 SkillHub 到底解决了什么问题、8 个 Skill 是怎么设计的、以及我们自己怎么照着这套思路去开发 Skill完整拆一遍。文章适合三类人看一是正在做 Agent 应用、但被各种 Skill 格式和调用方式折腾到头疼的开发者二是想在龙蜥 Anolis OS 或内网服务器上落地 AI 自动化能力的运维和研发同学三是对 Agent 生态感兴趣、想搞清楚 Skill 到底是什么的入门者。全程说人话涉及代码的部分我会直接贴出来。1. 为什么龙蜥社区要做 SkillHub这次 Workshop 真正想解决的问题在聊 8 个 Skill 之前得先搞明白 SkillHub 存在的理由。Agent 在过去一年发展很快但一个尴尬的问题是不同平台的 Agent 能力越来越强可每个人都要在一个个会话里重复描述自己的需求。你说“帮我看看这段代码有什么问题”AGENT 是真的会看但它不知道你们团队的代码规范不知道你用的框架版本不知道你希望它重点关注安全还是性能。于是你每次都要花大段文字去解释解释清楚了才能开始干活。1.1 什么是 Agent Skill为什么豆包、Codex 这些平台都在推Skill 这个概念听起来新本质上并不复杂。它就是把一套可复用的指令、背景知识、脚本工具和示例打包成一个单元交给 Agent 来调用。你可以把它理解成给 Agent 的一本“岗位手册”一个实习生进公司你不可能每次都从头教他报销流程你给他一份标准操作流程文档他照着走就行。Skill 就是这份文档只不过它还能直接调用脚本去执行真实任务而不只是嘴上说。最近豆包、Codex、WorkBuddy 这些平台都在密集推 Skill 生态方向是一致的Agent 要真正进入生产环境靠的不是用户在对话里临时写 prompt而是把高频操作预先封装成标准化模块。Skill 的魅力在于它足够轻一个目录加一个 Markdown 文件就能描述清楚模型读得懂人也读得懂。但同时问题也来了——每个平台的 Skill 格式不统一、接口有差异、依赖环境各写各的你在 A 平台写好的 Skill搬到 B 平台经常要重写。1.2 SkillHub 在整套技术架构里扮演的角色龙蜥社区做 SkillHub本质上想解决的是“Agent 技能碎片化”这个痛点。用软件包管理的类比最好懂Linux 生态没有 apt、yum 之前装个软件要自己找源码、手动编译、处理依赖可复制性极差有了包管理器之后一条命令解决。SkillHub 想做的是 Agent 世界的“软件源”把散落在各处的 Agent Skill 统一收编定一套相对标准的目录结构和描述规范让开发者可以发布、检索、复用别人写好的 Skill并且能够方便地接入自己的 Agent 工作流。龙蜥社区做这件事有个天然优势它耕耘的是操作系统层跟服务器的部署环境、容器生态、运维体系离得最近。SkillHub 上的 Skill 不只是聊天玩具式的文本技能更多是能真正操作 Linux 环境、调用系统命令、处理 GIS 数据、分析容器日志这类“能干活”的技能。这次 Workshop 现场演示的 8 个 Skill绝大多数都跑在龙蜥 Anolis OS 的容器环境里Agent 收到任务后调用 Skill 里的脚本在系统里执行真实操作最后把结构化结果返回给用户。这种深度对接操作系统环境的能力才是 SkillHub 区别于一般技能市场的地方。2. 现场亮相的 8 大 Skill先看全貌再逐个拆解这次 Workshop 的节奏很快8 个 Skill 每个大概十几分钟都是现场直接演示。我在下面把看到的 8 个 Skill 整理成一张总览表后面再挑几个有代表性的详细讲。Skill 名称所属类别解决的核心问题现场演示要点代码 Review Skill开发效能自动检查代码规范、安全风险输出结构化审查意见对一个 Python MR 做静态检查集成 pylint 与安全检查日志诊断 Skill系统运维读取容器日志、系统日志快速定位故障时间线分析一组异常日志输出崩溃根因与关键字聚类GIS 空间分析 Skill专业技能处理 GeoJSON、空间缓冲、叠加分析直接出图对一组地理数据做缓冲区分析用脚本生成可视化结果短剧脚本生成 Skill内容创作按设定生成分镜、台词、机位与提示词方案输入一个主题生成包含镜头描述的短剧脚本初稿语言学习陪练 Skill教育学习定制学习计划、生成场景对话、互动纠错模拟英语点餐场景实时给出表达建议HTML 页面优化 Skill前端性能解读 Lighthouse 报告定位渲染瓶颈并给出修改建议对页面性能报告分析输出 Top 问题清单运维巡检 SkillSRE 运维批量检查节点状态、服务健康度产出巡检报告在容器集群内执行巡检脚本汇总多个节点的状态文本去 AI 味改写 Skill内容创作把大模型生成腔调改写成更自然的口语表达把一段“模板感很强”的文字改写为对话式版本2.1 开发与运维类 Skill 的共性设计命令要真实可执行代码 Review、日志诊断、运维巡检这几个 Skill 有一个共同点它们不是靠“说”完成任务的而是要在真实环境里执行命令、读取文件、运行分析工具。这类 Skill 的结构通常包含脚本目录、依赖声明、以及清晰的输入输出定义。以代码 Review Skill 为例Agent 拿到一个 MR 分支后会调用 Skill 里的脚本先拉取代码再依次跑格式检查、静态分析、依赖安全扫描最后把结果聚合成一份 JSON 格式的报告。这类 Skill 在设计上最容易踩的坑是环境依赖。现场演示的代码 Review Skill 放在容器里执行容器内预装了 Python 工具链和常用的 lint 工具所以现场没有出现“命令找不到”的尴尬。这给我们一个重要提示凡是需要调用外部命令的 Skill都必须在 SKILL.md 里写清楚依赖最好直接提供容器镜像或者在安装脚本里声明依赖。后续我在第三部分会给出完整的依赖声明写法。2.2 内容与专业场景类 Skill 的落地细节轻前端重方法短剧脚本生成、语言学习陪练、文本去 AI 味这一类 Skill 看起来“轻”不需要执行系统命令但设计难度并不低。难点在于这类 Skill 的效果完全取决于你给 Agent 的“方法论”是否足够具体。比如短剧脚本生成 Skill它内部定义的不仅是“生成一个短剧脚本”而是一套分镜结构开场冲突、人物动机、镜头语言、对白节奏、结尾反转每个环节都有明确的输出格式要求。Agent 按照这套框架去思考产出的质量才稳定。现场演示的 GIS 空间分析 Skill 则属于另一类“专业技能型”它同时具备方法论和工具属性。Agent 收到用户上传的 GeoJSON 文件后会调用 Skill 里的 Python 脚本完成空间计算再通过 Matplotlib 生成分析图。这让我看到 Skill 的一个明确趋势传统的 Agent 只能处理文本而 Skill 可以把任意 CLI 工具、Python 库、外部服务封装进来让 Agent 的能力边界从“聊天”扩展到“干活”。3. 从 Workshop 现场还原一个 Skill 的完整开发过程看演示只是开胃菜真正有价值的是掌握开发方法。这次 Workshop 现场有动手环节我完整跟了下来这里以 GIS 空间分析 Skill 为例带你走一遍从零创建到被 Agent 调用的完整流程。这套流程同样适用于代码审查、日志分析等任意工具型 Skill。3.1 Skill 的标准目录结构与 SKILL.md 编写规范一个好的 Skill 应该是一个自包含的目录里面至少有描述文件、脚本目录和示例数据。我建议按下面的结构组织skills/ └── gis-spatial-analysis/ ├── SKILL.md # 技能描述文件Agent 可读 ├── README.md # 给人看的说明文档 ├── scripts/ │ ├── analyze.py # 核心分析脚本 │ └── visualize.py # 可视化脚本 ├── assets/ │ └── sample.geojson # 示例数据用于自测 └── tests/ └── test_analyze.py # 单元测试SKILL.md 是整个 Skill 的灵魂。它采用的是 Markdown 加 front matter 的格式顶部是一段 YAML 元信息下面是自然语言描述。一个合格的 SKILL.md 长这样--- name: gis-spatial-analysis description: 用于处理地理空间数据。当用户要求做缓冲区分析、面积计算、 叠加分析或者上传 GeoJSON 文件希望得到可视化结果时 使用本技能。 version: 1.0.0 license: Apache-2.0 runtime: python3 dependencies: - shapely - geopandas - matplotlib --- # GIS 空间分析 ## 功能 本技能提供基础的地理空间分析能力支持 - 读取 GeoJSON 格式的地理数据 - 计算缓冲区Buffer - 叠加分析 - 输出 PNG 格式的可视化图片 ## 使用流程 1. 获取用户提供的 GeoJSON 文件路径 2. 运行 python3 scripts/analyze.py input.geojson 执行分析 3. 运行 python3 scripts/visualize.py result.json 生成图片 4. 把输出图片和关键数据汇总给用户写 SKILL.md 时很容易犯一个错误把 description 写成“这是一个做 GIS 分析的技能”。这句描述对 Agent 来说几乎没有筛选价值。正确的写法是写明“当用户表达什么需求时应该触发这个技能”最好带一两个典型句式比如“帮我算一下这个区域周边 500 米的覆盖范围”就应该命中 GIS 技能。这一步直接决定了 Agent 能不能在正确的时机调用到正确的 Skill。3.2 在龙蜥 Anolis OS 上把 Skill 跑起来从注册到调用目录结构和描述文件都有了接下来就是让 Skill 真正被 Agent 使用。整个链路可以分为五步创建 Skill 目录编写 SKILL.md 和脚本文件。在本机验证脚本可以独立运行不依赖 Agent。把 Skill 目录放入 Agent 的 skills 配置路径。修改 Agent 的运行时配置声明 Skill 的工作目录和沙箱环境。发起一次真实的任务请求验证调用链路。现场演示时Agent 运行在龙蜥 Anolis OS 的容器中Skill 目录通过挂载方式放进容器。这样做的好处是隔离性即使 Skill 里的脚本写得有瑕疵也不会污染宿主机环境。以 GIS 分析脚本为例核心代码是这样的import sys import json from shapely.geometry import shape from shapely.ops import unary_union def main(): input_file sys.argv[1] buffer_distance float(sys.argv[2]) if len(sys.argv) 2 else 500 with open(input_file, r) as f: geojson json.load(f) features [] for feature in geojson[features]: geometry shape(feature[geometry]) buffered geometry.buffer(buffer_distance) features.append({ id: feature.get(properties, {}).get(id, unknown), buffer_area: buffered.area, original_area: geometry.area, geometry: buffered.__geo_interface__ }) result { type: FeatureCollection, features: [ { type: Feature, properties: { id: f[id], buffer_area: f[buffer_area], original_area: f[original_area] }, geometry: f[geometry] } for f in features ] } print(json.dumps(result, ensure_asciiFalse)) if __name__ __main__: main()这段代码做的事情很简单读入 GeoJSON计算每个要素的缓冲区面积输出一个新的 GeoJSON。它不追求功能有多么复杂而是展示一个原则——脚本要面向命令行设计输入路径、输出 stdout这样 Agent 就可以通过简单的命令调用拿到任务结果。脚本输出统一使用 JSONAgent 拿到 JSON 后再组织语言回复用户这是当前比较稳的协作模式把计算交给脚本把表达交给模型。依赖安装方面龙蜥 Anolis OS 可以使用 dnf 安装系统级依赖Python 库则推荐建虚拟环境或用容器镜像锁定版本。我建议你在 SKILL.md 里直接写清楚依赖列表同时提供一个 requirements.txt 或容器镜像说明方便别人拿到你的 Skill 后能够快速复现环境。4. 现场踩坑实录Skill 开发的常见问题与排查技巧再成熟的演示现场也会遇到状况。这次 Workshop 动手环节我也观察到不少参会者踩到同样的坑。这里整理成一份排查速查表都是实操中容易遇到的问题。问题现象根本原因排查方法解决方案Agent 没有触发期望的 SkillSKILL.md 的 description 写得太宽泛或太狭窄检查描述中是否包含典型触发句式改成“当用户需要 X 时使用本技能”的明确句式Skill 调用了但输出格式混乱缺少示例输出查看 SKILL.md 是否包含 few-shot 示例在 SKILL.md 中增加一个完整输入输出示例脚本在本机能跑Agent 环境里报错依赖未声明或执行路径不对检查脚本是否使用相对路径、依赖是否安装使用绝对路径在 dependencies 中完整声明依赖调用外部命令长期无响应命令阻塞或超时查看是否有交互式命令等待输入为命令添加 timeout长任务转后台并查询状态Skill 一次性返回内容过多导致上下文超限把完整手册塞进了 prompt检查 SKILL.md 是否过长或被整体加载只保留精简信息详细说明放入单独文件按需读取4.1 大家最容易忽略的可复现性比功能本身更重要我发现 Workshop 现场翻车最多的场景不是脚本逻辑写错了而是环境不一致。有人把自己的 Skill 从开发机直接拷到容器里结果发现少了一个依赖有人写死了本机路径换一台机器就找不到文件。这些都是可复现性没做到位的表现。好的做法是每个 Skill 都自带一个 install.sh 或者 requirements.txt并且把测试数据打进 assets 目录。这样任何人在任何机器上拿到这个 Skill都能先跑通一个最小例子。一个 Skill 如果别人拿过来跑不通它就只能躺在你本地谈不上生态。4.2 让 Skill 更通用、更稳定的两个实战原则根据我自己的使用经验Skill 设计守住两条原则能省掉很多麻烦。第一一条 Skill 只做一件事。这是我反复强调的一个原则。很多人写 Skill 喜欢“打包全家桶”比如既做日志分析又做性能巡检结果 SKILL.md 描述冗长Agent 经常犯了难用户聊到日志时它触发这个技能聊到性能时它也触发行为不稳定。把技能拆细一条只负责一个明确场景命中率和稳定性都会明显提升。第二参数少而且明确。Skill 对外暴露的参数越少Agent 就越不容易用错。有些 Skill 设计了十来个参数Agent 在调用时根本不知道哪些必填哪些可选经常传错。GIS 分析这个 Skill 就做得比较克制只暴露两个入参输入文件路径、缓冲距离可省略剩余逻辑完全封装在脚本内部。另外我特别想提一个容易被忽略的小点给 SKILL.md 写提供人看的 README。虽然模型只读 SKILL.md但社区里使用 Skill 的是人。README 说明清楚安装方法、参数含义、输出格式别人用起来才顺手。这就像一个开源项目光有代码没有文档是火不起来的。5. SkillHub Workshop 背后对开发者和社区的三个信号看完 8 个 Skill 的演示我的整体感受是Agent Skill 已经从“炫技 Demo”阶段走到了“能不能拿来就用、能不能改一改就变成自己的”阶段。这次 Workshop 释放了三个比较明显的信号。5.1 内网与私有化环境正在成为 Skill 落地的主战场这次 Workshop 现场不只一个参会者在问同一个问题“这些 Skill 能不能部署到内网”这其实代表了相当一部分企业的真实需求数据不出域、模型私有化、工具链封闭管理。SkillHub 这样的技能仓库天然适合内网部署——因为 Skill 本质上是本地脚本加描述文件不依赖云端服务。如果你想在内网离线部署一套 Skill 环境可以参考这个思路在外网准备好的机器上把需要的 Skill 目录完整打包。把 Python 依赖通过 pip download 下载为离线安装包一并拷入内网。在离线环境里构建一个包含所有依赖的容器镜像。把镜像导入内网容器运行时挂载 Skill 目录。Agent 的配置文件里写上本地的 Skill 绝对路径不依赖外网仓库。这套流程里最关键的是第二步和第三步一定要把依赖锁进镜像。内网环境往往不能随意访问外网源临时下载依赖很容易卡死。把依赖在源头准备好后面部署就只是导入镜像和挂载目录的事。5.2 社区生态未来的方向标准化和跨平台兼容龙蜥社区这次推 SkillHub我看不只是搭一个技能下载站更是在推动 Agent Skill 的标准化。Linux 生态之所以能走到今天标准化功不可没——apt 和 yum 虽然不同但软件包的基本格式、依赖声明方式都有共识。Skill 生态也一样如果每个平台都闭门造车开发者就要为一个技能写多个版本。SkillHub 从社区层面做规范对开源生态是有长远价值的。对个人开发者我的建议是别等标准确定才开始先把手头重复劳动最多的那件事做成一个 Skill。我在实际使用中的体会是哪怕一个 Skill 只是帮你把某个日志文件的排查时间从 20 分钟缩短到 3 分钟它都值得固化下来。技能库不是一次性建成的而是从你自己的工作流里一个个沉淀出来的。最后再分享一个小经验在 SKILL.md 的 description 里多用“当用户说 X 时使用本技能”这种句式比用“这个技能用于……”的效果好得多。前者是在教 Agent 什么时候触发后者只是在做自我介绍。这次 Workshop 上演示效果好、命中准的 Skill几乎都写了这种触发式描述。你写下一个 Skill 的时候可以立刻试试这个写法。