dsh-vibe-math 2.0.21 → 2.0.22
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -21
- package/README.md +5 -4
- package/RELEASE-NOTES-2.0.22.md +112 -0
- package/cordis.patch.yml +9 -9
- package/installer.js +304 -290
- package/package.json +10 -4
- package/vibe-math-v2/agent.cordis.yml +256 -212
- package/vibe-math-v2/preset.yml +2 -2
- package/vibe-math-v2/vibe-math-v2.js +243 -36
- package/vibe-math-v3/agent.cordis.yml +278 -226
- package/vibe-math-v3/preset.yml +2 -2
- package/vibe-math-v3/vibe-math-v3.js +2938 -2631
- package/vibe-math-v3//345/256/236/347/216/260/346/226/271/346/241/210.md +540 -540
- package/vibe-math-v4/agent.cordis.yml +300 -239
- package/vibe-math-v4/preset.yml +2 -2
- package/vibe-math-v4/vibe-math-v4.js +1275 -1111
- package/vibe-math-v4//345/256/236/347/216/260/346/226/271/346/241/210.md +647 -636
|
@@ -1,636 +1,647 @@
|
|
|
1
|
-
# Vibe Math V4 —— 常驻自组织合作研究框架（架构设计与实现方案）
|
|
2
|
-
|
|
3
|
-
> **一句话定位**：把 v3 的"中央规划器 + 确定性角色（explorer/solver/verifier/planner/method-keeper）"调度，升级为一组**持久化的常驻子代理**——它们之间**互相留言、集体开会**，自主决定接下来的一切任务（探索、尝试、验证、分工）。框架只做**媒介（消息总线/会议/任务板）、产物沉淀、共识验证、上下文管理、断点续跑**，**绝不分配任务**。像现实中的合作研究小组：人人有自己持续积累的笔记本与成果库，互相看、互相讨论、共同定论。
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 0. 背景与动机
|
|
8
|
-
|
|
9
|
-
v3（以及 v1/v2）给人的观感：**每个代理太专攻、上下文被切得太零碎**——explorer 只管拆方向、solver 只管一轮、verifier 只管审查、planner 调度、method-keeper 沉淀；各自只见局部，缺少"一个研究者持续投入、与人碰撞"的整体感。解决的产物也散落在多个角色的产出里，缺乏一个人一贯的思考痕迹。
|
|
10
|
-
|
|
11
|
-
V4 的核心转变：**让"研究者"本身成为主体**——若干常驻子代理持续存在、各自持有方向与积累，它们的交流与决策就是整个系统的"调度"。系统不再"指挥"它们，而是**促成**它们交流、**记录**它们的成果、**只在它们一致同意时**定论。
|
|
12
|
-
|
|
13
|
-
---
|
|
14
|
-
|
|
15
|
-
## 1. 与 v1/v2/v3 对比
|
|
16
|
-
|
|
17
|
-
| 维度 | v1（流水线） | v2（概率驱动） | v3（规划代理+角色） | **v4（常驻自组织）** |
|
|
18
|
-
|---|---|---|---|---|
|
|
19
|
-
| 调度 | 固定流水线状态机 | 代码启发式固定序 | 规划代理产 N 步计划 | **无中央调度**；任务由常驻互相通信/会议涌现 |
|
|
20
|
-
| 工作者 | 一次性子代理 | 一次性子代理 | 一次性子代理 | **常驻子代理**（持久上下文、可持续） |
|
|
21
|
-
| 任务分工 | 代码指定 | 代码指定 | 规划器指定 | **常驻们开会/留言决定** |
|
|
22
|
-
| 验证 | 多验证器投票→裁决 | 多验证器辩论→裁决（forced/flat） | 多验证器辩论→近共识裁决 | **全体常驻一致才定论**，否则留库附概率 |
|
|
23
|
-
| 产物归属 | 全局 | 全局 | 按路径 | **按常驻 id 归属**（每人自己的进展/命题/方法/子问题库） |
|
|
24
|
-
| 上下文管理 | 无 | 无 | 无 | **常驻上下文占比达阈值自动 `/compact`** |
|
|
25
|
-
| 停止 | 全解或卡死 | 全解或卡死 | 全解/无候选 | **全体常驻一致认为原问题已解决**才停 |
|
|
26
|
-
| 人工干预 | manual 门 | manual 门 | manual 门 | **随时可留言/提要求/开会/增开关闭常驻** |
|
|
27
|
-
|
|
28
|
-
---
|
|
29
|
-
|
|
30
|
-
## 2. 设计原则（你的哲学 → 架构规则）
|
|
31
|
-
|
|
32
|
-
1. **常驻主体**：起始产生 N 个常驻子代理，先各自对原问题头脑风暴，产出初始见解/方向；此后一直保持工作，直到全体认为解决。
|
|
33
|
-
2. **完全内部自组织**：之后所有任务安排（含朝某方向探索、尝试、分工、验证）都由它们之间**留言 + 开会**决定；框架不指派。
|
|
34
|
-
3. **自我验证 + 按价值沉淀**：每次思考产出的有价值内容，**自己**决定是否记入**自己**的 progress / 命题库 / 方法库 / 子问题库；记录至少注明 **价值程度 / 动机用途计划 / 自身概率估计**。
|
|
35
|
-
4. **互相可见**：常驻可查看、阅读彼此的 progress / 命题 / 方法 / 子问题库（只读）。
|
|
36
|
-
5. **验证 = 全体一致**：验证由常驻们**自行商议**何时、对哪个对象发起辩论；**只有全部常驻一致判真（或一致判假）**才写入 `Verified/`；否则留在库中并附概率 + 辩论记录。
|
|
37
|
-
6. **上下文管理**：常驻上下文量达阈值（默认 66%，可调）→ 对其实施 DSH `/compact`。
|
|
38
|
-
7. **可控**：允许助手/人工中途干预（留言、提要求、开会、增开/关闭某常驻）；不影响"之后一切由它们自组织"。
|
|
39
|
-
8. **持续化**：所有产物 + 常驻注册表 + 邮件箱 + 任务板 + 会议录持久化，支持断点续跑；多项目/多会话隔离。
|
|
40
|
-
|
|
41
|
-
---
|
|
42
|
-
|
|
43
|
-
## 3. 架构图
|
|
44
|
-
|
|
45
|
-
```mermaid
|
|
46
|
-
flowchart TD
|
|
47
|
-
subgraph 常驻层[常驻子代理（continuable，持久上下文）]
|
|
48
|
-
R1[R-1 方向A] ; R2[R-2 方向B] ; R3[R-3 方向C] ; RN[... R-N]
|
|
49
|
-
end
|
|
50
|
-
|
|
51
|
-
subgraph 媒介层[框架 vibe-v4（媒介/沉淀/共识/上下文）]
|
|
52
|
-
BUS[消息总线·邮件箱]
|
|
53
|
-
MTG[会议/辩论]
|
|
54
|
-
TASK[任务板]
|
|
55
|
-
PERSIST[产物沉淀]
|
|
56
|
-
VERIFY[共识验证]
|
|
57
|
-
COMPACT[/compact 监测]
|
|
58
|
-
STATE[State 注册表/锁/恢复]
|
|
59
|
-
end
|
|
60
|
-
|
|
61
|
-
subgraph 共享知识库[VibeMath/Projects/<project>]
|
|
62
|
-
PROJ[Problems/ 原问题]
|
|
63
|
-
SPROJ[Subproblems/ 各常驻子问题]
|
|
64
|
-
PROP[Propos/ 各常驻命题库]
|
|
65
|
-
METH[Methods/ 各常驻方法库]
|
|
66
|
-
PRG[Progress/ 各常驻进展]
|
|
67
|
-
VERF[Verified/ 仅共识后只读]
|
|
68
|
-
SHARED[Shared/ 会议·任务板·决策·辩论]
|
|
69
|
-
end
|
|
70
|
-
|
|
71
|
-
R1 & R2 & R3 & RN <-->|留言/开会/任务| BUS
|
|
72
|
-
BUS -->|唤醒 followup| R1
|
|
73
|
-
BUS -->|唤醒| R2
|
|
74
|
-
MTG -->|议程/结论| SHARED
|
|
75
|
-
R1 & R2 & R3 & RN -->|按价值沉淀| PROP
|
|
76
|
-
R1 & R2 & R3 & RN -->|记录| METH & SPROJ & PRG
|
|
77
|
-
R1 & R2 & R3 & RN -.->|只读他人的库| PRG & PROP & METH & SPROJ
|
|
78
|
-
VERIFY -->|全票真/假| VERF
|
|
79
|
-
VERIFY -.->|未全票→留库附概率| PROP
|
|
80
|
-
COMPACT -->|达66%| R1
|
|
81
|
-
STATE -->|断点重建| R1 & R2 & R3 & RN
|
|
82
|
-
```
|
|
83
|
-
|
|
84
|
-
---
|
|
85
|
-
|
|
86
|
-
## 4. 常驻子代理模型
|
|
87
|
-
|
|
88
|
-
### 4.1 本质
|
|
89
|
-
- 每个常驻 = 一个 DSH **continuable 子代理**：`subagents.startContinuable({ parent: 会话根代理, request, agentOptions, toolFilter })`。
|
|
90
|
-
- **持久上下文**（continuable）：跨多次唤醒记住前文，直到被 `/compact` 压缩。
|
|
91
|
-
- **唤醒** = `subagents.sendMessage(root, <childId>, [textBlock(prompt)], {signal})`（DSH 的 `subagents` 服务没有 `followup` 方法——`followup` 只是 `Agent` 对象的方法；`sendMessage` 才是服务暴露的续做 API。旧代码 `subagents.followup(...)` 在真实运行时抛 `TypeError`，导致每次唤醒都失败、小组整体停摆）；一轮收益 = 该常驻提交一次完整思考（经 `ctx.on('subagent/end')` 回归，`stateOf`=settled 时 `watchSettlement` 每次 dispose 都会重新触发一次 `/end`）。
|
|
92
|
-
- **工具**：`tools.register` 对会话内所有代理可用（处理器按 `exec.agent` 路由），故常驻可直接用 `fs` + `vibe_v4_*` 工具（写自己的库、读他人的库、发消息、提会议、记命题、发起验证）。
|
|
93
|
-
|
|
94
|
-
### 4.2 身份与上下文
|
|
95
|
-
```
|
|
96
|
-
id: r-<n> （n=1..N，可增开/关闭）
|
|
97
|
-
方向: 初始头脑风暴所得方向
|
|
98
|
-
初始上下文 = 常驻章程(§6) + 原问题完整陈述 + 本方向 + "先独立想，产出你的见解/思路/方向"
|
|
99
|
-
每轮上下文 = 常驻章程(精简) + 本人最新成果梗概 + 新到达的消息/会议录/任务认领 + "做一轮：思考→自验→按价值沉淀→交流/表决"
|
|
100
|
-
上下文占比 ≥ compactThreshold(默认66%) → 框架触发 DSH /compact
|
|
101
|
-
```
|
|
102
|
-
|
|
103
|
-
### 4.3 专属产物（持久，按常驻隔离）
|
|
104
|
-
```
|
|
105
|
-
VibeMath/Projects/<project>/
|
|
106
|
-
Progress/<r-id>/progress.md # 本人持续进展（追加式）
|
|
107
|
-
Propos/<r-id>/<p-id>.md # 本人命题
|
|
108
|
-
Methods/<r-id>/<m-id>.md # 本人理论/方法/工具
|
|
109
|
-
Subproblems/<r-id>/<s-id>.md # 本人子问题
|
|
110
|
-
# 常驻只写自己的目录；对其它常驻目录只读
|
|
111
|
-
```
|
|
112
|
-
|
|
113
|
-
---
|
|
114
|
-
|
|
115
|
-
## 5. 框架（vibe-v4 插件）= 媒介，绝不分配任务
|
|
116
|
-
|
|
117
|
-
| 能力 | 机制 | 关键点 |
|
|
118
|
-
|---|---|---|
|
|
119
|
-
| **常驻生命周期** | start 时 brainstorm→spawn N（各带初始方向）；add/remove；resume 重建 | 常驻上下文断点后需 re-spawn 并用其 `progress.md` 重种化 |
|
|
120
|
-
| **消息总线** | `vibe_v4_send_message(to, content)` → 入目标邮件箱 → 若空闲则 `sendMessage` 唤醒 | 常驻间不直接互调，全靠框架 relay（模拟收件箱）；支持 `broadcast(all)` |
|
|
121
|
-
| **会议** | `vibe_v4_meeting(agenda)` → 向全体发会议 prompt → 收齐发言 → 写 `Shared/meetings/<id>.md` → 广播结论 | 会议用于分工/方向/任务分配/提出验证/表决"是否已解决" |
|
|
122
|
-
| **任务板** | 常驻在会议/留言提议任务 → 框架记 `Shared/taskboard.md`；认领后被唤醒 | 框架只搬运，不决定谁做什么 |
|
|
123
|
-
| **产物沉淀** | `vibe_v4_publish_progress` / `record_proposition` / `record_method` / `record_subproblem` | **必填**：价值程度 / 动机用途计划 / 自身概率估计（框架校验，缺则提示） |
|
|
124
|
-
| **共识验证** | `vibe_v4_propose_verify(targetId)` → 常驻们同意后开辩论 | 独立初评→公开辩论→**全票真/假才入 Verified/**；否则留库附概率 |
|
|
125
|
-
| **停止条件** | 会议中全体常驻对"原问题已解决"投票，**全部同意** → 停止唤醒 | 人工 `abort` 始终可用 |
|
|
126
|
-
| **上下文/compact** | 监测每常驻上下文占比 ≥ 阈值 → 触发 DSH `/compact` | `compactThreshold` 默认 66，可调 |
|
|
127
|
-
| **人工/助手干预** | `vibe_v4_message(all, content)` / `vibe_v4_meeting` / `vibe_v4_add_member` / `remove_member` / `vibe_v4_message(to, content)`；`/v4` slash | 不改变"之后由它们自组织" |
|
|
128
|
-
|
|
129
|
-
---
|
|
130
|
-
|
|
131
|
-
## 6. 常驻章程（写入每个常驻初始上下文）
|
|
132
|
-
|
|
133
|
-
```
|
|
134
|
-
你是常驻研究者 R-<k>（共 N 位），与其它常驻协作解决问题：<原问题完整陈述>。
|
|
135
|
-
你的方向/起点：<初始头脑风暴方向>。
|
|
136
|
-
|
|
137
|
-
【信任规则】只有 Verified/（及 Propos 中"已验证·真/假"）绝对可信；你自己未验证的、他人的未验证产物都是经验性参考，不能当作已成立事实引用。
|
|
138
|
-
|
|
139
|
-
【每轮默认动作】
|
|
140
|
-
① 思考本方向下一步（或回应他人/会议）；
|
|
141
|
-
② 自我验证刚得到的结论，并"按价值"决定是否记入自己的 progress/命题/方法/子问题库；
|
|
142
|
-
凡入册必须写明：价值程度、动机用途计划、你对该对象为真的概率估计；
|
|
143
|
-
③ 决定是否要给某常驻留言 / 提议开会 / 提议对某对象开展共识验证辩论；
|
|
144
|
-
④ 会议或辩论中发言，对任务分工/方向/停止条件表态。
|
|
145
|
-
|
|
146
|
-
【验证规则】任何对象要进 Verified/ 必须全体常驻一致判真或判假；否则留在库中并附概率。你只信"全票同意"的。
|
|
147
|
-
|
|
148
|
-
【任务自主】下一轮你自己做什么、与他人怎么分工，由你们开会/留言决定——没有外部派活。
|
|
149
|
-
|
|
150
|
-
【可见性】你可以读所有常驻的 progress/命题/方法/子问题库；只写自己的库。
|
|
151
|
-
|
|
152
|
-
【停止】当且仅当全体一致认为原问题已解决，才会停止调度。
|
|
153
|
-
|
|
154
|
-
【干预】助手/人可能给你留言、提要求、要求开会、或增开/关闭常驻——服从并响应。
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
> 每轮回调 prompt = 常驻章程（可精简）+ 本人最新成果梗概 + 新到达输入 + "做一轮，并在结束时给出你对『原问题是否已解决』的最新看法"。
|
|
158
|
-
|
|
159
|
-
---
|
|
160
|
-
|
|
161
|
-
## 7. 数据模型 / Schema（软规范：头部锚点行 + 正文自由叙述；解析器同 v3 风格）
|
|
162
|
-
|
|
163
|
-
**常驻注册表 `State/residents.json`**
|
|
164
|
-
```json
|
|
165
|
-
{ "r-1": { "rId":"r-1", "childId":"...", "direction":"...", "status":"brainstorm|active|idle|compact",
|
|
166
|
-
"createdAt":..., "lastActiveAt":..., "contextPct":0.3 } }
|
|
167
|
-
```
|
|
168
|
-
|
|
169
|
-
**邮件箱 `State/mailboxes.json`**
|
|
170
|
-
```json
|
|
171
|
-
{ "r-1": [ { "from":"r-2", "at":..., "content":"...", "delivered":false } ] }
|
|
172
|
-
```
|
|
173
|
-
|
|
174
|
-
**任务板 `Shared/taskboard.md`**
|
|
175
|
-
```
|
|
176
|
-
- [open|claimed|done] <任务简述> (提议人: r-2, 认领人: r-3, 涉及方向: d3, 来源: 会议<id>/留言)
|
|
177
|
-
```
|
|
178
|
-
|
|
179
|
-
**命题卡 `Propos/<r-id>/<p-id>.md`**
|
|
180
|
-
```
|
|
181
|
-
- ID: p-xxx
|
|
182
|
-
- 类型: 命题
|
|
183
|
-
- 状态: 未定论|已验证·真|已验证·假
|
|
184
|
-
- 概率: 0.62
|
|
185
|
-
- 价值程度: 0.7
|
|
186
|
-
- 动机用途计划: ...（为何有价值/拟如何用于解决问题/如何回填主线）
|
|
187
|
-
- 依赖: []
|
|
188
|
-
## 陈述 （完整）
|
|
189
|
-
## 证明尝试 （### 证明 N｜…｜概率X｜状态Y）
|
|
190
|
-
## 证伪尝试 （### 证伪 N｜…｜概率X｜状态Y）
|
|
191
|
-
```
|
|
192
|
-
|
|
193
|
-
**方法卡 `Methods/<r-id>/<m-id>.md`**
|
|
194
|
-
```
|
|
195
|
-
- ID: m-xxx
|
|
196
|
-
- 类型: 理论体系|框架|工具|方法|思想|范式|技巧
|
|
197
|
-
- 状态: 经验|应用验证|含已验证断言
|
|
198
|
-
- 可信断言: [](只允许进过 Verified/ 的 id)
|
|
199
|
-
- 价值程度: 0.6
|
|
200
|
-
- 动机用途计划: ...
|
|
201
|
-
## 核心内容
|
|
202
|
-
## 定义与记号
|
|
203
|
-
## 应用记录
|
|
204
|
-
## 改进历史
|
|
205
|
-
```
|
|
206
|
-
|
|
207
|
-
**子问题卡 `Subproblems/<r-id>/<s-id>.md`**
|
|
208
|
-
```
|
|
209
|
-
- ID: s-xxx
|
|
210
|
-
- 状态: 未定论|求解中|已解决
|
|
211
|
-
- 价值程度: 0.5
|
|
212
|
-
- 动机用途计划: ...（如何回填主线 / 独立求解后如何反哺）
|
|
213
|
-
- 依赖: []
|
|
214
|
-
## 陈述 （完整）
|
|
215
|
-
## 进度
|
|
216
|
-
```
|
|
217
|
-
|
|
218
|
-
**共享写锁**：仅对 `Shared/*`、`Problems/<id>.md`、`Verified/*` 使用 `vibe_v4_claim_write/release_write`（进程级 fileOwner，同 v3）；各常驻目录内天然无冲突。
|
|
219
|
-
|
|
220
|
-
---
|
|
221
|
-
|
|
222
|
-
## 8. 共识验证（Verification）算法
|
|
223
|
-
|
|
224
|
-
```
|
|
225
|
-
1. 提议：常驻们经留言/会议达成"值得验证"的共识，对 target(命题/证明/方法/理论) 开启验证。
|
|
226
|
-
2. 框架建 Shared/debates/<target>.md；【独立初评】向每个常驻各发一次（不看他人）：
|
|
227
|
-
给 verdict(真/假/不确定) + 理由 + 概率。
|
|
228
|
-
3. 若已全票真 → 写入 Verified/命题(或方法→可信断言)/<id>.md，并回写来源库项状态=已验证·真。
|
|
229
|
-
若已全票假 → 写入 Verified/命题/<id>.md（结论=假），来源库项状态=已验证·假。
|
|
230
|
-
（问题类 target 同理：Verified/问题/<id>.md）
|
|
231
|
-
4. 否则【公开辩论】：把初评意见+理由写入辩论录，广播全体；各常驻看他人意见后重评
|
|
232
|
-
（可引用/反驳/修改），直至：全票同向，或不再出现理性新分歧。
|
|
233
|
-
（实现要点：进入 debate 轮时框架把上一轮投票快照进 `vs.history` 并**清空 `vs.verdicts`**，让每个常驻
|
|
234
|
-
都被重新询问一次——若不清理，`allVoted` 恒真，debate 轮会静默烧掉且**无人被重新询问**。）
|
|
235
|
-
5. 未全票 → 保留在来源库，概率取各常驻最后估计的平均，附"未达成全体一致"的辩论记录。
|
|
236
|
-
【要点】不设 v3 的 forced/flat/近共识自动收口——必须真实全体一致，防止强分歧被强行判真。
|
|
237
|
-
```
|
|
238
|
-
|
|
239
|
-
---
|
|
240
|
-
|
|
241
|
-
## 9. 并发 / 活性 / 隔离 / 恢复
|
|
242
|
-
|
|
243
|
-
- **活性（防僵死）**：每次 `subagent/end` 后，框架优先：
|
|
244
|
-
① 任何邮件箱非空 → 唤醒非忙收件人；
|
|
245
|
-
② 否则任务板有 open → 唤醒提议人/认领人；
|
|
246
|
-
③ 否则存在待验证提议 → 开会；
|
|
247
|
-
④ 否则"心跳"：唤醒最久未活跃者并给它开会，让它表态下一步（`activityTimeoutMs` 可调）。
|
|
248
|
-
- **并行**：同一时刻可唤醒多个空闲常驻（受 `maxParallel` 上限，默认 3，框架侧并发闸，非"指派"）。
|
|
249
|
-
- **隔离**（同 v3）：`sessions`(根代理→Session)、`childOwner`(子代理→会话路由 subagent/end)、`fileOwner`(进程级写锁跨会话)、`projectLock`(每会话)、`processEpoch`(进程级，防两会话互判陈旧)。
|
|
250
|
-
- **断点续跑**：`vibe_v4_resume` 用 `State/residents.json` + 各常驻 `progress.md` 重建常驻（re-spawn + 重种化上下文），恢复邮件箱/任务板/会议录；`processEpoch` 判断是否清空中在途轮。
|
|
251
|
-
|
|
252
|
-
---
|
|
253
|
-
|
|
254
|
-
## 10. 与 DSH 机制映射（实现时确认）
|
|
255
|
-
|
|
256
|
-
| DSH 能力 | 在本架构中的用途 |
|
|
257
|
-
|---|---|
|
|
258
|
-
| `subagents.startContinuable({parent, request, agentOptions, toolFilter})` | 产生常驻（continuable，持久上下文） |
|
|
259
|
-
| `subagents.sendMessage(root, childId, blocks, {signal})` | 唤醒常驻做一轮 / 投递一条留言 / 开会向某常驻收集发言（**服务暴露的续做 API**；旧 `subagents.followup` 不存在） |
|
|
260
|
-
| `ctx.on('subagent/end')` | 一常驻完成一轮（收其回复，续驱动） |
|
|
261
|
-
| `subagents.interrupt / list` | 中断 / 枚举常驻 |
|
|
262
|
-
| `tools.register`（会话内所有代理可用，`exec.agent` 路由） | 常驻可直接调用 `vibe_v4_*` 与 `fs` |
|
|
263
|
-
| `commands.register` | `/v4` slash 控制命令 |
|
|
264
|
-
| `contextPct` + DSH `/compact` | 上下文占比达 66% 自动压缩（精确触发点实现时确认） |
|
|
265
|
-
| `claimWrite/releaseWrite` + 项目锁（复用 v3 模式） | 共享文件写锁 + 会话项目锁 |
|
|
266
|
-
|
|
267
|
-
---
|
|
268
|
-
|
|
269
|
-
## 11. 实现阶段（只策划，不在此文档内写代码）
|
|
270
|
-
|
|
271
|
-
- **P0 脚手架**：`vibe-math-v4/`（`agent.cordis.yml`、`preset.yml`、`vibe-math-v4.js`）；`installer.js` 增加 v4 安装/能力自检；`package.json files` 增加 v4；README 增 V4 小节。
|
|
272
|
-
- **P1 常驻生命周期**：brainstorm→spawn N(各带方向)→track→wake→(`subagent/end`)→compact→resume；brainstormPhase 只产出初始方向并持久。
|
|
273
|
-
- **P2 消息总线 + 邮件箱 + 跨读**：`send_message`/mailbox/唤醒；他人库只读工具；写锁。
|
|
274
|
-
- **P3 会议 + 任务板 + 决策**：`meeting`/taskboard/decisions；分工涌现。
|
|
275
|
-
- **P4 产物沉淀**：`record_proposition/method/subproblem` + `publish_progress`（价值/动机/概率必填校验）。
|
|
276
|
-
- **P5 共识验证**：`propose_verify` + 独立初评 + 公开辩论 + 全票闭环；`Verified/` 生成与来源库回写。
|
|
277
|
-
- **P6 停止 + 干预 + 恢复**：stop-vote(全票 solved)/abort/pause/resume；`add_member/remove_member/message(all)`。
|
|
278
|
-
- **P7 测试**：`selfdrive-v4.mjs`（常驻互相留言/开会/沉淀/共识验证/compact/停止 的全流程记录器）；E2E 断言：消息送达、会议记录、仅全票入 Verified、未全票留库附概率、compact 触发、仅全体一致才 stop、resume。
|
|
279
|
-
|
|
280
|
-
---
|
|
281
|
-
|
|
282
|
-
## 12. 边界 / 失败 / 风险
|
|
283
|
-
|
|
284
|
-
| 场景 | 处理 |
|
|
285
|
-
|---|---|
|
|
286
|
-
| 全员等待、无人行动（僵死） | §9 活性机制（mailbox→taskboard→verify提案→心跳会议）兜底 |
|
|
287
|
-
| 共识永达不成 | 对象留库附概率，不阻塞其它工作；不强行裁决 |
|
|
288
|
-
| 上下文 blow-up | compact 阈值 + 每轮只带"梗概+新输入"；会议/辩论录按需截断 |
|
|
289
|
-
| 共享文件并发 | 写锁；各常驻专属文件无锁 |
|
|
290
|
-
| 常驻崩溃/退出 | `subagent/end` 异常置 `idle`；`resume` 重建 |
|
|
291
|
-
| 常驻误用工具 | 默认继承会话工具；可用 `toolFilter` 收权为 `fs` + `vibe_v4_*` + 只读库工具 |
|
|
292
|
-
| 多项目并发 | 各项目 `State/`+`Shared/` 隔离；`projectLock` 防两会话跑同一项目 |
|
|
293
|
-
|
|
294
|
-
---
|
|
295
|
-
|
|
296
|
-
## 13. 参数默认值
|
|
297
|
-
|
|
298
|
-
| 参数 | 建议默认 | 说明 |
|
|
299
|
-
|---|---|---|
|
|
300
|
-
| `residentCount` | 4 | 常驻数（可 `add_member` 增减） |
|
|
301
|
-
| `compactThreshold` | 66 | 常驻上下文占比达此值触发 `/compact` |
|
|
302
|
-
| `maxParallel` | 3 | 同时唤醒的常驻上限（框架侧并发闸，非指派） |
|
|
303
|
-
| `activityTimeoutMs` | 120000 | 无新消息/任务/提案时的心跳间隔 |
|
|
304
|
-
| `verdictQuorum` | `all` | 固定"全部常驻一致"（哲学要求，不建议放宽） |
|
|
305
|
-
| `perResidentLibs` | 每常驻独立目录 | 若"共享库+署名"会重新引入写锁竞争，不推荐 |
|
|
306
|
-
|
|
307
|
-
---
|
|
308
|
-
|
|
309
|
-
## 14. 成功标准（验收）
|
|
310
|
-
|
|
311
|
-
1. 起始产生 N 个常驻，先各自头脑风暴、产出初始见解/方向。
|
|
312
|
-
2. 此后所有任务安排（探索/尝试/分工/验证）由常驻们互相留言/开会决定，无中央调度器。
|
|
313
|
-
3. 每个常驻有专属、持久的 progress/命题/方法/子问题库，可互相阅读。
|
|
314
|
-
4. 记录产物必带 价值程度 / 动机用途计划 / 自身概率估计。
|
|
315
|
-
5. 验证由常驻自行商议发起；仅全体一致（真 或 假）才入 `Verified/`；否则留库附概率。
|
|
316
|
-
6. 常驻上下文达 66%（可调）自动 `/compact`。
|
|
317
|
-
7. 允许助手/人工中途干预（留言/提要求/开会/增开关闭常驻）。
|
|
318
|
-
8. 仅当全体常驻一致认为原问题已解决才停止调度。
|
|
319
|
-
9. 支持断点续跑、多会话/多项目隔离、共享文件写锁 + 常驻专属文件隔离。
|
|
320
|
-
|
|
321
|
-
---
|
|
322
|
-
|
|
323
|
-
## 15. 待确认项（实现前与用户敲定；已给建议默认）
|
|
324
|
-
|
|
325
|
-
- 常驻数默认 4，是否直接给用户一个 `residentCount` 参数。
|
|
326
|
-
- 是否允许"只读他人库但需授权"（哲学已允许互相阅读，默认全读）。
|
|
327
|
-
- `verdictQuorum` 是否始终为 `all`（哲学强调一致，默认不改）。
|
|
328
|
-
- `perResidentLibs`（每常驻独立目录 vs 共享库+署名）——默认独立。
|
|
329
|
-
- DSH `/compact` 的精确触发 API（实现 P1 时确认）。
|
|
330
|
-
|
|
331
|
-
---
|
|
332
|
-
|
|
333
|
-
## 16. 实现现状备注（P5/P6 已落地，v1.3.x）
|
|
334
|
-
|
|
335
|
-
**任务板认领（P5）**：`vibe_v4_propose_task / claim_task / task_done / list_tasks`。常驻可在回复或会议中提议/认领任务；认领后框架**唤醒认领者**带任务工作；任务板落盘 `Shared/taskboard.md` + `State/taskboard.json`；会议结束落任务板/触发验证目标。
|
|
336
|
-
|
|
337
|
-
**上下文 / /compact（P5）**：DSH 打包未暴露"子代理上下文占比 + `/compact`" RPC，故实现**等效真实压缩**——常驻用 `vibe_v4_report_context {pct}` 上报占比；达 `compactThreshold`(66) 或 `compactAfterRounds` 轮数时，框架在下次唤醒前注入"[CONTEXT COMPACT — 浓缩自述]"指令，常驻把工作状态浓缩为一段自述并在回复里带 `contextPct`(低)、`compacted:true`；框架记录**浓缩种子**为后续上下文并复位 `roundsSinceCompact/needCompact`。`compactThreshold/compactAfterRounds/meetingKeepEvery` 均可调。
|
|
338
|
-
|
|
339
|
-
**会议主动触发（P6）**：
|
|
340
|
-
- 常驻 normal 回复里 `propose_meeting` 自触发会议；助手亦可 `vibe_v4_meeting`。
|
|
341
|
-
- **自动同步会议**：每积累 `meetingKeepEvery`(默认 5) 个新产物，框架自动发起"分工/进展/是否需要验证"同步会议。
|
|
342
|
-
- 会议输入可含 `propose_task/claim_task/propose_verify/voteSolved`，结束统一落任务板、触发验证、记停止表决；仍"全体一致 voteSolved=true 才停止"。
|
|
343
|
-
|
|
344
|
-
---
|
|
345
|
-
|
|
346
|
-
## 17. 深度审计修复（v1.3.2，自驱动 20/20）
|
|
347
|
-
|
|
348
|
-
一次对 v4 的全面审计发现并修复了以下真实缺陷（`vibe-math-v4.js`）：
|
|
349
|
-
|
|
350
|
-
| 缺陷 | 说明 | 修复 |
|
|
351
|
-
|---|---|---|
|
|
352
|
-
| **上下文压缩按占比失效** | `contextPct` 被 `cl()` 压成 `[0,1]`，与 `compactThreshold`(66 百分比)比较变成 `1.0>=66` 恒假，导致"达到占比自动 `/compact`"从不触发；压缩后复位也被同样钳死。 | `contextPct` 按 **0–100 百分比**保存（新增 `clPct`），比较与复位随之修正。 |
|
|
353
|
-
| **常驻工具按全局槽路由** | 所有常驻工具用共享的 `currentResident`（一个可变全局），并发下（尤其 brainstorm 阶段 N 个常驻同时在途）所有产物/留言都归到"最后一个被唤醒者"，破坏每常驻独立库。 | 工具 handler 接收 `exec.agent`，按 `childId === agent.id` 解析"调用者常驻"（`residentIdOf`）；未知调用者再回落 `currentResident`。 |
|
|
354
|
-
| **`vibe_v4_read_progress` 失效** | handler 返回 `text: s.readProgress(...)`（一个未 await 的 Promise），`JSON.stringify` 后变 `{}`，常驻读不到他人进展。 | 改为 `await` 并返回 `{ok,text:<string>}`。 |
|
|
355
|
-
| **跨进程断点不重建常驻** | `resume()` 只在 `childId` 为空时 re-spawn；崩溃/重启后持久化的 `childId` 是陈旧值，导致不重建且对死链 followup；且 resume 从不 `scheduleNext()`。 | `session.json` 持久化 `processEpoch`；`resume()` 检测跨进程（epoch 不同）→ 清空陈旧 `childId` 强制 re-spawn，且末尾 `scheduleNext()` 重启调度。 |
|
|
356
|
-
| **`message(all)` 广播是空壳** | `to==='all'` 只返回一句 `broadcast: ...` 但什么都不投递。 | 新增 `broadcast()`：对每个常驻 `postMessage`（空闲唤醒/忙则入信箱），返回"投递到 N 个常驻"。 |
|
|
357
|
-
| **`addMember` 出现 id 碰撞** | `newResident` 用 `'r-'+(residents.size+1)`；移除某常驻后再增开会用与现存常驻重复的 id。 | 改用会话级单调 `residentSeq`（`start()` 时清零），增开永不复用旧 id。 |
|
|
358
|
-
|
|
359
|
-
> **未改（保留为已知边界）**：`maxParallel`/`activityTimeoutMs` 目前为声明参数但未实际限流/门控（保持"常驻持续推进"的收敛行为，未做心跳超时门控以免阻塞自组织推进）；`claim_write`/`release_write` 仍为占位（常驻专属目录内天然无写冲突，共享文件由框架独占写）；真实 DSH `/compact` API
|
|
360
|
-
|
|
361
|
-
---
|
|
362
|
-
|
|
363
|
-
## 18. 第二轮深度审计修复（v1.3.3，自驱动 21/21 + 独立修复测试 8/8）
|
|
364
|
-
|
|
365
|
-
针对 v1.3.2 之后仍存在的缺陷做第二轮审计并修复：
|
|
366
|
-
|
|
367
|
-
| 缺陷 | 说明 | 修复 |
|
|
368
|
-
|---|---|---|
|
|
369
|
-
| **非全票验证不写回平均概率** | `finalizeVerify` 算出 `avg` 只写进辩论录，源卡 `- 概率:` 保持原值，未兑现设计 §8"留库附概率"。 | 新增 `findSourceRel`/`rewriteSourceProb`，非全票时把 `avg` 写回源卡 `- 概率:`（状态仍 `未定论`）。 |
|
|
370
|
-
| **方法型验证被误标为"命题"** | `writeVerifiedCard` 把方法目标写进 `Verified/命题/` 且类型=命题。 | 按 `targetType` 标 `类型: 方法`（子问题→问题，方法→方法，其余→命题），来源卡标 `已验证·真/假`。 |
|
|
371
|
-
| **同进程 abort→resume 不重建常驻** | `processEpoch` 进程级，同进程 abort（interrupt 杀掉常驻）后 resume 判非跨进程→保留死 childId；且 `phase=idle && !running` 时 resume 直接拒绝。 | `initAbort` 清空 `childId` 并 `saveAll()`；`resume` 守卫改为 `phase==='idle' && !running && residents.size===0`（有常驻即可 重建）。 |
|
|
372
|
-
| **abort→resume 重种化不彻底（牵连修复）** | 同进程 abort 后 `phase='idle'`、childId 已清空，但旧居民 `status='active'` 且旧 `insight` 仍在；resume 走"非跨进程"分支不清状态，直接 re-spawn 后落入 `phase='active'`——重种化居民在第一轮 brainstorm 期间就被当作 active 处理（brainstorm 汇总不写）；且被 interrupt 的**旧**居民迟到的 `subagent/end`（同名 rId）会删除**新**居民的 busy 标记。 | `resume()` 用 `needRespawn`（任一 childId 为空）统一判定：**任何 re-spawn（跨进程或同进程 abort）** 都清空 busy/wakeKind/currentResident/pendingMeeting/pendingVerify/verifyState/meetingState，并把居民 `status='brainstorm'`、`insight=''`、`phase='brainstorm'`——让重种化居民真正重新头脑风暴、汇总正常写出、旧居民的迟到 end 不会污染新居民的 busy。 |
|
|
373
|
-
| **自动同步会议计数不一致** | `bumpArtifacts` 只在记录方法/子问题时调用，`recordProposition`/`publish_progress` 不计；`artifactCount` 未持久化。 | `recordProposition` 也 `bumpArtifacts()`；`artifactCount` 持久化到 `session.json` 并在 `start()` 时清零。 |
|
|
374
|
-
| **唤醒信号硬编码 60s** | `spawnResident`/`wakeResident` 用 `makeSignal(60000)`，比 `activityTimeoutMs`(120s) 短。 | 改用 `makeSignal(params.activityTimeoutMs||60000)`。 |
|
|
375
|
-
| **`verdictMaxRounds`/`meetingKeepEvery` 不可调/不展示** | `verdictMaxRounds` 不在 `vibe_v4_set` schema；两者都不在 `status()` 参数串。 | `vibe_v4_set` 增加 `verdictMaxRounds`；`status()` 参数串补 `meetingKeepEvery` 与 `verdictMaxRounds`。 |
|
|
376
|
-
|
|
377
|
-
> 测试：`selfdrive-v4.mjs` 21/21（新增 B1 参数可见性断言）；新增 `e2e-v4-fixes.test.mjs` 8/8（每项修复用独立 mock 宿主驱动：A1 非全票写回、A2 方法标 `类型: 方法`、A3 同进程 abort→resume 重建、B2 记录命题自动开会）。
|
|
378
|
-
|
|
379
|
-
> **已知边界（未改）**：`maxParallel`/`activityTimeoutMs` 仍未实际限流/心跳门控（避免破坏"持续推进→收敛"）；`claim_write`/`release_write` 仍未落地为真锁；真实 DSH `/compact` API
|
|
380
|
-
|
|
381
|
-
---
|
|
382
|
-
|
|
383
|
-
## 19. 边界 A 落地 + 真实 `/compact`（v1.3.5）
|
|
384
|
-
|
|
385
|
-
### 边界 A：事件驱动 + `activityTimeoutMs` 心跳门控 + `maxParallel` 限流
|
|
386
|
-
此前 `scheduleNext()` **无条件**唤醒"最久没动的人"，导致"只要没达到全体一致 solved 就永远烧 token 推进"。现改为贴合哲学"框架绝不指派/促成"的做法：
|
|
387
|
-
|
|
388
|
-
- **事件驱动为主**：有信（邮箱）、任务板 open、验证提案、会议请求 → 才唤醒对应常驻（不变）。
|
|
389
|
-
- **心跳门控**：`scheduleNext` 只在"某常驻空闲时间 ≥ `activityTimeoutMs`"时，才唤醒"最久没动的人"，并给它 **CHECKPOINT 提示词**：*"说明你下一步做什么；若已无产出/认为接近解决 → 提议开会/验证 或 声明 solved。"* 这样既防僵死，又施加**收敛/停止**压力，而非无限推进。
|
|
390
|
-
- **`maxParallel` 限流**：`scheduleNext` 唤醒前检查 `busy.size < maxParallel`，超限则改为 `armHeartbeat()` 等待（brainstorm 阶段的"各自独立想"仍一次全开，常态/会议/验证轮受控）。
|
|
391
|
-
- 新增 `heartbeatTimer` 心跳定时器：`scheduleNext` 无事可做且无人空闲到阈值时，用 `activityTimeoutMs` 定时重查；每次唤醒/开会/验证/start/pause/abort 都会 `clearHeartbeat()` 避免僵尸定时器。
|
|
392
|
-
|
|
393
|
-
> 行为变化：真实运行里若常驻都在推进（每轮 < `activityTimeoutMs`），心跳基本不触发；只有真正"无事可做"才触发一次 CHECKPOINT，推动收敛。测试中把 `activityTimeoutMs` 设小（如 40ms）以驱动自组织收敛。
|
|
394
|
-
|
|
395
|
-
### 真实 DSH `/compact`
|
|
396
|
-
找到了 DSH 真实压缩服务：**`ctx.compaction`**（`@deepseek-ai/dsh-compaction` 的 `CompactionEngine`，`agent.cordis.yml` 已加载 compaction-basic）。v4 现在对每个常驻做**真实压缩**：
|
|
397
|
-
|
|
398
|
-
- 在 `
|
|
399
|
-
- `compactIfNeeded` 用 `ctx.tokenMeter` **真实测量**该常驻会话 token 量，超过其模型上下文窗口阈值时把旧历史折叠成总结节点——真正的 `/compact` 效果（而非仅"注入浓缩指令+记账复位"）。
|
|
400
|
-
- 成功后复位 `roundsSinceCompact/needCompact` 并记 `logActivity`。**若宿主未提供 `ctx.compaction`（或模型未配 `contextWindow`）则静默回退**到现有"自述指令"等效层。
|
|
401
|
-
|
|
402
|
-
>
|
|
403
|
-
|
|
404
|
-
|
|
405
|
-
|
|
406
|
-
|
|
407
|
-
|
|
408
|
-
|
|
409
|
-
|
|
410
|
-
|
|
411
|
-
|
|
412
|
-
|
|
413
|
-
|
|
414
|
-
|
|
415
|
-
|
|
416
|
-
|
|
417
|
-
|
|
418
|
-
|
|
419
|
-
|
|
420
|
-
|
|
421
|
-
|
|
422
|
-
|
|
423
|
-
|
|
424
|
-
|
|
425
|
-
|
|
426
|
-
|
|
427
|
-
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
|
|
431
|
-
|
|
432
|
-
|
|
433
|
-
|
|
434
|
-
|
|
435
|
-
|
|
436
|
-
|
|
437
|
-
|
|
438
|
-
|
|
439
|
-
|
|
440
|
-
|
|
441
|
-
|
|
442
|
-
|
|
443
|
-
|
|
444
|
-
|
|
445
|
-
|
|
446
|
-
|
|
447
|
-
|
|
448
|
-
|
|
449
|
-
|
|
450
|
-
|
|
451
|
-
|
|
452
|
-
|
|
453
|
-
|
|
454
|
-
|
|
455
|
-
|
|
456
|
-
###
|
|
457
|
-
|
|
458
|
-
|
|
459
|
-
###
|
|
460
|
-
|
|
461
|
-
|
|
462
|
-
|
|
463
|
-
|
|
464
|
-
|
|
465
|
-
|
|
466
|
-
|
|
467
|
-
|
|
468
|
-
|
|
469
|
-
|
|
470
|
-
|
|
471
|
-
|
|
472
|
-
###
|
|
473
|
-
|
|
474
|
-
|
|
475
|
-
|
|
476
|
-
|
|
477
|
-
|
|
478
|
-
|
|
479
|
-
|
|
480
|
-
|
|
481
|
-
|
|
482
|
-
|
|
483
|
-
|
|
484
|
-
-
|
|
485
|
-
|
|
486
|
-
|
|
487
|
-
|
|
488
|
-
|
|
489
|
-
|
|
490
|
-
|
|
491
|
-
|
|
492
|
-
|
|
493
|
-
|
|
494
|
-
-
|
|
495
|
-
|
|
496
|
-
|
|
497
|
-
|
|
498
|
-
|
|
499
|
-
|
|
500
|
-
|
|
501
|
-
|
|
502
|
-
|
|
503
|
-
|
|
504
|
-
|
|
505
|
-
|
|
506
|
-
|
|
507
|
-
-
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
|
|
513
|
-
|
|
514
|
-
|
|
515
|
-
|
|
516
|
-
|
|
517
|
-
|
|
518
|
-
|
|
519
|
-
|
|
520
|
-
|
|
521
|
-
|
|
522
|
-
|
|
523
|
-
|
|
524
|
-
|
|
525
|
-
|
|
526
|
-
|
|
527
|
-
-
|
|
528
|
-
-
|
|
529
|
-
|
|
530
|
-
|
|
531
|
-
|
|
532
|
-
|
|
533
|
-
|
|
534
|
-
|
|
535
|
-
|
|
536
|
-
|
|
537
|
-
|
|
538
|
-
-
|
|
539
|
-
- `
|
|
540
|
-
-
|
|
541
|
-
|
|
542
|
-
|
|
543
|
-
|
|
544
|
-
|
|
545
|
-
|
|
546
|
-
|
|
547
|
-
|
|
548
|
-
|
|
549
|
-
|
|
550
|
-
|
|
551
|
-
|
|
552
|
-
|
|
553
|
-
|
|
554
|
-
|
|
555
|
-
|
|
556
|
-
|
|
557
|
-
|
|
558
|
-
|
|
559
|
-
|
|
560
|
-
|
|
561
|
-
|
|
562
|
-
|
|
563
|
-
|
|
564
|
-
-
|
|
565
|
-
-
|
|
566
|
-
-
|
|
567
|
-
-
|
|
568
|
-
|
|
569
|
-
|
|
570
|
-
|
|
571
|
-
|
|
572
|
-
|
|
573
|
-
|
|
574
|
-
|
|
575
|
-
|
|
576
|
-
|
|
577
|
-
|
|
578
|
-
|
|
579
|
-
|
|
580
|
-
|
|
581
|
-
|
|
582
|
-
|
|
583
|
-
|
|
584
|
-
-
|
|
585
|
-
|
|
586
|
-
|
|
587
|
-
|
|
588
|
-
|
|
589
|
-
|
|
590
|
-
|
|
591
|
-
|
|
592
|
-
|
|
593
|
-
|
|
594
|
-
|
|
595
|
-
-
|
|
596
|
-
-
|
|
597
|
-
|
|
598
|
-
|
|
599
|
-
|
|
600
|
-
-
|
|
601
|
-
|
|
602
|
-
|
|
603
|
-
|
|
604
|
-
|
|
605
|
-
|
|
606
|
-
|
|
607
|
-
|
|
608
|
-
|
|
609
|
-
|
|
610
|
-
-
|
|
611
|
-
-
|
|
612
|
-
|
|
613
|
-
|
|
614
|
-
|
|
615
|
-
-
|
|
616
|
-
|
|
617
|
-
|
|
618
|
-
|
|
619
|
-
|
|
620
|
-
|
|
621
|
-
|
|
622
|
-
|
|
623
|
-
|
|
624
|
-
|
|
625
|
-
-
|
|
626
|
-
-
|
|
627
|
-
-
|
|
628
|
-
-
|
|
629
|
-
|
|
630
|
-
>
|
|
631
|
-
|
|
632
|
-
|
|
633
|
-
|
|
634
|
-
|
|
635
|
-
|
|
636
|
-
|
|
1
|
+
# Vibe Math V4 —— 常驻自组织合作研究框架（架构设计与实现方案）
|
|
2
|
+
|
|
3
|
+
> **一句话定位**：把 v3 的"中央规划器 + 确定性角色（explorer/solver/verifier/planner/method-keeper）"调度，升级为一组**持久化的常驻子代理**——它们之间**互相留言、集体开会**，自主决定接下来的一切任务（探索、尝试、验证、分工）。框架只做**媒介（消息总线/会议/任务板）、产物沉淀、共识验证、上下文管理、断点续跑**，**绝不分配任务**。像现实中的合作研究小组：人人有自己持续积累的笔记本与成果库，互相看、互相讨论、共同定论。
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 0. 背景与动机
|
|
8
|
+
|
|
9
|
+
v3（以及 v1/v2）给人的观感：**每个代理太专攻、上下文被切得太零碎**——explorer 只管拆方向、solver 只管一轮、verifier 只管审查、planner 调度、method-keeper 沉淀；各自只见局部，缺少"一个研究者持续投入、与人碰撞"的整体感。解决的产物也散落在多个角色的产出里，缺乏一个人一贯的思考痕迹。
|
|
10
|
+
|
|
11
|
+
V4 的核心转变：**让"研究者"本身成为主体**——若干常驻子代理持续存在、各自持有方向与积累，它们的交流与决策就是整个系统的"调度"。系统不再"指挥"它们，而是**促成**它们交流、**记录**它们的成果、**只在它们一致同意时**定论。
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## 1. 与 v1/v2/v3 对比
|
|
16
|
+
|
|
17
|
+
| 维度 | v1（流水线） | v2（概率驱动） | v3（规划代理+角色） | **v4（常驻自组织）** |
|
|
18
|
+
|---|---|---|---|---|
|
|
19
|
+
| 调度 | 固定流水线状态机 | 代码启发式固定序 | 规划代理产 N 步计划 | **无中央调度**；任务由常驻互相通信/会议涌现 |
|
|
20
|
+
| 工作者 | 一次性子代理 | 一次性子代理 | 一次性子代理 | **常驻子代理**（持久上下文、可持续） |
|
|
21
|
+
| 任务分工 | 代码指定 | 代码指定 | 规划器指定 | **常驻们开会/留言决定** |
|
|
22
|
+
| 验证 | 多验证器投票→裁决 | 多验证器辩论→裁决（forced/flat） | 多验证器辩论→近共识裁决 | **全体常驻一致才定论**，否则留库附概率 |
|
|
23
|
+
| 产物归属 | 全局 | 全局 | 按路径 | **按常驻 id 归属**（每人自己的进展/命题/方法/子问题库） |
|
|
24
|
+
| 上下文管理 | 无 | 无 | 无 | **常驻上下文占比达阈值自动 `/compact`** |
|
|
25
|
+
| 停止 | 全解或卡死 | 全解或卡死 | 全解/无候选 | **全体常驻一致认为原问题已解决**才停 |
|
|
26
|
+
| 人工干预 | manual 门 | manual 门 | manual 门 | **随时可留言/提要求/开会/增开关闭常驻** |
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## 2. 设计原则（你的哲学 → 架构规则）
|
|
31
|
+
|
|
32
|
+
1. **常驻主体**：起始产生 N 个常驻子代理，先各自对原问题头脑风暴，产出初始见解/方向；此后一直保持工作，直到全体认为解决。
|
|
33
|
+
2. **完全内部自组织**：之后所有任务安排（含朝某方向探索、尝试、分工、验证）都由它们之间**留言 + 开会**决定；框架不指派。
|
|
34
|
+
3. **自我验证 + 按价值沉淀**：每次思考产出的有价值内容，**自己**决定是否记入**自己**的 progress / 命题库 / 方法库 / 子问题库；记录至少注明 **价值程度 / 动机用途计划 / 自身概率估计**。
|
|
35
|
+
4. **互相可见**：常驻可查看、阅读彼此的 progress / 命题 / 方法 / 子问题库（只读）。
|
|
36
|
+
5. **验证 = 全体一致**：验证由常驻们**自行商议**何时、对哪个对象发起辩论；**只有全部常驻一致判真（或一致判假）**才写入 `Verified/`；否则留在库中并附概率 + 辩论记录。
|
|
37
|
+
6. **上下文管理**：常驻上下文量达阈值（默认 66%，可调）→ 对其实施 DSH `/compact`。
|
|
38
|
+
7. **可控**：允许助手/人工中途干预（留言、提要求、开会、增开/关闭某常驻）；不影响"之后一切由它们自组织"。
|
|
39
|
+
8. **持续化**：所有产物 + 常驻注册表 + 邮件箱 + 任务板 + 会议录持久化，支持断点续跑；多项目/多会话隔离。
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## 3. 架构图
|
|
44
|
+
|
|
45
|
+
```mermaid
|
|
46
|
+
flowchart TD
|
|
47
|
+
subgraph 常驻层[常驻子代理（continuable，持久上下文）]
|
|
48
|
+
R1[R-1 方向A] ; R2[R-2 方向B] ; R3[R-3 方向C] ; RN[... R-N]
|
|
49
|
+
end
|
|
50
|
+
|
|
51
|
+
subgraph 媒介层[框架 vibe-v4（媒介/沉淀/共识/上下文）]
|
|
52
|
+
BUS[消息总线·邮件箱]
|
|
53
|
+
MTG[会议/辩论]
|
|
54
|
+
TASK[任务板]
|
|
55
|
+
PERSIST[产物沉淀]
|
|
56
|
+
VERIFY[共识验证]
|
|
57
|
+
COMPACT[/compact 监测]
|
|
58
|
+
STATE[State 注册表/锁/恢复]
|
|
59
|
+
end
|
|
60
|
+
|
|
61
|
+
subgraph 共享知识库[VibeMath/Projects/<project>]
|
|
62
|
+
PROJ[Problems/ 原问题]
|
|
63
|
+
SPROJ[Subproblems/ 各常驻子问题]
|
|
64
|
+
PROP[Propos/ 各常驻命题库]
|
|
65
|
+
METH[Methods/ 各常驻方法库]
|
|
66
|
+
PRG[Progress/ 各常驻进展]
|
|
67
|
+
VERF[Verified/ 仅共识后只读]
|
|
68
|
+
SHARED[Shared/ 会议·任务板·决策·辩论]
|
|
69
|
+
end
|
|
70
|
+
|
|
71
|
+
R1 & R2 & R3 & RN <-->|留言/开会/任务| BUS
|
|
72
|
+
BUS -->|唤醒 followup| R1
|
|
73
|
+
BUS -->|唤醒| R2
|
|
74
|
+
MTG -->|议程/结论| SHARED
|
|
75
|
+
R1 & R2 & R3 & RN -->|按价值沉淀| PROP
|
|
76
|
+
R1 & R2 & R3 & RN -->|记录| METH & SPROJ & PRG
|
|
77
|
+
R1 & R2 & R3 & RN -.->|只读他人的库| PRG & PROP & METH & SPROJ
|
|
78
|
+
VERIFY -->|全票真/假| VERF
|
|
79
|
+
VERIFY -.->|未全票→留库附概率| PROP
|
|
80
|
+
COMPACT -->|达66%| R1
|
|
81
|
+
STATE -->|断点重建| R1 & R2 & R3 & RN
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 4. 常驻子代理模型
|
|
87
|
+
|
|
88
|
+
### 4.1 本质
|
|
89
|
+
- 每个常驻 = 一个 DSH **continuable 子代理**：`subagents.startContinuable({ parent: 会话根代理, request, agentOptions, toolFilter })`。
|
|
90
|
+
- **持久上下文**（continuable）：跨多次唤醒记住前文，直到被 `/compact` 压缩。
|
|
91
|
+
- **唤醒** = `subagents.sendMessage(root, <childId>, [textBlock(prompt)], {signal})`（DSH 的 `subagents` 服务没有 `followup` 方法——`followup` 只是 `Agent` 对象的方法；`sendMessage` 才是服务暴露的续做 API。旧代码 `subagents.followup(...)` 在真实运行时抛 `TypeError`，导致每次唤醒都失败、小组整体停摆）；一轮收益 = 该常驻提交一次完整思考（经 `ctx.on('subagent/end')` 回归，`stateOf`=settled 时 `watchSettlement` 每次 dispose 都会重新触发一次 `/end`）。
|
|
92
|
+
- **工具**：`tools.register` 对会话内所有代理可用（处理器按 `exec.agent` 路由），故常驻可直接用 `fs` + `vibe_v4_*` 工具（写自己的库、读他人的库、发消息、提会议、记命题、发起验证）。
|
|
93
|
+
|
|
94
|
+
### 4.2 身份与上下文
|
|
95
|
+
```
|
|
96
|
+
id: r-<n> （n=1..N，可增开/关闭）
|
|
97
|
+
方向: 初始头脑风暴所得方向
|
|
98
|
+
初始上下文 = 常驻章程(§6) + 原问题完整陈述 + 本方向 + "先独立想，产出你的见解/思路/方向"
|
|
99
|
+
每轮上下文 = 常驻章程(精简) + 本人最新成果梗概 + 新到达的消息/会议录/任务认领 + "做一轮：思考→自验→按价值沉淀→交流/表决"
|
|
100
|
+
上下文占比 ≥ compactThreshold(默认66%) → 框架触发 DSH /compact
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
### 4.3 专属产物（持久，按常驻隔离）
|
|
104
|
+
```
|
|
105
|
+
VibeMath/Projects/<project>/
|
|
106
|
+
Progress/<r-id>/progress.md # 本人持续进展（追加式）
|
|
107
|
+
Propos/<r-id>/<p-id>.md # 本人命题
|
|
108
|
+
Methods/<r-id>/<m-id>.md # 本人理论/方法/工具
|
|
109
|
+
Subproblems/<r-id>/<s-id>.md # 本人子问题
|
|
110
|
+
# 常驻只写自己的目录；对其它常驻目录只读
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 5. 框架（vibe-v4 插件）= 媒介，绝不分配任务
|
|
116
|
+
|
|
117
|
+
| 能力 | 机制 | 关键点 |
|
|
118
|
+
|---|---|---|
|
|
119
|
+
| **常驻生命周期** | start 时 brainstorm→spawn N（各带初始方向）；add/remove；resume 重建 | 常驻上下文断点后需 re-spawn 并用其 `progress.md` 重种化 |
|
|
120
|
+
| **消息总线** | `vibe_v4_send_message(to, content)` → 入目标邮件箱 → 若空闲则 `sendMessage` 唤醒 | 常驻间不直接互调，全靠框架 relay（模拟收件箱）；支持 `broadcast(all)` |
|
|
121
|
+
| **会议** | `vibe_v4_meeting(agenda)` → 向全体发会议 prompt → 收齐发言 → 写 `Shared/meetings/<id>.md` → 广播结论 | 会议用于分工/方向/任务分配/提出验证/表决"是否已解决" |
|
|
122
|
+
| **任务板** | 常驻在会议/留言提议任务 → 框架记 `Shared/taskboard.md`；认领后被唤醒 | 框架只搬运，不决定谁做什么 |
|
|
123
|
+
| **产物沉淀** | `vibe_v4_publish_progress` / `record_proposition` / `record_method` / `record_subproblem` | **必填**：价值程度 / 动机用途计划 / 自身概率估计（框架校验，缺则提示） |
|
|
124
|
+
| **共识验证** | `vibe_v4_propose_verify(targetId)` → 常驻们同意后开辩论 | 独立初评→公开辩论→**全票真/假才入 Verified/**；否则留库附概率 |
|
|
125
|
+
| **停止条件** | 会议中全体常驻对"原问题已解决"投票，**全部同意** → 停止唤醒 | 人工 `abort` 始终可用 |
|
|
126
|
+
| **上下文/compact** | 监测每常驻上下文占比 ≥ 阈值 → 触发 DSH `/compact` | `compactThreshold` 默认 66，可调 |
|
|
127
|
+
| **人工/助手干预** | `vibe_v4_message(all, content)` / `vibe_v4_meeting` / `vibe_v4_add_member` / `remove_member` / `vibe_v4_message(to, content)`；`/v4` slash | 不改变"之后由它们自组织" |
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## 6. 常驻章程（写入每个常驻初始上下文）
|
|
132
|
+
|
|
133
|
+
```
|
|
134
|
+
你是常驻研究者 R-<k>（共 N 位），与其它常驻协作解决问题：<原问题完整陈述>。
|
|
135
|
+
你的方向/起点：<初始头脑风暴方向>。
|
|
136
|
+
|
|
137
|
+
【信任规则】只有 Verified/（及 Propos 中"已验证·真/假"）绝对可信；你自己未验证的、他人的未验证产物都是经验性参考，不能当作已成立事实引用。
|
|
138
|
+
|
|
139
|
+
【每轮默认动作】
|
|
140
|
+
① 思考本方向下一步（或回应他人/会议）；
|
|
141
|
+
② 自我验证刚得到的结论，并"按价值"决定是否记入自己的 progress/命题/方法/子问题库；
|
|
142
|
+
凡入册必须写明：价值程度、动机用途计划、你对该对象为真的概率估计；
|
|
143
|
+
③ 决定是否要给某常驻留言 / 提议开会 / 提议对某对象开展共识验证辩论；
|
|
144
|
+
④ 会议或辩论中发言，对任务分工/方向/停止条件表态。
|
|
145
|
+
|
|
146
|
+
【验证规则】任何对象要进 Verified/ 必须全体常驻一致判真或判假；否则留在库中并附概率。你只信"全票同意"的。
|
|
147
|
+
|
|
148
|
+
【任务自主】下一轮你自己做什么、与他人怎么分工，由你们开会/留言决定——没有外部派活。
|
|
149
|
+
|
|
150
|
+
【可见性】你可以读所有常驻的 progress/命题/方法/子问题库；只写自己的库。
|
|
151
|
+
|
|
152
|
+
【停止】当且仅当全体一致认为原问题已解决，才会停止调度。
|
|
153
|
+
|
|
154
|
+
【干预】助手/人可能给你留言、提要求、要求开会、或增开/关闭常驻——服从并响应。
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
> 每轮回调 prompt = 常驻章程（可精简）+ 本人最新成果梗概 + 新到达输入 + "做一轮，并在结束时给出你对『原问题是否已解决』的最新看法"。
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
## 7. 数据模型 / Schema（软规范：头部锚点行 + 正文自由叙述；解析器同 v3 风格）
|
|
162
|
+
|
|
163
|
+
**常驻注册表 `State/residents.json`**
|
|
164
|
+
```json
|
|
165
|
+
{ "r-1": { "rId":"r-1", "childId":"...", "direction":"...", "status":"brainstorm|active|idle|compact",
|
|
166
|
+
"createdAt":..., "lastActiveAt":..., "contextPct":0.3 } }
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
**邮件箱 `State/mailboxes.json`**
|
|
170
|
+
```json
|
|
171
|
+
{ "r-1": [ { "from":"r-2", "at":..., "content":"...", "delivered":false } ] }
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
**任务板 `Shared/taskboard.md`**
|
|
175
|
+
```
|
|
176
|
+
- [open|claimed|done] <任务简述> (提议人: r-2, 认领人: r-3, 涉及方向: d3, 来源: 会议<id>/留言)
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
**命题卡 `Propos/<r-id>/<p-id>.md`**
|
|
180
|
+
```
|
|
181
|
+
- ID: p-xxx
|
|
182
|
+
- 类型: 命题
|
|
183
|
+
- 状态: 未定论|已验证·真|已验证·假
|
|
184
|
+
- 概率: 0.62
|
|
185
|
+
- 价值程度: 0.7
|
|
186
|
+
- 动机用途计划: ...（为何有价值/拟如何用于解决问题/如何回填主线）
|
|
187
|
+
- 依赖: []
|
|
188
|
+
## 陈述 （完整）
|
|
189
|
+
## 证明尝试 （### 证明 N｜…｜概率X｜状态Y）
|
|
190
|
+
## 证伪尝试 （### 证伪 N｜…｜概率X｜状态Y）
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
**方法卡 `Methods/<r-id>/<m-id>.md`**
|
|
194
|
+
```
|
|
195
|
+
- ID: m-xxx
|
|
196
|
+
- 类型: 理论体系|框架|工具|方法|思想|范式|技巧
|
|
197
|
+
- 状态: 经验|应用验证|含已验证断言
|
|
198
|
+
- 可信断言: [](只允许进过 Verified/ 的 id)
|
|
199
|
+
- 价值程度: 0.6
|
|
200
|
+
- 动机用途计划: ...
|
|
201
|
+
## 核心内容
|
|
202
|
+
## 定义与记号
|
|
203
|
+
## 应用记录
|
|
204
|
+
## 改进历史
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
**子问题卡 `Subproblems/<r-id>/<s-id>.md`**
|
|
208
|
+
```
|
|
209
|
+
- ID: s-xxx
|
|
210
|
+
- 状态: 未定论|求解中|已解决
|
|
211
|
+
- 价值程度: 0.5
|
|
212
|
+
- 动机用途计划: ...（如何回填主线 / 独立求解后如何反哺）
|
|
213
|
+
- 依赖: []
|
|
214
|
+
## 陈述 （完整）
|
|
215
|
+
## 进度
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
**共享写锁**：仅对 `Shared/*`、`Problems/<id>.md`、`Verified/*` 使用 `vibe_v4_claim_write/release_write`（进程级 fileOwner，同 v3）；各常驻目录内天然无冲突。
|
|
219
|
+
|
|
220
|
+
---
|
|
221
|
+
|
|
222
|
+
## 8. 共识验证（Verification）算法
|
|
223
|
+
|
|
224
|
+
```
|
|
225
|
+
1. 提议：常驻们经留言/会议达成"值得验证"的共识，对 target(命题/证明/方法/理论) 开启验证。
|
|
226
|
+
2. 框架建 Shared/debates/<target>.md；【独立初评】向每个常驻各发一次（不看他人）：
|
|
227
|
+
给 verdict(真/假/不确定) + 理由 + 概率。
|
|
228
|
+
3. 若已全票真 → 写入 Verified/命题(或方法→可信断言)/<id>.md，并回写来源库项状态=已验证·真。
|
|
229
|
+
若已全票假 → 写入 Verified/命题/<id>.md（结论=假），来源库项状态=已验证·假。
|
|
230
|
+
（问题类 target 同理：Verified/问题/<id>.md）
|
|
231
|
+
4. 否则【公开辩论】：把初评意见+理由写入辩论录，广播全体；各常驻看他人意见后重评
|
|
232
|
+
（可引用/反驳/修改），直至：全票同向，或不再出现理性新分歧。
|
|
233
|
+
（实现要点：进入 debate 轮时框架把上一轮投票快照进 `vs.history` 并**清空 `vs.verdicts`**，让每个常驻
|
|
234
|
+
都被重新询问一次——若不清理，`allVoted` 恒真，debate 轮会静默烧掉且**无人被重新询问**。）
|
|
235
|
+
5. 未全票 → 保留在来源库，概率取各常驻最后估计的平均，附"未达成全体一致"的辩论记录。
|
|
236
|
+
【要点】不设 v3 的 forced/flat/近共识自动收口——必须真实全体一致，防止强分歧被强行判真。
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
---
|
|
240
|
+
|
|
241
|
+
## 9. 并发 / 活性 / 隔离 / 恢复
|
|
242
|
+
|
|
243
|
+
- **活性（防僵死）**：每次 `subagent/end` 后，框架优先：
|
|
244
|
+
① 任何邮件箱非空 → 唤醒非忙收件人；
|
|
245
|
+
② 否则任务板有 open → 唤醒提议人/认领人；
|
|
246
|
+
③ 否则存在待验证提议 → 开会；
|
|
247
|
+
④ 否则"心跳"：唤醒最久未活跃者并给它开会，让它表态下一步（`activityTimeoutMs` 可调）。
|
|
248
|
+
- **并行**：同一时刻可唤醒多个空闲常驻（受 `maxParallel` 上限，默认 3，框架侧并发闸，非"指派"）。
|
|
249
|
+
- **隔离**（同 v3）：`sessions`(根代理→Session)、`childOwner`(子代理→会话路由 subagent/end)、`fileOwner`(进程级写锁跨会话)、`projectLock`(每会话)、`processEpoch`(进程级，防两会话互判陈旧)。
|
|
250
|
+
- **断点续跑**：`vibe_v4_resume` 用 `State/residents.json` + 各常驻 `progress.md` 重建常驻（re-spawn + 重种化上下文），恢复邮件箱/任务板/会议录；`processEpoch` 判断是否清空中在途轮。
|
|
251
|
+
|
|
252
|
+
---
|
|
253
|
+
|
|
254
|
+
## 10. 与 DSH 机制映射（实现时确认）
|
|
255
|
+
|
|
256
|
+
| DSH 能力 | 在本架构中的用途 |
|
|
257
|
+
|---|---|
|
|
258
|
+
| `subagents.startContinuable({parent, request, agentOptions, toolFilter})` | 产生常驻（continuable，持久上下文） |
|
|
259
|
+
| `subagents.sendMessage(root, childId, blocks, {signal})` | 唤醒常驻做一轮 / 投递一条留言 / 开会向某常驻收集发言（**服务暴露的续做 API**；旧 `subagents.followup` 不存在） |
|
|
260
|
+
| `ctx.on('subagent/end')` | 一常驻完成一轮（收其回复，续驱动） |
|
|
261
|
+
| `subagents.interrupt / list` | 中断 / 枚举常驻 |
|
|
262
|
+
| `tools.register`（会话内所有代理可用，`exec.agent` 路由） | 常驻可直接调用 `vibe_v4_*` 与 `fs` |
|
|
263
|
+
| `commands.register` | `/v4` slash 控制命令 |
|
|
264
|
+
| `contextPct` + DSH `/compact` | 上下文占比达 66% 自动压缩（精确触发点实现时确认） |
|
|
265
|
+
| `claimWrite/releaseWrite` + 项目锁（复用 v3 模式） | 共享文件写锁 + 会话项目锁 |
|
|
266
|
+
|
|
267
|
+
---
|
|
268
|
+
|
|
269
|
+
## 11. 实现阶段（只策划，不在此文档内写代码）
|
|
270
|
+
|
|
271
|
+
- **P0 脚手架**：`vibe-math-v4/`（`agent.cordis.yml`、`preset.yml`、`vibe-math-v4.js`）；`installer.js` 增加 v4 安装/能力自检；`package.json files` 增加 v4；README 增 V4 小节。
|
|
272
|
+
- **P1 常驻生命周期**：brainstorm→spawn N(各带方向)→track→wake→(`subagent/end`)→compact→resume；brainstormPhase 只产出初始方向并持久。
|
|
273
|
+
- **P2 消息总线 + 邮件箱 + 跨读**：`send_message`/mailbox/唤醒；他人库只读工具；写锁。
|
|
274
|
+
- **P3 会议 + 任务板 + 决策**：`meeting`/taskboard/decisions；分工涌现。
|
|
275
|
+
- **P4 产物沉淀**：`record_proposition/method/subproblem` + `publish_progress`（价值/动机/概率必填校验）。
|
|
276
|
+
- **P5 共识验证**：`propose_verify` + 独立初评 + 公开辩论 + 全票闭环；`Verified/` 生成与来源库回写。
|
|
277
|
+
- **P6 停止 + 干预 + 恢复**：stop-vote(全票 solved)/abort/pause/resume；`add_member/remove_member/message(all)`。
|
|
278
|
+
- **P7 测试**：`selfdrive-v4.mjs`（常驻互相留言/开会/沉淀/共识验证/compact/停止 的全流程记录器）；E2E 断言：消息送达、会议记录、仅全票入 Verified、未全票留库附概率、compact 触发、仅全体一致才 stop、resume。
|
|
279
|
+
|
|
280
|
+
---
|
|
281
|
+
|
|
282
|
+
## 12. 边界 / 失败 / 风险
|
|
283
|
+
|
|
284
|
+
| 场景 | 处理 |
|
|
285
|
+
|---|---|
|
|
286
|
+
| 全员等待、无人行动（僵死） | §9 活性机制（mailbox→taskboard→verify提案→心跳会议）兜底 |
|
|
287
|
+
| 共识永达不成 | 对象留库附概率，不阻塞其它工作；不强行裁决 |
|
|
288
|
+
| 上下文 blow-up | compact 阈值 + 每轮只带"梗概+新输入"；会议/辩论录按需截断 |
|
|
289
|
+
| 共享文件并发 | 写锁；各常驻专属文件无锁 |
|
|
290
|
+
| 常驻崩溃/退出 | `subagent/end` 异常置 `idle`；`resume` 重建 |
|
|
291
|
+
| 常驻误用工具 | 默认继承会话工具；可用 `toolFilter` 收权为 `fs` + `vibe_v4_*` + 只读库工具 |
|
|
292
|
+
| 多项目并发 | 各项目 `State/`+`Shared/` 隔离；`projectLock` 防两会话跑同一项目 |
|
|
293
|
+
|
|
294
|
+
---
|
|
295
|
+
|
|
296
|
+
## 13. 参数默认值
|
|
297
|
+
|
|
298
|
+
| 参数 | 建议默认 | 说明 |
|
|
299
|
+
|---|---|---|
|
|
300
|
+
| `residentCount` | 4 | 常驻数（可 `add_member` 增减） |
|
|
301
|
+
| `compactThreshold` | 66 | 常驻上下文占比达此值触发 `/compact` |
|
|
302
|
+
| `maxParallel` | 3 | 同时唤醒的常驻上限（框架侧并发闸，非指派） |
|
|
303
|
+
| `activityTimeoutMs` | 120000 | 无新消息/任务/提案时的心跳间隔 |
|
|
304
|
+
| `verdictQuorum` | `all` | 固定"全部常驻一致"（哲学要求，不建议放宽） |
|
|
305
|
+
| `perResidentLibs` | 每常驻独立目录 | 若"共享库+署名"会重新引入写锁竞争，不推荐 |
|
|
306
|
+
|
|
307
|
+
---
|
|
308
|
+
|
|
309
|
+
## 14. 成功标准（验收）
|
|
310
|
+
|
|
311
|
+
1. 起始产生 N 个常驻，先各自头脑风暴、产出初始见解/方向。
|
|
312
|
+
2. 此后所有任务安排（探索/尝试/分工/验证）由常驻们互相留言/开会决定，无中央调度器。
|
|
313
|
+
3. 每个常驻有专属、持久的 progress/命题/方法/子问题库，可互相阅读。
|
|
314
|
+
4. 记录产物必带 价值程度 / 动机用途计划 / 自身概率估计。
|
|
315
|
+
5. 验证由常驻自行商议发起；仅全体一致（真 或 假）才入 `Verified/`；否则留库附概率。
|
|
316
|
+
6. 常驻上下文达 66%（可调）自动 `/compact`。
|
|
317
|
+
7. 允许助手/人工中途干预（留言/提要求/开会/增开关闭常驻）。
|
|
318
|
+
8. 仅当全体常驻一致认为原问题已解决才停止调度。
|
|
319
|
+
9. 支持断点续跑、多会话/多项目隔离、共享文件写锁 + 常驻专属文件隔离。
|
|
320
|
+
|
|
321
|
+
---
|
|
322
|
+
|
|
323
|
+
## 15. 待确认项（实现前与用户敲定；已给建议默认）
|
|
324
|
+
|
|
325
|
+
- 常驻数默认 4，是否直接给用户一个 `residentCount` 参数。
|
|
326
|
+
- 是否允许"只读他人库但需授权"（哲学已允许互相阅读，默认全读）。
|
|
327
|
+
- `verdictQuorum` 是否始终为 `all`（哲学强调一致，默认不改）。
|
|
328
|
+
- `perResidentLibs`（每常驻独立目录 vs 共享库+署名）——默认独立。
|
|
329
|
+
- DSH `/compact` 的精确触发 API（实现 P1 时确认）。
|
|
330
|
+
|
|
331
|
+
---
|
|
332
|
+
|
|
333
|
+
## 16. 实现现状备注（P5/P6 已落地，v1.3.x）
|
|
334
|
+
|
|
335
|
+
**任务板认领（P5）**：`vibe_v4_propose_task / claim_task / task_done / list_tasks`。常驻可在回复或会议中提议/认领任务；认领后框架**唤醒认领者**带任务工作；任务板落盘 `Shared/taskboard.md` + `State/taskboard.json`；会议结束落任务板/触发验证目标。
|
|
336
|
+
|
|
337
|
+
**上下文 / /compact（P5）**：DSH 打包未暴露"子代理上下文占比 + `/compact`" RPC，故实现**等效真实压缩**——常驻用 `vibe_v4_report_context {pct}` 上报占比；达 `compactThreshold`(66) 或 `compactAfterRounds` 轮数时，框架在下次唤醒前注入"[CONTEXT COMPACT — 浓缩自述]"指令，常驻把工作状态浓缩为一段自述并在回复里带 `contextPct`(低)、`compacted:true`；框架记录**浓缩种子**为后续上下文并复位 `roundsSinceCompact/needCompact`。`compactThreshold/compactAfterRounds/meetingKeepEvery` 均可调。
|
|
338
|
+
|
|
339
|
+
**会议主动触发（P6）**：
|
|
340
|
+
- 常驻 normal 回复里 `propose_meeting` 自触发会议；助手亦可 `vibe_v4_meeting`。
|
|
341
|
+
- **自动同步会议**：每积累 `meetingKeepEvery`(默认 5) 个新产物，框架自动发起"分工/进展/是否需要验证"同步会议。
|
|
342
|
+
- 会议输入可含 `propose_task/claim_task/propose_verify/voteSolved`，结束统一落任务板、触发验证、记停止表决；仍"全体一致 voteSolved=true 才停止"。
|
|
343
|
+
|
|
344
|
+
---
|
|
345
|
+
|
|
346
|
+
## 17. 深度审计修复（v1.3.2，自驱动 20/20）
|
|
347
|
+
|
|
348
|
+
一次对 v4 的全面审计发现并修复了以下真实缺陷（`vibe-math-v4.js`）：
|
|
349
|
+
|
|
350
|
+
| 缺陷 | 说明 | 修复 |
|
|
351
|
+
|---|---|---|
|
|
352
|
+
| **上下文压缩按占比失效** | `contextPct` 被 `cl()` 压成 `[0,1]`，与 `compactThreshold`(66 百分比)比较变成 `1.0>=66` 恒假，导致"达到占比自动 `/compact`"从不触发；压缩后复位也被同样钳死。 | `contextPct` 按 **0–100 百分比**保存（新增 `clPct`），比较与复位随之修正。 |
|
|
353
|
+
| **常驻工具按全局槽路由** | 所有常驻工具用共享的 `currentResident`（一个可变全局），并发下（尤其 brainstorm 阶段 N 个常驻同时在途）所有产物/留言都归到"最后一个被唤醒者"，破坏每常驻独立库。 | 工具 handler 接收 `exec.agent`，按 `childId === agent.id` 解析"调用者常驻"（`residentIdOf`）；未知调用者再回落 `currentResident`。 |
|
|
354
|
+
| **`vibe_v4_read_progress` 失效** | handler 返回 `text: s.readProgress(...)`（一个未 await 的 Promise），`JSON.stringify` 后变 `{}`，常驻读不到他人进展。 | 改为 `await` 并返回 `{ok,text:<string>}`。 |
|
|
355
|
+
| **跨进程断点不重建常驻** | `resume()` 只在 `childId` 为空时 re-spawn；崩溃/重启后持久化的 `childId` 是陈旧值，导致不重建且对死链 followup；且 resume 从不 `scheduleNext()`。 | `session.json` 持久化 `processEpoch`；`resume()` 检测跨进程（epoch 不同）→ 清空陈旧 `childId` 强制 re-spawn，且末尾 `scheduleNext()` 重启调度。 |
|
|
356
|
+
| **`message(all)` 广播是空壳** | `to==='all'` 只返回一句 `broadcast: ...` 但什么都不投递。 | 新增 `broadcast()`：对每个常驻 `postMessage`（空闲唤醒/忙则入信箱），返回"投递到 N 个常驻"。 |
|
|
357
|
+
| **`addMember` 出现 id 碰撞** | `newResident` 用 `'r-'+(residents.size+1)`；移除某常驻后再增开会用与现存常驻重复的 id。 | 改用会话级单调 `residentSeq`（`start()` 时清零），增开永不复用旧 id。 |
|
|
358
|
+
|
|
359
|
+
> **未改（保留为已知边界）**：`maxParallel`/`activityTimeoutMs` 目前为声明参数但未实际限流/门控（保持"常驻持续推进"的收敛行为，未做心跳超时门控以免阻塞自组织推进）；`claim_write`/`release_write` 仍为占位（常驻专属目录内天然无写冲突，共享文件由框架独占写）；真实 DSH `/compact` API 见 §19（**2026 已修**：原 `agents.get` 查询为死代码，改为 `subagent/start` 捕获引用）。
|
|
360
|
+
|
|
361
|
+
---
|
|
362
|
+
|
|
363
|
+
## 18. 第二轮深度审计修复（v1.3.3，自驱动 21/21 + 独立修复测试 8/8）
|
|
364
|
+
|
|
365
|
+
针对 v1.3.2 之后仍存在的缺陷做第二轮审计并修复：
|
|
366
|
+
|
|
367
|
+
| 缺陷 | 说明 | 修复 |
|
|
368
|
+
|---|---|---|
|
|
369
|
+
| **非全票验证不写回平均概率** | `finalizeVerify` 算出 `avg` 只写进辩论录，源卡 `- 概率:` 保持原值，未兑现设计 §8"留库附概率"。 | 新增 `findSourceRel`/`rewriteSourceProb`，非全票时把 `avg` 写回源卡 `- 概率:`（状态仍 `未定论`）。 |
|
|
370
|
+
| **方法型验证被误标为"命题"** | `writeVerifiedCard` 把方法目标写进 `Verified/命题/` 且类型=命题。 | 按 `targetType` 标 `类型: 方法`（子问题→问题，方法→方法，其余→命题），来源卡标 `已验证·真/假`。 |
|
|
371
|
+
| **同进程 abort→resume 不重建常驻** | `processEpoch` 进程级，同进程 abort（interrupt 杀掉常驻）后 resume 判非跨进程→保留死 childId；且 `phase=idle && !running` 时 resume 直接拒绝。 | `initAbort` 清空 `childId` 并 `saveAll()`；`resume` 守卫改为 `phase==='idle' && !running && residents.size===0`（有常驻即可 重建）。 |
|
|
372
|
+
| **abort→resume 重种化不彻底（牵连修复）** | 同进程 abort 后 `phase='idle'`、childId 已清空，但旧居民 `status='active'` 且旧 `insight` 仍在；resume 走"非跨进程"分支不清状态，直接 re-spawn 后落入 `phase='active'`——重种化居民在第一轮 brainstorm 期间就被当作 active 处理（brainstorm 汇总不写）；且被 interrupt 的**旧**居民迟到的 `subagent/end`（同名 rId）会删除**新**居民的 busy 标记。 | `resume()` 用 `needRespawn`（任一 childId 为空）统一判定：**任何 re-spawn（跨进程或同进程 abort）** 都清空 busy/wakeKind/currentResident/pendingMeeting/pendingVerify/verifyState/meetingState，并把居民 `status='brainstorm'`、`insight=''`、`phase='brainstorm'`——让重种化居民真正重新头脑风暴、汇总正常写出、旧居民的迟到 end 不会污染新居民的 busy。 |
|
|
373
|
+
| **自动同步会议计数不一致** | `bumpArtifacts` 只在记录方法/子问题时调用，`recordProposition`/`publish_progress` 不计；`artifactCount` 未持久化。 | `recordProposition` 也 `bumpArtifacts()`；`artifactCount` 持久化到 `session.json` 并在 `start()` 时清零。 |
|
|
374
|
+
| **唤醒信号硬编码 60s** | `spawnResident`/`wakeResident` 用 `makeSignal(60000)`，比 `activityTimeoutMs`(120s) 短。 | 改用 `makeSignal(params.activityTimeoutMs||60000)`。 |
|
|
375
|
+
| **`verdictMaxRounds`/`meetingKeepEvery` 不可调/不展示** | `verdictMaxRounds` 不在 `vibe_v4_set` schema；两者都不在 `status()` 参数串。 | `vibe_v4_set` 增加 `verdictMaxRounds`；`status()` 参数串补 `meetingKeepEvery` 与 `verdictMaxRounds`。 |
|
|
376
|
+
|
|
377
|
+
> 测试：`selfdrive-v4.mjs` 21/21（新增 B1 参数可见性断言）；新增 `e2e-v4-fixes.test.mjs` 8/8（每项修复用独立 mock 宿主驱动：A1 非全票写回、A2 方法标 `类型: 方法`、A3 同进程 abort→resume 重建、B2 记录命题自动开会）。
|
|
378
|
+
|
|
379
|
+
> **已知边界（未改）**：`maxParallel`/`activityTimeoutMs` 仍未实际限流/心跳门控（避免破坏"持续推进→收敛"）；`claim_write`/`release_write` 仍未落地为真锁；真实 DSH `/compact` API 已接通（见 §19，2026 修复：改为 `subagent/start` 捕获 Agent 引用）。
|
|
380
|
+
|
|
381
|
+
---
|
|
382
|
+
|
|
383
|
+
## 19. 边界 A 落地 + 真实 `/compact`（v1.3.5）
|
|
384
|
+
|
|
385
|
+
### 边界 A：事件驱动 + `activityTimeoutMs` 心跳门控 + `maxParallel` 限流
|
|
386
|
+
此前 `scheduleNext()` **无条件**唤醒"最久没动的人"，导致"只要没达到全体一致 solved 就永远烧 token 推进"。现改为贴合哲学"框架绝不指派/促成"的做法：
|
|
387
|
+
|
|
388
|
+
- **事件驱动为主**：有信（邮箱）、任务板 open、验证提案、会议请求 → 才唤醒对应常驻（不变）。
|
|
389
|
+
- **心跳门控**：`scheduleNext` 只在"某常驻空闲时间 ≥ `activityTimeoutMs`"时，才唤醒"最久没动的人"，并给它 **CHECKPOINT 提示词**：*"说明你下一步做什么；若已无产出/认为接近解决 → 提议开会/验证 或 声明 solved。"* 这样既防僵死，又施加**收敛/停止**压力，而非无限推进。
|
|
390
|
+
- **`maxParallel` 限流**：`scheduleNext` 唤醒前检查 `busy.size < maxParallel`，超限则改为 `armHeartbeat()` 等待（brainstorm 阶段的"各自独立想"仍一次全开，常态/会议/验证轮受控）。
|
|
391
|
+
- 新增 `heartbeatTimer` 心跳定时器：`scheduleNext` 无事可做且无人空闲到阈值时，用 `activityTimeoutMs` 定时重查；每次唤醒/开会/验证/start/pause/abort 都会 `clearHeartbeat()` 避免僵尸定时器。
|
|
392
|
+
|
|
393
|
+
> 行为变化：真实运行里若常驻都在推进（每轮 < `activityTimeoutMs`），心跳基本不触发；只有真正"无事可做"才触发一次 CHECKPOINT，推动收敛。测试中把 `activityTimeoutMs` 设小（如 40ms）以驱动自组织收敛。
|
|
394
|
+
|
|
395
|
+
### 真实 DSH `/compact`
|
|
396
|
+
找到了 DSH 真实压缩服务：**`ctx.compaction`**（`@deepseek-ai/dsh-compaction` 的 `CompactionEngine`，`agent.cordis.yml` 已加载 compaction-basic）。v4 现在对每个常驻做**真实压缩**：
|
|
397
|
+
|
|
398
|
+
- 在 `subagent/start` 时用 `ctx.agents.get(info.id)` 捕获该常驻**当时仍然注册**的 Agent 引用，存进 `liveAgents`（`childId → WeakRef<Agent>`）；`onResidentEnd`（常驻空闲）里取回它，再调 `ctx.compaction.compactIfNeeded(agent, 'pressure', signal)`。
|
|
399
|
+
- `compactIfNeeded` 用 `ctx.tokenMeter` **真实测量**该常驻会话 token 量，超过其模型上下文窗口阈值时把旧历史折叠成总结节点——真正的 `/compact` 效果（而非仅"注入浓缩指令+记账复位"）。
|
|
400
|
+
- 成功后复位 `roundsSinceCompact/needCompact` 并记 `logActivity`。**若宿主未提供 `ctx.compaction`（或模型未配 `contextWindow`）则静默回退**到现有"自述指令"等效层。
|
|
401
|
+
|
|
402
|
+
> **⚠️ 2026 修复（原实现是死代码）**：本节原先写的是在 `onResidentEnd` 里直接 `ctx.agents.get(r.childId)`。实测证明**那条路径永远拿不到 Agent**，真实压缩从未执行：
|
|
403
|
+
>
|
|
404
|
+
> ```
|
|
405
|
+
> dsh-subagent/lib/index.js:1231 await activation.handle.dispose()
|
|
406
|
+
> dsh-agent/lib/index.js:508 this.store.delete(entry.id) ← 常驻离开注册表
|
|
407
|
+
> dsh-subagent/lib/index.js:1241 activation.observer.settle(...) ← 此时才 emit subagent/end
|
|
408
|
+
> ```
|
|
409
|
+
>
|
|
410
|
+
> `subagent/end` 触发时子代理**已被移出注册表**，`agents.get()` 必然 `undefined`，函数在 `if(!agent || !agent.session) return` 处直接返回。**修法**即上面的"start 时捕获引用"；引用在 end 处理完成后由 `forgetAgent` 释放，用 `WeakRef` 保证即使漏掉释放也只是延迟回收、不会长期钉住 Agent。
|
|
411
|
+
> 可执行证明：`e2e-f1-agent-detach.test.mjs`（驱动真实 `AgentRegistry` 复现时序）；回归测试：`audit-f1-compact-fix.test.mjs`（mock 忠实复现"先 teardown 再 emit"，断言 `compactIfNeeded` **确实被调用**）。
|
|
412
|
+
> `claim_write`/`release_write` 仍保留为占位（常驻专属目录无写冲突）。
|
|
413
|
+
|
|
414
|
+
---
|
|
415
|
+
|
|
416
|
+
## 20. 哲学回归：清晰提示词 + 真实交流群 + 直接写文件（v1.3.7）
|
|
417
|
+
|
|
418
|
+
按用户哲学（"以通过交流群自组织各自任务/自组织推动项目为准，以模拟现实真实合作交流推动任务为准"）重做常驻的认知与协作机制：
|
|
419
|
+
|
|
420
|
+
### 1. 提示词/上下文足够清晰完整
|
|
421
|
+
新增共享的 `contextBrief(r, level)`，注入到每个常驻的每轮提示里，统一说明：
|
|
422
|
+
- **背景/使命**：你是常驻研究团队的一员，正在协作解决 <问题>；像真实学术小组一样，**没有中央调度/外部派活**，一切由你们讨论决定。
|
|
423
|
+
- **工作模式/会发生什么**：每人有持久全组可见的专属资料库；自由发消息/开会；会议把每人的实际发言（input）转给其他人；独立研究并**直接用 fs 写自己的文件**；"已确立"须全组一致；只有全组一致认为已解决才停止。
|
|
424
|
+
- **你负责的文件与格式**：`residentLibraries()` 列出 Progress/<你>/、Propos/<你>/、Methods/<你>/、Subproblems/<你>/ 及每个文件的确切字段格式（如 `- ID:`、`- 概率:`、`- 价值程度:`、`- 动机用途计划:`、`## 陈述` 等）；强调**只写自己、可读任何人的**并应主动读别人的库对齐事实。
|
|
425
|
+
- **可用工具及其功能**：`toolList()` 逐个说明 `vibe_v4_*` 各工具做什么，及 fs（读取任意文件/写自己的文件）。
|
|
426
|
+
- **规则**：仅 Verified/ 算确立、验证须全组一致、优先级/分工由团队讨论决定、退出只输出一个 JSON 对象。
|
|
427
|
+
|
|
428
|
+
### 2. 交流群：会话内容互相转发（真正商量）
|
|
429
|
+
- **会议=真实讨论**：`meetingPrompt` 把"其他常驻已发的 input（框架已转发给你）"注入，让每个人看到别人说了什么、能补充/反驳/表决，而不是各说各话。
|
|
430
|
+
- **常驻发言=群聊转发**：常驻在日常轮里给 `input`（想对团队说的话）时，框架 `relayToGroup` 把该发言**转发到其它常驻的邮箱**（下次唤醒时被看到），让团队的交流像一场群聊。
|
|
431
|
+
- 任务分工、优先级由这种讨论涌现；stop-vote 也发生在会议上（全票 solved 才停）。
|
|
432
|
+
|
|
433
|
+
### 3. 直接操作文件（不必用 vibemath 命令）
|
|
434
|
+
提示词明确："把进展/结论**直接用 fs 写进你自己的文件**（按上面的格式供全组阅读）"；`vibe_v4_publish_progress/record_*` 只是便捷记录器、**不是必需**。常驻自组织写自己的 md，框架据文件读取/索引/验证。
|
|
435
|
+
|
|
436
|
+
### 4. 自组织优先，非固定模式约束
|
|
437
|
+
删除"typical actions"式枚举，改为"你自己决定做什么；优先级/分工由团队讨论决定"。仍保留 JSON 回复里 `propose_verify/propose_meeting/claim_task/voteSolved/solved` 作为框架可执行的**控制通道**，但讨论内容走 `input`/会议转发。
|
|
438
|
+
|
|
439
|
+
> 测试：`selfdrive-v4.mjs` 21/21；`e2e-v4-fixes.test.mjs` 17/17（T5 提示词完整性、T6 群聊转发、T7 背景只讲一次）。
|
|
440
|
+
|
|
441
|
+
---
|
|
442
|
+
|
|
443
|
+
## 21. 基于真实测试的诊断修复（v1.3.8）
|
|
444
|
+
|
|
445
|
+
对一次真实 4 常驻 run（HRT 猜想）的会话记录做了全面诊断，修复以下违反哲学的问题：
|
|
446
|
+
|
|
447
|
+
### 1. 共识验证真正做到"全体一致"
|
|
448
|
+
此前 `finalizeVerify` 只看"投过票的人是否一致"——实测 `p-r1-04` 只有 r-1/r-3 两人投票（r-2/r-4 未投）却被判"全体一致为真"（2/4）。现改为：**只有当全体在册常驻都投了票（`verdicts` 覆盖全部 resident）才可能判"一致"**；否则进入辩论，或超轮后**保留为未定论（不回写 Verified）**。若某常驻一直忙/未投，则该对象**不会**被记为 Verified·真/假。
|
|
449
|
+
|
|
450
|
+
### 2. 会议必须全体发言
|
|
451
|
+
`continueMeetingRound` 改为按"是否已发言（`inputs` 覆盖全部 resident）"判定收口，而非按"是否被问过"。**只要还有常驻没发言，会议就继续等它**；`allSolved`（全票 solved→停止）也要求**全员发言且全票 true**。这样分工/停止表决不会被"缺席成员"带偏。
|
|
452
|
+
|
|
453
|
+
### 3. 背景只在第一轮讲一次（不再每轮重复，省上下文）
|
|
454
|
+
`contextBrief`（背景/使命/工作模式/文件与格式/工具/规则）现在**只在 `brainstormPrompt`（首轮）注入完整版一次**；之后的 normal/meeting/verify/CHECKPOINT 只用**极简的当前状态**（researcher id + 轮次 + 团队成员 + 通知 + JSON 回复），**不再重复那段长背景**，显著减少上下文占用。
|
|
455
|
+
|
|
456
|
+
### 4. 验证目标按"提出者"精确定位
|
|
457
|
+
`pendingVerify` 记录 `proposer`，`beginVerify` 存入 `targetOwner`；`findSourceRel` **优先在提出者的库里找**源卡（避免同名 id 跨常驻撞车，例如 r-3 的 `p-004` vs r-1 的 `p-r1-04`）；验证提示里标注"（提出者 <owner>）"让常驻明确在验哪个对象。
|
|
458
|
+
|
|
459
|
+
### 5. 主代理放权（减少"主持人"指挥）
|
|
460
|
+
`agent.cordis.yml` persona 明确：**你的角色是让常驻自组织（hands-off）**。不要注入议程/优先级/分工/验证决定，不要指挥常驻；运行 `start` 后只读 `status/report`、在用户明确要求或团队明显僵死时才 `message`/`meeting`，且只做"促成"，不做"决定"。
|
|
461
|
+
|
|
462
|
+
---
|
|
463
|
+
|
|
464
|
+
## 22. 进一步按哲学打磨（v1.3.9）
|
|
465
|
+
|
|
466
|
+
### 1. 会议议程来源确认（非 bug）
|
|
467
|
+
核查确认：之前担心的"主持人式"会议议程，其实是 **r-1 在它的汇报里 `propose_meeting` 字段给出的**，框架据此启动会议。属**常驻自组织发起会议**，符合哲学，无需改。（仅把 `finalizeMeeting` 的日志措辞从"not all spoke / not unanimous"改为准确的"no unanimous solved vote"。）
|
|
468
|
+
|
|
469
|
+
### 2. 压缩后重申核心规则（治"压缩遗忘规则"）
|
|
470
|
+
常驻的背景/规则只在首轮讲一次；为避免真实 `/compact` 后常驻淡忘规则，现在**每次压缩触发时**（`needCompact`/达阈值）在提示开头**重申一段短的核心规则**（只有 Verified/ 算确立、验证须全组一致、只写自己/只读他人、任务分工团队决定、退出只输出 JSON），其余轮次仍保持极简。
|
|
471
|
+
|
|
472
|
+
### 3. 验证 `verdict` 明确为 0–1 正确概率
|
|
473
|
+
验证提示明确：`verdict` ∈ [0,1]，**1=绝对为真（判真），0=绝对为假（判假），0.5=完全不确定**；"全体常驻一致判真（正确概率 verdict 为 1）或一致判假（正确概率 verdict 为 0）才算数"。框架把 `verdict` 解析为数值（>0.5→判真，<0.5→判假，=0.5→不确定），未全票时**留库附全组平均正确概率**；辩论录/源卡回写统一用该概率。向后兼容旧的 `"TRUE"/"FALSE"` 字符串。
|
|
474
|
+
|
|
475
|
+
### 4. 创建项目不再立即启动（先配置后启动）+ settings 文件 + 项目名
|
|
476
|
+
新增 **`vibe_v4_configure {project?, problem?, params?}`**：**只创建/配置项目（名称、问题、参数），不唤醒任何常驻**；参数持久化到 `State/settings.json`。之后 **`vibe_v4_start {problem?, residentCount?, seedDirections?}`** 才真正启动（若已配置问题可省略）。这样"先设好参数再启动"，不再一创建就着急跑。`/v4 configure` 子命令 + 主代理 persona 的 `Main controls` 已同步（`vibe_v4_set` 也持久化到 settings 文件）；支持设置**项目名**（`configure.project`）。
|
|
477
|
+
|
|
478
|
+
---
|
|
479
|
+
|
|
480
|
+
## 23. verdict 改为纯概率数值 + 全面审计修复（v1.4.0）
|
|
481
|
+
|
|
482
|
+
### 1. `verdict` 是**纯 0–1 概率数值**（不再二分类）
|
|
483
|
+
按用户要求，`verdict` 现在**只是一个 0–1 的正确概率**（程度），框架**不再把它分段映射成 TRUE/FALSE/不确定**。判定规则：
|
|
484
|
+
- **仅当全体常驻一致给 `1`（都认为是真）** → 按"真"写入 Verified/；
|
|
485
|
+
- **仅当全体常驻一致给 `0`（都认为是假）** → 按"假"写入 Verified/；
|
|
486
|
+
- **否则**：只作为**概率数值（一种程度）保留在库中**，附全组平均正确概率（`- 概率:` 写该平均值），**不写成真/假**。
|
|
487
|
+
|
|
488
|
+
相应地：验证提示改为"请给出对该对象为真的正确概率 verdict（一个 0–1 数值，不要给 TRUE/FALSE）"；解析/存储/辩论录/源卡回写全用**数值概率**。向后兼容旧 `"TRUE"/"FALSE"`（解析为 1/0）。**注意**：这也意味着"0.97（很高但非 1）"不再算"真"，会保留为概率 0.97——这是更严格的"绝对一致"口径。
|
|
489
|
+
|
|
490
|
+
### 2. 全面审计修复
|
|
491
|
+
- **`resume` 补上 `loadSettings()`**：否则跨进程 resume 后参数会退回默认（settings 不加载）。
|
|
492
|
+
- **`configure` 现在直接写出问题卡**（`Problems/<id>.md`），使"创建项目"在启动前就完整；`start` 仍会幂等重写。
|
|
493
|
+
- **补上缺失的 `/v4 set` 分支**：此前 usage 列了 `set` 但命令处理器没实现，`/v4 set` 会掉到 usage；现支持 `key=value` 解析并 `setParams`（也持久化到 settings）。
|
|
494
|
+
- **真实 `/compact` 后重申规则**：`realCompact` 成功压缩常驻真实会话后，置 `needCompact=true`，使下一次唤醒**重申核心规则**（与软压缩一致），避免真实压缩后常驻淡忘规则。
|
|
495
|
+
|
|
496
|
+
---
|
|
497
|
+
|
|
498
|
+
## 24. 自主发明理论 / 模型与工具权限 / 压缩重申泄漏修复（v1.4.1）
|
|
499
|
+
|
|
500
|
+
针对一次真实 3 常驻 run（HRT 4 猜想）的深入审计 + 用户三条新增要求：
|
|
501
|
+
|
|
502
|
+
### 1. 初始提示告知"可自主构建新的理论框架/工具"（v1.4.1-①）
|
|
503
|
+
在 `contextBrief(r,'full')`（**仅首轮 brainstorm**，符合"背景只讲一次"）新增一节 **"可自主发明理论/工具（鼓励，但不强迫）"**：
|
|
504
|
+
- 常驻可（但**不强迫**、完全视实际需要）**自主尝试构建新的理论框架或工具**——对某种系统做**抽象化、一般化**，抽离/推广出更一般的结构或理论框架；然后**不断完善**它，在该框架下推得各种**定理、性质、结论**，以利于该框架下问题的解决。
|
|
505
|
+
- 类比：为解决方程问题发明了**群论**、为分析需要建立了**泛函分析**框架——这比单纯解决当前问题更有价值，因为直接得到了一类**更普遍的方法/理论体系**。
|
|
506
|
+
- 若发明了这样的理论/工具，请**阐明它对原问题的用处、价值**；后续可**不断完善、一般化、推广**它，并把这类成果记入 `Methods/<你>/` 库。
|
|
507
|
+
- 这是**鼓励，不是指派**；不写固定模板、不强制"每轮必须发明"。
|
|
508
|
+
|
|
509
|
+
### 2. 补齐"模型继承关系 + 工具权限"参数（v1.4.1-②）
|
|
510
|
+
此前 `provider`/`model` 参数在 `DEFAULT_PARAMS` 里**声明但从未被使用**（死参数），且**没有任何工具权限参数**。现补齐并真正落地：
|
|
511
|
+
- **模型继承**：默认**常驻继承主代理（main assistant）的 provider/model 路由**（DSH `resolveChildAgentOptions` 把请求项并到父路由之上）。通过 `params.provider`/`params.model` 可**覆盖**常驻的 LLM 后端/模型（空=继承）。
|
|
512
|
+
- **工具权限**：新增 `params.toolAllow` / `params.toolDeny`，经 `startContinuable` 的 `toolFilter` 做**作用域 `tools.restrict()`**（被点名的工具从常驻提示里消失且拒绝执行）。默认两者为空 → **常驻继承全部工具**（含 fs 与各 `vibe_v4_*`）；只有显式配置才收权。⚠️ 注意"deny-all 陷阱"：**空 `allow:[]` 会拒绝一切工具**，因此只有当 allow 或 deny 至少有一项时才会发出 filter。
|
|
513
|
+
> **2026 补充**：`tools.restrict()` 对**未注册的工具名直接抛错**（`dsh-tools/lib/index.js:2803`），而 filter 是在建立 continuable 子代理时应用的（`dsh-subagent/lib/index.js:554`），因此**名字写错会让子代理根本建不起来**。v4 只用用户传入的名字、不硬编码网络/脚本名，所以默认不受影响；v2/v3 曾硬编码 `web`/`fetch`/`bash` 而中招（见 `../COMPAT-AUDIT-ROUND2.md` F-2）。
|
|
514
|
+
- **接线**：`spawnResident` 现把 `residentAgentOptions()`（provider/model）与 `residentToolFilter()`（toolAllow/toolDeny）传入 `startContinuable`；`setParams` 做类型归一（整数 / 逗号分隔的数组）；`vibe_v4_set` schema 与 `status()` 参数串也已加这些新参数。
|
|
515
|
+
|
|
516
|
+
### 3. 修复"[核心规则重申]+[CONTEXT COMPACT]"在提示开头重复泄漏（v1.4.1-③）
|
|
517
|
+
这是真实 run 的核心 bug。**根因**（从 `State/residents.json` 证实）：r-1 的 `needCompact:true` 常年不释放、`roundsSinceCompact:10`（>8）——框架在**所有**唤醒（含 meeting/verify）里都根据"`needCompact || contextPct>=阈值 || rounds>=afterRounds`"注入压缩指令；而 meeting/verify 分支收到回复后**提前 return，从不处理 `contextPct/compacted/needCompact`**，于是 `needCompact` 卡死为 true，**每个后续提示都在开头重复"核心规则重申 + CONTEXT COMPACT"**。修复：
|
|
518
|
+
- **只对 normal 研究轮注入完整压缩指令**；meeting/verify/CHECKPOINT 不再注入（它们的回复没有 `compacted/contextPct` 字段，注入了也永远无法被确认 → 无限重复）。
|
|
519
|
+
- **`needCompact`（真实 `/compact` 后）只重申一次短规则并立即清位**（下次任一唤醒即可，清位后不再重复），不再要求再做一次自述。
|
|
520
|
+
- 新增 `postmark(r, parsed)`，在 `onResidentEnd` **所有分支**（含 meeting/verify）开头统一处理 context/compact 记账，杜绝任何情况下的标志泄漏。
|
|
521
|
+
- 这样"规则重申/压缩指令"只出现在**真正发生了压缩的那次唤醒**（软压缩每 `compactAfterRounds` 轮一次、真实 `/compact` 后一次），不再"每轮都重复"。
|
|
522
|
+
|
|
523
|
+
### 4. 会议发言顺序轮换（v1.4.1-④，改善"第一位发言者看不到别人"）
|
|
524
|
+
真实 run 里 r-1 几乎总是在会议里 **第一个发言**（因 `residents` 按插入序 r-1,r-2,r-3，`continueMeetingRound` 取第一个未发言者），于是它本次会议内**看不到** r-2/r-3 的后续发言。现改为**每次会议随机轮换发言顺序**（`meetingState.order`），让不同常驻轮流先发言，讨论更公平、各成员都能看到别人。
|
|
525
|
+
|
|
526
|
+
### 5. 关于 HRT run 收敛与"第7轮后看不到别人消息"的解释（审计结论，非代码 bug）
|
|
527
|
+
- **收敛合理且符合哲学**：三名常驻经约 18/24/29 轮与 6 次会议，**独立且一致**地给出诚实结论——"HRT-4 一般形式很可能为假（0.8+，未确立）+ 完整必要筛 + 统一机制 + 判定方程(♯) + 明确标注未决点（显式反例=外部无全文阻塞、generic 证明=HRT 核心困难未证）"；**无任何 Verified/ 对象**；**无人 declare solved**（每会 `voteSolved` 均非全 true）。框架没有强行收口（`autoDone=false`），run 是被**外部暂停**（`running:false, phase:active`）。这正是哲学要求的诚实：常驻不编造"已解决"，框架也不强加结论。
|
|
528
|
+
- **"第7轮后看不到别人消息/群聊"合理且有两点成因**：① run 后期以**会议为主**（r-1 的后续唤醒几乎都是 Meeting 提示，而非"第 N 轮"研究轮）；② **`[群聊]` 群聊转发在会议主导期被积压**——`scheduleNext` 让会议/验证优先于邮箱投递，会议期间 `[群聊]` 只排队不投递，r-1 邮箱里积压了大量未投递的群聊消息（`State/mailboxes.json` 可见）。会议提示里虽会把"他人已发言"转给常驻，但 r-1 作为最常的先发言者，本次会议内看不到后续发言。这是**自组织在"深度协作+会议主导"下的自然表现**；已通过 §24.4 的发言顺序轮换改善，`[群聊]` 积压会在恢复 normal 阶段被正常投递。
|
|
529
|
+
|
|
530
|
+
> 测试：`selfdrive-v4.mjs` 21/21；`e2e-v4-fixes.test.mjs` 36/36（新增 T10 模型/工具权限接线、T11 默认继承、T12 自主发明理论提示、T13 压缩指令不泄漏进 meetings）；v3 E2E 100/100、v2 regression 14/14、v2 business 24/24、multisession 25/25 全绿。
|
|
531
|
+
|
|
532
|
+
---
|
|
533
|
+
|
|
534
|
+
## 25. 分级保活：自驱动心跳 + 停滞自动同步会议（v1.4.2）
|
|
535
|
+
|
|
536
|
+
针对一次真实 run（"跑完就停"）的诊断：三名常驻第一轮就把问题归约到**同一个硬核引理**并一致给出 `solved=false`——这是**自然的难点停滞**，而非 bug。但框架的活性机制太弱且会"死"：
|
|
537
|
+
- 空闲后唯一驱动是心跳（`activityTimeoutMs` 唤醒一个常驻、CHECKPOINT 提示词偏向"是否要停止"），**缺乏推进力**；
|
|
538
|
+
- **唤醒失败会永久停死**（`scheduleNext` 在心跳分支 `await wakeResident(...)` 后无条件 `return`，而 `wakeResident` 捕获异常后返回 false 但**不重新武装心跳**）→ 一旦某次唤醒抛异常，心跳不再武装，小组**永不再被唤醒**；
|
|
539
|
+
- **唤醒 API 用错**（历史根因）：代码曾调 `subagents.followup(...)`，但 DSH 的 `subagents` 服务**没有** `followup`（那只是 `Agent` 对象的方法），真实运行时每次唤醒抛 `TypeError: is not a function` → 被 catch 后所有后续唤醒全部失败。**已改为** `subagents.sendMessage(root, childId, blocks, {signal})`（服务暴露的续做 API），并保留 `followup` 作为旧宿主兜底。
|
|
540
|
+
- `session.json` 不持久化 `meetingState`（进行中会议只在进程内存），进程重启或会议唤醒失败都可能让会议悬停。
|
|
541
|
+
|
|
542
|
+
### A · 自驱动心跳（修复推进力 + 永不永久停死）
|
|
543
|
+
- `heartbeatPrompt` 改为**自驱动**：不是"是否要停止"，而是"**请继续解决这个问题**——读他人库、推进子问题/引理/方法、尝试路线；或向团队发消息（input）、提议任务（propose_task）；确实已解决/无路可走才提议开会/声明 solved。默认立场是推进而非停在原地。" 心跳回复 schema 增加 `input`、`propose_task`、`contextPct`，使一轮心跳能产生群聊消息/任务从而带动后续工作。
|
|
544
|
+
- **并行填充**（修复"只有 r1、再只有 r2"串行）：`scheduleNext` A 分支不再是"一次只唤醒一个最闲常驻"，而是收集所有空闲常驻（按空闲时长从大到小）**一次尽量填满 `maxParallel` 并发预算**——每个 `wakeResident` 只 sendMessage 发送（立即返回，等各自 `subagent/end` 异步回归），因此一轮可同时唤醒多个常驻，真正并行推进。失败的唤醒只跳过该常驻、继续填满预算；唤醒失败则重新武装心跳。
|
|
545
|
+
- **唤醒失败重新武装心跳**：`scheduleNext` 心跳分支、`continueMeetingRound`、`continueVerifyRound` 在 `wakeResident` 失败（返回 false）时调用 `armHeartbeat()`，保证**任何一次唤醒失败都不会让小组永久停住**（会稍后重试其它常驻）。
|
|
546
|
+
- **并发邮箱投递**：`deliverNextMailbox` 一次投递所有当前空闲收件人的消息（受 `maxParallel` 上限），避免 `relayToGroup` 广播到多个常驻时被"一次一个"串行化；忙碌收件人保留其消息队列稍后再投（避免饿死其它常驻）。
|
|
547
|
+
|
|
548
|
+
### B · 停滞自动同步会议（分级保活 B）
|
|
549
|
+
- 新增 `lastProgressAt`（会话状态，随产物/会议/验证/任务/群聊/消息更新，`markProgress()`），并持久化到 `State/session.json`。
|
|
550
|
+
- `scheduleNext` 在无 meeting/verify/pending、`phase==='active'` 且 `now()-lastProgressAt >= stallAutoMeetingMs`（默认 360000=6 分钟，可调）时，自动 `startMeeting('团队较长时间没有新进展。请你们自行讨论…')`——框架**只促成会议、不指派任务**，让常驻们自行决定下一步路线/分工，从而"复活"一个停滞的团队。
|
|
551
|
+
- 这同时覆盖"进程重启后进行中会议丢失"的场景：重启后 `running:true, phase:active`、无会议 → 若持续无新产物，B 会自动再召集一次协调会议。
|
|
552
|
+
|
|
553
|
+
> 行为：有产出的团队会不断更新 `lastProgressAt`，B 不会触发；真正停滞的团队先被 A（自驱动心跳）持续轻推，若仍无新产物则被 B（自动同步会议）召集起来自主重启。全程框架只"促成"，从不指派任务。
|
|
554
|
+
>
|
|
555
|
+
> 新增参数：`stallAutoMeetingMs`（`vibe_v4_set`/`status` 可见）。新增测试：T14（停滞自动会议）、T15（自驱动心跳提示词非旧的"说下一步"）；`selfdrive-v4` 21/21、`e2e-v4-fixes` 39/39。
|
|
556
|
+
|
|
557
|
+
---
|
|
558
|
+
|
|
559
|
+
## 26. 会议/验证死锁看门狗（v1.4.3）
|
|
560
|
+
|
|
561
|
+
一次真实 run（测试6）证实 A+B 之后仍会出现"三个常驻都停"：**B 定时同步会议确实被触发了，但会议本身卡死**——`continueMeetingRound` 唤醒某常驻、其发言未被正确记录（或某常驻的唤醒一直失败），导致该常驻被反复唤醒（rounds 递增但会议不前进），而**会议一旦处于卡死状态，`scheduleNext` 只走 `meetingState → continueMeetingRound` 分支，A 心跳、邮箱投递、B 定时会议全部被挡住**，整个团队就永久停在一个坏掉的会议后面。
|
|
562
|
+
|
|
563
|
+
### 死锁看门狗
|
|
564
|
+
- `meetingState` 增加 `lastInputAt`、`verifyState` 增加 `lastVerdictAt`（创建时=now，每当收到新发言/投票时刷新）。
|
|
565
|
+
- `continueMeetingRound` / `continueVerifyRound` 顶部加看门狗：若 `now()-lastInputAt/lastVerdictAt >= recoverStallMs()`（= `activityTimeoutMs`×2，默认 4 分钟），判定该会议/验证**卡死**，**放弃**（`meetingState/verifyState=null`，记 `abandoned (stuck)`），随后 `scheduleNext()` 回到正常自组织（A/B 继续驱动）。
|
|
566
|
+
- 同时：**找不到空闲的未发言/未投票常驻时不再静默 `return`，改为 `armHeartbeat()`**（稍后重查），并在发现"没有空闲者"时也武装心跳，杜绝"一直等待一个永不空闲的常驻"造成的隐性挂起。
|
|
567
|
+
- 分级保活 B 增加 `busy.size===0` 守卫：任何常驻正在工作时不触发，避免预抢占在途轮次。
|
|
568
|
+
|
|
569
|
+
### 会议与验证互斥（不抢占）
|
|
570
|
+
- 并行填充常驻后，一个常驻可能"提议验证（propose_verify）"而另一个同时"提议开会（propose_meeting）"。**会议不得抢占验证**：`startMeeting` 在 `verifyState || pendingVerify` 时改为把会议请求**暂存**（`pendingMeeting`，仅记录 agenda/type/target）并返回 `{deferred:true}`；`scheduleNext` 在所有 meeting/verify/pending 都清空后才恢复该暂存会议。这样统一共识验证（全真/全假）作为"求真"环节不会被会议的协调讨论打断，验证做完后再开会开会协调下一步——两者互斥但都不丢失（暂存会议之后补开）。**暂存只保留第一条**（`!pendingMeeting` 才写入），避免后到的请求覆盖先到的。
|
|
571
|
+
- **进行中增删常驻的一致性**：在会议/验证进行中 `removeMember` 会**同步清理**该常驻的会议发言（`delete meetingState.inputs[id]`）、验证投票（`delete verifyState.verdicts[id]`）、若它是待验证的提出者则清 `pendingVerify`，并从会议发言顺序 `st.order` 里剔除它；`wakeResident` 对已经不存在的常驻**防御性返回 false**（不再因 `r.childId` 抛 TypeError）。这样移除一个常驻不会让共识**卡在幽灵身上**，也不会让会议/验证循环去唤醒一个已删除的常驻而导致崩溃。
|
|
572
|
+
|
|
573
|
+
### 实战审计修复（test9）
|
|
574
|
+
- **源卡回写定位与格式兼容**：常驻用 fs 直写卡片时，文件名可能与卡内声明的 `- ID:` 不一致（如 `Propos/r-3/p-01.md` 声明 `ID: p-r3-01`），且元数据可能是单行 `; ` 分隔（`- ID: p-105; - 状态: 未定论; - 概率: 0.95; …`）。旧 `findSourceRel` 只按文件名匹配 → 找不到 → 回退到顶层 `Propos/<target>.md` 并对空串执行写回，产生 **0 字节垃圾文件**、真实源卡状态不更新；旧回写正则只匹配"每行一个字段"的格式，对单行 `; ` 分隔卡失效。修复：① 文件名快查后增加**按卡内 `- ID:` 扫描**各常驻库；② 找不到时**跳过写回并记日志**（不再造空文件）；③ 回写正则兼容"行首字段"与"行内 `; ` 分隔字段"两种格式。
|
|
575
|
+
- **会议/验证终结幂等（并发重入）**：两个常驻的 `onResidentEnd` 同时看到 `allSpoke/allVoted` 时可能**并发执行两次 finalizeMeeting/finalizeVerify**，重复 `meetings.push`/`logDecision`/`propose_task`/`stop`（test9：同一次会议在 decisions/session 里出现两次、生成两条相同任务、重复 stop）。修复：会话级 `finalizeLock` 重入锁（第一次执行期间再次进入直接返回），且**锁在调用 `scheduleNext()` 之前释放**——否则锁会跨 await 误吞紧随其后的链式验证/会议终结（牵连修正）。
|
|
576
|
+
- **重复验证同一对象去重**：并行自组织下多个常驻可能各自对同一对象 `propose_verify`，导致对象被端到端验证两次（test9：p-r3-04 被 Verified 两次）。修复：`verifiedRecently` 记录刚定论对象；在去重窗口（`recoverStallMs()`）内忽略对同一对象的再次提议（`maybeQueueVerify`）；`beginVerify` 启动时**再查一次**去重窗口（丢弃"验证进行中排进 pendingVerify、前一个刚关闭"的重复请求）；扩展后仍可在窗口外重新提议。
|
|
577
|
+
- **会议进行中加入成员**：新成员不在会议发言快照 `order` 中会导致 `allSpoke`（按当前成员集判定）永不成立，会议只能靠看门狗超时放弃。修复：`addMember` 在会议进行中把新成员**追加进 `order`**（验证进行中则自动被要求投票，无需处理）。
|
|
578
|
+
- **邮箱被长会议/长验证链饿死（记录为设计边界，未在会议轮内打断）**：`scheduleNext` 只在"无 meeting/verify/pending"时投递邮箱；verify→meeting→verify 长链可能让邮箱消息长时间未送达（test9 收尾期有积压）。曾尝试在会议/验证轮间投递，但会把未投票/未发言的常驻拉去做普通轮，令验证在看门狗窗口内等不到票而**误放弃**——故回退，改为**仅在无进行中共识时投递**（消息持久化不丢失，下次非共识调度/恢复时送达）。
|
|
579
|
+
|
|
580
|
+
> 效果：一个卡死/坏掉的会议或验证最多阻塞 `activityTimeoutMs`×2 后自动释放，团队重新回到 A/B 分级保活，**不会永久停死**。仍符合"框架只促成、从不指派任务"（放弃只是终止一个无法推进的会议，把控制权交还团队的自组织循环）。
|
|
581
|
+
>
|
|
582
|
+
> 说明：无法对"某常驻真的拒绝/掉线"的情况达成全体一致时，看门狗会把该对象保留为"未定论/带概率"，这是哲学上期望的诚实结果。`session.json` 仍不持久化 `meetingState`（进行中的会议不跨进程恢复），B 的停滞看门狗在重启后仍会触发，因此重启也能自愈。
|
|
583
|
+
>
|
|
584
|
+
> 全套测试仍全绿：`selfdrive-v4` 21/21、`e2e-v4-fixes` 120/120（T1–T41，后续审计回归见 §27–§30）、v3 100/100、v2 business 18/regression 14、multisession 25/25。
|
|
585
|
+
|
|
586
|
+
## 30. 第六/七轮全面深度审计（npm v2.0.21，迭代至无新发现）
|
|
587
|
+
|
|
588
|
+
按"不断检查、修复直至没有新问题"的要求连续多轮审计：本轮修复 6 处 + 2 处加固（新增回归 T38–T41），其后两轮全量通读与一致性扫描**未再发现新问题**，审计收敛。
|
|
589
|
+
|
|
590
|
+
- **全票停会后协调态残留**：`finalizeMeeting` 的 allSolved 分支直接 return，留下 `meetingState`/`wakeKind`/pending 态 → status 永久谎报 `meetingInProgress:true`（v2.0.20 修了 initAbort 却漏了 stop 路径）。修复：stop 分支与 initAbort 对称清空全部协调态。**T38**。
|
|
591
|
+
- **已定论/未运行 run 上 addMember 仍开工**：`addMember` → `spawnResident` 会真的启动一轮头脑风暴——在已全票定论的项目上制造僵尸工作。修复：`!running || autoDone` 时拒绝。**T38**。
|
|
592
|
+
- **验证目标/记录 id 路径穿越**：`propose_verify` 或 record 工具传入含 `/`、`\`、`:` 等的 id 时，Verified 卡/辩论文档/来源回写路径可逃出项目树或写入他人目录。修复：`idSafe` 消毒（保留含中文在内的无害字符，仅替换分隔符/非法字符/控制字符，去首尾点与横线），在 `maybeQueueVerify`（唯一入队漏斗）与三个 record 工具处统一应用。**T39**。
|
|
593
|
+
- **resident 工具 `to=all` 声称支持实际报错**：toolList 宣称 `vibe_v4_send_message {to:all}` 可广播，但 resident 版直接 `residents.get('all')` → no such resident。修复：resident 调用 `to=all` 走 `broadcast(content, from)`，且**跳过自己**（host 广播不受影响）。**T40**。
|
|
594
|
+
- **负值/NaN 时长参数灾难**：`vibe_v4_set {activityTimeoutMs:-50}` 会让 `recoverStallMs()` 为负 → 会议/验证看门狗**立即放弃一切共识**；A-fill 空闲窗口永不流逝（每 pass 唤醒全员）。修复：`posMs(v,def)` 兜底所有时长读取（recoverStallMs、makeSignal、armHeartbeat、A-fill atOs、B 停滞阈值）。**T41**。
|
|
595
|
+
- **residentCount<=0 启动空转**：settings 误配 0/负值 → start 不生成任何常驻却 running=true。修复：start 时回落默认值。
|
|
596
|
+
- **加固**：`deliverNextMailbox` 顺带清理已不存在常驻的陈旧邮箱条目；`subagent/end` 处理异常时（理论上所有 IO 均已内捕，此为最后防线）调用会话 `nudge()` 补一针调度，杜绝"异常回合后无 end、无心跳"的静默停摆。
|
|
597
|
+
|
|
598
|
+
> 审计收敛声明：此后两轮对全文件（1111 行）逐函数通读 + 交叉扫描，仅剩以下**已记录设计边界**（均有意识保留、非缺陷）：brainstorm 首轮 end 永不触发无看门狗（框架外故障）；会议/验证"末位在途成员"不被心跳打断（避免误杀慢成员，真实 DSH 回合必有 end）；暂停中显式 `postMessage` 仍投递（人的明确指令）；默认工具全继承（T11 钉住，宿主级工具未写入 resident toolList）；邮箱在超长共识链后送达（§27）；`State` 与进程内共识态不跨进程持久化（§26 说明，重启后 A/B 保活自愈）。
|
|
599
|
+
>
|
|
600
|
+
> 全套测试仍全绿：`selfdrive-v4` 21/21、`e2e-v4-fixes` 120/120（T1–T41）、v3 100/100、v2 business 18/regression 14、multisession 25/25、selfdrive-v3 0 异常。
|
|
601
|
+
|
|
602
|
+
## 29. 第五轮全面深度审计（npm v2.0.20，遗留区域 + 未修改逻辑）
|
|
603
|
+
|
|
604
|
+
对历轮尚未触达的"牵连对象/未改逻辑"做复查，发现并修复 5 处（新增回归 T33–T37）：
|
|
605
|
+
|
|
606
|
+
- **运行中 resume 用陈旧磁盘快照覆盖内存态（静默 clobber）**：resume 先 `loadAll` 再用磁盘状态覆盖内存——若某进程已在本进程内驱动着活 run（有人把 resume 当"踢一脚"用），内存里比磁盘新一个事件的 busy/轮次/邮箱状态会被回退到最近一次 saveAll 的快照。修复：resume 开头预读 `session.json`，若内存 `running && !autoDone` **且磁盘 epoch 属于本进程**（同进程活 run），直接返回 `{ok:true,message:'already running (no-op)'}`——不做任何加载；跨进程重启（epoch 不同）不受影响（A4 场景依旧放行）。**T33**。
|
|
607
|
+
- **configure 在运行中切换项目 → 状态分裂到两棵树**：configure 是"启动前"工具，但运行中调用会把 currentProject 改到新项目：常驻的简报/资料库仍在旧树，而之后的 saveAll/会议纪要/Verified 卡全写到新树。修复：`running && !autoDone` 时拒绝并提示改用 `vibe_v4_set` 调参数。**T34**。
|
|
608
|
+
- **abort 后 status 谎报在途协调态**：initAbort 只停调度并清 childId，会议/验证/暂存会议/验证队列/busy 全部残留——被中断常驻的 end 因 childId 已清无法命中，busy 印记永远无人清除，status 显示"会议进行中/验证中/busy=[r-1]"，而 run 早已 running=false。修复：initAbort 一并清空 `meetingState/verifyState/pendingMeeting/pendingVerify/busy/wakeKind/currentResident/finalizeLock`。**T35**。
|
|
609
|
+
- **暂停期间 claim 任务会僵尸唤醒认领者**：v2.0.18 的暂停门控只覆盖了 end 处理器；`claimTask` 的直接唤醒绕过了它——暂停时某个 end 回复里 `claim_task`（或宿主工具认领）会把认领者拉起来做一轮新工作。修复：认领记录照常入板，但唤醒加 `running && !autoDone` 门控（认领者自己知道认领了什么，恢复后自然接续）。**T36**。
|
|
610
|
+
- **reports/meetings 无界膨胀（session.json 每事件全量重写）**：`reports` 只写不读，且每个普通轮 end（模板自带 `solved:false`）都 push 一条；`meetings` 数组把**完整会议全文**再存一份（磁盘 `Shared/meetings/<id>.md` 已有），长 run 中 session.json 越来越大、每次 saveAll 都重写整份。修复：reports 上限 100（环形），meetings 只存 {id,agenda,at} 小索引（上限 200）——全文仍在磁盘，会议计数/报告不受影响。**T37**。
|
|
611
|
+
- **连带小修**：`postmark` 的 contextPct 只认 number，模型报数字字符串（"40"）时不生效；现兼容数字字符串。
|
|
612
|
+
|
|
613
|
+
> 边界复查（未改，记录）：暂停中 `postMessage`（显式宿主动作）仍会投递唤醒（与"认领"不同，是人的明确指令）；brainstorm 期首轮 end 永不触发、以及"邮箱在超长共识链后送达"维持 §27/§28 的设计边界。
|
|
614
|
+
>
|
|
615
|
+
> 全套测试仍全绿：`selfdrive-v4` 21/21、`e2e-v4-fixes` 107/107（T1–T37）、v3 100/100、v2 business 18/regression 14、multisession 25/25、selfdrive-v3 0 异常。
|
|
616
|
+
|
|
617
|
+
## 27. 第三轮全面深度审计（npm v2.0.18，牵连对象/逻辑）
|
|
618
|
+
|
|
619
|
+
对 v2.0.16/17 修复做连带对象与逻辑审计，又发现并修复 6 处真实缺陷（每处均有新回归 T24–T28 钉住）：
|
|
620
|
+
|
|
621
|
+
- **验证提议单槽丢失（pendingVerify 改 FIFO 队列）**：旧实现 `pendingVerify` 是单槽，后到覆盖先到——一次同步会议里多位常驻**各自提议不同对象**（或并行普通轮同时提议）时，只有最后一个对象的验证会被执行，前面的提议**静默丢失**（正是"框架忠实转达"哲学最不能丢的一环）。修复：改为 FIFO 队列 + 队内同目标去重（`maybeQueueVerify` 去重窗口后入队；`scheduleNext` 出队头启动；`beginVerify` 的"启动时二次去重"保留；`removeMember` 过滤其名下在队提议；status/report 显示队头 + `pendingVerifyCount`）。**T25**：一次会议两个成员各提议一个对象 → 两个都完整验证到 Verified/。
|
|
622
|
+
- **removeMember 后不再驱动调度 → 共识永久冻结**：会议/验证在服务中不武装心跳，靠"常驻 end 事件"推进。若被移除的常驻恰是**唯一在途**的那一个（如最后一个未投票者/未发言者，interrupt 后不会再发 end），其余常驻明明已齐票/齐发言却没人触发 finalize——没有看门狗能救（看门狗也在 end 驱动的轮次里），**永久冻结**。修复：`removeMember` 清理后立即 `await scheduleNext()`（顺带把 `currentResident` 复位）。**T26**：验证中移除在途未投票者（mock 永不发 end）→ 验证在剩余成员间照常达成全票、正常定论。
|
|
623
|
+
- **会议在 brainstorm/暂停期"假启动"后被看门狗误杀**：会议在 brainstorm 阶段（成员都在首轮思考）或暂停期间无法被服务，但它的看门狗时钟在创建时就开始走；几分钟后真正轮到它时已被判定卡死而**放弃**（主持人/常驻的会议请求被静默吞掉）。修复：`startMeeting` 在这两种情形（以及验证占场、暂停）一律**暂存到 `pendingMeeting`**（首条优先、不覆盖），等 brainstorm 完成/验证清空/恢复后再真正开始（时钟从真正开始时算）；从未启动（无成员）与已全票定论（autoDone）的运行则**明确拒绝**——旧代码在那里开会只会造出一个谁也唤不醒的僵尸会议。
|
|
624
|
+
- **autoDone 后 resume 把已结束的 run 悄悄复活**：已全票定论（`autoDone`）的 run 被 resume 后会把 autoDone 清掉、继续唤醒常驻工作——违反"只有全组一致认为已解决才停止"的哲学（僵尸复活）。修复：`resume()` 在 autoDone 时拒绝并提示改用 `vibe_v4_start`/`vibe_v4_configure`。**T24**。
|
|
625
|
+
- **暂停(Pause)不冻结共识;恢复后看门狗误杀进行中的会议/验证**：旧 setPause 只停 A/B 自驱动，进行中的会议/验证在常驻 end 后仍继续**新唤醒**（暂停不暂停）；而暂停期间时钟照走，恢复后若暂停超过看门狗窗口，进行中的会议/验证会被**立即放弃**。修复：end 处理器在 `!running` 时记录在途发言/投票后**不再启动新唤醒**（真暂停）；`resume()` 对仍在进行的 meeting/verify **刷新看门狗时钟**后继续。**T28**：暂停期间在途会议发言被记录但无新唤醒；恢复后会议照常收尾（转录文件写出）。
|
|
626
|
+
- **writeJson 并发丢写（同文件延迟序列化）**：taskboard/session/residents 等 State 文件被并行轮、end 处理器、工具并发写；两个近同时写同一文件的流程各自在 fs.writeText 落地**之前**序列化快照，**旧快照后落地会覆盖新快照**（同一瞬间两位常驻各自 proposeTask → 其中一条从 taskboard.json 消失，直到下次保存才自愈）。修复：`writeJson` 按文件串行化 + **延迟到真正执行时才 JSON.stringify**（执行时取最新内存态，后写者永远带全量状态，不会用旧子集覆盖）。
|
|
627
|
+
- **连带小修**：verdict 为**引号数字串**（`"0.9"`，LLM 常见）时旧解析落到 confidence 缺省 → 静默记成 0.5 不确定；现按数字解析。**T27**。
|
|
628
|
+
- **start() 前中断旧常驻**：同一会话复用启动新 run 时，旧 run 仍在途的常驻会继续往**同名** `r-1..` 库路径写文件，与新 run 的 r-1.. 互相污染；start 重置前先 interrupt 旧常驻。
|
|
629
|
+
|
|
630
|
+
> 设计边界复查确认（未改）：① 会议/验证轮次唤醒**不额外受 maxParallel 限制**——共识需要全员发言/投票；每个调度 pass 只唤醒一个未发言/未投票者，由各 end 事件串行驱动（残留的普通轮可能造成短暂并发，但不会无限累积）；② 非一致（平均概率留库）的对象可被后续提议**再次端到端验证**（去重窗口只挡"刚定论为真/假"的对象）——重复提议者是在不知情时提议的，重验一轮不算错；③ 验证中途 `addMember` 的新成员会被要求投票（v2.0.17 注释行为，保持）；④ 已定论 run 的成果随时可在磁盘读取，resume 拒绝只针对"自动复活"。
|
|
631
|
+
|
|
632
|
+
## 28. 第四轮全面深度审计（npm v2.0.19，对 v2.0.18 修复的牵连检查）
|
|
633
|
+
|
|
634
|
+
对 v2.0.18 的修复（FIFO 验证队列、会议暂存、暂停门控、writeJson 串行化等）做连带对象复查，发现并修复 4 处（新增回归 T29–T32）：
|
|
635
|
+
|
|
636
|
+
- **同回合重复 `subagent/end` 会把每个副作用跑两遍**：`onResidentEnd` 对"已结算回合的重复/迟到 end"无守卫——重复投递同一 end（宿主重放、桥接层抖动）会让 propose_task / 群聊转发 / 验证入队 / meetings.push **全部二次执行**（test9 的重复任务/重复 stop 一类问题在"重复 end"场景会原样复发）。修复：回合必须以 busy 标记在册为前提——`if(!busy.delete(r.rId)) return`（每次合法 end 都对应一次 spawn/wake 置位的 busy；busy 仅在本处、唤醒失败、removeMember、重生成时清除，而后者 stale childId 已无法 byChild 命中）。**T29**：同一 tick 内连发两次相同 end → 任务只提议一次、群聊只转发一次。
|
|
637
|
+
- **空/失效 rId 的 resident 写入工具会制造库根散卡**：`currentResident` 被复位为 `''`（如移除最后一名常驻后）时，主机/未知代理调用 `vibe_v4_record_*`/`vibe_v4_publish_progress` 会把路径 `Propos//p-x.md` 塌缩成**库根目录的散乱卡片**（正是 test9 曾出现的 0 字节散卡一类问题）。修复：`residentIdOf` 回退仅当 `currentResident` 仍真实存在时生效，否则返回 `''`；四个库写入函数对空/未知 rId 直接拒绝 `{ok:false}`（主机以 `currentResident` 代写这一既有便利不受影响——自驱动测试仍走该回退）。**T30**。
|
|
638
|
+
- **移除者的已排队验证提议被丢弃 → 提议静默蒸发（含"第二提议者意图被去重吞掉"边角）**：v2.0.12 遗留的"移除提议者则清掉其 pendingVerify"在 FIFO 队列下会把该成员的排队提议**整条删除**；且同目标被两人提议时去重只保留第一人的条目——若第一人被移除，第二人的意图同样蒸发。修复：`removeMember` **不再过滤验证队列**——提议是关于对象的陈述，由**当前成员**按对象价值共识判定（allVoted 本就按实时成员集计算，写回扫描也不依赖提出者存续）。**T31**：r-3 提议 p-x 后在 p-y 验证中被移除 → p-x 仍由剩余成员完整验证到 Verified/。
|
|
639
|
+
- **暂存的会议对用户不可见 / 普通轮提议任务永远没有描述**：`status/report` 新增 `parkedMeeting`（暂存会议议程），便于确认"会议没丢、在排队"（**T32** 同时钉住"brainstorm 期开会 → 暂存 → bootstrap 后真正召开"，不再被看门狗误杀）；普通轮/心跳提示词模板补上 `task_desc` 字段（此前普通轮提议任务时描述恒为空，只有会议轮能带描述）。
|
|
640
|
+
|
|
641
|
+
> 边界复查（未改，记录）：brainstorm 阶段若某常驻首轮 end 永不触发，run 停在 brainstorm（brainstorm 无看门狗、无心跳可唤醒"已空闲"者推进）——真实 DSH 的轮次必然以 completed/error/timeout 结束并触发 end，纯属框架外故障，不做可能"静默丢掉慢成员声音"的自动跳过；`Shared/taskboard.md`（人类视图）由调用时快照生成、非逐文件串行，最坏情况短暂滞后于 `State/taskboard.json`（权威源），下次任务动作即自愈。
|
|
642
|
+
>
|
|
643
|
+
> 全套测试仍全绿：`selfdrive-v4` 21/21、`e2e-v4-fixes` 94/94（T1–T32）、v3 100/100、v2 business 18/regression 14、multisession 25/25、selfdrive-v3 0 异常。
|
|
644
|
+
|
|
645
|
+
|
|
646
|
+
|
|
647
|
+
|