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

    Fields

    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