From dd68c34137c8826d0edb65f780a702ff15752f99 Mon Sep 17 00:00:00 2001
From: cfdaily <cfdaily@gitee.com>
Date: Thu, 14 May 2026 13:38:42 +0800
Subject: [PATCH] auto-sync: 2026-05-14 13:38:42

---
 docs/design/architecture-v2.md | 112 +++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/docs/design/architecture-v2.md b/docs/design/architecture-v2.md
index b17f701..84019c9 100644
--- a/docs/design/architecture-v2.md
+++ b/docs/design/architecture-v2.md
@@ -2110,6 +2110,118 @@ observation 写入条件（必须满足至少一条）：
 这是 PRD B1（AI 帮用户想清楚要什么）的全程贯穿，不限于 Phase 1。
 在庞统的 prompt 中加入"用户意图一致性检查"规则。
 
+#### 3.12.8 AI native Skill 体系（v2.5 新增）
+
+> **核心理念**：v1.0 的 Skill 是操作手册（告诉 AI 怎么做），v2.0 的 Skill 是行为准则（告诉 AI 做什么是对的）。
+> AI 自己决定具体怎么做，Skill 只设定边界。
+
+**三层 Skill 模型**（综合 oh-my-claudecode、Hermes、Nuwa、Agent Skills 生命周期）：
+
+| 层级 | 名称 | 内容 | 示例 |
+|------|------|------|------|
+| L1 | Principles（原则） | 做事的底线和方向 | "数据获取后必须先检查质量再回报" |
+| L2 | Patterns（模式） | 遇到什么情况应该怎么做 | "如果发现缺失值 > 5%，标记异常区间" |
+| L3 | Anti-patterns（反模式） | 绝对不能做的事 | "绝不能假设数据是干净的" |
+
+**v2.0 预设 Skill 目录**：
+
+```
+skills/
+├── task-bootstrap/SKILL.md        # Agent 启动协议（感知→执行→观察）
+├── task-report/SKILL.md           # Agent 完成报告协议
+├── quality-gate/SKILL.md          # 产出物自检协议
+├── orchestration-strategy/SKILL.md # 庞统调度策略（五原则）
+├── data-acquisition/SKILL.md      # 数据获取最佳实践（赵云）
+├── strategy-coding/SKILL.md       # 策略编码最佳实践（张飞）
+├── risk-review/SKILL.md           # 风控审核最佳实践（关羽）
+└── experience-distill/SKILL.md    # 经验蒸馏最佳实践
+```
+
+每个 Skill 包含 L1（原则）+ L2（模式）+ L3（反模式）三层。
+Skill 内容用 Markdown 格式（LLM 理解最好、token 最省），不用 JSON。
+
+#### 3.12.9 庞统调度策略 Skill（v2.5 新增）
+
+> 综合 Microsoft Azure Checker Pattern、Google RouterAgent、oh-my-claudecode Team pipeline、AWS Strands ReWOO。
+
+**调度五原则**：
+
+| # | 原则 | 说明 | 业界来源 |
+|---|------|------|---------|
+| 1 | **Capability Matching** | 根据 Agent 能力画像匹配任务，不是轮询分配 | Google RouterAgent |
+| 2 | **Dependency-Aware Scheduling** | 先调度无依赖步骤（可并行），有依赖的等前置完成 | AWS Strands ReWOO |
+| 3 | **Iterative Refinement** | 执行→验证→如有问题→第二轮修正→再验证（设上限） | Microsoft Azure Checker Pattern |
+| 4 | **Quality-Gated Advancement** | 当前步骤通过门控后才调度下一步 | oh-my-claudecode verify→fix loop |
+| 5 | **Escalation Over Failure** | 失败不放弃：重试→换 Agent→升级到用户 | Hermes per-task retry |
+
+**Iterative Refinement 具体流程**：
+
+```
+庞统调度张飞 → 张飞产出 → 庞统/司马懿审核
+  → 通过：调度下一步
+  → 未通过：调度张飞第二轮（带上审核意见 + 相关 observation）
+    → 张飞 read observations/ → 自主调整 → 再提交
+    → 通过：调度下一步
+    → 未通过 + 达到迭代上限（3次）：升级到用户
+```
+
+**并行步骤的处理**：
+并行步骤间不需要实时感知。庞统在两个并行步骤都完成后，
+检查 observation 是否有关联。如果有关联，调度受影响的 Agent 做第二轮。
+
+#### 3.12.10 Observation 设计方案（v2.5 完善）
+
+**Observation 生命周期**：
+
+```
+1. Agent 执行中发现问题
+   → 判断是否符合写入标准（影响后续步骤/提升质量/专业外问题）
+   → 不符合标准就不写（禁止进度报告、正常确认、无关细节）
+
+2. 写入 observation
+   → write artifacts/task-{id}/observations/{agent}-{timestamp}-{uuid短}.md
+   → 唯一强制：第一行必须是 [SEVERITY: blocking/warning/info]
+   → 内容格式完全自由（不固定 JSON 或 Markdown）
+   → POST /api/observations 通知 daemon
+
+3. daemon 收到通知
+   → blocking：立即通知庞统
+   → warning/info：步骤完成时一起通知
+
+4. 庞统处理
+   → 评估影响 → 决策（忽略/调整计划/通知后续 Agent/调度第二轮）
+
+5. 后续 Agent 感知
+   → 被调度时 read observations/ → 自主决定是否调整
+```
+
+**为什么内容格式不固定**：
+固定 JSON 或 Markdown 格式会束缚 AI 的表达能力。
+Agent 根据发现的情况自由选择最合适的表达方式。
+唯一强制 severity 标记是因为 daemon 需要它来决策通知级别。
+
+**频率限制**：每个步骤每个 Agent 最多 3 个 observation。
+
+**observation 的 pav 执行记录**（v2.5 新增）：
+Agent 执行过程中的关键决策点用 severity=audit 记录：
+- 为什么选这个方法
+- 做了什么取舍
+- 发现了什么
+audit 级别不通知庞统，只记录在文件系统供事后审查。
+
+#### 3.12.11 Agent 调度方式（v2.5 确认）
+
+**实验结论**（2026-05-14 spawn 实验）：
+- `sessions_spawn` 只能 spawn 自己的 sub-agent，不能指定 guanyu-dev 等其他 agentId
+- 因此 spawn 用于庞统内部的复杂分析，不能替代调度将军
+
+**v2.0 双模式调度**：
+
+| 方式 | 用途 | 特点 |
+|------|------|------|
+| `openclaw agent --agent xxx` | 调度将军执行步骤 | 一次性 CLI，执行完进程结束 |
+| `sessions_spawn` (cleanup:delete) | 庞统内部复杂分析 | 子 session 完成后自动清理 + 结论回传 |
+
 ---
 
 ## 4. 已决策（全部）