spec v0.1
ZH

Skill

示例 Skill

六个智能体 Skill，用于创建、控制和审计 MCP 服务器——本身按照 MCP-first 规则构建。

Skill 是封装好的 Workflow——MCP-first 系统的第三个构建块（Prompt / Workflow）。 它引导智能体完成多步骤流程，无需点击任何界面。

以下示例 Skill 服务于 MCP 服务器本身：创建、控制和审计。 关键在于：这些 Skill 遵守它们所执行的同一套规则。 每个风险步骤都标注了风险等级，写入和关键步骤都位于确认门 （Confirmation Gate）之后，每个操作都会生成审计事件。

创建

mcp.scaffold_server
High

引导构建一个以 Capability 为核心的 MCP 服务器：优先建立领域 Action，使用类型化 Schema，配置 Policy 引擎、风险元数据和审计——在任何界面出现之前。

trigger "为……创建一个 MCP 服务器" 创建

Ablauf

  1. 建模领域 Action——业务逻辑保留在领域层，而非服务器中。 Low
  2. 为每个 Action 生成类型化的输入、输出和错误 Schema。 Low
  3. 为每个 Tool 分配风险等级和 Confirmation Policy。 Medium
  4. 接入 Policy 引擎（can(user, action, resource, context)）和审计事件。 Medium
  5. 将服务器生成为适配器：Discovery、Schema 暴露、Policy 检查、审计日志。 High
  6. 仅在明确批准后注册写入和关键 Tool。 Critical ⏸ Freigabe

Hält sich an

  • Capability 优先于界面——先定义能力，不做 UI 假设。
  • 类型化的输入输出——不使用松散 JSON。
  • Policy 优先于信任——每个 Capability 都有权限和风险。
  • 审计优先于不透明——每个操作生成审计事件。
capability.add
High

按照 Tool Contract 标准添加新 Capability。没有完整合约，不进行注册。

trigger "为……添加一个 Tool / Resource" 创建

Ablauf

  1. 明确用户意图和类别；检查是否有现有 Capability 可作模板。 Low
  2. 定义输入/输出/错误 Schema 和所需 Scope。 Low
  3. 确定风险等级、副作用和审计事件。 Medium
  4. 确定 Confirmation Policy（自主、确认、Step-up、四眼原则、不允许 AI）。 Medium
  5. 为高风险 Tool 提供 Dry-Run 模式。 Medium
  6. 注册 Capability 并在 Discovery 中启用。 High ⏸ Freigabe

Hält sich an

  • Tool 优先于按钮——每个 Capability 一份统一合约。
  • 确认优先于盲目自动化——注册前先制定 Policy。
  • 为高风险操作提供 Dry Run。

控制

mcp.control_visibility
High

按用户、Client、Tenant、角色和 Scope 控制 Tool 可见性——在 Discovery 阶段即生效，而非在调用时。

trigger "智能体 X 可以看到哪些 Tool？" 控制

Ablauf

  1. 解析身份和上下文：User、MCP Client、Agent Identity、Tenant。 Low
  2. 计算有效权限（User + Agent + Client 信任级别 + Resource 敏感度）。 Low
  3. 将 Tool 列表过滤为允许的 Capability；锁定的 Tool 根本不下发。 Medium
  4. 按角色调整 Confirmation Policy。 High ⏸ Freigabe

Hält sich an

  • Tool 可见性按权限——在 Discovery 时过滤。
  • 上下文而非原始数据——只提供智能体所需的内容。
  • Policy 优先于信任。
mcp.connect_client
Critical

以受控方式接入 MCP Client：OAuth 2.1 授权码 + PKCE、白名单、短期 Token、Refresh 轮换。

trigger "将 Client … 连接到 MCP 服务器" 控制

Ablauf

  1. 对照白名单验证 Client；校验 Redirect URI。 Medium
  2. 配置 OAuth 2.1 + PKCE，设置短期 Access Token 有效期。 High
  3. 授予最小 Scope（最小权限原则），启用 Refresh 轮换。 High
  4. 激活 Client——需要管理员 Step-up Auth。 Critical ⏸ Freigabe

Hält sich an

  • 人类 UI / Client 作为 Client——核心仍是 Capability Layer。
  • 关键操作需要 Step-up Authentication。
  • 审计优先于不透明——Client 激活会被审计。

审计

mcp.audit_trail
Low

只读审查：读取审计轨迹和风险覆盖情况，执行 MCP-first 检查表并报告缺口。不修改任何内容。

trigger "对照 MCP-first 检查 MCP 服务器" 审计

Ablauf

  1. 读取 Capability 清单及其风险等级。 Low
  2. 检查审计事件的完整性和敏感输入的脱敏情况。 Low
  3. 标记没有风险分类或 Confirmation Policy 的 Tool。 Low
  4. 对比 Forbidden for AI Capability 与实际可见性。 Low
  5. 以结构化报告输出结果——无写入操作。 Low

Hält sich an

  • 审计优先于不透明——每个操作可追溯。
  • 100% 可控，而非 100% 自主——审计本身不修改任何内容。
  • 上下文而非原始数据——报告而非数据库转储。
mcp.harden_security
Critical

检查并提升防护：保护等级、Step-up 覆盖范围、脱敏、速率限制和 Prompt 注入防护。变更需要批准。

trigger "加固 MCP 服务器安全性" 审计

Ablauf

  1. 检查每个 Resource / Tool 的敏感区域和保护等级。 Low
  2. 验证关键 Tool 的 Step-up Auth；提议缺失的配置。 Medium
  3. 检查 AI 访问的脱敏规则和上下文过滤。 Medium
  4. 评估速率限制和 Prompt 注入防护。 High
  5. 应用 Policy 变更——需要管理员批准（四眼原则）。 Critical ⏸ Freigabe

Hält sich an

  • Policy 优先于信任——AI 受控制，而非被信任。
  • 确认优先于盲目自动化——Policy 变更需要批准。
  • 上下文而非原始数据——对敏感数据进行脱敏。

Build capabilities once. Expose them everywhere — 也包括运营服务器本身的 Skill。

Skill 即 Workflow