auto-sync: 2026-05-16 12:08:04
This commit is contained in:
cfdaily
@@ -1797,9 +1797,19 @@ moziplus 同此模式：一个 SQLite 黑板、一个 Daemon 进程、Tick 扫
|
||||
| 课题10 | 上下文管理 | — | ⏸️ 暂缓 |
|
||||
| 课题11 | 用户级多项目 | 参考优秀实践给方案提案 | 📋 待做 |
|
||||
|
||||
### 调研中
|
||||
### 潜在课题（7项目调研衍生）
|
||||
|
||||
- 7 个新项目调研（Claude Squad / Superset Terminal / OpenCode / claude-goal / Cline / Aider / DeepSeek-TUI）
|
||||
| 课题 | 来源 | 内容 | 优先级 |
|
||||
|------|------|------|--------|
|
||||
| 节点级模型策略 | Aider architect/editor/weak 三层分工 | 审查节点用强模型、执行节点用快模型，成本与质量平衡 | P2 |
|
||||
| 信任分级系统 | DeepSeek-TUI Plan/Agent/YOLO 三级 | Dashboard 按信任等级展示不同操作按钮 | P2 |
|
||||
| Worktree 项目隔离 | Superset + Claude Squad | 课题11多项目时的物理隔离方案 | P1（与课题11一起设计） |
|
||||
|
||||
### 已完成调研
|
||||
|
||||
- ✅ 7 个新项目调研（Claude Squad / Superset Terminal / OpenCode / claude-goal / Cline / Aider / DeepSeek-TUI）
|
||||
- 综合报告：`docs/research/research-seven-projects-synthesis.md`
|
||||
- 详细报告：`docs/research/research-batch{1,2,3}-*.md`
|
||||
|
||||
### 12.2 开发启动条件
|
||||
|
||||
@@ -1847,3 +1857,158 @@ moziplus 同此模式：一个 SQLite 黑板、一个 Daemon 进程、Tick 扫
|
||||
| 黑板膨胀(大量评论/产出)| 低 | 定期 archive + agent 只读最近 N 条 |
|
||||
| Agent 不知道该做什么 | 中 | Skill 指导 + 庞统 plan 评论 + daemon 消息含上下文 |
|
||||
| Sanguo Mail 退役后的系统通知 | 低 | 黑板 system 类型任务替代 |
|
||||
|
||||
---
|
||||
|
||||
## 15. 7项目调研结论与设计借鉴
|
||||
|
||||
> **调研日期**: 2026-05-16
|
||||
> **调研范围**: Claude Squad / Superset Terminal / OpenCode / claude-goal / Cline / Aider / DeepSeek-TUI
|
||||
> **详细报告**: `docs/research/research-seven-projects-synthesis.md`
|
||||
|
||||
### 15.1 已纳入设计的借鉴点
|
||||
|
||||
#### 借鉴1：Guardrail 验证脚本层（纳入课题3）
|
||||
|
||||
**来源**: Aider lint→test→commit 质量闭环
|
||||
|
||||
**当前设计**（topic3 方案 阶段2）：
|
||||
```
|
||||
L1 机械检查（文件存在、JSON格式）→ 不通过直接打回
|
||||
L2 轻量 AI 检查（Schema校验）→ 不通过写 observation
|
||||
L3 安全红线（tripwire）→ 立即中断
|
||||
```
|
||||
|
||||
**增强后**：L1 增加验证脚本层
|
||||
```
|
||||
L1 机械检查 + 验证脚本
|
||||
├── 文件存在性检查（原有）
|
||||
├── JSON 格式检查（原有）
|
||||
└── 🆕 verification_commands 执行（新增）
|
||||
├── 任务 Plan 中声明的验证命令（如 pytest, flake8, mypy）
|
||||
├── 命令 exit 0 = 通过，非 0 = 打回
|
||||
└── stdout/stderr 附在打回原因中
|
||||
```
|
||||
|
||||
**黑板 Schema 变更**：tasks 表新增 `verification_commands` JSON 字段
|
||||
```json
|
||||
{
|
||||
"verification_commands": [
|
||||
{"cmd": "pytest tests/test_foo.py -x", "description": "单元测试必须通过"},
|
||||
{"cmd": "flake8 src/", "description": "代码规范检查"}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**触发时机**：Daemon 检测到 output 写入 → 执行 Guardrail → L1 验证脚本 → 脚本失败则自动打回。
|
||||
|
||||
> 参考实践：Aider 的 lint→test→commit 是原子操作——验证不通过就不 commit。我们的 Guardrail 也是原子门控——验证不通过就不进入 review。
|
||||
|
||||
#### 借鉴2：对抗性审计映射（纳入课题3）
|
||||
|
||||
**来源**: claude-goal 三种审计模式（none/adversarial/double）
|
||||
|
||||
**映射到 Guardrail L1/L2/L3**：
|
||||
|
||||
| claude-goal 模式 | moziplus Guardrail | 触发条件 | 行为 |
|
||||
|-----------------|-------------------|---------|------|
|
||||
| none（跳过审计） | L1 only（机械+脚本） | low 风险任务 | 自动检查通过即完成 |
|
||||
| adversarial（对抗审计） | L1 + L2（AI审查） | standard 风险任务 | 一轮 AI 审查，通过/打回 |
|
||||
| double（双重审计） | L1 + L2 + 反驳权 | high 风险任务 | 双轮审查 + 执行者可反驳 + 最多5轮 |
|
||||
|
||||
> claude-goal 的完成审计 6 步流程（还原交付物→对照表→检查证据→找缺失→继续/完成）对 Output Guard 的 AI 审查层有参考价值，但不硬编码步骤——AI 审查者按 Skill 指导灵活执行。
|
||||
|
||||
#### 借鉴3：防偏离改进（纳入课题3+4）
|
||||
|
||||
**来源**: claude-goal Stop Hook + 完成审计
|
||||
|
||||
**v2.0 的防偏离三层防线**：
|
||||
|
||||
| 防线 | claude-goal 机制 | moziplus v2.0 对应 | 实现方式 |
|
||||
|------|-----------------|-------------------|---------|
|
||||
| 每轮重新注入目标 | Stop Hook 注入 `<objective>` | L2 引擎注入任务上下文 | Daemon spawn 时注入 truths + acceptance_criteria |
|
||||
| 不信任 Agent 自述 | 完成审计 6 步（查证据） | Output Guard + Scope Guard | L1 验证脚本 + L2 AI 审查（prompt→artifact 对照） |
|
||||
| Runaway Guard | 500 次续杯上限 | ❌ 当前缺失 | 新增：每个任务最大 tick 上限（配置项 `max_ticks`，默认 100） |
|
||||
|
||||
**新增设计**：tasks 表增加 `max_ticks` 字段（默认 100）。Daemon 每次 tick 处理某任务时递增 `tick_count`，超过 `max_ticks` 时：
|
||||
1. 自动暂停任务
|
||||
2. 写入 system observation：“任务超过最大 tick 上限，可能陷入循环”
|
||||
3. 通知用户决定继续/取消
|
||||
|
||||
#### 借鉴4：双重 Hook 机制（纳入 Daemon 设计）
|
||||
|
||||
**来源**: claude-goal 的 Claude Code Stop Hook + mozi v1 的 HookRegistry
|
||||
|
||||
**v2.0 双重 Hook 架构**：
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Layer 1: OpenClaw Hook（系统级） │
|
||||
│ • Heartbeat（定时轮询，读 HEARTBEAT.md） │
|
||||
│ • Webhook（HTTP 入口，外部事件触发） │
|
||||
│ • Cron（定时任务） │
|
||||
│ → 触发 Agent session 内行为 │
|
||||
└─────────────────────────────────────────┘
|
||||
↓ 事件到达
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Layer 2: moziplus Hook（编排级） │
|
||||
│ • NODE_AFTER_EXECUTE → 触发 Guardrail │
|
||||
│ • NODE_ON_SUCCESS → 触发经验沉淀 │
|
||||
│ • TASK_AFTER_COMPLETE → 触发 Scope Guard │
|
||||
│ • CONCLUSION_AFTER_PARSE → 写入黑板 │
|
||||
│ → 触发编排层业务逻辑 │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**mozi v1 已有 HookRegistry**（20 个 hook 点，覆盖任务/节点/结论/路由全生命周期），v2.0 继承并精简：
|
||||
- v1 的 HookPoint 枚举 → v2 的 Daemon event handler
|
||||
- v1 的 priority + stop_propagation → v2 保留（Hook 链可控）
|
||||
- v1 的两级失败隔离（关键型暂停/辅助型跳过）→ v2 保留
|
||||
- 新增：Guardrail 验证脚本作为 NODE_AFTER_EXECUTE 的默认 Hook
|
||||
|
||||
**与 claude-goal 的对比**：
|
||||
| 维度 | claude-goal | moziplus v2.0 |
|
||||
|------|-----------|-------------|
|
||||
| Hook 注册位置 | Claude Code settings.json | Daemon HookRegistry |
|
||||
| Hook 触发点 | Agent Stop 事件 | 节点完成/任务完成/产出写入 |
|
||||
| Hook 实现 | Python 脚本 | Daemon event handler + 可插拔 Hook |
|
||||
| 防偏离手段 | 拦截停止+注入目标 | L2注入上下文+Guardrail验证+Runaway Guard |
|
||||
|
||||
#### 借鉴5：Shadow Checkpoint（纳入课题6 经验沉淀）
|
||||
|
||||
**来源**: Cline Shadow Git Checkpoint
|
||||
|
||||
**设计**：每次 Agent 产出写入黑板时，Daemon 自动对产出目录做 git commit（带 agent_id + task_id + timestamp tag）。
|
||||
|
||||
- **与课题4的关系**：不依赖课题4。Shadow Checkpoint 是 Daemon 层行为（产出写入后触发），课题4是 Agent spawn 时的上下文注入。两者独立。
|
||||
- **与课题6的关系**：Shadow Checkpoint 的变更历史是经验蒸馏的输入（课题6 DISCOVER 阶段可以 diff 两个 checkpoint 看Agent改了什么）
|
||||
- **回滚能力**：用户可以在 Dashboard 上选择任意 checkpoint 一键回滚
|
||||
- **存储开销**：git commit 增量存储，开销可控
|
||||
|
||||
**实现**：在 `NODE_AFTER_EXECUTE` Hook 中增加 git checkpoint 逻辑。
|
||||
|
||||
### 15.2 经评估暂不纳入的借鉴点
|
||||
|
||||
#### Blackboard Map（按需触发，不预设）
|
||||
|
||||
**来源**: Aider Repo Map
|
||||
|
||||
**结论**：当前单个任务黑板信息 ~1000-1500 tokens（§11.1 测算），10 个任务全量注入 ~1-1.5 万 tokens，远小于 128K。**现阶段不需要 Blackboard Map**。
|
||||
|
||||
**触发条件**（达到以下任一时启动设计）：
|
||||
- 单个任务黑板信息超过 5000 tokens
|
||||
- 并行任务数超过 15 个
|
||||
- Agent spawn 时注入上下文超过 10K tokens
|
||||
- 或者 L2 注入需要做精准裁剪（只取关联子图而非全量）
|
||||
|
||||
**预留设计**：当需要时，基于黑板 comments/outputs/decisions 的拓扑关系构建图索引，Agent 按任务 ID 只读关联子图。
|
||||
|
||||
### 15.3 技术选型更新
|
||||
|
||||
| 需求 | 原参考 | 新增参考 | 我们的方案 |
|
||||
|------|--------|---------|----------|
|
||||
| 质量门控 | Hermes 幻觉门控 | Aider lint→test→commit | L1 机械+脚本 → L2 AI → L3 红线 |
|
||||
| 防偏离 | 无 | claude-goal Stop Hook + 完成审计 | L2 注入 + Guardrail + Runaway Guard |
|
||||
| 产出追溯 | 无 | Cline Shadow Git | NODE_AFTER_EXECUTE Hook 自动 git commit |
|
||||
| Hook 机制 | mozi v1 HookRegistry | claude-goal Stop Hook + OpenClaw Heartbeat/Webhook | 双重 Hook（系统级+编排级） |
|
||||
| 多项目隔离 | 无 | Superset Worktree | 课题11 中设计（Worktree 物理隔离） |
|
||||
|
||||
Reference in New Issue
Block a user