From f1d87f2653d17e0239e12045fc30b787079b7f2b Mon Sep 17 00:00:00 2001 From: cfdaily Date: Fri, 15 May 2026 21:52:01 +0800 Subject: [PATCH] auto-sync: 2026-05-15 21:52:01 --- docs/design/topic4-skill-checklist-draft.md | 96 +++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 docs/design/topic4-skill-checklist-draft.md diff --git a/docs/design/topic4-skill-checklist-draft.md b/docs/design/topic4-skill-checklist-draft.md new file mode 100644 index 0000000..c1a5951 --- /dev/null +++ b/docs/design/topic4-skill-checklist-draft.md @@ -0,0 +1,96 @@ +# 课题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. 三者的关系和优先级