cfdaily
639 lines
27 KiB
Markdown
639 lines
27 KiB
Markdown
# 课题4 设计方案：智能拆解机制 + Skill 体系工程落地
|
||
|
||
**作者**: 庞统士元
|
||
**日期**: 2026-05-15
|
||
**状态**: 方案待确认
|
||
**前置**: 课题1/2/3 已结题
|
||
**调研报告**: `docs/research/v2.6-research-04-decomposition-skills.md`
|
||
|
||
---
|
||
|
||
## Part A：智能拆解机制
|
||
|
||
### 1. 设计目标
|
||
|
||
v1.0 的拆解是"关键词匹配 → 固定 DAG 模板"，问题是：
|
||
- 模板太死板（5个固定DAG），无法根据需求动态调整
|
||
- 关键词匹配粗糙，复杂需求容易匹配错模板
|
||
- 庞统拆解时靠 LLM 理解，没有结构化引导
|
||
|
||
课题4要解决：**庞统收到用户需求后，如何把它变成黑板上的任务（含依赖关系、角色分配、风险等级）。**
|
||
|
||
### 2. 和课题1/2/3的关系
|
||
|
||
课题1-3 已经定义了"任务在黑板上长什么样"（tasks 表 schema、状态机、reviews 表、Guardrail 配置）。课题4定义的是"任务怎么被创建出来"。
|
||
|
||
```
|
||
课题4（创建） → 课题2（触发执行） → 课题3（审查） → 课题1（失败处理）
|
||
```
|
||
|
||
### 3. 设计决策
|
||
|
||
#### D4-1：模板组件库替代固定 DAG
|
||
|
||
> **参考实践**：
|
||
> - **MetaGPT**：SOP 自动链 + `_watch` 声明式订阅，不是固定 DAG
|
||
> - **get-shit-done**：discuss→plan→execute→verify→ship 五阶段，但每阶段内部灵活
|
||
> - **open-multi-agent**：Goal → DAG 自动分解，按 complexity 决定粒度
|
||
> - **v1.0**：5 个固定模板（full_role_development / circular_review_test / multi_stage_review / data_acquisition / multi_edge_discussion）
|
||
|
||
**方案**：不是 5 个完整 DAG，而是**模板组件库（Phase Components）**。庞统按需组合。
|
||
|
||
```yaml
|
||
# template_components.yaml
|
||
components:
|
||
research:
|
||
trigger: "需要调研/分析"
|
||
mandatory: false
|
||
steps:
|
||
- id: lit_search
|
||
name: "资料调研"
|
||
agent: zhaoyun-data
|
||
output: "research_report.md"
|
||
- id: analysis
|
||
name: "分析总结"
|
||
agent: pangtong-fujunshi
|
||
output: "analysis.md"
|
||
|
||
design:
|
||
trigger: "需要架构/设计"
|
||
mandatory: false
|
||
steps:
|
||
- id: arch_design
|
||
name: "架构设计"
|
||
agent: pangtong-fujunshi
|
||
output: "design.md"
|
||
- id: design_review
|
||
name: "设计评审"
|
||
agent: simayi-challenger
|
||
review_type: plan_review
|
||
|
||
coding:
|
||
trigger: "需要编码/实现"
|
||
mandatory: false
|
||
steps:
|
||
- id: implement
|
||
name: "编码实现"
|
||
agent: zhangfei-dev
|
||
output: "code/"
|
||
- id: code_review
|
||
name: "代码评审"
|
||
agent: simayi-challenger
|
||
review_type: output_review
|
||
|
||
data:
|
||
trigger: "需要数据获取/处理"
|
||
mandatory: false
|
||
steps:
|
||
- id: data_acquire
|
||
name: "数据获取"
|
||
agent: zhaoyun-data
|
||
output: "data/"
|
||
- id: data_validate
|
||
name: "数据验证"
|
||
agent: zhaoyun-data
|
||
|
||
deploy:
|
||
trigger: "需要部署"
|
||
mandatory: false
|
||
steps:
|
||
- id: deploy
|
||
name: "部署"
|
||
agent: jiangwei-infra
|
||
output: "deploy_log.md"
|
||
- id: deploy_verify
|
||
name: "部署验证"
|
||
agent: jiangwei-infra
|
||
|
||
risk_control:
|
||
trigger: "涉及实盘/资金/策略"
|
||
mandatory: true # 触发条件满足时强制包含
|
||
steps:
|
||
- id: risk_check
|
||
name: "风控检查"
|
||
agent: guanyu-dev
|
||
|
||
review:
|
||
trigger: "always"
|
||
mandatory: true # 铁律 IR-1
|
||
steps:
|
||
- id: final_review
|
||
name: "最终审查"
|
||
agent: simayi-challenger
|
||
review_type: final_review
|
||
|
||
custom:
|
||
trigger: "none" # 不自动触发，庞统主动选择
|
||
description: "庞统自由定义的 phase，结构与标准组件相同"
|
||
steps: [] # 空的，庞统运行时填充
|
||
```
|
||
|
||
**custom 组件接口**：与标准组件同 schema（steps 列表，每个 step 有 id/name/agent/output/review_type）。Plan Checker 对 custom 组件的验证和标准组件相同——检查覆盖性、依赖性、粒度、铁律。唯一区别是 custom 不从库中引用，而是庞统在 Step 2 中自由定义。
|
||
```
|
||
|
||
**庞统的拆解流程**：
|
||
|
||
```
|
||
Step 1：需求结构化
|
||
- 分析用户输入，提取需求列表
|
||
- 每个需求标注类型（数据/编码/分析/部署/风控）
|
||
- 评估复杂度（简单/中等/复杂）
|
||
- 隐含需求挖掘（如用户说"回测"→ 隐含需要数据获取）
|
||
- 产出：structured_requirements → 写入黑板 decisions 表
|
||
|
||
Step 2：组件选择 + 组合
|
||
- 根据需求类型，从组件库选择需要的 phases
|
||
- 检查 mandatory 组件是否被遗漏
|
||
- 组合 phases，排列依赖关系
|
||
- AI 增强：增删调整（如"这次数据已有，跳过 data_acquire"）
|
||
- 产出：draft_plan → 写入黑板 decisions 表
|
||
|
||
Step 3：Plan Checker 验证
|
||
- 独立验证（不是庞统自己验证自己）
|
||
- 检查项：
|
||
- 覆盖性：每个需求是否被至少一个 step 覆盖
|
||
- 依赖性：step 依赖是否合理（无环、无遗漏前置）
|
||
- 粒度性：step 是否过大/过小
|
||
- 铁律：IR-1（每任务至少2 Agent）是否满足
|
||
- 风险：risk_level 是否合理，高风险任务是否有对抗审查
|
||
- 不通过 → 回 Step 2 调整（最多 2 轮）
|
||
- 2 轮不通过 → 庞统带着 Plan Checker issues 创建任务，标注 risk_level=high，由审查者在 plan_review 阶段进一步验证。不升级用户（庞统能处理）
|
||
- 通过 → 进入 Step 4
|
||
|
||
Step 4：任务创建
|
||
- 将 plan 转为黑板 tasks
|
||
- 每个 step → 一个 task（含 truths / artifacts / constraints / risk_level / assigned_to）
|
||
- 依赖关系 → tasks 的 depends_on 字段
|
||
- 庞统在黑板上写 scope_declaration
|
||
- 产出：tasks 写入黑板 → Daemon 检测 → 开始执行
|
||
```
|
||
|
||
#### D4-2：需求结构化的输出格式
|
||
|
||
庞统分析用户需求后，输出结构化需求到黑板：
|
||
|
||
```json
|
||
{
|
||
"original_input": "实现一个双均线策略的回测",
|
||
"requirements": [
|
||
{
|
||
"id": "req-001",
|
||
"description": "获取标的分钟线数据",
|
||
"type": "data",
|
||
"acceptance_criteria": "数据文件存在于 NAS 指定路径",
|
||
"complexity": "simple",
|
||
"implicit": true
|
||
},
|
||
{
|
||
"id": "req-002",
|
||
"description": "编写双均线策略逻辑",
|
||
"type": "coding",
|
||
"acceptance_criteria": "策略代码通过单元测试",
|
||
"complexity": "medium",
|
||
"implicit": false
|
||
},
|
||
{
|
||
"id": "req-003",
|
||
"description": "回测并生成报告",
|
||
"type": "analysis",
|
||
"acceptance_criteria": "回测报告包含收益曲线和关键指标",
|
||
"complexity": "medium",
|
||
"implicit": false
|
||
}
|
||
],
|
||
"inferred_components": ["data", "coding", "analysis"],
|
||
"risk_level": "standard",
|
||
"estimated_tasks": 3
|
||
}
|
||
```
|
||
|
||
#### D4-3：Plan Checker 独立验证
|
||
|
||
> **参考实践**：
|
||
> - **superpowers**：plan-document-reviewer subagent 独立验证方案
|
||
> - **oh-my-claudecode Critic**：预判→验证→自审五阶段
|
||
> - **get-shit-done**：Scope Reduction Detection（完成后反向检查覆盖）
|
||
|
||
Plan Checker 是一个 Subagent（不需要 Agent 身份），Daemon spawn 后执行：
|
||
|
||
```yaml
|
||
# review_protocols/plan_check.yaml
|
||
name: plan_check
|
||
description: "验证庞统的拆解方案是否合理"
|
||
|
||
dimensions:
|
||
- id: coverage
|
||
description: "每个需求是否被至少一个 task 覆盖"
|
||
weight: critical
|
||
method: "需求 ID → task ID 映射矩阵，检查是否有遗漏"
|
||
|
||
- id: dependency
|
||
description: "依赖是否合理"
|
||
weight: critical
|
||
method: "拓扑排序检查无环，前置是否完整"
|
||
|
||
- id: granularity
|
||
description: "粒度是否合适"
|
||
weight: major
|
||
method: "检查每个 task 的 truths 是否是一个 Agent 一次 spawn 能完成的"
|
||
|
||
- id: iron_rules
|
||
description: "铁律是否满足"
|
||
weight: critical
|
||
method: "IR-1: 至少 2 Agent 参与；IR-2: 每个 task 有 truths"
|
||
|
||
- id: risk_alignment
|
||
description: "风险等级是否合理"
|
||
weight: major
|
||
method: "涉及资金/部署 → high；纯分析 → research"
|
||
|
||
output_schema: "schemas/plan-check-output.schema.json"
|
||
verdict_options: ["approved", "needs_revision"]
|
||
```
|
||
|
||
#### D4-4：复杂度驱动的粒度控制
|
||
|
||
> **参考实践**：
|
||
> - **open-multi-agent**：按 complexity 决定是否拆分子任务
|
||
> - **wanman**：Token 预算控制执行深度
|
||
|
||
| 复杂度 | 判断标准 | 拆解策略 | truths 定义 |
|
||
|--------|---------|---------|------------|
|
||
| **simple** | 单一文件、单一操作、< 50 行 | 1 个 task | 1-2 条 truths |
|
||
| **medium** | 多文件、有依赖、需要验证 | 1-3 个 task + 依赖 | 每个 2-3 条 truths |
|
||
| **complex** | 跨模块、多角色、需要调研 | 多 phase 组件组合 | 每个 3-5 条 truths |
|
||
|
||
**粒度自检规则**（庞统的 Skill 中定义）：
|
||
- 一个 task 的 truths > 5 条 → 拆分
|
||
- 一个 task 需要跨 3+ 角色 → 拆分
|
||
- 一个 task 预计 > 30 分钟 → 拆分
|
||
|
||
#### D4-5：用户确认点
|
||
|
||
> **参考实践**：
|
||
> - **get-shit-done**：discuss phase 是必须的用户确认步骤
|
||
> - **v2.0 PRD**：Phase 1 需求探索（苏格拉底对话）
|
||
|
||
不是每步都问用户，但在关键节点确认：
|
||
|
||
| 检查点 | 触发条件 | 用户看到什么 |
|
||
|--------|---------|------------|
|
||
| 需求确认 | Step 1 完成后 | 结构化需求列表 + 隐含需求 |
|
||
| 方案确认 | Step 2 完成后（complex 任务） | 任务列表 + 依赖关系 + 预估时间 |
|
||
|
||
simple 任务跳过方案确认，直接创建。complex 任务必须确认。
|
||
|
||
**用户干预三种模式**（来源：2026 human-in-the-loop 综述 + OpenAI Agents SDK）：
|
||
|
||
| 模式 | 机制 | 适用 |
|
||
|------|------|------|
|
||
| 审批式 | Agent 暂停等用户确认 | high 任务方案确认、部署前 |
|
||
| 通知式 | 推送消息，用户可回复可不回复 | standard 任务产出审查后 |
|
||
| 中断式 | Agent 主动问用户 | 歧义需求、争议仲裁 |
|
||
|
||
**当前落地**：通过庞统 session（webchat/Signal）。**未来**：dashboard Checkpoint 面板。
|
||
|
||
**干预点由 risk_level 动态决定**：low→无干预、standard→通知式、high→审批式、用户随时可中断。
|
||
|
||
---
|
||
|
||
|
||
## Part B：Skill 体系工程落地
|
||
|
||
### 4. 设计目标
|
||
|
||
三个课题产出了大量"Agent 需要知道怎么做"的内容（28 项 Skill TODO），需要一个系统的 Skill 体系来承载。
|
||
|
||
### 5. 核心洞察：被动触发不可靠
|
||
|
||
> **问题**：我们写了好多个 Skill，但除了用户明文指定"用 PAV""用 delegation"，几乎没见哪个 Skill 被主动触发过。
|
||
>
|
||
> **根因**：Agent 不知道自己不知道什么。OpenClaw 的 Skill 列表注入 system prompt 后，Agent 需要自己判断需要哪个——但 Agent 根本不知道"我应该先读一个 Skill 来学怎么做"。
|
||
>
|
||
> **优秀实践验证**：superpowers / GSD / open-multi-agent 没有一个是靠被动 Skill 触发的——全部是编排器构造好 prompt 直接注入。
|
||
|
||
**结论**：moziplus 的关键操作规范不走被动 Skill 发现，走引擎注入。
|
||
|
||
### 5.1 铁律定义（L0 内容）
|
||
|
||
铁律是**所有 Agent 共享的**强制规则，不可定制。角色追加的规则放在 L1（SOUL.md）。
|
||
|
||
| 编号 | 铁律 | 来源 |
|
||
|------|------|------|
|
||
| IR-1 | 每个任务至少 2 个 Agent 参与（做 + 挑战） | v1.0 PRD |
|
||
| IR-2 | 每个 task 必须有 truths（可观测行为标准） | 课题1 must_haves |
|
||
| IR-3 | 结论必须有证据（file:line 或具体引用） | oh-my-claudecode Critic |
|
||
| IR-4 | 语义含糊先确认，不擅自执行 | SOUL.md 底线 |
|
||
| IR-5 | 改代码先改文档（需求→设计→测试→部署） | v1.0 实践 |
|
||
|
||
**Token 估算**：5 条铁律，每条 ~30 token（编号+一句话），总计 ~150 token + XML 包装 ~50 token = **~200 token**。加上角色追加（L1 SOUL.md 已计入），L0 预算 ~200-300 token，远低于 ~500 上限。
|
||
|
||
### 6. 设计决策
|
||
|
||
#### D4-6：四层上下文架构
|
||
|
||
> **参考实践**：
|
||
> - **superpowers**：每个 subagent 有独立 prompt 模板（implementer-prompt.md / spec-reviewer-prompt.md），模板里写死操作步骤
|
||
> - **open-multi-agent**：`buildTaskPrompt()` 拼 task title + description + 依赖产出 + messages
|
||
> - **GSD**：每个 executor 拿到 PLAN.md + PROJECT.md + STATE.md + CONTEXT.md，按 context window 大小自适应
|
||
> - **OpenClaw**：Hook `agent_turn_prepare` 可注入 prependContext/appendContext
|
||
|
||
共同模式：**操作规范（模板）+ 项目背景（固定）+ 任务上下文（动态）**，编排器拼装，不靠 Agent 自己找。
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ Layer 0: 铁律（Iron Rules） │
|
||
│ 机制: OpenClaw Hook agent_turn_prepare │
|
||
│ 保证: 每轮强制注入 | Token: ~500 │
|
||
│ 内容: IR-1~IR-5（每个 Agent 可定制） │
|
||
├─────────────────────────────────────────────────────────────┤
|
||
│ Layer 1: 角色（Agent Identity） │
|
||
│ 机制: SOUL.md + IDENTITY.md + AGENTS.md │
|
||
│ 保证: 每轮强制 | Token: ~2000 │
|
||
│ 内容: 角色定义 + 行为准则 + 记忆 │
|
||
│ 变化频率: 极少（换平台不变） │
|
||
├─────────────────────────────────────────────────────────────┤
|
||
│ Layer 2: 操作规范 + 任务上下文（引擎注入） │
|
||
│ 机制: Daemon spawn 时拼装 bootstrap 消息 │
|
||
│ 保证: 每次 spawn 强制注入 | Token: ~1000-2000 │
|
||
│ 三段式： │
|
||
│ ① 角色操作规范模板（executor.md / reviewer.md / planner.md）│
|
||
│ → 固定部分，写死关键操作步骤（scope/output/handoff等） │
|
||
│ → 变化频率: 很少（moziplus 平台变了才改） │
|
||
│ ② 项目背景（项目路径/框架/NAS/回测服务） │
|
||
│ → 半固定部分，按项目配置 │
|
||
│ ③ 任务上下文（truths/artifacts/constraints + depends_on产出）│
|
||
│ → 动态部分，每次 spawn 不同 │
|
||
├─────────────────────────────────────────────────────────────┤
|
||
│ Layer 3: 参考信息（OpenClaw Skill 被动发现） │
|
||
│ 机制: OpenClaw Skill 列表注入 system prompt │
|
||
│ 保证: ❌ 不保证触发（锦上添花） │
|
||
│ 内容: 具体操作方法（回测流程/数据获取/部署步骤等） │
|
||
│ 优化: description 中加触发场景+示例对话+触发词（见D4-8） │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**张飞编码时靠什么**：
|
||
- L0+L1：身份和纪律（每轮都有）
|
||
- L2 ① executor.md："读黑板→写scope→执行→写output→写Handoff"（引擎注入，不会忘）
|
||
- L2 ③ 任务上下文："这次要做什么、truths 是什么、前序产出是什么"（引擎注入）
|
||
- L3 quant-backtest Skill：具体回测代码怎么写（自己判断要不要读）
|
||
|
||
#### D4-7：L2 引擎注入的拼装原则
|
||
|
||
> **参考实践**：
|
||
> - **superpowers**：implementer/spec-reviewer/code-quality-reviewer 三个独立 prompt 模板，只包含该角色需要的信息
|
||
> - **open-multi-agent**：`buildTaskPrompt()` 只注入依赖链上的产出（default-deny），不是全量
|
||
> - **GSD**：按 context window 大小自适应（200K 只给任务级，1M 给全量）
|
||
|
||
**原则：按角色和任务阶段精确注入，不统一拼装，不多不少。**
|
||
|
||
| Agent 角色 | 注入内容 | 不注入 |
|
||
|-----------|---------|--------|
|
||
| **执行者** | executor.md + Guardrail 配置 + 任务上下文 | Review Protocol |
|
||
| **审查者** | reviewer.md + Review Protocol + required_reading | Guardrail 配置 |
|
||
| **庞统（规划）** | planner.md + template_components + Plan Checker | Review Protocol |
|
||
| **庞统（裁决）** | adjudicator.md + 正方 comment + 反方 comment | Guardrail 配置 |
|
||
| **反驳者** | rebuttal.md + 审查者 review + ACCEPT/REJECT 指令 | Review Protocol |
|
||
| **Plan Checker** | plan_checker.md + 需求列表 + 拆解方案 | 全部角色模板 |
|
||
|
||
**拼装逻辑**（Daemon 代码）：
|
||
```python
|
||
def build_bootstrap(agent_id, role, task):
|
||
parts = []
|
||
|
||
# ① 角色操作规范模板
|
||
template = load_template(f"prompt_templates/{role}.md")
|
||
parts.append(template)
|
||
|
||
# ② 项目背景（半固定）
|
||
parts.append(format_project_context(task))
|
||
|
||
# ③ 任务上下文（动态）
|
||
parts.append(format_task_context(task))
|
||
|
||
# 按角色追加（只注入该角色需要的）
|
||
if role == "executor":
|
||
parts.append(format_guardrails(task.task_type))
|
||
elif role == "reviewer":
|
||
parts.append(format_review_protocol(task.review_type))
|
||
parts.append(format_required_reading(task))
|
||
elif role == "planner":
|
||
parts.append(format_template_components())
|
||
elif role == "rebuttal":
|
||
parts.append(format_review_to_respond(task))
|
||
|
||
return "\n\n".join(parts)
|
||
```
|
||
|
||
#### D4-8：L3 Skill 被动触发的优化写法
|
||
|
||
> **参考实践**：
|
||
> - **superpowers code-reviewer**：description 里嵌入 `<example>` 标签，用对话示例教 Agent 触发场景
|
||
> - **wiki-query**：description 里加 Chinese/English triggers 列表
|
||
> - **gstack plan-design-review**：加 `Proactively suggest when...` 指令
|
||
> - **SkillRouter 论文**（2026）：Agent 自主搜索（agentic）比纯关键词/纯语义准确率最高
|
||
|
||
即使 L3 不保证触发，也要优化写法提高命中率。**moziplus 的 Skill 全部按以下规范写 description**：
|
||
|
||
```yaml
|
||
---
|
||
name: quant-backtest
|
||
description: >
|
||
标准化量化回测技能。
|
||
|
||
When to use: 当需要回测量化策略、验证策略历史表现、测试策略参数时。
|
||
|
||
Chinese triggers: 回测、backtest、策略测试、历史表现验证、参数优化。
|
||
English triggers: backtest, strategy test, historical performance, parameter optimization.
|
||
|
||
Proactively suggest when: 用户提到策略实现完成后，主动建议运行回测验证。
|
||
|
||
Example: user says "帮我测一下双均线策略" → use quant-backtest skill.
|
||
---
|
||
```
|
||
|
||
**description 四要素**：
|
||
1. **功能描述**：这个 Skill 干什么
|
||
2. **触发场景**（When to use）：什么情况下该用
|
||
3. **触发词**（Chinese/English triggers）：中英文关键词
|
||
4. **主动建议**（Proactively suggest）：Agent 看到相关场景时主动推荐
|
||
|
||
#### D4-9：Skill 诚实边界
|
||
|
||
> **参考实践**：nuwa-skill Agentic Protocol 要求每个 Skill 声明自己做不到什么
|
||
|
||
每个 Skill 必须包含 `## 诚实边界` section：
|
||
|
||
```markdown
|
||
## 诚实边界
|
||
- 本 Skill 不覆盖实盘交易逻辑（实盘请参考 live-trading Skill）
|
||
- 性能问题需要实际测试数据，纯代码审查无法确认
|
||
- 复杂策略可能需要拆分为多个 task
|
||
```
|
||
|
||
#### D4-10：moziplus 目录结构
|
||
|
||
```
|
||
sanguo_moziplus/
|
||
prompt_templates/ ← L2 ① 角色操作规范（Daemon 读取拼装）
|
||
executor.md ← 执行者操作步骤（读黑板→scope→执行→output→handoff）
|
||
reviewer.md ← 审查者操作步骤（读Protocol→审查→写review）
|
||
planner.md ← 庞统拆解步骤（需求结构化→组件选择→PlanChecker）
|
||
adjudicator.md ← 庞统裁决步骤（正方反方→判断→写决策）
|
||
rebuttal.md ← 反驳步骤（读review→ACCEPT/REJECT/PARTIAL）
|
||
plan_checker.md ← Plan Checker 步骤（覆盖性→依赖→粒度→铁律）
|
||
|
||
review_protocols/ ← L2 审查协议（Daemon 构造 reviewer bootstrap 时读取）
|
||
plan_review.yaml ← 方案审查协议
|
||
output_review.yaml ← 产出审查协议
|
||
guardrail_l2.yaml ← L2 轻量AI检查协议
|
||
analysis_review.yaml ← 分析审查协议
|
||
plan_check.yaml ← Plan Checker 协议
|
||
|
||
schemas/ ← CLI 层 Schema 校验（blackboard.py 读取）
|
||
handoff.schema.json ← Handoff 格式校验
|
||
output.schema.json ← Output 格式校验
|
||
decide.schema.json ← Decision 格式校验
|
||
observe.schema.json ← Observation 格式校验
|
||
review-output.schema.json ← Review 格式校验
|
||
|
||
template_components.yaml ← 模板组件库（庞统拆解时参考）
|
||
guardrails.yaml ← 声明式 Guardrail（Daemon 执行检查）
|
||
project_context.yaml ← L2 ② 项目背景（NAS路径/回测服务/框架）
|
||
```
|
||
|
||
**各目录作用**：
|
||
|
||
| 目录/文件 | 谁读 | 作用 | 变化频率 |
|
||
|----------|------|------|----------|
|
||
| `prompt_templates/` | Daemon | 按 Agent 角色拼装 bootstrap 消息 | 很少变 |
|
||
| `review_protocols/` | Daemon | 构造审查者的 bootstrap 消息 | 偶尔变 |
|
||
| `schemas/` | blackboard.py CLI | 写入时校验数据格式 | 偶尔变 |
|
||
| `template_components.yaml` | 庞统（通过 L2 注入） | 拆解需求时选择组件 | 偶尔变 |
|
||
| `guardrails.yaml` | Daemon | 自动检查产出 | 偶尔变 |
|
||
| `project_context.yaml` | Daemon | 拼装项目背景信息 | 换项目时变 |
|
||
|
||
**注意**：Agent 不直接读这些文件——全部由 Daemon 读取后拼装到 bootstrap 消息中注入。
|
||
|
||
#### D4-11：L2 引擎注入示例（张飞编码场景）
|
||
|
||
Daemon spawn 张飞时拼装的完整 bootstrap 消息：
|
||
|
||
```
|
||
═══ 操作规范（executor.md 模板）═══
|
||
|
||
你是任务执行者。按以下步骤工作：
|
||
|
||
## 1. 理解任务
|
||
- 读黑板任务详情（blackboard.py read --task {task_id}）
|
||
- 理解 truths（可观测行为标准）、artifacts（必须产出）、constraints（约束）
|
||
|
||
## 2. 声明范围
|
||
- 写 scope_declaration（blackboard.py decide --task {task_id} --decider zhangfei-dev）
|
||
- 格式：{"decision": "我计划做什么", "rationale": "为什么", "artifacts": ["路径"]}
|
||
|
||
## 3. 执行工作
|
||
- 按你的专业能力完成任务
|
||
- 发现风险 → blackboard.py observe --task {task_id} --severity warning
|
||
- 需要协作 → blackboard.py comment --task {task_id} @mention
|
||
|
||
## 4. 提交产出
|
||
- blackboard.py output --task {task_id} --summary "一句话" --content-path "文件路径"
|
||
|
||
## 5. 写交接
|
||
- blackboard.py comment --task {task_id} --author zhangfei-dev \
|
||
--handoff '{"completed":"...", "artifacts":["..."]}'
|
||
|
||
## 6. 通知引擎
|
||
- 写 inbox 文件通知 Daemon 完成
|
||
|
||
═══ 项目背景（project_context.yaml）═══
|
||
|
||
项目：sanguo_quant_live
|
||
框架：vnpy
|
||
NAS 数据：/Volumes/stock/
|
||
回测服务：http://192.168.2.154:8088
|
||
编码规范：类型注解必须、禁止 any、match 现有风格
|
||
|
||
═══ 任务上下文（黑板动态读取）═══
|
||
|
||
任务 ID: task-001
|
||
任务标题: 实现双均线策略
|
||
truths: ["策略代码通过单元测试", "回测结果包含收益曲线"]
|
||
artifacts: ["task-001/strategy.py", "task-001/backtest_report.pdf"]
|
||
constraints: ["使用 vnpy 框架", "不超过 500 行"]
|
||
risk_level: standard
|
||
|
||
═══ 前序信息（depends_on 产出）═══
|
||
|
||
[赵云 Handoff] 完成了分钟线数据下载，产出 task-000/data/
|
||
数据路径: /Volumes/stock/min_data/IF888.csv
|
||
|
||
═══ 可选参考 ═══
|
||
|
||
如果需要具体操作方法，用 read 加载：
|
||
- 编码：~/.openclaw/skills/coding-implementation/SKILL.md
|
||
- 回测：~/.openclaw/skills/quant-backtest/SKILL.md
|
||
```
|
||
|
||
**对比审查者（司马懿）收到的 bootstrap**：
|
||
|
||
```
|
||
═══ 操作规范（reviewer.md 模板）═══
|
||
|
||
你是质量审查者。按 Review Protocol 执行审查：
|
||
|
||
## 审查步骤
|
||
1. 预判：先不读产出，预测 3-5 个最可能出问题的点
|
||
2. 验证：读实际产出（不是报告），逐条验证每个 truth
|
||
3. 多视角：从安全/新人/运维三个角度看产出
|
||
4. 缺口分析：不只看"什么有问题"，还看"什么缺失了"
|
||
5. 自审：给每个 finding 打 confidence，低 confidence 降级
|
||
|
||
## 写 Review
|
||
- blackboard.py review --task {task_id} --verdict [approved|rejected|needs_revision] ...
|
||
|
||
[... 对抗性指令 ...]
|
||
|
||
═══ Review Protocol（output_review.yaml）═══
|
||
|
||
[审查维度、方法、输出 Schema 等详细协议内容]
|
||
|
||
═══ 任务上下文 ═══
|
||
[同上]
|
||
|
||
═══ Required Reading ═══
|
||
- 执行者 scope_declaration: ...
|
||
- 产出物: task-001/strategy.py
|
||
- must_haves truths: [...]
|
||
```
|
||
|
||
---
|
||
|
||
## 7. 和现有设计的对齐检查
|
||
|
||
| 已有设计 | 课题4 补充 | 一致性 |
|
||
|---------|-----------|--------|
|
||
| §3.2 tasks 表 schema | D4-1 模板组件输出 → tasks 写入 | ✅ truths/artifacts/constraints/risk_level/depends_on 对齐 |
|
||
| §9.2 分级审查矩阵 | D4-4 复杂度→粒度控制 | ✅ risk_level 在创建时标注 |
|
||
| §4.2 Tick+Inbox | D4-1 Step 4 创建任务后 Daemon tick 检测 | ✅ 创建是事件源 |
|
||
| §9.4 Review Protocol Registry | D4-10 review_protocols/ 目录 | ✅ Daemon 构造审查者 bootstrap 时读取 |
|
||
| §9.9 Agent vs Subagent | D4-3 Plan Checker 走 Subagent | ✅ 无身份一次性检查 |
|
||
| Skill TODO 28项 | D4-10 prompt_templates/ 承载关键操作 | ✅ S-01~S-28 的关键操作写死在模板中 |
|
||
|
||
## 8. 遗留 TODO
|
||
|
||
| # | 待解决事项 | 归属 | 说明 |
|
||
|---|----------|------|------|
|
||
| ~~T4-1~~ | ~~template_components.yaml 完整定义~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-2~~ | ~~Plan Checker 的 plan_check.yaml 实现~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-3~~ | ~~prompt_templates/ 编写~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-4~~ | ~~project_context.yaml 定义~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-5~~ | ~~Daemon build_bootstrap() 拼装逻辑~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-6~~ | ~~铁律 Hook 实现（L0）~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-7~~ | ~~现有 Skill description 优化（加四要素）~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-8~~ | ~~Skill 诚实边界补充~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
|
||
| ~~T4-9~~ | ~~Skill 测试框架~~ | ~~Phase 3~~ | ➡️ 移至工具链课题（开发工具链的一部分，不属于拆解机制） |
|
||
| ~~T4-10~~ | ~~Skill 进化/蒸馏机制~~ | ~~Phase 3~~ | ➡️ 合并进课题6（经验→Skill的进化是经验沉淀闭环，课题6已有两级蒸馏+Skill生命周期） |
|