能力体系（Capabilities）

**能力（Capability）**是 Sigil 暴露给 AI 客户端的"动作单元"。每个能力背后是一段 Rust 代码或一个 HTTP 模板，它知道如何使用某种凭据完成某类操作。

心智模型

AI 客户端           Sigil                  目标服务
   │                  │                      │
   │ 我要 git push    │                      │
   ├─────────────────►│                      │
   │                  │ 找到 git_push 能力   │
   │                  │ 查找 github_token    │
   │                  │ 注入 Authorization   │
   │                  ├─────────────────────►│
   │                  │                      │ 执行 push
   │                  │◄─────────────────────│
   │                  │ 脱敏响应             │
   │◄─────────────────│                      │
   │ push 成功        │                      │

能力是"凭据 + 操作"的桥。AI 知道"有哪些操作可以请求"，但不知道具体哪条凭据被用、不知道凭据明文。

内置能力清单

当前约 160 个内置能力。但你和 AI 实际看到的通常更少 —— 工具列表会按金库里 存了哪些凭据动态收缩，详见 MCP Server · 按凭据渐进披露。

按用途分组如下，每组都有独立章节讲细节：

分组	数量	做什么	详见
Git 多平台（远端）	22	一套工具通吃 GitHub / Gitee / GitCode：仓库、issue、PR、release	Git 平台能力
GitHub 专属	33	Actions / CI、Release、Secrets 与变量、分支保护、协作者	Git 平台能力
GitLab	24	独立一组，支持自建实例	Git 平台能力
本地工作区	18	暂存、提交、分支、diff、fetch / pull / push	Git 工作区
Git 本地	2	`git_clone` / `git_push`	Git 平台能力
对象存储	11	R2 / S3 兼容桶的增删查，腾讯云 COS 用量与访问日志分析	对象存储
加密分享 / 文件加密	8	打加密分享包、单文件加密、收件人管理	加密分享包
Maven Central	6	发布身份托管、部署状态、正式发布	发布与签名
MQTT / 物联网	5	设备状态、历史、发布消息	MQTT 设备监控
代码签名	4	签名资产导入、灌 CI Secrets、本地落地	发布与签名
邮件	4	收信、搜索、读信、代发	邮件
密码管理	4	密码检索、复制到剪贴板、TOTP 动态码	密码与两步验证
安全管家	3	凭据健康检查、用量统计、策略校验	凭据金库
元工具 / 自省	9	列凭据、列能力、查审计 —— AI 用来「看看自己能干什么」	审计日志
系统级	4	应用信息、Token 列表、外部客户端、Kill Switch 状态	—
HTTP 代理	1	`http_request`：自由拼 URL，调用范围最大	见下方「自定义 HTTP 模板」

不确定当前有哪些能力，别猜

让 AI 调 list_capabilities 自省，或在桌面端「能力」页看 —— 那才是当前真实生效的清单。本页表格是按分组给的概览，具体能力名随版本演进。

元工具值得单独说一句

list_capabilities / list_credentials / credentials_for_capability 这几个是给 AI 「认路」用的。AI 接进来第一件事通常是问「我能干什么、有哪些凭据可用」—— 有了这几个工具，它就不用靠猜工具名去试错。

它们返回的全是元信息：凭据的名称、类型、账号、备注，没有任何明文。

自定义 HTTP 模板

Sigil 内置能力覆盖了 80% 通用场景，剩下 20% 通常是"调用我们公司内部 API"——为此提供 HTTP 模板机制，无需写一行 Rust。

一个例子

公司内部对账系统有个接口 POST https://billing.acme.internal/api/refund，需要 X-Service-Token 头鉴权。

在 Sigil → 能力 → 新增 HTTP 模板：

名称：    refund-acme
方法：    POST
URL：     https://billing.acme.internal/api/refund
Headers：
  X-Service-Token: ${cred:acme-internal-svc.value}
  Content-Type: application/json
Body：
  {
    "order_id": "${input:order_id}",
    "reason":   "${input:reason}",
    "operator": "${meta:caller}"
  }
默认凭据：acme-internal-svc
范围：    白名单客户端

占位符语法：

占位符	含义
`${cred:<name>.<field>}`	引用金库里某条凭据的某字段
`${input:<name>}`	调用方传入的参数
`${meta:caller}`	当前调用方的 Token 名（用于审计追溯）
`${meta:now}`	当前 ISO 时间戳

保存后，这条 HTTP 模板就出现在 Claude / Cursor 的工具列表里，叫做 refund-acme。AI 可以像调内置能力一样调它，全程不知道 acme-internal-svc 的明文 Token。

占位符替换时机

客户端发起请求
Sigil 校验白名单 + Scope Policy
解密 acme-internal-svc → 拿到明文 Token
替换所有 ${cred:...} 占位符
真的发起 HTTP 请求
响应回来后，把所有可能的凭据明文用 [REDACTED:xxx] 占位
返回给客户端

明文只在第 4-5 步之间出现在内存里（< 1 ms），用完立刻清零。

三档确认

内置能力的确认级别由 Sigil 集中判定，用户在界面上改不了单个内置能力的确认开关 —— 这是有意的：能不能绕过确认，不该是一个可以被顺手点掉的选项。

档	什么时候	表现
阻塞式确认	不可逆 / 破坏性 / 安全态变更 / 明文外发	弹独立审批窗，执行前等你决定，超时按拒绝
非阻塞通知	其余改动型（提交、普通推送、建 issue…）	右下角弹一条提示，不打断，可回看
静默	只读	不打扰，只进审计

阻塞档覆盖的动作包括：删仓库 / 删 release / 删分支 / 清空仓库、强制推送、删除对象存储里的对象、分支保护与协作者等放权动作、发布到 Maven Central、把明文凭据复制到剪贴板或落到磁盘、代发邮件、往 MQTT 发消息、打加密分享包。

弹窗里写的是人话，不是 JSON

审批窗展示的是动作摘要：动词、风险等级、一句话后果、打的是哪个目标、几个关键字段。

┌──────────────────────────────────────────┐
│  发送邮件                         🔴 高危 │
│  邮件一旦发出无法撤回，收件人会立刻收到   │
│                                          │
│  目标：  alice@example.com               │
│  主题：  发布通知                        │
│  正文开头： 各位，v1.8.0 已经…            │
└──────────────────────────────────────────┘

你在那二十秒里真正要核对的就是「打的是哪个目标、内容是什么」—— 所以摘要把这两条放在最显眼处，而不是让你从一坨参数里自己找。

「本会话不再询问」有边界

批准时可以选「本会话不再询问」或「N 分钟内不再询问」，省得连着做同类操作时反复点。

但有一类能力刻意不提供这个按钮：每次调用打的目标都不一样、且后果不可撤回的那些 —— 任意 URL 的 HTTP 请求、代发邮件、MQTT 发布、删仓库、明文凭据外发。

对它们来说，「批准一次」记下的是「以后对任何目标都不用问」，这和你当时同意的完全不是一回事。这类操作要连着做很多次，就逐次确认 —— 逐次确认正是它们唯一的安全边界。

能力注解（readOnlyHint / destructiveHint）

每个能力在 tools/list 里都带 MCP 行为注解，供客户端做分级审批：

注解	含义	客户端典型行为
`readOnlyHint: true`	只读、无副作用（各 `*_list` / 自省类）	可免二次确认、失败可安全重试
`destructiveHint: true`	破坏性（删除 / 覆盖 / 不可逆，如删分支、强制推送、取消 run）	强确认

注解是给客户端的 UX 提示，不是安全保证 —— 真正的拦截在 Sigil 这一侧。

防误删的硬校验

有些动作光靠弹窗还不够，因为人也会顺手点确认。这几个加了参数级校验：

删仓库：调用方必须把确认字段填成与仓库全名完全一致的字符串，否则直接拒绝。防的是模型一次幻觉就把整个仓库删掉。
建仓库：一律私有，入参覆盖不了。需要公开仓请去平台网页端手动改。
强制推送：不开放裸的强制覆盖，内部一律走带安全基准的方式 —— 远端被别人改动过就拒绝执行，而不是盖掉。

AI Kill Switch

Sigil 状态栏右下角有一个红色拨杆——禁用所有 AI 能力执行。

启用后：

MCP Server 仍在监听，但所有能力调用立即返回 kill_switch_active
金库 UI 仍可正常使用（人能看、能管理）
审计日志记录"Kill Switch 期间被拦截 N 次"

适用场景：

上线敏感时段（不希望任何代理执行）
应急响应（怀疑某个 Token 泄漏，先全停再排查）
合规审查窗口

下一步

了解 MCP Server 的协议细节：MCP Server →
了解能力调用的安全模型：AI 使用边界 →

能力体系（Capabilities） ​

心智模型 ​

内置能力清单 ​

元工具值得单独说一句 ​

自定义 HTTP 模板 ​

一个例子 ​

占位符替换时机 ​

三档确认 ​

弹窗里写的是人话，不是 JSON ​

「本会话不再询问」有边界 ​

能力注解（readOnlyHint / destructiveHint） ​

防误删的硬校验 ​

AI Kill Switch ​

下一步 ​