认证
公开注册中心端点可以不使用 Project Key 检查。运行和工作台操作需要登录上下文和有作用域凭据。
公开 Skill 注册中心端点
使用注册/搜索端点列出公开 Skills，并按任务、运行时、验证状态和权限画像筛选。
Manifest 检查
Skill 详情端点在采用前展示 manifest、schema、权限、版本、发布者和审核状态。
Project Key 运行端点
运行调用应使用登录后项目中创建的 Project Key 认证。
错误与限流
API 客户端应处理校验错误、未授权调用、策略阻断、限流、缺少 Project Key 和支付能力门禁。
请求示例
POST /v1/runtime/invoke，使用 Authorization: Bearer PROJECT_KEY，并传入 Skill slug 与类型化输入。
开发者应该先用哪条路径？
评估 Skill 时先走公开发现；团队确认要复用某个工作流并检查权限后，再进入项目运行。
- 发现：免密浏览分类、对比发布者，并检查 manifest 元数据。
- 采用：登录后创建项目，只有团队计划长期复用时才保存 Skill。
- 运行：只在可信服务端或已批准自动化环境中，用有作用域的 Project Key 调用 REST。
请求与响应契约
生产客户端应把每个 Skill 当成类型化合约：发送前校验输入，处理结构化输出，并保存 invocation id 便于审计追踪。
- 发送 Skill slug、必要时指定版本偏好，并提交符合 manifest schema 的类型化 payload。
- 策略阻断、校验错误、限流和运行时不可用都应作为正常分支处理。
- 记录请求时间、项目、Skill slug、响应状态和 invocation id，但不要记录 secret。
生产前运营检查清单
把 API 接入客户可见流程前，要确认负责人、Key 作用域、重试行为、日志和人工兜底。
- Project Key 保留在服务端；负责人或环境变化时要轮换。
- 可重试工作流应使用幂等键或任务 id。
- 涉及高风险权限、客户数据、账务或外部写入时，保留人工复核。