Archon Protocol：命名与协议设计

---

一、为什么叫 Archon

Archon（/ˈɑːrkɒn/）来自古希腊语 ἄρχων，意为"执政官"——城邦中拥有最高治理权力的单一角色。

在雅典的政治制度中，Archon 不是通过委员会投票治理的——他是一个人，拥有明确的权力边界和执行权。他有顾问、有下属，但最终决策权归他一人。其他角色向他汇报，不与他"协商"。

这正是 Archon Protocol 的核心架构：

Archon（古希腊）              Archon Protocol（AI 架构）
────────────────              ─────────────────────────
一个执政官治理城邦              一个 Agent 治理项目
法律是城邦的约束               文档是 Agent 的约束
顾问提供信息，不做决策          子代理提供分析，不做决策
执政官对城邦负全责              Agent 对交付负全责
法律越完善，城邦越稳定          规则越完善，代码越稳定

命名对照表

概念	古希腊	Archon Protocol
治理者	Archon（执政官）	主 Agent
法律体系	Nomos（νόμος）	constraint skills
执行工具	Hyperetes（下属执行者）	internal skills（self-auditor, test-runner, verifier）
城邦知识	Episteme（知识）	docs/ 知识文档
立法进化	Ekklesia（公民大会修法）	Stage 3.6 知识进化

为什么不是其他名字

候选名	问题
AI-OS	太通用，搜索重名无数，听起来像课程作业
AgentOS	同上，且暗示"操作系统"——我们不是 OS，是约束协议
CodePilot	和 GitHub Copilot 混淆
AutoDev	暗示全自动，忽略了人类设定边界的角色
Archon Protocol	独特、有哲学深度、精确传达"单一治理者 + 规则体系"

---

二、AAEP 协议：AI 架构师进化协议

AAEP = AI Architect Evolution Protocol（AI 架构师进化协议）

这是 Archon Protocol 自创的标准协议，定义了 AI 如何在持续开发中自我进化为项目的架构师。

为什么需要一个"协议"

现有的 AI 编程工具（Cursor、Claude Code、Codex）提供了能力——AI 能写代码、跑测试、读文档。但它们不提供方法论——AI 应该按什么流程工作？如何保证质量？如何积累经验？

AAEP 填补了这个空白：

AI 编程工具提供的：能力（capability）
  ├── 代码生成
  ├── 文件操作
  ├── 终端执行
  └── 上下文理解

AAEP 提供的：方法论（methodology）
  ├── 约束层级（什么能做、什么不能做）
  ├── 交付流程（需求 → 实现 → 审计 → 修复 → 提交）
  ├── 进化机制（每次任务让系统变得更强）
  └── 治理模型（单一 Agent + 工具型子代理）

类比： AI 工具是引擎，AAEP 是交通规则。引擎决定车能跑多快，交通规则决定车能安全到达目的地。

AAEP 的四层架构

┌──────────────────────────────────────────────────────────┐
│                                                          │
│  Layer 1: Constraint Layer（约束层）                      │
│  ─────────────────────                                   │
│  skills/code-quality/SKILL.md — 代码质量约束               │
│  skills/test-sync/SKILL.md — 测试同步约束                  │
│  skills/async-loading/SKILL.md — 异步加载约束              │
│  skills/error-handling/SKILL.md — 错误处理约束             │
│                                                          │
│  定义了 AI 的"不可逾越边界"：                               │
│    ❌ 禁止项列表                                          │
│    📏 文件大小限制                                        │
│    🔒 类型安全要求                                        │
│    🧪 测试同步强制                                        │
│                                                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Layer 2: Workflow Layer（工作流层）                       │
│  ──────────────────────                                  │
│  skills/*/SKILL.md — 所有工作流均为 skill                  │
│                                                          │
│  定义了 AI 的"标准动作序列"：                               │
│    /init     — 项目初始化                                 │
│    /demand   — 一句话需求 → 完整交付                       │
│    /audit    — 全面审计                                   │
│    /refactor — 渐进式重构                                 │
│                                                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Layer 3: Evolution Layer（进化层）                       │
│  ──────────────────────                                  │
│  /demand Stage 3.6 — 知识进化触发器                       │
│  /refactor — 架构进化方向                                 │
│                                                          │
│  定义了 AI 的"自我强化机制"：                               │
│    发现反模式 → 写入禁止项                                 │
│    发现最佳实践 → 更新规则/文档                             │
│    完成重构项 → 推进里程碑                                 │
│                                                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Layer 4: Knowledge Layer（知识层）                       │
│  ──────────────────────                                  │
│  docs/ — 性能经验、架构决策、重构计划                       │
│  archon.config.yaml — 项目技术栈配置                       │
│                                                          │
│  定义了 AI 的"项目记忆"：                                   │
│    性能优化经验                                            │
│    架构设计决策                                            │
│    重构进度追踪                                            │
│    技术栈上下文                                            │
│                                                          │
└──────────────────────────────────────────────────────────┘

AAEP 的核心机制："进化压力"

生物进化需要三个条件：变异、选择、遗传。

AAEP 在 AI 编程中构建了相同的机制：

生物进化	AAEP 对应	具体实现
变异	每次 /demand 产生新代码	Stage 1 实现阶段
选择	六维自审筛选出好的模式和坏的模式	Stage 3 自审阶段
遗传	好的模式写入规则，坏的模式写入禁止项	Stage 3.6 知识进化

关键区别： 生物进化是随机的，AAEP 的进化是有方向的。每次进化都朝着"更少 bug、更高性能、更一致的架构"前进。

第 1 代规则：基础约束（文件大小、类型安全）
     │
     │  经过 N 次 /demand
     ▼
第 2 代规则：基础 + 项目特有反模式
     │
     │  经过 N 次 /demand
     ▼
第 3 代规则：基础 + 反模式 + 性能优化 + 架构模式
     │
     │  经过 N 次 /demand
     ▼
第 N 代规则：趋近于该项目的"完美约束集"

这就是"AI 架构师进化"的含义——AI 不是天生的架构师，而是通过 AAEP 的进化压力，逐渐进化成这个项目的架构师。

AAEP 的协议规范

约束格式规范

禁止项格式：❌ <具体模式> — <原因和替代方案>
  ✅ ❌ `any` type — use the real type or `unknown`
  ❌ ❌ Don't use bad types（太模糊，不可 grep 验证）

约束激活：每个约束是一个 SKILL.md，通过 init skill 定义激活时机

工作流格式规范：
  SKILL.md frontmatter: name + description（必填）
  每个工作流必须有 Output 格式定义

进化触发规范

每次 /demand 的 Stage 3.6 必须评估：
  1. 本次任务是否产生了新的反模式？ → 写入 proposed-rules.md（隔离区）
  2. 本次任务是否发现了可复用的技术？ → 写入 proposed-rules.md（隔离区）
  3. 本次任务是否产生了性能相关发现？ → 更新性能文档
  4. 以上都没有 → 明确标注 [SKIP]，不强制进化

禁止直接修改约束技能。规则需经用户批准或自动化检测后才能毕业到约束技能。

治理模型规范

单 Agent 治理原则：
  ✅ 主 Agent 拥有最终决策权
  ✅ 子代理是工具（无决策权，仅返回结果）
  ✅ 约束通过文档注入（不依赖第二个 Agent 监督）
  ❌ 禁止多 Agent 平级协商
  ❌ 禁止子代理自主修改代码（除非主 Agent 明确委派）

---

三、命名体系总览

名称	全称	含义
Archon Protocol	—	项目整体：单一治理者 + 规则体系
AAEP	AI Architect Evolution Protocol	核心协议：AI 如何进化为架构师
Constraint Layer	—	constraint skills（不可逾越的边界）
Workflow Layer	—	skills（标准动作序列）
Evolution Layer	—	Stage 3.6 + /refactor（自我强化机制）
Knowledge Layer	—	docs + config（项目压缩记忆）

---

四、一句话总结

Archon Protocol 是一套约束体系，让 AI 编程 Agent 在项目中扮演执政官角色。

AAEP 是这套体系的核心协议，定义了 AI 如何通过持续的约束-执行-进化循环，从一个通用的代码生成器进化为这个项目的专属架构师。

人类只需要提需求。协议确保 AI 在正确的方向上越做越好。