auto-sync: 2026-05-14 14:50:11
This commit is contained in:
cfdaily
@@ -2211,18 +2211,144 @@ Agent 执行过程中的关键决策点用 severity=audit 记录：
|
||||
- 发现了什么
|
||||
audit 级别不通知庞统，只记录在文件系统供事后审查。
|
||||
|
||||
#### 3.12.11 Agent 调度方式（v2.5 确认）
|
||||
#### 3.12.11 Agent 调度方式（v2.6 终版确认）
|
||||
|
||||
**实验结论**（2026-05-14 spawn 实验）：
|
||||
- `sessions_spawn` 只能 spawn 自己的 sub-agent，不能指定 guanyu-dev 等其他 agentId
|
||||
- 因此 spawn 用于庞统内部的复杂分析，不能替代调度将军
|
||||
**实验结论**（2026-05-14 两轮 spawn 实验）：
|
||||
- `sessions_spawn` 配置 `allowAgents: ["*"]` 后可以指定其他 agentId
|
||||
- 跨 Agent spawn 读写文件、结论回传、cleanup:delete 全部正常
|
||||
- **spawn 是 v2.0 调度将军的首选方式**
|
||||
|
||||
**v2.0 双模式调度**：
|
||||
**Gateway 配置**（已应用）：
|
||||
```json
|
||||
// ~/.openclaw/openclaw.json → agents.list[id=pangtong-fujunshi]
|
||||
{ "subagents": { "allowAgents": ["*"] } }
|
||||
```
|
||||
|
||||
| 方式 | 用途 | 特点 |
|
||||
|------|------|------|
|
||||
| `openclaw agent --agent xxx` | 调度将军执行步骤 | 一次性 CLI，执行完进程结束 |
|
||||
| `sessions_spawn` (cleanup:delete) | 庞统内部复杂分析 | 子 session 完成后自动清理 + 结论回传 |
|
||||
**v2.0 调度方式（按优先级排序）**：
|
||||
|
||||
| 优先级 | 方式 | 用途 | 特点 |
|
||||
|--------|------|------|------|
|
||||
| **首选** | `sessions_spawn(agentId="xxx", cleanup="delete")` | 调度将军执行步骤 | 不走 Gateway、并行、自动清理、结论回传 |
|
||||
| Fallback | `openclaw agent --agent xxx --local --json` | spawn 不可用时 | `--local` 本地运行，自动 fallback |
|
||||
| 内部 | `sessions_spawn()` (无 agentId) | 庞统内部复杂分析 | 子 session 继承上下文 |
|
||||
|
||||
**spawn 的关键优势**（vs `openclaw agent` CLI）：
|
||||
- 不依赖 Gateway（Gateway 挂了也能调度）
|
||||
- 庞统可以通过 `subagents list` 实时监控子 session 状态
|
||||
- 完成后自动回传结果，不需要轮询
|
||||
- 支持嵌套调度（`maxSpawnDepth: 2`）
|
||||
- 支持并行（`maxConcurrent: 8`）
|
||||
|
||||
#### 3.12.12 庞统上下文管理（v2.6 新增）
|
||||
|
||||
> **核心问题**：庞统在一个 session 里处理多个任务时，上下文会膨胀。如果“每次唤醒全新视角”，
|
||||
> 之前的推理过程丢失，决策质量下降。如果保留全部上下文，token 爆炸。
|
||||
> **必须找到平衡**。
|
||||
|
||||
**调研来源**：
|
||||
- **get-shit-done**：Wave Execution——每个 plan 用独立新鲜上下文，避免 context rot
|
||||
- **Claude Code**：session linked by parent_session_id + auxiliary-LLM compression
|
||||
- **学术：Episodic Memory**（arXiv:2502.06975）：episodic memory 是长期 Agent 的缺失拼图
|
||||
- **学术：Memory as Action**（arXiv:2509.25250）：自主上下文策展
|
||||
|
||||
**方案：三层上下文架构**
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────┐
|
||||
│ L1: 永久记忆（跨任务保留） │
|
||||
│ MEMORY.md + 经验库 + Skill 体系 │
|
||||
│ 每次启动自动注入，不受上下文窗口限制 │
|
||||
└───────────────────────────────────────────┘
|
||||
|
||||
┌───────────────────────────────────────────┐
|
||||
│ L2: 任务工作记忆（单任务内保留） │
|
||||
│ decisions.jsonl + moments.jsonl + status.json │
|
||||
│ 存文件系统，庞统被唤醒时 read 获取 │
|
||||
│ → 这就是“上下文恢复协议”的实质 │
|
||||
└───────────────────────────────────────────┘
|
||||
|
||||
┌───────────────────────────────────────────┐
|
||||
│ L3: 推理上下文（每次唤醒重建） │
|
||||
│ 当前推理过程，对话历史中的近期部分 │
|
||||
│ 通过 OpenClaw compaction 自动管理 │
|
||||
└───────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**具体机制**：
|
||||
|
||||
1. **庞统被唤醒时**：
|
||||
- read `status.json`（当前全局状态）
|
||||
- read `decisions.jsonl`（之前做过的决策及理由）
|
||||
- read `moments.jsonl`（最近 10 条事件）
|
||||
- 这三步重建 L2 工作记忆
|
||||
|
||||
2. **庞统做决策时**：
|
||||
- 关键决策写入 `decisions.jsonl`（不只在对话历史里）
|
||||
- 格式：`{decision, reason, alternatives_rejected, timestamp}`
|
||||
- 下次被唤醒时能看到自己之前为什么做这个决策
|
||||
|
||||
3. **防止“忘了”的兜底**：
|
||||
- 每个 observation 写入时，daemon 同时记录到 `moments.jsonl`
|
||||
- 庞统被唤醒时看到的 moments 包含所有 Agent 的 observation 摘要
|
||||
- 即使庞统“忘了”对话中的推理，通过文件系统能找回来
|
||||
|
||||
4. **并行步骤完成后的识别**：
|
||||
- 两个并行步骤都完成后，daemon 生成一个“并行步骤关联分析”
|
||||
- 检查两个步骤的 observation 是否有关联
|
||||
- 如果有关联，写入 moments 并通知庞统
|
||||
- 庞统不需要“记住”并行步骤的关系——文件系统替他记着
|
||||
|
||||
**与之前“全新视角”方案的区别**：
|
||||
- 之前：每次唤醒清空一切，只看 status.json
|
||||
- 现在：每次唤醒有 L1（永久）+ L2（文件系统工作记忆）+ L3（对话上下文）
|
||||
- L2 是关键创新——决策理由和 observation 摘要存在文件里，不依赖对话历史
|
||||
|
||||
#### 3.12.13 防降级机制（v2.6 新增）
|
||||
|
||||
> **核心问题**：调度策略本身如何防止在执行过程中逐渐妥协？
|
||||
> 庞统如何保证不为了“完成任务”而降级目标？
|
||||
|
||||
**四个防降级机制**：
|
||||
|
||||
**机制 1：反合理化表（Anti-Rationalization Table）**
|
||||
|
||||
来源：Agent Skills 生命周期实践
|
||||
|
||||
写入 orchestration-strategy Skill 的 L3（反模式）层：
|
||||
|
||||
```
|
||||
庞统自检清单——每个调度决策前必须过：
|
||||
❌ “这个步骤简化一下” → 问：PRD 目标是否被覆盖？
|
||||
❌ “时间不够跳过验证” → 没有验证的产出不算完成
|
||||
❌ “这个Agent做不到就算了” → 换 Agent 或拆步骤
|
||||
❌ “先用简单方案后续优化” → v2.0 就是完整实现
|
||||
❌ “用户应该不在意” → 你的判断 ≠ 用户需求
|
||||
```
|
||||
|
||||
**机制 2：目标锚定（Goal Anchoring）**
|
||||
|
||||
每个任务的原始 goal 和 PRD 需求写入 `context.json`，不可修改。
|
||||
庞统每次做调度决策时必须对照 goal：
|
||||
- 决策是否更接近 goal？
|
||||
- 如果偏离 goal，必须升级到用户，不能自行降级
|
||||
|
||||
**机制 3：范围缩减检测（Scope Reduction Detection）**
|
||||
|
||||
来源：get-shit-done 实践
|
||||
|
||||
planner.py 在 Phase 2 生成计划时，每个步骤必须标注覆盖哪些需求。
|
||||
daemon 在执行完所有步骤后，反向检查：每个需求是否被至少一个步骤覆盖。
|
||||
如果有遗漏，不允许进入 Phase 4，必须 replan。
|
||||
|
||||
**机制 4：验证前不完成（Verification-Before-Completion）**
|
||||
|
||||
来源：superpowers 实践
|
||||
|
||||
Agent 声称完成时，validator.py 检查：
|
||||
1. 产出物文件存在且非空
|
||||
2. 产出物与 end_state 描述匹配（AI 语义检查）
|
||||
3. 没有未处理的 blocking observation
|
||||
任何一项不通过，步骤状态不变为 completed。
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user