ZixieKit：一份源、多端分发的 AI 能力运行时

背景：随着 AI 辅助开发工具的普及，日常工作中经常需要在 CodeBuddy、Claude Code、OpenClaw 等多个 IDE/Agent 之间切换。每个工具的 Skill 目录结构、配置格式、Hook 机制完全不同，手动维护多份一致的 Skill 集合既低效又容易出错。更麻烦的是，当企业 AI 有 token 额度限制时，额度用完就必须换工具继续工作——但切换工具的代价是丢失之前积累的所有 Skill 配置。

ZixieKit 就是为解决这个问题而生的——它是一套可编排的 AI 能力运行时，将 Skill / Procedure / Rule / Hook 等能力单元，通过统一的安装派生机制分发到不同 AI 工具，同时在 Agent 和 CLI 两种模式下使用。

一、痛点：为什么需要 ZixieKit？

日常 AI 辅助开发中，两个场景倒逼出 ZixieKit：

1. Token 额度驱动 IDE 切换：公司 AI 有 token 额度限制，额度用完后必须切换到另一个 IDE 继续工作。但问题是——每个 IDE 的 Skill 目录结构、配置格式、Hook 机制完全不同。手动在多 IDE 之间维护一致的 Skill 集合，既低效又容易出错。

2. 机器人 Agent 倒逼一致性：随着 OpenClaw 等机器人 Agent 的接入，Skill 不仅要在人类开发者的 IDE 中运行，还要在无人值守的自动化 Agent 中运行。同一批 Skill，需要同时部署到多个终端、多种环境。手动同步必然导致版本漂移和配置不一致。

规模放大后，七个衍生痛点浮出水面：

痛点	现象	根源	对应能力域
配置漂移	多 IDE 多机器各自维护副本，版本不一致	无统一安装源	① 安装派生
平台锁定	不同 IDE 的目录结构 / Hook / 配置格式完全不同	无跨平台抽象层	① 安装派生
产物污染	缓存、日志、临时文件与源码混在一起	无环境隔离机制	① 安装派生
流程失控	多步骤任务交给 LLM 自由跳转，结果不可控	无确定性编排引擎	② Procedure
依赖断裂	手动复制 Skill 到外部项目，import 丢失	无自动化分发系统	③ Dispatch
质量盲区	规模增长后靠人眼检查必漏	无自动化检查体系	④ 自检
反馈浪费	执行日志堆积但不被系统化处理	无闭环进化机制	⑤ 自进化

设计目标：一份源（ZixieKit 仓库）→ 多端分发（不同 IDE）→ 机器人 + 人类共享同一套能力 → 持续进化。

二、整体架构

                         ┌─────────────────────────────────┐
                         │         ZixieKit 仓库            │
                         │ ① 安装(profiles/types/adapters/) │
                         │ ② Procedure(procedures/)        │
                         │ ③ Dispatch(dispatch/)           │
                         │ ④ 自进化(skills/)               │
                         │ ⑤ 记忆(profiles/default/)       │
                         └────────────┬────────────────────┘
                                      │
                        ┌─────────────┼─────────────┐
                        │             │             │
                   ┌────▼────┐  ┌────▼────┐  ┌────▼────┐
                   │Adapter A│  │Adapter B│  │Adapter C│
                   │CodeBuddy│  │Claude   │  │OpenClaw │
                   └────┬────┘  └────┬────┘  └────┬────┘
                        │            │            │
                   ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
                   │  Mac 1  │ │  Mac 1  │ │  Mac 2  │
                   │codebuddy│ │ claude  │ │ openclaw│
                   └─────────┘ └─────────┘ └─────────┘

ZixieKit 仓库是唯一真相源，通过 Adapter 层屏蔽不同 IDE 的差异，一份 Skill 源文件自动渲染为各平台的原生格式。

三、五大能力域

┌─────────────────────────────────────────────────────────────────┐
│                     ZixieKit 五大能力域                          │
├─────────────────────────────────────────────────────────────────┤
│  ① 安装派生与实例管理                                            │
│     profile × type × instance → adapter → install to target     │
│     解决："同一份能力怎么装到不同 IDE"                            │
│                                                                 │
│  ② Procedure 确定性流程引擎                                      │
│     多步骤编排 → 引擎驱动 → LLM 不参与跳转                       │
│     解决："多步骤流程怎么不被 LLM 乱跑"                           │
│                                                                 │
│  ③ 第三方 Dispatch                                               │
│     将 Skill 按需同步到外部仓库 / 平台                            │
│     解决："怎么把能力分发到别的项目"                              │
│                                                                 │
│  ④ Skill 开发与自进化                                            │
│     Skill 规约 + 自检 + 自进化 + 版本锁定                        │
│     解决："Skill 怎么持续提升质量"                                │
│                                                                 │
│  ⑤ 记忆蒸馏与角色沉淀                                            │
│     长期记忆定期蒸馏 → 沉淀人格 → 多角色协作                      │
│     解决："AI 记忆怎么沉淀为长期人格"                             │
├─────────────────────────────────────────────────────────────────┤
│  Agent 模式（IDE 对话）  │  CLI 模式（命令行）                    │
└─────────────────────────────────────────────────────────────────┘

能力域	核心问题	关键概念
① 安装派生	同一份能力怎么装到不同 IDE	Profile / Type / Instance / Adapter / InstallPlan
② Procedure	多步骤流程怎么不被 LLM 乱跑	Procedure / Step / when / on_error / checkpoint
③ Dispatch	怎么把能力同步到外部	dispatch/ 脚本 / 依赖分析 / 路径改写
④ 自进化	Skill 怎么自检和进化	frontmatter / manifest / lint / skill-validator
⑤ 记忆角色	记忆怎么沉淀为人格	distill / refine / Role / Profile

① 安装派生 —— 同一份能力，装到不同 IDE

这是 ZixieKit 的核心引擎。30+ 台机器 × 3+ 种 IDE 的组合如果手动维护，配置漂移和版本不一致是必然的。安装系统只让用户描述”装什么、装到哪”，引擎负责渲染、diff、写入全链路。

五层实例模型

Layer 0: 环境变量     ZIXIEKIT_HOME, ZIXIEKIT_TMP, WORK_ROOT
────────────────────────────────────────────────────────
Layer 1: Profile     人格模版（SOUL, MEMORY, IDENTITY...）
         ↓ 继承       每台机器共享的共性配置
Layer 2: Type         IDE 适配器模板（目录结构、配置格式）
         ↓ 适配       决定 Skill "怎么装"
Layer 3: Instance     实例配置（机器 × IDE 绑定）
         ↓ 覆盖       差异项：disabled_skills, enabled_tasks
Layer 4: State        运行状态（snapshots, audit log）
────────────────────────────────────────────────────────

新增一台机器只需建 instances/<name>/ 目录，Layer 1-2 的共性自动继承。差异项通过 instance 覆盖。

全链路安装流程

  zk instance install          zk instance update --apply
     │                              │
     │ 创建 instance.yaml            │
     │                              ▼
     │                    ┌──────────────────┐
     │                    │  1. Collection   │  收集 skill/procedure/
     │                    │                  │  hook/profile 文件
     │                    └────────┬─────────┘
     │                             │
     │                             ▼
     │                    ┌──────────────────┐
     │                    │  2. Render       │  Adapter 渲染
     │                    │                  │  SKILL.md → 目标格式
     │                    └────────┬─────────┘
     │                             │ RenderedFileSet
     │                             ▼
     │                    ┌──────────────────┐
     │                    │  3. Plan         │  对比目标现状
     │                    │  build_plan()    │  基于内容 SHA8
     │                    │                  │  create/update/skip
     │                    └────────┬─────────┘
     │                             │ InstallPlan
     │                             ▼
     │                    ┌──────────────────┐
     │                    │  4. Apply        │  文件写入 + 备份
     │                    │  apply_plan()    │  支持回滚
     │                    └────────┬─────────┘
     │                             │
     └─────────────────────────────┘
                                   │
                                   ▼
                           目标 IDE 文件系统

幂等安装原理

基于文件内容 hash 做 diff，杜绝伪变更：

文件 A (源)        文件 A' (目标)        操作
──────────────────────────────────────────────
sha:k1a2b3c4       不存在               → create
sha:k1a2b3c4       sha:k1a2b3c4         → skip
sha:k1a2b3c4       sha:d5e6f7g8         → update（备份后写）
不存在              sha:xxxxxxxx         → delete

Adapter 接口

class BaseAdapter:
    def render_skill(skill, ctx)      → RenderedFileSet  # SKILL.md → 目标格式
    def render_procedure(proc, ctx)   → RenderedFileSet  # workflow.yaml
    def render_hook(hook, ctx)        → RenderedFileSet  # hooks.json / .sh
    def render_raw_asset(asset, ctx)  → RenderedFileSet  # rules / commands
    def render_profile_file(path,ctx) → RenderedFileSet  # SOUL / MEMORY...
    def install_plan(rendered, tgt)   → InstallPlan       # 基于 hash diff
    def apply(plan, target)           → InstallResult     # 写入 + 备份
    def smoke_test(target)            → list[Issue]       # 安装后验证

当前实现：codebuddy.py、openclaw.py。新增 IDE 只需实现一个 Adapter 子类。

环境分离与密钥管理

Skill 的运行产物与源码严格分离：

ZIXIEKIT_HOME   → 框架配置（~/.zixiekit/.env）
ZIXIEKIT_TMP    → 运行产物（~/.zixiekit/cache/ / logs/）
WORK_ROOT       → 用户项目工作区
OUTPUT_ROOT     → 用户项目输出区

.env 文件是唯一全局环境变量源，zk init 自动生成。所有 Skill 脚本通过 bootstrap.py 统一加载，禁止各自解析 .env。敏感信息集中存储在 ${ZIXIEKIT_TMP}/secrets.env（chmod 600），通过 zk secrets 管理：

zk secrets set DOUBAN_APIKEY "your-key"
zk secrets get DOUBAN_APIKEY

② Procedure 引擎 —— 流程不被 LLM 乱跑

70+ 个 Skill 的编排如果完全交给 LLM 自由决策，流程跳转不可控、审计不可追溯。Procedure 引擎的核心理念是确定性——LLM 只负责每个步骤内的执行，不参与流程跳转。

三种步骤类型

类型	执行方式	适用场景
script（bash）	子进程执行，stdout 捕获到 `output`	自动化操作：API 调用、文件处理、数据提取
pending	暂停并输出 PENDING_ACTION JSON 给 AI 处理	语义审查、人工决策、复杂推理
confirm	等待用户输入 y/n	关键决策点：确认覆盖、确认发布

变量传递与断点续跑

步骤间通过 `` 共享数据。每步输出落地为独立 JSON 文件，支持断点续跑：

state/runtime/resume-flow/
  checkpoint.yaml          # 元数据（completed / fingerprints）
  step_init.json           # {"workspace": "/path/to/workspace"}
  step_collect.json        # {"projects": [...]}
  step_extract.json        # {"raw_data": {...}}

执行 resume-flow:
  Step 1: init             ✓ → step_init.json
  Step 2: collect          ✓ → step_collect.json
  Step 3: extract          执行中...

-- 用户中断 --

zk procedure run resume-flow --from extract
  Step 1: 跳过 → 读 step_init.json 恢复到 context
  Step 2: 跳过 → 读 step_collect.json 恢复到 context
  Step 3: extract          重跑 ✓ → step_extract.json
  Step 4: project-analyze  读 step_extract.json 继续...

PENDING 机制（AI 介入点）

当步骤执行后返回 needs_regeneration 或 validation_errors，引擎暂停并输出 PENDING_ACTION JSON，等待 AI Agent 介入：

{
  "status": "pending",
  "step_id": "draft",
  "skill": "resume-draft",
  "reason": "needs_regeneration",
  "detail": {
    "outdated_files": ["tech_summary.md"],
    "missing_files": ["skills_section.md"]
  }
}

PENDING 不终止流程——它是”暂停，等你干完再继续”的信号。

引擎边界

引擎负责（确定性）	引擎不做（留给 AI）
顺序执行 steps	自然语言路由到 skill
评估 when 条件	LLM 决策”下一步选哪个”
`` 变量插值与传递	并行执行
on_error 处理（stop/continue）	动态增删步骤
写审计日志（run.json）	跨 Procedure 编排

启动必读协议（rules 字段）

Procedure 的 workflow.yaml 支持 rules 字段，声明一段「启动必读协议」。引擎每次运行 Procedure 时先输出这段协议，约束 AI Agent 的整个执行过程——例如 trip-flow 用 rules 声明「重新生成 = 重新分析、禁止机械更新 hash 跳过推导」等铁律，确保多步骤执行不偏离既定规范。

完整案例：简历生成工作流

以 resume-flow Procedure 为例，将 7 个原子 Skill 编排成一条完整的简历生成流水线：

name: resume-flow
version: 3
description: "项目经验导向的简历生成 — 7 个原子 skill 全流程编排"

inputs:
  project:
    type: string
    required: false
    description: "指定项目子集（逗号分隔），为空时处理全部"

steps:
  - id: init
    skill: resume-init
    description: "检查/创建 workspace，确保配置文件就绪"
  - id: collect
    skill: resume-collect
    description: "交互式收集项目配置（GitHub 仓库、本地路径等）"
  - id: extract
    skill: resume-extract
    inputs:
      project: ""
    description: "从 GitHub API + 本地 Git 仓库提取原始数据"
  - id: project-analyze
    skill: resume-project-analyze
    inputs:
      project: ""
    description: "对每个项目生成深度技术分析"
  - id: cross-analyze
    skill: resume-cross-analyze
    inputs:
      project: ""
    description: "跨项目技术栈对比与框架能力画像"
  - id: draft
    skill: resume-draft
    description: "从分析结果生成结构化简历草稿"
  - id: export
    skill: resume-export
    description: "导出 Markdown、HTML、JSON 多格式简历"

outputs:
  workspace: ""
  export_dir: ""

数据流：init → collect → extract → project-analyze → cross-analyze → draft → export，每步的输出作为下一步的输入，形成完整的流水线。

完整案例：出行规划工作流

另一个典型是 trip-flow Procedure——将 7 个原子 Skill 编排成出行规划流水线。它与 resume-flow 的关键区别在于 skill 之间存在依赖拓扑，而非简单的线性链：

overview / transport / daily 是三个独立源头（目的地、交通、每日行程）
prep 依赖 daily（行程决定要准备什么），pack 再依赖 prep（物品清单决定打包清单）
summary 汇总 overview + transport + daily（主题 / 途经点 / 路线介绍）
export 依赖以上全部，渲染最终交付文档（plan.md + pdf）

下游 skill 通过 metadata.depends.<上游>.content_hash 记录上游版本。当某个上游内容变化时，Procedure 各 step 检测到「来源 B（上游变）」，自动重新生成受影响的下游产物，而不是机械更新 hash 跳过重新推导——这让「改一处、级联同步」成为引擎的确定性行为，而非依赖 AI 自觉。

③ Dispatch —— 按需同步到外部

部分 Skill 需要脱离 ZixieKit 仓库独立分发到外部项目使用（如 MNA 诊断工具、AAF 升级工具）。Dispatch 系统自动分析依赖、复制文件、改写路径，输出自包含的 Skill 副本。

核心流程

  skills/android/apk-size-analyzer/
         │
         ▼
  DependencyAnalyzer.analyze_directory()
         │
         ├─ Python import: from adb_tools import ...
         ├─ Shell 引用: source scripts/helper.sh
         └─ 同级引用: ../references/version_check.py
         │
         ▼
  sync_skill.py
         │
         ├─ 拷贝 skill 目录到目标仓库
         ├─ 复制依赖文件
         └─ 路径改写：../references/xxx → skill 根
         │
         ▼
  目标仓库 skills/apk-size-analyzer/

依赖处理

依赖类型	检测方式	分发后位置
仓库级 `scripts/`	Python import 分析	目标 `skill/scripts/`
分类级 `../references/`	源码字符串扫描	目标 `skill/` 根目录
Internal skill	frontmatter 标记	不分发（warning）

路径改写示例：../../references/version_check.py → version_check.py。

四、Hook 系统（跨域基础设施）

Agent 生命周期需要多处插桩（提交前授权检查、工具调用后错误记录、Agent 回复后执行日志），但不同 IDE 的 Hook 机制完全不同。ZixieKit 通过 Adapter 统一转换：

 Prompt 前              工具调用后            Agent 回复后          提交前
     │                      │                     │                  │
     ▼                      ▼                     ▼                  ▼
┌──────────┐         ┌──────────┐          ┌──────────┐       ┌──────────┐
│correction│         │  error   │          │ response │       │ git-auth │
│detector  │         │ detector │          │  logger  │       │（阻塞）   │
└──────────┘         └──────────┘          └──────────┘       └──────────┘
     │                     │                     │
     └─────────────────────┼─────────────────────┘
                           │
                    写入 ZIXIEKIT_TMP/cache/
                           │
                    供 session-error-review 消费

Hook 配置统一写在 HookManifest，由各 Adapter 转换为目标 IDE 的原生 Hook 格式（CodeBuddy 的 hooks.yaml、OpenClaw 的 hooks.json 等）。

五、定时调度（CRON & HEARTBEAT）

部分任务需要周期性自动执行（每日记忆蒸馏、资讯汇总），部分需要定期健康检查（服务可用性）。ZixieKit 提供声明式调度系统，共性任务一次配置、所有实例继承。

CRON 四层模型

Layer 0: 意图声明    profiles/default/cron-intents.yaml
                    "要做什么"
                    ↓ 实例可覆盖 cron.time / cron.enabled
Layer 1: 实例覆盖    instances/{name}/state/cron/
                    "什么时候做、做不做"
                    ↓
Layer 2: 运行记录    instances/{name}/state/cron/run.log
                    "上次什么时候跑的"
                    ↓
Layer 3: 外部调度    crontab / launchd
                    "谁来触发"

HEARTBEAT 三层模型

Layer 0: 意图声明    profiles/default/heartbeat-intents.md
                    "检查什么"
                    ↓
Layer 1: 实例覆盖    instances/{name}/state/heartbeat/
                    "检查谁"
                    ↓
Layer 2: 运行记录    instances/{name}/state/heartbeat/run.log
                    "上次结果"

CRON 关注业务动作（定时抓取、定时蒸馏），HEARTBEAT 关注健康状态（服务是否存活、磁盘是否满了）。两者都在 profile 层声明意图，沿五层模型向下继承——新增一台机器自动获得所有通用定时任务。

六、核心概念速览

┌──────────┐     ┌───────────┐
│  Skill   │────▶│ Procedure │    声明式 YAML 编排多个 Skill
│ 能力原子  │     │  流程引擎  │
└────┬─────┘     └─────┬─────┘
     │                 │
     │    ┌────────────┘
     ▼    ▼
┌──────────────┐
│   Adapter    │  跨平台安装器：render → plan → apply
└──────┬───────┘
       │
       ▼
┌──────────────┐     ┌──────────────┐
│   Instance   │────▶│ 目标 IDE     │
│ 机器×IDE绑定  │     │ 文件系统     │
└──────────────┘     └──────────────┘

概念	职责	物理位置
Skill	最小能力单元。IDE-only（SKILL.md）或 Procedure 化（manifest.yaml + CLI）	`skills/<category>/<name>/`
Procedure	声明式多步骤流程，引擎确定性驱动	`procedures/<name>/workflow.yaml`
Adapter	跨平台抽象层，将 Skill/Procedure/Hook 转为目标 IDE 格式	`adapters/<name>.py`
Profile	人格模版集合（SOUL / MEMORY / IDENTITY / AGENTS / TOOLS / USER）	`profiles/<name>/`
Instance	部署目标，绑定一台机器和一个 IDE	`instances/<name>/instance.yaml`

Skill 认定与加载策略

认定规则：目录下存在 SKILL.md 或 manifest.yaml → 认定为 skill。IDE-only 形态（~90%）只需 SKILL.md 一个文件，无需额外配置。

加载策略：大部分 Skill 不会出现在 IDE 的默认列表中：

类型	触发方式	是否出现在 IDE 列表	占比
公开 Skill	LLM 自然语言匹配 + 用户手动选择	✅	~15%
Procedure 专用	仅被 workflow.yaml 的 step 引用	❌	~70%
Command 专用	仅通过 `/` 斜杠命令触发	❌	~15%

核心原则：Skill 的默认姿态是”不被看见”。只有真正需要 LLM 自由调用的能力才设为公开，避免噪声。通过 internal: true 标记内部 Skill，通过 disable-model-invocation: true 阻止 LLM 自动匹配。

七、Command 体系

ZixieKit 用 15 个子命令覆盖完整生命周期，围绕四个阶段组织：

初始化与安装：zk init 写入全局环境锚点，zk instance install / zk instance update 创建实例并安装到目标 IDE（安装默认 dry-run，副作用需显式 --apply）
体检与修复：zk doctor 全面体检、zk lint 全量检查（支持 --fix 自动修复）、zk test 跑测试套件
执行：zk procedure run <name> 跑 Procedure、zk skill list 列出 Skill
管理：zk secrets 集中式密钥管理、zk dispatch lint 检查分发配置

所有副作用操作（安装、写密钥）都默认预览，显式传 --apply 才落盘，践行「幂等 + 可回滚」的设计原则。

八、自进化 —— Skill 质量的自动化保障

124 个 Skill 的规模下，靠人工检查必然出漏洞。ZixieKit 提供了三层质量体系：

zk lint ──────▶ 代码规范（5 类：shell/template/skill/procedure/instance）
     │
     ▼
zk doctor ────▶ 架构体检（10 类：adr/naming/spec/tmpdir/instance...）
     │
     ▼
zk test ──────▶ 回归测试（pytest，178 项）

质量覆盖矩阵

检查维度	工具	示例规则
Shell 规范	`zk lint`	`set -euo pipefail`、禁止 `/tmp/`
模板占位符	`zk template lint`	`${VAR}` vs `{VAR}`、硬编码路径
Skill 结构	`zk skill lint`	frontmatter 四字段、目录一致性
Procedure 结构	`zk procedure lint`	workflow.yaml 字段、版本锁定
Instance 配置	`zk instance lint`	引用存在性、枚举合法性
Dispatch 引用	`zk dispatch lint`	skill 存在、internal 过滤、references/ 完整

zk lint --fix 支持自动修复：补 Skill frontmatter、修复 Shell 语法问题。

自进化不只靠 lint。三路径并行：

 规范驱动                    会话反思                    记忆管理
 (检查清单)                  (执行反馈)                  (数据蒸馏)

 skill-validator             session-again              memory-distill
       │                          │                          │
       ▼                          ▼                          ▼
 格式/合规审查              快速自检遗漏              当日 memory → summary
       │                          │                          │
       ▼                          ▼                          ▼
 skill-optimization         session-retrospect         memory-refine
       │                          │                          │
       ▼                          ▼                          ▼
 精简 + 变量统一           更新规则 + 记忆             写入 profile 长期文件

九、记忆蒸馏 —— AI 记忆怎样沉淀为长期人格

每次会话中 AI 积累的碎片记忆，如果不被系统化处理就是浪费。ZixieKit 的记忆系统分三级存储：

数据流

 每次会话
    │
    ▼
 碎片记忆 ──→ state/memory/daily/YYYY-MM-DD.md（原始记录）
    │
    │ (cron 定期触发或手动)
    ▼
 memory-distill
    │  扫描 raw memory，提取有价值的片段
    │  写入 state/memory/summary/YYYY-MM-DD.md
    │
    ▼
 memory-refine
    │  扫描所有 summary 文件
    │  逐条确认，分发到长期存储：
    │
    ├── profiles/default/SOUL.md     ← 人格特质
    ├── profiles/default/MEMORY.md    ← 长期记忆
    ├── profiles/default/USER.md      ← 用户画像
    ├── profiles/default/IDENTITY.md  ← 身份角色
    ├── profiles/default/TOOLS.md     ← 工具使用习惯
    └── skills/**/SKILL.md           ← 反馈到对应 Skill

三级存储

层级	存储位置	生命周期	内容
Raw	`state/memory/daily/`	当日，蒸馏后清理	会话中的碎片记录
Summary	`state/memory/summary/`	待 refine 处理	distill 提炼的候选条目
Profile	`profiles/default/*.md`	长期，持续更新	refine 落地的人格/记忆/习惯

六个 Profile 文件

文件	存储内容	示例
`SOUL.md`	核心人格、偏好风格	语言习惯、回复长度偏好
`MEMORY.md`	长期记忆、经验沉淀	项目背景、历史决策
`USER.md`	用户画像	角色、技能栈、工作流
`IDENTITY.md`	身份角色定义	角色名称、职责边界
`TOOLS.md`	工具使用记录	常用命令、脚本偏好

Profile 文件是能力域 ①（安装派生）和 ⑤（记忆蒸馏）的交汇点：⑤ 将提炼的长期记忆写入 Profile 文件，① 的 zk instance update 将 Profile 文件渲染到目标 IDE 的 workspace 目录，形成”记忆 → 人格 → 安装”的闭环。

十、设计原则与技术决策

设计原则

决策权显式分离：ZixieKit 不接管自然语言路由，只提供确定性子模块
Frontmatter 是真相源：普通 Skill 只需 SKILL.md 一个文件，无需 manifest.yaml
install 默认 dry-run：所有安装操作默认预览，副作用必须显式传 --apply
幂等性：输出基于文件 hash，不写时间戳或 UUID，确保重复安装不产生伪 diff
确定性优先：Procedure 引擎保持确定性的流程控制，LLM 不参与跳转

技术决策汇总

ADR	决策	权衡
001	Skill + Procedure 二元抽象	不引入 Agent/Task/Action
002	命名空间统一 zixiekit/zk	kebab-case / UPPER_SNAKE
003	索引段自动同步	幂等 hash 替代时间戳
004	Frontmatter 是真相源	普通 Skill 只需 SKILL.md
005	Procedure 引擎确定性	LLM 不介入流程控制
006	Skill 版本显式锁定	升级 Skill 必须同步 Procedure
007	五层实例架构	新增机器只需建 instance 目录
008	CRON 四层 + HEARTBEAT 三层	新增任务只需改 profile
009	HookManifest 走 Adapter	IDE 差异由 adapter 屏蔽
010	环境变量双入口	bootstrap.py + global_env.py

十一、当前规模

指标	数值
Skill 总数	124
Skill 分类	14
Procedure	13
Adapter	4（CodeBuddy + OpenClaw + Claude Code + Hermes）
CLI 子命令	15
测试覆盖	178 项 pytest
架构文档	12 ADR + 10 SPEC

十二、后续演进（v3.0+）

当前优先完善记忆蒸馏体系（能力域 ⑤），因为长期记忆是角色的前提——没有准确的记忆就无法定义有价值的角色。路径：

v2.x: 记忆蒸馏完善 → profile 文件驱动安装
   ↓
v3.0: 角色系统启动

当记忆体系成熟后，引入角色系统：

能力	说明	触发条件
Role 定义	按职能划分（Android 开发 / Web 开发 / PM / 运维），各持 Skill / Procedure 子集	记忆蒸馏跑稳
多 Agent 消息总线	一个 Agent 即为一个角色，角色间通过消息总线通信	跨角色协作场景
并发协作	Procedure 引擎支持 parallel / loop，多 Agent 并行处理	流程时长成为瓶颈

演进原则：渐进式启用，单角色 → 多角色上下文分区 → 多 Agent 消息总线，不一步到位。

十三、快速开始

# 1. 克隆并安装
git clone https://github.com/bihe0832/ZixieKit.git && cd ZixieKit
pip install -e .

# 2. 首次使用，写入全局环境锚点
zk init

# 3. 创建实例并安装到 IDE
zk instance install
zk instance update --instance <name> --apply

# 4. 跑一个 Procedure
zk procedure run resume-flow --inputs '{}'

总结

ZixieKit 不是一个 AI 工具，而是一套让 AI 能力可管理、可分发、可进化的运行时框架：

装得上：一份源文件，通过五层实例模型 + Adapter 自动渲染到 CodeBuddy / Claude Code / OpenClaw 等不同工具，新机器建一个 instance 目录即可
跑得稳：Procedure 引擎保证多步骤流程的确定性执行，三种步骤类型 + 变量传递 + 断点续跑 + PENDING 机制，LLM 只负责步骤内逻辑
控得住：zk lint + zk doctor + zk test 三层质量体系 + 质量覆盖矩阵，124 Skill 的规模下依然可控
长得好：三级记忆存储（Raw → Summary → Profile），六个 Profile 文件驱动人格沉淀，形成”记忆 → 人格 → 安装”的闭环
传得开：Dispatch 依赖分析 + 路径改写，Skill 一键同步到外部项目；CRON + HEARTBEAT 声明式调度，共性任务一次配置全局生效

如果你也在多个 AI 工具之间切换、维护多份 Skill 配置、或者想让 AI 的长期记忆真正沉淀下来，ZixieKit 值得一试。

那时年少

微信公共平台

前端开发

开发资源

终端开发

开发工具

经验总结

玩一玩

在路上

后台开发

标签

总结 8

公共平台 3

wordpress 1

API 1

web 9

资源 4

android 51

log 1

adb 6

学习资源 1

md5 1

bug 7

svn 2

命令 3

常用工具 8

Markdown 3

markdown 2

工具 30

经验 3

SDK 22

Android 13

NDK 1

jni 1

个人作品 8

终端 1

测试 7

签名 1

iMac 13

调试 1

学习 1

gradle 7

ant 1

旅行 8

php 1

git 2

mac 2

java 1

androir 1

sqlite 1

mysql 1

tags 57

apk 5

图片 1

规划 1

chrome 1

iOS 1

jekyll 1

ruby 1

schema 1

自动 3

appium 2

linux 1

webview 1

开发资源 1