auto-sync: 2026-05-14 13:38:42
This commit is contained in:
cfdaily
@@ -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. 已决策（全部）
|
||||
|
||||
Reference in New Issue
Block a user