cfdaily
97 lines
5.4 KiB
Markdown
97 lines
5.4 KiB
Markdown
# 课题4 Skill 设计清单（草稿）
|
||
|
||
**背景**：三个课题（1/2/3）产出了27项设计决策，其中大量内容需要 Agent 在 Skill 层面"知道怎么做"。当前 TODO 只列了4项（T1-5/6/7 + T2-8），远不够。
|
||
|
||
## 一、按角色分类的 Skill 需求
|
||
|
||
### 1. 所有 Agent 通用 Skill
|
||
|
||
| # | Skill 内容 | 来源 | 说明 |
|
||
|---|-----------|------|------|
|
||
| S-01 | blackboard.py CLI 使用手册 | 课题1 §5.2 | 所有黑板操作的 CLI 命令、参数、Schema 校验说明 |
|
||
| S-02 | 读黑板 L1 消息 → 判断是否需要 L2/L3 | 课题2 §4.4 | Agent 收到 L1 后自主决定信息是否足够，不够就主动调 L2/L3 |
|
||
| S-03 | 写 Handoff Comment | 课题2 §5.1 | 结束前必须写结构化交接（强烈建议，不强制） |
|
||
| S-04 | 读 Handoff Comment | 课题2 §5.1 | 收到上一个 Agent 的 Handoff 后如何利用 |
|
||
| S-05 | 写 observation 的时机和格式 | 课题1 §4.7 | 工作中发现风险时主动写 observation + severity |
|
||
| S-06 | 写 decision 的时机和格式 | 课题1 §9.4 | 每个关键决策必须记录，哪怕是自己的决策 |
|
||
| S-07 | 写 output 的 Schema 约束 | 课题2 §3.7 | --output 必须有 summary + content_path，CLI 校验 |
|
||
| S-08 | 收到 Guardrail 打回时的处理 | 课题3 §9.3 | L1 机械失败→修改重提交；L2 语义问题→评估是否合理 |
|
||
| S-09 | @mention 的使用规范 | 课题1 §5.2 | 需要协作时 @mention + 附带上下文 |
|
||
|
||
### 2. 执行者 Agent（张飞/关羽/赵云/姜维）
|
||
|
||
| # | Skill 内容 | 来源 | 说明 |
|
||
|---|-----------|------|------|
|
||
| S-10 | claim 任务后写 scope_declaration | 课题1 §4.7 | "我计划做什么、产出什么"，格式和内容要求 |
|
||
| S-11 | scope_declaration 的格式 | 课题1 T1-5 | truths 字段格式、声明方式 |
|
||
| S-12 | 收到 review needs_revision 时的处理 | 课题3 §9.5 | 读 issues → 逐条 ACCEPT/REJECT/PARTIAL，写 comment 回应 |
|
||
| S-13 | 收到 Guardrail reject 的处理 | 课题3 §9.8 | 理解 assert 失败原因，修改重提交 |
|
||
| S-14 | must_haves 三件套理解 | 课题1 §9 | truths/artifacts/constraints 的含义和自检方法 |
|
||
|
||
### 3. 审查者 Agent（司马懿 + 挑战者池）
|
||
|
||
| # | Skill 内容 | 来源 | 说明 |
|
||
|---|-----------|------|------|
|
||
| S-15 | 收到 Review Protocol 后的审查流程 | 课题3 §9.4 | 五阶段 Investigation Protocol 的执行方法 |
|
||
| S-16 | 多视角审查方法 | 课题3 §9.4 | 代码视角（安全/新人/运维）、方案视角（执行者/利益相关者/怀疑论者） |
|
||
| S-17 | 写 review 的 Schema 约束 | 课题3 §9.6 | verdict 必须是枚举，issues 必须有 evidence |
|
||
| S-18 | 信心度自评方法 | 课题3 §9.6 | confidence 打分标准，< 0.7 意味着什么 |
|
||
| S-19 | 收到反驳（REJECT）后的处理 | 课题3 §9.5 | 评估执行者的反驳是否合理，决定坚持还是让步 |
|
||
| S-20 | plan_review 协议 | 课题3 §9.4 | 假设提取+评级、pre-mortem、依赖审计、歧义扫描 |
|
||
| S-21 | output_review 协议 | 课题3 §9.4 | 需求追踪、scope 对齐、正确性验证、缺口分析 |
|
||
| S-22 | analysis_review 协议 | 课题3 §9.4 | 逻辑跳跃、无支撑结论、数据来源可靠性 |
|
||
|
||
### 4. 协调者 Agent（庞统）
|
||
|
||
| # | Skill 内容 | 来源 | 说明 |
|
||
|---|-----------|------|------|
|
||
| S-23 | 创建任务时的 truths/artifacts/constraints 定义 | 课题1 §9 | 用户视角的可观测行为、必须存在的文件、继承的约束 |
|
||
| S-24 | 风险等级自动判断 | 课题3 §9.2 | task_type→risk_level 的映射规则 |
|
||
| S-25 | 挑战者选择策略 | 课题3 §9.10 | 按任务类型选挑战者（编码→司马懿、风控→关羽、数据→赵云、部署→姜维） |
|
||
| S-26 | 对抗辩论裁决方法 | 课题3 §9.10 | 综合正方反方观点做最终判断 |
|
||
| S-27 | escalated 任务的用户沟通 | 课题3 §9.7 | 超轮次升级时如何向用户呈现争议和选项 |
|
||
| S-28 | confidence 低时的升级判断 | 课题3 T3-5 | confidence < 0.7 时升级策略 |
|
||
| S-29 | 任务拆解方法 | 课题1 §5.1 | 复杂任务如何拆成子任务，依赖如何声明 |
|
||
| S-30 | L1 消息构建逻辑 | 课题2 §4.4 | 给 Agent spawn 时的 bootstrap 消息拼装 |
|
||
|
||
## 二、按阶段分类
|
||
|
||
### Phase 1 必须有（Agent 能基本工作）
|
||
|
||
- S-01 blackboard.py CLI 使用手册
|
||
- S-03 写 Handoff Comment
|
||
- S-10 claim 后写 scope_declaration
|
||
- S-14 must_haves 理解
|
||
- S-23 创建任务（庞统）
|
||
- S-24 风险等级判断（庞统）
|
||
- S-30 L1 消息构建（庞统/Daemon）
|
||
|
||
### Phase 2 必须有（审查体系生效）
|
||
|
||
- S-02 L2/L3 按需读取
|
||
- S-04 读 Handoff Comment
|
||
- S-05/06 observation/decision 写入
|
||
- S-07 output Schema 约束
|
||
- S-12 收到 review 的处理（反驳权）
|
||
- S-15~22 审查者全套 Skill
|
||
- S-25 挑战者选择（庞统）
|
||
- S-26 对抗辩论裁决（庞统）
|
||
|
||
### Phase 3 可选（高级功能）
|
||
|
||
- S-16 多视角审查深化
|
||
- S-20~22 三种审查协议细化
|
||
- S-27 escalated 用户沟通
|
||
- S-28 confidence 升级策略
|
||
- S-29 任务拆解方法深化
|
||
|
||
## 三、和现有 TODO 的对齐
|
||
|
||
课题4 的 Skill 设计需要覆盖以上 30 项。现有的 T1-5/6/7 和 T2-8 只是其中4项。
|
||
|
||
建议：课题4 的正式设计把这 30 项整理成 Skill 体系文档，明确：
|
||
1. 哪些是 Skill 文件（Agent 读的 Markdown）
|
||
2. 哪些是 Protocol 文件（Daemon 注入的 YAML）
|
||
3. 哪些是 CLI 帮助信息（blackboard.py --help）
|
||
4. 三者的关系和优先级
|