操作系统模型
Archon Protocol 是一个 AI 代理的操作系统。每个文件都精确映射到一个 OS 概念，拥有明确的加载语义：哪些常驻内存，哪些按需加载，哪些跨会话持久化。
完整架构图
┌──────────────────────────────────────────────────────────────────┐
│ ARCHON PROTOCOL = AI 代理操作系统 │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 内核 (始终驻留在上下文中) │ │
│ │ │ │
│ │ AGENTS.md / CLAUDE.md 最高指令、核心工作流 │ │
│ │ archon.config.yaml 系统配置 │ │
│ │ ai-index.md 页表（地址映射） │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↕ 系统调用接口 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 驱动 (通过 `skills:` 字段加载到内核空间) │ │
│ │ │ │
│ │ archon-code-quality 类型安全、文件限制 │ │
│ │ archon-test-sync 测试跟随代码 │ │
│ │ archon-async-loading 骨架屏、重试、懒加载 │ │
│ │ archon-error-handling 结构化错误处理 │ │
│ │ archon-handoff 接口契约 │ │
│ │ archon-nextjs-ssr ⟵ 按框架检测加载 │ │
│ │ archon-react-hydration ⟵ 按框架检测加载 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↕ 进程管理 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 系统调用 (用户主动触发的命令) │ │
│ │ │ │
│ │ /archon-init = boot() 引导 + 硬件检测 │ │
│ │ /archon-demand = exec() 完整交付流水线 │ │
│ │ /archon-audit = stat() 只读健康检查 │ │
│ │ /archon-refactor = defrag() 渐进式重构 │ │
│ │ /archon-verifier = fsck() 独立完整性校验 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↕ 子进程派生 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 守护进程 (内部使用，用户不直接调用) │ │
│ │ │ │
│ │ archon-self-auditor = watchdog 6 维代码审计 │ │
│ │ archon-test-runner = testd 测试同步与执行 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↕ 读/写 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 文件系统 (持久化存储) │ │
│ │ │ │
│ │ /docs/architecture/ = /usr/src/ 内核源码 │ │
│ │ /docs/guide/ = /usr/share/man/ 手册页 │ │
│ │ /docs/reference/ = /usr/share/info/ 参考文档 │ │
│ │ /docs/decisions/ = /var/log/ 系统日志 │ │
│ │ /proposed-rules.md = /tmp/staging 包暂存区 │ │
│ │ /todo/debt_radar.md = /var/spool/ 任务队列 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 安装器 & 包管理器 │ │
│ │ │ │
│ │ templates/install.sh = 系统安装器 │ │
│ │ templates/archon.config.yaml = 默认 /etc/ │ │
│ │ templates/constraints/ = 驱动包 │ │
│ │ tests/ = POST (开机自检) │ │
│ └──────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘逐层解析
1. 内核 — 始终驻留
内核永远在 AI 的上下文窗口中，不会被换出。它定义了代理的身份、遵守的规则、以及查找一切的地址。
| 文件 | OS 等价物 | 加载方式 | 用途 |
|---|---|---|---|
AGENTS.md | 内核镜像 | alwaysApply: true | 身份、最高指令、核心工作循环 |
archon.config.yaml | /etc/ | 每次命令时读取 | 项目配置：语言、框架、环境 |
ai-index.md | 页表 | AI 定位文件时读取 | 所有文档的用途和路径索引 |
为什么必须常驻：没有内核，代理没有身份、没有工作流、不知道任何约束的存在。所有其他组件都依赖内核的存在。
2. 驱动 — 加载到内核空间
驱动是约束技能。它们定义硬边界（❌ 禁令），通过 Agent YAML 前言中的 skills: 字段注入上下文。
| 文件 | OS 等价物 | 激活时机 |
|---|---|---|
archon-code-quality | 存储驱动 | 每次代码变更 |
archon-test-sync | 文件系统完整性驱动 | 每次代码变更 |
archon-async-loading | 显示驱动 | 编辑 UI 组件时 |
archon-error-handling | 网络驱动 | 编辑 API/组件时 |
archon-handoff | IPC 驱动 | 跨边界变更时 |
archon-nextjs-ssr | GPU 驱动（可选） | 仅 Next.js 项目 |
archon-react-hydration | 音频驱动（可选） | 仅 React 项目 |
加载机制：skills: 字段等价于 modprobe —— 在代理开始处理之前将驱动加载到内核上下文。
3. 系统调用 — 用户主动触发
| 命令 | 系统调用类比 | 功能 |
|---|---|---|
/archon-init | boot() | 检测环境、加载驱动、挂载文件系统、开机自检 |
/archon-demand | exec() | 完整交付：实现 → 审计 → 修复 → 进化 → 提交 |
/archon-audit | stat() | 只读项目健康检查，评分 0-100 |
/archon-refactor | defrag() | 分析碎片化（技术债），制定渐进重构计划 |
/archon-verifier | fsck() | 独立完整性检查 |
4. 守护进程 — 内部服务
守护进程用户不直接调用。由系统调用（主要是 /archon-demand）作为子进程派生，拥有独立上下文。
| 守护进程 | OS 等价物 | 由谁派生 | 能力 |
|---|---|---|---|
archon-self-auditor | watchdogd | demand Stage 3 | 只读 6 维代码审计 |
archon-test-runner | testd | demand Stage 3.4 | 测试发现、断言同步、执行 |
为什么需要独立上下文：就像 OS 守护进程在自己的地址空间运行，这些 Agent 获得独立的上下文窗口。审计守护进程的内部推理不会污染主进程的工作内存。
5. 文件系统 — 持久化存储
| 路径 | FS 等价物 | 挂载模式 | 用途 |
|---|---|---|---|
docs/architecture/ | /usr/src/ | 只读 | 内核源码：系统如何工作 |
docs/guide/ | /usr/share/man/ | 只读 | 用户手册：如何使用系统 |
docs/reference/ | /usr/share/info/ | 只读 | 参考文档：完整的命令/技能规格 |
docs/decisions/ | /var/log/journal/ | 仅追加 | 系统日志：为什么做了这些决策 |
proposed-rules.md | /tmp/staging/ | 读写 | 包暂存区：待审批的新规则 |
todo/debt_radar.md | /var/spool/ | 读写 | 任务队列：待执行的工作项 |
6. 内存模型
AI 的上下文窗口就是 RAM。不是所有东西都能同时装入。OS 模型规定了什么常驻、什么按需调页：
┌────────────────────────────────────────────┐
│ 始终驻留（内核空间） │ ~2% 上下文
│ AGENTS.md + archon.config.yaml │
├────────────────────────────────────────────┤
│ 预加载（驱动空间） │ ~5% 上下文
│ 约束技能（通过 skills: 字段） │
├────────────────────────────────────────────┤
│ 按需加载（用户空间） │ ~93% 上下文
│ 源代码、测试输出、文档查阅、 │
│ git diff、终端输出等 │
└────────────────────────────────────────────┘核心洞察：内核 + 驱动仅消耗 ~7% 上下文。这是治理的"税"。剩余 93% 用于实际工作。这就是为什么 Archon 使用约束技能（紧凑禁令）而非冗长指南 —— 内核空间的每个 Token 都是黄金地段。
引导序列
当 /archon-init 运行时，它遵循类似真实 OS 的引导序列：
1. BIOS/UEFI → 检测执行环境（Cursor? Claude Code? Codex?）
2. 引导加载器 → 读取 archon.config.yaml（首次启动则创建）
3. 内核加载 → AGENTS.md 已驻留（alwaysApply: true）
4. 硬件扫描 → 检测项目：语言、框架、i18n、状态管理、测试工具
5. 驱动加载 → 部署约束技能到 skills_dir
6. 挂载文件系统 → 验证 docs/ 结构完整性
7. Init 系统 → 就绪，等待用户的 /archon-demand
8. POST → 运行完整性测试（vitest）约束金字塔
四层约束同时作用于每个任务。它们不是冗余的——而是互补的：
┌─────────────────────────────────────────────┐
│ 第 1 层：内核（始终驻留） │ AGENTS.md, archon.config.yaml
│ "你是谁，你遵守什么法则" │ 不可绕过
├─────────────────────────────────────────────┤
│ 第 2 层：驱动（按命令预加载） │ 约束技能，通过 skills: 字段
│ "你不能做什么" │ ❌ 禁令、硬限制
├─────────────────────────────────────────────┤
│ 第 3 层：系统调用（标准化工作流） │ archon-demand 7 阶段流水线
│ "你必须怎么做" │ 步骤化、含审计与进化
├─────────────────────────────────────────────┤
│ 第 4 层：文件系统（按需查阅） │ 架构文档、ADR、重构报告
│ "为什么我们这样做" │ 可搜索的知识库
└─────────────────────────────────────────────┘文档生命周期
文档沿着一个生命周期从发现到固化：
发现问题 → 临时修复 → 固化为规则 → 扩展为流程 → 沉淀为参考
proposed-rules.md 约束技能 架构文档
"不要这样做" "应该这样做" "为什么这样做"为什么这个模型重要
没有 OS 隐喻，这个协议就是"一堆 Markdown 文件"。有了它：
- 加载优先级一目了然 — 内核不可商量，驱动关键，文件系统按需
- 新贡献者立刻理解层级 — "这是内核变更还是文件系统变更？"
- 上下文预算明确 — 内核 = 始终加载，驱动 = 按命令预加载，文件系统 = 按需
- 进化路径清晰 — 新约束是驱动，不是内核补丁；新文档是文件系统写入，不是内核重编译
- 约束层级可见 — 四层同时作用，各覆盖一个维度
- 文档生命周期明确 — 每条规则都有从发现到固化的清晰路径