发现、安装并测试
Listing -> 项目安装 -> 受治理测试调用 -> 日志和成本回访
从市场开始这里是 SkillHub 的产品级参考入口,覆盖注册库、市场、运行网关、审核治理、账本、提现、通知和后台运营。
P0 产品是否成立,就看这三条路径能不能接起来:一个 listing 必须能变成项目状态、审核状态、运行状态、账本状态、通知状态和运营状态。
Listing -> 项目安装 -> 受治理测试调用 -> 日志和成本回访
从市场开始草稿 -> 精确版本审核 -> 检查证据 -> 定价阻断 -> 反馈和提现就绪
开始发布审核队列 -> 信任动作 -> 事故 -> 财务/提现 -> 上线就绪和审计
进入运营每个域都必须给用户一个第二次回来的理由:开发者回来管理更安全的运行,发布者回来修复审核和收入,管理员回来治理真实运营。
SkillHub 技能包是版本化合约。公开发现应优先批准版本,不能悄悄替换已安装行为。
无论 agent 使用 REST、MCP、SDK 还是控制台测试,运行调用都要经过同一条治理路径。
发布者需要精确修复闭环,而不是模糊拒绝理由。自动检查必须带阻断、字段、类别和下一步。
用量不会直接支付给发布者。可计费用量和订阅周期必须先生成不可变商业记录。
站内通知、邮件行和 webhook outbox 要分开,个人偏好不能压制组织级 webhook 投递。
管理员需要在一个控制台看到不泄密的上线就绪、身份、审核、风险、财务、提现、投递、webhook 和审计。
{
"schemaVersion": "0.1",
"name": "support-triage",
"displayName": "Support Triage",
"version": "0.1.0",
"runtime": {
"type": "http",
"entrypoint": "https://api.example.com/skill"
},
"permissions": {
"network": false,
"browser": false,
"filesystem": "none",
"secrets": []
},
"inputSchema": { "type": "object" },
"outputSchema": { "type": "object" }
}这些分组是公开页面和控制台真正依赖的 API 面。支付和提现提供商的实际划转可以后置,但内部状态机必须先完整建模。
公开发现、技能详情、发布者信任和推荐排序输入。
GET /v1/skills/searchGET /v1/skills/:slugGET /v1/publishersGET /v1/publishers/:slug组织范围内的发布、版本创建、精确版本提交和商业化就绪。
POST /v1/skillsPOST /v1/publisher/skills/:slug/versionsPOST /v1/publisher/skills/:slug/versions/:version/submitPOST /v1/prices项目安装状态、收藏技能、策略审批、运行 Key、测试调用、发票和更新。
GET /v1/developer/projectsPOST /v1/projects/:projectId/installed-skillsPOST /v1/projects/:projectId/api-keysPOST /v1/projects/:projectId/runtime-test审核、信任治理、事故、上线就绪、财务、提现、通知、Webhook outbox 和审计。
GET /v1/admin/reviewsGET /v1/admin/launch-readinessGET /v1/admin/payoutsGET /v1/admin/audit-logs这些名称必须在市场卡片、技能详情、发布预检、项目策略、发布者工作台、后台审核、财务和上线就绪里保持一致。
技能版本的发布和审核状态。
draftsubmittedin_reviewverifiedrejecteddeprecatedsuspended审核证据和修复闭环中的自动检查状态。
queuedrunningpassedwarningfailed商业化就绪和资金流转状态。
pendingavailablelockedpaidfailedblockedreversed最终 provider 接入前的通知和 webhook 投递状态。
queuedpendingprocessingsentskippedfailedretry_ready支付扣款、提现提供商自动化、税务/KYC 自动化、最终法律条款和最终邮件投递提供商都属于最后接入项;P0 发布者提现使用 PayPal/Alipay 人工转账记录。