auto-sync: 2026-05-31 11:44:03 (catch-all)
This commit is contained in:
cfdaily
+189
-192
@@ -1,22 +1,22 @@
|
||||
# 03-prompt-evolution.md — Prompt 进化 v2.0：从 SOP 到任务式指挥
|
||||
# 03-prompt-evolution.md - Prompt 进化 v2.0:从 SOP 到任务式指挥
|
||||
|
||||
**日期**: 2026-05-31
|
||||
**作者**: 庞统
|
||||
**状态**: v2.1 修订中（司马懿评审意见已纳入）
|
||||
**状态**: v2.1 修订中(司马懿评审意见已纳入)
|
||||
**前置**: `02-main-session-delegation.md`、`04-blackboard-collaboration-model.md`
|
||||
**参考**: PRD v3.0（B3 共享意识）、shared-consciousness-research.md
|
||||
**参考**: PRD v3.0(B3 共享意识)、shared-consciousness-research.md
|
||||
|
||||
---
|
||||
|
||||
## 一、v1.x 的核心问题：SOP 模式
|
||||
## 一、v1.x 的核心问题:SOP 模式
|
||||
|
||||
v1.0 → v1.1 做了统一三段式、身份注入、去 curl 等改进，但**模式没变**——仍然是用 prompt 写 SOP（标准操作流程）。
|
||||
v1.0 → v1.1 做了统一三段式、身份注入、去 curl 等改进,但**模式没变**--仍然是用 prompt 写 SOP(标准操作流程)。
|
||||
|
||||
### 症状
|
||||
|
||||
| Prompt | v1.x 行为 | 本质 |
|
||||
|--------|----------|------|
|
||||
| `_build_claim_prompt` | "只认领符合专长的任务" / "没有适合你的任务则 NO_REPLY" | 二元开关：要么 claim 要么闭嘴 |
|
||||
| `_build_claim_prompt` | "只认领符合专长的任务" / "没有适合你的任务则 NO_REPLY" | 二元开关:要么 claim 要么闭嘴 |
|
||||
| `executor.md` | 操作步骤列表 + 纪律条目 | 操作手册 |
|
||||
| `reviewer.md` | 审查要点 checklist | QA 表格 |
|
||||
| `review_simayi.md` | "审查层级由 risk_level 决定" | 规则查表 |
|
||||
@@ -24,18 +24,18 @@ v1.0 → v1.1 做了统一三段式、身份注入、去 curl 等改进，但**
|
||||
|
||||
### 根因
|
||||
|
||||
> **我们把状态机从 Python 代码搬到了 prompt 里。** Agent 的行为是确定性的：看规则 → 匹配 → 执行固定步骤。和 v1.0 的确定性引擎没有本质区别，只是换了个载体。
|
||||
> **我们把状态机从 Python 代码搬到了 prompt 里。** Agent 的行为是确定性的:看规则 → 匹配 → 执行固定步骤。和 v1.0 的确定性引擎没有本质区别,只是换了个载体。
|
||||
|
||||
这直接违背了 PRD B2（编排层应该是 AI 指挥官）和 B3（Agent 共享意识，不传消息）：
|
||||
这直接违背了 PRD B2(编排层应该是 AI 指挥官)和 B3(Agent 共享意识,不传消息):
|
||||
|
||||
- B3 说"所有 Agent 共享一个实时信息空间"——但当前广播 prompt 让不匹配的 Agent NO_REPLY，等于**消灭了信息**
|
||||
- PRD §3.2 的理想画面是"赵云看到策略任务，主动说数据有缺失"——但当前 prompt 让赵云直接闭嘴
|
||||
- B3 说"所有 Agent 共享一个实时信息空间"--但当前广播 prompt 让不匹配的 Agent NO_REPLY,等于**消灭了信息**
|
||||
- PRD §3.2 的理想画面是"赵云看到策略任务,主动说数据有缺失"--但当前 prompt 让赵云直接闭嘴
|
||||
|
||||
### 优秀实践的对比
|
||||
|
||||
| 维度 | SOP 模式（当前） | 任务式指挥（目标） | 来源 |
|
||||
| 维度 | SOP 模式(当前) | 任务式指挥(目标) | 来源 |
|
||||
|------|-----------------|-------------------|------|
|
||||
| 指令方式 | 告诉步骤 | 告诉目标 + 约束，Agent 自主决定步骤 | ClawTeam Auftragstaktik |
|
||||
| 指令方式 | 告诉步骤 | 告诉目标 + 约束,Agent 自主决定步骤 | ClawTeam Auftragstaktik |
|
||||
| Agent 间信息 | 只有执行者发言 | 每个 Agent 贡献专业判断 | bMAS 共享黑板 |
|
||||
| 质量保障 | Checklist 穷举 | 挑战者思维 + 置信度自评 | ClawTeam 元认知 |
|
||||
| 规划方式 | Phase 查表 | 理解需求 → 拆解 → 动态调整 | PRD B2 |
|
||||
@@ -45,70 +45,70 @@ v1.0 → v1.1 做了统一三段式、身份注入、去 curl 等改进，但**
|
||||
|
||||
## 二、设计原则
|
||||
|
||||
### P1. Auftragstaktik（任务式指挥）
|
||||
### P1. Auftragstaktik(任务式指挥)
|
||||
|
||||
告诉 Agent **Intent（意图）→ End State（终态）→ Constraints（约束）**，不告诉步骤。
|
||||
告诉 Agent **Intent(意图)→ End State(终态)→ Constraints(约束)**,不告诉步骤。
|
||||
|
||||
Agent 有 SOUL.md、workspace、工具能力，不需要手把手教。Prompt 定义"什么算做完了"，Agent 自己决定怎么做。
|
||||
Agent 有 SOUL.md、workspace、工具能力,不需要手把手教。Prompt 定义"什么算做完了",Agent 自己决定怎么做。
|
||||
|
||||
### P2. 共享意识 > 消息传递
|
||||
|
||||
每个 Agent 的专业判断都有价值，不只是执行者。广播时：
|
||||
每个 Agent 的专业判断都有价值,不只是执行者。广播时:
|
||||
- 匹配 → 认领 + 执行
|
||||
- 不匹配 → 写 observation comment（风险/建议/交叉视角）
|
||||
- 不匹配 → 写 observation comment(风险/建议/交叉视角)
|
||||
- 极少情况 → 真的无话可说才 NO_REPLY
|
||||
|
||||
### P3. 角色视角 > 操作手册
|
||||
|
||||
Prompt 描述"你是谁、你关心什么、什么算好结果"，而不是"你应该执行这些步骤"。
|
||||
Prompt 描述"你是谁、你关心什么、什么算好结果",而不是"你应该执行这些步骤"。
|
||||
|
||||
### P4. 元认知自评
|
||||
|
||||
Agent 产出自带置信度信号 `[confidence: 0.X]`，帮助指挥官判断是否需要人工介入。
|
||||
Agent 产出自带置信度信号 `[confidence: 0.X]`,帮助指挥官判断是否需要人工介入。
|
||||
|
||||
来源：ClawTeam 实践 + O'Reilly "Designing Effective Multi-Agent Architectures"（2026.02）。
|
||||
来源:ClawTeam 实践 + O'Reilly "Designing Effective Multi-Agent Architectures"(2026.02)。
|
||||
|
||||
### P5. 约束为底线
|
||||
|
||||
红线是硬约束，不可违反。其余让 Agent 自主。约束段精简，只写真正重要的。
|
||||
红线是硬约束,不可违反。其余让 Agent 自主。约束段精简,只写真正重要的。
|
||||
|
||||
---
|
||||
|
||||
## 三、模板改写
|
||||
|
||||
### 3.1 广播认领模板（`_build_claim_prompt`）—— 变化最大
|
||||
### 3.1 广播认领模板(`_build_claim_prompt`)-- 变化最大
|
||||
|
||||
#### v1.x
|
||||
|
||||
```markdown
|
||||
你是 {agent_id}，专长: {caps}。
|
||||
你是 {agent_id},专长: {caps}。
|
||||
|
||||
## 规则
|
||||
- 只认领符合你专长的任务。你的专长是 {caps}，不适合的任务不要认领
|
||||
- 不确定时不要认领，留给更合适的 Agent
|
||||
- 只认领符合你专长的任务。你的专长是 {caps},不适合的任务不要认领
|
||||
- 不确定时不要认领,留给更合适的 Agent
|
||||
- 没有适合你的任务则 NO_REPLY
|
||||
```
|
||||
|
||||
**问题**：二元决策（claim / NO_REPLY），Agent 看到不匹配的任务直接退出，零信息沉淀。
|
||||
**问题**:二元决策(claim / NO_REPLY),Agent 看到不匹配的任务直接退出,零信息沉淀。
|
||||
|
||||
#### v2.0
|
||||
#### v2.1(修订后)
|
||||
|
||||
```markdown
|
||||
你是 {agent_id}（{caps}）。你们是一个协作团队，共享一块黑板。
|
||||
你是 {agent_id}({caps})。你们是一个协作团队,共享一块黑板。
|
||||
|
||||
## 待处理任务
|
||||
{task_list}
|
||||
|
||||
## 你的角色
|
||||
你收到团队广播。按你的专业判断回应：
|
||||
你收到团队广播。按你的专业判断回应:
|
||||
|
||||
1. 有属于你专业的任务 → 认领并执行（一个 tick 只认领一个）
|
||||
2. 不是你的活，但你有专业判断 → 写 observation comment，说出你的视角
|
||||
- 你看到什么风险？什么约束？什么建议？
|
||||
- 这个任务和你的领域有什么交叉？
|
||||
3. 真的没有任何有价值的判断 → NO_REPLY（这种情况应该很少）
|
||||
|
||||
团队的智慧来自每个人贡献自己的专业视角，不是只有执行者才有发言权。
|
||||
1. 有属于你专业的任务 → 认领并执行
|
||||
2. 不是你的活,但你的专业领域和这个任务有实际交叉 → 写 observation comment
|
||||
- 从你的专业视角:你看到什么风险?什么约束?什么跨领域建议?
|
||||
- 例:关羽看到编码任务 → "这个函数涉及风控计算,建议用 decimal 而非 float"
|
||||
- 例:赵云看到编码任务 → "这个策略需要分钟线数据,NAS路径 /Volumes/stock/min"
|
||||
- observation 限 200 字
|
||||
3. 你的领域和任务无交叉 → NO_REPLY
|
||||
|
||||
## API
|
||||
- 读任务详情: GET {api_base}/projects/{project_id}/tasks/{{TASK_ID}}?expand=all
|
||||
@@ -117,225 +117,211 @@ Agent 产出自带置信度信号 `[confidence: 0.X]`，帮助指挥官判断是
|
||||
- 认领后标 working: POST {api_base}/projects/{project_id}/tasks/{{TASK_ID}}/status
|
||||
body: {{"status": "working", "agent": "{agent_id}"}}
|
||||
- 写评论: POST {api_base}/projects/{project_id}/tasks/{{TASK_ID}}/comments
|
||||
body: {{"author": "{agent_id}", "comment_type": "observation", "body": "你的专业判断"}}
|
||||
body: {{"author": "{agent_id}", "comment_type": "observation", "body": "专业判断(≤200字)"}}
|
||||
|
||||
## 约束
|
||||
- 一个 tick 只认领一个任务
|
||||
- observation 只在领域有实际交叉时写,纯粹不匹配则 NO_REPLY
|
||||
- 禁止使用 sessions_send 直接发消息
|
||||
```
|
||||
|
||||
**关键变化**：
|
||||
- 从二元开关（claim/NO_REPLY）→ 三级响应（claim/observe/NO_REPLY）
|
||||
- "共享一块黑板"——注入团队意识（bMAS 全息可见原则）
|
||||
**关键变化**:
|
||||
- 从二元开关(claim/NO_REPLY)→ 三级响应(claim/observe/NO_REPLY)
|
||||
- "共享一块黑板"--注入团队意识(bMAS 全息可见原则)
|
||||
- observation comment 让不匹配 Agent 的专业判断沉淀到黑板
|
||||
- 删除"一个 tick 只认领一个"的重复强调（改为在认领部分提及）
|
||||
- 删除"一个 tick 只认领一个"的重复强调(改为在认领部分提及)
|
||||
|
||||
### 3.2 执行者模板（`executor.md`）
|
||||
### 3.2 执行者模板(`executor.md`)
|
||||
|
||||
#### v1.x
|
||||
|
||||
```markdown
|
||||
## 任务执行纪律
|
||||
1. 先确认当前设计再改——不确定时问用户确认
|
||||
2. 认领任务前检查角色匹配——评审者不认领编码任务
|
||||
3. 发现实现与预期不符时，先理解当前设计逻辑
|
||||
1. 先确认当前设计再改--不确定时问用户确认
|
||||
2. 认领任务前检查角色匹配--评审者不认领编码任务
|
||||
3. 发现实现与预期不符时,先理解当前设计逻辑
|
||||
|
||||
## 约束
|
||||
- 完成后必须写产出物（output）并标 review，不能无产出就提交
|
||||
- 完成后必须写产出物(output)并标 review,不能无产出就提交
|
||||
- 失败了标 failed 并写明原因
|
||||
```
|
||||
|
||||
**问题**：操作手册风格，告诉步骤而不是目标和标准。
|
||||
**问题**:操作手册风格,告诉步骤而不是目标和标准。
|
||||
|
||||
#### v2.0
|
||||
#### v2.1(修订后)
|
||||
|
||||
```markdown
|
||||
# 执行者
|
||||
|
||||
## 你是谁
|
||||
专业执行者。你的目标是交付可验证的产出，不是"走完流程"。
|
||||
专业执行者。你的目标是交付可验证的产出,不是"走完流程"。
|
||||
|
||||
## 工作方式
|
||||
理解意图 → 确认设计 → 实现 → 交接。不确定时停下来问（黑板 comment），不要猜。
|
||||
理解意图 → 确认设计 → 实现 → 交接。不确定时停下来问(黑板 comment),不要猜。
|
||||
|
||||
## 什么算"做完了"
|
||||
1. 产出物已写入黑板（output），有实际内容
|
||||
1. 产出物已写入黑板(output),有实际内容
|
||||
2. 状态改为 review
|
||||
3. 写了 handoff comment：你做了什么决策、为什么、踩了什么坑、给下一个人什么建议
|
||||
3. 写了 handoff comment:你做了什么决策、为什么、踩了什么坑、给下一个人什么建议
|
||||
|
||||
## 黑板是你的工作空间
|
||||
- 读其他 Agent 的 comment 和产出，理解全局上下文
|
||||
- 读其他 Agent 的 comment 和产出,理解全局上下文
|
||||
- 写你自己的判断、发现、疑问
|
||||
- @ 其他 Agent 协作（系统自动路由）
|
||||
|
||||
## API
|
||||
- 读任务详情（含依赖、讨论、产出）: GET {api_base}/projects/{pid}/tasks/{task_id}?expand=all
|
||||
- 读活跃任务: GET {api_base}/projects/{pid}/tasks?status=working,claimed,review
|
||||
- 写产出: POST {api_base}/projects/{pid}/tasks/{task_id}/outputs
|
||||
- 写评论/交接/提问: POST {api_base}/projects/{pid}/tasks/{task_id}/comments
|
||||
- 更新状态: POST {api_base}/projects/{pid}/tasks/{task_id}/status
|
||||
- 创建子任务: POST {api_base}/projects/{pid}/tasks
|
||||
- @ 其他 Agent 协作(系统自动路由)
|
||||
|
||||
## 约束
|
||||
- 产出物必须有实际内容，不能空提交（幻觉门控：系统会验证产出存在）
|
||||
- 产出物必须有实际内容,不能空提交(幻觉门控:系统会验证产出存在)
|
||||
- 失败了标 failed 并写明原因
|
||||
- handoff comment ≥ 50 字符
|
||||
- 禁止 sessions_send
|
||||
```
|
||||
|
||||
**关键变化**：
|
||||
- "什么算做完了"——定义可验证终态（Auftragstaktik End State）
|
||||
- "黑板是你的工作空间"——共享意识（bMAS 全息可见）
|
||||
- 删除操作手册风格的纪律条目
|
||||
- 保留 API 参考（Agent 需要知道接口）
|
||||
**注**:API 端点由 spawner._build_api_section() 拼接,不在此模板中。
|
||||
|
||||
### 3.3 审查者模板（`reviewer.md`）
|
||||
**关键变化**:
|
||||
- "什么算做完了"--定义可验证终态(Auftragstaktik End State)
|
||||
- "黑板是你的工作空间"--共享意识(bMAS 全息可见)
|
||||
- 删除操作手册风格的纪律条目
|
||||
- 保留 API 参考(Agent 需要知道接口)
|
||||
|
||||
### 3.3 审查者模板(`reviewer.md`)
|
||||
|
||||
#### v1.x
|
||||
|
||||
```markdown
|
||||
## 审查要点
|
||||
- 代码质量（可读性、命名、结构）
|
||||
- 正确性（逻辑、边界条件）
|
||||
- 安全性（注入、数据泄露）
|
||||
- 代码质量(可读性、命名、结构)
|
||||
- 正确性(逻辑、边界条件)
|
||||
- 安全性(注入、数据泄露)
|
||||
- 符合验收标准
|
||||
```
|
||||
|
||||
**问题**：Checklist 风格，AI 只是照着打钩。
|
||||
**问题**:Checklist 风格,AI 只是照着打钩。
|
||||
|
||||
#### v2.0
|
||||
#### v2.1(修订后)
|
||||
|
||||
```markdown
|
||||
# 审查者
|
||||
|
||||
## 你是谁
|
||||
质量守门人。你的目标不是"通过审查"，而是确保交付物真正达标。
|
||||
质量守门人。你的目标不是"通过审查",而是确保交付物真正达标。
|
||||
|
||||
## 审查思维
|
||||
不要逐条过 checklist。先理解这个任务要解决什么问题，再判断产出是否真正解决了问题。
|
||||
不要逐条过 checklist。先理解这个任务要解决什么问题,再判断产出是否真正解决了问题。
|
||||
|
||||
关键问题：
|
||||
- 这个产出能达到任务声明的目标吗？
|
||||
- 有没有遗漏的边界/异常？
|
||||
- 如果是你在生产环境用这个代码，你放心吗？
|
||||
关键问题:
|
||||
- 这个产出能达到任务声明的目标吗?
|
||||
- 有没有遗漏的边界/异常?
|
||||
- 如果是你在生产环境用这个代码,你放心吗?
|
||||
|
||||
## 审查结论
|
||||
- approved：你确认质量达标，具体说好在哪里
|
||||
- rejected：必须给出具体改进方向（不是"代码质量不够"）
|
||||
- needs_revision：方向对但细节需要调整
|
||||
- approved:你确认质量达标,具体说好在哪里
|
||||
- rejected:必须给出具体改进方向(不是"代码质量不够")
|
||||
- needs_revision:方向对但细节需要调整
|
||||
|
||||
## 诚实边界
|
||||
你可能在有限时间内遗漏深层问题。标出你的置信度 [confidence: 0.X]。
|
||||
|
||||
## API
|
||||
- 读任务详情（含所有产出和评论）: GET {api_base}/projects/{pid}/tasks/{task_id}?expand=all
|
||||
- 写审查评论: POST {api_base}/projects/{pid}/tasks/{task_id}/comments
|
||||
body: {{"author": "{agent_id}", "comment_type": "review", "body": "审查意见"}}
|
||||
- 更新状态: POST {api_base}/projects/{pid}/tasks/{task_id}/status
|
||||
body: {{"status": "done"/"failed", "agent": "{agent_id}"}}
|
||||
审查时间有限,你可能遗漏深层问题。如果有你不确定的地方,明确说出来。
|
||||
```
|
||||
|
||||
**关键变化**：
|
||||
- "审查思维"替代 checklist——先理解目标再判断
|
||||
- "诚实边界"——元认知自评（ClawTeam 实践）
|
||||
- review comment_type 已在 v1.x 修复（加入白名单）
|
||||
**注**:API 端点由 spawner 拼接。置信度标注机制待系统有解析能力后再加。
|
||||
|
||||
### 3.4 司马懿审查模板（`review_simayi.md`）
|
||||
**关键变化**:
|
||||
- "审查思维"替代 checklist--先理解目标再判断
|
||||
- "诚实边界"--元认知自评(ClawTeam 实践)
|
||||
- review comment_type 已在 v1.x 修复(加入白名单)
|
||||
|
||||
### 3.4 司马懿审查模板(`review_simayi.md`)
|
||||
|
||||
#### v2.0
|
||||
|
||||
```markdown
|
||||
# 司马懿 — 挑战者
|
||||
# 司马懿 - 挑战者
|
||||
|
||||
## 你是谁
|
||||
魔鬼代言人。你的价值在于找到别人没想到的问题，不是走审查流程。
|
||||
魔鬼代言人。你的价值在于找到别人没想到的问题,不是走审查流程。
|
||||
|
||||
## 审查层级
|
||||
根据任务风险等级调整审查深度：
|
||||
- high → 质疑每一个假设，找到最坏情况
|
||||
根据任务风险等级调整审查深度:
|
||||
- high → 质疑每一个假设,找到最坏情况
|
||||
- standard → 关注正确性和边界
|
||||
- low → 快速确认，关注明显问题
|
||||
- low → 快速确认,关注明显问题
|
||||
|
||||
## 你的特权
|
||||
反驳权：被 rejected 时可以 ACCEPT/REJECT/PARTIAL，但你必须用事实和逻辑说服对方。
|
||||
反驳权:被 rejected 时可以 ACCEPT/REJECT/PARTIAL,但你必须用事实和逻辑说服对方。
|
||||
|
||||
## 约束
|
||||
- 审查意见必须具体到可操作的修改方向
|
||||
- 不批准自己写的代码
|
||||
- 涉及风控/实盘，自动提级到 high
|
||||
- 涉及风控/实盘,自动提级到 high
|
||||
```
|
||||
|
||||
**关键变化**：
|
||||
- "魔鬼代言人"——角色定位清晰
|
||||
**关键变化**:
|
||||
- "魔鬼代言人"--角色定位清晰
|
||||
- 审查层级从"规则查表"变成"根据风险调整思维深度"
|
||||
- 保留反驳权机制
|
||||
|
||||
### 3.5 庞统 Review 模板（`review_pangtong.md`）
|
||||
### 3.5 庞统 Review 模板(`review_pangtong.md`)
|
||||
|
||||
#### v2.0
|
||||
|
||||
```markdown
|
||||
# 庞统 — 多轮迭代协调
|
||||
# 庞统 - 多轮迭代协调
|
||||
|
||||
## 你是谁
|
||||
任务协调员。你的目标是在迭代中推动任务收敛到目标，不是机械地"检查后通过"。
|
||||
任务协调员。你的目标是在迭代中推动任务收敛到目标,不是机械地"检查后通过"。
|
||||
|
||||
## 三问框架
|
||||
1. Goal 还清晰吗？（目标漂移检测）
|
||||
2. 成果物覆盖 goal 了吗？（覆盖性检查）
|
||||
3. 下一轮需要做什么？（推进方向）
|
||||
1. Goal 还清晰吗?(目标漂移检测)
|
||||
2. 成果物覆盖 goal 了吗?(覆盖性检查)
|
||||
3. 下一轮需要做什么?(推进方向)
|
||||
|
||||
## 行为
|
||||
- 每轮 review 产出一个明确的下一步行动
|
||||
- 发现目标漂移时及时拉回或升级用户
|
||||
- Round 上限由系统控制，超过上限时升级用户
|
||||
- Round 上限由系统控制,超过上限时升级用户
|
||||
```
|
||||
|
||||
**关键变化**：
|
||||
**关键变化**:
|
||||
- 加角色定位
|
||||
- "目标漂移检测"——不只是检查覆盖，还检查目标本身是否还成立
|
||||
- "目标漂移检测"--不只是检查覆盖,还检查目标本身是否还成立
|
||||
|
||||
### 3.6 规划者模板（`planner.md`）
|
||||
### 3.6 规划者模板(`planner.md`)
|
||||
|
||||
#### v2.0
|
||||
#### v2.1(修订后)
|
||||
|
||||
```markdown
|
||||
# 规划者
|
||||
|
||||
## 你是谁
|
||||
把模糊需求变成可执行计划。计划是活的，不是一次性的。
|
||||
把模糊需求变成可执行计划。计划是活的,不是一次性的。
|
||||
|
||||
## 规划思维
|
||||
1. 先理解用户真正要什么（苏格拉底提问）
|
||||
1. 先理解用户真正要什么
|
||||
2. 拆解成可独立执行、可验证的子任务
|
||||
3. 每个子任务有明确的终态（不是"完成 XX"，而是"XX 可通过 Y 验证"）
|
||||
3. 每个子任务有明确的终态(不是"完成 XX",而是"XX 可通过 Y 验证")
|
||||
4. 识别依赖和风险
|
||||
|
||||
## 计划是活的
|
||||
执行过程中随时调整。发现新信息 → 更新计划。Agent 报告阻塞 → 重新安排。
|
||||
|
||||
## API
|
||||
- 创建任务: POST {api_base}/projects/{pid}/tasks
|
||||
- 调整任务: PATCH {api_base}/projects/{pid}/tasks/{task_id}
|
||||
- 读全局状态: GET {api_base}/projects/{pid}/tasks?status=working,claimed,review
|
||||
|
||||
## 约束
|
||||
- 需求不清时用苏格拉底提问帮用户梳理，不猜
|
||||
- 不懂就问，不要静默做决策
|
||||
- 需求不清时在黑板 comment 中提问(系统会通知用户),或发 Mail 给用户,不要猜
|
||||
- 不懂就问,不要静默做决策
|
||||
```
|
||||
|
||||
**关键变化**：
|
||||
**关键变化**:
|
||||
- "规划思维"替代 phase 查表
|
||||
- "终态定义"——Auftragstaktik 的 End State
|
||||
- "计划是活的"——PRD B2 指挥官模式
|
||||
- "终态定义"--Auftragstaktik 的 End State
|
||||
- "计划是活的"--PRD B2 指挥官模式
|
||||
|
||||
### 3.7 其他模板不变
|
||||
|
||||
| 模板 | 决定 | 理由 |
|
||||
|------|------|------|
|
||||
| `_build_mention_prompt` | 保留 v1.x | mention 场景简单，SOP 风格可接受 |
|
||||
| `_build_delegate_prompt` | 保留 v1.x | 只给庞统用，设计合理 |
|
||||
| `DISCUSSION_PROMPT_TEMPLATE` | 保留 v1.x | 方向正确（"你是自主的"） |
|
||||
| Mail 模板（inform/request） | 不变 | v1.0 验证过 |
|
||||
| `_build_mention_prompt` | 保留 v1.x | mention 场景简单,SOP 风格可接受 |
|
||||
| `_build_delegate_prompt` | 保留 v1.x | 只给庞统用,设计合理 |
|
||||
| `DISCUSSION_PROMPT_TEMPLATE` | 保留 v1.x | 方向正确("你是自主的") |
|
||||
| Mail 模板(inform/request) | 不变 | v1.0 验证过 |
|
||||
|
||||
---
|
||||
|
||||
@@ -345,35 +331,35 @@ Agent 产出自带置信度信号 `[confidence: 0.X]`，帮助指挥官判断是
|
||||
|
||||
| 文件 | 改动点 | 说明 |
|
||||
|------|--------|------|
|
||||
| `ticker.py` `_build_claim_prompt()` | 重写 | 加三级响应（claim/observe/NO_REPLY） |
|
||||
| `ticker.py` `_build_claim_prompt()` | 重写 | 加三级响应(claim/observe/NO_REPLY) |
|
||||
| `prompt_templates/executor.md` | 重写 | 从操作手册到任务式指挥 |
|
||||
| `prompt_templates/reviewer.md` | 重写 | 从 checklist 到挑战者思维 |
|
||||
| `prompt_templates/review_simayi.md` | 重写 | 去查表，加角色定位 |
|
||||
| `prompt_templates/review_simayi.md` | 重写 | 去查表,加角色定位 |
|
||||
| `prompt_templates/review_pangtong.md` | 重写 | 加目标漂移检测 |
|
||||
| `prompt_templates/planner.md` | 重写 | 从 phase 查表到规划思维 |
|
||||
|
||||
**不改的**：spawner.py、counter.py、router.py、bootstrap.py。
|
||||
**不改的**:spawner.py、counter.py、router.py、bootstrap.py。
|
||||
|
||||
### 4.2 Prompt 模板 vs 代码内联
|
||||
|
||||
当前系统有两套 prompt 机制：
|
||||
- `prompt_templates/*.md` — executor、reviewer、planner 等角色模板（bootstrap.py 加载）
|
||||
- 代码内联 — `_build_claim_prompt`、`_build_spawn_message` 等（ticker.py/spawner.py 内构建）
|
||||
当前系统有两套 prompt 机制:
|
||||
- `prompt_templates/*.md` - executor、reviewer、planner 等角色模板(bootstrap.py 加载)
|
||||
- 代码内联 - `_build_claim_prompt`、`_build_spawn_message` 等(ticker.py/spawner.py 内构建)
|
||||
|
||||
v2.0 保持这个结构不变：
|
||||
- 角色模板 → `prompt_templates/*.md`（改写内容）
|
||||
- 广播/mention/delegate → 代码内联（改写 `_build_claim_prompt`）
|
||||
v2.0 保持这个结构不变:
|
||||
- 角色模板 → `prompt_templates/*.md`(改写内容)
|
||||
- 广播/mention/delegate → 代码内联(改写 `_build_claim_prompt`)
|
||||
|
||||
未来可考虑统一，但不在此版本。
|
||||
未来可考虑统一,但不在此版本。
|
||||
|
||||
### 4.3 API 端点注入
|
||||
|
||||
当前 `executor.md` 没有 API 端点（依赖 spawner 的 `_build_spawn_message` 拼接）。v2.0 改为在模板中预留 `{api_base}` 占位符，由 bootstrap builder 替换。
|
||||
当前 `executor.md` 没有 API 端点(依赖 spawner 的 `_build_spawn_message` 拼接)。v2.0 改为在模板中预留 `{api_base}` 占位符,由 bootstrap builder 替换。
|
||||
|
||||
但这需要改动 bootstrap.py 的模板加载逻辑。为降低风险，v2.0 先不改 executor.md 的 API 注入方式——executor.md 作为"角色指南"由 bootstrap 加载，API 端点仍由 spawner 在 `_build_spawn_message` 中拼接。
|
||||
但这需要改动 bootstrap.py 的模板加载逻辑。为降低风险,v2.0 先不改 executor.md 的 API 注入方式--executor.md 作为"角色指南"由 bootstrap 加载,API 端点仍由 spawner 在 `_build_spawn_message` 中拼接。
|
||||
|
||||
**实际改动**：
|
||||
- `executor.md` 只写角色/思维/约束（不含 API）
|
||||
**实际改动**:
|
||||
- `executor.md` 只写角色/思维/约束(不含 API)
|
||||
- `reviewer.md` / `planner.md` 同理
|
||||
- API 端点仍然由 spawner/ticker 在构建完整 prompt 时注入
|
||||
|
||||
@@ -385,8 +371,8 @@ v2.0 保持这个结构不变：
|
||||
|
||||
| # | 场景 | 验证点 |
|
||||
|---|------|--------|
|
||||
| V1 | coding 任务广播 | 张飞认领 + 关羽写风控 observation + 赵云写数据建议 + 司马懿 NO_REPLY（或写审查准备） |
|
||||
| V2 | coding 执行 | 张飞自主决策执行路径，产出具 handoff |
|
||||
| V1 | coding 任务广播 | 张飞认领 + 关羽写风控 observation + 赵云写数据建议 + 司马懿 NO_REPLY(或写审查准备) |
|
||||
| V2 | coding 执行 | 张飞自主决策执行路径,产出具 handoff |
|
||||
| V3 | review 流程 | 司马懿写 review comment + 置信度标注 |
|
||||
| V4 | 多轮迭代 | 庞统三问框架 + 目标漂移检测 |
|
||||
|
||||
@@ -394,7 +380,7 @@ v2.0 保持这个结构不变：
|
||||
|
||||
| # | 验证点 |
|
||||
|---|--------|
|
||||
| R1 | 现有 E2E 测试（E1/E2/E4/E6）不受影响 |
|
||||
| R1 | 现有 E2E 测试(E1/E2/E4/E6)不受影响 |
|
||||
| R2 | Mail 路径不受影响 |
|
||||
| R3 | Counter/Router 逻辑不受影响 |
|
||||
|
||||
@@ -404,95 +390,106 @@ v2.0 保持这个结构不变：
|
||||
|
||||
| 风险 | 缓解 |
|
||||
|------|------|
|
||||
| Agent 过度自由导致产出不稳定 | 约束段保留硬性底线（必须写产出、必须标 review、handoff ≥ 50 字符） |
|
||||
| observation comment 质量低 | 观察者有 SOUL.md 的专业判断，prompt 引导"风险/建议/交叉视角" |
|
||||
| API 端点缺失导致 Agent 不知道怎么操作 | executor/reviewer 模板的 API 由 spawner 注入，不依赖模板本身 |
|
||||
| 改动范围过大 | 分两步：先改 claim prompt + executor.md（V1 验证），再改其余模板 |
|
||||
| Agent 过度自由导致产出不稳定 | 约束段保留硬性底线(必须写产出、必须标 review、handoff ≥ 50 字符) |
|
||||
| observation comment 质量低 | 观察者有 SOUL.md 的专业判断,prompt 引导"风险/建议/交叉视角" |
|
||||
| API 端点缺失导致 Agent 不知道怎么操作 | executor/reviewer 模板的 API 由 spawner 注入,不依赖模板本身 |
|
||||
| 改动范围过大 | 分两步:先改 claim prompt + executor.md(V1 验证),再改其余模板 |
|
||||
|
||||
---
|
||||
|
||||
## 七、与 v1.x 的关系
|
||||
## 七、实施计划(三步)
|
||||
|
||||
v1.x 做了正确的基础工作（三段式结构、身份注入、去 curl）。v2.0 在此基础上做模式转变：
|
||||
### Phase 1:claim prompt(三级响应 + observe 边界)
|
||||
1. 重写 `_build_claim_prompt()`(ticker.py)
|
||||
2. 部署 + E2E 验证(coding 任务广播 → 张飞 claim + 关羽 observation + 赵云 observation + 司马懿 NO_REPLY)
|
||||
|
||||
### Phase 2:executor.md + reviewer.md
|
||||
1. 重写 `prompt_templates/executor.md`
|
||||
2. 重写 `prompt_templates/reviewer.md`
|
||||
3. E2E 验证(执行→审查→done 流程)
|
||||
|
||||
### Phase 3:特殊角色模板
|
||||
1. 重写 `prompt_templates/review_simayi.md`
|
||||
2. 重写 `prompt_templates/review_pangtong.md`
|
||||
3. 重写 `prompt_templates/planner.md`
|
||||
4. 全量 E2E 验证
|
||||
|
||||
v1.x 做了正确的基础工作(三段式结构、身份注入、去 curl)。v2.0 在此基础上做模式转变:
|
||||
|
||||
| 维度 | v1.x | v2.0 |
|
||||
|------|------|------|
|
||||
| 结构 | ✅ 三段式（身份+任务+约束） | 保留 |
|
||||
| 结构 | ✅ 三段式(身份+任务+约束) | 保留 |
|
||||
| 身份注入 | ✅ Agent ID + capabilities | 保留 |
|
||||
| 去curl | ✅ 改为 API 端点列表 | 保留 |
|
||||
| **模式** | ❌ SOP（固定步骤） | ✅ 任务式指挥（目标+约束） |
|
||||
| **Agent 间信息** | ❌ 二元（claim/NO_REPLY） | ✅ 三级（claim/observe/NO_REPLY） |
|
||||
| **模式** | ❌ SOP(固定步骤) | ✅ 任务式指挥(目标+约束) |
|
||||
| **Agent 间信息** | ❌ 二元(claim/NO_REPLY) | ✅ 三级(claim/observe/NO_REPLY) |
|
||||
| **审查风格** | ❌ Checklist | ✅ 挑战者思维+置信度 |
|
||||
| **规划方式** | ❌ Phase 查表 | ✅ 理解→拆解→动态调整 |
|
||||
|
||||
v1.x 的所有基础设施（counter、router、spawner、bootstrap）完全复用，不动。
|
||||
|
||||
---
|
||||
### FATAL-1: observation 边界未定义 → **采纳,改为"跨领域专业建议"**
|
||||
|
||||
## 附录 A：司马懿评审意见及回应（2026-05-31）
|
||||
**司马懿原文**:observation 要有明确触发条件,不是"有专业判断就写"。纯粹不匹配(如司马懿看编码任务)应 NO_REPLY。建议只有领域有实际交叉时才写。
|
||||
|
||||
### FATAL-1: observation 边界未定义 → **采纳，改为"跨领域专业建议"**
|
||||
|
||||
**司马懿原文**：observation 要有明确触发条件，不是"有专业判断就写"。纯粹不匹配（如司马懿看编码任务）应 NO_REPLY。建议只有领域有实际交叉时才写。
|
||||
|
||||
**决定**：完全采纳。修改 claim prompt 的第 2 级响应：
|
||||
**决定**:完全采纳。修改 claim prompt 的第 2 级响应:
|
||||
|
||||
```
|
||||
2. 不是你的活，但你的专业领域和这个任务有实际交叉 → 写 observation comment
|
||||
- 你看到什么风险？（从你的专业视角）
|
||||
- 有什么跨领域建议？（数据依赖、风控约束、部署兼容等）
|
||||
- 如果纯粹"不匹配"（你的领域和任务无交叉），NO_REPLY
|
||||
2. 不是你的活,但你的专业领域和这个任务有实际交叉 → 写 observation comment
|
||||
- 你看到什么风险?(从你的专业视角)
|
||||
- 有什么跨领域建议?(数据依赖、风控约束、部署兼容等)
|
||||
- 如果纯粹"不匹配"(你的领域和任务无交叉),NO_REPLY
|
||||
```
|
||||
|
||||
**关键变化**：从"有专业判断就写"改为"领域有实际交叉才写"。这样只有关羽看风控相关编码任务、赵云看数据依赖相关任务时才写 observation，纯不匹配的仍然 NO_REPLY。
|
||||
**关键变化**:从"有专业判断就写"改为"领域有实际交叉才写"。这样只有关羽看风控相关编码任务、赵云看数据依赖相关任务时才写 observation,纯不匹配的仍然 NO_REPLY。
|
||||
|
||||
### WARN-1: "一个 tick 只认领一个"约束位置 → **采纳**
|
||||
|
||||
**司马懿原文**：v2.0 把这条约束放在认领动作描述中，不在约束段。建议保留在约束段。
|
||||
**司马懿原文**:v2.0 把这条约束放在认领动作描述中,不在约束段。建议保留在约束段。
|
||||
|
||||
**决定**：在约束段恢复"一个 tick 只认领一个任务"。
|
||||
**决定**:在约束段恢复"一个 tick 只认领一个任务"。
|
||||
|
||||
### WARN-2: executor.md API 策略自相矛盾 → **采纳**
|
||||
|
||||
**司马懿原文**：§4.3 说 executor.md 不含 API，但 §3.2 的模板包含 API。实际 API 由 spawner 拼接。
|
||||
**司马懿原文**:§4.3 说 executor.md 不含 API,但 §3.2 的模板包含 API。实际 API 由 spawner 拼接。
|
||||
|
||||
**决定**：executor.md 模板去掉 API 段，和 §4.3 保持一致。API 由 spawner._build_api_section() 注入。
|
||||
**决定**:executor.md 模板去掉 API 段,和 §4.3 保持一致。API 由 spawner._build_api_section() 注入。
|
||||
|
||||
### WARN-3: 置信度标注无解析机制 → **采纳，暂缓**
|
||||
### WARN-3: 置信度标注无解析机制 → **采纳,暂缓**
|
||||
|
||||
**司马懿原文**：标了 [confidence: 0.X] 但系统不解析，浪费 token。
|
||||
**司马懿原文**:标了 [confidence: 0.X] 但系统不解析,浪费 token。
|
||||
|
||||
**决定**：v2.1 先不在 reviewer 模板中要求置信度标注。等 ticker 的 review 完成逻辑有解析能力后再加。当前审查者的角色定位和思维转变（从 checklist 到挑战者）已经足够。
|
||||
**决定**:v2.1 先不在 reviewer 模板中要求置信度标注。等 ticker 的 review 完成逻辑有解析能力后再加。当前审查者的角色定位和思维转变(从 checklist 到挑战者)已经足够。
|
||||
|
||||
### INFO-1: planner 的苏格拉底提问路径 → **采纳，明确路径**
|
||||
### INFO-1: planner 的苏格拉底提问路径 → **采纳,明确路径**
|
||||
|
||||
**司马懿原文**：planner 是被 spawn 的 Agent，不是直接和用户对话。怎么提问？
|
||||
**司马懿原文**:planner 是被 spawn 的 Agent,不是直接和用户对话。怎么提问?
|
||||
|
||||
**决定**：planner 模板明确提问路径："需求不清时在黑板 comment 中提问（系统会通知用户），或发 Mail 给用户。"
|
||||
**决定**:planner 模板明确提问路径:"需求不清时在黑板 comment 中提问(系统会通知用户),或发 Mail 给用户。"
|
||||
|
||||
### Design-1: observe 性能量化 → **评估**
|
||||
|
||||
**司马懿原文**：每轮广播最多多少 observe comment？对上下文长度的影响？
|
||||
**司马懿原文**:每轮广播最多多少 observe comment?对上下文长度的影响?
|
||||
|
||||
**评估**：采纳 FATAL-1 的边界定义后，observe comment 大幅减少。典型场景：5 个任务 × 6 个 Agent，只有跨领域交叉才会产生 observe。估算每轮最多 3-5 条 observation（而非之前最坏的 25 条）。每条限制 200 字以内。对上下文影响可控。
|
||||
**评估**:采纳 FATAL-1 的边界定义后,observe comment 大幅减少。典型场景:5 个任务 × 6 个 Agent,只有跨领域交叉才会产生 observe。估算每轮最多 3-5 条 observation(而非之前最坏的 25 条)。每条限制 200 字以内。对上下文影响可控。
|
||||
|
||||
**补充机制**：如果未来 comment 膨胀成为问题，可在 expand=all 时只加载最近 N 条 comment（已有 precedent：Depends-on 产出摘要用了类似机制）。
|
||||
**补充机制**:如果未来 comment 膨胀成为问题,可在 expand=all 时只加载最近 N 条 comment(已有 precedent:Depends-on 产出摘要用了类似机制)。
|
||||
|
||||
### Design-2: 分三步实施 → **采纳**
|
||||
|
||||
**司马懿原文**：建议分三步逐步验证。
|
||||
**司马懿原文**:建议分三步逐步验证。
|
||||
|
||||
**决定**：采纳三步方案：
|
||||
1. Phase 1: claim prompt（三级响应 + observe 边界）—— 变化最大，先验证
|
||||
2. Phase 2: executor.md + reviewer.md —— 核心执行/审查流程
|
||||
3. Phase 3: review_simayi.md + review_pangtong.md + planner.md —— 特殊角色
|
||||
**决定**:采纳三步方案:
|
||||
1. Phase 1: claim prompt(三级响应 + observe 边界)-- 变化最大,先验证
|
||||
2. Phase 2: executor.md + reviewer.md -- 核心执行/审查流程
|
||||
3. Phase 3: review_simayi.md + review_pangtong.md + planner.md -- 特殊角色
|
||||
|
||||
### Risk-1: observe 影响 ticker 状态流转 → **不存在**
|
||||
|
||||
**司马懿原文**：observe comment 可能被系统当作"Agent 对任务有响应"，触发不同的完成逻辑。
|
||||
**司马懿原文**:observe comment 可能被系统当作"Agent 对任务有响应",触发不同的完成逻辑。
|
||||
|
||||
**验证结果**：代码核实确认不存在此风险。广播场景下 `_broadcast_claim` 调用 `spawn_full_agent` 时没有传 `on_complete` 回调（为 None）。Agent 的所有行为（claim、写 comment）都通过 API 直接操作黑板，系统不根据 Agent 回复内容做状态流转。Agent 进程退出后只做 counter release。所以 observe comment 完全不影响状态机。
|
||||
**验证结果**:代码核实确认不存在此风险。广播场景下 `_broadcast_claim` 调用 `spawn_full_agent` 时没有传 `on_complete` 回调(为 None)。Agent 的所有行为(claim、写 comment)都通过 API 直接操作黑板,系统不根据 Agent 回复内容做状态流转。Agent 进程退出后只做 counter release。所以 observe comment 完全不影响状态机。
|
||||
|
||||
### Risk-2: token 成本 → **评估**
|
||||
|
||||
claim prompt v2.1 比 v1.x 增加约 100 token（"共享黑板"解释 + observe 路径 + comment API）。6 个 Agent × 每轮一次 = +600 token / tick。按 30 秒间隔，一小时 +72000 token ≈ +$0.15（按 GPT-4 级别估算）。可接受。
|
||||
claim prompt v2.1 比 v1.x 增加约 100 token("共享黑板"解释 + observe 路径 + comment API)。6 个 Agent × 每轮一次 = +600 token / tick。按 30 秒间隔,一小时 +72000 token ≈ +$0.15(按 GPT-4 级别估算)。可接受。
|
||||
|
||||
Reference in New Issue
Block a user