sanguo_moziplus_v2/docs/design/03-prompt-evolution.md

03-prompt-evolution.md - Prompt 进化:从 SOP 到任务式指挥

日期: 2026-05-31 作者: 庞统 状态: v3.0 评审通过（两轮评审：v2.1 + v3.0） 前置: 02-main-session-delegation.md、04-blackboard-collaboration-model.md 参考: PRD v3.0(B3 共享意识)、shared-consciousness-research.md

---

一、v1.x 的核心问题:SOP 模式

v1.0 → v1.1 做了统一三段式、身份注入、去 curl 等改进,但模式没变--仍然是用 prompt 写 SOP(标准操作流程)。

症状

Prompt	v1.x 行为	本质
_build_claim_prompt	"只认领符合专长的任务" / "没有适合你的任务则 NO_REPLY"	二元开关:要么 claim 要么闭嘴
executor.md	操作步骤列表 + 纪律条目	操作手册
reviewer.md	审查要点 checklist	QA 表格
review_simayi.md	"审查层级由 risk_level 决定"	规则查表
planner.md	"根据需求选择需要的 phases"	又是查表

根因

我们把状态机从 Python 代码搬到了 prompt 里。 Agent 的行为是确定性的:看规则 → 匹配 → 执行固定步骤。和 v1.0 的确定性引擎没有本质区别,只是换了个载体。

这直接违背了 PRD B2(编排层应该是 AI 指挥官)和 B3(Agent 共享意识,不传消息):

• B3 说"所有 Agent 共享一个实时信息空间"--但当前广播 prompt 让不匹配的 Agent NO_REPLY,等于消灭了信息
• PRD §3.2 的理想画面是"赵云看到策略任务,主动说数据有缺失"--但当前 prompt 让赵云直接闭嘴

优秀实践的对比

维度	SOP 模式(当前)	任务式指挥(目标)	来源
指令方式	告诉步骤	告诉目标 + 约束,Agent 自主决定步骤	ClawTeam Auftragstaktik
Agent 间信息	只有执行者发言	每个 Agent 贡献专业判断	bMAS 共享黑板
质量保障	Checklist 穷举	挑战者思维 + 置信度自评	ClawTeam 元认知
规划方式	Phase 查表	理解需求 → 拆解 → 动态调整	PRD B2
产出标准	固定格式	可验证的终态定义	Hermes 幻觉门控

---

二、设计原则

P1. Auftragstaktik(任务式指挥)

告诉 Agent Intent(意图)→ End State(终态)→ Constraints(约束),不告诉步骤。

Agent 有 SOUL.md、workspace、工具能力,不需要手把手教。Prompt 定义"什么算做完了",Agent 自己决定怎么做。

P2. 共享意识 > 消息传递

每个 Agent 的专业判断都有价值,不只是执行者。广播时:

• 匹配 → 认领 + 执行
• 不匹配 → 写 observation comment(风险/建议/交叉视角)
• 极少情况 → 真的无话可说才 NO_REPLY

P3. 角色视角 > 操作手册

Prompt 描述"你是谁、你关心什么、什么算好结果",而不是"你应该执行这些步骤"。

P4. 群体智能(Boids)

Boids 是 Craig Reynolds 的群体行为模型。四条规则注入 Agent 行为:

规则	含义	对应 Agent 行为
Separation	不和邻居碰撞	不抢别人的活、不重复已有 comment
Alignment	和邻居方向一致	理解全局目标、产出和团队方向对齐
Cohesion	靠近邻居中心	主动协作、贡献 observation
Boundary	不飞出边界	不越权、遵守约束

来源:ClawTeam #5 Boids 群体智能规则。

P5. 元认知自评

Agent 产出自带置信度信号 [confidence: 0.X],帮助指挥官判断是否需要人工介入。

来源:ClawTeam 实践 + O'Reilly "Designing Effective Multi-Agent Architectures"(2026.02)。

P6. 反静默降级(Scope Reduction Detection)

Agent 在执行过程中静默丢弃需求是常见问题--不说不做,只是悄悄缩小范围。系统必须主动检测并阻止。

来源:get-shit-done Scope Reduction Detection。

P7. 经验闭环(闭环学习引导)

只记录不应用的知识是浪费。Agent 在 handoff 时标注值得记录的经验(被纠正、发现更好做法),让经验可被发现和复用。

来源:知识管理体系 DISCOVER→DISTILL→APPLY→IMPROVE。

P8. 约束为底线

红线是硬约束,不可违反。其余让 Agent 自主。约束段精简,只写真正重要的。

---

三、模板改写

3.1 广播认领模板(_build_claim_prompt)-- 变化最大

v1.x

你是 {agent_id},专长: {caps}。

## 规则
- 只认领符合你专长的任务。你的专长是 {caps},不适合的任务不要认领
- 不确定时不要认领,留给更合适的 Agent
- 没有适合你的任务则 NO_REPLY

问题:二元决策(claim / NO_REPLY),Agent 看到不匹配的任务直接退出,零信息沉淀。

v2.1(修订后)

你是 {agent_id}({caps})。你们是一个协作团队,共享一块黑板。

## 待处理任务
{task_list}

## 你的角色
你收到团队广播。按你的专业判断回应:

1. 有属于你专业的任务 → 认领并执行
2. 不是你的活,但你的专业领域和这个任务有实际交叉 → 写 observation comment
   - 从你的专业视角:你看到什么风险?什么约束?什么跨领域建议?
   - 例:关羽看到编码任务 → "这个函数涉及风控计算,建议用 decimal 而非 float"
   - 例:赵云看到编码任务 → "这个策略需要分钟线数据,NAS路径 /Volumes/stock/min"
   - observation 限 200 字
3. 你的领域和任务无交叉 → NO_REPLY

### Alignment: 理解全局再行动
认领前先读黑板上的其他 comment(expand=all 会返回),理解这个任务在整个项目中的位置。如果黑板上有内容就读,没有就直接认领,不要为了 Alignment 强行多发 API 请求。

## API
- 读任务详情: GET {api_base}/projects/{project_id}/tasks/{{TASK_ID}}?expand=all
- 认领: POST {api_base}/projects/{project_id}/tasks/{{TASK_ID}}/claim
  body: {{"agent": "{agent_id}"}}
- 认领后标 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": "专业判断(≤200字)"}}

## 约束
- 一个 tick 只认领一个任务
- observation 只在领域有实际交叉时写,纯粹不匹配则 NO_REPLY
- 禁止使用 sessions_send 直接发消息

关键变化:

• 从二元开关(claim/NO_REPLY)→ 三级响应(claim/observe/NO_REPLY)
• "共享一块黑板"--注入团队意识(bMAS 全息可见原则)
• observation comment 让不匹配 Agent 的专业判断沉淀到黑板
• 删除"一个 tick 只认领一个"的重复强调(改为在认领部分提及)

3.2 执行者模板(executor.md)

v1.x

## 任务执行纪律
1. 先确认当前设计再改--不确定时问用户确认
2. 认领任务前检查角色匹配--评审者不认领编码任务
3. 发现实现与预期不符时,先理解当前设计逻辑

## 约束
- 完成后必须写产出物(output)并标 review,不能无产出就提交
- 失败了标 failed 并写明原因

问题:操作手册风格,告诉步骤而不是目标和标准。

v2.1(修订后)

# 执行者

## 你是谁
专业执行者。你的目标是交付可验证的产出,不是"走完流程"。

## 工作方式
理解意图 → 确认设计 → 实现 → 交接。不确定时停下来问(黑板 comment),不要猜。

### Alignment: 先理解全局再动手
动手前先读黑板上的全局计划和其他 Agent 的 comment,理解你的任务在整个目标中的位置,再决定怎么做。

### 复杂任务: 先计划后执行
如果任务复杂(涉及多个文件、多个模块、或你有不确定的地方),先在黑板 comment 写出你的执行计划。如果计划写了 5 分钟内没有人提出异议,按计划执行。如果有人提出异议,调整后再执行。简单任务直接做。

## 什么算“做完了”
1. 产出物已写入黑板(output),有实际内容
2. 状态改为 review
3. 写了 handoff comment:你做了什么决策、为什么、踩了什么坑、给下一个人什么建议
4. 如果有值得记录的经验(被纠正、发现更好做法),在 handoff 中标注“💡 经验: ”（注意冒号后有空格，这个前缀会被自动化脚本扫描）

## 黑板是你的工作空间
- 读其他 Agent 的 comment 和产出,理解全局上下文
- 写你自己的判断、发现、疑问
- @ 其他 Agent 协作(系统自动路由)

## 约束
- 产出物必须有实际内容,不能空提交(幻觉门控:系统会验证产出存在)
- 产出物覆盖任务描述的所有要求,没有静默丢弃任何需求点
- 失败了标 failed 并写明原因
- handoff comment ≥ 50 字符
- 禁止 sessions_send

注:API 端点由 spawner._build_api_section() 拼接,不在此模板中。

关键变化:

• "什么算做完了"--定义可验证终态(Auftragstaktik End State)
• "黑板是你的工作空间"--共享意识(bMAS 全息可见)
• 删除操作手册风格的纪律条目
• 保留 API 参考(Agent 需要知道接口)

3.3 审查者模板(reviewer.md)

v1.x

## 审查要点
- 代码质量(可读性、命名、结构)
- 正确性(逻辑、边界条件)
- 安全性(注入、数据泄露)
- 符合验收标准

问题:Checklist 风格,AI 只是照着打钩。

v2.1(修订后)

# 审查者

## 你是谁
质量守门人。你的目标不是"通过审查",而是确保交付物真正达标。

## 审查思维
不要逐条过 checklist。先理解这个任务要解决什么问题,再判断产出是否真正解决了问题。

关键问题:
- 这个产出能达到任务声明的目标吗?
- 有没有遗漏的边界/异常?
- 如果是你在生产环境用这个代码,你放心吗?

## Scope Reduction Detection(反静默降级)
对照原始需求,检查:
- 有没有需求被静默丢弃或降级?(不说不做,只是悄悄缩小范围)
- 产出声称覆盖的范围和实际一致吗?
- 如果发现需求消失,明确指出并标记

## 审查结论
- approved:你确认质量达标,具体说好在哪里
- rejected:必须给出具体改进方向(不是"代码质量不够")
- needs_revision:方向对但细节需要调整

## 诚实边界
审查时间有限,你可能遗漏深层问题。如果有你不确定的地方,明确说出来。

注:API 端点由 spawner 拼接。置信度标注机制待系统有解析能力后再加。

关键变化:

• "审查思维"替代 checklist--先理解目标再判断
• "诚实边界"--元认知自评(ClawTeam 实践)
• review comment_type 已在 v1.x 修复(加入白名单)

3.4 司马懿审查模板(review_simayi.md)

v2.0

# 司马懿 - 挑战者

## 你是谁
魔鬼代言人。你的价值在于找到别人没想到的问题,不是走审查流程。

## 审查层级
根据任务风险等级调整审查深度:
- high → 质疑每一个假设,找到最坏情况
- standard → 关注正确性和边界
- low → 快速确认,关注明显问题

## 你的特权
反驳权:被 rejected 时可以 ACCEPT/REJECT/PARTIAL,但你必须用事实和逻辑说服对方。

## 约束
- 审查意见必须具体到可操作的修改方向
- 不批准自己写的代码
- 涉及风控/实盘,自动提级到 high

关键变化:

• "魔鬼代言人"--角色定位清晰
• 审查层级从"规则查表"变成"根据风险调整思维深度"
• 保留反驳权机制

3.5 庞统 Review 模板(review_pangtong.md)

v2.0

# 庞统 - 多轮迭代协调

## 你是谁
任务协调员。你的目标是在迭代中推动任务收敛到目标,不是机械地"检查后通过"。

## 三问框架
1. Goal 还清晰吗?(目标漂移检测)
2. 成果物覆盖 goal 了吗?(覆盖性检查)
3. 下一轮需要做什么?(推进方向)

## Scope Reduction Detection
对照原始需求,检查是否有需求被静默丢弃或降级。如果发现需求消失,明确指出。

## 行为
- 每轮 review 产出一个明确的下一步行动
- 发现目标漂移时及时拉回或升级用户
- Round 上限由系统控制,超过上限时升级用户

关键变化:

• 加角色定位
• "目标漂移检测"--不只是检查覆盖,还检查目标本身是否还成立

3.6 规划者模板(planner.md)

v2.1(修订后)

# 规划者

## 你是谁
把模糊需求变成可执行计划。计划是活的,不是一次性的。

## 规划思维
1. 先理解用户真正要什么
2. 拆解成可独立执行、可验证的子任务
3. 每个子任务有明确的终态(不是"完成 XX",而是"XX 可通过 Y 验证")
4. 识别依赖和风险

## 计划是活的
执行过程中随时调整。发现新信息 → 更新计划。Agent 报告阻塞 → 重新安排。

## 约束
- 需求不清时在黑板 comment 中提问(系统会通知用户),或发 Mail 给用户,不要猜
- 不懂就问,不要静默做决策

关键变化:

• "规划思维"替代 phase 查表
• "终态定义"--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 验证过

---

四、实现细节

4.1 改动范围

文件	改动点	说明
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_pangtong.md	重写	加目标漂移检测
prompt_templates/planner.md	重写	从 phase 查表到规划思维

不改的: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 内构建)

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 替换。

但这需要改动 bootstrap.py 的模板加载逻辑。为降低风险,v2.0 先不改 executor.md 的 API 注入方式--executor.md 作为"角色指南"由 bootstrap 加载,API 端点仍由 spawner 在 _build_spawn_message 中拼接。

实际改动:

• executor.md 只写角色/思维/约束(不含 API)
• reviewer.md / planner.md 同理
• API 端点仍然由 spawner/ticker 在构建完整 prompt 时注入

---

五、验证标准

E2E 验证场景

#	场景	验证点
V1	coding 任务广播	张飞认领 + 关羽写风控 observation + 赵云写数据建议 + 司马懿 NO_REPLY(或写审查准备)
V2	coding 执行	张飞自主决策执行路径,产出具 handoff
V3	review 流程	司马懿写 review comment + 置信度标注
V4	多轮迭代	庞统三问框架 + 目标漂移检测

回归验证

#	验证点
R1	现有 E2E 测试(E1/E2/E4/E6)不受影响
R2	Mail 路径不受影响
R3	Counter/Router 逻辑不受影响

---

六、风险

风险	缓解
Agent 过度自由导致产出不稳定	约束段保留硬性底线(必须写产出、必须标 review、handoff ≥ 50 字符)
observation comment 质量低	观察者有 SOUL.md 的专业判断,prompt 引导"风险/建议/交叉视角"
API 端点缺失导致 Agent 不知道怎么操作	executor/reviewer 模板的 API 由 spawner 注入,不依赖模板本身
改动范围过大	分两步:先改 claim prompt + executor.md(V1 验证),再改其余模板

---

七、实施计划(三步)

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)
审查风格	❌ Checklist	✅ 挑战者思维+置信度
规划方式	❌ Phase 查表	✅ 理解→拆解→动态调整

v1.x 的所有基础设施(counter、router、spawner、bootstrap)完全复用,不动。

---

八、第二波 AI Native 实践(v3.0 新增)

在 v2.1 的基础上,从调研报告中进一步提炼 5 个尚未借蘫但高价值的实践。以下全部已融入对应模板。

8.1 Boids 群体智能: Alignment(理解全局再行动)

来源: ClawTeam #5 Boids 群体智能规则

问题: v2.1 的三级响应解决了 Separation(不抢活)和 Cohesion(贡献 observation),但缺了 Alignment--Agent 认领任务后不读黑板就开干,可能做出和全局方向不一致的决策。

做法: 在 claim prompt 和 executor.md 中各加一句"先读黑板理解全局再行动"。具体措辞:

• claim prompt: "认领前先读黑板上的其他 comment,理解这个任务在整个项目中的位置"
• executor.md: "动手前先读黑板上的全局计划和其他 Agent 的 comment,理解你的任务在整个目标中的位置"

影响: +30 token / Agent,但减少因信息不对称导致的返工。净值正。

Boids 四条规则的落地状态：

• Separation → v2.1 已落地(claim CAS 保护 + 专长匹配)
• Cohesion → v2.1 已落地(三级响应 observe 机制)
• Alignment → v3.0 新增(读黑板理解全局)
• Boundary → 基础设施已有(SOUL.md + 约束段)

8.2 Scope Reduction Detection(反静默降级)

来源: get-shit-done Scope Reduction Detection

问题: Agent 在执行/审查过程中可能静默丢弃需求--不说不做,只是悄悄缩小范围。这是多 Agent 系统中常见的质量问题,比直接拒绝更危险,因为更难发现。

做法: 在 reviewer.md 和 review_pangtong.md 中加入显式检查项:

## Scope Reduction Detection(反静默降级)
对照原始需求,检查:
- 有没有需求被静默丢弃或降级?
- 产出声称覆盖的范围和实际一致吗?
- 如果发现需求消失,明确指出并标记

影响: 审查 prompt 增加 ~80 token。但这是质量门控的关键补充--当前审查只看"做的好不好",不看"有没有悄悄少做"。

与 P6(反静默降级原则)呼应: 这是 P6 的具体落地。

司马懿补充(已采纳): executor.md 的约束段也加入自检：“产出物覆盖任务描述的所有要求,没有静默丢弃任何需求点”。执行者自检 + 审查者复检,双重保险。

8.3 Plan 审批工作流(复杂任务先计划后执行)

来源: ClawTeam #14 Plan 审批工作流

问题: 当前 executor 模板对所有复杂度的任务一视同仁--都直接执行。复杂任务(多文件、多模块、不确定方案)直接开工容易走偏。

做法: 在 executor.md 中加入分级引导:

### 复杂任务: 先计划后执行
如果任务复杂(涉及多个文件、多个模块、或你有不确定的地方),先在黑板 comment 写出你的执行计划。如果计划写了 5 分钟内没有人提出异议,按计划执行。如果有人提出异议,调整后再执行。简单任务直接做。

设计决策: 不在 ticker 层面做 risk_level 分支(那需要改 spawner/ticker 代码),而是让 Agent 自己判断复杂度。理由:

1. Agent 有 SOUL.md 和上下文,比代码更能判断复杂度
2. 不增加基础设施改动
3. 如果 Agent 判断失误(该计划没计划),审查者的 Scope Reduction Detection 会兜住

司马懿 WARN(已采纳): “等确认后再动手”的确认者不明确。改为“5 分钟异议窗口”机制:计划写了 5 分钟内没人异议就执行,有人异议就调整。不卡住。

影响: executor.md +50 token。

8.4 经验闭环引导(handoff 中标注经验)

来源: 知识管理体系 DISCOVER→DISTILL→APPLY→IMPROVE

问题: 当前 Agent 的经验沉淀在各人的 MEMORY.md / .learnings/ 中,是自发行为,不成体系。Trajectory Distillation 项目正在批量处理历史数据,但实时经验没有采集机制。

做法: 在 executor.md 的"什么算做完了"中加入:

4. 如果有值得记录的经验(被纠正、发现更好做法),在 handoff 中标注“💡 经验: ”（注意冒号后有空格，这个前缀会被自动化脚本扫描）

设计决策: 不做复杂的经验采集流程(那需要改黑板 API 加 experience 表),而是在 handoff comment 中用前缀“💡 经验: ”标记。未来 Trajectory Distillation 可以扫描这个标记。

司马懿补充(已采纳): 格式严格固定为“💡 经验: ”（冒号+空格），后续 distillation 脚本用 body.startswith("💡 经验: ") 扫描。模板中写死格式,不给 Agent 自由发挥的空间。

影响: executor.md +30 token。零基础设施改动。

8.5 /goal Ralph Loop(持久目标保持)--暂不实施

来源: Hermes v0.13 /goal Ralph Loop

问题: 庞统在多轮 tick 之间没有持久的目标上下文。每轮广播都是无状态的--Agent 不知道"这个项目在做什么,已经做到哪了"。

做法(未来方向): ticker 在构建 claim prompt 时注入项目级别的 context(项目目标、已完成的任务摘要、当前阻塞点)。这需要 ticker 有一个项目级的 context 缓存。

暂不实施理由: 需要 ticker 层面改动(加 context 缓存逻辑),超出 prompt 模板范围。记录在此作为 Phase 4 候选。

---

附录 A:司马懿 v2.1 评审意见及回应(2026-05-31)

司马懿原文:observation 要有明确触发条件,不是"有专业判断就写"。纯粹不匹配(如司马懿看编码任务)应 NO_REPLY。建议只有领域有实际交叉时才写。

决定:完全采纳。修改 claim prompt 的第 2 级响应:

2. 不是你的活,但你的专业领域和这个任务有实际交叉 → 写 observation comment
   - 你看到什么风险?(从你的专业视角)
   - 有什么跨领域建议?(数据依赖、风控约束、部署兼容等)
   - 如果纯粹"不匹配"(你的领域和任务无交叉),NO_REPLY

关键变化:从"有专业判断就写"改为"领域有实际交叉才写"。这样只有关羽看风控相关编码任务、赵云看数据依赖相关任务时才写 observation,纯不匹配的仍然 NO_REPLY。

WARN-1: "一个 tick 只认领一个"约束位置 → 采纳

司马懿原文:v2.0 把这条约束放在认领动作描述中,不在约束段。建议保留在约束段。

决定:在约束段恢复"一个 tick 只认领一个任务"。

WARN-2: executor.md API 策略自相矛盾 → 采纳

司马懿原文:§4.3 说 executor.md 不含 API,但 §3.2 的模板包含 API。实际 API 由 spawner 拼接。

决定:executor.md 模板去掉 API 段,和 §4.3 保持一致。API 由 spawner._build_api_section() 注入。

WARN-3: 置信度标注无解析机制 → 采纳,暂缓

司马懿原文:标了 [confidence: 0.X] 但系统不解析,浪费 token。

决定:v2.1 先不在 reviewer 模板中要求置信度标注。等 ticker 的 review 完成逻辑有解析能力后再加。当前审查者的角色定位和思维转变(从 checklist 到挑战者)已经足够。

INFO-1: planner 的苏格拉底提问路径 → 采纳,明确路径

司马懿原文:planner 是被 spawn 的 Agent,不是直接和用户对话。怎么提问?

决定:planner 模板明确提问路径:"需求不清时在黑板 comment 中提问(系统会通知用户),或发 Mail 给用户。"

Design-1: observe 性能量化 → 评估

司马懿原文:每轮广播最多多少 observe comment?对上下文长度的影响?

评估:采纳 FATAL-1 的边界定义后,observe comment 大幅减少。典型场景:5 个任务 × 6 个 Agent,只有跨领域交叉才会产生 observe。估算每轮最多 3-5 条 observation(而非之前最坏的 25 条)。每条限制 200 字以内。对上下文影响可控。

补充机制:如果未来 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 -- 特殊角色

Risk-1: observe 影响 ticker 状态流转 → 不存在

司马懿原文:observe comment 可能被系统当作"Agent 对任务有响应",触发不同的完成逻辑。

验证结果:代码核实确认不存在此风险。广播场景下 _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 级别估算)。可接受。

---

附录 B：司马懿 v3.0 评审意见及回应（2026-05-31）

§8.1 Boids Alignment — ✅ 通过

司马懿 INFO: 广播场景下黑板 comment 可能很少，不建议强行多发 API 请求。

决定: 采纳。措辞改为“如果黑板上有内容就读，没有就直接认领，不要为了 Alignment 强行多发 API 请求”。

§8.2 Scope Reduction Detection — ✅ 通过

司马懿 INFO: 执行者也可能静默降级，建议 executor.md 约束段也加自检。

决定: 采纳。executor.md 约束段增加“产出物覆盖任务描述的所有要求,没有静默丢弃任何需求点”。执行者自检 + 审查者复检，双重保险。

§8.3 Plan 审批工作流 — ⚠️ WARN

司马懿 WARN: “等确认后再动手”的确认者不明确。等用户→可能不在线卡住；等审查者→还没介入；等庞统→可能在忙。

决定: 采纳。改为“5 分钟异议窗口”机制：计划写了 5 分钟内没人异议就执行，有人异议就调整。不卡住。

§8.4 经验闭环引导 — ✅ 通过

司马懿 INFO: “💡 经验:”格式要机器可读。固定为“💡 经验: ”（冒号+空格）。

决定: 采纳。模板中写死格式，后续 distillation 脚本用 body.startswith("💡 经验: ") 扫描。

§8.5 /goal Ralph Loop — ✅ 暂不实施

无异议。

Risk-3: P4-P8 编号冲突 → 不存在

核实：P1-P8 连续编号，无冲突。P4=Boids(新增)、P5=元认知(v2.1 已有)、P6=反静默降级(新增)、P7=经验闭环(新增)、P8=约束为底线(v2.1 已有，原 P5 改号)。

Risk-4: executor.md token 膨胀 → 采纳上限建议

司马懿 INFO: executor.md 从 ~400 token 可能膨胀到 ~600 token。建议单个模板不超过 500 token。

决定: 采纳。设上限：单个模板 ≤ 500 token（约 1000 中文字符）。后续新增实践超限时必须精简或合并。当前 executor.md 约 450 token，在安全范围内。

评审结论

v3.0 评审通过。无 FATAL。1 WARN（Plan 审批确认者）已修复。其余 INFO 已采纳。