278 lines
7.5 KiB
Markdown
278 lines
7.5 KiB
Markdown
# V4 最小落地方案（当前 OpenClaw 实例）
|
||
|
||
- 版本：v1
|
||
- 日期：2026-03-27
|
||
- 目的：在不大改现有工作流的前提下，让 Val 当前实例开始按 v4（Truth Gate / facts layering / truth audit / credibility-first）运转。
|
||
|
||
---
|
||
|
||
## 1. 目标
|
||
|
||
本方案不追求一次性把全部 v4 组织完全实现，而是先落地最关键的 4 个能力：
|
||
|
||
1. **Truth Gate**：中大型任务立项前先过真实性闸门
|
||
2. **Facts Layering**：明确区分 verified / claimed / assumed
|
||
3. **Sentinel 独立审计**：至少复杂任务时把事实审计独立出来
|
||
4. **Atlas 记忆闭环**：把事实、失败与规则沉淀回知识层
|
||
|
||
---
|
||
|
||
## 2. 当前可复用资产
|
||
|
||
### 2.1 现有治理基础
|
||
- `org/CONSTITUTION_v1.md` / `v2` / `v3`
|
||
- `workspace-val/org/CONSTITUTION_v4.md`
|
||
- `workspace-val/org/TRUTH_GATE_ROLES_AND_FLOW.md`
|
||
- `workspace-val/org/TRUTH_GATE_TEMPLATE.md`
|
||
|
||
### 2.2 现有角色定义
|
||
- `org/agents/BRAIN_AUDITOR_SENTINEL.md`
|
||
- `org/agents/BRAIN_CONTROLLER_VECTOR.md`
|
||
- `org/agents/KNOWLEDGE_MEMORY_ATLAS.md`
|
||
|
||
### 2.3 现有闸门与证据资产
|
||
- `org/pilot/GATE_USAGE.md`
|
||
- `org/pilot/gate_check.sh`
|
||
- `org/pilot/EVIDENCE_MANIFEST.md`
|
||
- `org/ops/sentinel_audit_contract.v1.md`
|
||
- `org/ops/sentinel_audit_contract.v1.json`
|
||
|
||
结论：当前实例**并不缺概念和模板**，缺的是把这些模板变成主会话的日常强制动作。
|
||
|
||
---
|
||
|
||
## 3. v4 在当前实例里的最小角色映射
|
||
|
||
### Val — Gate Owner（立即生效）
|
||
- 负责判断一个任务是否必须过 Truth Gate
|
||
- 负责汇总 Atlas + Sentinel 输出
|
||
- 负责做 `pass / hold / fail`
|
||
|
||
### Atlas — Facts Ledger Owner（以文件系统模拟）
|
||
当前先不单独常驻成 agent，先以文件与记忆层模拟：
|
||
- 事实台账 → 写入任务文件 / `.learnings/` / `memory/`
|
||
- 关键来源 → 明确记录文件路径、工具输出、时间
|
||
- unknowns / gaps → 在任务模板中显式写出
|
||
|
||
### Sentinel — Truth Auditor（优先独立成子代理）
|
||
当前最值得先独立出来的角色。
|
||
- 中大型任务：由主会话显式 spawn 一个审计子代理
|
||
- 输出：truth audit（pass / partial / fail）
|
||
- 审计对象：facts manifest，而不是直接审设计
|
||
|
||
### Vector — Orchestrator（继续由 Val 主控兼任）
|
||
短期内继续由 Val 兼任 Vector：
|
||
- 负责 sessions_spawn / 汇总 / 节奏控制
|
||
- 但前提是：**未过 Truth Gate 不得分发执行型子任务**
|
||
|
||
---
|
||
|
||
## 4. Truth Gate 触发规则（最小版）
|
||
|
||
以下任务默认必须触发 Truth Gate：
|
||
|
||
1. 涉及模型 / API / 订阅 / 权限 / 配置边界
|
||
2. 涉及外部系统接入
|
||
3. 涉及架构设计或方案立项
|
||
4. 涉及“选什么模型 / 走什么路由 / 用什么平台”这类判断
|
||
5. 涉及复杂多 agent 协作，且前提事实尚未明确
|
||
|
||
以下任务可跳过：
|
||
- 纯文本润色
|
||
- 小范围已验证文件修改
|
||
- 已知环境内的低风险例行操作
|
||
- 不涉及资源边界判断的简单查询
|
||
|
||
一句话规则：
|
||
> 只要资源边界不清，就先过 Truth Gate。
|
||
|
||
---
|
||
|
||
## 5. 最小执行流程
|
||
|
||
### Step 1 — Intake
|
||
Val 接收任务后先判断：
|
||
- `skip_truth_gate`
|
||
- `require_truth_gate`
|
||
|
||
### Step 2 — Atlas Manifest（轻量）
|
||
主会话先产出最小 facts manifest，至少包含：
|
||
- Verified facts
|
||
- Claimed facts
|
||
- Assumed facts
|
||
- Unknowns / Gaps
|
||
|
||
模板可直接复用 `workspace-val/org/TRUTH_GATE_TEMPLATE.md` 的核心字段。
|
||
|
||
### Step 3 — Sentinel Truth Audit
|
||
若任务为 medium / complex：
|
||
- 用 `sessions_spawn` 拉起一个 Sentinel 子代理
|
||
- 审 facts manifest
|
||
- 输出：
|
||
- `truth_audit: pass | partial | fail`
|
||
- `critical_gaps`
|
||
- `forbidden_assumptions`
|
||
- `recommendation: proceed | hold | stop`
|
||
|
||
### Step 4 — Val Gate Decision
|
||
Val 根据 Atlas + Sentinel 输出，做：
|
||
- `pass` → 允许 Oracle / Helix / Vector 后续流程
|
||
- `hold` → 先补证据，再继续
|
||
- `fail` → 终止当前路径，必要时改问题定义
|
||
|
||
### Step 5 — 才进入设计 / 分流 / 执行
|
||
只有 `pass` 后，才允许：
|
||
- Oracle 做复杂度分流
|
||
- Helix 做方案设计
|
||
- Vector 派发执行型子代理
|
||
- Anvil / Forge / Bastion 等进入执行链
|
||
|
||
---
|
||
|
||
## 6. 输出格式（当前实例强制建议）
|
||
|
||
今后复杂任务前，主会话默认给出：
|
||
|
||
```markdown
|
||
## Truth Gate
|
||
|
||
### Verified
|
||
- ...
|
||
|
||
### Claimed
|
||
- ...
|
||
|
||
### Assumed
|
||
- ...
|
||
|
||
### Unknown / Gaps
|
||
- ...
|
||
|
||
### Sentinel Truth Audit
|
||
- result: pass|partial|fail
|
||
- critical_gaps: ...
|
||
- forbidden_assumptions: ...
|
||
|
||
### Val Decision
|
||
- truth_gate: pass|hold|fail
|
||
- next_action: ...
|
||
```
|
||
|
||
如果没有这段，默认视为：
|
||
- 尚未真正进入 v4 流程
|
||
|
||
---
|
||
|
||
## 7. 多智能体协作的 v4 约束
|
||
|
||
### 允许并行派发的前提
|
||
必须同时满足：
|
||
- Truth Gate 已 pass
|
||
- 子任务边界清晰
|
||
- 关键依赖为 verified
|
||
- 失败成本可控
|
||
|
||
### 禁止并行派发的情况
|
||
任一满足即禁止：
|
||
- 核心资源仍是 claimed / assumed
|
||
- 问题本身是否存在都未确认
|
||
- 路由/平台/模型选择仍建立在假设上
|
||
- 需要外部权限但未确认开通
|
||
|
||
一句话原则：
|
||
> 前提没过关，不要让多个 agent 一起放大错误。
|
||
|
||
---
|
||
|
||
## 8. Atlas / Prism / Forge 的最小闭环
|
||
|
||
### Atlas（先文件化）
|
||
每个中大型任务结束后，至少沉淀：
|
||
- 最终 verified facts
|
||
- 关键 decision
|
||
- 失败模式（如有）
|
||
- 新规则 / 新工具边界
|
||
|
||
建议写入位置：
|
||
- `memory/YYYY-MM-DD.md`
|
||
- `.learnings/LEARNINGS.md`
|
||
- `.learnings/ERRORS.md`
|
||
- `TOOLS.md`
|
||
- `AGENTS.md`
|
||
|
||
### Prism（先流程化）
|
||
当前不要求独立常驻 agent，但失败时必须执行：
|
||
1. 停止推进
|
||
2. 记录 failure pattern
|
||
3. 判断是否要回到 Truth Gate
|
||
4. 禁止用“继续修补”掩盖基础前提错误
|
||
|
||
### Forge（先知识化）
|
||
把工具边界明确写进：
|
||
- `TOOLS.md`
|
||
- `.learnings/ERRORS.md`
|
||
- `.learnings/LEARNINGS.md`
|
||
|
||
如：
|
||
- Lightpanda 当前仅适合实验性站点验证
|
||
- Tavily 已接入，适合作为网页资讯搜索层
|
||
|
||
---
|
||
|
||
## 9. 立即可执行的制度变化
|
||
|
||
### 规则 1
|
||
今后所有涉及接入/架构/平台选择的任务，Val 默认先输出 Truth Gate。
|
||
|
||
### 规则 2
|
||
今后复杂任务的第一个子代理，优先不是工兵执行，而是 Sentinel 审事实。
|
||
|
||
### 规则 3
|
||
如果 Sentinel 给出 `partial` 或 `fail`，Val 不得继续组织执行型并行协作。
|
||
|
||
### 规则 4
|
||
复杂任务结束后，至少写 1 条 Atlas/Prism/Forge 向的沉淀：
|
||
- 事实
|
||
- 失败模式
|
||
- 工具边界
|
||
- 预防规则
|
||
|
||
---
|
||
|
||
## 10. 判断是否已进入“v4 最小落地”的验收标准
|
||
|
||
### 达标标准
|
||
- [ ] 中大型任务开始前，有显式 Truth Gate 输出
|
||
- [ ] 至少 1 个复杂任务使用过独立 Sentinel truth audit 子代理
|
||
- [ ] Val 有明确 `pass / hold / fail` 决策
|
||
- [ ] 未过 Truth Gate 的任务，没有直接进入执行链
|
||
- [ ] 至少 1 次任务结束后，把 facts / failures / rules 沉淀到 Atlas/Prism/Forge 对应文件
|
||
|
||
如果以上 5 条都做到，可认为：
|
||
> 当前实例已进入 v4 的最小可运行状态。
|
||
|
||
---
|
||
|
||
## 11. 推荐推进顺序
|
||
|
||
### Phase 1（马上生效）
|
||
- 主会话开始强制使用 Truth Gate 输出模板
|
||
- 复杂任务先派 Sentinel truth audit
|
||
|
||
### Phase 2（接下来 1-3 次复杂任务）
|
||
- 把 Atlas 输出模板固定下来
|
||
- 把 Prism 失败处理规则固定下来
|
||
|
||
### Phase 3（后续）
|
||
- 再考虑把 Oracle / Helix / Vector / Atlas 真正分离成更稳定的独立 agent 角色
|
||
|
||
---
|
||
|
||
## 12. 一句话结论
|
||
|
||
当前实例离 v4 并不远，最大的缺口不是“没有 agent 名字”，而是：
|
||
|
||
**Truth Gate 还没成为强制动作。**
|
||
|
||
一旦把 Truth Gate + Sentinel truth audit + Val pass/hold/fail 固化下来，v4 就会从理念变成日常运行机制。
|