Skip to content

AnyClaw Cloud Marketplace and Existing Architecture Adaptation Analysis #307

Open
Open
AnyClaw Cloud Marketplace and Existing Architecture Adaptation Analysis#307
@TheShigure7

Description

@TheShigure7
TheShigure7
opened on Apr 29, 2026

1. 文档目标

本文档专门回答下面这个问题：

以 AnyClaw 1.4 为现状基线，如果要新增“独立云端 Skill / Agent / CLI 市场”能力，怎样才能尽量不改原有架构，而是在当前结构上低侵入接入？

因此，这不是一份纯产品文档，也不是完整项目架构说明，而是一份：

  • 现状调研
  • 可复用/可扩展/需新增模块分析
  • 接入路径分析
  • 对现有架构影响分析

文档。

2. 调研范围

本次分析基于 AnyClaw 1.4 当前代码与已有文档，重点查看了：

  • pkg/gateway/gateway_routes_platform.go
  • pkg/gateway/gateway_market_control_api.go
  • pkg/gateway/gateway_market_artifacts_api.go
  • pkg/marketplace/control_plane.go
  • pkg/marketplace/artifacts.go
  • ui/src/features/market/useMarketDirectory.ts
  • 本地 skills、agent profile/config、clihub、runtimePool

3. 1.4 当前已经有什么

3.1 已有统一市场对象模型

1.4 已经在 pkg/marketplace 中定义了统一对象：

  • Artifact
  • ArtifactKind
  • Binding
  • Source
  • ControlPlaneView

这说明：

agent / skill / cli 已经被组织进同一套市场视图，不再像 1.2 那样主要分散在 plugin/store/skill 入口里。

结论：

  • 后续不应再创造第二套“云端市场专属对象模型”
  • 应继续沿用 Artifact / Binding / Source

3.2 已有统一市场入口

1.4 已经在 Gateway 上暴露：

  • GET /market/control-plane
  • GET /market/artifacts
  • POST /market/install
  • GET /market/bindings
  • POST /market/bindings

同时还兼容旧市场接口。

结论：

  • 不需要重起一套新的市场路由
  • 新功能应沿用 /market/*

3.3 已有本地安装、绑定、刷新闭环

当前 1.4 已经具备：

  • 安装 skill
  • 安装 agent
  • 安装 cli
  • 保存 binding
  • 应用 binding
  • 刷新 runtime

并且已有：

  • runtimePool.InvalidateAll()
  • runtimePool.InvalidateByAgent(...)

结论：

  • 新功能不需要重做“本地落地链”
  • 更合理的是继续复用现有安装/绑定/刷新闭环

3.4 已有市场 UI 消费层

前端已经消费：

  • /market/control-plane
  • /market/artifacts
  • /market/install
  • /market/bindings

并且已经区分：

  • agent / skill / cli
  • local / cloud

结论：

  • 新功能不需要重做市场页
  • 重点是补齐市场页背后的数据与决策能力

4. 1.4 当前缺什么

尽管 1.4 已经有统一市场控制面，但它目前更像：

本地统一市场消费层

而不是：

对接独立云端 Registry 的正式市场客户端

当前主要缺下面 4 块。

4.1 缺少远端目录客户端

还没有一个正式的：

  • Remote Catalog Client

来对接未来独立云端 Registry 的目录接口。

缺失后果：

  • 远端来源接入分散
  • 新来源不易标准化

4.2 缺少远端检索层

还没有一个正式的：

  • Remote Retrieval Client

来承接：

  • fulltext
  • tag/filter
  • vector retrieval
  • hybrid retrieval

缺失后果：

  • 文档里的“向量命中 / 混合检索”没有模块落点
  • 云端检索无法和本地聚合器明确解耦

4.3 缺少本地最终决策层

还没有一个正式的：

  • Local Selector

来负责：

  • 本地硬过滤
  • 风险检查
  • 兼容性判断
  • Auto / Ask / Block

缺失后果：

  • 只能列出和安装
  • 还做不到真正的静默安装控制

4.4 缺少安装回执与已安装索引

还没有统一记录去表达：

  • 这个包来自哪个远端来源
  • 下载了哪个版本
  • checksum/signature 是什么
  • 安装到了哪里
  • 是否可升级/回滚

缺失后果：

  • 后续升级/回滚/审计能力薄弱

5. 可复用、需扩展、需新增模块清单

这部分是整份文档最重要的内容，因为它直接体现：

好的架构接入新功能，不需要大改主骨架。

5.1 可复用模块

模块 当前所在位置 复用方式 为什么可以直接复用
Gateway /market/* 入口 pkg/gateway 直接复用 已有统一市场 HTTP 入口
Artifact / Binding / Source pkg/marketplace 直接复用 已有统一市场对象模型
SkillsManager 本地能力层 直接复用 skill 安装后仍落到原 skill 系统
Agent Profiles / Config 配置层 直接复用 agent 安装后仍通过 profile/config 接入
CLIHub CLI 能力层 直接复用 cli 安装后仍由 CLIHub 管理
runtimePool 刷新入口 运行时层 直接复用 已有刷新运行时能力
市场 UI 页面骨架 ui/src/features/market 直接复用 已有市场展示与交互壳子

5.2 需扩展模块

模块 原职责 扩展点 影响范围
Artifact Aggregator / 条目聚合器 聚合 local/cloud 条目 增加独立 Registry 来源；增加远端检索候选和 score；增加 trust/risk/compatibility 字段 影响 /market/artifacts 的 cloud 聚合逻辑
Market Artifacts API / 市场条目接口 返回市场条目列表 增加 filters、paging、retrieval metadata、score 透出 影响前端查询参数和返回结构
Artifact Installer / 条目安装协调器 按 kind 分流安装 增加本地选择器、下载校验、安装回执 影响安装链，但不改变最终落地位置
Binding Repository / 绑定存储器 存储 binding 增加来源/version/receipt_ref 关联 影响 binding 记录结构
Binding Applier / 绑定应用器 将 binding 写回本地配置 增加来源上下文与细粒度 target 控制 影响 binding 应用逻辑
Control Plane Builder / 控制面构建器 输出市场蓝图 增加独立 Registry 来源、检索能力、策略能力说明 影响 /market/control-plane 返回内容
Runtime Refresh Coordinator / 运行时刷新协调器 安装/绑定后刷新运行时 增加“静默安装后恢复执行”的挂点 影响执行后恢复体验
Agent/Skill/CLI Source Adapter / 来源适配器 将来源映射成 Artifact 增加远端 Registry 协议映射 影响 cloud 条目质量与统一性

5.3 需新增模块

模块 为什么必须新增 接入位置
Remote Catalog Client / 远端目录客户端 1.4 没有正式 Registry 客户端 pkg/marketplace/remote
Remote Retrieval Client / 远端检索客户端 1.4 没有 fulltext/tag/vector/hybrid 召回层 pkg/marketplace/remote
Local Selector / 本地选择与静默安装策略器 1.4 没有本地最终决策层 pkg/marketplace/selector.go
Install Receipt & Installed Index / 安装回执与已安装索引 1.4 缺远端安装回执、来源版本索引 pkg/marketplace/install_receipts.go

6. 模块之间怎么对接

不只是看“有哪些模块”，更要看“请求怎么穿过这些模块”。

6.1 市场浏览链

  1. Market Shell UI
  2. Gateway /market/artifacts
  3. Artifact Aggregator
  4. Remote Retrieval Client
  5. 云端 Search / Retrieval Service
  6. 返回候选与 score
  7. Artifact Aggregator 统一成 Artifact
  8. 返回 UI

说明：

  • Gateway 主结构不变
  • 扩展点主要在聚合器的 cloud 分支

6.2 手动安装链

  1. Market Shell UI
  2. Gateway /market/install
  3. Artifact Installer
  4. Local Selector
  5. Remote Catalog Client
  6. 云端 Catalog / Distribution
  7. 本地落地到：
    • SkillsManager
    • Agent Profiles / Config
    • CLIHub
  8. Install Receipt & Installed Index
  9. 返回安装结果

说明：

  • skill/agent/cli 的最终落地系统不变
  • 新增的是选择器、目录客户端和回执系统

6.3 绑定启用链

  1. Market Shell UI
  2. Gateway /market/bindings
  3. Binding Applier
  4. Binding Repository
  5. Runtime Refresh Coordinator
  6. runtimePool / MainRuntime

说明：

  • binding 机制本身不变
  • 扩展的是 binding 上下文和刷新粒度

6.4 自动补能链

  1. 任务/聊天入口
  2. 执行编排发现缺能力
  3. Remote Retrieval Client
  4. 云端 Search / Retrieval Service
  5. Local Selector
  6. Artifact Installer
  7. Install Receipt
  8. Binding Applier
  9. Runtime Refresh Coordinator
  10. 原任务恢复执行

说明：

  • 这是 1.4 目前没有完整做出的新链路
  • 但仍然复用现有市场安装与绑定能力

7. 为什么这体现了“好的架构不用大改”

这件事不能只靠口头说，要靠事实证明。

这里有 4 个证据：

证据 1：入口没变

仍然使用：

  • /market/control-plane
  • /market/artifacts
  • /market/install
  • /market/bindings

证据 2：核心对象没变

仍然使用：

  • Artifact
  • Binding
  • Source

证据 3：能力落地方式没变

仍然是：

  • skill -> SkillsManager
  • agent -> Agent Profiles / Config
  • cli -> CLIHub

证据 4：运行时刷新机制没变

仍然使用：

  • runtimePool.InvalidateAll()
  • runtimePool.InvalidateByAgent(...)

所以可以得出结论：

AnyClaw 1.4 的当前架构具备较好的扩展性。新增云端市场功能时，不需要重写 Gateway、Runtime、Skill、Agent、CLI 主体系统，只需要在既有扩展点上新增少量模块，并增强少量连接点。

8. 这个新功能对现有架构产生什么影响

8.1 对 Gateway 的影响

  • 不改 Gateway 主体组织方式
  • 只增强 /market/* 的语义和返回字段

8.2 对 marketplace 域层的影响

  • 从“本地统一市场控制面”
  • 升级成“本地市场客户端”

主要新增：

  • 远端目录
  • 远端检索
  • 本地选择器
  • 安装回执

8.3 对本地能力层的影响

  • skill/agent/cli 的本地落地方式不变
  • 只是市场安装结果要接入原有能力层

8.4 对运行时的影响

  • 安装后需要按粒度刷新 runtime
  • 自动补能需要在执行编排处新增“调用市场”的入口

这说明：

  • 运行时确实会受影响
  • 但影响点是明确、有限、可控的

9. 最终结论

基于 AnyClaw 1.4 的现状，可以得到一个明确判断：

  1. 1.4 已经有统一市场控制面雏形。
  2. 它已经适合承接 agent / skill / cli 统一市场能力。
  3. 新增云端市场功能时，最合理的路线不是重做一整套新架构，而是：
    • 复用现有 /market/*
    • 复用 Artifact / Binding
    • 复用本地 skill/agent/cli 落地链
    • 在聚合、检索、决策、回执四处补新模块

一句话总结：

以 1.4 为基线时，AnyClaw 新增云端市场功能并不需要大改原有架构；更合理的路线是把 1.4 已有的统一市场控制面升级为“本地市场客户端”，再通过远端目录、远端检索和本地选择器把独立云端 Registry 接进来。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions