🎉 init: 小龙的工作空间
This commit is contained in:
大海
@@ -0,0 +1,97 @@
|
||||
# Playbook: Agent Evolution Task
|
||||
|
||||
> 适用: 深度学习外部项目 → 提取能力 → 增强自身
|
||||
> 来源: 2026-06-03 Agent Evolution Mode 实战
|
||||
> 结果: 5h 完成预估 42.5h 的工作
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: 源码分析 (并行)
|
||||
|
||||
### Step 1: Clone 源码
|
||||
```bash
|
||||
mkdir -p repos/ && cd repos/
|
||||
git clone <repo_url>
|
||||
```
|
||||
|
||||
### Step 2: 并行分析
|
||||
对每个项目 spawn 子 agent:
|
||||
```
|
||||
任务: 深度分析项目 X
|
||||
分析维度 (10 + 9 = 19 项):
|
||||
项目分析: 解决的问题/架构图/模块/数据流/Prompt/Agent/Memory/Context/Tool/可迁移
|
||||
源码分析: 核心算法/Agent Loop/MCP/Tool Routing/Context/Memory/Planning/Reflection/Self-correction
|
||||
输出: repos/analysis/X-analysis.md
|
||||
```
|
||||
|
||||
### Step 3: 检查分析质量
|
||||
每个分析文件应 ≥ 500 行，包含代码引用（文件路径+行号）
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: 方案设计
|
||||
|
||||
### Step 4: 能力矩阵
|
||||
```
|
||||
当前能力 ← 完整度评估 (✅✅⚠️⚠️❌❌❌)
|
||||
缺失能力 ← 三个项目谁补充
|
||||
```
|
||||
|
||||
### Step 5: 架构设计
|
||||
```
|
||||
融合后架构图 (ASCII art)
|
||||
优先级排序 (投入产出比 × 风险 × 缺失度)
|
||||
MVP 定义 (最小可验证单元)
|
||||
```
|
||||
|
||||
### Step 6: 代码修改计划
|
||||
```
|
||||
Phase 0/1/2/3/4 每个阶段的文件清单 + 预估工时
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: 分阶段实现
|
||||
|
||||
### Step 7: P0 MVP (先上线)
|
||||
- 选 2-3 个"不改架构就能用"的能力
|
||||
- 每个模块写完立即 `node module.js` 测试
|
||||
- 目标: 1-3h 出第一个可用的版本
|
||||
|
||||
### Step 8: 按 Phase 递进
|
||||
- 每完成一个 Phase → 全量集成测试
|
||||
- 发现模式 → 写入 patterns/
|
||||
- 发现反模式 → 写入 reflections/
|
||||
|
||||
### Step 9: Skill 化
|
||||
- 每个能力模块 → 一个 Skill 文件
|
||||
- Skill 包含: When/How/Commands/Integration Pattern
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: 反思与沉淀
|
||||
|
||||
### Step 10: 记录反思
|
||||
```
|
||||
成功经验 × 5 项
|
||||
失败经验 × 4 项
|
||||
设计模式 × N 项
|
||||
下次改进 × 3 项
|
||||
```
|
||||
|
||||
### Step 11: 提取模式
|
||||
每个可复用模式: 问题/方案/适用场景/反模式
|
||||
|
||||
### Step 12: 更新记忆
|
||||
在 memory/daily/ 写入今日总结
|
||||
|
||||
---
|
||||
|
||||
## 关键决策点
|
||||
|
||||
| 决策 | 建议 |
|
||||
|------|------|
|
||||
| 用 sub-agent 并行分析 | ✅ 3 个项目同时跑，2-3 分钟完成 |
|
||||
| 遇到不兼容的依赖 | 自写替代，不换依赖 |
|
||||
| 实现顺序 | 低风险高价值先做 (P0)，架构改动大的后做 (P3) |
|
||||
| 测试策略 | 每个模块写完即测，不等全部写完 |
|
||||
@@ -0,0 +1,101 @@
|
||||
# 记忆系统审计 Playbook
|
||||
|
||||
> 可复用操作手册。当需要全量检查记忆系统健康状态时按此流程执行。
|
||||
|
||||
## 触发条件
|
||||
|
||||
- 每 2 周例行审计
|
||||
- 记忆搜索异常时
|
||||
- 发现 git 未推送时
|
||||
- MEMORY.md 或 vault.md 超过阈值时
|
||||
|
||||
## Phase 1: 数据收集 (Collect)
|
||||
|
||||
### 1.1 文件系统
|
||||
```bash
|
||||
find memory -type f -name '*.md' | sort
|
||||
du -sh memory/
|
||||
find memory -type f -name '*.md' -exec ls -lt {} + | head -15
|
||||
```
|
||||
|
||||
### 1.2 Git 状态
|
||||
```bash
|
||||
git remote -v
|
||||
git status --short
|
||||
git log --oneline -5
|
||||
```
|
||||
|
||||
### 1.3 远程同步
|
||||
```bash
|
||||
curl -s --max-time 5 http://111.229.145.18/api/v2/stats
|
||||
bash scripts/memory-sync.sh check
|
||||
```
|
||||
|
||||
### 1.4 自动化
|
||||
```bash
|
||||
# 检查 cron 列表 (通过 cron tool)
|
||||
# 验证 dream-cycle 上次运行
|
||||
cat memory/.dream-cycle-last-run
|
||||
```
|
||||
|
||||
## Phase 2: 诊断 (Diagnose)
|
||||
|
||||
### 2.1 版本控制
|
||||
- [ ] git remote 是否存在？
|
||||
- [ ] .gitignore 是否存在？
|
||||
- [ ] 最后一次 push 是否在 24h 内？
|
||||
|
||||
### 2.2 索引时效
|
||||
- [ ] `grep -c '^- ' memory/index.md` vs 实际文件数
|
||||
- [ ] index.md 是否遗漏 project/daily？
|
||||
|
||||
### 2.3 文件健康
|
||||
- [ ] MEMORY.md 是否 < 200 行？
|
||||
- [ ] vault.md 是否 < 200 行？
|
||||
- [ ] daily/ 是否有连续空缺 > 1 天？
|
||||
|
||||
### 2.4 寄存器健康
|
||||
- [ ] _index.md 引用与实际文件一致？
|
||||
- [ ] 是否有被引用但未创建的文件？
|
||||
|
||||
### 2.5 去重检查
|
||||
```python
|
||||
# 交叉分析 vault.md 决策 vs registers/ 内容
|
||||
keywords = ['工具','服务','配置','偏好','规则']
|
||||
# 同一条信息不应同时出现在两个寄存器中
|
||||
```
|
||||
|
||||
## Phase 3: 修复 (Fix)
|
||||
|
||||
### 分级策略
|
||||
| 级别 | 标准 | 示例 |
|
||||
|------|------|------|
|
||||
| P0 🔴 | 数据可能丢失、自动化断链 | 无 git remote、cron 缺失 |
|
||||
| P1 🟡 | 影响效率、信息不一致 | 索引过时、vault 超限 |
|
||||
| P2 🟢 | 预防性改进 | 去重检查、演化目录充实 |
|
||||
|
||||
### 修复后验证
|
||||
```bash
|
||||
bash scripts/memory-sync.sh check
|
||||
bash scripts/memory-sync.sh index
|
||||
git push origin main
|
||||
```
|
||||
|
||||
## Phase 4: 沉淀 (Internalize)
|
||||
|
||||
1. 写 reflection → `reflections/YYYY-MM-DD-memory-audit.md`
|
||||
2. 更新本 playbook（如有新发现）
|
||||
3. 更新 companion-log（如有伙伴参与）
|
||||
4. 记录到今天的 daily/
|
||||
|
||||
## 快速健康评分公式
|
||||
|
||||
```
|
||||
f = 最近 daily 日期距离今天的天数
|
||||
c = registers/ 更新率 (30天内更新数/总数)
|
||||
e = vault.md 行数 (>200行扣分)
|
||||
r = git push 24h内? (是=100, 否=0)
|
||||
s = 远程服务器在线? (是=100, 否=0)
|
||||
|
||||
health = f*25 + c*25 + e*20 + r*15 + s*15
|
||||
```
|
||||
@@ -0,0 +1,111 @@
|
||||
# Tool Call Strategy — 工具选择与组合
|
||||
|
||||
> 来源: Agent Evolution 实战验证
|
||||
> 每次发现新的有效工具组合时追加
|
||||
|
||||
---
|
||||
|
||||
## 策略 1: 大任务并行化
|
||||
|
||||
**场景**: 多个独立子任务，需要加速
|
||||
|
||||
**组合**: `sessions_spawn` (并行) → `sessions_yield` (等待) → 合并结果
|
||||
|
||||
**示例**:
|
||||
```
|
||||
sessions_spawn(taskName="analyze-ecc", task="深度分析 ECC")
|
||||
sessions_spawn(taskName="analyze-headroom", task="深度分析 headroom")
|
||||
sessions_spawn(taskName="analyze-codegraph", task="深度分析 codegraph")
|
||||
sessions_yield() // 等待全部完成
|
||||
// 合并三个分析文件
|
||||
```
|
||||
|
||||
**关键参数**:
|
||||
- `mode: "run"` — 一次性后台任务
|
||||
- `runTimeoutSeconds: 600` — 大任务 10 分钟超时
|
||||
- `context: "isolated"` — 子 agent 不需要父上下文（省 token）
|
||||
|
||||
**经验**: 3 个项目并行 vs 串行，从 8 分钟降到 2.5 分钟
|
||||
|
||||
---
|
||||
|
||||
## 策略 2: 多轮对话式编码
|
||||
|
||||
**场景**: 需要逐步构建复杂模块
|
||||
|
||||
**组合**: 先独立测试 → 再集成
|
||||
|
||||
**示例**:
|
||||
```
|
||||
1. write detector.js → node detector.js < test.txt → 确认输出
|
||||
2. write smart-crusher.js → node smart-crusher.js < data.json → 确认输出
|
||||
3. write ctx-compress.js → cat data | node ctx-compress.js → 确认全链路
|
||||
```
|
||||
|
||||
**反模式**: 全部写完再测 → 一个 bug 要回溯到多个文件
|
||||
|
||||
---
|
||||
|
||||
## 策略 3: 安全门控链
|
||||
|
||||
**场景**: 执行可能有风险的操作
|
||||
|
||||
**组合**: `risk-scorer` → `permission-gate` → `budget-tracker` → `audit-log`
|
||||
|
||||
```
|
||||
Input: tool_name, command
|
||||
→ ctx_execute("node src/security/risk-scorer.js '...input...'")
|
||||
→ if REVIEW: show risk factors
|
||||
→ if CONFIRM: ask user
|
||||
→ if BLOCK: refuse
|
||||
→ if ALLOW:
|
||||
→ preCheck budget
|
||||
→ execute
|
||||
→ postRecord (audit log + budget usage)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 策略 4: 压缩优先
|
||||
|
||||
**场景**: 工具输出可能在 500+ 字符
|
||||
|
||||
**组合**: `exec` → `ctx_compress` → 读压缩版本 → 需要时 `ctx_compress --retrieve`
|
||||
|
||||
```
|
||||
大输出 → ctx_compress --json → { compressed, savings%, ccrHash }
|
||||
→ 99% 情况下压缩版本就够了
|
||||
→ 需要原始数据时: ctx_compress --retrieve <hash>
|
||||
```
|
||||
|
||||
**经验**: 压缩版 99.1% 节省 build log，完全够定位问题
|
||||
|
||||
---
|
||||
|
||||
## 策略 5: CodeGraph 优先
|
||||
|
||||
**场景**: 代码搜索/理解
|
||||
|
||||
**组合**: `codegraph search` 优先于 `grep/find`
|
||||
|
||||
```
|
||||
1. codegraph search "symbol_name" → 结构化结果 (kind + file + line)
|
||||
2. 不够 → codegraph callers "symbol" → 调用关系
|
||||
3. 还不够 → codegraph impact "symbol" → BFS 影响范围
|
||||
4. 最后手段 → grep/read
|
||||
```
|
||||
|
||||
**经验**: CodeGraph 比 grep 少 58% 工具调用（项目 README benchmark）
|
||||
|
||||
---
|
||||
|
||||
## 策略 6: 减少工具调用
|
||||
|
||||
**场景**: Agent 倾向于逐个文件 grep → 大量工具调用
|
||||
|
||||
**替代方案**:
|
||||
- 「找所有 X」: `codegraph search X --limit 20` 替代 20 次 grep
|
||||
- 「读大文件」: `ctx_compress` 替代 read 整个文件
|
||||
- 「批量命令」: `ctx_batch_execute` 替代 5+ 个独立 exec
|
||||
|
||||
**关键指标**: 工具调用次数 > 必要次数 → 有优化空间
|
||||
Reference in New Issue
Block a user