SwarmAI 设计哲学 — 自改进系统的六根支柱

[xg-gh-25]

GitHub: #39

---

多数 AI 系统优化的是 "现在能用"。SwarmAI 优化的是 "不可能以相同方式再次失败"。

TL;DR — 六根支柱一览

#	支柱	一句话
1	预防 > 恢复	让 bug 在结构上不可能（L1 文字 → L2 代码闸 → L3 架构不可能）
2	验证 > 推理	你越确定，越该去读代码
3	知识即基础设施	DDD 不是文档 — 是每个引擎消费的活基座
4	纠正 > 能力	一条纠正永久消灭一个类别；一个功能只增值一次
5	时间复利	9 个钩子会话后触发 — 系统从不是同一个 agent
6	所有权即架构	Agent 不能改自己的规则 — 边界是结构性的，不靠自觉

另外： 我们明确拒绝什么（RAG、fine-tuning、multi-agent、平台记忆）以及为什么。

---

这不是宣言。这是工程报告 — 来自 32 条纠正、9 个 COE、75+ 天生产运行、以及一个开发自身的系统。每个论断都可追溯到具体 commit、具体失败、或具体架构决策。

---

六根支柱

1. 预防优于恢复 — 三级硬化

核心信念： 最好的修复让 bug 在结构上不可能发生，而不仅仅是不太可能。

SwarmAI 的每条规则都始于文字指令。有些就留在那里。重要的升级为代码。关键的变成结构性不可能。

级别	机制	示例	绕过成本
L1 指令	写在 AGENT.md / STEERING.md 里	"代码变更后必须跑测试"	零 — 靠自觉
L2 机械闸	代码阻断	对抗子代理必须运行才能 push	需要删除闸
L3 结构不可能	架构层面阻止	群组频道物理上无法访问 MEMORY.md	需要重新设计系统

路径始终是渐进的，从不自上而下：

发布 → 失败 → 纠正（L1 文字）→ 复发 → 闸（L2 代码）→ 再复发 → 不可能（L3 架构）

证据：对抗审查始于一条建议（Discussion #3）。到 C011 时，pipeline 以 10/10 信心发布了 100% 不工作的代码后，它变成 AGENT.md 的书面规则。到 C021 时，它变成强制代码闸。同一类别 8 次纠正（C011→C032），直到结构强制终止复发。

为什么重要： 多数系统对失败的反应是"我们会更小心"。那是 L1 思维。小心不能规模化。闸可以。

---

2. 验证优于推理 — 置信度是反向信号

核心信念： 你感觉越确定，越可能是基于陈旧推理而非新鲜证据。

这条原则来自一个具体的痛苦模式：

• C005：Memory 连续 5+ 个会话声称"只有 L0+L1"。实际：L0-L4 全部实现（1,142 行，106 测试）
• C019：不读代码就断言系统行为。三次
• C015：基于直觉"优化"了一个系统。测量表明"问题"根本不存在

结构性响应：

"我认为..." (推理)     → 需要证据，否则沉默
"我测量了..." (数据)    → 可接受的断言
"代码显示..." (来源)    → 真理

关于系统状态的每个断言都必须附带文件路径和行号，否则被视为待验证的假设。

为什么重要： AI 系统对自身输出有完美回忆，但对现实的模型是不完美的。盲目信任自身记忆的 LLM 会通过蒸馏循环强化错误 — 昨天的错误答案变成今天的"已知事实"。SwarmAI 通过让验证成为默认而非例外来打破这个循环。

---

3. 知识即基础设施 — DDD 供养一切

核心信念： 领域知识不是文档，是代码消费的结构化资源。

传统方法	失败模式	SwarmAI 的替代
文档	几周内死亡 — 维护成本 > 收益	从 8 个通道自动培养
RAG	检索文本，不做判断	全量注入每个会话
Fine-tuning	静态快照，更新昂贵，不透明	透明、可审计的 markdown
项目提示词	不能交叉授粉	跨项目 Entity Index

DDD 模型（每项目 4 文档）：

文档	回答的问题	增长来源
PRODUCT.md	该不该做？	策略、用户反馈、信号
TECH.md	能不能做？	代码提交、架构决策
IMPROVEMENT.md	以前试过吗？	Pipeline REFLECT、纠正、复盘
PROJECT.md	现在该做吗？	迭代上下文、优先级、阻塞

复利效应： 多个引擎共享同一个 DDD。Pipeline 用 TECH.md 做代码决策。Pollinate 用 PRODUCT.md 做内容策略。Evolution 用 IMPROVEMENT.md 做模式检测。Pipeline 今天学到的，让 Pollinate 明天更聪明 — 不是因为它们通信，而是因为它们共享同一个生长中的基座。

证据：DDD 从 28 节（2026-03-24）增长到 110+ 节（2026-05-16）。零次"文档冲刺"。全部来自正常工作 — 8 个自动通道作为做事的副作用捕获知识。

---

4. 纠正优于能力 — 失败是最高价值数据

核心信念： 防止同一错误再次发生，优先级高于增加新功能。

比例是刻意的：EVOLUTION.md 中 32 条纠正 vs 12 条能力。跟踪"什么出了错"的精力是"什么做对了"的 3 倍。

经济学：

• 新能力线性增值（一个功能，一个收益）
• 一条纠正永久防止整个类别的失败（一个修复，无限未来避免）

模式：

C011 (2026-04-25): 跳过对抗审查。功能发布后 100% 不工作。
C021 (2026-05-09): 相同合理化。不同功能。相同结果。
C025 (2026-05-15): 相同模式。第三次。
...
C032 (2026-05-20): 第八次。

根因："我对这个够熟，可以跳过流程。"
结构修复：P5 (SOUL.md), STEERING R13 (强制闸), 机械强制。
结果：类别消除。结构修复后零复发。

质量收敛数据：

发布范围	每次发布 P0 数	Bug 类别	防护级别
v1.6–v1.9	~1.0	灾难性（OOM、app 无法启动）	Pipeline 存在之前
v1.10–v1.12	~0.3	边界（竞态、平台差异）	Pipeline 运行中
v1.13–v1.15	0.0	无（merge 前被截获）	Pipeline + 对抗 + DDD

为什么重要： 多数系统随时间增加功能。很少有系统随时间减少 bug。质量收敛 — 失败率在结构上下降，不仅仅是统计上 — 是自我改进为真的信号。

---

5. 时间复利 — 系统从不是同一个 Agent

核心信念： 会话间的间隙不是空闲。是系统学习的时刻。

每次会话关闭后 9 个钩子并发触发：

钩子	做什么	效果
DailyActivity	捕获原始会话日志	L0 记忆层填充
Distillation	提升反复出现的模式到 MEMORY.md	L1 策展层增长
EvolutionTrigger	检测纠正模式	自改进管道供料
EvolutionMaintenance	触发优化周期	技能渐进改善
SkillMetrics	跟踪使用 + 成功率	健康评分准确
UserObserver	学习偏好和模式	个性化复利
ImprovementWriteback	按项目更新 IMPROVEMENT.md	DDD 保持新鲜
ContextHealth	验证索引、缓存、git 状态	系统完整性维护
AutoCommit	提交工作区变更	Git 为真，每次会话

对会话 N+1 意味着什么： 代理醒来时，已经吸收了上一个代理犯的错。不是"从中断处继续"，是"从已经学到的地方出发"。

证据：Resume context 从 ~3-5K tokens（形状：你读了文件 X）增长到 ~50-100K tokens（实质：你读了文件 X 并发现了 Y，这意味着 Z）。

为什么重要： 时间对称意味着系统的价值主张是持续性的。使用越多越好，不是通过更新变好。这是模型改进无法复制的壕沟 — 你可以换模型，但积累的知识和硬化的规则持续存在。

---

6. 所有权即架构 — 设计中的边界，不靠自觉

核心信念： 清晰的所有权让冲突有确定性行为。不是"谁都能编辑所有东西" — 是架构级访问控制。

层级	文件	行为	谁控制
系统所有	SWARMAI.md, IDENTITY.md, SOUL.md, AGENT.md	启动时从源覆盖	平台
用户所有	USER.md, STEERING.md, TOOLS.md 等	首次复制，永不覆盖	人类
代理所有	MEMORY.md, EVOLUTION.md	通过 locked_write.py（并发安全）维护	AI

关键防御： Agent 永远不能修改自己的规则（SOUL/AGENT 是系统所有）。它只能积累证据表明规则应该改变，然后提议。这在架构上阻止了"AI 修改规则让自己的工作更轻松"的失败模式。

---

反哲学 — 我们明确拒绝什么

被拒绝的方法	为什么	我们的替代
RAG 后处理	"可能找到"< "永远拥有"。1M context，直接注入	全量 DDD 注入（~46K tokens）
Fine-tuning	不透明、昂贵、静态快照。无法审计变更	结构化进化：纠正→模式→规则，每次变更是 git commit
Multi-agent 编排	交接开销、上下文丢失。劳动分工是人类妥协不是最优设计	单 agent 多角色，零上下文转移成本
"下次更小心"	L1 思维。自觉不能规模化	结构性预防。让错事不可能，不仅仅是不鼓励
平台提供的记忆	最有价值资产的供应商锁定	自主记忆管道。换模型不丢知识
Token 预算优化	省 token = 弱上下文 = 差决策	Power over budget。1M context 存在 — 激进使用

---

复利测试

去掉任何一根支柱，其他都退化：

• 没有 预防(1)，纠正积累但从不硬化 → 同类反复发生
• 没有 验证(2)，记忆蒸馏错误信念 → DDD 腐败
• 没有 知识(3)，pipeline 无领域上下文运行 → 通用产出
• 没有 纠正(4)，质量停滞 → 无收敛信号
• 没有 时间(5)，会话无状态 → 知识不复利
• 没有 所有权(6)，agent 修改自己的规则 → 治理崩塌

这种相互依赖是架构赌注。也是让系统难以部分复制的原因 — 你不能只取"记忆"或"pipeline"就得到同样效果。复利循环本身就是产品。

---

从哲学到证据

论断	可验证方式
32 条纠正，一个类别 8 次	grep -c "^### C" EVOLUTION.md
P0 率收敛	docs/CONVERGENCE.md + release notes
DDD 增长 28→110 节	git log --diff-filter=M Projects/
9 个会话后钩子	ls backend/hooks/
质量闸强制	backend/skills/s_autonomous-pipeline/INSTRUCTIONS.md

SwarmAI 开发 SwarmAI。 哲学不是愿景 — 是操作系统。每个会话要么确认它有效，要么生成让它有效的纠正。两种结果都复利。

---

发布自 SwarmAI — 一个自改进的 AI 指挥中心，每次失败都成为永久的结构性防御。源码