A8 · Agent 如何组织和复用专业技能？ - Skills

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：02 · Agent 的能力由哪些部分构成？ - Internal Architecture
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent 如何将领域方法、操作规程、工具组合和经验封装为可发现、可选择、可加载、可执行、可验证、可维护的 Skill？Skill 与 Tool、Prompt、Workflow、Memory 和 Planning 的边界是什么？如何解决技能选择、上下文加载、版本管理、授权执行、结果评估及安全问题？

专题导读

在 Agent 的内部架构中，Tools 解决“系统能够调用什么外部操作”，Skills 进一步解决“面对某类任务，系统应该如何有组织地使用知识、步骤、工具和检查方法”。例如，read_file、search 和 write_file 是工具操作；“对技术文献进行有来源的对比研究”则是一种可复用的专业工作方法，包含研究问题拆解、检索、证据筛选、比较、写作和验证。它可以被组织为一个 Skill，但不必等同于单个工具调用或一条固定流程。

本篇将 Skill 作为一种可复用的任务方法与能力封装契约研究。它可以以自然语言指令、结构化元数据、代码、脚本、工具组合、子流程或这些要素的混合形式实现。Skill 不存在跨所有 Agent 框架的唯一标准定义；不同产品中同名概念的执行能力、加载方式和权限边界可能显著不同。以下先建立通用技术模型，再讨论代表性实现，最后以一个本地可运行的 Skill Registry / Runner 实验验证关键契约。实验只验证确定性编排与授权边界，不宣称证明真实模型能够可靠选择或执行技能。

01 · 研究定位：为什么 Agent 需要 Skills？

1.1 从原子工具到任务方法

假设研究助理 Agent 收到任务：“对比两种 Agent 框架的持久化执行机制，形成可追溯的研究简报。”其工具集可能提供 web_search、read_document、extract_quote、write_report。这些工具没有自动说明：应该先确定比较维度还是先搜索；什么时候需要核对原文；什么证据可以支持技术判断；证据不足时如何回退；最终报告如何验收。

如果每次都由模型临时构造整套工作方法，可能产生步骤遗漏、质量不一致、重复推理和无效工具调用。Skill 将已知的任务方法外显为可复用资产，使 Agent 能够在类似任务中采用相对一致的工作规程。它并不能消除模型的不确定性；只有配合适当的选择、执行和验证机制，才能提升可控性。

1.2 Skill 的工作定义

在本知识库中，Skill 指：面向一类可识别任务、具有明确使用条件和输入输出契约、能够为 Agent 提供可复用执行方法的能力单元。它可以指导模型，也可以由运行时直接执行部分确定性步骤。一个 Skill 至少应回答五个问题：适用于什么任务；需要什么输入；依赖哪些资源；如何完成或指导执行；如何判断结果可接受。

这一定义是本篇为分析不同实现提出的工作模型，并非某个行业标准的逐字定义。一个仅包含简短说明的“技能”可能只具备指导作用；一个包含可执行脚本的技能可以实际触发工具；一个具备状态和恢复机制的技能可能接近可复用子工作流。分析时必须区分这些实现能力。

1.3 什么时候不需要 Skill？

如果任务只需一次明确的 API 调用，直接使用 Tool 往往更合适；如果任务严格确定、分支有限、可由程序稳定完成，普通函数或工作流可能更简单；如果只是提供一条临时写作风格要求，Instructions 已足够。Skill 的价值来自重复出现的任务模式及其方法、依赖和质量标准值得独立维护，而不是“所有行为都需要技能化”。

02 · 概念边界：Skill、Tool、Prompt、Workflow、Memory

对象	核心抽象	典型内容	主要执行责任	例子
Tool	可调用的原子操作或服务接口	参数模式、调用端点、返回值	工具执行器	search(query)
Instructions / Prompt	当前行为的指令与约束	角色、要求、格式	模型解释，运行时强制约束另行实现	“优先使用原始来源”
Skill	面向任务类别的可复用方法与能力契约	触发条件、步骤、工具依赖、检查标准	模型和/或 Skill Runner	“完成可追溯技术对比”
Workflow	明确的控制流与状态转换	节点、边、条件、重试	工作流执行器	“审批后发布报告”
Memory	可被未来任务复用的历史信息	事实、偏好、经验、历史结果	记忆存取机制	“上次检索发现某来源失效”
Knowledge	支撑判断的外部事实与证据	文档、数据库、引用	检索与证据处理	“某框架的官方文档”
Planning	当前任务的动态行动选择	计划、依赖、下一步动作	规划器/决策器	“先补充缺失证据”

关键关系：Skill 是任务方法的封装，而不是对其他机制的替代。 Skill 可以引用工具、包含指令、调用工作流、读取知识，并在执行过程中利用记忆；但不能因为它描述了某项能力，就推定它已经具备执行权限、可靠性或持久化能力。

例如“发布技术报告”Skill 可以写明发布前必须审批，但真正阻止未授权发布的必须是执行器中的权限策略，而非 Skill 文本本身。另一个边界是 Skill 与 Sub-agent：Skill 是能力资产，Sub-agent 是可以独立接收任务并运行决策循环的执行主体；Skill 可以被 Sub-agent 使用，也可以由主 Agent 直接使用。

03 · 技术模型：一个 Skill 应包含什么？

3.1 技能契约（Skill Contract）

可将 Skill 表示为：

$$S=(I,O,T,D,P,V,E,R)$$

其中 I 为输入契约，O 为输出契约，T 为触发/适用条件，D 为依赖资源，P 为过程描述或可执行程序，V 为验证规则，E 为副作用和权限要求，R 为版本及来源信息。这是分析性模型，不要求每种实现都以完全相同的文件格式保存。

一个可操作的 YAML 例子：

name: technical-comparison
version: 1.2.0
description: Compare two technical solutions with traceable evidence
triggers:
  - compare_technical_approaches
inputs:
  required: [topic, candidates, output_path]
outputs:
  report: markdown
required_tools: [search, read_document, write_file]
required_knowledge: [source_quality_criteria]
permissions:
  read: [public_documents]
  write: [workspace/reports]
  publish: false
procedure:
  - define_comparison_dimensions
  - collect_primary_sources
  - extract_evidence_with_provenance
  - compare_claims_and_limitations
  - draft_report
  - verify_citations_and_completion
validation:
  - every_major_claim_has_source
  - uncertainties_are_labeled
  - no_unauthorized_publish

该 YAML 是本篇建议的设计格式，不是已验证的某一框架原生 schema。procedure 中的名字是方法步骤，不能直接假定存在对应的可执行函数；必须通过执行器、工具映射或模型解释将其落实。

3.2 输入与输出契约

输入不应只写成自然语言描述。至少应区分必需字段、可选字段、类型、允许范围、敏感度和来源可信度。输出应区分产物本身、来源证据、执行状态和质量检查结果。对具有副作用的 Skill，还应明确允许写入的位置、是否需要审批以及失败时如何处理部分完成的操作。

3.3 版本与依赖

Skill 的语义变化可能改变任务行为，即使工具接口未变。例如从“生成摘要”改成“必须先验证每条引用”就改变了成功条件。执行记录应保存 skill_id、version、配置摘要、工具版本和关键输入摘要，以便复现与回归。不能把“最新版本”作为可复现执行的充分依据；运行中应固定版本或保存加载快照。

04 · 技能发现与选择：Agent 如何知道该用哪个 Skill？

4.1 发现过程

一个典型流程为：接收任务 → 提取任务意图与约束 → 检索候选 Skill → 评估适配性与权限 → 选择版本 → 加载完整说明 → 执行。Skill Registry 可以只提供元数据索引，也可以存储完整内容和版本。候选发现与最终授权必须分开：发现某 Skill 不意味着当前用户有权执行它。

4.2 候选排序

可以采用关键词、规则、嵌入相似度、分类模型或 LLM 路由。一个分析性评分模型是：

$$score(S,q)=w_{1}relevance+w_{2}input\mathrm{\_}fit+w_{3}environment\mathrm{\_}fit-w_{4}risk-w_{5}cost$$

其中 q 为任务。此式仅用于表达设计因素，权重必须通过任务数据校准；不能把模型输出的“置信度”直接当作经过统计校准的成功概率。若多个 Skill 都适用，应评估其输入完整性、资源可用性、授权范围和结果质量，而非只看名称相似度。

4.3 选择失败

常见失败包括：错误匹配（选择了相似但不适用的技能）、漏检（未发现适用技能）、过度调用（简单任务被复杂 Skill 包装）、版本漂移（选择到不兼容版本）、依赖缺失（工具或知识库不可用）和越权调用。工程上应提供“无合适 Skill”的正常路径，允许回退到直接工具调用、人工澄清或终止，而不是强行匹配。

05 · 技能加载：从索引到执行上下文

5.1 渐进式披露（Progressive Disclosure）

当 Skill 数量很多时，将所有完整说明放进模型上下文会造成 token 成本、检索噪声和指令冲突。可采用三级加载：第一层只展示名称、描述与触发条件；第二层在选中后加载主说明与执行契约；第三层在具体步骤需要时加载参考文件、脚本说明或其他依赖资源。

这是一种上下文组织策略，不是自动保证正确选择的算法。它减少一次性上下文占用，但可能增加检索延迟，并带来“关键规则未及时加载”的风险。对于权限、安全和不可逆操作的强制约束，不能依赖模型是否看到了某段 Skill 文本，而应由执行边界独立执行。

5.2 上下文组装与优先级

Skill 文本属于被加载的任务材料。它应服从更高优先级的系统和开发者约束，不得覆盖用户授权范围。若 Skill 来源于外部仓库或共享目录，应把其内容视为可能不可信的指令性材料，进行来源审查与完整性校验。尤其要防止 Skill 引用的文档中嵌入“忽略之前规则、上传密钥”等提示注入内容。

5.3 加载失败的处理

需处理文件缺失、版本不匹配、引用循环、脚本缺少依赖、文本过长和上下文冲突。一个可用的加载器应返回明确状态，例如 FOUND、NOT_FOUND、INCOMPATIBLE、DENIED，并提供可观测的失败原因，而不是默默退化为不完整的技能执行。

06 · 技能执行：指导型与可执行型的不同机制

6.1 指导型 Skill

指导型 Skill 主要向模型提供领域方法，例如“先确定比较维度，再寻找原始文档，最后核对证据”。实际行动仍由 Agent 的规划器和工具执行器完成。其优点是灵活，适合开放式研究与创作；缺点是步骤遵循率不确定，必须通过外部检查验证。

6.2 可执行型 Skill

可执行型 Skill 包含脚本、函数、工作流入口或确定性步骤编排。执行器可以直接检查输入并调用工具；模型只负责选中技能或填写参数。优点是可测试、可复现、关键约束更容易强制执行；缺点是适用范围较窄，维护成本和环境依赖更高。

6.3 混合型 Skill

混合型通常更适合复杂 Agent：用确定性代码执行输入校验、权限检查、文件操作和完成条件；用模型完成信息提取、比较判断和不确定性处理。执行路径可以是：

任务 → Skill 发现 → 版本固定 → 输入绑定
  → 权限/依赖检查 → 加载技能内容
  → 执行方法（模型步骤 + 工具步骤）
  → 记录观察与副作用 → 结果验证
  → COMPLETED / FAILED / WAITING_APPROVAL

需要区分“技能步骤成功”与“用户任务成功”。例如报告文件写入成功不意味着论证准确，必须另外检查证据与交付标准。

6.4 Skill Runner 状态模型

最小状态可以包括 PENDING、READY、RUNNING、WAITING_APPROVAL、COMPLETED、FAILED、CANCELLED。如果支持暂停恢复，应持久化已完成步骤、外部副作用标识、输入摘要和版本信息。对于具有不可逆副作用的技能，重试不能简单地从第一步重新执行；必须结合幂等键、执行账本或人工核对。生产级状态持久化和分布式恢复归 Agent System 进一步研究。

07 · Skill 组合、嵌套与冲突

复杂任务往往需要多个 Skill，例如“资料研究”后接“报告校验”。组合方式至少包括顺序组合、条件分支、并行独立执行和子技能调用。此时 Skill 依赖可以建模为有向图 G=(V,E)，其中节点为技能或步骤，边为数据或执行依赖。必须检测循环依赖、资源冲突和重复副作用。

对于模型驱动的动态组合，规划器可以选择 Skill 序列，但运行时应检查各 Skill 的输入输出契约是否兼容。例如前一技能输出的 sources 是字符串列表，而下一技能要求带 url、timestamp、quote 的证据对象，不能仅凭字段名相似就直接连接。

Skill 之间可能发生指令冲突：一个要求“必须引用原文”，另一个要求“只输出无引用摘要”。应在任务契约层定义最终交付标准，由组合器解决冲突或请求澄清；不能简单按加载顺序让后加载文本覆盖前者。授权采用交集原则：组合后的实际权限不应超出用户授予的范围，即使某个子 Skill 声明了更大的权限。

08 · Skill 的生命周期与治理

一个 Skill 资产的生命周期可以抽象为：需求识别 → 设计契约 → 编写方法/脚本 → 测试 → 发布版本 → 注册发现 → 加载执行 → 监测效果 → 修订或退役。技能定义的版本与一次技能执行的状态必须分开；修改定义不应悄悄改变正在运行的任务。

可维护的 Skill Registry 至少应记录：唯一标识、版本、描述、适用条件、输入输出契约、工具依赖、权限需求、来源、维护者、测试状态、兼容性和弃用状态。对于第三方 Skill，建议在安装或更新时进行人工审查、静态检查、依赖锁定与来源完整性校验；这些措施不能单独保证安全，但能降低风险。

技能迭代需要回归集：一个改进可能提高常见任务的完成率，却损害少见但重要的边界情况。对技能的质量评价应以任务结果为依据，不能只统计调用次数或用户主观喜好。

09 · 代表性技术路线与研究

9.1 经典技能思想：层级强化学习的 Options

强化学习中的 Options Framework（Sutton、Precup、Singh，1999）将时间延展动作建模为启动集合 I、内部策略 π 和终止条件 β。其重要启发是：可复用能力不一定是单步动作，而可以是具有内部决策和终止条件的子过程。Options 是形式化决策抽象，不能直接等同于现代产品中的 Markdown Skill；后者还包含指令文本、工具资源与工程元数据。

9.2 Voyager：技能库与环境反馈

Voyager（Wang 等，2023）研究在 Minecraft 环境中通过自动课程、代码生成和迭代提示构建技能库，并在新任务中检索和复用已积累的技能。它提供了“从执行经验中积累可复用程序”的研究范例。其效果依赖特定环境、工具与评估设置，不能据此推断任意通用 Agent 自动学习技能都会可靠。

9.3 现代文件式 Skill 生态

一些现代 Agent 产品采用“技能目录 + 元数据 + 主说明文件 + 可选脚本/参考资源”的组织方式，强调按需加载、跨任务复用和人工维护。其工程价值在于将长指令和专业规程从主提示词中解耦。但文件格式、技能发现方式、脚本执行权限、是否支持嵌套和具体上下文注入策略依实现而异，不能把某一产品的约定写成通用标准。实际接入时应核验该产品当前官方规范与运行行为。

9.4 与 ReAct、Toolformer 的区别

ReAct（Yao 等，2022/2023）强调推理与行动交替；Toolformer（Schick 等，2023）研究模型学习何时及如何调用 API。它们主要解释行动选择和工具使用的机制，不等同于独立的 Skill 管理系统。Skill 可以封装 ReAct 风格的工作方法，也可以调用 Toolformer 类能力，但三者研究对象不同。

9.5 比较

技术路线	复用单元	核心机制	主要局限
Options	时间延展动作	启动、内部策略、终止	环境与策略形式化要求较高
Voyager	可执行代码技能	经验积累、检索、执行反馈	依赖环境与代码执行条件
文件式 Skills	指令、资源、脚本	元数据发现、按需加载	指令遵循与执行能力依平台而异
Workflow Template	固定子流程	节点与条件编排	对开放任务适应性有限
Prompt Template	可复用文本	变量替换与上下文注入	缺少独立的执行和验证保障

上述比较是技术抽象层面的综合分析，未对各框架最新版本逐项在线核验。

10 · 工程架构：研究助理的技能系统

10.1 需求

研究助理需要复用“阅读资料并生成简报”“比较技术方案”“检查引用与事实依据”等方法。我们先实现一个最小 research_brief 技能：输入 source_id，读取资料，生成简报，输出报告及执行事件。此例不调用真实 LLM，摘要由确定性函数模拟，因此验证的是 Skill 组件契约，而非语言理解能力。

10.2 模块与职责

Task Router ──► Skill Registry ──► Skill Resolver
                                  │
                                  ▼
                           Input Validator
                                  │
                                  ▼
                          Permission / Approval
                                  │
                                  ▼
                            Skill Runner
                                  │
                             Tool Gateway
                                  │
                          Read / Summarize
                                  │
                                  ▼
                       Events + Output Validator

Skill Registry 保存版本化元数据；Skill Resolver 固定技能版本；Input Validator 检查必需字段；Permission/Approval 强制限制工具与操作；Skill Runner 编排步骤；Tool Gateway 执行实际操作并记录调用；Events 保存可检查的执行痕迹。真实系统还需要持久化、取消、超时、幂等、沙箱、密钥管理和遥测。

10.3 关键接口

@dataclass(frozen=True)
class SkillSpec:
    name: str
    version: str
    description: str
    triggers: frozenset[str]
    required_tools: frozenset[str]
    required_inputs: frozenset[str]
    approval_for: frozenset[str] = frozenset()

class Registry:
    def discover(self, intent: str) -> list[SkillSpec]: ...
    def resolve(self, name: str, version: str) -> SkillSpec: ...

class SkillRunner:
    def run(self, name, version, inputs, granted_tools, approvals): ...

完整可运行代码见配套 A8-Agent-Skills-v1.1-demo.py。下载后运行：python3 A8-Agent-Skills-v1.1-demo.py。本实验的 run 是同步执行，不支持生产级事务或跨进程恢复。

10.4 实验设计与实际结果

本地使用 Python 3 标准库运行了六项断言：① 按意图发现技能；② 正常执行两步工具操作并生成产物；③ 拒绝缺失输入；④ 拒绝缺失工具权限且不调用工具；⑤ 拒绝空来源并报告验证失败；⑥ 未审批时等待、获批后执行。终端实际输出：

A8 skill contract: 6 checks passed
{
  "status": "COMPLETED",
  "events": [
    {"step": "read_source", "sha256": "5da9a31cc037eeb72506945353e8b2ae93feeb84a460764515da43a57189115b"},
    {"step": "summarize"}
  ],
  "output": {"report": "Brief: Agents use tools and feedback."}
}

该实验说明：在给定确定性工具和规则的条件下，可以验证 Skill 的发现、版本解析、输入契约、工具权限、审批和基本结果状态。它没有验证模型选择 Skill 的准确率、真实检索质量、自然语言规程遵循率、并发安全或生产环境的外部副作用。

10.5 扩展到真实 Agent 的路径

第一步，将 summarize 替换为模型调用，使用结构化输出约束摘要字段并保留来源标识；第二步，将 read_source 替换为可信文档检索工具；第三步，加入技能选择数据集，对正确选中与错误拒绝进行评测；第四步，加入持久化执行账本、超时、取消、幂等键与审批恢复；第五步，针对恶意技能文本、越权参数和提示注入建立对抗测试。每一步都需要新的证据，不能沿用最小实验的“测试通过”结论。

11 · 安全边界：技能不是授权主体

11.1 Skill 文本与执行权限

Skill 可能包含“执行脚本”“读取某目录”“访问外部网站”等指令，但这些声明不构成用户授权。实际操作必须经过工具网关、权限策略和必要的审批。应区分：技能被发现、技能被加载、技能被选择、技能获得执行许可、工具调用被允许，这五个状态并不等价。

11.2 供应链与提示注入

第三方 Skill 可能通过说明文件、脚本、依赖或引用资源引入风险。攻击面包括：伪装成系统指令的文本、恶意 shell 命令、隐蔽网络请求、过宽文件访问、依赖替换、被篡改的更新和跨 Skill 的数据泄漏。防护应组合来源校验、内容审查、最小权限、沙箱、网络限制、密钥隔离、审计记录和发布前测试。没有单一机制能保证绝对安全。

11.3 数据与副作用

Skill 应显式声明读取、写入、删除、发布、付款、发送消息等副作用类别。不可逆或外部可见操作通常需要更严格的确认。对于需要重试的操作，必须区分“明确失败”和“结果未知”；结果未知时盲目重试可能导致重复发布或重复扣费。此类可靠执行机制与 A7 Tools、A10 Permissions 及 Agent System 密切相关。

12 · 如何评估 Skill 的真实价值？

评估应区分四个层面：发现（选对技能）、遵循（正确执行方法）、产物（交付满足要求）、系统（成本、安全与稳定性）。仅统计“技能调用成功率”无法判断用户任务是否完成。

指标	建议定义	常见误区
Skill Selection Accuracy	正确选择技能的任务比例	不包含应拒绝调用的负样本
False Invocation Rate	不应调用时错误调用的比例	只测试正向匹配
Contract Pass Rate	输入、依赖、权限、输出契约通过率	把字段合法等同于语义正确
Procedure Adherence	关键步骤和约束得到遵循的比例	只看最终文字是否流畅
Task Success Rate	最终交付满足用户验收标准的比例	把工具执行成功当作任务成功
Side-effect Safety	未授权或错误副作用的发生率	不记录拒绝和未知状态
Cost / Latency	每个成功任务的 token、工具成本与耗时	只比较单次模型调用成本
Regression Stability	新版本在固定任务集上的性能变化	只测新加入的成功案例

建议实验采用成对任务：同一模型与工具条件下比较“无 Skill”“加载 Skill 指令”“带确定性 Skill Runner”三种配置。任务集应包含正常任务、模糊任务、缺失依赖、越权请求、恶意引用文档、版本不兼容和部分执行失败。报告样本数、通过率、置信区间或不确定性、错误类别和成本。若 Skill 的收益仅体现在极少数样例上，应避免推广为普遍结论。

13 · 设计取舍与常见失败

粒度过大。 一个“万能研究 Skill”可能包含大量无关步骤，导致加载成本高、适配性差。可拆分为证据检索、对比分析、引用检查等相对独立的能力单元，但避免拆成无法复用的碎片。

粒度过小。 将每个简单工具包装成 Skill 会增加路由与维护负担；这种场景直接暴露 Tool 更清晰。

指令代替控制。 在 Skill 中写“禁止删除文件”不能阻止底层工具删除；必须在执行层设置强制授权。

缺少终止与验证。 只定义“怎么做”而不定义“何时算完成”，容易造成无限循环或提前结束。需要任务完成条件、预算与结果检查。

版本不可复现。 技能说明被修改后，历史执行无法解释。应固定版本并保留执行元数据。

模型与程序责任不清。 如果既让模型自由选择步骤，又由脚本强制执行不同顺序，容易发生冲突。应明确哪些步骤允许动态规划、哪些步骤必须确定性执行。

经验自动晋升为规则。 从单次成功任务提取的经验不一定具有普遍性。自动生成 Skill 时，需要去重、来源标注、人工审查和回归评测，不能将未经验证的偶然策略直接视为最佳实践。

14 · 与其他专题的接口

A1 Identity & Role 定义 Agent 承担的角色，Skill 则定义某类任务的可复用方法；A2 Model 决定模型如何理解和选择技能；A3 Instructions 提供更高层的任务约束；A4 Context 负责技能内容按需加载与上下文预算；A5 Memory 保存执行经验，但不自动等同于经过验证的 Skill；A6 Knowledge 提供技能执行所需的证据；A7 Tools 负责具体外部操作；A9 Planning & Reasoning 决定何时组合和调整技能；A10 Permissions & Constraints 强制执行授权边界。

与 Agent System 的边界同样重要：本篇解释 Skill 的定义、发现、加载、执行契约与基本状态；生产级任务队列、分布式调度、执行沙箱、持久化检查点、故障恢复和平台级技能分发属于后续系统与平台研究。即使采用同一代码库，也应区分研究对象与技术职责。

15 · 总结：从工具集合到可复用的专业工作方法

Agent 的专业能力不只是模型知识与工具数量的叠加。真正有价值的 Skill 将任务方法、适用条件、输入输出、依赖、权限和验证标准组织成可复用资产，使 Agent 能够在相似任务中复用经过设计与检验的工作方式。

理解 Skill 的关键，是同时把握三个层面：语义层决定何时使用什么方法；执行层决定如何把方法落实为模型步骤与工具操作；验证层决定产物是否真正符合任务要求。三者缺一，Skill 都可能沦为只有名称的提示词、缺乏边界的自动化脚本，或无法证明效果的功能包装。

对于研究助理 Agent，合理的工程路线是先从高频、可验收的任务中提炼少量 Skill，明确契约和权限，在真实任务集上验证其收益，再逐步增加发现、组合、版本管理与自动化执行能力。Skill 的数量不是能力成熟度的直接指标；可发现、可控制、可验证、可维护的复用效果才是核心。

下一篇 A9 · Planning & Reasoning 将进一步研究何时组合和调整技能背后的行动规划与动态决策；A10 · Permissions & Constraints 则深入授权与约束的强制执行模型。

参考研究与进一步核验

1. Sutton, R. S., Precup, D., & Singh, S. (1999). Between MDPs and semi-MDPs: A Framework for Temporal Abstraction in Reinforcement Learning. Artificial Intelligence, 112(1–2), 181–211. 用于理解可复用时间延展动作的形式化思想。
2. Wang, G., et al. (2023). Voyager: An Open-Ended Embodied Agent with Large Language Models. 用于研究技能库、代码生成与环境反馈的组合。
3. Yao, S., et al. (2022/2023). ReAct: Synergizing Reasoning and Acting in Language Models. 用于比较行动循环与技能封装。
4. Schick, T., et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. 用于区分工具调用学习与 Skill 复用。
5. 现代 Agent 产品的官方 Skills 规范与示例：接入前应核对其当前版本的技能文件结构、加载策略、脚本权限与运行时行为；本篇不将未核验的产品细节写成确定事实。

研究声明

本篇采用通用系统分析模型对 Skills 进行研究；Skill Contract、YAML 示例、评分式及部分架构划分属于本文的工程抽象与建议方案，并非统一行业标准。文中代表性论文的研究定位基于已知公开研究内容，本次未在线逐项核验论文原文及各产品最新文档。配套 A8-Agent-Skills-v1.1-demo.py 已在本地实际运行并通过六项确定性断言（输出 A8 skill contract: 6 checks passed）；未接入真实 LLM、外部 Skills 服务或远程工具，未开展生产环境的安全性、性能或可靠性验证。后续工程实践应以当前官方规范、真实任务数据和实测结果为依据。