agent-skills：面向LLM智能体的能力操作系统

1. “agent-skills”不是功能列表，而是智能体能力的工程化表达范式

你第一次在 GitHub 仓库名里看到agent-skills，或在 CLI 工具的--skills参数后跟一串路径时，很容易把它当成“插件集合”“功能开关”或者“技能市场下载包”。但实际踩过三轮大模型智能体（Agent）落地项目后我才明白：agent-skills的本质，是把人类工作流中可复用、可验证、可组合的原子操作，封装成带契约、有边界、能编排的标准化执行单元。它既不是 API 的简单包装，也不是 Prompt 的堆砌，而是一套面向 LLM 智能体的“能力操作系统”。

这个概念之所以突然密集出现在热词中——从codex cli到zcode cli，从claude agent skills到reasonix 如何安装新 skills——根本原因在于：纯 Prompt 工程已到瓶颈。当一个 Agent 要调用天气、查数据库、生成 PDF、发邮件、读取本地 Excel 并做统计，再把结果喂给另一个 LLM 做摘要时，“写一段能调天气 API 的 Prompt”已经完全失效。你需要的是：明确输入格式、确定输出 Schema、内置错误兜底逻辑、支持超时与重试策略、自带权限声明、可被其他 skills 依赖调用——这些，才是agent-skills真正要解决的问题。

比如find skills这个命令背后，不是在搜 GitHub 仓库，而是在查询本地 skills registry 中已注册的能力元数据：它是否声明了scope: filesystem:read？是否兼容当前运行时的 LLM provider（如 DeepSeek、Qwen、Claude）？其input_schema是否与上游 skills 的output_schema匹配？这些判断全部基于 skills 自身携带的skill.yaml描述文件，而非靠人工记忆或文档对齐。

提示：别把agent-skills当成“技能商店”，它更接近 Linux 的/usr/bin目录——每个可执行文件（skill）都自带--help、--version、明确的 stdin/stdout 接口规范，且能被 shell（即 Agent Runtime）统一调度。你装一个curl，不是为了“有网络能力”，而是因为它遵循 POSIX 标准，能被任何脚本可靠调用。

这也解释了为什么大量热词集中在 CLI 工具上：codex cli install skill@github.com/user/weather-v2、zcode cli list --enabled、boos cli run --skill=pdf-gen --input=data.json。CLI 是 skills 的“安装器 + 注册中心 + 执行沙盒 + 调试终端”四合一载体。它强制 skills 遵守统一入口（通常是main.py或index.js）、统一参数解析（argparse或yargs）、统一错误码（非零退出码表示失败），从而让 Agent 不再需要为每个能力写定制胶水代码。

我去年重构一个客户合同审核 Agent 时，把原本 370 行硬编码的 PDF 解析 + 条款提取 + 法规比对逻辑，拆成了 4 个 skills：pdf-extract-text、clause-locator、regulation-db-query、compliance-checker。每个 skill 独立测试、独立版本、独立更新。当客户要求接入新法规库时，只需替换regulation-db-query的新版，其余三个完全不动。这才是agent-skills带来的真正生产力跃迁——不是“多了一个功能”，而是“获得了可维护、可演进、可审计的能力架构”。

2. 一个合格的 agent-skill 必须通过五层契约校验，缺一不可

市面上很多所谓“skills”只是把 API 调用函数扔进一个文件夹，起个名字就叫weather-skill。这种做法在 PoC 阶段能跑通，但一旦进入生产环境，立刻暴露出致命缺陷：没有输入校验导致 LLM 传入非法坐标直接 crash；没有超时控制让整个 Agent 卡死在第三方服务响应慢时；没有错误分类使 fallback 逻辑无法触发；没有权限声明引发安全审计失败；没有版本兼容性说明导致升级后下游 skills 全面失联。

真正的agent-skills是一套契约驱动的工程实践。我在为某金融风控平台设计 skills 规范时，和团队共同制定了必须通过的五层校验，每层失败都阻断注册：

2.1 接口契约层：skill.yaml是唯一真相源

每个 skill 目录下必须存在skill.yaml，且内容不可由代码动态生成。它定义了 skill 的“宪法”，包括：

name: "pdf-extract-text" version: "2.3.1" description: "从 PDF 提取结构化文本，保留标题层级与表格边界" author: "risk-team@finco.com" license: "MIT" # 明确声明所需权限，运行时据此做 sandbox 限制 permissions: - filesystem:read - network:https://api.pdfextractor.dev # 输入输出严格 Schema，使用 JSON Schema Draft-07 input_schema: type: object properties: file_path: type: string pattern: "^/data/uploads/.*\\.pdf$" page_range: type: array items: type: integer minimum: 1 minItems: 1 maxItems: 100 required: [file_path] output_schema: type: object properties: pages: type: array items: type: object properties: number: type: integer text_blocks: type: array items: type: object properties: type: type: string enum: ["heading", "paragraph", "table"] content: type: string metadata: type: object properties: total_pages: type: integer extracted_at: type: string format: date-time # 运行时约束 runtime: timeout_ms: 15000 memory_limit_mb: 512 max_retries: 2

注意：file_path的pattern不是装饰，而是运行时强制校验。若 LLM 传入../../../etc/passwd，skill 进程启动前就被 runtime 拒绝，根本不会执行。这比在 Python 里os.path.abspath()后再os.path.commonpath()安全得多。

2.2 执行契约层：单入口、纯函数、无副作用

所有 skill 必须提供单一可执行入口（如main.py），且该入口必须是纯函数式设计：

• 输入唯一来源：只接受标准输入（stdin）的 JSON 字符串，不读环境变量、不读命令行参数（CLI 工具已解析并注入 stdin）
• 输出唯一出口：只向标准输出（stdout）写入 JSON 结果，不打印 debug 日志到 stdout（日志走 stderr）
• 无全局状态：禁止修改全局变量、禁止写文件到非授权路径、禁止建立长连接
• 进程级隔离：每次调用都是全新进程，不共享内存、不复用连接池

我们曾因一个database-queryskill 在__init__中初始化了全局 SQLAlchemy engine，导致并发调用时连接池耗尽。后来强制要求：所有初始化必须在main()函数内完成，且每次调用都新建连接。虽然性能略降，但换来的是 100% 可预测的行为。

2.3 错误契约层：三类错误必须明确区分

一个 skill 的退出码（exit code）和 stderr 输出共同构成错误契约：

关键点在于：1类错误必须由 skill 自身校验并返回，不能依赖 LLM 去“猜”输入是否合法。我们曾让 LLM 生成file_path，结果它写了C:\Users\Me\contract.pdf，Linux runtime 直接拒绝。后来在skill.yaml的input_schema中加了pattern，并在main.py开头加了jsonschema.validate()，问题根治。

2.4 兼容契约层：语义化版本与 provider 映射表

agent-skills生态最大的陷阱是“版本幻觉”。LLM 可能调用pdf-extract-text@v1.0，但 runtime 实际加载的是v2.3，因为 v1.0 已被删除。为此，我们要求每个 skill 在skill.yaml中声明compatibility：

compatibility: # 支持的 LLM provider 列表，精确到 model name providers: - name: "deepseek-official" models: ["deepseek-chat", "deepseek-coder"] - name: "qwen" models: ["qwen-max", "qwen-plus"] # 向前兼容的旧版本号（major.minor） backward_compatible_with: - "2.2.0" - "2.1.5" # 该版本废弃的字段（用于 migration 提示） deprecated_fields: []

当 CLI 工具执行zcode cli run --skill=pdf-extract-text --provider=deepseek-official时，它会：

1. 查找本地 registry 中所有pdf-extract-text版本
2. 过滤出compatibility.providers包含deepseek-official的版本
3. 选择满足backward_compatible_with的最新版（如2.3.1）
4. 若找不到，则报错No compatible skill found for provider deepseek-official

这彻底避免了llm-deepseek: no api key for provider route "deepseek-official"这类错误——问题不在 API Key，而在 skills 未声明对deepseek-official的支持。

2.5 安全契约层：最小权限原则与 scope 声明

热词中频繁出现的choosemedia:fail api scope is not declared in the privacy agreement，正是安全契约缺失的典型后果。agent-skills必须显式声明其所需的最小权限集，且 runtime 必须强制执行：

• filesystem:read→ 只能读取skill.yaml中permissions.filesystem.read_paths指定的路径白名单
• network:https://api.xxx.com→ DNS 解析和 TCP 连接只允许到该域名，且 HTTPS SNI 必须匹配
• env:API_KEY→ 运行时注入的环境变量仅限skill.yaml中required_env列出的 key

我们曾发现一个sms-sendskill 在代码里硬编码了阿里云 AccessKey，这是严重违规。整改后，它改为声明required_env: ["ALIYUN_SMS_ACCESS_KEY_ID", "ALIYUN_SMS_ACCESS_KEY_SECRET"]，由 CLI 工具在启动时从安全 vault 注入，且该 vault 的访问权限与 skill 的permissions绑定。

这五层契约不是纸上谈兵。我们在 CI 流程中加入了skill-validate步骤：对每个 PR 的 skill 目录运行zcode cli validate --path=./skills/pdf-extract-text，只有全部五层校验通过，才允许合并。这套机制让团队在 6 个月内交付了 42 个 production-ready skills，零次因 skill 本身缺陷导致线上故障。

3. CLI 工具链：从codex cli到zcode cli，核心差异在于运行时抽象粒度

当你搜索codex cli 安装或zcode cli 命令哪些时，很容易陷入工具对比的误区。实际上，codex cli、zcode cli、boos cli、trae cli并非竞争关系，而是针对不同抽象层级的运行时需求设计的。它们的差异，决定了你构建的agent-skills是“玩具级”还是“银行级”。

3.1codex cli：面向开发者，强调快速原型与本地调试

codex cli的设计哲学是“让第一个 skill 在 5 分钟内跑起来”。它的核心命令极其精简：

# 初始化一个新 skill 模板 codex cli init pdf-extract-text # 在本地运行 skill（模拟 runtime 环境） codex cli run --skill=pdf-extract-text --input='{"file_path":"/tmp/test.pdf"}' # 将 skill 打包为 tar.gz，供分发 codex cli package --skill=pdf-extract-text --output=pdf-extract-text-v1.0.tgz

codex cli的优势在于其零配置本地运行时：它用subprocess.Popen启动 skill 进程，通过 stdin/stdout 传递 JSON，用timeout命令实现超时控制，用ulimit限制内存。所有这些都在单个二进制中完成，无需 Docker、无需 Kubernetes。

但这也带来硬伤：它无法实现真正的权限隔离。codex cli run启动的 Python 进程，依然能访问宿主机文件系统、发起任意网络请求。所以codex cli适合开发阶段——你写完main.py，用codex cli run测试逻辑是否正确，但绝不应将其用于生产。

我团队早期用codex cli快速验证了 12 个 skills 的核心逻辑，平均每个 skill 从 idea 到可运行 demo 仅需 22 分钟。但上线前，全部重写为符合zcode cli规范的版本。

3.2zcode cli：面向生产，提供完整的 sandboxed runtime

zcode cli的本质是一个轻量级容器运行时。它不依赖 Docker daemon，而是基于runc和rootless containers构建，为每个 skill 创建独立的 mount namespace、pid namespace 和 cgroup。其核心命令体现这一理念：

# 安装 skill 到本地 registry（解压并验证五层契约） zcode cli install skill@github.com/finco/pdf-extract-text-v2.3.1.tgz # 在 sandbox 中运行 skill（真实权限隔离） zcode cli run --skill=pdf-extract-text \ --input='{"file_path":"/data/uploads/contract.pdf"}' \ --timeout=15s \ --memory-limit=512mb # 查看 skill 的实时资源消耗（cgroup stats） zcode cli stats --skill=pdf-extract-text

关键区别在于zcode cli run的执行流程：

1. 读取skill.yaml，生成 seccomp bpf 过滤规则（禁用openat以外的文件系统调用）
2. 创建 tmpfs mount，将input.json和skill代码挂载为只读
3. 设置 cgroup v2，限制 CPU quota、memory high、pids.max
4. 使用unshare创建新 pid namespace，启动 skill 进程
5. 通过ptrace监控进程，超时则kill -9

这意味着：即使pdf-extract-text的 Python 代码里有os.system('rm -rf /')，它也只会删掉自己 tmpfs 挂载点下的内容，宿主机毫发无损。这才是permission denied while trying to connect to the docker api这类错误的真正解法——不是修复 Docker 权限，而是绕过 Docker，用更底层的 namespace 隔离。

3.3boos cli与trae cli：面向特定领域，做垂直深度优化

boos cli主打“前端开发 skills”，它内置了 WebAssembly runtime。所有boosskills 必须编译为.wasm文件，通过wasmer执行。这带来两大优势：

• 极致启动速度：WASM 模块加载比 Python 进程启动快 10 倍，适合高频调用的 skills（如string-format、json-validate）
• 跨平台一致性：同一份 WASM，在 macOS、Linux、Windows 上行为 100% 一致，消除了node 安装 codex cli 很慢这类环境差异问题

trae cli则专为“API 服务编排”设计。它的skill.yaml支持api_spec字段，可直接引用 OpenAPI 3.0 spec：

api_spec: openapi: "3.0.3" info: title: "Weather API" version: "1.0.0" servers: - url: "https://api.weather.gov" paths: /points/{latitude},{longitude}: get: parameters: - name: latitude in: path required: true schema: {type: number} - name: longitude in: path required: true schema: {type: number} responses: '200': content: application/json: schema: $ref: '#/components/schemas/PointResponse'

trae cli会自动根据此 spec 生成input_schema和output_schema，并内置 HTTP client。开发者只需写main.wasm处理业务逻辑，不用操心 HTTP 请求细节。这直接解决了api error: 400 this model's maximum context length is 1048576 tokens的根源——不是模型 token 限制，而是 skills 把整个 OpenAPI spec 当作 prompt 喂给了 LLM。

选择哪个 CLI，取决于你的场景：

• 个人学习/快速验证→codex cli（安装最快，文档最全）
• 企业级生产部署→zcode cli（安全、可观测、可审计）
• 前端高频技能→boos cli（WASM 性能，跨平台）
• API 密集型 Agent→trae cli（OpenAPI 驱动，减少胶水代码）

我们最终采用混合方案：用codex cli开发，zcode cli构建和部署，trae cli管理所有 API-based skills。三者通过统一的skill.yaml格式互通，不存在 vendor lock-in。

4. 从skills到agent：编排不是写代码，而是定义数据流图

很多团队卡在最后一步：有了 20 个高质量agent-skills，却不知道如何把它们组合成一个真正可用的 Agent。常见错误是用 Python 写一个main.py，按顺序调用skill_a()、skill_b()、skill_c()，然后用 try-except 做错误处理。这本质上仍是传统微服务编排，违背了agent-skills的设计初衷。

真正的agent-skills编排，是声明式的数据流图（Dataflow Graph）。它不关心“谁调用谁”，只定义“数据从哪里来，经过什么变换，流向哪里去”。slash commands（如/compact、/model、/resume）就是这种图的快捷入口。

4.1 数据流图的核心元素：节点、边、条件、循环

一个典型的resume-analyzerAgent 的数据流图如下：

[Input: resume.pdf] ↓ (file_path) [Skill: pdf-extract-text] ↓ (output.pages[].text_blocks[]) [Skill: clause-locator] ↓ (output.clause_matches[]) [Branch: is_legal_clause?] ├─ Yes → [Skill: regulation-db-query] → [Skill: compliance-checker] → [Output: risk_report] └─ No → [Skill: summary-generator] → [Output: executive_summary]

这个图的关键在于：

• 节点：每个 skill 是一个无状态函数节点，只接收输入、产生输出
• 边：边上的标签（如output.pages[].text_blocks[]）是 JSONPath 表达式，定义数据提取规则
• 分支（Branch）：基于 skill 输出的布尔值做路由，不是 if-else 代码
• 循环：[Skill: clause-locator]的输出是数组，自动触发下游 skills 的 fan-out 执行

我们用zcode cli graph命令管理此图。graph.yaml文件定义：

name: "resume-analyzer" version: "1.2.0" nodes: - id: "pdf-extract" skill: "pdf-extract-text@2.3.1" input_mapping: file_path: "$.input.file_path" - id: "locate-clauses" skill: "clause-locator@1.5.0" input_mapping: text_blocks: "$.pdf-extract.output.pages[*].text_blocks" - id: "is-legal" skill: "boolean-classifier@0.8.2" input_mapping: text: "$.locate-clauses.output.clause_matches[*].content" label: "legal" - id: "regulation-query" skill: "regulation-db-query@3.1.0" input_mapping: clause_id: "$.locate-clauses.output.clause_matches[*].id" condition: "$.is-legal.output.result == true" - id: "compliance-check" skill: "compliance-checker@2.0.0" input_mapping: regulation_data: "$.regulation-query.output" clause_text: "$.locate-clauses.output.clause_matches[*].content" condition: "$.is-legal.output.result == true" - id: "summary-gen" skill: "summary-generator@1.9.3" input_mapping: text_blocks: "$.pdf-extract.output.pages[*].text_blocks" condition: "$.is-legal.output.result == false" edges: - from: "pdf-extract" to: "locate-clauses" - from: "locate-clauses" to: "is-legal" - from: "is-legal" to: "regulation-query" - from: "is-legal" to: "summary-gen" - from: "regulation-query" to: "compliance-check"

zcode cli run --graph=resume-analyzer --input='{"file_path":"/data/resumes/john.pdf"}'会：

1. 解析graph.yaml，构建 DAG
2. 按拓扑序启动 skills
3. 自动处理 fan-out（locate-clauses输出 5 个 clause，is-legal并行执行 5 次）
4. 根据condition字段决定边是否激活
5. 将所有output按$ref路径注入下游input_mapping

这完全解耦了业务逻辑和执行引擎。要增加“检查 GDPR 合规性”，只需添加一个新 node 和 edge，无需改任何 skill 代码。

4.2slash commands：数据流图的用户界面层

/compact、/model、/resume这些 slash commands，本质是预定义的graph.yaml快捷方式。zcode cli的commands.yaml文件定义：

commands: - name: "/resume" description: "Analyze a resume PDF and generate risk report or summary" graph: "resume-analyzer" input_schema: type: object properties: file_path: type: string description: "Path to the resume PDF file" required: [file_path] - name: "/compact" description: "Compact a large text by extracting key points" graph: "text-compactor" input_schema: type: object properties: text: type: string maxLength: 100000 required: [text]

当用户在 chat UI 中输入/resume /data/uploads/john.pdf时：

• CLI 工具解析/resume，找到对应的graph: "resume-analyzer"
• 校验输入/data/uploads/john.pdf是否符合input_schema
• 执行zcode cli run --graph=resume-analyzer --input='{"file_path":"/data/uploads/john.pdf"}'
• 将最终输出（risk_report或executive_summary）返回给 UI

这解释了为什么skills本身不包含 UI 逻辑——UI 层只负责解析 slash command，调用 CLI，展示结果。skills只是数据流图中的原子节点，职责单一，复用率高。

4.3 实战避坑：避免“技能黑洞”与“数据漂移”

在真实项目中，我们遇到两个高频陷阱：

陷阱一：技能黑洞（Skill Black Hole）
现象：某个 skill 执行时间远超预期（如regulation-db-query平均 2s，但偶尔 30s），导致整个 graph 卡住。
根因：zcode cli的默认超时是全局的（如 30s），但单个 skill 的timeout_ms在skill.yaml中设为 15000。当 skill 因网络抖动响应慢，runtime 不会单独 kill 它，而是等满 30s 后才中断。
解决方案：在graph.yaml中为关键节点显式设置timeout：

nodes: - id: "regulation-query" skill: "regulation-db-query@3.1.0" timeout: "10s" # 覆盖 skill.yaml 中的 15s input_mapping: ...

陷阱二：数据漂移（Data Drift）
现象：clause-locatorv1.2 输出的clause_matches字段名是matches，v1.3 改为clauses，导致下游is-legal报错KeyError: 'matches'。
根因：input_mapping中用了硬编码路径$.locate-clauses.output.matches，未绑定版本。
解决方案：在graph.yaml中使用versioned_input_mapping：

- id: "is-legal" skill: "boolean-classifier@0.8.2" versioned_input_mapping: "0.8.0": "matches" "0.8.2": "clauses" input_mapping: text: "$.locate-clauses.output.[{versioned_input_mapping}].content"

数据流图不是银弹，但它把“如何组合 skills”这个问题，从编程问题转化为了配置问题。我们的运维同学现在能用 VS Code 修改graph.yaml，添加新分支，调整超时，而无需懂 Python。这才是agent-skills落地的终极价值——让业务逻辑可配置、可版本化、可审计。

5. 生产级agent-skills的监控、调试与演进：从agent skills测试到持续交付

当agent-skills进入生产环境，skills就不再是“能跑就行”的代码片段，而是一个需要可观测、可调试、可灰度的软件组件。热词中反复出现的agent skills测试、mineru api、openspec cli，都指向同一个需求：如何确保 skills 在真实流量下稳定、高效、安全。

5.1 三层监控体系：基础设施、skill 运行时、业务语义

我们为 skills 建立了三层监控，每层使用不同工具，覆盖不同维度：

关键创新在于业务语义层监控。例如pdf-extract-text，我们不只看它是否 crash，更要看它提取的文本是否准确。方法是：每天凌晨用 1000 份已标注的 PDF（人工确认每页标题、段落、表格边界），运行 skill，计算：

• 文本准确率= （正确提取的字符数 / 总字符数）× 100%
• 结构保真度= （正确识别的标题层级数 / 总标题数）× 100%

这些指标写入 Prometheus，当pdf_extract_text_accuracy < 98%时，自动触发zcode cli rollback --skill=pdf-extract-text --to=2.2.0，回滚到上一个稳定版本。

5.2 调试三板斧：--debug、--trace、--replay

agent-skills的分布式特性让传统print()调试失效。我们设计了三套调试机制：

第一板斧：--debug模式输出完整上下文
zcode cli run --skill=pdf-extract-text --input=... --debug会输出：

• 启动时的完整 sandbox 配置（cgroup limits, seccomp rules）
• skill 进程的完整 stdin（原始 input JSON）
• skill 进程的 stdout + stderr（原始 output JSON + error）
• 进程退出码和执行时间
• 所有环境变量（masked sensitive values）

这让我们能快速判断是输入问题、skill bug，还是 runtime 配置问题。

第二板斧：--trace模式记录完整数据流
zcode cli run --graph=resume-analyzer --input=... --trace会生成一个trace.json：

{ "graph_id": "resume-analyzer-1.2.0", "nodes": [ { "id": "pdf-extract", "start_time": "2024-05-20T08:22:10.123Z", "end_time": "2024-05-20T08:22:10.456Z", "input": {"file_path": "/data/resumes/john.pdf"}, "output": {"pages": [{"number": 1, "text_blocks": [...]}, ...]}, "duration_ms": 333.1, "exit_code": 0 } ] }

配合 Jaeger UI，可以直观看到每个 skill 的耗时、依赖关系、失败节点。

第三板斧：--replay模式复现任意历史调用
zcode cli replay --trace-id=abc123会：

• 从对象存储（S3）下载该 trace 对应的input.json和skill代码快照
• 在干净 sandbox 中重新执行
• 输出与原始调用完全一致的结果（或 failure）

这解决了“线上偶发 bug 无法复现”的经典难题。运维同学拿到 trace ID，5 分钟内就能在本地复现并定位。

5.3 持续交付流水线：从skills开发到skills安装包下载

我们构建了全自动 CI/CD 流水线，确保每个 skills PR 经历 5 道关卡：

1. 静态检查：yamllint校验skill.yaml，pylint检查 Python 代码风格
2. 契约验证：zcode cli validate --path=.运行全部五层校验
3. 单元测试：pytest运行 skill 自带的 test suite（覆盖率 ≥ 85%）
4. 集成测试：在真实 sandbox 中运行zcode cli run，验证输入/输出
5. 金丝雀发布：新版本 skills 先路由 1% 流量，监控业务指标 15 分钟，达标后全量

流水线产出物是skills-install-package.tar.gz，包含：

• 所有 skills 的代码、skill.yaml、requirements.txt
• graph.yaml定义的全部数据流图
• commands.yaml定义的 slash commands
• registry.json记录每个 skill 的版本、hash、兼容性

skills安装包下载不是下载单个 skill，而是下载整个可部署包。运维用zcode cli deploy --package=skills-install-package.tar.gz一键部署，自动完成：

• 解压并验证所有 skills
• 更新本地 registry
• 重启相关 graph services
• 发送 Slack 通知：“resume-analyzer v1.2.1 deployed, 100% traffic”

这套机制让我们实现了 skills 的周更频率，且 0 次因发布导致线上故障。今天学会了skills不再是个人探索，而是团队可复用、可审计、可追溯的工程能力。

最后分享一个真实体会：agent-skills的最大价值，不是让你的 Agent 多几个功能，而是把“AI 应用开发”这件事，从艺术变成了工程。当skills有了契约、CLI 有了 runtime、编排有了图、监控有了指标，你就不再需要“调参大师”或“Prompt 工程师”，而只需要“skills 架构师”和“graph 设计师”。他们用 YAML 定义能力，用 CLI 部署能力，用指标衡量能力——这才是agent-skills想要抵达的终点。