sanguo/sanguo_moziplus_v2
9
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

auto-sync: 2026-05-31 13:01:46 (catch-all)

Browse Source
This commit is contained in:
cfdaily
2026-05-31 13:01:46 +08:00
parent 49d342d72e
commit 83a6bbf942
1 changed files with 33 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design/03-prompt-evolution.md
+33 -33
View File
@@ -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。建议只有领域有实际交叉时才写。