Skip to content

AnyClaw Cloud Marketplace Overall Plan #287

Description

@TheShigure7

1. 文档目的

本文档用于统一 AnyClaw 云端市场方向,作为后续产品设计、架构设计、模块规格、接口设计、数据库设计的总入口。

本文档重点回答:

  1. 为什么要做云端市场。
  2. 云端市场做成 AnyClaw 私有后端,还是独立 Registry。
  3. 云端市场完整范围包含哪些模块。
  4. 应按什么阶段推进。
  5. 第一阶段先做到什么,哪些内容后置。

本文档是汇总版总计划,不替代详细产品、架构、模块规格与接口文档。


2. 总体结论

2.1 建议形态

建议把云端市场做成:

  • 独立的 Skill / Agent Registry Service

而不是只做成:

  • AnyClaw 私有市场后端

原因:

  • AnyClaw 可作为一个客户端接入。
  • OpenClaw 等其他 runtime 后续也可接入。
  • 云端协议更中立,生态边界更清晰。
  • 能力发布、搜索、分发、信任治理可独立演进。

2.2 总体目标

AnyClaw 云端市场不是简单的“技能展示页”,而是一条完整能力供应链,使系统具备:

  • 云端发现 Skill / Agent
  • 统一搜索与召回
  • 本地筛选与决策
  • 受控静默安装
  • 本地注册与热加载
  • 安装后恢复当前任务执行

2.3 核心分工

云端负责:

  • 能力目录
  • 包发布与版本管理
  • 包分发
  • 元数据、标签、向量索引
  • 信任与审核信息

本地负责:

  • 判断缺的是 skill 还是 agent
  • 最终筛选与排序
  • Auto / Ask / Block 决策
  • 下载、安装、回滚、注册
  • 与当前 runtime 和任务执行闭环联动

3. 完整模块清单

为避免旧文档里模块覆盖不齐,统一采用以下模块清单。

3.1 云端侧模块

  1. Catalog Service
  2. Search / Retrieval Service
  3. Package Registry Service
  4. Release / Version Management Service
  5. Distribution Service
  6. Publisher / Review Service
  7. Trust / Signature / Audit Service
  8. Metadata / Tagging / Embedding Builder

3.2 本地侧模块

  1. Market Client
  2. Capability Resolver / Selector
  3. Installer
  4. Installed Registry
  5. Runtime Loader / Activation
  6. Approval / Silent Install Policy

3.3 展示侧模块

  1. Desktop Shell Market UI

3.4 基础设施模块

  1. Database
  2. Object Storage

说明:

  • 旧文档里的“市场后端”“搜索与召回”“治理与安全”“本地安装器”等都统一归入这套模块表。
  • 接口设计.md 当前仅覆盖了其中一部分,主要是 Market Client 与主安装链路相关接口,不是全量模块接口设计。

4. 阶段划分

阶段一:最小可用市场

目标:

  • 建立独立云端 Registry 的最小闭环。
  • 让桌面壳能展示市场目录。
  • 让 AnyClaw 能从云端下载并安装能力包。

范围:

  • Catalog Service
  • Package Registry Service
  • Release / Version Management Service
  • Distribution Service
  • Database
  • Object Storage
  • Desktop Shell Market UI
  • Market Client
  • Installer
  • Installed Registry
  • Runtime Loader / Activation

不追求:

  • 混合检索
  • 自动打标签
  • 向量召回
  • 全自动静默安装
  • 复杂审核流

交付物:

  • 市场包模型
  • 最小数据库表结构
  • 最小 API 集
  • 本地安装闭环
  • 桌面壳市场列表与安装交互

阶段二:智能筛选与静默安装

目标:

  • 让系统能根据任务自动找候选能力。
  • 具备混合检索、结构化过滤和静默安装决策。

范围:

  • Search / Retrieval Service
  • Metadata / Tagging / Embedding Builder
  • Capability Resolver / Selector
  • Approval / Silent Install Policy

交付物:

  • 标签与结构化建模
  • fulltext / tag / embedding / hybrid 检索
  • 本地硬过滤
  • Auto / Ask / Block

阶段三:生态化与治理增强

目标:

  • 让市场具备对外发布、审核、可信分发和多客户端复用能力。

范围:

  • Publisher / Review Service
  • Trust / Signature / Audit Service
  • 推荐与排序增强
  • 私有可见性与组织隔离

交付物:

  • 发布与审核后台
  • 签名与 checksum 校验链
  • 安装审计
  • 团队/私有市场能力

5. 当前状态判断

基于现有文档和讨论,当前进展处于:

  • 方向明确:已完成
  • 产品与架构讨论:已形成第一版
  • 模块清单统一:需补齐
  • 数据库设计:未完成
  • 全量接口设计:未完成
  • 工程实现:未开始

因此,当前最合理的下一步不是继续泛化讨论,而是:

  1. 固化产品设计边界。
  2. 固化架构设计和模块清单。
  3. 补齐模块规格。
  4. 之后再进入数据库和 API 设计。

6. 与现有文档的关系

本汇总版之后,建议文档层次固定为:

  1. AnyClaw云端市场总体计划(汇总版).md
  2. AnyClaw云端市场产品设计文档.md
  3. AnyClaw云端市场架构设计文档.md
  4. AnyClaw云端市场模块规格文档.md
  5. 云端Skill与Agent市场接口设计.md
  6. 后续再补:
    • 数据库设计
    • 对象存储与包分发设计
    • 本地安装与运行时集成设计

其中:

  • 总体计划回答“为什么做、分几步做”。
  • 产品设计回答“给谁用、解决什么问题、功能范围是什么”。
  • 架构设计回答“系统怎么分层、怎么协作”。
  • 模块规格回答“每个模块具体做什么、输入输出是什么”。
  • 接口设计回答“对外 API 怎么定义”。

7. 风险与控制

7.1 范围膨胀风险

风险:

  • 一开始把推荐、社区、私有市场、审批、签名、向量检索全部一起做,导致第一版无法落地。

控制:

  • 严格按三阶段推进。
  • 第一阶段只做最小闭环。

7.2 云端与本地职责混乱

风险:

  • 把最终安装决策放云端,削弱本地优先和可控执行。

控制:

  • 云端只做目录、分发和召回。
  • 本地保留最终筛选与安装决策权。

7.3 模块边界不清

风险:

  • 把搜索、审核、分发、安装、已安装状态混在一起,导致文档和实现都混乱。

控制:

  • 统一采用本文档模块清单。
  • 以后所有文档均按这套模块表对齐。

8. 推荐后续顺序

推荐下一步顺序:

  1. 产品设计文档
  2. 架构设计文档
  3. 模块规格文档
  4. 数据库设计文档
  5. API 设计文档补全

一句话总结:

AnyClaw 云端市场应做成独立 Registry + 本地消费闭环的能力供应链系统,而不是单纯的目录页或私有后端。当前最重要的是统一模块清单、补齐产品与架构层级,再进入工程设计。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions