# CCP v0.1 — 能力通约协议规范

> **协议全称**：Capability Commensurability Protocol（能力通约协议）
> **版本**：v0.1（草案）
> **日期**：2026-08-28
> **状态**：社区提案阶段
> **协议标识**：CCP

---

## 零、导言：为什么需要 CCP

当前 AI 能力生态面临三重名实乖离：

1. **"插件"之名遮蔽了"能力通约"之实**：以"可安装的代码包"定义插件，混淆了分发形态与能力本质。
2. **"工具声明"之名遮蔽了"认知能力"之实**：Agent 需要的不是"调用 parse_pdf"这个操作，而是"理解 PDF 内容"这个认知结果。
3. **"发布者身份"之名遮蔽了"能力可信度"之实**：调用方不关心能力来自谁，只关心能力是否可靠、是否可用。

CCP 协议将这三重误认消解，将"插件"重构为"能力锚点"——一个使异构系统间能力请求与能力执行得以对接的最小通约协议。

**核心原则**：协议优先于平台。CCP 本身是公共基础设施，不绑定任何特定实现、平台或分发渠道。

---

## 一、能力锚点（Capability Anchor）Schema

能力锚点是 CCP 协议的基本操作单元。它不包含代码、不包含安装脚本、不包含运行时环境——只包含让调用方能够**发现、评估、调用**该能力所需的最小元数据集。

### 1.1 必填字段

| 字段           | 类型           | 说明                                | 示例                                                         |
| -------------- | -------------- | ----------------------------------- | ------------------------------------------------------------ |
| `id`           | `string`       | 全局唯一标识符，格式 `{name}-{seq}` | `"pdf-extract-text-001"`                                     |
| `name`         | `string`       | 中文能力名称                        | `"PDF文本提取"`                                              |
| `name_en`      | `string`       | 英文能力名称                        | `"PDF Text Extraction"`                                      |
| `desc`         | `string`       | 中文能力描述（自然语言）            | `"从PDF文件中提取全部文本内容，保留段落结构"`                |
| `desc_en`      | `string`       | 英文能力描述                        | `"Extract all text from PDF files..."`                       |
| `input`        | `string`       | 中文输入参数说明                    | `"PDF文件URL或本地路径"`                                     |
| `input_en`     | `string`       | 英文输入参数说明                    | `"PDF file URL or local path"`                               |
| `output`       | `string`       | 中文输出承诺说明                    | `"结构化文本字符串，包含页码映射"`                           |
| `output_en`    | `string`       | 英文输出承诺说明                    | `"Structured text string with page mapping"`                 |
| `endpoint`     | `string`       | 调用端点 URI                        | `"mcp://pymupdf-server/extract-text"`                        |
| `endpointType` | `enum`         | 调用方式类型                        | `"http"` / `"mcp"` / `"command"` / `"prompt"` / `"workflow"` |
| `category`     | `enum`         | 能力分类                            | `"ai"` / `"data"` / `"media"` / `"language"` / `"dev"`       |
| `provenance`   | `string` (URL) | 源码/项目来源链接                   | `"https://github.com/pymupdf/PyMuPDF"`                       |

### 1.2 信任向量字段（L1）

信任向量是 CCP 区别于传统"星级评分"的核心创新。它采用多维向量替代单一分数，允许调用方根据自身需求对不同维度赋予不同权重。

| 字段             | 类型                | 说明                                       | 范围           |
| ---------------- | ------------------- | ------------------------------------------ | -------------- |
| `trustSource`    | `float`             | 源码可验证性：声明是否可追溯到源码         | 0-1            |
| `trustUsage`     | `integer`           | 使用痕迹：原始调用次数                     | >=0            |
| `trustUsageRate` | `float`             | 使用痕迹归一化评分                         | 0-1            |
| `trustSuccess`   | `float`             | 成功率：历史调用成功率                     | 0-1            |
| `trustRisk`      | `float`             | 依赖风险：依赖链复杂度与健康度（越低越好） | 0-1            |
| `trustTime`      | `float`             | 时效性：能力数据的时效性（越高越新）       | 0-1            |
| `lastUpdated`    | `string` (ISO date) | 最后验证/更新日期                          | `"2026-08-20"` |

### 1.3 证据层字段（L2）

基于 Josang 主观逻辑理论，单一信任分数混淆"基于 3 次调用的 100% 成功率"与"基于 1 万次调用的 97% 成功率"。L2 证据层显式建模证据量 n 与不确定性 u。

| 字段                   | 类型      | 说明                        | 范围 |
| ---------------------- | --------- | --------------------------- | ---- |
| `evidence.count`       | `integer` | 证据量 n：累计调用/验证次数 | >=0  |
| `evidence.uncertainty` | `float`   | 不确定性 u：n 越大 u 越小   | 0-1  |

**不确定性计算参考公式**：`u ≈ 1 / (1 + log10(count))`

### 1.4 可选字段

| 字段            | 类型       | 说明                                           |
| --------------- | ---------- | ---------------------------------------------- |
| `features`      | `string[]` | 中文功能特性列表                               |
| `features_en`   | `string[]` | 英文功能特性列表                               |
| `usageGuide`    | `string`   | 中文使用说明                                   |
| `usageGuide_en` | `string`   | 英文使用说明                                   |
| `codeExample`   | `string`   | 调用代码示例（JSON 格式）                      |
| `tags`          | `string[]` | 语义标签（用于分类和检索）                     |
| `dependencies`  | `string[]` | 依赖的其他能力锚点 ID                          |
| `version`       | `string`   | 能力版本号（SemVer）                           |
| `status`        | `enum`     | `"active"` / `"deprecated"` / `"experimental"` |

---

## 二、CCP 三大操作

### 2.1 发现（Discover）

调用方通过自然语言描述或结构化查询，检索匹配的能力锚点。

**检索模式**：

- **关键词匹配**：对 `name`、`desc`、`id`、`category`、`endpointType` 字段执行大小写不敏感的模糊匹配。
- **语义检索**：对 `name`、`desc` 字段生成文本嵌入向量，计算查询向量与锚点向量的余弦相似度。
- **分类过滤**：按 `category` 字段精确筛选。

**排序规则**：

- 默认按综合信任分降序排列。
- 综合信任分 = 五维信任向量加权求和 × (1 - 不确定性惩罚因子)。

**综合信任分计算**：

```
信任权重分配（基于 DCI 论文 AHP 实证）：
  source: 0.25（源码可验证性）
  usage:  0.15（使用痕迹）
  success: 0.30（成功率，最高权重）
  risk:   0.15（依赖风险，1-riskScore）
  time:   0.15（时效性）

综合信任分 = (w_source × trustSource + w_usage × usageRate + w_success × trustSuccess + w_risk × (1-trustRisk) + w_time × timeScore) × (1 - uncertainty × 0.5)
```

### 2.2 评估（Evaluate）

调用方获取能力锚点的完整信任向量和证据层数据，进行自主风险评估。

**评估维度**：

- 五维信任向量（L1）：直观展示各维度信任水平。
- 证据层（L2）：展示证据量和不确定性，区分"高置信度"与"低置信度"的高分。
- 新能力标记：`evidence.count < 100` 的能力标注"新能力"徽标，提醒调用方证据不足。

### 2.3 调用（Invoke）

调用方通过 `endpoint` 字段获取调用端点，通过 `endpointType` 判断调用方式，按 `input` 字段构造请求，按 `output` 字段解析响应。

**调用方式类型**：

| 类型       | 说明          | 端点格式                         |
| ---------- | ------------- | -------------------------------- |
| `http`     | HTTP REST API | `https://api.example.com/v1/...` |
| `mcp`      | MCP 协议      | `mcp://server-name/method`       |
| `command`  | 命令行工具    | `command://tool-name --arg`      |
| `prompt`   | 提示词协议    | `prompt://action?param={value}`  |
| `workflow` | 工作流编排    | `workflow://pipeline/name`       |

---

## 三、CCP 第四操作：路由（Route）

> **新增于 v0.1.1** · 基于"调用路由层"论证

### 3.0 为什么需要"路由"操作

CCP 协议的边界原则是"通约层不执行代码"。但这带来了一个体验断层：用户从"发现"到"评估"到"调用"，在"调用"这一步被踢出 SkillMesh，需要自己翻文档、拼参数、写代码。**"路由"操作填补这个断层**——它不执行能力，而是帮用户**生成通往执行层的路径**。

**名实学定位**：路由操作是"能力锚点之名"与"调用执行之实"之间的通约桥梁。它不侵入执行层，但将执行层的入口标准化、可操作化。

### 3.1 路由操作的职责边界

| 路由层做什么                                   | 路由层不做什么           |
| ---------------------------------------------- | ------------------------ |
| 根据 `endpointType` 生成对应调用代码片段       | 托管代码或执行调用       |
| 为 HTTP 类型能力提供浏览器端 API 试用          | 管理运行时依赖或沙箱环境 |
| 生成 Agent 框架适配器配置（MCP/DSH/LangChain） | 安装 npm/pip 包          |
| 构造带认证信息的请求模板                       | 存储或代理 API 密钥      |
| 将多个能力锚点串联为调用工作流草稿             | 执行工作流或管理状态     |

### 3.2 路由操作的五种模式

#### 模式 1：代码生成（Code Generation）

根据 `endpointType` 和 `input`/`output` 字段，自动生成可执行的调用代码。

| endpointType | 生成内容                                    | 示例                                                                       |
| ------------ | ------------------------------------------- | -------------------------------------------------------------------------- |
| `http`       | cURL / fetch / Python requests / 各语言 SDK | `curl -X POST {endpoint} -H 'Content-Type: application/json' -d '{input}'` |
| `mcp`        | MCP 客户端配置 JSON                         | `{ "mcpServers": { "pdf-extract": { "url": "..." } } }`                    |
| `command`    | 终端命令 + 参数说明                         | `tool-name --arg1 value1 --arg2 value2`                                    |
| `prompt`     | 提示词模板                                  | 基于 `input` 字段填充的完整 Prompt                                         |
| `workflow`   | 工作流 DSL 草稿                             | YAML/JSON 格式的编排描述                                                   |

**生成策略**：每个能力锚点的 `codeExample` 字段优先使用；若无，则根据 Schema 自动构造。

#### 模式 2：浏览器端试用（Browser Try-It）

仅对 `endpointType === "http"` 的能力锚点开放。用户在 SkillMesh 页面内直接发起 HTTP 请求，查看返回结果。

**约束条件**：

- 仅支持 GET/POST 方法，且目标 API 必须支持 CORS（或通过 Cloudflare Worker 代理）
- 每次试用自动递增 `evidence.count`（前端本地计数，非权威）
- 试用结果不持久化存储，刷新即丢失
- 敏感参数（API Key 等）由用户手动填入，SkillMesh 不存储

**实现原理**：

```
用户点击"试用"
  → SkillMesh 解析 endpoint + input schema
  → 生成参数填写表单
  → 用户填写参数 + 可选认证信息
  → 浏览器 fetch() 发起请求
  → 展示响应（状态码、响应体、耗时）
  → 本地递增 evidence.count
```

#### 模式 3：Agent 适配器配置（Agent Adapter）

为不同 Agent 框架生成能力锚点的接入配置。

| 框架                 | 适配器格式              | 说明                                |
| -------------------- | ----------------------- | ----------------------------------- |
| **DeepSeek-Harness** | `dsh.bundle.patch` YAML | 将能力锚点转为 DSH 可安装的插件声明 |
| **MCP 客户端**       | `mcp.json`              | 标准 MCP 服务器配置                 |
| **LangChain**        | Tool 定义 JSON          | 将能力锚点映射为 LangChain Tool     |
| **CrewAI**           | Tool Schema             | 将能力锚点映射为 CrewAI Tool        |
| **Dify**             | 工具配置 YAML           | 将能力锚点映射为 Dify 自定义工具    |

#### 模式 4：一键复制（Copy-to-Clipboard）

将端点 URL、参数模板、认证方式组合为一行可复制的命令或代码片段，用户粘贴到自己的终端/IDE 中执行。

#### 模式 5：能力组合编排（Capability Orchestration）

将多个能力锚点按工作流逻辑串联，生成调用序列草稿：

```
A 的输出 → 转换 → B 的输入 → C 的输入
```

输出为 CCP 工作流描述 JSON，供外部编排引擎（如 Dify、Temporal）消费。

### 3.3 路由操作的数据流

```
┌─────────────────────────────────────────────────────┐
│                    CCP 通约层                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │ 发现     │  │ 评估     │  │ 调用（协议定义）  │  │
│  │ Discover │  │ Evaluate │  │ Invoke (Schema)  │  │
│  └──────────┘  └──────────┘  └────────┬─────────┘  │
│                                       │             │
│                          ┌────────────▼──────────┐  │
│                          │ 路由（新增）           │  │
│                          │ Route                  │  │
│                          │ ┌───────────────────┐  │  │
│                          │ │ 代码生成           │  │  │
│                          │ │ 浏览器试用         │  │  │
│                          │ │ Agent 适配器       │  │  │
│                          │ │ 一键复制           │  │  │
│                          │ │ 能力组合编排       │  │  │
│                          │ └───────────────────┘  │  │
│                          └────────────┬──────────┘  │
└───────────────────────────────────────┼─────────────┘
                                        │
                         ┌──────────────▼──────────────┐
                         │        执行层（外部）        │
                         │  ┌────────┐  ┌───────────┐  │
                         │  │ 浏览器 │  │ Agent     │  │
                         │  │ fetch  │  │ 框架      │  │
                         │  └────────┘  └───────────┘  │
                         │  ┌────────┐  ┌───────────┐  │
                         │  │ 终端   │  │ 工作流    │  │
                         │  │ CLI    │  │ 引擎      │  │
                         │  └────────┘  └───────────┘  │
                         └─────────────────────────────┘
```

---

## 四、通约层与分发层分离原则

CCP 协议严格区分三个层次：

### 4.1 通约层（CCP 职责范围）

- 定义能力锚点的元数据 Schema。
- 定义能力锚点的发现、评估、调用协议。
- 定义信任向量的计算方法和证据层标准。
- 维护能力锚点索引（不包含代码）。

### 4.2 路由层（CCP 路由职责范围）

- 生成调用代码片段（cURL、fetch、Python、MCP 配置等）。
- 提供浏览器端 API 试用（HTTP 类型能力）。
- 生成 Agent 框架适配器配置（DSH、MCP、LangChain、CrewAI、Dify）。
- 提供一键复制调用指令。
- 生成能力组合编排草稿。

### 4.3 分发层（不在 CCP 职责范围）

- 代码托管与分发（npm、PyPI、GitHub Releases）。
- 运行时环境管理（Docker、沙箱、Serverless）。
- 安装与配置管理。
- 计费与授权。

**分离理由**：通约层关注"能力是什么、如何调用、是否可信"，分发层关注"代码在哪里、如何安装、如何运行"。将两者分离，使得：

- 同一个能力锚点可以对应多个分发实现（一个 PDF 提取能力，可以有 PyMuPDF 实现，也可以有 pdfplumber 实现）。
- 分发层的变更不影响通约层的索引（代码迁移、版本升级不影响能力锚点的"发现"能力）。
- 通约层可以索引任何形式的能力，不限于"可安装的软件包"（人工服务、API 服务、甚至物理设备都可以注册为能力锚点）。

---

## 五、数据格式与存储

### 5.1 数据格式

能力锚点数据以 JSON 数组形式存储，每个元素为符合上述 Schema 的 JSON 对象。

```javascript
const CAPABILITIES = [
  {
    id: "pdf-extract-text-001",
    name: "PDF文本提取",
    name_en: "PDF Text Extraction",
    // ... 其余字段
  },
];
```

### 5.2 存储策略

- **当前阶段**：静态 JSON 文件（`js/data.js`），随仓库一起版本管理。
- **下一阶段**：迁移至 Cloudflare D1（边缘 SQLite），支持 FTS5 全文搜索。
- **远期**：支持联邦化索引——多个 CCP 节点可以互相发现和交换能力锚点索引。

---

## 六、协议演进

### 6.1 版本策略

- **v0.1**（当前）：草案阶段，Schema 字段可能调整。
- **v0.5**：冻结 Schema，开始社区征集能力锚点。
- **v1.0**：正式发布，Schema 向后兼容。

### 6.2 贡献方式

- 能力锚点提交：通过 GitHub Issue 模板或 Pull Request 提交。
- 协议修改：通过 GitHub Discussion 发起提案，经社区讨论后由维护者合入。
- 实现参考：本项目 `index.html` + `js/` 为 CCP 协议的参考实现。

### 6.3 名实学治理原则

CCP 协议的演进遵循名实学三大定律：

1. **定律五（名实共振律）**：协议 Schema 的变更必须与社区实际需求保持共振，避免超前设计。
2. **定律十四（名实反馈律）**：通过正反馈（高质量能力上浮）和负反馈（低质量能力下沉）实现生态自组织。
3. **定律十五（名实终极律）**：协议趋向动态谐振的吸引子，不追求完全同一，也不容忍彻底分离。

---

## 七、许可

CCP 协议文本采用 [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) 许可。

参考实现代码（`index.html`、`js/`、`css/`）采用 [MIT](https://opensource.org/licenses/MIT) 许可。

---

## 八、附录 A：DeepSeek-Harness 适配器规范

> **适用场景**：将 CCP 能力锚点映射为 DeepSeek-Harness（DSH）生态中的可安装插件声明。

### 8.1 背景与定位

DeepSeek-Harness 是一个基于 Cordis 运行时的 Agent 开发框架，其插件系统采用 `dsh.bundle.patch` 规范。CCP 协议与 DSH 的关系是 **索引层与执行层** 的关系：

- **CCP / SkillMesh**：能力锚点的发现、评估、路由（索引层）
- **DeepSeek-Harness**：插件安装、运行时执行、生命周期管理（执行层）

SkillMesh 不替代 DSH 的插件市场，而是作为 **DSH 生态的"能力发现前端"**——用户在 SkillMesh 搜索能力，通过路由操作生成 DSH 适配器配置，然后导入 DSH 运行时执行。

### 8.2 CCP 能力锚点 → DSH 插件声明的映射规则

| CCP 字段           | DSH 字段                        | 映射逻辑                                                      |
| ------------------ | ------------------------------- | ------------------------------------------------------------- |
| `id`               | `metadata.name`                 | 直接映射，格式化为 kebab-case                                 |
| `name` / `name_en` | `metadata.description`          | 拼接为 `"{name} — {name_en}"`                                 |
| `desc`             | `README.md`（生成）             | 生成一段 Markdown 描述                                        |
| `endpoint`         | `runtime.entrypoint.command`    | 根据 `endpointType` 映射                                      |
| `endpointType`     | `runtime.type`                  | `mcp` → `mcp-server`；`http` → `http`；`command` → `function` |
| `provenance`       | `metadata.repository`           | 直接映射                                                      |
| `category`         | `metadata.tags`                 | 映射为标签数组                                                |
| `trustSource`      | `permissions.riskScore`（参考） | 源码可验证性越高，风险评分越低                                |
| `features`         | `capabilities`                  | 映射为能力声明列表                                            |

### 8.3 生成的 `plugin.yaml` 示例

以 CCP 能力锚点 `pdf-extract-text-001`（PDF文本提取）为例，SkillMesh 路由操作生成的 DSH 插件声明：

```yaml
# ============================================================
# 由 SkillMesh / CCP 路由操作自动生成
# 源能力锚点：pdf-extract-text-001
# 生成时间：2026-08-28T12:00:00Z
# CCP 协议版本：v0.1.1
# ============================================================

apiVersion: deepseek.io/plugin/v1
kind: Plugin
metadata:
  name: pdf-extract-text
  version: 1.0.0
  description: "PDF文本提取 — PDF Text Extraction"
  authors:
    - name: "CCP Community"
  license: MIT
  homepage: "https://skillmesh.礼字号.中国"
  repository: "https://github.com/pymupdf/PyMuPDF"
  tags: [pdf, text, extraction, document, data]
  categories: [data]
  maturity: stable
  minHarnessVersion: "0.8.0"

runtime:
  type: mcp-server
  entrypoint:
    command: ["python", "-m", "pymupdf_server"]
  env:
    - name: MCP_SERVER_URL
      description: "MCP server endpoint"
      required: true
      default: "mcp://pymupdf-server/extract-text"

capabilities:
  - name: extract-text
    description: "从PDF文件中提取全部文本内容，保留段落结构"
    input:
      type: object
      properties:
        file:
          type: string
          description: "PDF文件URL或本地路径"
      required: [file]
    output:
      type: object
      properties:
        text:
          type: string
          description: "提取的文本内容"
        pages:
          type: integer
          description: "页数"

permissions:
  services:
    inject: [fs]
    provide: [pdf-extract-text]
  sandbox:
    recommended: workspace-read
    fileAccess: ["${workspace}/**/*.pdf"]
  riskScore: 1.8

# CCP 信任向量（以注释形式保留，供 DSH 安全策略参考）
# trustSource: 0.92
# trustUsage: 1240
# trustSuccess: 0.97
# trustRisk: 0.10
# trustTime: 0.88
# evidence: { count: 1240, uncertainty: 0.24 }
```

### 8.4 SkillMesh → DSH 的调用入口

SkillMesh 在能力锚点详情页（模态框）中，为每个能力锚点提供"适配器导出"入口：

```
┌─────────────────────────────────────────────┐
│  模态框：PDF文本提取                         │
│  ┌─────────────────────────────────────────┐│
│  │ 描述 | 输入输出 | 功能特性 | 使用说明    ││
│  │ 调用示例 | 端点 | 来源 | 信任向量       ││
│  │ 证据层                                   ││
│  ├─────────────────────────────────────────┤│
│  │ 🔗 路由操作                              ││
│  │ ┌─────────┐ ┌──────────┐ ┌───────────┐ ││
│  │ │ 生成代码 │ │ 浏览器试用│ │ 导出适配器 │ ││
│  │ └─────────┘ └──────────┘ └─────┬─────┘ ││
│  │                                 │       ││
│  │  ┌──────────────────────────────▼─────┐ ││
│  │  │ 导出到：                            │ ││
│  │  │ ○ DeepSeek-Harness (plugin.yaml)   │ ││
│  │  │ ○ MCP 客户端 (mcp.json)            │ ││
│  │  │ ○ LangChain (Tool JSON)            │ ││
│  │  │ ○ CrewAI (Tool Schema)             │ ││
│  │  │ ○ Dify (工具配置)                   │ ││
│  │  │ [导出选中] [复制全部]               │ ││
│  │  └────────────────────────────────────┘ ││
│  └─────────────────────────────────────────┘│
└─────────────────────────────────────────────┘
```

### 8.5 DSH 插件安装命令（SkillMesh 生成）

用户从 SkillMesh 获取 DSH 适配器配置后，在 DSH 环境中执行：

```bash
# 方式 1：从 SkillMesh 生成的 plugin.yaml 安装
dsh plugin add --config ./skillmesh-pdf-extract-text.plugin.yaml

# 方式 2：从 SkillMesh 生成的 URL 安装
dsh plugin add https://skillmesh.礼字号.中国/api/ccp/pdf-extract-text-001/dsh.yaml

# 方式 3：通过 SkillMesh CLI 工具直接安装
skillmesh install pdf-extract-text-001 --target dsh
```

### 8.6 双向信任同步

CCP 与 DSH 的信任数据可以双向流动：

```
CCP 信任向量 ────────────────► DSH 安全策略
  trustSource  ──►  permissions.riskScore
  trustSuccess ──►  安装决策参考
  evidence      ──►  审计日志

DSH 运行时遥测 ───────────────► CCP 证据层更新
  调用次数      ──►  evidence.count ++
  成功率        ──►  trustSuccess 更新
  错误日志      ──►  uncertainty 调整
```

**远期规划**：当 DSH 运行时遥测通过标准化接口回传至 SkillMesh 时，CCP 的证据层数据将从"社区手动填写"升级为"运行时自动采集"，实现信任数据的闭环演化。

---

## 九、版本历史

| 版本   | 日期       | 变更内容                                                                                      |
| ------ | ---------- | --------------------------------------------------------------------------------------------- |
| v0.1.0 | 2026-08-28 | 初始草案：能力锚点 Schema、三大操作（发现/评估/调用）、通约层与分发层分离                     |
| v0.1.1 | 2026-08-28 | 新增第四操作"路由（Route）"、五种路由模式、DeepSeek-Harness 适配器规范                        |
| v0.1.2 | 2026-08-29 | CCP API 端点正式上线（`/api/ccp/v1/`）、CORS 代理上线（`/api/proxy`）、浏览器试用支持代理回退 |

### v0.1.2 API 端点

CCP 协议的首个可编程 API 端点已部署于 `skillmesh.礼字号.中国`：

```
GET /api/ccp/v1/capabilities              → 全部能力锚点列表
GET /api/ccp/v1/capabilities/{id}         → 单个能力锚点详情
GET /api/ccp/v1/capabilities/{id}/adapters/dsh       → DSH 插件 YAML
GET /api/ccp/v1/capabilities/{id}/adapters/mcp       → MCP 客户端配置 JSON
GET /api/ccp/v1/capabilities/{id}/adapters/langchain → LangChain Tool 配置
GET /api/ccp/v1/capabilities/{id}/adapters/crewai    → CrewAI Tool 配置
GET /api/ccp/v1/capabilities/{id}/adapters/dify      → Dify 工具配置

POST /api/proxy                            → CORS 代理（浏览器试用回退）
```

所有端点返回 `Access-Control-Allow-Origin: *`，支持跨域调用。

> **协议文件导航**：
>
> - [CCP 协议规范](./CCP-v0.1.md)（本文档）
> - [贡献指南](../CONTRIBUTING.md)
> - [项目说明](../README.md)
> - [SkillMesh 插台——名实学·道场学终极理论指导](./SkillMesh%20插台——名实学·道场学终极理论指导与项目执行规划.md)
