From 83a6bbf9429b267a14889c864fd183387ae45c17 Mon Sep 17 00:00:00 2001 From: cfdaily Date: Sun, 31 May 2026 13:01:46 +0800 Subject: [PATCH] auto-sync: 2026-05-31 13:01:46 (catch-all) --- docs/design/03-prompt-evolution.md | 66 +++++++++++++++--------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/docs/design/03-prompt-evolution.md b/docs/design/03-prompt-evolution.md index 5245325..3adb4b9 100644 --- a/docs/design/03-prompt-evolution.md +++ b/docs/design/03-prompt-evolution.md @@ -125,18 +125,18 @@ Agent 在执行过程中静默丢弃需求是常见问题--不说不做,只是 {task_list} ## 你的角色 -你收到团队广播。按你的专业判断回应： +你收到团队广播。按你的专业判断回应: 1. 有属于你专业的任务 → 认领并执行 2. 不是你的活,但你的专业领域和这个任务有实际交叉 → 写 observation comment - - 从你的专业视角：你看到什么风险?什么约束?什么跨领域建议? - - 例：关羽看到编码任务 → "这个函数涉及风控计算,建议用 decimal 而非 float" - - 例：赵云看到编码任务 → "这个策略需要分钟线数据,NAS路径 /Volumes/stock/min" + - 从你的专业视角:你看到什么风险?什么约束?什么跨领域建议? + - 例:关羽看到编码任务 → "这个函数涉及风控计算,建议用 decimal 而非 float" + - 例:赵云看到编码任务 → "这个策略需要分钟线数据,NAS路径 /Volumes/stock/min" - observation 限 200 字 3. 你的领域和任务无交叉 → NO_REPLY ### Alignment: 理解全局再行动 -认领前先读黑板上的其他 comment（expand=all 会返回），理解这个任务在整个项目中的位置。如果黑板上有内容就读，没有就直接认领，不要为了 Alignment 强行多发 API 请求。 +认领前先读黑板上的其他 comment(expand=all 会返回),理解这个任务在整个项目中的位置。如果黑板上有内容就读,没有就直接认领,不要为了 Alignment 强行多发 API 请求。 ## API - 读任务详情: GET {api_base}/projects/{project_id}/tasks/{{TASK_ID}}?expand=all @@ -191,9 +191,9 @@ Agent 在执行过程中静默丢弃需求是常见问题--不说不做,只是 动手前先读黑板上的全局计划和其他 Agent 的 comment,理解你的任务在整个目标中的位置,再决定怎么做。 ### 复杂任务: 先计划后执行 -如果任务复杂(涉及多个文件、多个模块、或你有不确定的地方),先在黑板 comment 写出你的执行计划,等确认后再动手。简单任务直接做。 +如果任务复杂(涉及多个文件、多个模块、或你有不确定的地方),先在黑板 comment 写出你的执行计划。如果计划写了 5 分钟内没有人提出异议,按计划执行。如果有人提出异议,调整后再执行。简单任务直接做。 -## 什么算"做完了" +## 什么算“做完了” 1. 产出物已写入黑板(output),有实际内容 2. 状态改为 review 3. 写了 handoff comment:你做了什么决策、为什么、踩了什么坑、给下一个人什么建议 @@ -474,88 +474,88 @@ v1.x 的所有基础设施(counter、router、spawner、bootstrap)完全复用, --- -## 八、第二波 AI Native 实践（v3.0 新增） +## 八、第二波 AI Native 实践(v3.0 新增) 在 v2.1 的基础上,从调研报告中进一步提炼 5 个尚未借蘫但高价值的实践。以下全部已融入对应模板。 -### 8.1 Boids 群体智能: Alignment（理解全局再行动） +### 8.1 Boids 群体智能: Alignment(理解全局再行动) **来源**: ClawTeam #5 Boids 群体智能规则 -**问题**: v2.1 的三级响应解决了 Separation（不抢活）和 Cohesion（贡献 observation）,但缺了 Alignment——Agent 认领任务后不读黑板就开干,可能做出和全局方向不一致的决策。 +**问题**: v2.1 的三级响应解决了 Separation(不抢活)和 Cohesion(贡献 observation),但缺了 Alignment--Agent 认领任务后不读黑板就开干,可能做出和全局方向不一致的决策。 -**做法**: 在 claim prompt 和 executor.md 中各加一句“先读黑板理解全局再行动”。具体措辞： -- claim prompt: “认领前先读黑板上的其他 comment,理解这个任务在整个项目中的位置” -- executor.md: “动手前先读黑板上的全局计划和其他 Agent 的 comment,理解你的任务在整个目标中的位置” +**做法**: 在 claim prompt 和 executor.md 中各加一句"先读黑板理解全局再行动"。具体措辞: +- claim prompt: "认领前先读黑板上的其他 comment,理解这个任务在整个项目中的位置" +- executor.md: "动手前先读黑板上的全局计划和其他 Agent 的 comment,理解你的任务在整个目标中的位置" **影响**: +30 token / Agent,但减少因信息不对称导致的返工。净值正。 -### 8.2 Scope Reduction Detection（反静默降级） +### 8.2 Scope Reduction Detection(反静默降级) **来源**: get-shit-done Scope Reduction Detection -**问题**: Agent 在执行/审查过程中可能静默丢弃需求——不说不做,只是悄悄缩小范围。这是多 Agent 系统中常见的质量问题,比直接拒绝更危险,因为更难发现。 +**问题**: Agent 在执行/审查过程中可能静默丢弃需求--不说不做,只是悄悄缩小范围。这是多 Agent 系统中常见的质量问题,比直接拒绝更危险,因为更难发现。 -**做法**: 在 reviewer.md 和 review_pangtong.md 中加入显式检查项： +**做法**: 在 reviewer.md 和 review_pangtong.md 中加入显式检查项: ```markdown -## Scope Reduction Detection（反静默降级） +## Scope Reduction Detection(反静默降级) 对照原始需求,检查: - 有没有需求被静默丢弃或降级? - 产出声称覆盖的范围和实际一致吗? - 如果发现需求消失,明确指出并标记 ``` -**影响**: 审查 prompt 增加 ~80 token。但这是质量门控的关键补充——当前审查只看“做的好不好”,不看“有没有悄悄少做”。 +**影响**: 审查 prompt 增加 ~80 token。但这是质量门控的关键补充--当前审查只看"做的好不好",不看"有没有悄悄少做"。 -**与 P6（反静默降级原则）呼应**: 这是 P6 的具体落地。 +**与 P6(反静默降级原则)呼应**: 这是 P6 的具体落地。 -### 8.3 Plan 审批工作流（复杂任务先计划后执行） +### 8.3 Plan 审批工作流(复杂任务先计划后执行) **来源**: ClawTeam #14 Plan 审批工作流 -**问题**: 当前 executor 模板对所有复杂度的任务一视同仁——都直接执行。复杂任务（多文件、多模块、不确定方案）直接开工容易走偏。 +**问题**: 当前 executor 模板对所有复杂度的任务一视同仁--都直接执行。复杂任务(多文件、多模块、不确定方案)直接开工容易走偏。 -**做法**: 在 executor.md 中加入分级引导： +**做法**: 在 executor.md 中加入分级引导: ```markdown ### 复杂任务: 先计划后执行 如果任务复杂(涉及多个文件、多个模块、或你有不确定的地方),先在黑板 comment 写出你的执行计划,等确认后再动手。简单任务直接做。 ``` -**设计决策**: 不在 ticker 层面做 risk_level 分支（那需要改 spawner/ticker 代码）,而是让 Agent 自己判断复杂度。理由： +**设计决策**: 不在 ticker 层面做 risk_level 分支(那需要改 spawner/ticker 代码),而是让 Agent 自己判断复杂度。理由: 1. Agent 有 SOUL.md 和上下文,比代码更能判断复杂度 2. 不增加基础设施改动 -3. 如果 Agent 判断失误（该计划没计划）,审查者的 Scope Reduction Detection 会兜住 +3. 如果 Agent 判断失误(该计划没计划),审查者的 Scope Reduction Detection 会兜住 **影响**: executor.md +50 token。 -### 8.4 经验闭环引导（handoff 中标注经验） +### 8.4 经验闭环引导(handoff 中标注经验) **来源**: 知识管理体系 DISCOVER→DISTILL→APPLY→IMPROVE **问题**: 当前 Agent 的经验沉淀在各人的 MEMORY.md / .learnings/ 中,是自发行为,不成体系。Trajectory Distillation 项目正在批量处理历史数据,但实时经验没有采集机制。 -**做法**: 在 executor.md 的“什么算做完了”中加入： +**做法**: 在 executor.md 的"什么算做完了"中加入: ```markdown -4. 如果有值得记录的经验(被纠正、发现更好做法),在 handoff 中标注“💡 经验:...” +4. 如果有值得记录的经验(被纠正、发现更好做法),在 handoff 中标注"💡 经验:..." ``` -**设计决策**: 不做复杂的经验采集流程（那需要改黑板 API 加 experience 表）,而是在 handoff comment 中用前缀“💡 经验:”标记。未来 Trajectory Distillation 可以扫描这个标记。 +**设计决策**: 不做复杂的经验采集流程(那需要改黑板 API 加 experience 表),而是在 handoff comment 中用前缀"💡 经验:"标记。未来 Trajectory Distillation 可以扫描这个标记。 **影响**: executor.md +30 token。零基础设施改动。 -### 8.5 /goal Ralph Loop（持久目标保持）——暂不实施 +### 8.5 /goal Ralph Loop(持久目标保持)--暂不实施 **来源**: Hermes v0.13 /goal Ralph Loop -**问题**: 庞统在多轮 tick 之间没有持久的目标上下文。每轮广播都是无状态的——Agent 不知道“这个项目在做什么,已经做到哪了”。 +**问题**: 庞统在多轮 tick 之间没有持久的目标上下文。每轮广播都是无状态的--Agent 不知道"这个项目在做什么,已经做到哪了"。 -**做法（未来方向）**: ticker 在构建 claim prompt 时注入项目级别的 context（项目目标、已完成的任务摘要、当前阻塞点）。这需要 ticker 有一个项目级的 context 缓存。 +**做法(未来方向)**: ticker 在构建 claim prompt 时注入项目级别的 context(项目目标、已完成的任务摘要、当前阻塞点)。这需要 ticker 有一个项目级的 context 缓存。 -**暂不实施理由**: 需要 ticker 层面改动（加 context 缓存逻辑）,超出 prompt 模板范围。记录在此作为 Phase 4 候选。 +**暂不实施理由**: 需要 ticker 层面改动(加 context 缓存逻辑),超出 prompt 模板范围。记录在此作为 Phase 4 候选。 --- -## 附录 A：司马懿 v2.1 评审意见及回应（2026-05-31） +## 附录 A:司马懿 v2.1 评审意见及回应(2026-05-31) **司马懿原文**:observation 要有明确触发条件,不是"有专业判断就写"。纯粹不匹配(如司马懿看编码任务)应 NO_REPLY。建议只有领域有实际交叉时才写。