CCJK 架构方向：从工具脚本到生产级环境层

旧版架构文章把 CCJK 解释成一组 v2 API 模块，比如 Brain API、Agents API、Actionbook API。那种写法的问题是，很容易让官网内容脱离当前公开定位。

按照最新 README 和本站本轮升级方向，今天更值得强调的架构重点不是“某个内部模块名字”，而是 CCJK 作为环境层到底承担什么责任。

1. 当前更准确的架构理解

CCJK 不是单一模型客户端，也不是一组零散安装脚本。它更像一层覆盖整个 AI 编码环境的操作层，负责：

• onboarding
• 环境优化
• 长期记忆
• 远程控制
• MCP 自动化
• provider 决策辅助
• 官方内容和事实同步

如果把它画成结构，更接近下面这种关系：

hljs mermaid
graph TB
    USER[开发者 / 团队]

    subgraph CCJK["CCJK 环境层"]
      ONBOARD[Onboarding]
      BOOST[Optimize + Presets]
      MEMORY[Persistent Memory]
      REMOTE[Remote Control]
      MCP[MCP Automation]
      PROVIDER[Provider Intelligence]
      SNAPSHOT[Official Snapshot]
    end

    subgraph WORKFLOWS["编码工作流"]
      CLAUDE[Claude Code]
      CODEX[Codex]
      RELAY[Relay / Aggregator]
    end

    subgraph SOURCES["官方与外部来源"]
      README[GitHub README]
      RELEASE[GitHub Release]
      NPM[npm package]
      DOCS[Provider Official Docs]
    end

    USER --> ONBOARD
    ONBOARD --> BOOST
    BOOST --> MEMORY
    BOOST --> REMOTE
    BOOST --> MCP
    PROVIDER --> CLAUDE
    PROVIDER --> CODEX
    PROVIDER --> RELAY
    SNAPSHOT --> README
    SNAPSHOT --> RELEASE
    SNAPSHOT --> NPM
    PROVIDER --> DOCS

2. Onboarding 是第一层架构，不是附属功能

当前公开入口把 npx ccjk 放在最前面，不是因为它只是最短命令，而是因为它定义了整个环境层的起点。

hljs bash
npx ccjk
export ANTHROPIC_API_KEY="sk-ant-..." && npx ccjk init --silent
npx ccjk boost
ccjk zc --preset dev

这条路径的重要性在于：

• 让不同机器从同一入口起步
• 降低历史命令分叉
• 为后续 memory、remote、provider 决策打统一基础

3. Memory 是环境连续性的核心

过去很多工具只解决“这一轮能不能回答”，但长期开发更需要解决“下一轮还记不记得”。

所以 current architecture 里，memory 更像一项基础设施能力，而不是附属增强项。

hljs bash
ccjk memory
ccjk memory --edit

它服务的是：

• 项目约定持续保存
• 多轮交互上下文延续
• 团队共享的长期背景沉淀

4. Agent Teams 与 Remote 是运行层能力

今天的 CCJK 架构已经不只是“本地配置助手”。

公开定位里，Agent Teams 和 remote control 都已经进入 headline 能力，这意味着架构关注点正在从“单机命令”扩展到“多角色、多设备、可巡检环境”。

hljs bash
ccjk agent-teams --on
ccjk remote setup
ccjk remote doctor
ccjk remote status

这层能力更适合被理解为运行层，而不是单纯的功能堆积。

5. Provider Intelligence 是决策层

这次官网升级里，最关键的架构补强之一就是 provider intelligence。

原因很简单：用户真正的风险并不只在命令能不能跑通，而在于：

• 这个 provider 是不是官方直连
• 是聚合商、relay 还是转售
• 有没有稳定付款和文档
• 适不适合生产接入

因此 provider 详情页现在增加了：

• 官方来源基线
• 运营模式分类
• 接入建议结论
• review cadence

这意味着 CCJK 官网本身也在承担“决策层架构”的角色。

6. Snapshot 是内容系统的基础设施层

如果官网继续在页面运行时直接抓活数据，或者靠人工硬编码版本号，内容体系迟早会再次失真。

所以现在的架构里，official snapshot 是必须强调的一层：

• 同步 GitHub README
• 同步公开 release
• 同步 npm 最新版
• 给首页、文档、下载页提供稳定事实来源

这层架构的价值不在 UI，而在于“让官网内容可验证、可刷新、可审查”。

7. 当前架构升级的真正方向

如果把最近的上游变化和本站升级放在一起看，CCJK 的架构方向很明确：

• 从单次安装工具，转向长期环境层
• 从“信息罗列”，转向“决策支持”
• 从静态文案，转向 snapshot 驱动内容系统

所以以后再写 CCJK 架构，优先顺序应该是：

1. 统一入口
2. 统一环境能力
3. 统一 provider 决策
4. 统一内容更新机制

而不是优先堆砌已经没有当前公开依据的历史 API 名称。