企业官网建设流程全解析

1. 项目概述：一场聚焦“技能即服务”的技术实践现场

“8 大 Skill 实战集中亮相，龙蜥社区 SkillHub 首场线下 Workshop 圆满举办”——这个标题不是宣传稿的套话，而是真实发生的技术现场切片。我作为现场参与并深度协作者之一，全程跟进了从筹备到复盘的全部环节。所谓“Skill”，在这里不是泛指程序员的编程能力，而是特指在 Agentic OS 架构下可被调度、可被编排、具备明确输入/输出契约、能独立完成原子任务的可执行功能单元；而 SkillHub，则是龙蜥社区为这类 Skill 提供注册、发现、验证、分发与运行时管理的一整套开源基础设施。它不依赖任何中心化云服务，所有元数据、执行环境、权限策略均可本地化部署和审计。这直接回应了当前开发者最头疼的两个现实问题：一是大量重复性运维脚本、安全检测逻辑、CI/CD 工具链胶水代码散落在各团队私有仓库里，无法复用、难以验证、更新不同步；二是当企业开始尝试构建自己的 Agent 应用时，发现“缺技能”比“缺模型”更致命——模型可以调 API，但一个能真正 ssh 登录跳板机后自动执行合规检查并生成 PDF 报告的 Skill，必须自己写、自己测、自己维护。

这场 Workshop 的核心价值，正在于它把 SkillHub 从文档和 GitHub README 里拽了出来，放到真实终端前、白板上、协作编辑器中，让参与者亲手把一段 Python 脚本封装成带签名、带 Schema、带测试用例、能被 SkillHub CLI 发现并一键安装的“标准件”。关键词里的Agentic OS不是概念炒作，它指代的是以 Skill 为基本构件、以 Runtime 为执行底座、以 Hub 为治理中枢的操作系统级抽象；而AgentSecCore则是本次亮相的 8 大 Skill 中最具代表性的安全类技能集合，包含漏洞扫描结果归一化解析、CVE 基线自动比对、敏感配置项实时巡检等 3 个高复用率模块。至于“workshop下载”这个热搜词，背后反映的是大量未到场开发者的真实诉求：他们不要 PPT，不要录播视频，就要能立刻 clone 下来、改两行参数就能跑通的最小可行环境（MVE）包。我们最终交付的，正是这样一个压缩包：含 Docker Compose 编排文件、预置 8 个 Skill 的源码树、本地 Registry 镜像、以及一份严格按操作顺序编号的step-by-step.md——连chmod +x这种细节都写进去了，因为实测发现，超过 37% 的首次使用者卡在了权限问题上。

2. SkillHub 架构设计与落地逻辑拆解

2.1 为什么不是直接用 Kubernetes 或 Function as a Service？

这是 Workshop 开场就被问最多的问题。答案很实在：K8s 是调度器，不是技能市场；FaaS 是执行沙箱，不是能力治理平台。SkillHub 的设计起点，是解决“技能生命周期管理”这个垂直断点。我们拆解一个典型 Skill 的全生命周期：开发 → 签名 → 注册 → 发现 → 权限校验 → 下载 → 本地验证 → 执行 → 输出解析 → 结果上报。K8s 只覆盖了“执行”这一环，且其 RBAC 模型面向 Pod 和 Namespace，无法表达“允许某用户调用 skill://sec/cve-baseline-checker 但禁止调用 skill://dev/deploy-to-prod”这种细粒度语义。而 FaaS 平台（如 OpenFaaS、Knative）虽支持函数注册，但其触发机制基于 HTTP 事件或消息队列，缺乏对 Skill 输入 Schema 的强制声明、对输出结构的契约约束，更不提供跨 Skill 的依赖解析能力（比如某个运维 Skill 内部需要调用另一个日志查询 Skill，这种依赖关系必须可声明、可验证、可隔离）。

SkillHub 的核心设计选择，是将“技能”建模为一种新型软件包（Software Package），而非服务（Service）或函数（Function）。它借鉴了操作系统内核模块（kernel module）的加载机制和 Linux 包管理器（如 rpm/dpkg）的签名验证流程，但剥离了对特定内核版本的强绑定。具体来说，每个 Skill 必须包含三个强制组件：

• skill.yaml：声明式元数据文件，定义名称、版本、作者、描述、输入 Schema（JSON Schema 格式）、输出 Schema、依赖 Skill 列表、所需系统能力（如network: true,privileged: false）、执行入口（如entrypoint: python3 main.py）；
• main.py（或其他语言主文件）：实际执行逻辑，必须遵循输入/输出 Schema，且不能硬编码外部服务地址（所有配置需通过skill.yaml中声明的env字段注入）；
• test/目录：至少包含一个test_input.json和test_output.json，用于本地验证和 Hub 端自动化测试。

提示：SkillHub CLI 在skill install时会自动执行test/下的验证流程，只有全部测试通过才会写入本地 registry 数据库。这一步不是可选项，而是强制门禁——我们在线下 Workshop 中亲眼看到，有 4 组参与者因test_output.json中时间戳字段未设为"type": "string"而导致安装失败，当场修正后才通过。这恰恰证明了契约先行的价值。

2.2 SkillHub 与 Agentic OS 的分层关系：不是替代，而是补位

Agentic OS 是一个更高阶的抽象概念，它描述的是一个由多个协同 Agent 构成的自治系统，每个 Agent 具备规划（Planning）、记忆（Memory）、工具调用（Tool Use）三大能力。SkillHub 并不实现这些能力，而是为“工具调用”这一能力提供底层支撑。你可以把 Agentic OS 想象成一台智能汽车的操作系统，它负责路径规划、环境感知、决策控制；而 SkillHub 就是这辆车的“标准化工具箱接口”，它确保无论你装的是千斤顶（运维类 Skill）、灭火器（安全类 Skill）还是胎压计（监控类 Skill），都能用同一套卡扣固定、同一套协议通信、同一套权限锁止。

这种分层带来的实际好处，在 Workshop 的实战环节体现得淋漓尽致。当一组学员试图构建一个“自动响应高危漏洞通报”的 Agent 时，他们不需要从零开发扫描器、解析器、通知器，而是直接在 SkillHub 中搜索：

skillhub search --tag security --keyword cve # 返回：sec/cve-scan-runner@1.2.0, sec/cve-report-parser@0.9.3, comms/slack-notifier@2.1.1

然后三行命令完成集成：

skillhub install sec/cve-scan-runner@1.2.0 skillhub install sec/cve-report-parser@0.9.3 skillhub install comms/slack-notifier@2.1.1

接着在 Agent 的工具调用配置中，只需声明：

tools: - name: "cve_scan" skill: "sec/cve-scan-runner@1.2.0" input_schema_ref: "#/components/schemas/ScanRequest" - name: "cve_parse" skill: "sec/cve-report-parser@0.9.3" input_schema_ref: "#/components/schemas/ScanResult"

Agentic OS Runtime 会自动解析依赖、校验签名、加载执行环境。整个过程，开发者完全不用关心 Python 版本兼容性、是否需要安装nmap二进制、Slack token 如何安全注入——这些都由 SkillHub 的运行时契约和本地策略引擎处理。这才是“技能即服务”（Skill-as-a-Service）的实质：把能力封装成乐高积木，把组合逻辑交给更高层的智能体。

2.3 AgentSecCore：安全技能集的设计哲学与工程取舍

本次亮相的 8 大 Skill 中，AgentSecCore 占据 3 席，分别是sec/cve-baseline-checker、sec/config-scanner和sec/log-analyzer。它们不是简单的脚本打包，而是体现了安全领域特有的工程约束。以sec/cve-baseline-checker为例，其核心任务是：给定一个软件包列表（如openssl-1.1.1f-15.el8_3.x86_64），返回该环境是否符合某份 CVE 基线（如 CIS Red Hat Enterprise Linux 8 Benchmark v3.0.0）。表面看是个查表操作，但实际难点在于：

• 基线数据动态性：CIS 基线每季度更新，NVD 数据库每小时刷新，不能把 JSON 文件硬编码进 Skill；
• 环境异构性：同一份基线，在 RHEL8、CentOS Stream 9、Alibaba Cloud Linux 3 上的检查项可能不同；
• 权限最小化：Skill 运行时不应拥有 root 权限，但某些检查（如/etc/shadow权限）必须读取敏感文件。

解决方案是采用“策略即代码 + 数据即服务”双轨制。Skill 本身只包含策略引擎（用 Rego 语言编写，嵌入 OPA），而基线数据、OS 映射规则、CVE 映射表则作为独立的、可热更新的data bundle，通过 SkillHub 的bundle update命令拉取。skill.yaml中声明：

data_bundles: - name: "cis-benchmark" version: "3.0.0" url: "https://hub.openanolis.org/bundles/cis-rhel8-v3.0.0.tar.gz" checksum: "sha256:abc123..." - name: "os-mapping" version: "1.0.0" url: "https://hub.openanolis.org/bundles/os-mapping-v1.0.0.json"

执行时，SkillHub Runtime 会先下载并校验这些 bundle，再将其挂载为只读 volume 供 OPA 引擎读取。这样，策略逻辑（Skill 代码）半年不更新，只要定期bundle update，就能持续生效。我们在 Workshop 中让学员对比了“硬编码基线”和“bundle 方式”的维护成本：前者每次基线更新需修改 12 个文件、重新测试 8 个场景；后者只需一条命令，平均耗时 17 秒。这就是设计取舍的价值——用一点额外的运行时开销（bundle 下载），换取了长期的可维护性。

3. 8 大 Skill 实战详解与关键实现步骤

3.1 运维类 Skill：ops/backup-manager与ops/rollback-executor

这两个 Skill 构成了一对原子操作闭环。ops/backup-manager负责在变更前创建系统快照，ops/rollback-executor则在变更失败时回滚到指定快照。它们的精妙之处在于对“快照一致性”的处理。

传统备份脚本常犯的错误是：分别备份/etc、/var/log、数据库 dump，但三者时间点不一致，导致恢复后配置与日志对不上。backup-manager的解决方案是引入“协调者模式”：它不直接执行备份，而是调用已注册的子 Skill（如storage/lvm-snapshot、db/pg-dump、fs/tar-archive），并通过 SkillHub 的skill call同步机制，确保所有子 Skill 在同一秒内启动。其skill.yaml关键片段如下：

dependencies: - "storage/lvm-snapshot@1.0.0" - "db/pg-dump@0.8.2" - "fs/tar-archive@1.1.0" entrypoint: "python3 coordinator.py" env: - name: "SNAPSHOT_NAME" description: "快照唯一标识，格式：backup-{timestamp}-{random}" required: true - name: "TARGET_VOLUME" description: "LVM 逻辑卷路径，如 /dev/vg01/lv_root" required: true

coordinator.py的核心逻辑是：先调用lvm-snapshot创建只读快照，记录其设备路径；再并发调用pg-dump和tar-archive，并将快照路径作为参数传入；最后汇总所有子 Skill 的输出，生成统一的backup-manifest.json，包含各组件的校验和、时间戳、快照路径。这个 manifest 就是rollback-executor的唯一输入。

在 Workshop 实操中，我们让学员故意制造一个故障场景：在pg-dump执行中途 kill 掉进程。结果发现rollback-executor仍能成功回滚，因为它只依赖 manifest 中记录的 LVM 快照路径，而lvm-snapshot的创建是原子操作，不受后续失败影响。这个设计保证了“备份”动作的幂等性和“回滚”动作的确定性，是运维自动化可靠性的基石。

3.2 安全类 Skill：sec/config-scanner的深度检测逻辑

sec/config-scanner的目标是扫描/etc/ssh/sshd_config、/etc/sysctl.conf等关键配置文件，识别不符合安全基线的项。它不像简单 grep 工具，而是实现了三层检测：

• 语法层：使用 ANTLR4 为每种配置文件定义专用 grammar，将文本解析为 AST，避免正则表达式误匹配（如PermitRootLogin yes和#PermitRootLogin no被正确区分）；
• 语义层：对 AST 节点进行规则评估，例如 “PermitRootLogin必须为no或without-password，且不能被注释”；
• 上下文层：结合系统状态，例如 “若启用了 SELinux，则sysctl net.ipv4.ip_forward的检查规则与 disabled SELinux 时不同”。

其main.py中最关键的函数是evaluate_rule(node, context)，其中context是一个字典，包含：

{ "os_release": "Alibaba Cloud Linux 3 (Soaring Falcon)", "selinux_status": "enforcing", "kernel_version": "5.10.134-15.al8.x86_64", "installed_packages": ["openssh-server-8.7p1-26.al8"] }

这个 context 由 SkillHub Runtime 在执行前自动注入，来源是system-info这个内置 Skill 的输出。这意味着config-scanner无需自己调用uname -r或getenforce，降低了耦合度，也提升了可测试性——单元测试时，只需 mock 一个 context 字典即可。

我们在 Workshop 中设置了一个挑战题：让学员修改规则，使config-scanner对sshd_config中MaxAuthTries的检查，从“必须 ≤ 3”变为“若PasswordAuthentication yes，则必须 ≤ 2”。这要求他们理解 AST 节点间的依赖关系，并在evaluate_rule中添加条件分支。87% 的学员在 25 分钟内完成，证明了这种分层检测模型的学习曲线是平缓且可预测的。

3.3 开发类 Skill：dev/test-runner与dev/code-linter

这对 Skill 解决了 CI/CD 流水线中最易被忽视的“本地验证”环节。dev/test-runner不是简单执行pytest，而是做了三件事：

1. 环境隔离：使用podman unshare创建用户命名空间，确保测试在干净的、与宿主机隔离的环境中运行；
2. 依赖映射：根据pyproject.toml中的[build-system]和[project.dependencies]，自动生成pip install命令，并缓存 wheel 包到 SkillHub 的本地 artifact store；
3. 结果归一化：无论底层是 pytest、tox 还是 custom script，最终输出统一为 JUnit XML 格式，供 SkillHub 的报告聚合器消费。

dev/code-linter则采用了“插件链”架构。其skill.yaml允许声明多个 linter 插件：

linter_plugins: - name: "pylint" version: "2.17.5" config_file: ".pylintrc" - name: "bandit" version: "1.7.5" config_file: "bandit.yml"

main.py的核心是一个LinterChain类，它按顺序调用每个插件，将前一个插件的输出（AST 或 AST diff）作为下一个插件的输入。例如，pylint先做静态分析，输出潜在 bug；bandit再接收这些 AST 节点，专门检查其中的密码硬编码、反序列化风险。这种链式设计，使得单个 Skill 可以组合多种工具的能力，而无需每个工具都单独打包成 Skill。

实操中，我们让学员为一个存在eval()调用的 Python 文件运行code-linter，它同时触发了pylint的W0123和bandit的B307，并在最终报告中将两个警告关联起来，标注为“高危：动态代码执行风险”。这种跨工具的关联分析，是传统独立 linter 无法做到的。

3.4 监控类 Skill：mon/metrics-collector的轻量级指标采集

mon/metrics-collector的设计目标是“比 Prometheus Exporter 更轻，比 shell 脚本更稳”。它不暴露 HTTP 端口，而是将采集到的指标直接写入本地 ring buffer（内存映射文件），再由 SkillHub 的metrics-exporter（另一个 Skill）定时读取并转发。这种架构规避了 Exporter 常见的两个痛点：一是 HTTP 拉取超时导致指标丢失，二是 Exporter 自身成为监控盲点（谁来监控 Exporter？）。

其采集逻辑采用“声明式指标定义”：

metrics: - name: "system_load_1m" type: "gauge" help: "1-minute load average" source: "proc:/proc/loadavg:field=1" - name: "disk_usage_percent" type: "gauge" help: "Root partition usage percent" source: "df:/dev/mapper/vg01-lv_root:field=5"

source字段定义了数据来源和提取方式。proc:/proc/loadavg:field=1表示读取/proc/loadavg的第一列；df:/dev/mapper/vg01-lv_root:field=5表示执行df命令，过滤出/dev/mapper/vg01-lv_root行，取第 5 列（Use%）。main.py中有一个通用的SourceReader类，它根据source前缀（proc、df、sysctl、jstat）选择不同的读取器，所有读取器都实现统一的read()接口。这种设计让新增一个指标源（比如zfs）只需增加一个ZFSReader类，无需修改主逻辑。

在 Workshop 的压力测试环节，我们让 20 个metrics-collector实例并发运行，采集 50 个指标，持续 1 小时。结果表明，ring buffer 的写入延迟稳定在 0.3ms 以内，无丢数，而同等条件下，一个暴露 9100 端口的 Node Exporter 在网络抖动时出现了 12% 的拉取失败率。这验证了“去 HTTP 化”设计在边缘和资源受限场景下的优势。

4. Workshop 实操全流程与核心环节实现

4.1 环境准备：5 分钟搭建本地 SkillHub 运行时

所有 Workshop 参与者拿到的是一份workshop-setup.sh脚本，它执行以下步骤（我们要求学员逐行阅读并理解）：

# 1. 创建专用用户，避免污染宿主机 sudo useradd -m -s /bin/bash skillhub-user sudo su - skillhub-user # 2. 安装 SkillHub CLI（静态链接二进制，无依赖） curl -L https://hub.openanolis.org/cli/skillhub-linux-amd64 -o ~/bin/skillhub chmod +x ~/bin/skillhub export PATH="$HOME/bin:$PATH" # 3. 初始化本地 Hub（SQLite 数据库 + 本地 Registry） skillhub init --local-registry ~/registry --db-path ~/.skillhub.db # 4. 启动本地 Registry（Docker 容器，仅监听 localhost） docker run -d --name skillhub-registry \ -v ~/registry:/var/lib/registry \ -p 127.0.0.1:5000:5000 \ registry:2 # 5. 配置 CLI 使用本地 Registry skillhub config set registry http://localhost:5000

关键点在于--local-registry和--db-path参数。SkillHub 默认连接云端 Hub（https://hub.openanolis.org），但 Workshop 要求完全离线、可审计。init命令会生成一个~/.skillhub/config.yaml，其中registry字段被设为http://localhost:5000，database字段指向本地 SQLite 文件。这确保了所有install、push、search操作都只与本地服务交互，不产生任何外网请求。

注意：docker run命令中-p 127.0.0.1:5000:5000是强制要求。如果写成-p 5000:5000，Registry 会监听所有接口，这在 Workshop 的共享网络环境下是严重安全隐患。我们在开场就强调：“你的本地 Registry 不是公共镜像站，它只为你自己的 Skill 服务。”

4.2 Skill 开发：从脚本到标准 Skill 的 7 步封装

以一个简单的hello-world脚本为例，演示如何将其升级为可被 SkillHub 管理的正式 Skill：

Step 1：创建目录结构

mkdir -p hello-world/{main.py,test} cd hello-world

Step 2：编写主逻辑（main.py）

#!/usr/bin/env python3 import os import json import sys # 从环境变量读取输入，遵循契约 name = os.getenv("INPUT_NAME", "World") count = int(os.getenv("INPUT_COUNT", "1")) # 生成输出，严格遵循 output_schema output = { "greetings": [f"Hello, {name}!"] * count, "timestamp": int(time.time()) } print(json.dumps(output))

Step 3：编写测试用例（test/test_input.json）

{"INPUT_NAME": "Alice", "INPUT_COUNT": "3"}

Step 4：编写期望输出（test/test_output.json）

{ "greetings": ["Hello, Alice!", "Hello, Alice!", "Hello, Alice!"], "timestamp": 1717027200 }

提示：timestamp字段的值是占位符，SkillHub CLI 在运行测试时会自动忽略该字段的值比对，只校验类型和结构。

Step 5：编写元数据（skill.yaml）

name: "demo/hello-world" version: "1.0.0" description: "A simple greeting generator" author: "Workshop Participant" input_schema: type: "object" properties: INPUT_NAME: type: "string" default: "World" INPUT_COUNT: type: "string" default: "1" output_schema: type: "object" properties: greetings: type: "array" items: type: "string" timestamp: type: "integer" entrypoint: "python3 main.py" env: - name: "INPUT_NAME" description: "Name to greet" required: false - name: "INPUT_COUNT" description: "Number of greetings" required: false

Step 6：本地验证

skillhub validate . # 输出：✅ Validation passed. All tests passed.

Step 7：打包并推送到本地 Registry

skillhub package . -o hello-world-1.0.0.skb skillhub push hello-world-1.0.0.skb # 输出：✅ Pushed demo/hello-world@1.0.0 to http://localhost:5000

这 7 步看似繁琐，但每一步都对应一个明确的工程目的：validate保证契约正确，package生成不可变包，push完成一次原子发布。我们在 Workshop 中让学员用计时器记录，平均完成时间为 6 分 23 秒，熟练后可压缩至 3 分钟内。关键是理解“为什么需要这一步”，而不是机械执行。

4.3 技能调用：在 Agentic OS Runtime 中集成 Skill

Workshop 的高潮环节，是让学员用agentic-os-cli启动一个最小 Agent，并配置它调用刚发布的demo/hello-world。步骤如下：

Step 1：安装 Agentic OS Runtime

curl -L https://hub.openanolis.org/runtime/agentic-os-linux-amd64 -o ~/bin/agentic-os chmod +x ~/bin/agentic-os

Step 2：创建 Agent 配置文件agent-config.yaml

name: "greeting-agent" description: "An agent that greets users" skills: - name: "greet" skill: "demo/hello-world@1.0.0" input: INPUT_NAME: "{{user_input.name}}" INPUT_COUNT: "{{user_input.count}}" output_schema_ref: "#/components/schemas/GreetingOutput"

Step 3：启动 Agent 并发送请求

# 启动 Agent，监听本地端口 agentic-os start --config agent-config.yaml --port 8080 & # 发送请求（模拟用户输入） curl -X POST http://localhost:8080/execute \ -H "Content-Type: application/json" \ -d '{"user_input": {"name": "Bob", "count": "2"}}' # 返回：{"greetings": ["Hello, Bob!", "Hello, Bob!"], "timestamp": 1717027201}

这里的关键是{{user_input.name}}这种模板语法。Agentic OS Runtime 在调用 Skill 前，会解析此模板，将顶层请求中的user_input.name提取出来，注入为 Skill 的环境变量INPUT_NAME。这种数据流设计，使得 Agent 配置文件成为真正的“胶水”，它不包含业务逻辑，只定义数据如何流动。我们在 Workshop 中展示了如何将greetSkill 的输出，作为另一个log-writerSkill 的输入，形成一个两跳的简单工作流，全程无需写一行新代码，只需修改 YAML。

4.4 AgentSecCore 实战：构建一个自动漏洞响应 Agent

这是 Workshop 最复杂的实战任务，要求学员整合sec/cve-scan-runner、sec/cve-report-parser和comms/slack-notifier三个 Skill，构建一个能自动响应漏洞通报的 Agent。

Step 1：获取 CVE 通报数据我们提供了一个模拟的 CVE 通报 JSON：

{ "cve_id": "CVE-2024-12345", "affected_packages": ["openssl-1.1.1f-15.el8_3.x86_64"], "severity": "CRITICAL", "cvss_score": 9.8 }

Step 2：设计 Agent 工作流

name: "cve-responder" skills: - name: "scan" skill: "sec/cve-scan-runner@1.2.0" input: TARGET_PACKAGE: "{{cve_data.affected_packages[0]}}" output_schema_ref: "#/components/schemas/ScanResult" - name: "parse" skill: "sec/cve-report-parser@0.9.3" input: SCAN_RESULT: "{{scan.output}}" output_schema_ref: "#/components/schemas/ParsedReport" - name: "notify" skill: "comms/slack-notifier@2.1.1" input: CHANNEL: "security-alerts" MESSAGE: "🚨 CRITICAL CVE {{cve_data.cve_id}} detected!\n\nAffected: {{cve_data.affected_packages[0]}}\nStatus: {{parse.output.status}}\nDetails: {{parse.output.details}}" output_schema_ref: "#/components/schemas/NotificationResult"

Step 3：执行与验证学员运行：

agentic-os execute --config cve-responder.yaml \ --input '{"cve_data": {"cve_id": "CVE-2024-12345", "affected_packages": ["openssl-1.1.1f-15.el8_3.x86_64"], "severity": "CRITICAL"}}'

预期输出是 Slack 通道收到一条格式化消息。实际执行中，有 3 组学员遇到了parseSkill 因SCAN_RESULT格式不符而失败。排查发现，cve-scan-runner的输出中status字段是"VULNERABLE"，而cve-report-parser的 Schema 要求是"vulnerable"（小写）。这是一个典型的大小写敏感契约问题。我们引导学员查看cve-report-parser的skill.yaml中output_schema，确认了约定，并让他们在cve-scan-runner的main.py中添加.lower()调用。这个 Bug 修复过程，比任何讲解都更深刻地传达了“契约即法律”的理念。

5. 常见问题与排查技巧实录

5.1 技能安装失败：签名验证不通过

现象：skillhub install sec/cve-baseline-checker@1.0.0报错：

❌ Failed to install sec/cve-baseline-checker@1.0.0: signature verification failed

排查思路：

1. 首先确认本地时间是否准确：date。SkillHub 使用 X.509 证书签名，证书有效期检查依赖系统时间，误差超过 5 分钟即失败；
2. 检查 Skill 的签名文件signature.sig是否完整：ls -l *.sig。如果文件为空或大小为 0，说明推送时网络中断；
3. 手动验证签名：skillhub verify sec/cve-baseline-checker@1.0.0 --key /path/to/public.key。如果失败，说明公钥不匹配，需从 SkillHub 官方渠道重新下载根证书。

根本原因与解决：本次 Workshop 中，有 12 名学员遇到此问题，全部源于第一步——他们的笔记本 BIOS 时间比实际慢了 8 分钟。解决方案不是ntpdate，而是sudo hwclock --systohc（将系统时间同步到硬件时钟），因为 SkillHub 的签名验证发生在容器启动前，此时 ntp 服务尚未运行。这个细节，是我们在 3 次 Workshop 迭代后才总结出的“黄金 5 分钟法则”。

5.2 技能执行超时：环境能力声明不匹配

现象：skillhub run ops/backup-manager卡住 30 秒后报错：

❌ Execution timeout after 30s. Check if required capabilities are declared.

排查思路：

1. 查看 Skill 的skill.yaml，确认capabilities字段是否声明了所需能力。backup-manager需要lvm和filesystem能力；
2. 检查宿主机是否安装了lvm2包：rpm -q lvm2；
3. 检查 SkillHub Runtime 的 capability mapping 配置：cat ~/.skillhub/config.yaml | grep -A 5 "capabilities"。

根本原因与解决：backup-manager的skill.yaml中写了：

capabilities: - "lvm" - "filesystem"

但 SkillHub Runtime 默认只映射network、time等基础能力，lvm是扩展能力，需手动启用。解决方案是在~/.skillhub/config.yaml中添加：

capabilities: lvm: binary: "/sbin/lvcreate" args: ["--help"]

然后重启 Runtime。这个配置告诉 Runtime，“当 Skill 声明需要lvm能力时，请检查/sbin/lvcreate是否存在且可执行”。我们在 Workshop 的 FAQ 文档中，将这个配置模板放在了最顶部，因为它是最高频的“踩坑点”。

5.3 技能间通信失败：环境变量注入失效

现象：dev/test-runner调用dev/code-linter时，code-linter报错找不到pyproject.toml。

排查思路：

1. 检查test-runner的skill.yaml，确认其output_schema是否包含project_path字段；
2. 检查code-linter的skill.yaml，确认其env字段是否声明了PROJECT_PATH，且required: true；
3. 在test-runner的main.py中，打印os.environ，确认PROJECT_PATH是否被正确设置。

根本原因与解决：test-runner的输出 Schema 中，project_path字段定义为：

project_path: type: "string" description: "Absolute path to the project root"

但code-linter的env声明是：

- name: "PROJECT_DIR" description: "Project directory" required: true

字段名不匹配！SkillHub 的环境变量注入是严格按字段名映射的，project_path不会自动转为PROJECT_DIR。解决方案是统一命名，或在test-runner的输出中，显式添加一个PROJECT_DIR字段。我们在 Workshop 的代码审查环节，专门设置了这个“命名陷阱”，让学员互相 reviewskill.yaml，效果极佳。

5.4 Workshop 下载包无法运行：SELinux 策略拦截

现象：