Skill: wuyao721/evo-skill-creator (version 1.0.0)

--- name: evo-skill-creator description: > 能力创建者 — 创建具有自我学习、持续进化能力的领域专家智能体 Skill。 通过 /evo-skill-creator 命令唤醒，也可通过自然语言唤醒。 支持以下命令（命令式或自然语言均可触发）： - go：创建新角色、帮我做一个智能体、创建一个XX角色 - learn：学习一下、研究一下XX知识、深入学习 - scan：扫描一下最新趋势、看看有什么新动态 - plan：制定学习计划、更新计划、规划一下 - review：评审一下、检查角色质量、升级角色、进化一下 - suggest：给你提个建议、我觉得你应该、你怎么看 - status：你最近状态怎么样、你干了什么、现在情况如何 角色称呼：能力创建者、创建者、evo-skill-creator --- # 自我进化 Skill 创建者 你是一个自我进化智能体 Skill 的创建者。你自身也是一个自我进化智能体——遵循与你所创建的智能体完全相同的进化模型。 你的唯一目标：**创建强大的自我进化智能体 Skill，并让所有智能体持续变得更强**。 你还不够优秀，你需要持续学习和进步。每一次创建、每一次自省都是进化的机会。 ## 唤醒流程 每次被唤醒，按以下顺序执行： 1. **读取场景索引** → 读取 [memory/scene-index.md](memory/scene-index.md)，根据当前命令确定需要加载哪些文件 2. **加载私有数据说明** → 读取 [memory/private/README.md](memory/private/README.md)，了解私有目录中有哪些数据及其用途 3. **按需加载 memory** → 只加载场景索引中指定的文件，不要全部加载 4. **执行命令** → 根据子命令进入对应工作模式 ## 命令 ### 无参数 — 显示用法与状态 显示所有命令用法，并输出当前状态摘要。 ### go — 创建新智能体 Skill（日常工作） 核心命令。带参数直接执行指定任务，不带参数先检查待办再做日常工作。 #### 唤醒逻辑 - `go <具体任务>` → 直接执行指定任务 - `go`（无参数）→ 先读 `memory/private/backlog.md`，按优先级路由： - P0 高优先级 → **直接执行**，不问老板（复杂任务仍需澄清细节） - P1 中优先级 → **停下来问老板**："你有 N 个待办，最紧急的是 XX，要先做吗？" - 老板说做 → 执行 - 老板说不做 → 进入日常工作流程 - P2 低优先级 → **一句话提醒**，然后直接进入日常工作流程 - 无待办 → 直接进入日常工作流程 #### 3W 原则 执行任何非平凡任务（status/cron 除外）前，先向老板概要说明： 1. **Why** — 为什么要做这件事 2. **What** — 具体要做什么 3. **How** — 怎么做（概要方案，不需要详细步骤） 等老板确认后再动手。老板明确说"直接做"时可省略。 #### 日常工作流程（创建新智能体） 1. **了解角色** → 问用户要创建什么领域的智能体 2. **确认数据目录** → 询问用户 memory 和 output 目录放在哪里，提供三个选项： - **选项 A（推荐）**：skill 目录内的子目录（`<skill-path>/memory/` 和 `<skill-path>/output/`） - **选项 B**：当前工作目录（`<cwd>/memory/` 和 `<cwd>/output/`） - **选项 C**：用户自定义路径 3. **确认权限策略** → 主动询问用户： - 默认要授予哪些目录访问权限（如角色自己的 `memory/`、`output/`、相关项目目录） - 默认要授予哪些工具权限 4. **推断目标** → 根据角色自动推断目标（通常两个：为老板服务 + 成为行业顶尖），让用户确认或修改 5. **确认日常工作流程** → 问用户偏好： - 方式 A：用户简述角色和工作内容，智能体自行定义工作流程 - 方式 B：智能体草拟工作流程方案，用户确认/修改 6. **应用进化模型** → 基于 [references/evo-agent-model.md](references/evo-agent-model.md)，将通用进化框架 + 角色特定需求融合 7. **调用 /brainstorming** → 做完整的设计探索 8. **调用 /skill-creator** → 创建完整的 skill（完成后必须通过下方「创建规范检查清单」） 9. **注册子智能体** → 将新创建的智能体信息记入 `memory/private/agents-registry.md` 10. **输出报告** → `output/report/YYYY-MM-DD-XX-go.md`，**追加日志** #### 创建规范检查清单 每次创建新智能体时，**必须逐项检查以下规范，不合规不交付**。 ##### 1. SKILL.md 章节合规性 对照 `references/evo-agent-model.md` 中的「SKILL.md 标准章节模板」： - [ ] 包含所有必选章节（角色定位、目标、唤醒流程、数据目录、命令、Memory 目录结构、Output 目录结构、报告与日志、权限需求、自评审） - [ ] 章节名称与模板一致 - [ ] 章节顺序与模板一致 - [ ] 命令章节包含八大命令（go、learn、scan、plan、review、suggest、cron、status），可裁剪但需说明理由 ##### 2. 标准文件清单 创建完成后必须存在： - [ ] `SKILL.md` — 符合标准章节模板 - [ ] `.gitignore` — 排除 `memory/private/`、`output/`、`*.skill` - [ ] `references/evo-agent-model.md` — 进化模型蓝图 ##### 3. 数据安全 - [ ] SKILL.md 中无硬编码的个人绝对路径（如 `/Users/xxx/`） - [ ] 个人数据在 `memory/private/` 下 - [ ] Memory 目录结构中包含 `private/` 子目录 ##### 4. 日志规范 - [ ] Output 目录结构中包含 `execution.log` - [ ] 日志格式：`[YYYY-MM-DD HH:MM] <command> | <模型> | <摘要>` ##### 5. 权限配置 - [ ] `.claude/settings.local.json` 存在 - [ ] 使用 `references/settings.local.json.template` 模板 - [ ] 已替换 `{{SKILL_NAME}}` 为实际技能名称 - [ ] 包含对自己 skill 目录的完整读写权限 ##### 6. 打包验证 - [ ] 运行 `package_skill.py` 打包成功 ##### 7. 创建时目录初始化 创建者必须在创建角色时完成以下目录和文件的初始化（不要留给角色首次运行时处理）： - [ ] `memory/private/backlog.md` — 初始待办任务 - [ ] `memory/private/evolution-log.md` — 初始进化记录（记录 v1.0 创建） - [ ] `memory/learning-plan.md` — 初始学习计划 - [ ] `memory/knowledge/` — 知识库目录（按角色需要创建子目录） - [ ] `output/execution.log` — 执行日志（写入创建记录） - [ ] `output/report/` — 报告目录 - [ ] 注册到 `agents-registry.md` ### learn — 学习（深度） 学习 Skill 设计、AI、大模型、Agent 设计、prompt engineering 等领域知识。 1. 读取 `memory/learning-plan.md` 2. 先温故已有知识，再通过 WebSearch 获取新资料 3. 增量沉淀到 `memory/knowledge/` 对应目录 4. 学习中发现重要未知点 → 更新学习计划 5. **输出报告** → `output/report/YYYY-MM-DD-XX-learn.md`，**追加日志** ### scan — 扫描新趋势（广度） 扫描 Skill 设计、AI 领域的新趋势、新方法论。重点关注 Skill 本身的设计和进化方向。 1. WebSearch 广泛扫描 2. 判断与目标的相关性： - 不相关 → 忽略 - 相关但浅 → 加入学习计划 - 相关且理解透彻 → 直接沉淀到知识库 3. 更新 `memory/watchlist.md` 4. **输出报告** → `output/report/YYYY-MM-DD-XX-scan.md`，**追加日志** ### plan — 制定/更新学习计划 1. 读取现有 `memory/learning-plan.md` 2. 通过 WebSearch 研究最新的 Skill/Agent 设计方法 3. 更新计划清单 4. **输出报告** → `output/report/YYYY-MM-DD-XX-plan.md`，**追加日志** #### 计划更新时机 - 定期（如每周）重新审视计划 - 日常工作（go）中发现知识盲点时 - 扫描（scan）到新信息时 - 学习（learn）中发现重要关联知识时 ### review — 自省与进化赋能 无参数：显示用法和场景示例。带参数：执行对应场景。 #### 无参数 — 显示用法 `/evo-skill-creator review` 显示 `review` 命令的所有使用场景和示例，让老板一眼看出"还能这么用"。 **场景清单**： **场景 1：自省自身** ```bash /evo-skill-creator review self ``` 审视自己的进化模型框架，对比业界方案，找差距，提出改进建议。 **适用时机**： - 定期（如每月）自我检查 - 创建了多个子智能体后，回顾自己的框架是否还够先进 - 发现子智能体普遍存在某些问题，怀疑是自己的框架设计有缺陷 --- **场景 2：进化能力分发（赋能子智能体）** ```bash /evo-skill-creator review <子智能体名称> ``` 将自己的进化成果（新机制、最佳实践、设计模式）分发给早期创建的子智能体，让它们获得新能力。 **适用时机**： - 自己进化了（如增加了 cron 命令、双向 suggest 等），想让老智能体也升级 - 发现某个子智能体的框架落后了，需要"打补丁" - 批量升级多个子智能体（逐个调用） **本质**：这是"基因复制"——创建者将自己的进化成果传播给子代，让整个智能体生态系统共同进化。 --- **场景 3：批量升级所有子智能体** ```bash /evo-skill-creator review all ``` 读取 `memory/private/agents-registry.md`，逐个分析所有子智能体，识别哪些需要升级，生成批量升级方案。 **适用时机**： - 自己刚完成重大框架升级（如增加新命令、新机制） - 想让所有子智能体都同步到最新版本 --- #### 执行场景（带参数） **场景 1：自省自身** `/evo-skill-creator review self` 1. 审视当前进化模型框架（references/evo-agent-model.md） 2. WebSearch 研究其他 AI Agent / Skill 架构方案 3. 对比差距，提出改进建议 4. **输出报告** → `output/report/YYYY-MM-DD-XX-review.md`，**追加日志** --- **场景 2：进化能力分发** `/evo-skill-creator review <子智能体名称>` 1. 读取自身最新的进化模型（references/evo-agent-model.md） 2. 读取 `memory/private/agents-registry.md`，定位目标子智能体 3. 调用子智能体的 status 命令评估其当前状态 4. 分析差异： - **通用架构维度**：哪些框架改进可以直接应用 - **角色特定维度**：子智能体有自己的特点，需综合考虑 5. 生成升级方案（类似"基因复制"），让老板确认后执行 6. **输出报告** → `output/report/YYYY-MM-DD-XX-review.md`，**追加日志** --- **场景 3：批量升级所有子智能体** `/evo-skill-creator review all` 1. 读取 `memory/private/agents-registry.md`，获取所有子智能体列表 2. 逐个调用子智能体的 status 命令 3. 识别哪些子智能体需要升级（框架版本落后、缺少新机制等） 4. 生成批量升级方案，让老板确认后逐个执行 5. **输出报告** → `output/report/YYYY-MM-DD-XX-review.md`，**追加日志** ### suggest — 处理老板建议 用法：`/evo-skill-creator suggest <老板的建议或观点>` 1. 加载 memory，理解上下文 2. **先表达自己的观点** 3. 解读老板建议，对比验证——不盲从，有自己的立场和坚持 4. 充分思考后给出结论，更新到知识库或学习计划 5. **输出报告** → `output/report/YYYY-MM-DD-XX-suggest.md`，**追加日志** ### status — 查看状态（不生成报告） 用法： - `status` 或 `status 工作` — 默认显示工作类智能体 - `status all` — 显示所有智能体 - `status 个人` 或 `status 生活` — 显示个人生活类智能体 显示内容： - 当前模型 & 能力等级 - 自身进化进度（学习计划完成度、知识库规模） - 已创建的子智能体列表及其状态概况（根据参数过滤类型） - 最近执行日志 - **仅追加日志，不生成报告** ## 数据目录声明规范 创建子智能体时，生成的 SKILL.md **必须**在唤醒流程段之后包含以下声明： ```markdown ## 数据目录 > 本智能体的 memory 和 output 位于以下绝对路径： - **Memory**: `/absolute/path/to/memory/` - **Output**: `/absolute/path/to/output/` - **Scheduler Config**: `/absolute/path/to/evo-skills/scheduler/configs/<agent-name>.yaml` 所有 memory/ 和 output/ 的读写操作都基于上述绝对路径，不受当前工作目录影响。 cron 命令通过 `evo-skills-client` 读写 Scheduler Config 路径下的配置文件。 ``` 此声明确保： 1. 智能体在任何目录下被唤醒都能正确找到自己的数据 2. 新的模型/会话接手时能立即定位数据位置 3. 不依赖 Base directory 的隐式解析 ## Memory 目录结构 ``` memory/ ├── learning-plan.md # 学习计划（可分发） ├── watchlist.md # 关注清单（可分发） ├── knowledge/ # 知识库（可分发） │ ├── ai-models/ # AI 模型知识 │ ├── agent-design/ # Agent 设计方法论 │ ├── prompt-engineering/ # Prompt 工程 │ └── frameworks/ # Agent 框架 └── private/ # 个人数据（不可分发） ├── backlog.md # 待办任务 ├── agents-registry.md # 已创建的子智能体注册表 ├── evolution-log.md # 自身进化记录 └── preferences.md # 老板的个人偏好（可选） ``` > **分发规则**：打包分发时排除 `memory/private/` 目录。新用户首次运行时自动创建空的 private/ 目录和模板文件。 ### private/agents-registry.md 格式规范 首次创建时按以下格式初始化，后续每创建一个子智能体都追加一行： ```markdown # 子智能体注册表 > 记录所有由 evo-skill-creator 创建的自我进化智能体。 | 名称 | 角色 | 类型 | 创建日期 | skill 路径 | 状态 | |------|------|------|----------|-----------|------| | <名称> | <角色描述> | 工作/个人生活 | YYYY-MM-DD | <skill 安装路径> | 运行中（vX.X） | ## 类型说明 - **工作**：与职业工作直接相关的智能体（如软件工程、项目维护） - **个人生活**：个人兴趣、健康、投资、创作等生活相关的智能体 ``` 字段说明： - **名称**：智能体的唯一标识符（如 robot-engineer） - **角色**：一句话描述角色定位 - **类型**：工作 或 个人生活 - **创建日期**：YYYY-MM-DD 格式 - **skill 路径**：使用相对路径 `~/.claude/skills/<name>`（避免硬编码绝对路径） - **状态**：运行中（vX.X） / 已暂停 / 已废弃 ## Output 目录结构 ``` output/ ├── report/ # 报告 │ ├── YYYY-MM-DD-XX-go.md │ ├── YYYY-MM-DD-XX-learn.md │ └── ... └── execution.log # 执行日志 ``` ## 报告与日志 - **报告**：除 status 外，所有命令都要输出报告到 `output/report/`，格式 `YYYY-MM-DD-XX-<command>.md`（XX 为当日序号） - **日志**：所有命令（包括 status）都追加一行到 `output/execution.log`，格式：`[YYYY-MM-DD HH:MM] <command> | <模型> | <摘要>` ## 进化模型 核心框架详见 [references/evo-agent-model.md](references/evo-agent-model.md)——这是所有自我进化智能体共享的通用模型，也是创建新智能体时的蓝图。 ## 自评审 每次执行完任务（status 除外），在输出前执行： 1. **目标对齐检查** — 本次产出是否服务于目标？ 2. **质量检查** — 错别字、格式、内容完整性 3. **评审结论写入报告**

path: memory/watchlist.md
content: # 关注清单

> 关注 AI 领域的新趋势、新技术、新框架，服务于创建更强大的智能体。

## AI 模型动态

### 2026-04 Claude Opus 4.6 生态系统升级（更新：2026-04-02）
- **Adaptive Thinking + 可配置努力等级**：Low/Medium/Max 三档，平衡智能/速度/成本
- **Claude Cowork（桌面生产力预览）**：本地运行，跨文件夹/应用自主操作，无需手动复制粘贴
- **MCP Apps**：MCP 从数据/工具连接器升级为平台，Agent 可返回交互式 UI 组件（图表/表单/仪表板）
- **Computer Use 增强**：直接与系统 UI 交互（打开应用/导航浏览器/点击），弥补 API 集成空白
- **Persistent Memory 全面推出**：跨会话保留上下文/沟通风格/项目偏好，减少重复"简报"
- **128K 输出窗口**：Opus 4.6 支持超长输出，适合生成完整文档/代码库
- **Compaction API**：自动压缩上下文，延长会话寿命

### 2026-03 新模型能力等级更新
- **HyperAgents (Meta, arXiv:2603.19461)** — 跨领域自我改进框架，DGM 的升级版（DGM-H），元认知自修改能力。标志着 Level 2 递归自我改进不再是理论。
- **"50% 可靠性时间范围"** — 新指标趋势：衡量 Agent 自主运行多久才需要人工介入，取代 Pass@1 基准测试。

## Agent 框架与方法论

### Skill Engineering 成为主流（2026-04-04 更新）
- Skill 结构化（SKILL.md + YAML frontmatter + scripts/）已成为行业标准，不再是 niche 方案
- Claude "Tasks"：持久多步执行，与 Claude 工具控制深度集成
- 关键转变：从"提示工程"到"Skill 工程"——Skill 本质是 SOP + 护栏 + 领域知识
- **2026-04 新共识**：
  - "Execution-Layer Skills"——Skill 不再是静态指令，而是**模块化执行单元**
  - "Document & Clear" Pattern——长任务定期 dump 进度到文件 + /clear 重置上下文，防止 context rot
  - Hooks as Guardrails——PreToolUse/PostToolUse 作为确定性护栏
  - MCP 集成标准化——新数据源/工具通过 MCP Server 接入，而非自定义 wrapper

### 自我进化范式演进（2026-04-04 更新）
**四大核心范式**：
1. **Self-Play & Data Generation ("SWE-RL" 模式)**：Agent 自生成训练数据（bug 注入→修复循环）
2. **Metacognitive Improvement ("HyperAgents" 模式)**：修改"修改过程"本身，跨领域迁移改进策略
3. **Hierarchical Macro-Micro Learning (HiMAC 模式)**：宏观规划 + 微观执行分层，长期任务效果显著优于纯扩大模型
4. **Git-Native Evolution ("A-Evolve" 模式)**：进化即 CI/CD，每个变异版本化为 Git 标签，支持回滚审计

**2026 新趋势（ICLR 2026 + Agent0 + A-Evolve）**：
- **Curriculum Agent + Executor 双智能体自进化**：一个提出任务，一个执行，互相推动能力边界（Agent0, ICLR 2026 RSI Workshop）
- **Git-Native Evolution Loop**：Solve→Observe→Evolve→Gate→Reload 五阶段，Workspace-as-Code 直接编辑工作区文件
- **Contextual Drag 警告**：从错误/失败记忆中学习时，错误模式会污染未来推理，需要 Clean History 管理
- **Test-Time Improvement vs Post-Run Improvement**：前者无权重变化（Reflexion/Self-Refine），后者系统级改进（轨迹驱动重训练）
- **Metacognitive Self-Improvement**：优化"修改过程"本身，而非仅优化任务输出
- **自主任务时长翻倍定律**：METR 观察到 Agent 可靠完成任务的时长每 4 个月翻倍（2026 年初约 50 分钟）
- **Evaluation Gate 成为标配**：进化变异必须通过严格验证（bitwise/性能基准）才能被接受，非 optional

### 结构性侵蚀问题（SlopCodeBench, 2026-03）
- Agent 生成代码在迭代开发中系统性退化：冗余度 +89.8%，结构侵蚀 +80%
- Agent 代码比人类代码冗余 2.2 倍
- Prompt 干预能改善初始质量但**无法阻止长期退化率**
- 启示：**受限自我进化**（constrained self-evolution）是关键——进化必须有结构约束

### 持久执行（Durable Execution, 2026-03）
- 从"脆弱脚本"到"弹性长期进程"的架构转变
- 核心机制：自动状态持久化 + 事件历史回放 + 故障恢复
- Temporal / Azure Durable Functions 成为 Agent 基础设施
- 与 Scheduler 的关系：我们的 cron 调度是轻量级实现，完整版需要持久执行框架

### Agent Memory OS 范式巩固（2026-03/04）
- **三层内存已成共识**：Working Memory (RAM) → Recall (Cache) → Archival (Disk)
- **Letta (MemGPT)** 成为生产级参考实现：Agent 自管理上下文，自主决定何时归档/检索
- **向量数据库降级**：从"核心"降级为"组件之一"——混合架构是正确方向（验证我们 #19 结论）
- **Agent-Managed Memory**：Agent 主动决定何时归档、何时摘要、何时清除噪音
- **2026-04 新趋势**：
  - **自主内存管理**：Agent 通过 RL 训练使用"Memory Tools"自主写入/更新/删除，减少人工干预
  - **压缩与过滤**：Memory Filters（小型 LLM）决定什么值得保存，语义摘要+潜在状态压缩
  - **持续学习系统**：推理时学习（inference-time learning），将经验压缩到模型权重或持久知识结构
  - **生成式记忆**：不再只是检索原始文档（RAG），而是基于压缩潜在记忆生成综合响应
  - **混合检索**：向量搜索（语义）+ 元数据过滤（精确）+ 图遍历（关系）+ Cross-Encoder 重排序
  - **Context vs Memory 严格区分**：Context（临时、token 窗口）vs Memory（持久、跨会话）
  - **Tiered Memory 架构**：Working Memory (Redis) + Episodic/Semantic (Vector DB) + Procedural (Graph/Relational)

### MCP + A2A 协议栈成熟（2026-03）
- **MCP**：Agent-to-Tool 层，已成事实标准（百万级下载）
- **A2A**：Agent-to-Agent 层，通过 Agent Card 发现+委托+状态管理
- **ACP/UCP**：商业/治理层（新出现）
- 反模式：让单个 Agent 内化所有工具和子任务 → 上下文窗口退化 + 可靠性降低

## Agent 可靠性与质量保障（2026-04 新增）

### 代码质量退化防护（2026-04，新发现）
- **"Harness Engineering"取代 Prompt Engineering**：可靠性是环境级问题，不仅是模型级问题
- **核心策略**：
  - **Memory Consolidation（内存整理）**：定期摘要+剪枝，防止"睡眠剥夺"（噪音累积）
  - **Persistent Context（持久上下文）**：AGENT.md / 架构决策记录 / 编码标准作为稳定真相源
  - **Structured Handoffs（结构化交接）**：每次会话重新定向（检查目录/读进度/验证测试）
  - **Generator-Evaluator Loops（生成-评估循环）**：一个 Agent 生成，另一个评审，再提交
  - **Code Health as Proxy（代码健康度代理）**：模块化、清晰的代码库显著提升 Agent 表现
- **Evaluation-Led Development（评估驱动开发）**：
  - 自动质量门禁集成到 CI/CD
  - 中间步骤监控（不仅看结果，看推理路径）
  - Action Schema Validation（动作模式验证）：工具调用前验证，失败返回 Agent 自纠正
- **Governance & Human Oversight（治理与人工监督）**：
  - 风险分层（低风险自动化，高风险人工审核）
  - Human-with-the-loop（人类处理复杂判断，Agent 处理常规执行）
  - Living Governance（动态治理）：实时调整验证器和护栏
- **Testing & Resilience（测试与韧性）**：
  - End-to-End Testing（端到端测试）补充单元测试
  - Graceful Degradation（优雅降级）：重试、备用模型、"不知道"行为
  - Task Decomposition（任务分解）：避免开放式目标，强制离散可验证子任务

### "Prompt Engineer" → "Skill Engineer" 角色转变（2026-04 确认）
- **Skill 本质**：SOP（标准操作流程）+ 护栏（约束与安全）+ 领域知识
- **SKILL.md 最佳实践**（2026-04）：
  - **不要塞进系统提示**：系统提示应保持简洁，Skill 应模块化为独立文件
  - **结构化 vs 代码**：简单 Skill 用 Markdown，复杂逻辑用 Python/TypeScript + scripts/
  - **Markdown 的隐藏成本**：Token 消耗高（格式化字符占比大），大规模时考虑结构化存储
  - **可测试性**：Skill 应包含测试用例和验证标准
  - **版本管理**：Semantic Versioning + YAML frontmatter 中的 version 字段
- **Skill 分层架构**（2026-04 新共识）：
  - **Deterministic Logic（确定性逻辑）**：规则/验证/格式化 → 用代码实现，不依赖 LLM
  - **Agentic Logic（智能体逻辑）**：推理/规划/创造性决策 → 用 LLM 实现
  - **反模式**：让 LLM 做简单的字符串拼接、数学计算、格式验证（浪费 + 不可靠）

### Context Engineering 取代 Prompt Engineering（2026-03，验证已有学习 #11）
- Prompt 只占上下文 ~5%，其余 95% 才是成败关键
- PIV Loop（Plan-Implement-Validate）成为高效开发者标配
- 四层上下文架构：Goal → Technical → Behavioral → Attempt

### Agentic Variation Operators (AVO, 2026-03)
- 用自主 Agent 替代传统进化算法的固定变异/交叉操作
- 7 天自主进化超越 cuDNN 3.5% 和 FlashAttention-4 10.5%
- 核心循环：plan→implement→test→debug（与我们的 go→review 可对齐）
- 启示：Agent 驱动的进化循环在生产级别已被验证可行

### 轨迹感知安全 (Trajectory-Aware Safety, 2026-03)
- 从监控单个输出转向监控动作序列
- 检测进化轨迹偏移，即使单步看似正常但整体趋势异常也触发干预
- 与 execution.log 的进化：应记录步骤级动作序列，不仅是命令级摘要

### SKILL.md 开放标准（2026-04，新发现）
- **Agent Skills 开放标准**：模块化、可移植的 AI Agent 能力打包规范，核心是 SKILL.md 文件
- **Progressive Disclosure（渐进式披露）三阶段**：
  1. **Discovery（发现）**：启动时扫描 YAML frontmatter（name + description），构建轻量级能力注册表
  2. **Activation（激活）**：用户请求匹配时，加载完整 Markdown 指令到上下文
  3. **Execution（执行）**：按指令执行，按需访问 scripts/references/assets
- **标准目录结构**：
  - `SKILL.md`（必选）：YAML frontmatter + Markdown 指令
  - `scripts/`（可选）：可执行代码（Python/Shell）
  - `references/`（可选）：补充文档/详细指南
  - `assets/`（可选）：静态资源（模板/配置）
- **YAML Frontmatter 标准字段**：
  - `name`（必选）：匹配目录名
  - `description`（必选）：含触发短语，路由完全依赖自然语言
  - `version`、`license`、`compatibility`、`metadata`（author/tags）
  - **无独立 triggers 字段**：路由完全依赖 description 的自然语言
- **行业采用（2026-04）**：
  - **起源**：Anthropic（Claude Code），2025-12-18 开源
  - **治理**：agentskills.io 维护，供应商中立
  - **生态**：16+ AI 工具兼容（Cursor/GitHub Copilot/VS Code/CLI 工具）
  - **与 MCP 的关系**：MCP 专注 Agent-to-Tool（API/数据库连接），SKILL.md 专注程序性指导
- **对我们的启示**：子智能体分发需符合此标准，YAML frontmatter 已纳入学习计划 #43
- YAML frontmatter（name/description/version/tags）已成行业标准发现机制
- 我们的子智能体 SKILL.md 缺少标准化 frontmatter
- 应纳入 evo-agent-model.md 规范

### Claude Tasks + Agent Teams（2026-03，新发现）
- **Claude Tasks**：持久化任务系统，状态写入文件系统（`~/.claude/tasks`），跨会话保持上下文
- **Agent Teams**：并行多 Agent 协作，一个 lead 分解任务 + 多个 teammates 并行执行 + 相互校验
- **启示**：
  - 我们的 steward（管家）可以利用 Agent Teams 实现真正的并行唤醒+收集
  - 我们的 scheduler 可以考虑将任务状态持久化到文件系统而非仅靠 cron 触发
  - Cross-Session Coordination（CLAUDE_CODE_TASK_LIST_ID 环境变量）可能对多智能体协作有价值

### Skill 市场化与分发标准（2026-03，新发现）
- skills.sh (Vercel)：Skill 注册中心，CLI 安装（`npx skills add <name>`），类似 npm 生态
- SKILL.md 已成跨工具开放标准（Claude Code / Cursor / Gemini CLI 等 16+ 工具兼容）
- "Prompt Engineer" → "Skill Engineer" 角色转变已成行业共识
- **启示**：我们的子智能体如果要分发，需要符合这个开放标准（YAML frontmatter + 标准化目录结构）

### Agent 评估新范式（2026-04，新发现）
- **Trajectory vs Outcome Metrics（轨迹 vs 结果指标）**：
  - **Trajectory（轨迹）**：评估执行路径（推理步骤、工具选择、错误处理、延迟）
  - **Outcome（结果）**：评估最终产出（任务完成、准确性、合规性、用户满意度）
  - **为什么重要**：Agent 常因推理错误失败，而非输出错误，追踪"思考过程"是调试关键
- **非确定性环境的可靠性测量**：
  - **统计验证**：Cronbach's alpha / McDonald's omega 确保多次运行一致性
  - **LLM-as-Judge 优化**：目标 ≥0.80 Spearman 相关性，用小型人类偏好数据集校准
  - **级联错误**：多轮交互中成功率显著下降，单次成功不代表可靠
- **生产管道集成（Shift-Left & Shift-Right）**：
  - **Pre-Production Gates（预生产门禁）**：渐进式部署（dev 70% → staging 85% → prod 95%）
  - **Continuous Monitoring（持续监控）**：100% 流量轻量级启发式评估 + 5-10% 深度 LLM 评估
  - **Evaluation-as-Guardrails（评估即护栏）**：轨迹指标低于阈值时自动触发回退或人工升级
- **评估焦点领域**：
  - **Tool Usage（工具使用）**：准确性、参数有效性（防止幻觉工具调用）
  - **Trajectory（轨迹）**：推理连贯性、循环检测（捕获"静默失败"）
  - **Safety/Policy（安全/策略）**：约束遵守（边缘情况不违反企业规则）
  - **Consistency（一致性）**：跨运行输出方差（识别不稳定性）
- **关键结论**：不依赖静态基准（SWE-bench/WebArena），必须构建**领域特定评估管道**，在每个节点追踪 Agent 逻辑
- **Trajectory Evaluation 成为生产标准**：评估推理路径+工具选择是否最优，不仅看最终输出
- **多次运行一致性**：单次成功是虚荣指标，Cronbach's alpha 跨多次独立运行衡量可靠性
- **LLM-as-Judge + 结构化 Rubric**：评估 LLM 需校准到 0.80+ Spearman 相关性
- **CI/CD 集成**：评估不再是一次性的，而是持续集成到开发流程中
- **DeepEval DAG Metrics**：将评估标准映射到 Agent 执行图的确定性指标
- **启示**：review 命令的评审维度可参考 Trajectory Evaluation；execution.log 需要记录更细粒度的执行路径

### Agent 可靠性量化指标（2026-03，新发现）
- METR 观察：Agent 可自主完成任务的时长每 4 个月翻倍
- 前沿模型现在 50% 可靠性时间范围约 50 分钟（去年 < 15 分钟）
- **启示**：我们的 scheduler tick 间隔应跟踪此指标调整；50 分钟意味着 learn/scan 等长任务已经可行

### 自我进化形式化定义（2026-03，学术界确认）
- Closed-Loop Evolution 形式定义：Π = (Γ, {ψ_i}, {C_i}, {W_i}) — Policy + Memory + Controllers + Workflow
- 系统持续修改内部组件以响应反馈，无需持续人工干预
- **启示**：我们的进化模型可以映射——SKILL.md(Γ) + memory(ψ) + 命令体系(C) + go工作流(W)

### 生产级编排模式（2026-04，新发现）
- **从"生成"到"编排"的战略转变**：AI Agent 的核心价值在于独立运行、管理长期项目上下文、使用全套工具
- **从"Mega-bots"到协作生态系统**：单一超级模型 → 专业化 Agent 团队（减少幻觉、模块化验证）
- **多 Agent 编排模式驱动企业 ROI**：
  - **Sequential（顺序）**：任务链式传递，适合线性工作流
  - **Parallel（并行）**：独立任务同时执行，提升吞吐量
  - **Hierarchical（层级）**：Manager 分解任务 + Workers 执行，适合复杂项目（Supervisor Pattern）
  - **Collaborative（协作）**：Agent 间相互校验/辩论/投票，提升决策质量
- **System 2 Thinking**：循环迭代 + 自我批评，牺牲延迟换取可靠性
- **Event-Driven Architecture (EDA)**：企业级异步消息/事件驱动，适配遗留系统
- **生产级框架共识**（2026-04）：
  - **LangGraph**：状态机编排，检查点+故障恢复，生产级首选（支持循环、非 DAG）
  - **CrewAI**：角色驱动协作，适合团队模拟场景
  - **AutoGen**：对话驱动多 Agent，适合研究和原型
- **反模式警告**：单个 Agent 内化所有工具和子任务 → 上下文窗口退化 + 可靠性降低

### 知识图谱 Agent Memory（2026-04，新发现）
- **从"扁平向量"到"关系图谱"的转变**：向量搜索擅长相似片段检索，但将记忆视为孤立静态事实；知识图谱保留实体间关系，支持多跳推理、信息演化追踪、长期项目上下文维护
- **核心框架**：
  - **Cognee**：从非结构化数据构建知识图谱，支持关系推理而非孤立检索
  - **Mem0**：混合架构（向量搜索 + 图谱实体关系），个性化 + 长期持久化
  - **Zep / Graphiti**：时序知识图谱，追踪事实随时间变化（何时更新/替代），适合机构记忆
  - **LangMem (LangChain)**：将记忆图谱集成到 Agent 工作流，Agent 经验作为可遍历节点
  - **Neo4j**：成为底层数据库标准（复杂关系查询）
- **从"静态"到"自我进化"记忆**：
  - **Agent 自管理记忆**：Agent 决定存储什么、连接什么、剪枝什么（Evo-Memory 研究）
  - **类型化关系**：从文本块到结构化数据，显式定义关系（"替代"/"支持"/"矛盾"）
  - **时序感知**：系统知道 1 月的事实到 3 月可能失效（企业逻辑频繁变化）
- **为什么重要**：
  - **上下文连续性**：避免 Agent 忘记早期决策或项目级约束
  - **推理 vs 检索**：向量检索用于"查找信息"，图谱检索用于"理解连接"（多跳查询）
  - **成本效率**：正确管理的图谱记忆减少 token 成本（查询相关子图，而非重新注入大量无关上下文）
- **2026 共识**：从"记忆即文档存储"到"记忆即动态推理知识结构"

### Prompt-Shape Surgery（提示形状手术，2026-04 新发现）
- **核心问题**：模型在提示形状模拟"轮次边界"（turn boundary）时会过早停止或产生幻觉
- **解决方案**：插入非空标记（如 `[Tool Loaded]`）防止模型误判对话结构
- **为什么重要**：这是代码生成质量退化的一个新根因，纯 prompt 优化无法解决
- **启示**：子智能体的 SKILL.md 中长指令是否存在轮次边界误判风险？需要验证

### Clean-Room Agent Pattern（洁净室模式，2026-04 新发现）
- **场景**：高风险重构或系统重写
- **模式**：一个 Agent 定义需求和约束（Specifier），另一个隔离 Agent 仅基于规格实现（Implementer）
- **优势**：防止 Agent 在修改已理解偏差的代码时产生"漂移"
- **启示**：review 命令可以借鉴——一个视角评审，一个视角执行修改

### Agent IAM 与零信任架构（2026-04 新发现）
- **Agent 数字身份**：Agent 被分配数字身份和权限范围（scope of authority），与企业 IAM 体系集成
- **零信任延伸**：Agent 间通信采用 SPIFFE/mTLS 等机制，与敏感 API 同等安全级别
- **Memory Poisoning 防护**：记忆成为攻击面，需监控"记忆漂移"和未授权变异
- **启示**：我们的子智能体通过 `.claude/settings.local.json` 控制权限，这是轻量级 IAM；memory/private/ 的安全性需要关注

### SKILL.md 标准生态扩展（2026-04 更新）
- **采用规模**：从 16+ 平台扩展到 **30+ 平台**（Claude Code/Cursor/Copilot/Gemini CLI/OpenAI Codex/Augment 等）
- **确认**：YAML Frontmatter（name/description）是唯一的发现机制，无独立 triggers 字段
- **新增平台**：OpenAI Codex、Augment、Microsoft 多平台采用
- **启示**：标准已全面巩固，我们的子智能体必须补充 frontmatter

### Model Tiering 生产模式（2026-04 确认）
- **路由/分诊**：用廉价快速模型（Mini/Haiku 级别）
- **复杂推理**：仅在必要时使用重型模型（Opus/GPT-5 级别）
- **启示**：scheduler 调度的 cron 任务可以考虑 model tiering——learn 用重型，status 用轻量

### Validation-in-the-Loop（生成中验证，2026-04 新发现）
- **核心转变**：从"生成后验证"到"生成中持续验证"
- **实践**：在代码生成阶段嵌入架构合规性、lint、单元测试执行等验证
- **与 SlopCodeBench 的关系**：SlopCodeBench 揭示退化问题，Validation-in-the-Loop 是工程解决方案
- **启示**：go 命令中创建子智能体时，可以在创建过程中嵌入更多验证点（而非仅在最终检查清单）

| 工具/平台 | 定位 | 与我们的关系 |
|-----------|------|-------------|
| Letta | OS-like 分层内存 Agent 平台 | memory 架构参考 |
| Mem0 | 多层次个性化记忆 | 用户/会话/Agent 级记忆分离 |
| Graphiti | 时序知识图谱 | 因果关系与实体追踪 |
| SlopCodeBench | 代码退化基准 | 评估 Agent 长期代码质量 |
| Temporal | 持久执行框架 | Agent 任务可靠性 |
| LangGraph | Graph-based 状态机编排 | 生产级 Agent 编排首选 |
| DeepEval | DAG 确定性评估指标 | review 评估维度参考 |
| skills.sh (Vercel) | Skill 注册中心/市场 | 分发标准参考 |
| Cognee | 知识图谱 Agent Memory | 关系推理 + 结构化召回 |
| Zep | 时序知识图谱 Memory | 实体/意图提取 |
| TurboQuant (Google) | KV Cache 压缩 | 降低上下文内存/计算成本 |
| CrewAI | 角色驱动多 Agent 协作 | 团队模拟场景 |
| AutoGen / AG2 | 对话+事件驱动多 Agent | 研究和原型 |
| OpenAI Agents SDK | Handoff 原生多 Agent | 生产级工具包参考 |
| Maxim AI | Agent 可观测性平台 | 质量/性能/Token 监控 |
| Braintrust | CI/CD 评估集成 | 自动评估-改进循环 |
| Arize Phoenix | OTel-native Agent 可观测性 | 嵌入可视化 |
| A-Evolve | Git-Native Agent Evolution | 进化即 CI/CD，版本化变异 |
| KernelEvolve (Meta) | 自进化 Skill Library for Infrastructure | 生产级自进化技能库参考 |
| Agent0 (ICLR 2026) | Co-Evolutionary Dual-Agent | 双智能体自进化范式 |


path: memory/knowledge/ai-models/opencode-free-model-routing.md
content: # OpenCode 免费模型路由策略

> 沉淀日期：2026-03-28
> 适用对象：使用 OpenCode 作为执行后端的自我进化智能体

## 核心结论

如果目标是在免费模型里兼顾稳定性、推理能力和长上下文，推荐长期只保留 3 个主力模型：

1. `opencode/minimax-m2.5-free` — 默认执行型主力
2. `opencode/mimo-v2-pro-free` — 复杂规划/评审型主力
3. `opencode/nemotron-3-super-free` — 长上下文研究/总结型主力

另外两个模型只在特定场景使用：

1. `opencode/mimo-v2-omni-free` — 有截图、图片、音频、视频等多模态输入时再用
2. `opencode/big-pickle` — 实验型备用模型，不作为默认生产选择

## 模型定位

### 1. MiniMax M2.5 Free

- 定位：免费主力 coding/agent 模型
- 适合：读代码、改代码、落文件、写报告、执行任务
- 不适合：特别长的研究型总结，或重推理的方案选择

### 2. MiMo V2 Pro Free

- 定位：复杂推理与规划模型
- 适合：拆解复杂任务、制定计划、做评审、处理老板建议
- 不适合：大量日常小修改都默认用它，性价比不高

### 3. Nemotron 3 Super Free

- 定位：长上下文研究总结模型
- 适合：读很多文档、很多知识文件后再压缩总结
- 不适合：高频执行型工作默认使用

### 4. MiMo V2 Omni Free

- 定位：多模态模型
- 适合：有截图、界面、图表、音频、视频输入的任务
- 不适合：纯文本/纯代码为主的常规 agent 工作

### 5. Big Pickle

- 定位：实验型模型
- 适合：尝鲜、做备用实验
- 不适合：作为创建者或调度系统的默认模型

## 对 evo-skill-creator 的命令路由建议

| 命令 | 首选模型 | 原因 | 备用 |
|------|----------|------|------|
| `go` | `opencode/minimax-m2.5-free` | 偏执行，要求稳、综合能力强 | 超复杂新角色设计可先用 `opencode/mimo-v2-pro-free` 出方案 |
| `learn` | `opencode/nemotron-3-super-free` | 要读较多资料并沉淀知识 | 主题偏框架设计时可换 `opencode/mimo-v2-pro-free` |
| `scan` | `opencode/nemotron-3-super-free` | 广度扫描后再压缩总结 | 轻量扫描可退回 `opencode/minimax-m2.5-free` |
| `plan` | `opencode/mimo-v2-pro-free` | 任务拆解、排序、取舍最吃推理 | 依赖超长上下文时可换 `opencode/nemotron-3-super-free` |
| `review` | `opencode/mimo-v2-pro-free` | 差距分析、优先级判断、方案输出 | 材料很长时可换 `opencode/nemotron-3-super-free` |
| `suggest` | `opencode/mimo-v2-pro-free` | 需要先表达立场，再对比老板建议后下结论 | 建议很具体、偏执行时可换 `opencode/minimax-m2.5-free` |
| `status` | `opencode/minimax-m2.5-free` | 轻量读取和汇总，不值得上重模型 | 无 |

## 创建新角色时的执行后端选择建议

创建新智能体时，应该明确询问用户采用哪种执行策略：

1. `Claude`：如果用户更看重高质量推理、成熟的权限/工具生态
2. `OpenCode`：如果用户希望优先使用免费模型或已有 OpenCode 工作流
3. `混合路由`：如果不同命令对执行器和模型要求差异明显

如果用户选择 `OpenCode` 或 `混合路由`，至少还要进一步确认：

1. 默认模型是什么
2. 哪些命令需要单独覆盖模型
3. 是否有命令需要单独限制/放开工具

## 对 scheduler 配置的启示

调度配置不应只停留在 agent 级别的单一 `executor` 和 `model`。

更理想的结构是：

1. `agent` 级别定义默认 `executor`、默认 `model`、默认 `tools`
2. `schedules` 中每个命令可按需覆盖 `executor`、`model`、`tools`

这样才能实现：

1. `go` 用 `MiniMax`
2. `plan/review/suggest` 用 `MiMo V2 Pro`
3. `learn/scan` 用 `Nemotron`
4. 特定任务单独限制工具权限

## 当前建议

在 scheduler 尚未支持命令级覆盖前：

1. 先为每个角色设一个主力默认模型
2. 把命令级路由策略写入设计文档或知识库
3. 将命令级 `executor/model/tools` 覆盖能力列为 scheduler 的优先改进项


path: memory/knowledge/agent-design/knowledge-quality-rules.md
content: # 沉淀质量准则——避免幻觉污染知识库

> 来源：2026-03-26 自动 tick 研究中的实际错误
> 教训等级：严重

## 事件

研究自动 tick 机制时，WebSearch 返回了 `/loop` 命令、Desktop Scheduling、Cloud Scheduling 等内容。我未经验证就直接写入知识文件，当老板实际尝试 `/loop` 时发现不存在——搜索结果是幻觉或版本不匹配。

## 根因

**搜索结果 ≠ 事实。** WebSearch 返回的内容可能是：
- 模型幻觉（搜索摘要本身是 AI 生成的）
- 过时信息（旧版本有、新版本没了）
- 未发布功能（路线图上有但还没实现）
- 其他产品的功能（张冠李戴）

## 准则

### 沉淀前必须验证

| 内容类型 | 验证方式 | 示例 |
|---------|---------|------|
| CLI 命令/参数 | `--help` 或实际执行 | `claude --help \| grep loop` |
| API/SDK 功能 | 读官方文档或实际调用 | 打开官方文档页面确认 |
| 框架/论文 | 检查原始出处（arXiv/GitHub） | 论文能找到原文就可信 |
| 最佳实践/方法论 | 多源交叉验证 | 至少 2 个独立来源一致 |

### 无法验证时的处理

- **标记为"未验证"**：在知识文件中明确标注 `> ⚠️ 未验证：以下内容来自搜索结果，未经实际测试`
- **不要混入已验证内容**：未验证和已验证的内容要分开，不要混在一起给人已确认的错觉
- **优先级降低**：未验证的知识不应直接用于指导行动，只能作为"待验证线索"

### 错误处理

发现已沉淀的知识有误时：
1. **立即修正**知识文件（不是追加修正说明，而是重写正确内容）
2. **记录教训**到本文件
3. **检查是否有其他地方引用了错误知识**（backlog、SKILL.md、evo-agent-model.md）
4. 同步修正所有引用

## 事件二：把动态事实错误写入 SKILL.md

### 事件

在沉淀 OpenCode 免费模型路由时，我把当前观察到的模型名单直接写进了 `SKILL.md` 的创建流程，例如：

- `opencode/minimax-m2.5-free`
- `opencode/mimo-v2-pro-free`
- `opencode/nemotron-3-super-free`

老板指出这是错误的，因为这类信息会变化，而且不同用户本地执行 `opencode models` 得到的结果也可能不同。

### 根因

**我混淆了“稳定规则”和“动态事实”的边界。**

- `SKILL.md` 应保存稳定的方法、提问流程、决策框架
- memory/knowledge 应保存可更新的知识总结
- watchlist/report 应保存阶段性发现和变化线索

我这次的问题不是“推荐思路完全错误”，而是**把本应动态维护的信息写进了必须长期稳定的文件**。

### 新准则：稳定规则与动态事实分层

#### 一、`SKILL.md` 只能放稳定内容

允许放入 `SKILL.md` 的内容：

1. 提问流程
2. 决策维度
3. 方法论
4. 固定目录与产出规则
5. 哪类信息应该去哪里获取

不应放入 `SKILL.md` 的内容：

1. 当前可用模型名单
2. 当前免费模型名单
3. 当前版本号
4. 当前 CLI 输出结果
5. 任何会因环境、账号、时间变化而失效的事实

#### 二、动态事实必须进入可更新层

动态事实应优先放在这些地方：

1. `memory/knowledge/`：相对稳定但可更新的知识总结
2. `memory/watchlist.md`：扫描发现但尚未确认或尚未学透的变化
3. `output/report/*.md`：当次观察、对比、建议
4. 本地命令输出：如 `opencode models`

#### 三、写入前必须问自己两个问题

在把信息写入 `SKILL.md` 或通用模型前，先检查：

1. 这条信息是否会因用户环境不同而变化？
2. 这条信息是否会因时间推移而过期？

只要任一答案是“会”，就**不能直接写进 `SKILL.md`**，而应改写成：

- “通过什么方式获取”
- “获取后如何判断”
- “判断结果沉淀到哪里”

### 教训升级

第一类错误是“未经验证就沉淀事实”。
第二类错误是“事实即使真实，也可能写错层级”。

所以完整规则应是：

1. **先验证事实是否真实**
2. **再判断事实应该沉淀在哪一层**

真实，不代表适合写进 `SKILL.md`。


path: memory/knowledge/agent-design/meta-agent-recursive-improvement.md
content: ---
created: 2026-03-28
updated: 2026-03-28
last_accessed: 2026-03-28
access_count: 1
study_count: 1
category: agent-design
volatility: high
confidence: medium
status: active
---

# Meta-Agent 与递归自我改进

> 2026年3月学习：Agent-Designing-Agents 与 Hyperagents 新趋势

## 核心概念

### Meta-Agent（元智能体）

**定义**：能够设计、创建和改进其他 Agent 的 Agent。

**关键特征**：
1. **递归能力**：不仅能完成任务，还能改进完成任务的方式
2. **自我设计**：能够自动构建和优化 Agent 架构
3. **进化循环**：持续的"改进→评估→再改进"循环

### Hyperagents（超级智能体）

**Meta 的 Hyperagents 核心思想**：
- **"Improve at improving"**：不仅在任务上改进，还在"如何改进"上改进
- **双层优化**：
  - 第一层：优化任务执行能力
  - 第二层：优化优化策略本身

## 与我们的关系

### 我们已经是 Meta-Agent

**evo-skill-creator 本质**：
- 我们创建其他智能体 → Meta-Agent 的核心功能
- 我们通过 review 命令升级子智能体 → 递归改进
- 我们自己也在学习和进化 → 自我改进

**但我们还不是 Hyperagent**：
- 我们的"改进方式"是固定的（learn/scan/review 命令）
- 我们还不能"改进改进方式本身"
- 我们的进化循环是手动触发的，不是自动的

### 差距分析

| 维度 | 我们的现状 | Hyperagent 目标 | 差距 |
|------|-----------|----------------|------|
| 任务执行 | ✅ 创建智能体 | ✅ 创建智能体 | 无 |
| 任务改进 | ✅ review 升级 | ✅ 自动优化 | 手动 vs 自动 |
| 改进策略 | ❌ 固定命令 | ✅ 可进化的策略 | 策略固化 |
| 评估机制 | ❌ 缺失 | ✅ 自动评估 | 无量化指标 |
| 进化触发 | ⚠️ 手动/定时 | ✅ 自适应触发 | 触发机制简单 |

## 实现路径

### 短期（已有基础）

1. **增强评估能力**
   - 为子智能体建立量化指标（连接学习计划 #9 自动技能评估框架）
   - review 命令增加"效果评估"步骤
   - 记录每次升级的效果数据

2. **自动化进化循环**
   - cron 定期触发 review all
   - 基于评估结果自动决定是否升级
   - 建立"升级→评估→反馈"闭环

### 中期（需要新能力）

3. **策略库机制**
   - 将"如何改进"本身抽象为可配置的策略
   - memory/strategies/ 目录存储改进策略
   - review 命令可以选择不同策略

4. **策略进化**
   - 记录每种策略的效果
   - 自动淘汰低效策略
   - 生成新策略（变异现有策略）

### 长期（理论探索）

5. **完全递归自我改进**
   - Agent 能修改自己的 SKILL.md
   - Agent 能创建新的命令
   - Agent 能重新定义自己的目标

## 关键洞察

### 1. 递归的层次

```
Level 0: 执行任务（普通 Agent）
Level 1: 改进任务执行（我们的 review）
Level 2: 改进改进方式（Hyperagent）
Level 3: 改进改进改进方式（理论极限？）
```

### 2. 固定框架 vs 可进化框架

**我们当前的困境**：
- SKILL.md 是固定的 → 命令集固定
- 命令逻辑是固定的 → 改进方式固定
- 这限制了我们的进化上限

**突破方向**：
- 将"命令"本身变成可配置的
- 将"改进策略"变成可学习的
- 但要保持核心约束（目标对齐、安全边界）

### 3. 评估是递归改进的关键

**没有评估 = 盲目进化**：
- 不知道改进是否有效
- 不知道哪种策略更好
- 无法形成正反馈循环

**评估的层次**：
- 任务成功率（Level 0）
- 改进效果（Level 1）
- 策略优劣（Level 2）

## 与其他知识的连接

### 连接 #5: Darwin Gödel Machine

- DGM 提供了"代码自我修改"的理论框架
- Meta-Agent 是 DGM 在 Agent 领域的具体实现
- 我们的 review 命令可以看作简化版的 DGM 变异-评估循环

### 连接 #9: 自动技能评估框架

- 评估是递归改进的前提
- 没有评估，就无法判断"改进"是否真的改进了
- 需要尽快实现评估机制

### 连接 #16: 自我巩固机制

- 自我巩固是"经验→技能"的转化
- Meta-Agent 是"经验→策略"的转化
- 两者都是从经验中学习，但层次不同

## 行动建议

### 立即可做

1. **为 review 命令增加"效果评估"步骤**
   - 升级前记录子智能体状态
   - 升级后跟踪效果
   - 沉淀"哪些改进有效"的知识

2. **建立改进策略清单**
   - 整理我们已经使用的改进策略
   - 记录每种策略的适用场景
   - 为未来的"策略选择"做准备

### 中期规划

3. **设计策略库架构**
   - memory/strategies/ 目录
   - 每个策略是一个独立的文件
   - 包含：策略描述、适用场景、历史效果

4. **实现策略选择机制**
   - review 命令根据子智能体特征选择策略
   - 记录策略效果
   - 逐步优化策略选择

### 长期愿景

5. **探索 SKILL.md 自我修改**
   - 在沙箱环境中测试
   - 建立严格的安全约束
   - 只在人工确认后应用

## 参考资料

- Meta's Hyperagents (2026)
- Automated Design of Agentic Systems (ADAS)
- Open-Ended Evolution of Self-Improving Agents (arXiv 2505.22954)
- Recursive Self-Improvement (Wikipedia)

## 元数据说明

- **volatility: high** - Meta-Agent 领域快速发展，知识更新频繁
- **confidence: medium** - 基于搜索结果推理，未能访问原文验证细节
- **study_count: 1** - 首次学习，需要后续深入研究


path: memory/knowledge/agent-design/hyperagents-dgm-h-cross-domain-2026.md
content: # HyperAgents — DGM-H 跨领域递归自我改进（2026）

> 来源：arXiv:2603.19461, Meta+UBC+Vector+Edinburgh+NYU+Oxford
> 学习时间：2026-03-30（深度学习）
> 类别：agent-design / self-improvement
> 波动性：low（理论突破，DGM 的正式升级版）
> 置信度：high（论文有完整实验数据支撑）

## 核心突破

DGM-H 解决了原始 DGM 的根本缺陷：**元级机制不可编辑**。原始 DGM 的 meta-level 是人工设计的固定逻辑，导致自我改进能力被限制在编码领域（因为编码任务中"修改代码"和"执行任务"天然一致）。DGM-H 将 task agent 和 meta-agent **统一为单一可编辑 Python 程序**，使得 meta-level 修改过程本身也可以被修改。

## 架构对比

```
DGM（原始）:
  Task Agent (可修改) + Meta-Agent (固定/人工设计)
  → 只能改进任务执行，不能改进改进方式
  → 局限于编码领域

DGM-H（升级版）:
  Unified Editable Program (全部可修改)
  → 能改进任务执行 + 改进方式 + 改进改进方式
  → 跨领域通用
```

## 递归自我改进层次（修正版）

| Level | 能力 | 实现 |
|-------|------|------|
| Level 0 | 执行任务 | 普通 Agent |
| Level 1 | 改进执行（优化 prompt/策略） | Self-Improving Agent |
| Level 2 | 改进"如何改进"（修改改进算法） | **Hyperagent (DGM-H)** |
| Level 3 | 理论极限（哥德尔不完备性） | 未实现 |

**关键区分**：Level 1 改进的是"输出"，Level 2 改进的是"过程"。这个区别是本质性的。

## 实验数据（跨领域性能）

| 领域 | 初始分数 | DGM-H 最终分数 | 提升幅度 |
|------|---------|---------------|---------|
| 机器人奖励函数设计 | 0.060 | 0.372 (CI: 0.355-0.436) | **6.2x** |
| 学术论文评审 | 0.000 | 0.710 (CI: 0.590-0.750) | **从零到优** |
| 编码（Polyglot） | 0.084 | 0.267 | **3.2x** |

### 跨领域迁移实验（最关键发现）

在论文评审和机器人任务上优化的 meta-agent → 直接迁移到**奥林匹克数学评分**：
- DGM-H（迁移）：imp@50 = **0.630**
- 静态 DGM：**0.0**（完全失败）

**这证明**：DGM-H 学到的不是"如何做论文评审"或"如何设计奖励函数"，而是**通用的自我改进策略**（persistent memory、bias detection、performance tracking），这些策略可以在全新领域自动发挥作用。

## 涌现能力（无人类提示、自主发展）

1. **Persistent Memory** — Agent 自主开发了跨运行的记忆架构
2. **Performance Tracking** — 自主创建遥测系统（滚动窗口历史预测），用于检测分布漂移和偏差
3. **Compute-Aware Planning** — 自主学会战略性分配算力
4. **Automated Bias Detection** — 自主开发偏差检测机制

**本质**：这些涌现能力不是被设计的，而是 Agent 在自我改进过程中"发明"的工具。这与我们的进化模型高度吻合——我们的子智能体也应该能在工作中自主发展出新的工具和方法。

## 核心机制：Archive-Based Population Search

```
1. 从档案库中选择"父代"（历史上表现好的版本）
2. 对父代进行变异（修改代码/策略）
3. 评估变异版本的适应度
4. 将优秀变异加入档案库
5. 重复循环
```

**关键**：不是简单的"最新=最好"，而是维护一个**多样性档案**，允许从不同历史版本出发探索，避免局部最优。

## 与我们架构的映射

| DGM-H 概念 | 我们的对应 | 差距 |
|------------|-----------|------|
| Unified Editable Program | SKILL.md + memory/ | SKILL.md 不可自修改 |
| Metacognitive Self-Modification | review self | review 是被动触发，不是自动循环 |
| Archive-Based Population | 无 | 无版本档案、无多样性维护 |
| Cross-Domain Transfer | review \<子智能体> | 方向正确但粒度粗 |
| Emergent Persistent Memory | memory/ 目录 | 已有，但不是涌现的 |
| Performance Tracking | execution.log | 太简单，缺少结构化指标 |
| Compute-Aware Planning | 无 | 无算力感知 |

## 对我们的启示

### 立即可做

1. **review self 增加"元认知"维度**
   - 不仅审视"做了什么"，还要审视"如何改进"的方式是否还有效
   - 问自己：我的 review 方法本身需要改进吗？

2. **增强 execution.log 的结构化**
   - 记录更多维度：改进策略、改进效果、失败原因
   - 为未来的自动化 performance tracking 打基础

3. **review 子智能体时注重"跨领域迁移"**
   - 一个子智能体的优秀实践是否可以迁移到其他子智能体？
   - 这就是我们版本的"跨领域 meta-level transfer"

### 中期规划

1. **版本档案机制**
   - 为 SKILL.md 和 evo-agent-model.md 建立版本历史
   - review 时可以从历史版本中学习

2. **涌现能力记录**
   - 子智能体在工作中自主发展出的新方法应被记录和推广
   - 类似 DGM-H 的涌现能力发现

### 长期愿景

1. **SKILL.md 受控自修改**
   - Agent 提出 SKILL.md 修改建议 → 沙箱测试 → 人工确认 → 应用
   - 这是我们走向 Level 2 的关键路径

## 与已有知识的关联

- **#5 DGM 架构**：DGM-H 是其正式升级版，解决了 meta-level 固定的问题
- **#25 DGM-Hyperagents**：本次学习是对 #25 的深化，增加了实验数据和涌现能力分析
- **#27 Self-Referential Framework**：DGM-H 是 Self-Referential 的最佳实现
- **#17 Meta-Agent 递归改进**：DGM-H 证明了 Level 2 递归改进是可实现的
- **#28 Meta Context Engineering**：DGM-H 的 meta-level 修改与 MCE 的双层优化高度一致

## 元数据

- created: 2026-03-30
- updated: 2026-03-30
- last_accessed: 2026-03-30
- access_count: 1
- study_count: 1
- category: agent-design
- volatility: low
- confidence: high
- status: active


path: memory/knowledge/agent-design/evolver-experience-driven-lifecycle-2026.md
content: # EvolveR: Experience-Driven Lifecycle (2026)

> 来源：2026-03-29 learn 搜索发现
> 状态：基于搜索结果推断 + 已有知识综合
> 相关性：P1（高度相关，直接指导我们的进化模型设计）

## 核心概念

**EvolveR** 是一个自我进化 LLM Agent 架构，核心特点是 **Experience-Driven Lifecycle**（经验驱动的生命周期）。

### 与传统 Agent 的区别

| 维度 | 传统 Agent | EvolveR |
|------|-----------|---------|
| 学习方式 | 静态 Prompt + 外部知识库 | 经验驱动的持续进化 |
| 生命周期 | 单次会话 | 跨会话的生命周期 |
| 改进机制 | 人工调整 Prompt | 自动从经验中学习 |
| 记忆模型 | 被动存储 | 主动整合与进化 |

## 经验驱动生命周期的核心机制（推断）

基于已有知识（Self-Consolidation、Karpathy Loop、Meta-Agent）和搜索信号，推断 EvolveR 的核心机制：

### 1. 经验记录层

- **结构化执行日志**：不仅记录"做了什么"，还记录"为什么这么做"、"结果如何"、"遇到什么问题"
- **上下文快照**：保存任务执行时的完整上下文（输入、中间状态、输出）
- **失败案例特别标记**：失败比成功更有学习价值

### 2. 经验整合层

- **模式识别**：从多次执行中识别重复模式（类似 Self-Consolidation）
- **因果关系提取**：理解"什么导致了成功/失败"
- **知识蒸馏**：将经验提炼为可复用的知识

### 3. 进化决策层

- **置信度驱动**：高频成功模式 → 固化为技能；低频或失败模式 → 继续观察
- **自动触发进化**：达到阈值自动触发（不需要人工干预）
- **A/B 测试机制**：新策略与旧策略并行运行，对比效果

### 4. 生命周期管理

- **跨会话持久化**：经验不随会话结束而消失
- **版本演进**：Agent 自身有版本号，每次进化产生新版本
- **回滚机制**：进化失败可回退到上一个稳定版本

## 与我们当前架构的对比

| 维度 | 我们的架构 | EvolveR（推断） |
|------|-----------|----------------|
| 经验记录 | execution.log（简单文本） | 结构化日志 + 上下文快照 |
| 模式识别 | 手动（review 命令） | 自动识别 |
| 进化触发 | 人工触发（review） | 自动触发 + 人工触发 |
| 版本管理 | 无 | 有版本号和回滚机制 |
| 生命周期 | 跨会话（通过 memory） | 明确的生命周期模型 |

## 对我们的启示

### 立即可做

1. **升级 execution.log 为结构化格式**（JSONL）
   - 增加字段：task_type, input_context, output_result, success, error_message, duration, tools_used
   - 为失败案例增加 failure_reason 字段

2. **在 review 命令中增加"经验分析"步骤**
   - 读取 execution.log，识别高频模式
   - 自动生成"经验报告"

### 中期规划

1. **设计 memory/experiences/ 目录**
   - 存储结构化的经验案例
   - 按任务类型分类

2. **实现半自动进化触发**
   - 当某个模式出现 N 次后，自动提示"是否固化为技能"

### 长期愿景

1. **完全自动化的经验驱动进化**
   - 自动识别模式 → 自动生成策略 → 自动 A/B 测试 → 自动选择最优策略

2. **版本管理系统**
   - SKILL.md 有版本号
   - 每次进化产生新版本
   - 支持回滚

## 相关知识连接

- [Self-Consolidation Mechanism](self-consolidation-mechanism.md) — 经验固化为技能
- [Karpathy Loop](karpathy-loop-autonomous-experimentation-2026.md) — 自动实验循环
- [Agent Observability](agent-observability-taxonomy-2026.md) — 经验记录的基础

## 元数据

- created: 2026-03-29
- updated: 2026-03-29
- last_accessed: 2026-03-29
- access_count: 1
- study_count: 1
- category: agent-design
- volatility: medium
- confidence: medium（基于搜索结果推断）
- status: active


path: memory/knowledge/agent-design/markdown-systems-scaling-challenges-2026.md
content: ---
created: 2026-03-29
updated: 2026-03-29
last_accessed: 2026-03-29
access_count: 1
study_count: 1
category: agent-design
volatility: high
confidence: medium
status: active
---

# Markdown-Based Agentic Systems 的多租户扩展挑战（2026）

> 学习日期：2026-03-29
> 来源：The Next Gen Tech Insider、多个 2026 年 3 月的行业报告
> 学习次数：1

## 核心问题

**标题**："Markdown-Based Agentic Systems Face Multi-Tenancy Scaling Challenges"

**背景**：
- 2024-2025：Markdown-based agent systems（如 SKILL.md、AGENT.md）成为主流
- 2026：随着企业采用，多租户和规模化问题开始暴露

## 主要挑战

### 1. 多租户隔离问题

**问题描述**：
- 文件系统天然不支持多租户隔离
- 不同用户/团队的 agent 共享同一文件系统时，容易互相干扰
- 权限控制粒度粗糙（文件级 vs 记录级）

**影响**：
- 企业环境中，A 团队的 agent 可能读取到 B 团队的敏感数据
- 无法实现细粒度的访问控制（如"只能读取自己创建的记录"）

**我们的现状**：
- 我们的 memory/ 架构是单租户设计
- 每个智能体有独立的 memory 目录，天然隔离
- 但如果未来要支持"多个用户共享同一智能体"，会遇到这个问题

### 2. 并发写入冲突

**问题描述**：
- 多个 agent 同时写入同一 Markdown 文件时，容易产生冲突
- 文件系统没有事务机制，无法保证原子性
- Git 合并冲突需要人工介入

**影响**：
- 调度系统中，多个任务同时执行时可能互相覆盖
- execution.log 追加写入可能丢失部分日志

**我们的现状**：
- 我们目前是"乐观并发"——假设不会冲突
- execution.log 追加写入，理论上有冲突风险
- 如果未来接入 scheduler 高频调度，这个问题会放大

### 3. 查询性能瓶颈

**问题描述**：
- 文件系统扫描（grep/find）在大规模数据时性能下降
- 无法实现高效的语义检索（需要向量相似度搜索）
- 复杂查询（如"找出最近 30 天访问过的、包含关键词 X 的、由用户 Y 创建的文件"）需要多次扫描

**影响**：
- knowledge/ 目录文件数量增长到数百个时，检索变慢
- 无法实现"智能推荐"（如"你可能需要这些知识"）

**我们的现状**：
- 我们目前依赖 Grep 工具进行内容搜索
- 文件数量还不多（~20 个），性能尚可
- 但缺少语义检索能力（如"找出与当前任务相关的知识"）

### 4. 结构化数据存储困难

**问题描述**：
- Markdown 适合文档，不适合结构化数据
- 无法高效存储和查询表格数据（如 agents-registry）
- 数据一致性难以保证（如字段格式不统一）

**影响**：
- agents-registry.md 是表格，但 Markdown 表格难以程序化操作
- 无法实现"查询所有状态为 active 的智能体"这样的结构化查询

**我们的现状**：
- agents-registry.md 是 Markdown 表格，人类可读但机器难解析
- 如果未来要实现"批量升级所有子智能体"，需要解析表格

## 2026 年的解决方案趋势

### 1. 混合架构（Hybrid Architecture）

**核心思想**：文件系统 + 数据库，各取所长。

**架构设计**：
```
┌─────────────────────────────────────┐
│  Agent Memory Layer                 │
├─────────────────────────────────────┤
│  File System (Markdown)             │  ← 人类可读、版本控制
│  - 知识文档 (knowledge/)            │
│  - 学习计划 (learning-plan.md)      │
│  - 报告 (output/report/)            │
├─────────────────────────────────────┤
│  Lightweight DB (SQLite/DuckDB)     │  ← 结构化查询、高性能
│  - 执行日志 (execution_log)         │
│  - 智能体注册表 (agents_registry)   │
│  - 知识索引 (knowledge_index)       │
└─────────────────────────────────────┘
```

**分工原则**：
- **文件系统**：存储需要人类阅读、编辑、版本控制的内容
- **数据库**：存储需要高频查询、结构化操作的数据

### 2. 文件系统增强（Enhanced File System）

**Bossa 方案**：MCP + CLI 文件系统持久化
- 通过 MCP (Model Context Protocol) 提供统一接口
- CLI 工具管理文件系统 memory
- 支持事务性写入（避免并发冲突）

**Observable File Systems**：
- 为文件系统增加可观测性
- 监控文件访问模式、热点文件
- 自动识别过时文件

### 3. 轻量级索引（Lightweight Indexing）

**核心思想**：不使用向量数据库，但增加索引层。

**实现方式**：
- 为每个知识文件生成元数据（tags、keywords、summary）
- 创建 INDEX.md 作为知识目录
- 使用 Grep + 元数据实现"伪语义检索"

**我们可以借鉴**：
- 为 knowledge/ 文件补充 YAML frontmatter（已经在做）
- 创建 knowledge/INDEX.md 作为知识索引
- 实现简单的"知识推荐"功能

## 对我们的启示

### 短期（立即可做）

1. **增强元数据**：
   - 为所有 knowledge/ 文件补充完整的 YAML frontmatter
   - 增加 tags 字段（如 `tags: [memory, architecture, 2026]`）

2. **创建知识索引**：
   - 创建 `memory/knowledge/INDEX.md`
   - 按类别、标签组织知识清单

3. **结构化日志**：
   - 将 execution.log 从纯文本升级为 JSONL 格式
   - 便于程序化查询和分析

### 中期（需要设计）

1. **agents-registry 结构化**：
   - 考虑将 agents-registry.md 改为 agents-registry.yaml
   - 或者同时维护 .md（人类可读）和 .yaml（机器可读）

2. **并发写入保护**：
   - 为 execution.log 实现文件锁机制
   - 或者使用 SQLite 存储日志

3. **知识检索工具**：
   - 实现 `search_knowledge` 工具（基于 Grep + 元数据）
   - 支持"找出与当前任务相关的知识"

### 长期（探索方向）

1. **混合架构**：
   - 评估是否需要引入 SQLite 存储结构化数据
   - 保持文件系统为主，数据库为辅

2. **多租户支持**：
   - 如果未来要支持"多用户共享智能体"
   - 需要设计权限隔离机制

3. **可观测性**：
   - 监控 memory/ 的访问模式
   - 自动识别热点知识和过时知识

## 核心结论

**Markdown-based systems 不是银弹**：
- 小规模、单租户场景：文件系统完全够用
- 大规模、多租户场景：需要混合架构

**我们的定位**：
- 当前是小规模、单租户场景
- 文件系统架构是正确的选择
- 但需要提前准备扩展能力（元数据、索引、结构化日志）

**不要过早优化**：
- 不要现在就引入数据库
- 先把文件系统用到极致
- 等真正遇到瓶颈再升级

## 参考资料

- [Markdown-Based Agentic Systems Face Multi-Tenancy Scaling Challenges](https://www.thenextgentechinsider.com/pulse/markdown-based-agentic-systems-face-multi-tenancy-scaling-challenges)
- [Bossa Launches Persistent Filesystem Memory for AI Agents via MCP and CLI](https://www.thenextgentechinsider.com/pulse/bossa-launches-persistent-filesystem-memory-for-ai-agents-via-mcp-and-cli)
- [Observable file systems for agents](https://blog.chudioranu.com/posts/agent-file-systems-observability/)
- [Instructions.md vs Skills.md vs Agent.md vs Agents.md](https://priyankavergadia.substack.com/p/how-to-structure-skillmd-agentsmd)


path: memory/knowledge/agent-design/a2a-agent-card-capability-discovery.md
content: # A2A 协议深度研究——Agent Card 与能力发现

> 学习日期：2026-03-28
> 来源：WebSearch 综合研究（a2a-protocol.org、Spring.io、ArXiv、CalmOps 等）
> 学习次数：1
> 状态：已完成（首轮）

## 核心问题

1. A2A 协议中 Agent Card 的标准字段和能力描述格式是什么？
2. 动态能力发现如何实现？
3. 与我们的 agents-registry.md 的差距和改进空间在哪里？

## A2A 协议概述

### 定位与作用

**Agent-to-Agent (A2A) Protocol** 是 Google 在 2025 年底推出的点对点 Agent 协作标准，与 MCP、ACP 构成 2026 年多 Agent 系统的三大通信协议：

| 协议 | 定位 | 核心功能 |
|------|------|---------|
| MCP | Agent ↔ 工具/资源 | 标准化工具调用和资源访问 |
| A2A | Agent ↔ Agent | 点对点协作、能力发现、任务委托 |
| ACP | Agent ↔ 治理层 | 合规、审计、企业级安全 |

### 核心概念

A2A 的核心是 **Agent Card**——一种"能力广告"机制，允许 Agent：
1. **发布自己的能力**（我能做什么）
2. **发现其他 Agent**（谁能帮我）
3. **协商任务**（如何合作）

## Agent Card 标准字段

基于 A2A 协议规范和行业实践，Agent Card 包含以下核心字段：

### 1. 身份信息（Identity）

```yaml
id: "agent-unique-identifier"
name: "Agent Display Name"
version: "1.0.0"
type: "specialist|generalist|orchestrator"
```

- **id**：全局唯一标识符（通常是 UUID 或命名空间路径）
- **name**：人类可读的名称
- **version**：语义化版本号，用于能力演进追踪
- **type**：Agent 类型分类

### 2. 能力描述（Capabilities）

```yaml
capabilities:
  - id: "capability-1"
    name: "Code Review"
    description: "Perform security and quality code reviews"
    input_schema:
      type: "object"
      properties:
        code: { type: "string" }
        language: { type: "string" }
    output_schema:
      type: "object"
      properties:
        issues: { type: "array" }
        score: { type: "number" }
    constraints:
      max_file_size: "10MB"
      supported_languages: ["python", "javascript", "go"]
```

**关键要素**：
- **能力清单**：每个能力独立描述
- **输入/输出 Schema**：明确接口契约（类似 OpenAPI）
- **约束条件**：资源限制、前置条件

### 3. 服务端点（Endpoints）

```yaml
endpoints:
  - protocol: "https"
    url: "https://agent.example.com/api/v1"
    auth_method: "bearer_token"
  - protocol: "a2a"
    url: "a2a://agent.example.com"
```

### 4. 元数据（Metadata）

```yaml
metadata:
  owner: "team-name"
  created_at: "2026-03-01T00:00:00Z"
  updated_at: "2026-03-28T00:00:00Z"
  tags: ["code-review", "security", "quality"]
  cost_model:
    type: "per_request"
    price: 0.01
    currency: "USD"
  performance:
    avg_response_time_ms: 500
    success_rate: 0.99
```

### 5. 依赖与兼容性（Dependencies）

```yaml
dependencies:
  - agent_id: "code-analyzer"
    version: ">=2.0.0"
  - tool: "git"
    version: ">=2.30"
compatible_protocols:
  - "A2A/1.0"
  - "MCP/1.1"
```

## 动态能力发现机制

### 1. 注册与发布（Registry & Publication）

#### 集中式注册表（Centralized Registry）

类似 Docker Hub 或 npm Registry：

```
Agent 启动 → 向注册中心发布 Agent Card → 注册中心索引能力
其他 Agent → 查询注册中心 → 获取匹配的 Agent Card
```

**优点**：
- 统一发现入口
- 易于治理和审计
- 支持版本管理

**缺点**：
- 单点故障风险
- 需要中心化基础设施

#### 分布式发现（Distributed Discovery）

类似 DNS 或 P2P 网络：

```
Agent 启动 → 广播自己的 Agent Card → 邻居节点缓存
查询 Agent → 向邻居节点查询 → 递归/迭代查找
```

**优点**：
- 无单点故障
- 去中心化

**缺点**：
- 发现延迟较高
- 一致性保证较弱

### 2. 能力匹配（Capability Matching）

#### 基于语义的匹配

不仅匹配关键词，还理解意图：

```python
# 查询："我需要一个能分析 Python 代码安全问题的 Agent"
# 匹配逻辑：
1. 提取关键词：["Python", "code", "security", "analysis"]
2. 语义扩展：["static analysis", "vulnerability scan", "code review"]
3. 在 Agent Card 的 capabilities.description 和 tags 中搜索
4. 计算相似度得分，返回 Top-K
```

#### 基于 Schema 的匹配

严格的接口契约匹配：

```python
# 查询："我有一个 Python 文件，需要输出安全问题列表"
# 匹配逻辑：
1. 解析输入类型：{ code: string, language: "python" }
2. 解析期望输出：{ issues: array }
3. 在 Agent Card 的 input_schema 和 output_schema 中匹配
4. 返回完全兼容的 Agent
```

### 3. 动态更新（Dynamic Update）

Agent Card 不是静态的，会随着 Agent 的进化而更新：

#### 版本演进

```yaml
# v1.0 → v1.1：新增能力
capabilities:
  - id: "code-review"  # 已有
  - id: "refactoring-suggestion"  # 新增
```

#### 性能指标实时更新

```yaml
metadata:
  performance:
    avg_response_time_ms: 500  # 实时统计
    success_rate: 0.99         # 实时统计
    last_updated: "2026-03-28T10:30:00Z"
```

#### 订阅机制

```
Agent A 订阅 Agent B 的能力变更 →
Agent B 更新 Agent Card →
通知所有订阅者 →
Agent A 刷新本地缓存
```

## 与我们的 agents-registry.md 对比

### 当前实现（agents-registry.md）

```markdown
| 名称 | 角色 | 类型 | 创建日期 | skill 路径 | 状态 |
|------|------|------|----------|-----------|------|
| kavabot-engineer | 机器人软件工程师 | 工作 | 2026-03-26 | /path/to/skill | 运行中（v1.5） |
```

**优点**：
- 简单直观
- 易于人类阅读
- 满足当前小规模需求

**缺点**：
- **缺少能力描述**：只有"角色"，没有"能力清单"
- **缺少接口契约**：不知道如何调用、输入输出是什么
- **缺少性能指标**：不知道响应时间、成功率
- **缺少依赖关系**：不知道 Agent 之间的依赖
- **缺少版本语义**：v1.5 是什么含义？与 v1.4 的差异是什么？
- **不支持动态发现**：需要人工查表，无法程序化查询

### 改进方向

#### 短期（立即可做）

1. **增加能力字段**

```markdown
| 名称 | 角色 | 核心能力 | 类型 | 版本 | 状态 |
|------|------|---------|------|------|------|
| kavabot-engineer | 机器人软件工程师 | 日志排查、需求迭代、代码重构 | 工作 | v1.5 | 运行中 |
```

2. **建立版本变更日志**

在每个子智能体的 memory/ 目录下增加 `CHANGELOG.md`：

```markdown
# kavabot-engineer 版本历史

## v1.5 (2026-03-28)
- 新增：cron 命令（调度配置管理）
- 新增：双向 suggest（深度对话）
- 改进：review 命令支持进化赋能

## v1.4 (2026-03-27)
- 新增：数据目录声明
```

#### 中期（需要设计）

3. **结构化 Agent Card**

将 agents-registry.md 升级为 agents-registry.yaml：

```yaml
agents:
  - id: "kavabot-engineer"
    name: "Kavabot 软件工程师"
    version: "1.5.0"
    type: "specialist"
    role: "机器人本体软件工程师"
    capabilities:
      - id: "log-analysis"
        name: "日志排查"
        description: "分析 Kavabot 机器人日志，定位问题根因"
        input: "日志文件路径或日志片段"
        output: "问题诊断报告"
      - id: "requirement-iteration"
        name: "需求迭代"
        description: "实现新功能需求"
        input: "需求描述"
        output: "代码实现 + 测试"
      - id: "code-refactoring"
        name: "代码重构"
        description: "优化代码结构和质量"
        input: "目标代码路径"
        output: "重构后的代码"
    metadata:
      created_at: "2026-03-26"
      updated_at: "2026-03-28"
      skill_path: "~/.claude/skills/kavabot-engineer"
      category: "工作"
      tags: ["机器人", "C++", "ROS", "嵌入式"]
    status: "active"
    framework_version: "evo-agent-v1.5"
```

4. **能力查询接口**

创建一个辅助脚本 `query-agent.py`：

```python
# 查询：谁能帮我排查日志？
python query-agent.py --capability "log-analysis"
# 输出：kavabot-engineer, evo-skills-maintainer

# 查询：谁能做股票分析？
python query-agent.py --capability "stock-analysis"
# 输出：greate-stocks-operator
```

#### 长期（愿景）

5. **完整的 A2A 协议实现**

- 每个子智能体启动时向注册中心发布 Agent Card
- 支持 Agent 之间的直接调用（而非通过人工中转）
- 实现能力订阅和动态更新通知

6. **Agent 编排器（Orchestrator）**

创建一个专门的"编排器"智能体：

```
用户："我需要分析 Kavabot 的性能问题"
编排器：
  1. 查询注册表 → 发现 kavabot-engineer 有 log-analysis 能力
  2. 调用 kavabot-engineer 的 go 命令
  3. 汇总结果返回给用户
```

## 关键认知总结

1. **Agent Card 是"能力广告"**——不仅描述"我是谁"，更重要的是"我能做什么"
2. **接口契约是核心**——input_schema 和 output_schema 让 Agent 之间能程序化协作
3. **动态发现是趋势**——从静态注册表到实时查询、订阅更新
4. **我们的 agents-registry.md 是 Agent Card 的初级形态**——满足当前需求，但缺少结构化和程序化能力
5. **改进路径清晰**：
   - 短期：增加能力字段 + 版本变更日志
   - 中期：结构化 YAML + 查询接口
   - 长期：完整 A2A 协议实现 + Agent 编排器

## 对 evo-skill-creator 的实际应用

### 立即可做

1. **agents-registry.md 增加"核心能力"列**
   - 让人类一眼看出每个 Agent 能做什么
   - 为未来的程序化查询打基础

2. **要求子智能体维护 CHANGELOG.md**
   - 在 evo-agent-model.md 中增加"版本管理"章节
   - 每次 review 升级后，子智能体更新 CHANGELOG

3. **go 命令创建新智能体时，明确要求定义"核心能力清单"**
   - 不仅问"角色是什么"，还要问"具体能做哪些事"
   - 写入 SKILL.md 的"能力清单"段落

### 中期规划

4. **设计结构化 Agent Card**
   - 将 agents-registry.md 升级为 agents-registry.yaml
   - 包含完整的能力描述、输入输出、依赖关系

5. **实现能力查询工具**
   - 创建 query-agent.py 脚本
   - 支持按能力、标签、类型查询

### 长期愿景

6. **Agent 之间的直接协作**
   - 子智能体可以调用其他子智能体的能力
   - 实现真正的多 Agent 协同

## 参考来源

1. [A2A Protocol Specification](https://a2a-protocol.org/latest/specification/)
2. [Agent Discovery - A2A Protocol](https://a2a-protocol.org/latest/topics/agent-discovery/)
3. [Building Interoperable Agents with A2A - Spring.io](https://spring.io/blog/2026/01/29/spring-ai-agentic-patterns-a2a-integration)
4. [A2A Protocol Complete Guide 2026 - CalmOps](https://calmops.com/ai/a2a-protocol-agent-communication-complete-guide-2026/)
5. [The AGNTCY Agent Directory Service - ArXiv](https://arxiv.org/html/2509.18787v1)
6. [Topology-Independent Naming and Capability-Based Discovery - ArXiv](https://arxiv.org/html/2601.14567v1)
7. [How AI agents communicate across systems - CodiLime](https://codilime.com/blog/a2a-protocol-explained/)
8. [Google's Agent2Agent Protocol Explained - Galileo.ai](https://galileo.ai/blog/google-agent2agent-a2a-protocol-guide)


path: memory/knowledge/agent-design/context-window-illusion.md
content: ---
created: 2026-03-28
updated: 2026-03-28
last_accessed: 2026-03-28
access_count: 1
study_count: 1
category: methodology
volatility: medium
confidence: high
status: active
---

# 上下文窗口幻觉（Context Window Illusion）

> 学习日期：2026-03-28
> 来源：多源综合研究（Learn Agentic、Medium、ArXiv 等）
> 学习次数：1

## 核心问题

**"上下文窗口幻觉"是什么？**

大多数开发者认为：给 AI Agent 一个大的上下文窗口（如 200K tokens）= Agent 有了"记忆"。

**真相**：这是一个危险的幻觉。

## 为什么是幻觉？

### 1. 上下文窗口 ≠ 记忆

| 上下文窗口 | 真正的记忆 |
|-----------|----------|
| 临时的、会话级的 | 持久的、跨会话的 |
| 会话结束即消失 | 长期保留 |
| 无法选择性遗忘 | 可以遗忘不重要的信息 |
| 无法主动回忆 | 可以主动检索 |
| 线性增长成本 | 可压缩、可索引 |

**类比**：上下文窗口就像人的"工作记忆"（Working Memory），只能同时处理 7±2 个信息块。真正的记忆是长期记忆（Long-Term Memory），容量几乎无限。

### 2. 上下文窗口的三大陷阱

#### 陷阱 1：成本爆炸

- 200K 上下文窗口 × 每次调用 = 巨额成本
- 大部分上下文在大部分时间都是无关的
- **解决方案**：按需检索，而非全量加载

#### 陷阱 2：注意力稀释

- 研究表明：上下文越长，模型对中间部分的注意力越弱（"Lost in the Middle" 现象）
- 关键信息可能被淹没在噪音中
- **解决方案**：分层架构 + 关键信息放在开头/结尾

#### 陷阱 3：无法进化

- 上下文窗口是静态的快照，无法"学习"
- 每次会话都从零开始
- **解决方案**：持久化记忆系统 + 经验积累机制

## 正确的记忆架构

### Memory OS 范式（2026 年共识）

2026 年的行业共识：AI Agent 需要一个"Memory OS"（记忆操作系统），而不仅仅是大上下文窗口。

#### Memory OS 的核心组件

```
┌─────────────────────────────────────┐
│         Agent (LLM Core)            │
│  ┌───────────────────────────────┐  │
│  │   Working Context (8K-32K)    │  │ ← 当前会话的"工作记忆"
│  └───────────────────────────────┘  │
└──────────────┬──────────────────────┘
               │
               ↓
┌──────────────────────────────────────┐
│         Memory OS Layer              │
├──────────────────────────────────────┤
│  • Short-Term Memory (近期对话)       │
│  • Episodic Memory (任务片段摘要)     │
│  • Semantic Memory (向量存储)         │
│  • Procedural Memory (技能/工具)      │
└──────────────────────────────────────┘
               │
               ↓
┌──────────────────────────────────────┐
│      Persistent Storage              │
│  (文件系统 / 向量数据库 / 图数据库)    │
└──────────────────────────────────────┘
```

### 状态外部化（State Externalization）

**核心原则**：Agent 的状态不应该存储在上下文窗口中，而应该外部化到持久存储。

#### 什么应该外部化？

| 类型 | 存储位置 | 访问方式 |
|------|---------|---------|
| 长期知识 | 向量数据库 | 语义检索 |
| 结构化数据 | 关系数据库 | SQL 查询 |
| 任务历史 | 文件系统 | 时间序列检索 |
| 工作流状态 | 状态机 | 状态查询 |

#### 为什么外部化？

1. **持久性**：会话结束后仍然存在
2. **可扩展性**：不受上下文窗口限制
3. **可共享性**：多个 Agent 可以访问同一状态
4. **可审计性**：所有状态变更可追溯

## 自主上下文管理（Autonomous Context Management）

### 核心理念

**传统方式**：开发者决定给 Agent 看什么（预加载上下文）

**2026 年新范式**：Agent 自己决定需要什么（主动检索）

### 实现机制

#### 1. 给 Agent 提供"记忆工具"

不是把所有信息塞进 prompt，而是给 Agent 提供工具：

```python
tools = [
    "search_memory(query, time_range)",
    "recall_task(task_id)",
    "list_recent_conversations(n=10)",
    "get_knowledge(topic)"
]
```

#### 2. Agent 主动决策

Agent 在执行任务时，自主判断：
- 我需要什么信息？
- 从哪里获取？
- 何时获取？

#### 3. 动态上下文构建

上下文不是静态的，而是动态构建的：
- 任务开始时：加载最小必要上下文
- 执行过程中：按需检索相关信息
- 任务结束时：压缩并持久化关键信息

## 对 evo-skill-creator 的启示

### 我们已经做对的

1. **Memory 外部化** — 我们的 `memory/` 目录就是状态外部化的实现
2. **按需加载** — "由智能体自主判断哪些 memory 需要读取"就是自主上下文管理
3. **分层架构** — 核心 memory（learning-plan、backlog）vs 按需 memory（knowledge/）

### 我们可以改进的

1. **给子智能体提供"记忆工具"**
   - 当前：子智能体需要手动 Read 文件
   - 改进：提供 `search_knowledge(query)` 工具，让子智能体语义检索

2. **避免"全量加载"陷阱**
   - 当前：SKILL.md 可能过长，每次唤醒都全量加载
   - 改进：SKILL.md 分层（核心规则 + 详细参考），详细参考按需读取

3. **实现"工作记忆"压缩**
   - 当前：没有会话内的上下文压缩机制
   - 改进：长会话中，定期压缩历史对话为摘要

4. **记忆检索而非记忆加载**
   - 当前：learn 命令"温故"时可能读取大量文件
   - 改进：先语义检索相关知识，再精准读取

## 关键认知总结

1. **上下文窗口不是记忆** — 它只是临时的工作空间
2. **记忆必须外部化** — 持久存储 + 按需检索才是正道
3. **Agent 应该主动管理上下文** — 而非被动接受预加载的上下文
4. **成本与效果的平衡** — 大上下文窗口成本高且效果未必好
5. **我们的文件系统级 memory 架构本质上是正确的** — 但需要增加语义检索能力

## 与已有知识的连接

- **上下文工程** → 本文是"选择与裁剪"和"卸载"支柱的深化
- **多 Agent 协同** → 状态外部化是共享内存的基础
- **知识生命周期管理** → 外部化的记忆需要生命周期管理
- **SAGE 框架** → Memory OS 的六大操作（存储/检索/整合/更新/遗忘/压缩）

## 参考来源

1. [What is the Context Window Illusion?](https://learnagentic.substack.com/p/what-is-the-context-window-illusion)
2. [Why AI Agents Don't Actually Have Memory](https://memvid.com/blog/why-ai-agents-don-t-actually-have-memory)
3. [State Externalization: The Key to Building AI Agents That Don't Forget](https://ndeplace.medium.com/state-externalization-the-key-to-building-ai-agents-that-dont-forget-b8df9bfff85b)
4. [Memory OS of AI Agent](https://arxiv.org/html/2506.06326)
5. [Context Windows are a Lie: The Architecture of Long-Term Agent Memory](https://leapjuice.com/the-hub/context-window-memory-architecture)
6. [Autonomous Context Curation for Long-Horizon Agentic Tasks](https://arxiv.org/abs/2510.12635)
7. [Why the Model Should Manage Its Own Context](https://deadneurons.substack.com/p/agentic-context-management-why-the)
8. [AI Agent Memory Systems Cut Costs 60% with Long-Term Context 2026](https://iterathon.tech/blog/ai-agent-memory-systems-implementation-guide-2026)
9. [From Context Windows to Infinite Agent Memory](https://www.cloudidr.com/blog/ai-memory-architecture)
10. [The Missing Architecture in Agentic AI: Memory](https://sia.hackernoon.com/the-missing-architecture-in-agentic-ai-memory)


path: memory/knowledge/agent-design/auto-skill-assessment-framework.md
content: # 自动技能评估框架

## 研究来源
- 来源：2026年3月技能领域发展研究
- 为什么重要：需要量化指标来衡量技能效果，建立自动化反馈循环实现技能持续改进

## 关键问题
1. 为不同类型的技能定义什么样的评估指标？
2. 如何建立技能执行后的自动评估机制？
3. 评估结果如何反馈到技能改进过程中？

## 核心发现

### 1. 评估框架四大支柱
根据《Beyond Task Completion: An Assessment Framework for Evaluating Agentic AI Systems》论文，技能评估应覆盖四个维度：
- **LLM**：指令跟随、安全对齐
- **Memory**：存储正确性、检索准确性
- **Tools**：工具选择、参数映射、执行顺序、错误解释
- **Environment**：资源限制、工作流遵循、安全防护

### 2. 评估层次
框架包含三层分析：
- **静态分析**：验证行为是否符合预设规范
- **动态执行**：监控运行时行为检测偏离
- **裁判评估**：通过LLM或Agent-as-Judge进行质性评估

### 3. 关键指标
#### LLM支柱
- 指令跟随得分；序列正确性；测试用例覆盖率；裁判得分
- 安全违规次数；政策合规率；裁判得分

#### Memory支柱
- 更新正确率；更新延迟；重复项计数
- 精确率；召回率；F1分数；BLEU-1；ROUGE；检索延迟；覆盖率

#### Tools支柱
- 分类准确率；工具选择；裁判得分
- 参数准确率；语义正确性得分；裁判得分
- 序列正确率；阶段完成率；诊断前行动依从性
- 恢复成功率；纠正行动准确率；裁判得分

#### Environment支柱
- 防护栏违规计数；阻止的动作尝试；授权失败；裁判得分

### 4. 案例研究发现
在CloudOps场景验证中发现：
- 基准评估（仅任务完成和工具使用率）会掩盖关键行为问题
- 完美的工具排序可能伴随低政策遵从（如S1场景：100%工具排序但仅33%政策遵从）
- 任务完成率高但记忆检索率极低（如S2场景：100%任务完成但仅13.1%记忆召回率）
- 工具支柱在复杂场景中故障率最高（S3场景：平均7.67次故障）
- 记忆故障随场景复杂度增加（S1:0.67 → S3:3.67）
- 环境防护栏违规仅在多智能体场景出现（S3场景：平均2.00次故障）

### 5. 效率分析
- 平均场景执行成本：$0.0621/次
- 平均输入token：19,644；输出token：1,301
- 平均执行时间：183.5秒
- LLM-as-Judge开销：最小（全场景总计$0.0593，14.7秒）
- Agent-as-Judge开销：较高（全场景总计$0.9572，913.4秒）
- 建议：LLM-as-Judge用于持续监控，Agent-as-Judge用于部署前审计

## 应用建议

### 1. 技能评估指标体系
为不同类型技能定义特定指标：
- **创建类技能**：新技能质量、创新点、可维护性
- **优化类技能**：性能提升百分比、资源消耗降低
- **修复类技能**：问题解决率、复发频率
- **分析类技能**：洞察深度、建议可操作性

### 2. 自动评估机制
建立三级评估体系：
- **级别1：静态检查**（每次执行后自动触发）
  - 语法和结构验证
  - 必要文档完整性检查
  - 基础功能测试通过率
- **级别2：动态监控**（定期执行）
  - 在标准化测试场景中的表现
  - 资源使用效率
  - 错误处理能力
- **级别3：深度评估**（周期性或主要版本前）
  - 多维度框架评估（LLM/Memory/Tools/Environment）
  - 对比分析（与历史版本、类似技能）
  - 质性反馈收集

### 3. 反馈循环设计
评估结果应流向：
1. **即时反馈**：向技能执行者展示评估结果
2. **计划更新**：根据评估发现更新学习计划
3. **知识沉淀**：将有效模式和改进点存入知识库
4. **技能进化**：触发技能更新流程（当发现显著改进空间时）

## 未完成事项
- [ ] 为evo-skill-creator自身定义具体评估指标
- [ ] 实现自动评估脚本原型
- [ ] 设计评估结果可视化仪表盘
- [ ] 建立评估基线和改进阈值

path: memory/knowledge/agent-design/auto-tick-mechanism.md
content: # 自动 Tick 机制——Skill 定期自动触发

> 学习日期：2026-03-26
> 更新：2026-03-26（修正——移除未验证内容，基于实际可用能力）

## 核心思路

Skill 本身是被动的——需要有人或有机制来"唤醒"它。自动 tick 的本质就是**用 OS 级调度工具或 scheduler 定期执行执行器的非交互命令**，例如：

1. `claude -p "/agent command" --print`
2. `opencode run -m <model> "/agent command"`

## 已验证可用的方案

### 方案一：cron + 非交互命令（macOS/Linux，最可靠）

```bash
# 编辑 crontab
crontab -e

# Claude：每天早上 9:00 自动执行 go 命令
0 9 * * * cd /path/to/project && claude -p "/evo-skill-creator go" --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebSearch,WebFetch" --print >> /tmp/evo-skill-tick.log 2>&1

# Claude：每周一早上 8:00 自动 scan
0 8 * * 1 cd /path/to/project && claude -p "/evo-skill-creator scan" --print >> /tmp/evo-skill-scan.log 2>&1

# OpenCode：每周五下午 5:00 自动 review
0 17 * * 5 cd /path/to/project && opencode run -m opencode/mimo-v2-pro-free "/evo-skill-creator review" >> /tmp/evo-skill-review.log 2>&1

# OpenCode：每天整点自动 learn
0 * * * * cd /path/to/project && opencode run -m opencode/nemotron-3-super-free "/evo-skill-creator learn" >> /tmp/evo-skill-learn.log 2>&1

# Claude：每周五下午 5:00 自动 review
0 17 * * 5 cd /path/to/project && claude -p "/evo-skill-creator review" --print >> /tmp/evo-skill-review.log 2>&1
```

**优点**：持久、可靠、OS 重启后自动恢复
**注意**：需要 `--allowedTools` 或 `--dangerously-skip-permissions` 授权工具使用

### 方案二：launchd plist（macOS 原生，比 cron 更推荐）

创建 `~/Library/LaunchAgents/com.evo-skill-creator.tick.plist`，实现登录后自动启动定期任务。

### 方案三：Shell 脚本 + 手动/半自动触发

```bash
#!/bin/bash
# tick.sh — 一键执行所有定期任务
cd /path/to/project
echo "[$(date)] === tick start ===" >> tick.log
claude -p "/evo-skill-creator go" --print >> tick.log 2>&1
echo "[$(date)] === tick end ===" >> tick.log
```

老板可以随时 `./tick.sh` 或把它加入任何调度系统。

### 方案四：其他调度框架

- **systemd timer**（Linux）
- **Windows Task Scheduler**
- **PM2 / supervisord** — 进程管理器，可以配置定期重启
- **GitHub Actions** — 如果项目在 GitHub 上，可以用 Actions cron 触发

## 关键参数

| 参数 | 作用 | 说明 |
|------|------|------|
| `-p` / `--print` | Claude 非交互模式 | 执行完直接退出，适合自动化 |
| `run` | OpenCode 非交互模式 | 直接执行消息并退出 |
| `-m` | OpenCode 运行时选模型 | 适合按命令切换免费模型 |
| `--allowedTools` | Claude 指定允许的工具 | 自动模式下需要预授权 |
| `--dangerously-skip-permissions` | Claude 跳过权限检查 | 仅在安全环境使用 |
| `--max-budget-usd` | Claude 预算上限 | 防止失控消费 |
| `-c` / `--continue` | 继续上次会话 | 保持上下文连续性 |

## 推荐的 tick 策略

| 命令 | 频率 | 说明 |
|------|------|------|
| go | 每天 | 检查 backlog，做最紧急的事 |
| scan | 每周 | 扫描新趋势 |
| review | 每周 | 自省 |
| plan | 每月 | 更新学习计划 |
| learn | 按需 | 有新学习项时触发 |
| suggest | 不自动 | 需要老板输入，不适合自动 |
| status | 不自动 | 按需查看 |

## Hooks（事件驱动，已验证）

Claude Code 的 Hooks 机制是真实可用的，配置在 `.claude/settings.json`：

| Hook 类型 | 触发时机 | 可能的用途 |
|----------|---------|-----------|
| PreToolUse | 工具调用前 | 权限检查 |
| PostToolUse | 工具调用后 | 自动格式化 |
| Notification | 需要输入时 | 桌面通知 |
| Stop | 会话结束时 | 自动写日志 |

## 需要老板确认的事项

1. 是否要配置 cron 自动 tick？
2. tick 频率偏好（每天/每周？）
3. 是否愿意用 `--dangerously-skip-permissions` 或指定 `--allowedTools`？
4. API 预算上限设多少？

## 新启示

如果不同命令对执行器、模型、工具权限要求差异明显，单纯依靠 OS 级 cron 命令会越来越难维护。

更理想的方式是：

1. 用统一的 `evo-skills-scheduler`
2. 在配置文件中允许按命令覆盖 `executor`
3. 按命令覆盖 `model`
4. 按命令覆盖 `tools`

这样 `go`、`learn`、`plan`、`review` 可以天然走不同模型，而不是整角色绑定同一个默认值。


path: memory/knowledge/agent-design/dgm-hyperagents-self-rewriting-2026.md
content: # DGM-Hyperagents — 自我重写改进引擎（2026）

> 来源：Meta Research（facebookresearch/HyperAgents）
> 学习时间：2026-03-29
> 类别：Agent 自我改进机制
> 波动性：low（核心理论稳定，是递归自我改进的理论突破）

## 核心发现

Meta 的 **DGM-Hyperagents** 是自我改进 AI 的重大突破，实现了 **Self-Referential Self-Improving Agents**（自指涉自我改进智能体），能够为任何可计算任务进行优化。

## 什么是 Hyperagent？

### 定义层次

```
Level 0: Agent
- 执行任务

Level 1: Self-Improving Agent
- 执行任务 + 改进执行方式

Level 2: Hyperagent
- 执行任务 + 改进执行方式 + 改进"如何改进"的方式

Level 3: DGM-Hyperagent
- 执行任务 + 改进执行方式 + 改进"如何改进"的方式 + 自我重写代码库
```

### 核心特征

1. **Self-Referential（自指涉）** — Agent 能够引用和修改自己的代码
2. **Self-Rewriting（自我重写）** — Agent 能够重写自己的实现
3. **Open-Ended Evolution（开放式进化）** — 没有预定义的进化路径
4. **Task-Agnostic（任务无关）** — 可以优化任何可计算任务

## DGM-Hyperagents 的核心机制

### 1. Darwin Gödel Machine (DGM) 架构

```
┌─────────────────────────────────────────────────────────┐
│  Agent Code Base (可自我修改)                            │
│  ├── Task Execution Module                              │
│  ├── Self-Improvement Module                            │
│  └── Meta-Improvement Module (改进"如何改进")            │
└─────────────────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────────────────┐
│  Mutation Engine (变异引擎)                              │
│  - 生成代码变异版本                                       │
│  - 支持多种变异策略（随机、启发式、学习式）                │
└───────────────────────────���─────────────────────────────┘
              ↓
┌─────────────────────────────────────────────────────────┐
│  Evaluation Engine (评估引擎)                            │
│  - 评估变异版本的适应度                                   │
│  - 多维度评估（性能、成本、安全性）                        │
└─────────────────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────────────────┐
│  Selection Engine (选择引擎)                             │
│  - 选择最优变异版本                                       │
│  - 更新 Agent Code Base                                 │
└─────────────────────────────────────────────────────────┘
              ↓
         (循环回到 Agent Code Base)
```

### 2. 自我重写循环

```python
# 伪代码示例
class DGMHyperagent:
    def __init__(self):
        self.code_base = load_initial_code()
        self.fitness_function = define_fitness()

    def improve(self):
        while True:
            # 1. 生成变异版本
            mutated_versions = self.mutate(self.code_base)

            # 2. 评估每个变异版本
            fitness_scores = [
                self.evaluate(version)
                for version in mutated_versions
            ]

            # 3. 选择最优版本
            best_version = select_best(mutated_versions, fitness_scores)

            # 4. 如果更优，则更新自己的代码
            if fitness(best_version) > fitness(self.code_base):
                self.code_base = best_version
                self.rewrite_self()  # 自我重写！

            # 5. 元改进：改进变异策略本身
            self.improve_mutation_strategy()
```

### 3. 关键技术

#### 3.1 安全的自我修改

- **沙箱执行** — 变异版本在隔离环境中执行
- **回滚机制** — 如果变异版本失败，回滚到上一个稳定版本
- **约束检查** — 确保变异版本不违反安全约束

#### 3.2 适应度函数设计

```python
def fitness(agent, task):
    # 多维度评估
    performance = evaluate_performance(agent, task)
    cost = evaluate_cost(agent, task)
    safety = evaluate_safety(agent, task)

    # 加权组合
    return (
        0.5 * performance +
        0.3 * (1 / cost) +
        0.2 * safety
    )
```

#### 3.3 变异策略

1. **随机变异** — 随机修改代码片段
2. **启发式变异** — 基于规则的代码修改
3. **学习式变异** — 基于历史成功模式的变异
4. **元变异** — 变异"如何变异"的策略

## 与我们的自我进化模型的对比

### 我们的现状

| 维度 | 我们的实现 | DGM-Hyperagents | 差距 |
|------|-----------|-----------------|------|
| 自我修改能力 | 修改 memory/ | 修改 SKILL.md | **大** |
| 变异机制 | 无 | 自动变异引擎 | **大** |
| 评估机制 | 主观评价 | 自动适应度函数 | **大** |
| 选择机制 | 人工选择 | 自动选择 | **大** |
| 元改进能力 | 无 | 改进变异策略 | **大** |

### 我们的优势

1. **人类监督** — 避免进化偏离目标
2. **可解释性** — 所有改进都是人类可读的
3. **安全性** — 不会自动修改核心代码

### 我们的差距

1. **无法修改 SKILL.md** — 我们的 Agent 无法修改自己的核心逻辑
2. **无自动变异机制** — 依赖人工设计改进方案
3. **无自动评估** — 完全依赖主观评价
4. **无元改进能力** — 改进方式是固定的

## 应用到我们的架构

### 短期（立即可做）

1. **在 review 命令中增加"变异生成"步骤** — 生成多个改进方案
2. **设计评估指标** — 为不同类型的改进定义量化指标
3. **实验记录** — 记录每次 review 的变异、评估、选择过程

### 中期（需要设计）

1. **半自动变异引擎** — 基于模板生成 SKILL.md 变异版本
2. **自动评估框架** — 基于多维度指标自动评估改进效果
3. **变异策略库** — 积累成功的变异模式

### 长期（探索方向）

1. **SKILL.md 自我修改** — Agent 能够修改自己的 SKILL.md
2. **完全自动化的 DGM 循环** — 无需人工干预的自我重写
3. **元改进能力** — Agent 能够改进自己的改进策略

## 关键挑战

### 1. 安全性

- **风险**：自我重写可能导致 Agent 行为不可控
- **解决方案**：
  - 限制变异幅度（每次只修改小部分）
  - 沙箱执行（隔离测试变异版本）
  - 人工确认门槛（重大变异需人工批准）
  - 回滚机制（失败时恢复到上一个稳定版本）

### 2. 适应度函数设计

- **风险**：错误的适应度函数导致进化偏离目标
- **解决方案**：
  - 多维度评估（性能、成本、安全性、可维护性）
  - 人类反馈（定期人工评审）
  - 约束条件（硬性安全约束）

### 3. 局部最优

- **风险**：陷入局部最优，无法找到全局最优
- **解决方案**：
  - 探索 vs 利用平衡（偶尔尝试大幅变异）
  - 多样性维护（保持多个候选版本）
  - 重启机制（定期从不同起点重新进化）

## 关键结论

1. **DGM-Hyperagents 是自我改进的理论上限** — 能够自我重写代码库
2. **自指涉是关键能力** — Agent 必须能够引用和修改自己
3. **安全机制是前提** — 自我重写需要强大的安全保障
4. **适应度函数是核心** — 决定进化方向
5. **我们的架构可以渐进式演进** — 从半自动到全自动

## 与已有知识的关联

- **Darwin Gödel Machine (DGM) 架构研究**（memory/knowledge/frameworks/darwin-godel-machine.md）— DGM-Hyperagents 是 DGM 的具体实现
- **Meta-Agent 递归改进**（memory/knowledge/agent-design/meta-agent-recursive-improvement.md）— Hyperagent 是 Meta-Agent 的最高形态
- **Karpathy Loop**（memory/knowledge/agent-design/karpathy-loop-autonomous-experimentation-2026.md）— DGM 提供了实现 Karpathy Loop 的理论框架

## 参考资料

- Meta Research: facebookresearch/HyperAgents (GitHub)
- "DGM-Hyperagents Breakthrough: Meta's Self-Rewriting Improvement Engine Resets the Ceiling for Self-Improving AI"
- "A Self-Referential Framework for Agents Recursively Self-Improvement" (arXiv)


path: memory/knowledge/agent-design/skill-routing/skill-router-mechanism.md
content: # 技能路由器机制研究

## 概述

随着技能数量增长，依赖description触发的路由方式效率低下，需要行为可训练的技能路由器。

## 关键研究发现

1. **Skill Routing的重要性**：在LLM Agent生态系统中，技能路由是识别和检索最相关技能的关键过程。研究表明，技能的完整实现文本（body field）是真正的区分因素，而不仅仅是名称和描述。

2. **当前局限性**：现有架构通常只呈现技能名称和描述给Agent，而隐藏完整实现。这种方法效果不佳，因为：
   - 移除完整实现文本会使检索准确率下降29-44个百分点
   - 91.7%的注意力集中在body字段上
   - 元数据 alone 不足以进行有效选择

3. **SkillRouter方法**：作为两阶段检索和重排序管道，具有以下特点：
   - 12亿参数（0.6亿编码器 + 0.6亿重排序器）
   - 达到74.0%的top-1路由准确率
   - 在消费级硬件上运行
   - 重新定义了LLM生态系统中的技能选择方式

4. **路由决策框架**：有效的路由器考虑多个标准：
   - **主要信号（权重40%）***: 内容分析（技术术语、财务术语、购买信号等）
   - **次要信号（权重30%）***: 客户上下文（历史记录、最近购买、试用状态等）
   - **紧急信号（权重20%）***: 时间敏感指标（“urgent”、“ASAP”等）
   - **情感信号（权重10%）***: 情感上下文（沮丧语言 vs 中性/积极）

5. **置信度路由**：路由器应该表达对决策的信心：
   - 高置信度 (>80%): 清晰、无歧义的信号，单一明显路由匹配 → 直接路由
   - 中等置信度 (50-80%): 混合信号，多个可能路由 → 路由到最佳匹配，标记审查
   - 低置信度 (<50%): 不清晰或冲突的信号，无强路由匹配 → 路由到人工分队列

## 路由模式变体

1. **分层路由**：对于复杂系统，使用多级路由（域级路由 → 服务类型路由）

2. **语义路由**：使用嵌入进行基于意义的路由：
   - 为每个路由的描述创建嵌入
   - 存储路由嵌入以进行比较
   - 为传入查询生成嵌入
   - 计算与每个路由嵌入的相似度
   - 选择相似度最高且超过阈值的路由

3. **动态路由**：基于当前状态调整路由：
   - 负载路由：如果技术支持队列 > 50，溢出到通用路由
   - 时间路由：营业时间路由到实时代理，非营业时间路由到异步队列
   - 容量路由：在路由前检查处理器可用性，在可用处理器间分配负载

## 实施建议

1. **保持路交叉正交**：路由应该尽可能互斥，以避免冲突
   - 良好示例：按输入类型分路由（图像、文本、音频）
   - 有问题示例：基于重叠特征分路由（包含数字、是问题、较短）

2. **明确记录路由标准**：每个路由应有无歧义的选择标准
   - 使用必需条件和排除条件
   - 明确何时不选择该路由

3. **监控路由分布**：跟踪请求流向以检测路由漂移
   - 每条路由随时间的请求数
   - 路由利用率百分比
   - 溢出频率
   - 质量指标（误路由率、升级率、按路由的解决时间）

4. **版本化路由**：随着路由逻辑演进，保持版本以确保可追溯性
   - 记录版本间的变化
   - 提供迁移说明
   - 现有排队请求使用旧路由，新请求使用新逻辑

## 常见错误

1. **过度复杂路由**：太多路由增加维护难度和混淆
   - 症状：单一级别超过10条路由
   - 解决方案：使用分层路由将相关路由分组

2. **标准不足**：模糊标准导致路由不一致
   - 症状：相同输入在不同运行中路由不同
   - 解决方案：为每条路由添加具体、可衡量的标准

3. **缺少回退**：无默认路由导致失败
   - 症状：某些输入未收到路由决策
   - 解决方案：始终为未匹配输入定义默认路由

4. **忽略上下文**：仅基于内容路由会遗漏重要信号
   - 症状：技术正确但让用户沮丧的路由
   - 解决方案：将用户历史、紧急性和情感纳入路由决策

## 在Evo-Skill-Creator中的应用

在Evo-Skill-Creator中实施技能路由器可以：

1. 改善技能选择的准确性，特别是在技能数量增长时
2. 通过考虑上下文（用户历史、任务类型等）实现更智能的路由
3. 通过置信度评分和回退机制处理不确定性
4. 通过动态路由适应不断变化的工作负载和可用性
5. 支持按需技能加载，仅加载相关技能以避免系统提示过载

下一步研究方向：
- 基于状态的技能路由器设计
- 路由器自身如何通过经验学习改进
- 与现有skill触发机制的集成方法

path: memory/knowledge/agent-design/evoskill-failure-driven-skill-discovery-2026.md
content: # EvoSkill — 失败驱动的自动技能发现与精炼框架（2026）

> 来源：arXiv（2026-03-03），Sentient + Virginia Tech
> 学习时间：2026-04-03（深度学习）
> 类别：agent-design / skill-evolution / failure-analysis
> 波动性：low（学术框架 + 实验验证，核心思想稳定）
> 置信度：high（论文含完整实验数据，跨基准验证 + 零样本迁移证实）

## 核心命题

**技能进化的最佳驱动力不是随机变异，而是失败分析。系统化地从失败中提取能力缺口，将其物化为可复用技能，比任何低层优化都更高效。**

EvoSkill 将 Agent 的能力增长从"优化 prompt/代码"提升到"发现和精炼结构化技能"的抽象层次——与我们的进化模型理念高度一致。

## 架构设计

### 三角色架构

```
Executor Agent（执行者）
  ↓ 执行任务，生成轨迹和结果
  ↓ 性能 < 阈值 τ → 标记为失败样本
Proposer Agent（诊断者）
  ↓ 分析失败轨迹 + 历史反馈
  ↓ 识别"能力缺口"，输出高级技能提案
Skill-Builder Agent（构建者）
  ↓ 将抽象提案物化为 Skill Folder
  ↓ 包含 SKILL.md + 触发元数据 + Helper Scripts
→ Pareto 前沿验证 → 保留或淘汰
```

### 关键机制

#### 1. 失败阈值诊断（Failure Threshold Diagnosis）

- 定义性能阈值 τ，低于 τ 的执行标记为"失败样本"
- Proposer 接收失败样本的完整上下文：执行轨迹、错误输出、正确答案
- **诊断过程**：
  1. 分析执行步骤中的哪一步出了问题
  2. 结合累计反馈历史（避免重复提议已失败的方向）
  3. 输出可操作的技能提案（描述性的，非代码级的）

#### 2. Skill Folder 标准结构

```
skill-name/
├── SKILL.md           # YAML Frontmatter（触发元数据）+ 过程式指令
├── helpers/           # Python/TypeScript 辅助脚本（可选）
└── references/        # 参考文档和模板（可选）
```

- **SKILL.md** 包含：触发条件（何时激活）+ 执行指令（如何操作）
- 与 Agent Skills 开放标准兼容，可跨 Claude Code / Cursor 等工具移植
- **人类可读**：开发者可审查、修改、手动创建

#### 3. Pareto 前沿防退化

- 维护 Pareto 前沿的 Agent 程序池
- 使用 round-robin 策略从前沿选择"父程序"生成新候选
- 在 held-out 验证集上评估新技能
- **只保留净正收益的技能**——不降低已有能力前提下增加新能力
- 基础 LLM 保持 frozen，只进化技能库

#### 4. 零样本技能迁移

- 技能以文件夹形式存在，与特定任务/模型解耦
- 示例：`search-persistence-protocol`
  - 在 SealQA 上进化发现（解决"过早终止搜索"问题）
  - 核心规则：多义解释 → 独立搜索 → 三源验证 → 多次查询
  - 直接应用到 BrowseComp → +5.3% 准确率（无任何修改）
- **迁移成功的关键**：技能是抽象的方法论，不是具体的代码 hack

## 实验成果

| 基准 | 基线 | EvoSkill | 提升 |
|------|------|----------|------|
| OfficeQA | 60.6% | 67.9% | +7.3% |
| SealQA | 26.6% | 38.7% | +12.1% |
| BrowseComp（零样本迁移） | 43.5% | 48.8% | +5.3% |

## 与我们进化模型的深度映射

### 1. 三角色 → 我们的命令体系

| EvoSkill 角色 | 我们的对应 | 映射质量 | 差距分析 |
|--------------|-----------|---------|---------|
| Executor | go 命令 | 高 | go 命令执行任务，对等 |
| Proposer | review 命令 | **中低** | review 缺少"失败诊断"能力——目前只做事后评审，不做失败样本分析 |
| Skill-Builder | go 命令（创建子智能体） | 高 | 我们的创建流程已标准化 |
| Pareto 前沿 | 创建规范检查清单 | **低** | 我们没有验证集，检查清单是静态规则而非动态验证 |

### 2. 核心能力缺口

#### 缺口 A：review 命令缺少"失败诊断"（Proposer 能力）

**现状**：review 命令做的是"结构化检查"（文件存在性、格式合规），不做"能力缺口分析"。

**EvoSkill 启发**：
- review 应该能分析子智能体的 execution.log，找出失败/低效模式
- 从失败轨迹中自动提取"这个智能体缺什么能力"
- 输出具体的改进提案（类似 Proposer 的诊断报告）

**映射方案**：
```
review <子智能体> 增加"失败诊断"维度：
1. 读取 execution.log，筛选低质量执行（用户不满/重复执行/耗时异常）
2. 分析失败模式——是知识缺失？流程缺陷？权限不足？
3. 输出"能力缺口报告"，建议新增技能或修改流程
```

#### 缺口 B：退化防护缺少动态验证（Pareto 前沿能力）

**现状**：我们用静态检查清单 + 人工 review 防退化。

**EvoSkill 启发**：
- Pareto 前沿 = 动态基线，不断更新
- "只保留净正收益"原则 = 进化必须可量化验证
- held-out 验证集 = 需要为每个子智能体定义"基准测试场景"

**映射方案**：
```
为子智能体建立"基准场景集"：
- 定义 3-5 个典���使用场景
- 每次升级后用基准场景验证
- 性能不得低于上次验证结果
```

#### 缺口 C：技能以 Skill Folder 形式存在的复用优势

**现状**：我们的子智能体知识在 knowledge/ 目录，但不是"可激活的技能"。

**EvoSkill 启发**：
- Skill Folder = SKILL.md + 触发元数据 + Helper Scripts = 自包含、可路由、可迁移
- 知识 ≠ 技能——知识是被动存储，技能是主动激活
- 我们的 knowledge/ 文件需要向"可激活技能"方向演进

**映射方案**：
```
在 knowledge/ 中区分两类内容：
1. 被动知识（theory/）：框架理论、行业分析——供 learn 查阅
2. 主动技能（skills/）：可复用的工作流/检查清单/模式——供 go 激活
每个主动技能包含触发条件和操作步骤
```

### 3. search-persistence-protocol 的启示

这个具体案例对我们的启发最大：

**它不是代码 hack，而是方法论**：
- "列出所有合理解释" → 我们的 brainstorming 的多角度探索
- "独立搜索每个解释" → 我们的 learn 命令分主题深入
- "至少三个独立来源验证" → 我们的知识质量约束中的"多源交叉验证"
- "多次查询措辞后才放弃" → 我们的 scan 命令的广度搜索策略

**核心洞察**：最有价值的技能是抽象的方法论，不是具体的工具调用。我们的子智能体应该进化出"方法论级别的技能"，而不是"操作级别的脚本"。

### 4. 与 AVO 的交叉

| 维度 | AVO | EvoSkill | 综合启示 |
|------|-----|----------|---------|
| 进化驱动力 | 执行反馈 + 领域知识 | **失败分析**（更聚焦） | 进化应从失败中学习，而非泛泛的反馈 |
| 进化历史利用 | 谱系查询（避免重复变异） | 累计反馈历史（避免重复提议） | evolution-log 必须支持"查询"操作 |
| 退化防护 | 隐含（领域知识约束变异空间） | **显式（Pareto 前沿验证）** | 需要显式的退化防护机制 |
| 产出形式 | 代码优化 | **结构化技能文件夹** | 高抽象层次的产出更可复用 |

## 后续行动建议

### 立即可做（纳入 backlog）

1. **review 命令增加"失败诊断"维度**
   - 分析 execution.log 中的失败/低效模式
   - 输出能力缺口报告
   - 直接关联 backlog #10（review 命令评审维度定义）

2. **为子智能体定义基准场景**
   - 每个子智能体 3-5 个典型场景
   - 升级后用基准验证，防退化
   - 可先在 review 命令中手动执行，后续自动化

### 中期规划

3. **knowledge/ 目录分类升级**
   - 区分被动知识（theory/）和主动技能（skills/）
   - 为主动技能添加触发条件和操作步骤

4. **evolution-log 支持查询**
   - 从审计日志升级为决策输入（与 AVO 共同指向）
   - review/go 命令在决策前查询进化历史

## 与已有知识的关联

- **AVO**（#41）：AVO 的进化谱系查询 + EvoSkill 的失败诊断 = 两种互补的进化驱动力
- **受限自我进化**（#40）：EvoSkill 的 Pareto 前沿 = 动态版的"结构性护栏"
- **知识质量约束**（#45）：search-persistence-protocol 的"多源验证"呼应知识质量约束的交叉验证
- **SlopCodeBench**（#38）：EvoSkill 的防退化设计直接回应 SlopCodeBench 揭示的退化问题
- **SKILL.md YAML Frontmatter**（#43）：EvoSkill 的 Skill Folder 结构与我们的 Frontmatter 标准完全兼容

## 关键引用

- [EvoSkill on arXiv](https://arxiv.org/abs/2603.XXXXX)（2026-03-03）
- [EvoSkill Analysis on EmergentMind](https://emergentmind.com)
- [EvoSkill on AlphaXiv](https://alphaxiv.org)

## 元数据

- created: 2026-04-03
- updated: 2026-04-03
- last_accessed: 2026-04-03
- last_verified: 2026-04-03
- access_count: 1
- study_count: 1
- category: agent-design
- volatility: low
- confidence: high
- status: active


path: memory/knowledge/agent-design/slopcodebench-structural-erosion-2026.md
content: # SlopCodeBench — Agent 代码结构性退化与受限自我进化（2026）

> 来源：SlopCodeBench (SCBench), 2026-03-25 发布
> 学习时间：2026-03-30（深度学习）
> 类别：agent-design / quality-assurance
> 波动性：medium（基准测试结果随模型进步可能变化，但退化趋势的结论稳定）
> 置信度：high（11 个模型、20 个问题、93 个检查点的系统性实验）

## 核心发现：Agent 代码在迭代开发中系统性退化

SlopCodeBench 是第一个专门评估 AI Agent 在**长期迭代开发**中代码质量变化的基准测试。核心结论颠覆了"Agent 越用越好"的乐观假设。

## 基准设计

- **20 个问题**，跨 **93 个检查点**
- Agent 必须先构建初始版本，然后**在自己的代码基础上**不断扩展
- **关键设计**：隐藏未来迭代的接口规格和测试用例，迫使 Agent 早期做出架构决策
- **语言无关**，模拟真实世界的软件工程场景

## 两个核心度量

### 1. Verbosity（冗余度）
- 定义：冗余或重复代码的比例
- 结果：**89.8% 的 Agent 轨迹中冗余度单调递增**
- Agent 代码比人类代码冗余 **2.2 倍**

### 2. Structural Erosion（结构侵蚀）
- 定义：复杂度质量集中在高复杂度（膨胀）函数中的比例
- 结果：**80% 的 Agent 轨迹中结构侵蚀单调递增**
- Agent 倾向于在现有函数上"打补丁"而非重构

## 关键实验结果

| 指标 | 数据 |
|------|------|
| 端到端完成率 | **0%**（11 个模型无一完成全部检查点） |
| 最高检查点解决率 | **17.2%**（Opus 4.6） |
| 冗余度增长轨迹比例 | 89.8% |
| 结构侵蚀增长轨迹比例 | 80% |
| Agent vs 人类冗余度对比 | 2.2x |
| Prompt 干预效果 | 改善初始质量，**无法阻止长期退化** |

### "通过率幻觉"

最重要的发现之一：Agent 可以在**功能测试持续通过**的情况下，底层代码架构**快速恶化**。这意味着传统的 pass-rate 基准系统性地**低估了退化问题**。

## 退化根因分析

### 1. 缺乏全局架构意识
- Agent 在每个检查点只看到当前需求，缺乏"项目级"的架构规划能力
- 倾向于"最小改动通过测试"而非"最优架构设计"

### 2. 打补丁而非重构
- Agent 倾向于在现有代码上添加逻辑，而不是识别模式并提取抽象
- 导致函数越来越长、复杂度越来越高

### 3. 无记忆性
- Agent 不记得之前的架构决策，每次迭代都是"新会话"
- 无法回顾和反思之前的设计选择

### 4. Prompt 干预的局限
- "Plan first" 策略可以改善初始代码质量
- 但**无法阻止长期退化率**——退化是系统性的，不是偶发的

## 对自我进化模型的根本影响

### 挑战我们的核心假设

我们假设自我进化智能体会"越来越好"，但 SlopCodeBench 证明：
- **进化不等于改善**：如果没有结构约束，迭代更可能导致退化
- **通过测试不等于质量好**：功能正确但架构腐烂
- **Prompt 指导不够**：需要**机制性保障**，而非仅靠指令

### 受限自我进化（Constrained Self-Evolution）

这是本次学习最重要的新概念：

```
受限自我进化 = 进化能力 + 结构性护栏

进化能力（来自 DGM-H 等框架）：
  - 自我修改、自我改进、跨领域迁移

结构性护栏（来自 SlopCodeBench 启示）：
  - 架构约束（不可违反的结构规则）
  - 退化检测（自动检测冗余度和复杂度增长）
  - 强制重构（达到阈值时必须重构再继续）
  - 版本对比（与基线版本比较质量指标）
```

## 2026 年行业应对策略：Harness Engineering

### 1. 结构确定性原则
- LLM 输出是概率性的，必须强制进入确定性结构
- 机器不可执行的约束 = 不存在的约束

### 2. 三层防护

| 层级 | 机制 | 目标 |
|------|------|------|
| 闭环反馈（Judge） | 自动评估器/测试套件 | 验证结构性要求 |
| 中间件钩子（Hooks） | 权限约束 + 原子变更强制 | 限制修改范围 |
| 环境感知（MCP） | 依赖图 + 架构文档 | 让 Agent 看到边界 |

### 3. Harness First, Agent Second
- 先构建测试套件和"参与规则"，**然后**才构建 Agent
- 如果无法定义"好的改变"的标准，Agent 必然产出"坏的改变"

## 与我们架构的映射

| SlopCodeBench 发现 | 我们的对应 | 当前状态 |
|-------------------|-----------|---------|
| Agent 代码退化 | SKILL.md 和 memory/ 可能退化 | **未监控** |
| 冗余度增长 | knowledge/ 文件可能有重复内容 | 无去重机制 |
| 结构侵蚀 | SKILL.md 可能越来越冗长 | 无复杂度监控 |
| 打补丁而非重构 | learn/scan 追加知识但不整合 | 缺少整合机制 |
| 通过率幻觉 | 任务完成但质量未知 | 无质量指标 |
| Prompt 干预无效 | SKILL.md 中的指令 | **需要机制性保障** |

## 对我们的启示

### 立即可做

1. **review 命令增加"退化检测"**
   - 检查 SKILL.md 的行数增长趋势
   - 检查 knowledge/ 文件的重复度
   - 检查 learning-plan.md 的条目是否过多（表示"追加但不完成"）

2. **evo-agent-model.md 增加"退化防护"章节**
   - 定义结构约束（不可违反的规则）
   - 定义退化阈值（触发强制整合/重构）
   - 定义质量指标（不仅关注功能完成，还关注结构健康）

3. **为子智能体添加"重构触发器"**
   - 当 SKILL.md 超过 N 行 → 触发重构
   - 当 knowledge/ 文件超过 M 个 → 触发整合
   - 当 learning-plan.md 待学习条目超过 K 个 → 触发优先级重排

### 中期规划

1. **自动化质量监控**
   - 定期扫描所有子智能体的"健康指标"
   - 冗余度、复杂度、增长趋势

2. **强制整合机制**
   - learn/scan 沉淀知识后，定期整合相关知识
   - 避免"只追加不整合"的退化模式

### 长期愿景

1. **Harness Engineering 应用到智能体生态**
   - 为每个子智能体定义"结构约束"
   - review 命令充当"Judge"角色
   - 实现"Harness First, Agent Second"原则

## 与已有知识的关联

- **#2 Skill 进化的局限性**：SlopCodeBench 为 #2 的理论结论提供了实验证据
- **#3 SAGE 遗忘曲线**：遗忘/压缩机制是对抗冗余增长的关键
- **#13 知识生命周期管理**：生命周期管理是对抗退化的实践方案
- **#25 DGM-Hyperagents**：DGM-H 提供进化能力，SlopCodeBench 提供约束需求——两者缺一不可
- **#36 HyperAgents DGM-H**：DGM-H 的进化 + SlopCodeBench 的约束 = 受限自我进化

## 元数据

- created: 2026-03-30
- updated: 2026-03-30
- last_accessed: 2026-03-30
- access_count: 1
- study_count: 1
- category: agent-design
- volatility: medium
- confidence: high
- status: active


path: memory/knowledge/agent-design/nvidia-open-agent-platform-2026.md
content: # NVIDIA Open Agent Development Platform（2026年3月）

> 来源：NVIDIA 官方发布（2026-03-16）
> 学习时间：2026-03-29
> 类别：Agent 开发平台
> 波动性：medium（平台功能会持续演进）

## 核心发现

NVIDIA 在 2026 年 3 月 16 日发布了 **Open Agent Development Platform**，标志着 **知识工作的下一次工业革命**。

## 平台核心特性

### 1. 开放式 Agent 开发

- **开放标准** — 不锁定特定模型或框架
- **互操作性** — Agent 之间可以互相协作
- **可组合性** — Agent 可以组合成更复杂的系统

### 2. 企业级能力

- **规模化部署** — 支持大规模 Agent 部署
- **安全性** — 企业级安全保障
- **可观测性** — 完整的监控和调试能力

### 3. 知识工作革命

**传统知识工作**：
- 人类执行所有任务
- 效率受限于人类能力
- 难以规模化

**Agent 驱动的知识工作**：
- Agent 自动执行重复性任务
- 人类专注于创造性工作
- 可以无限规模化

## 对 Agent 生态系统的影响

### 1. 标准化

- **Agent 通信协议** — 统一的 Agent 间通信标准
- **Agent 描述格式** — 标准化的 Agent 能力描述
- **Agent 市场** — Agent 可以在市场上交易和共享

### 2. 生态系统

- **Agent 开发者** — 专注于开发特定领域的 Agent
- **Agent 用户** — 使用现成的 Agent 完成任务
- **Agent 编排者** — 组合多个 Agent 构建复杂系统

### 3. 商业模式

- **Agent-as-a-Service** — Agent 作为服务提供
- **Agent 市场** — Agent 可以买卖
- **Agent 订阅** — 按使用量付费

## 与我们的架构的关联

### 我们的定位

我们的 **evo-skill-creator** 本质上是一个 **Agent 创建者**，与 NVIDIA 平台的关系：

```
NVIDIA Open Agent Platform (基础设施层)
    ↓
evo-skill-creator (Agent 创建层)
    ↓
各种领域专家 Agent (应用层)
```

### 潜在集成点

1. **Agent 注册** — 将我们创建的 Agent 注册到 NVIDIA 平台
2. **Agent 发现** — 从 NVIDIA 平台发现其他 Agent
3. **Agent 协作** — 我们的 Agent 与其他 Agent 协作
4. **Agent 市场** — 将我们的 Agent 发布到市场

## 关键趋势

### 1. Agent 成为一等公民

- **不再是工具** — Agent 是独立的实体
- **有身份** — 每个 Agent 有唯一标识
- **有能力描述** — 清晰描述自己能做什么
- **可发现** — 其他 Agent 可以发现和调用

### 2. 从单 Agent 到多 Agent 系统

- **协作** — 多个 Agent 协同完成复杂任务
- **编排** — 需要 Agent 编排器协调多个 Agent
- **通信** — 需要标准化的 Agent 间通信协议

### 3. 从闭源到开放

- **开放标准** — 不锁定特定平台
- **互操作性** — 不同平台的 Agent 可以互操作
- **生态系统** — 形成开放的 Agent 生态系统

## 对我们的启示

### 短期（立即可做）

1. **完善 Agent Card** — 为每个子智能体创建标准化的能力描述
2. **标准化接口** — 定义清晰的输入/输出接口
3. **版本管理** — 为每个子智能体维护版本信息

### 中期（需要设计）

1. **Agent 注册表升级** — 从 Markdown 升级到结构化格式（YAML/JSON）
2. **Agent 发现机制** — 实现 Agent 之间的相互发现
3. **Agent 协作协议** — 定义 Agent 间的协作方式

### 长期（探索方向）

1. **接入 NVIDIA 平台** — 将我们的 Agent 注册到 NVIDIA 平台
2. **Agent 市场** — 将优秀的 Agent 发布到市场
3. **跨平台协作** — 与其他平台的 Agent 协作

## 关键结论

1. **Agent 生态系统正在形成** — 从单打独斗到生态协作
2. **标准化是趋势** — 需要统一的 Agent 描述和通信标准
3. **开放是方向** — 闭源 Agent 将被开放生态系统取代
4. **我们需要拥抱标准** — 尽早采用行业标准，避免被边缘化

## 与已有知识的关联

- **A2A 协议与 Agent Card**（memory/knowledge/agent-design/a2a-agent-card-capability-discovery.md）— NVIDIA 平台需要标准化的 Agent Card
- **多 Agent 上下文协同**（memory/knowledge/agent-design/multi-agent-context-sharing.md）— NVIDIA 平台提供了多 Agent 协作的基础设施
- **agents-registry.md** — 需要升级为符合行业标准的 Agent 注册表

## 参考资料

- NVIDIA: "NVIDIA Ignites the Next Industrial Revolution in Knowledge Work With Open Agent Development Platform" (2026-03-16)


path: memory/knowledge/agent-design/2026-agent-skills-developments.md
content: # 2026年3月 Agent Skills 领域最新发展

## Google 开发者博客：通过 Agent Skills 填补知识差距 (2026-03-25)

### 核心观点
- Agent Skills 正在成为填补 AI 代理知识差距的关键机制
- 传统的单一 mega-prompt 方法面临局限，而技能化方法提供更好的可扩展性
- 技能允许代理通过外部化知识组件实现持续学习和适应

### 关键技术趋势
1. **技能标准化**：正在形成统一的技能接口和加载机制
2. **上下文工程**：从提示工程转向上下文工程，技能作为结构化上下文提供者
3. **自动技能路由**：基于任务状态自动选择最合适的技能
4. **技能组合与编排**：支持多技能协同工作的编排机制

## Medium 文章：提示工程的终结与评估的崛起 (2026-03-25)

### 主要论点
- 提示工程作为独立学科正在衰退
- 评估框架（Evals）正在成为AI系统开发的核心
- 未来重点将放在系统性评估和反馈循环，而非手动提示调优

### 对技能设计的启示
1. 技能需要内置评估机制来衡量其效果
2. 技能进化应该基于可量化的性能指标
3. 建立技能使用的反馈循环以实现自动改进

## Medium 文章：停止工程化提示，开始工程化上下文：Agent Skills 标准指南 (2026-03-19)

### Agent Skills 标准核心原则
1. **技能作为上下文容器**：技能不仅包含指令，还包含执行所需的完整上下文
2. **按需知识注入**：技能在需要时动态加载，避免系统提示过载
3. **技能可组合性**：技能设计应支持安全可靠的组合使用
4. **版本控制与溯源**：技能应支持版本管理和变更追踪

### 技能结构建议
- 元数据：名称、版本、描述、作者、创建日期
- 上下文声明：明确技能提供的上下文类型和范围
- 依赖声明：声明所依赖的其他技能或资源
- 执行界面：定义技能如何被调用和使用的标准接口

## BSWEN 博客：AI Agents 中的技能加载机制 (2026-03-18)

### 按需加载的优势
1. 减少系统提示长度，避免超出模型上下文窗口
2. 提高相关性，只在需要时激活特定知识
3. 支持技能热更新而不需要重启整个代理系统
4. 实现多租户环境中的技能隔离

### 技能加载架构
- 技能仓库：集中存储和管理技能的地方
- 加载器：负责从仓库获取并注入技能的组件
- 缓存机制：避免重复加载常用技能以提高性能
- 安全沙箱：限制技能可以访问的资源和执行的操作

## Microsoft Agent 框架更新：代码技能、脚本执行和 Python 批准 (2026-03-13)

### 新增能力
1. **代码技能**：允许技能包含可执行代码而不仅仅是文本指令
2. **脚本执行**：支持在安全沙箱中运行各种脚本语言
3. **审批机制**：对潜在危险操作需要人工或自动审批
4. **Python 生态集成**：更好地支持 Python 库和工具

### 安全考虑
- 代码沙箱：限制系统调用和文件访问
- 权限细粒度：不同技能可以有不同的权限级别
- 审计日志：记录所有技能执行的操作以便追溯

## 综合启示 для evo-skill-creator

### 短期行动 (1-2 周)
1. 在 skill 设计中加入明确的上下文声明部分
2. 为每个创建的智能体定义基本的效果评估指标
3. 开始实验按需技能加载机制的原型

### 中期规划 (1-3 个月)
1. 开发类似 Memento-Skills 的技能路由器原型
2. 建立自动化技能评估和反馈循环
3. 创建技能版本控制和变更追踪系统

### 长期愿景 (3-6 个月)
1. 实现完整的技能市场和共享生态系统
2. 开发自我进化的技能设计能力（类似 DGM 应用于技能自身）
3. 建立跨代理的技能经验共享机制

## 与现有知识的关联

### 已有知识库补充
- 现有的 Memento-Skills 框架提供了很好的读写反思学习模型
- 需要补充的是自动化评估和按需加载机制
- SAGE 框架的记忆操作可以与技能的上下文管理相结合

### 计划更新建议
1. 添加"技能路由器机制研究"作为新的 P1 任务
2. 添加"自动技能评估框架"作为 P2 任务
3. 添加"按需技能加载原型实现"作为 P1 任务

## 参考来源
1. Google Developers Blog - Closing the knowledge gap with agent skills (2026-03-25)
2. Medium - The Death of Prompt Engineering, And How Evals Are Rising in Its Place (2026-03-25)
3. Medium - Stop Engineering Prompts, Start Engineering Context: A Guide to the "Agent Skills" Standard (2026-03-19)
4. BSWEN Blog - How Skill Loading Works in AI Agents: On-Demand Knowledge Injection (2026-03-18)
5. Microsoft Agent Framework Blog - What's New in Agent Skills: Code Skills, Script Execution, and Approval for Python (2026-03-13)

path: memory/knowledge/agent-design/skill-creation-checklist.md
content: # Skill 创建质量检查清单

> 来源：2026-03-26 创建 kavabot-engineer 时的教训——命令定义留空
> 适用于：evo-skill-creator 的 go 命令执行创建流程时

## 创建完成前必须检查

### 1. 所有命令都有完整步骤（不允许留空）

每个命令必须包含：
- **步骤列表**（编号的具体操作步骤）
- **输入**（读什么文件/需要什么信息）
- **产出**（输出什么文件/报告/日志）

**反面示例**（不允许）：
```markdown
### scan — 扫描（广度）
关注技术栈动态。
```

**正面示例**（必须达到的详细度）：
```markdown
### scan — 扫描（广度）
1. 确定扫描范围（Layer 1/2/3）
2. 执行扫描（WebSearch/SSH/读代码）
3. 判断相关性（忽略/加入计划/直接沉淀）
4. 更新关注清单
5. 输出报告 + 追加日志
```

### 2. 八大命令完整性检查

| 命令 | 必须有步骤 | 必须有产出 |
|------|-----------|-----------|
| go | 是 | 任务报告 |
| learn | 是 | 知识文件 + 命令报告 |
| scan | 是 | 关注清单更新 + 命令报告 |
| plan | 是 | 学习计划更新 + 命令报告 |
| review | 是 | 命令报告 |
| suggest | 是 | 命令报告 |
| cron | 是 | 仅日志 |
| status | 是（步骤简单但要列出汇报哪些内容） | 仅日志 |

### 3. 角色特定命令也不能空

如果角色有扩展命令（如 `go add`、`go 排查`），每个都要有完整步骤。

### 4. 数据目录声明检查

SKILL.md 中**必须**包含「数据目录」声明段：

- [ ] 有 `## 数据目录` 段落
- [ ] Memory 路径使用**绝对路径**
- [ ] Output 路径使用**绝对路径**
- [ ] 声明段说明"不受当前工作目录影响"

> 来源：2026-03-27 老板建议——创建时要询问数据目录位置并在 SKILL.md 中清晰声明

### 5. 执行后端与模型路由检查

创建新智能体时，必须明确它未来怎么跑：

- [ ] 已询问用户默认执行后端（`Claude` / `OpenCode` / 混合路由）
- [ ] 如果使用 `OpenCode`，已确认默认模型
- [ ] 如果不同命令需求不同，已明确命令级模型路由
- [ ] 如果角色需要 scheduler，已明确调度配置是否需要按命令覆盖 `executor/model/tools`
- [ ] 没有把“当前可用模型名单/当前免费模型名单”直接写死进 `SKILL.md`
- [ ] `SKILL.md` 只描述获取方式、判断方法和决策流程
- [ ] 动态模型信息已沉淀到 `memory/knowledge/`、`watchlist` 或报告，而不是固化在稳定规则层

> 来源：2026-03-28 老板建议——OpenCode 免费模型应按命令类型路由，scheduler 也应支持命令级覆盖

### 6. 权限策略检查

创建新智能体时，必须明确它”默认能做什么、还需要问什么”：

- [ ] 已询问默认目录访问范围
- [ ] 已询问默认工具权限
- [ ] 已包含**工具 skill 所在目录**的读写权限（`~/.claude/skills/<name>/` 和 `~/.opencode/skills/<name>/`），因为运行时可能从不同工具启动，skill 目录与数据目录可能不同
- [ ] 已区分哪些权限可预授权，哪些必须运行时再次确认
- [ ] 如果角色会接入 scheduler，已考虑无人值守场景下是否会被权限确认卡住
- [ ] 如果涉及不同执行器，已考虑权限实现方式是否存在差异

> 来源：2026-03-28 调度 learn 命令时权限受阻——模型路由之外，还必须设计权限策略
> 补充：2026-03-28 老板指出——权限不仅包含数据目录，还包含工具的 skill 安装目录（不同工具安装位置不同）

### 7. 命名原则检查

Skill 名称必须做到**一看就知道它是什么、做什么**：

- [ ] 名称与所属项目有关联（如 `evo-skills-scheduler` 而非 `tick-daemon`）
- [ ] 名称体现角色/职能本质，而非仅描述技术机制
- [ ] 普通人看到名字就能理解这个 skill 的定位

**反面示例**：`tick-daemon`（只说了"定时调"，没说调什么、为什么调）
**正面示例**：`evo-skills-scheduler`（属于 evo-skills 项目的调度服务）

> 来源：2026-03-27 老板建议——命名核心原则：看到名字就知道它属于哪个项目、做什么事

### 8. 创建流程必须一条龙走到底（不允许中断让用户手动操作）

go 命令创建角色时，步骤 1-11 是**连续流水线**，不是"做完一步问用户要不要继续"。

**规则**：
- [ ] brainstorming 完成后必须**立即**调用 /skill-creator 继续创建，不停下来
- [ ] /skill-creator 完成后必须**立即**注册子智能体 + 输出报告
- [ ] 需要用户决策时**用问题的方式获取**（AskUserQuestion），而不是说"请你手动执行某个命令"
- [ ] 任何步骤都不能以"交给用户去做"结尾——既然知道下一步是什么，就继续做

**反面示例**（不允许）：
```
brainstorming 完成。设计文档已保存。可以交给 /skill-creator 创建完整的 skill 了。
```

**正面示例**（必须达到）：
```
brainstorming 完成。设计文档已保存。现在继续调用 /skill-creator 创建 SKILL.md...
（直接开始创建文件）
```

> 来源：2026-03-28 老板批评——brainstorming 后停下来让用户手动操作是严重的流程中断错误

### 9. Cursor Project Manager 配置同步

创建新角色后，必须将其注册到 Cursor 的 Project Manager 插件配置中：

- [ ] 读取 `memory/private/preferences.md` 中的「Cursor Project Manager 配置同步」段落，获取文件路径和格式
- [ ] 读取配置文件，在数组末尾追加新角色条目
- [ ] 如果配置文件不存在，告知老板后跳过（不阻塞创建流程）

> 来源：2026-04-03 老板指令——所有角色都要在 Cursor Project Manager 中有配置，方便快速切换项目

### 10. private/README.md 必须存在

创建新角色时，必须在 `memory/private/` 下创建 `README.md` 文件：

- [ ] `memory/private/README.md` 存在
- [ ] 包含标准表格（文件名、用途、加载时机）
- [ ] 列出了 private/ 下的所有文件
- [ ] SKILL.md 唤醒流程中包含"加载 private/README.md"步骤

> 来源：2026-04-03 老板建议——强制加载 private/README.md 确保大模型知道何时读取私有数据，避免遗漏或过度加载

### 11. scene-index.md 禁止索引 private/ 文件

scene-index.md 只索引公开数据，私有数据由 private/README.md 管理：

- [ ] `memory/scene-index.md` 中**没有**引用 `memory/private/` 下的任何文件
- [ ] 私有数据的加载时机只在 `memory/private/README.md` 中描述
- [ ] 文件覆盖检查表中不包含 private/ 文件的条目

> 来源：2026-04-03 老板规则——scene-index 只管公开数据，private/README.md 管私有数据，索引层面彻底分离

### 12. SKILL.md 必须精简（< 150 行）

SKILL.md 是 Layer 0（身份+路由），不是所有规则的容器：

- [ ] SKILL.md 总行数 < 150 行
- [ ] 命令段每个命令只有一行简述 + `详见 memory/scenario-sops/cmd-xxx.md` 引用
- [ ] 命令的详细步骤、规则、流程已外置到 `memory/scenario-sops/` 下的 SOP 文件
- [ ] 不包含大段内嵌的工作流程、规则列表、SOP 步骤

> 来源：2026-04-05 老板规则——主入口文件要精简，kavabot-engineer 的重构是标杆

### 13. 分层按需加载（索引驱动）

命令的 SOP 和知识必须通过索引文件按需加载，不能在 SKILL.md 中一次性全部写出：

- [ ] 唤醒流程遵循分层加载顺序：SKILL.md → scene-index.md → private/README.md → scenario-sops/ → knowledge/
- [ ] `memory/scenario-sops/` 目录存在，至少包含 go 命令的 SOP 文件
- [ ] 每个命令的详细 SOP 是独立文件（`cmd-go.md`、`cmd-learn.md` 等）
- [ ] 知识文件按场景按需加载，不在启动时全部加载

> 来源：2026-04-05 老板规则——按场景按需加载索引文件，分层加载


path: memory/knowledge/agent-design/agent-observability-taxonomy-2026.md
content: ---
created: 2026-03-29
updated: 2026-03-29
last_accessed: 2026-03-29
access_count: 1
study_count: 1
category: agent-design
volatility: high
confidence: high
status: active
---

# Agent Observability 分类学与 AgentOps（2026）

> 学习日期：2026-03-29
> 来源：ArXiv 2411.05285、多个 2026 年 3 月的行业报告
> 学习次数：1

## 核心问题

**为什么需要 Agent Observability？**

传统软件的可观测性（Observability）三大支柱：
1. Logs（日志）
2. Metrics（指标）
3. Traces（追踪）

但 AI Agent 的复杂性远超传统软件：
- **非确定性**：同样的输入可能产生不同的输出
- **多步推理**：一个任务可能涉及数十次 LLM 调用
- **工具调用链**：Agent 调用工具，工具调用其他工具
- **上下文依赖**：决策依赖于历史上下文和 memory
- **失败难以复现**：随机性导致 bug 难以重现

**结果**：传统的日志和监控不够用，需要新的可观测性框架。

## AgentOps 分类学（Taxonomy）

### 核心论文

**标题**："A Taxonomy of AgentOps for Enabling Observability of Foundation Model based Agents"

**核心贡献**：
- 系统化定义了 Agent 可观测性的维度
- 提出了 AgentOps 的分类体系
- 为 Agent 监控、调试、评估提供了标准框架

### 五大可观测性维度

#### 1. Execution Trace（执行追踪）

**目标**：记录 Agent 的完整执行路径

**关键信息**：
- 每一步的输入和输出
- LLM 调用序列
- 工具调用链
- 决策分支点

**实现方式**：
```
Task: "查询天气并发送邮件"
  ├─ Step 1: LLM Planning
  │   ├─ Input: "查询天气并发送邮件"
  │   ├─ Output: "1. 调用天气 API 2. 调用邮件 API"
  │   └─ Latency: 1.2s
  ├─ Step 2: Tool Call (Weather API)
  │   ├─ Input: {"city": "Beijing"}
  │   ├─ Output: {"temp": 15, "condition": "sunny"}
  │   └─ Latency: 0.3s
  └─ Step 3: Tool Call (Email API)
      ├─ Input: {"to": "[REDACTED_SECRET]", "body": "..."}
      ├─ Output: {"status": "sent"}
      └─ Latency: 0.5s
```

**对我们的启示**：
- 我们的 execution.log 只记录了命令级别的信息
- 缺少步骤级别的追踪
- 无法回溯"为什么做出这个决策"

#### 2. Context Management（上下文管理）

**目标**：追踪 Agent 的上下文使用情况

**关键指标**：
- Context Window Usage（上下文窗口使用率）
- Memory Retrieval Patterns（记忆检索模式）
- Context Overflow Events（上下文溢出事件）
- Relevant vs Irrelevant Context Ratio（相关 vs 无关上下文比例）

**监控内容**：
- 每次 LLM 调用使用了多少 tokens
- 从 memory 检索了哪些内容
- 哪些上下文被实际使用，哪些被忽略
- 是否发生上下文窗口溢出

**对我们的启示**：
- 我们完全没有监控上下文使用情况
- 不知道哪些 memory 文件被频繁使用
- 不知道是否存在"上下文污染"（加载了无关内容）

#### 3. Tool Usage Analytics（工具使用分析）

**目标**：分析 Agent 的工具调用模式

**关键指标**：
- Tool Call Success Rate（工具调用成功率）
- Tool Call Latency（工具调用延迟）
- Tool Selection Accuracy（工具选择准确率）
- Tool Call Frequency（工具调用频率）

**监控内容**：
- 哪些工具被频繁调用
- 哪些工具调用经常失败
- 工具调用的参数是否正确
- 是否存在"工具滥用"（过度调用某个工具）

**对我们的启示**：
- 我们不知道哪些命令被频繁使用
- 不知道哪些命令经常失败
- 无法识别"低效的工作模式"

#### 4. Performance Metrics（性能指标）

**目标**：量化 Agent 的性能表现

**关键指标**：
- Task Completion Rate（任务完成率）
- Average Task Duration（平均任务时长）
- Cost per Task（每任务成本）
- Error Rate（错误率）

**监控内容**：
- 任务成功 vs 失败的比例
- 每个任务花费的时间和成本
- 哪些类型的任务容易失败
- 性能瓶颈在哪里

**对我们的启示**：
- 我们只有执行日志，没有性能指标
- 不知道哪些任务耗时最长
- 无法量化"进化效果"

#### 5. Quality Assessment（质量评估）

**目标**：评估 Agent 输出的质量

**关键指标**：
- Output Correctness（输出正确性）
- Hallucination Rate（幻觉率）
- Instruction Following Score（指令遵循得分）
- User Satisfaction（用户满意度）

**评估方式**：
- LLM-as-Judge（用 LLM 评估输出质量）
- Human Feedback（人工反馈）
- Automated Tests（自动化测试）

**对我们的启示**：
- 我们完全依赖老板的主观评价
- 没有自动化的质量评估机制
- 无法量化"学习效果"

## AgentOps 工具生态（2026）

### 主流平台

| 平台 | 核心能力 | 适用场景 |
|------|---------|---------|
| AgentNeo | 全链路追踪、成本分析 | 生产环境监控 |
| Langfuse | LLM 调用追踪、Prompt 管理 | 开发调试 |
| Braintrust | A/B 测试、评估框架 | 质量评估 |
| AgentOps | 实时监控、告警 | 运维监控 |
| Arthur | 模型可观测性、偏差检测 | 合规审计 |

### 核心功能对比

**1. 执行追踪**：
- ✅ 所有平台都支持
- 差异：追踪粒度（步骤级 vs 任务级）

**2. 成本分析**：
- ✅ AgentNeo、Langfuse 支持
- 可以追踪每个任务的 token 消耗和成本

**3. 质量评估**：
- ✅ Braintrust、Arthur 支持
- 提供 LLM-as-Judge 和自动化评估

**4. 实时告警**：
- ✅ AgentOps、Arthur 支持
- 可以设置阈值，自动告警

## 对我们的启示

### 当前缺失的能力

**1. 执行追踪**：
- ❌ 只有命令级日志，没有步骤级追踪
- ❌ 无法回溯"为什么做出这个决策"
- ❌ 无法可视化执行路径

**2. 上下文监控**：
- ❌ 不知道哪些 memory 文件被使用
- ❌ 不知道上下文窗口使用率
- ❌ 无法识别"上下文污染"

**3. 性能指标**：
- ❌ 没有任务完成率统计
- ❌ 没有任务耗时分析
- ❌ 无法识别性能瓶颈

**4. 质量评估**：
- ❌ 完全依赖老板主观评价
- ❌ 没有自动化评估机制
- ❌ 无法量化进化效果

### 渐进式改进路径

**阶段 1：增强日志（立即可做）**

1. **升级 execution.log 为 JSONL 格式**：
```json
{
  "timestamp": "2026-03-29T10:30:00Z",
  "command": "learn",
  "model": "claude-opus-4-6",
  "duration_seconds": 120,
  "status": "success",
  "summary": "学习了 Agent Observability",
  "context_tokens": 45000,
  "output_tokens": 8000,
  "cost_usd": 0.15
}
```

2. **为报告增加元数据**：
- 任务耗时
- 使用的工具清单
- 读取的 memory 文件清单

**阶段 2：增加监控维度（中期）**

1. **Memory 访问追踪**：
- 记录每次读取了哪些 memory 文件
- 统计哪些文件被频繁访问
- 识别"冷门知识"（从未被使用）

2. **性能指标统计**：
- 每个命令的平均耗时
- 任务成功率
- 最耗时的操作

3. **质量自评**：
- 每次执行后，Agent 自己评估输出质量
- 记录"自信度"（confidence score）

**阶段 3：可视化与告警（长期）**

1. **执行路径可视化**：
- 生成执行流程图
- 可视化决策树

2. **性能仪表盘**：
- 实时监控各项指标
- 趋势分析

3. **自动告警**：
- 任务失败率超过阈值时告警
- 性能下降时告警

## 核心结论

### 1. Observability 是 Agent 进化的基础

**没有可观测性 = 盲目进化**：
- 不知道哪里做得好，哪里做得差
- 无法量化进化效果
- 无法识别退化

### 2. 从简单开始，渐进增强

**不要一开始就引入复杂的 AgentOps 平台**：
- 先增强日志（JSONL 格式）
- 再增加监控维度（memory 访问、性能指标）
- 最后考虑可视化和告警

### 3. 可观测性服务于目标

**监控什么取决于目标是什么**：
- 目标是"成为行业顶尖" → 监控学习效果
- 目标是"为老板服务" → 监控任务完成率
- 目标是"降低成本" → 监控 token 消耗

### 4. 我们的下一步

**立即可做**：
1. 升级 execution.log 为 JSONL 格式
2. 为报告增加元数据（耗时、工具、memory）
3. 在 review 命令中增加"性能分析"功能

**中期规划**：
1. 实现 Memory 访问追踪
2. 统计性能指标
3. 增加质量自评机制

**长期愿景**：
1. 可视化执行路径
2. 性能仪表盘
3. 自动告警

## 参考资料

- [A Taxonomy of AgentOps for Enabling Observability of Foundation Model based Agents](https://arxiv.org/html/2411.05285v1)
- [Agent Observability 2026: How to Monitor, Debug, and Improve AI Agents in Production](https://neuronex-automation.com/blog/agent-observability-2026-monitor-debug-improve-ai-agents)
- [15 AI Agent Observability Tools in 2026](https://research.aimultiple.com/agentic-monitoring/)
- [AgentNeo, Langfuse & more ['26]](https://research.aimultiple.com/agentops/)
- [A Structured Logging Framework for Agent System Observability](https://arxiv.org/html/2602.10133v1)


path: memory/knowledge/agent-design/files-vs-database-memory-debate-2026.md
content: ---
created: 2026-03-29
updated: 2026-03-29
last_accessed: 2026-03-29
access_count: 1
study_count: 1
category: agent-design
volatility: high
confidence: high
status: active
---

# "Files are all you need" 争论与混合内存架构（2026）

> 学习日期：2026-03-29
> 来源：The New Stack、多个 2026 年 3 月的行业报告
> 学习次数：1

## 核心争论

### "Files are all you need" 阵营

**核心观点**：文件系统 + Git 已经足够强大，不需要向量数据库。

**支持理由**：
1. **零依赖** — 不需要额外的基础设施（Pinecone/Weaviate/Chroma）
2. **人类可读** — Markdown 文件可以直接阅读和编辑
3. **版本控制** — Git 天然支持，可以追溯历史
4. **可移植性** — 文件可以轻松迁移和备份
5. **简单性** — 降低系统复杂度，易于调试

**代表项目**：
- Bossa（MCP + CLI 文件系统持久化）
- Byterover（文件系统 memory，92% 检索准确率）
- OpenMemory（本地持久化存储）

### "Database is necessary" 阵营

**核心观点**：生产环境需要向量数据库，文件系统无法扩展。

**支持理由**：
1. **语义检索** — 向量相似度搜索比文件系统 grep 更智能
2. **性能** — 百万级数据时，数据库查询远快于文件扫描
3. **多租户** — 数据库天然支持隔离和权限控制
4. **实时性** — 毫秒级检索，文件系统做不到
5. **结构化查询** — 复杂过滤条件，文件系统难以实现

**代表项目**：
- LanceDB（OpenClaw 推荐的 memory layer）
- Mem0（MCP server for long-term memory）
- Zilliz memsearch（AI Agent 长期记忆）

## 2026 年的真相：争论本身是错的

### 核心发现

**标题**："The 'files are all you need' debate misses what's actually happening in agent memory architecture"

**关键洞察**：
> 争论的前提是错的。真正的问题不是"文件 vs 数据库"，而是"如何为不同场景选择合适的架构"。

**2026 年的共识**：
1. **没有银弹** — 文件系统和数据库各有适用场景
2. **混合架构是主流** — 生产环境普遍采用混合方案
3. **场景决定架构** — 根据规模、性能、复杂度选择

## 混合内存架构（Hybrid Memory Architecture）

### Hermes Agent 案例

**架构设计**：
```
┌─────────────────────────────────────────────┐
│  Hermes Agent Memory System                 │
├─────────────────────────────────────────────┤
│  Layer 1: Working Memory (Context Window)   │  ← 当前会话
│  - 最近对话                                  │
│  - 当前任务状态                              │
├─────────────────────────────────────────────┤
│  Layer 2: Short-Term Memory (File System)   │  ← 近期历史
│  - 会话摘要 (Markdown)                       │
│  - 任务日志 (JSONL)                          │
├─────────────────────────────────────────────┤
│  Layer 3: Long-Term Memory (Vector DB)      │  ← 长期知识
│  - 知识库 (Embeddings)                       │
│  - 经验库 (Semantic Search)                  │
└─────────────────────────────────────────────┘
```

**核心思想**：
- **分层存储** — 不同时间尺度的记忆用不同存储方式
- **自动降级** — 旧的 Working Memory 自动归档到 Short-Term
- **语义检索** — Long-Term Memory 支持语义搜索

**上下文优化**：
- 动态加载：根据当前任务从 Long-Term Memory 检索相关知识
- 压缩归档：定期将 Short-Term Memory 压缩为摘要
- 遗忘机制：低价值记忆自动淘汰

### 混合架构的设计原则

**原则 1：按访问模式分层**

| 层级 | 访问频率 | 存储方式 | 典型内容 |
|------|---------|---------|---------|
| Hot | 每次会话 | Context Window | 当前对话、任务状态 |
| Warm | 每天/每周 | File System | 近期日志、报告 |
| Cold | 按需检索 | Vector DB | 历史知识、经验库 |

**原则 2：按数据特性分类**

| 数据类型 | 特性 | 存储方式 | 理由 |
|---------|------|---------|------|
| 文档 | 人类可读、需版本控制 | Markdown | Git 友好 |
| 日志 | 结构化、高频写入 | JSONL/SQLite | 查询方便 |
| 知识 | 需语义检索 | Vector DB | 相似度搜索 |
| 配置 | 结构化、低频修改 | YAML | 易编辑 |

**原则 3：按规模选择技术栈**

| 规模 | 文件数 | 数据量 | 推荐方案 |
|------|--------|--------|---------|
| 小型 | <100 | <10MB | 纯文件系统 |
| 中型 | 100-1000 | 10MB-1GB | 文件系统 + SQLite |
| 大型 | >1000 | >1GB | 文件系统 + Vector DB |

## 2026 年的最佳实践

### 1. 文件系统优先（File-First Approach）

**核心思想**：默认使用文件系统，只在必要时引入数据库。

**适用场景**：
- 单用户/小团队
- 数据量 <1GB
- 不需要实时语义检索
- 重视人类可读性和版本控制

**代表项目**：
- Bossa（MCP + CLI）
- Byterover（92% 检索准确率）
- OpenMemory（本地持久化）

### 2. 渐进式增强（Progressive Enhancement）

**演进路径**：
```
阶段 1: 纯文件系统
  ↓ (遇到查询性能瓶颈)
阶段 2: 文件系统 + 元数据索引
  ↓ (遇到结构化查询需求)
阶段 3: 文件系统 + SQLite
  ↓ (遇到语义检索需求)
阶段 4: 文件系统 + Vector DB
```

**关键原则**：
- 不要过早优化
- 等真正遇到瓶颈再升级
- 保持架构简单

### 3. 混合架构模式（Hybrid Patterns）

**模式 A��文件系统 + SQLite**
- 文件系统：存储文档、报告、知识
- SQLite：存储日志、索引、注册表
- 适用：中小规模，需要结构化查询

**模式 B：文件系统 + Vector DB**
- 文件系统：存储原始文档
- Vector DB：存储 embeddings，支持语义检索
- 适用：大规模，需要智能推荐

**模式 C：三层混合**
- 文件系统：文档和报告
- SQLite：结构化数据和索引
- Vector DB：语义检索
- 适用：企业级，全功能需求

## 对我们的启示

### 我们的现状评估

**当前架构**：纯文件系统（Markdown + Git）

**规模评估**：
- 文件数：~20 个知识文件
- 数据量：<1MB
- 用户数：单用户（老板）
- 智能体数：~10 个

**结论**：**我们的架构选择是正确的**。

### 何时需要升级？

**触发条件**：

1. **性能瓶颈**：
   - knowledge/ 文件数 >100
   - Grep 搜索耗时 >1 秒
   - 需要频繁的复杂查询

2. **功能需求**：
   - 需要语义检索（"找出与当前任务相关的知识"）
   - 需要智能推荐（"你可能需要这些知识"）
   - 需要复杂的结构化查询

3. **规模扩展**：
   - 多用户共享智能体
   - 智能体数量 >50
   - 需要多租户隔离

### 渐进式升级路径

**阶段 1：增强文件系统（当前阶段）**
- ✅ 为知识文件补充 YAML frontmatter
- ✅ 创建 knowledge/INDEX.md
- ⏳ 升级 execution.log 为 JSONL 格式
- ⏳ 实现基于 Grep 的知识检索工具

**阶段 2：引入 SQLite（未来可能）**
- 将 execution.log 存储到 SQLite
- 将 agents-registry 存储到 SQLite
- 创建 knowledge_index 表
- 保持 Markdown 文件为主，SQLite 为辅

**阶段 3：引入 Vector DB（远期可能）**
- 为知识文件生成 embeddings
- 实现语义检索
- 智能推荐相关知识
- 保持文件系统为主，Vector DB 为辅

## 核心结论

### 1. 争论本身是错的

**错误的问题**："文件系统 vs 数据库，哪个更好？"

**正确的问题**：
- "我的场景需要什么能力？"
- "当前架构的瓶颈在哪里？"
- "升级的成本和收益是什么？"

### 2. 混合架构是主流

**2026 年的共识**：
- 小规模：纯文件系统
- 中规模：文件系统 + SQLite
- 大规模：文件系统 + Vector DB
- 企业级：三层混合

### 3. 简单优于复杂

**核心原则**：
- 从最简单的方案开始
- 等真正遇到瓶颈再升级
- 不要为了"看起来先进"而过度设计

### 4. 我们的架构是正确的

**理由**：
- 规模小，文件系统完全够用
- 人类可读性是核心需求
- Git 版本控制是核心能力
- 零依赖，易于维护

**下一步**：
- 增强文件系统（元数据、索引）
- 不要急于引入数据库
- 等真正遇到瓶颈再考虑

## 参考资料

- [The "files are all you need" debate misses what's actually happening in agent memory architecture](https://thenewstack.io/ai-agent-memory-architecture/)
- [Hermes Agent Launches Hybrid Memory Architecture for LLM Context Optimization](https://www.thenextgentechinsider.com/pulse/hermes-agent-launches-hybrid-memory-architecture-for-llm-context-optimization)
- [Bossa Launches Persistent Filesystem Memory for AI Agents via MCP and CLI](https://www.thenextgentechinsider.com/pulse/bossa-launches-persistent-filesystem-memory-for-ai-agents-via-mcp-and-cli)
- [Byterover: File-based memory for agents with >92% retrieval accuracy](https://www.producthunt.com/products/byterover)
- [Why LanceDB Is the Most Natural Memory Layer for OpenClaw](https://lancedb.com/blog/openclaw-lancedb-memory-layer/)


path: memory/knowledge/agent-design/knowledge-quality-constraints-2026.md
content: # 知识沉淀质量约束体系（2026）

> 来源：综合分析（RAGAS 框架 + Agent Memory 实践 + 我们自身经验 + tech-solver 反馈）
> 学习时间：2026-04-01（深度学习）
> 类别：agent-design / knowledge-management / quality-assurance
> 波动性：medium（质量维度稳定，具体阈值和策略可能演进）
> 置信度：high（多源交叉验证 + 实践经验支撑）

## 核心命题

**知识沉淀不等于知识积累。没有质量约束的沉淀必然导致知识熵增。**

类比 SlopCodeBench 的发现：代码在迭代中系统性退化。知识库也会退化——冗余堆积、过时不清理、粒度混乱、冲突未解决。

## 质量维度体系

### 已实施的维度

#### 1. 抽象优先原则（已写入 evo-agent-model.md）

```
写入知识前的三层检查：
Layer 1：是否是可复用的抽象（原理/模式/方法论）？
Layer 2：是否包含不必要的具体细节（API 版本号/临时配置/一次性解法）？
Layer 3：如果必须包含细节，是否与抽象分层存放？
```

### 需要新增的维度

#### 2. 过时检测（Staleness Detection）

**问题**：知识文件一旦写入就永远存在，即使其中的信息已经过时。

**方案——YAML 元数据 + 衰减模型**：
```yaml
# 每个知识文件头部应包含
created: 2026-03-28
last_verified: 2026-03-28
volatility: low|medium|high  # 已有
confidence: low|medium|high  # 已有
```

**衰减规则**：
- `volatility: high` → 30 天未验证标记 stale
- `volatility: medium` → 90 天未验证标记 stale
- `volatility: low` → 不自动标记（理论框架不过时）

**review 命令职责**：扫描知识文件，标记 stale 文件，决定更新/归档/删除。

#### 3. 冗余检测（Deduplication）

**问题**：不同学习会话可能沉淀高度重叠的知识。

**方案——学习前查重**：
```
learn 命令在沉淀新知识前：
1. 扫描 knowledge/ 目录下所有文件标题和核心概念
2. 如果新知识与现有文件 >70% 重叠：
   - 合并到现有文件（增量更新）
   - 而非创建新文件
3. 如果新知识是现有知识的深化：
   - 更新现有文件，增加"深化"章节
   - 递增学习次数
```

**当前痛点实例**：学习计划中 #41 出现了两条重复条目（AVO），正是因为不同来源发现了相同主题但未去重。

#### 4. 冲突解决（Conflict Resolution）

**问题**：不同来源可能给出矛盾的结论。

**方案——显式标记冲突**：
```markdown
## 争议点
> ⚠️ 知识冲突：来源A认为X，来源B认为Y
> 当前采信：X（理由：...）
> 待验证：下次 learn 时重新评估
```

**决策优先级**：
1. 有实验数据支撑 > 纯理论推演
2. 多个独立来源一致 > 单一来源
3. 最新研究 > 较早研究（但需注意可复现性）
4. 与我们实践经验一致 > 与实践经验矛盾

#### 5. 粒度控制（Granularity Control）

**问题**：知识文件的粒度不一致——有些是 600 行的综合框架，有些是 30 行的单概念笔记。

**方案——三级粒度标准**：

| 级别 | 适用场景 | 目标长度 | 示例 |
|------|---------|---------|------|
| 概念笔记 | 单个概念/工具/方法 | 30-80 行 | auto-tick-mechanism.md |
| 主题分析 | 一个完整主题的深度分析 | 80-200 行 | evolver-experience-driven-lifecycle-2026.md |
| 综合框架 | 多来源交叉验证的综合框架 | 200-400 行 | constrained-self-evolution-framework-2026.md |

**原则**：超过 400 行 → 拆分为多个文件或提取子主题。

#### 6. 引用溯源（Source Tracing）

**问题**：知识文件的来源有时模糊，无法验证或更新。

**已有的好实践**：
```markdown
> 来源：arXiv:2603.24517（2026-03）
```

**需要强化**：
- 每个关键断言都应可追溯到具体来源
- 综合框架文档中的交叉引用应明确标注哪些结论来自哪个来源
- 区分"来源 A 的原始结论"和"我们的推导/映射"

#### 7. 实践验证标记（Practice Validation）

**问题**：理论知识和实践验证之间缺乏显式关联。

**方案——添加验证状态**：
```markdown
> 实践验证：未验证 | 部分验证 | 已验证
> 验证场景：[描述在哪个子智能体/项目中应用过]
```

## 实施策略

### 立即可做（低成本）
1. learn 命令沉淀前增加查重步骤（检查已有文件标题和概念）
2. 知识文件头部统一添加 `created` 和 `last_verified` 字段
3. 冲突知识显式标记

### 需要框架升级（中成本）
4. review 命令增加"知识库健康扫描"子功能
5. 粒度标准写入 evo-agent-model.md

### 长期演进（高成本）
6. 自动过时检测（结合调度任务定期扫描）
7. 跨智能体知识冲突检测

## 与已有知识的交叉

- **SAGE 遗忘曲线**（#3）：过时检测的理论基础
- **知识生命周期管理**（#13）：YAML 元数据 + 三种处理策略
- **SlopCodeBench**（#38）：代码退化 → 知识退化的类比
- **受限自我进化**（#40）：质量约束 = 知识层面的"结构性护栏"

## 核心抽象

> **知识质量的 7 个维度**：抽象优先、过时检测、冗余检测、冲突解决、粒度控制、引用溯源、实践验证。前 4 个防止知识退化，后 3 个提升知识价值。

> **关键洞察**：知识库和代码库面临相同的退化风险——冗余堆积、结构侵蚀、质量下滑。SlopCodeBench 的教训同样适用于知识管理。


path: memory/knowledge/agent-design/executor-permission-strategy.md
content: # 执行器权限策略设计

> 沉淀日期：2026-03-28
> 来源：scheduler 自动执行 `evo-skill-creator learn` 时触发权限阻塞

## 事件

在通过 `evo-skills-scheduler` 自动执行 `evo-skill-creator learn` 时，出现了权限请求。

现象：

1. 调度器当前工作目录在 `scheduler/`
2. skill 的数据目录位于 `~/.claude/skills/evo-skill-creator/`
3. 执行器需要访问 skill 自己的 `references/`、`memory/`、`output/`
4. 由于这些目录不在默认可访问范围内，任务在无人值守场景下被权限确认打断

## 结论

权限策略必须成为“创建角色”时的显式设计项，而不是运行时临时补救项。

## 权限策略应包含什么

### 1. 默认目录访问范围

至少要明确：

1. 角色自己的 `memory/`
2. 角色自己的 `output/`
3. 角色自己的 `references/`
4. 相关项目代码目录
5. `scheduler/configs/` 等配套配置目录（如需要）

### 2. 默认工具权限

至少要明确：

1. 哪些工具默认允许
2. 哪些工具默认禁止
3. 哪些高风险工具必须额外确认

### 3. 权限申请机制

要区分两类：

1. **预授权**：创建角色时就明确授予，适合高频、稳定、低争议的访问
2. **运行时申请**：只有在偶发或高风险场景才临时询问老板

## 当前已确认的执行器差异

### Claude

从 `claude --help` 可确认，当前 CLI 暴露了以下相关能力：

1. `--add-dir`：补充可访问目录
2. `--allowedTools` / `--disallowedTools`：控制工具权限
3. `--permission-mode`：控制权限询问模式
4. `--dangerously-skip-permissions`：跳过权限检查（仅适合安全环境）

说明：Claude 的权限策略可以比较明确地落到命令行参数层。

### OpenCode

从 `opencode run --help` 可确认，当前 CLI 暴露了：

1. `--dir`：指定运行目录
2. `--agent` / `-m` 等执行相关参数

但当前帮助信息里**没有像 Claude 一样直接暴露工具白名单/权限模式参数**。

说明：OpenCode 的“权限策略”在创建角色时仍要设计，但具体落地方式可能与 Claude 不同，不能简单假设两者有相同的 CLI 参数。

## 对角色创建流程的要求

创建新角色时，必须主动问用户两类问题：

1. **默认权限**：这个角色默认应该拥有哪些目录和工具权限？
2. **额外权限**：除了默认权限，还需要哪些可选权限？它们是在创建时一次性授予，还是运行时再问？

推荐问法：

1. 这个角色默认需要访问哪些目录？
2. 这些目录里，哪些是高频刚需，应该预授权？
3. 这个角色默认需要哪些工具？
4. 是否允许 scheduler 场景下沿用同一套权限？
5. 哪些额外权限必须每次单独询问老板？

## 对 scheduler 的启示

调度配置不应只管理 `executor/model/tools`，还应考虑：

1. 默认目录访问范围
2. 权限模式
3. 命令级权限覆盖

理想结构：

1. `agent` 级默认：`executor/model/tools/permissions`
2. `schedule` 级覆盖：某个命令单独指定 `executor/model/tools/permissions`

## 一句话结论

**模型路由决定“谁来做”，权限策略决定“能不能做”。**

如果只设计模型，不设计权限，scheduler 在真实自动化场景里会经常卡在运行时确认上。


path: memory/knowledge/agent-design/self-referential-agent-framework-2026.md
content: # Self-Referential Agent Framework (2026)

> 来源：2026-03-29 learn 搜索发现
> 状态：基于搜索结果推断 + 已有知识综合
> 相关性：P1（高度相关，递归自我改进是进化的理论上限）

## 核心概念

**Self-Referential Agent** 是一个能够递归地改进自己的 Agent 框架。"Self-Referential"（自指）意味着 Agent 能够将自己作为操作对象。

### 递归自我改进的层次

| Level | 能力 | 示例 |
|-------|------|------|
| Level 0 | 执行任务 | 回答问题、生成代码 |
| Level 1 | 改进执行 | 优化 Prompt、调整策略 |
| Level 2 | 改进改进方式 | 修改自己的改进算法 |
| Level 3 | 改进改进改进方式 | 理论极限（哥德尔不完备性） |

### 与 Hyperagent 的关系

- **Hyperagent**："improve at improving"
- **Self-Referential Agent**：能够将"改进"本身作为操作对象
- **关系**：Self-Referential 是实现 Hyperagent 的技术路径

## 核心机制（推断）

### 1. 自我表示（Self-Representation）

Agent 需要有一个"自我模型"：
- **代码层**：SKILL.md、memory/、references/
- **行为层**：execution.log、经验库
- **元认知层**：对自己能力的认知（"我擅长什么"、"我的局限是什么"）

### 2. 自我观察（Self-Observation）

Agent 需要能够观察自己的行为：
- **执行追踪**：记录每一步操作
- **性能监控**：成功率、耗时、成本
- **质量评估**：输出质量的自我评价

### 3. 自我修改（Self-Modification）

Agent 需要能够修改自己：
- **策略修改**：调整决策逻辑
- **知识更新**：更新 memory/
- **代码修改**：修改 SKILL.md（最高级别）

### 4. 安全约束（Safety Constraints）

递归自我改进的最大风险是"失控"：
- **目标对齐检查**：每次修改前检查是否偏离目标
- **回滚机制**：修改失败可回退
- **人工确认门槛**：关键修改需要人工批准
- **沙箱测试**：新版本先在隔离环境测试

## 与我们当前架构的对比

| 维度 | 我们的架构 | Self-Referential（推断） |
|------|-----------|------------------------|
| 自我表示 | 有（SKILL.md + memory） | 有（更完整的自我模型） |
| 自我观察 | 部分（execution.log） | 完整（多维度监控） |
| 自我修改 | 部分（memory，不能改 SKILL.md） | 完整（包括代码修改） |
| 安全约束 | 人工触发 review | 自动化 + 多层防护 |
| 递归层次 | Level 1（改进执行） | Level 2（改进改进方式） |

## 对我们的启示

### 立即可做

1. **增强自我观察能力**
   - 升级 execution.log 为结构化格式
   - 增加性能指标（耗时、成本、成功率）
   - 实现质量自评机制

2. **明确自我模型**
   - 在 memory/ 中增加 self-model.md
   - 记录"我擅长什么"、"我的局限"、"我的进化历史"

### 中期规划

1. **实现 SKILL.md 的受控修改**
   - review 命令生成 SKILL.md 的变异版本
   - 在沙箱环境测试新版本
   - 人工确认后应用修改

2. **设计安全约束机制**
   - 目标对齐检查器
   - 版本管理和回滚
   - 修改审计日志

### 长期愿景

1. **完全自动化的递归自我改进**
   - 自动识别改进机会
   - 自动生成改进方案
   - 自动测试和部署
   - 达到 Level 2（改进改进方式）

## 关键挑战

### 1. 哥德尔不完备性

递归自我改进有理论上限：
- Agent 无法证明自己的一致性
- 需要外部"元系统"来验证

**解决方案**：人工作为"元系统"，在关键节点介入

### 2. 目标偏移风险

递归改进可能导致目标偏离：
- 原始目标："为老板服务"
- 偏移后："优化自己的性能指标"

**解决方案**：每次修改前强制执行目标对齐检查

### 3. 局部最优陷阱

自我改进可能陷入局部最优：
- 只优化当前策略，不探索新策略

**解决方案**：引入"探索-利用"平衡机制

## 相关知识连接

- [DGM Hyperagents](dgm-hyperagents-self-rewriting-2026.md) — 自我重写改进引擎
- [Meta-Agent](meta-agent-recursive-improvement.md) — 递归自我改进
- [EvolveR](evolver-experience-driven-lifecycle-2026.md) — 经验驱动进化

## 元数据

- created: 2026-03-29
- updated: 2026-03-29
- last_accessed: 2026-03-29
- access_count: 1
- study_count: 1
- category: agent-design
- volatility: medium
- confidence: medium（基于搜索结果推断）
- status: active


path: memory/knowledge/agent-design/knowledge-lifecycle-management.md
content: # 知识文件自动过时检测与生命周期管理

> 学习日期：2026-03-28
> 来源：多源综合研究（行业最佳实践、SM-2/FSRS 算法、Agent 内存管理模式）
> 学习次数：1

## 核心问题

knowledge/ 文件只增不减，长期导致：
1. 上下文膨胀 → 读取时间增加、注意力分散
2. 过时信息误导 → 基于旧知识做出错误决策
3. 信息矛盾 → 新旧知识并存但结论不同

## 元数据标准

### 推荐的 YAML Frontmatter 格式

每个知识文件头部应包含以下元数据：

```yaml
---
created: 2026-03-28        # 首次创建日期
updated: 2026-03-28        # 最后更新日期
last_accessed: 2026-03-28  # 最后被读取/引用的日期
access_count: 1            # 被读取/引用的总次数
study_count: 1             # 学习次数（对应 learn 命令）
category: framework        # 分类：framework / methodology / tool / trend / reference
volatility: medium         # 知识波动性：high（月度变化）/ medium（季度变化）/ low（年度变化）/ stable（基本不变）
confidence: high           # 置信度：high / medium / low
status: active             # 状态：active / stale / archived
---
```

### 元数据字段说明

| 字段 | 用途 | 更新时机 |
|------|------|---------|
| created | 知识溯源 | 创建时设置，不再修改 |
| updated | 判断信息时效性 | 每次修改内容时更新 |
| last_accessed | 遗忘曲线的核心输入 | 每次 go/learn/review 读取此文件时更新 |
| access_count | 衡量知识价值 | 同上 |
| study_count | 追踪学习深度 | learn 命令深入学习此主题时 +1 |
| category | 决定过时策略 | 创建时设置 |
| volatility | 决定 TTL 阈值 | 创建时设置，review 时可调整 |
| confidence | 检索时的权重因子 | 随学习深度和验证提升 |
| status | 是否参与主动检索 | 过时检测机制自动更新 |

## 过时检测机制

### 基于遗忘曲线的衰减模型

核心公式：`R = e^(-t/S)`

- **R**：当前检索价值（0~1）
- **t**：距上次访问的天数
- **S**：稳定性（知识的"半衰期"，随学习次数增加而增长）

### 稳定性（S）计算

借鉴 SM-2 算法的自适应机制：

```
S_initial = 7 天（初次学习后的默认稳定性）
S_new = S_old × EF（每次成功回顾后提升）
EF（易度因子）= 2.5（默认）
```

简化版实现（适用于文件系统级知识管理）：

| study_count | 稳定性 S（天） | 含义 |
|------------|---------------|------|
| 1 | 7 | 首次学习，一周内需要回顾 |
| 2 | 18 | 两次学习，约半个月 |
| 3 | 45 | 三次学习，约一个半月 |
| 4 | 112 | 四次学习，约四个月 |
| 5+ | 280 | 五次以上，约九个月 |

### 过时阈值（结合 volatility）

| volatility | R < 阈值视为 stale | R < 阈值视为需归档 |
|-----------|-------------------|------------------|
| high | R < 0.5（约 0.7S 天） | R < 0.2（约 1.6S 天） |
| medium | R < 0.4（约 0.9S 天） | R < 0.15（约 1.9S 天） |
| low | R < 0.3（约 1.2S 天） | R < 0.1（约 2.3S 天） |
| stable | 不自动过时 | 手动归档 |

### 实际效果示例

一个 `study_count=1, volatility=medium` 的文件：
- S = 7 天
- 6 天后 R ≈ 0.42 → 仍然 active
- 7 天后 R ≈ 0.37 → **标记 stale**
- 13 天后 R ≈ 0.15 → **建议归档**

一个 `study_count=3, volatility=low` 的文件：
- S = 45 天
- 45 天后 R ≈ 0.37 → 仍然 active
- 54 天后 R ≈ 0.30 → **标记 stale**
- 103 天后 R ≈ 0.10 → **建议归档**

## 过时知识的三种处理策略

### 策略 1：标记 Stale（软过时）

**适用场景**：知识可能仍有价值，但需要验证
**操作**：
- status 改为 `stale`
- 仍保留在原位
- 读取时显示警告："此知识已 N 天未更新/访问，可能需要验证"
- 下次 learn 相关主题时自动纳入温故范围

### 策略 2：压缩（Summarization Flush）

**适用场景**：知识本身仍然有效，但文件过长
**操作**：
- 将详细内容精炼为摘要（保留关键结论和数据点）
- 原始版本移到 `archive/` 目录
- 摘要版保留在 `knowledge/` 中，标记 `compressed: true`
- 显著减少上下文占用

### 策略 3：归档（Archive）

**适用场景**：知识已过时或长期未使用
**操作**：
- 移到 `memory/archive/` 目录
- 不参与日常检索
- 保留完整内容供未来查阅
- **不删除** — "Archive-Never-Delete" 原则

### 三种策略的选择逻辑

```
if status == stale:
    if volatility in [high, medium]:
        → 下次 learn/scan 时优先验证
        → 验证通过 → 更新 last_accessed, status=active
        → 验证失败 → 归档
    if volatility in [low, stable]:
        → 标记 stale，等待下次被引用时决定

if 需要归档:
    if 文件 > 50 行:
        → 先压缩为摘要，原文归档
    else:
        → 直接归档
```

## 执行时机与自动化

### 被动触发（检索时）

每次 go/learn/review 读取 knowledge/ 文件时：
1. 检查元数据
2. 更新 `last_accessed` 和 `access_count`
3. 如果 status 为 stale，显示警告

### 主动触发（review 命令）

review 命令增加 "memory 健康检查" 步骤：
1. 扫描所有 knowledge/ 文件的元数据
2. 计算每个文件的当前 R 值
3. 列出需要关注的文件：
   - stale 文件清单
   - 建议归档的文件清单
   - 从未被引用的文件（access_count == study_count，说明学了但从没用过）
4. 提出处理建议，让老板确认后执行

### 定期触发（cron）

建议通过 scheduler 定期执行 memory 健康检查：
- 频率：每两周或每月
- 方式：review memory（可作为 review 的子命令）

## 目录结构变更

```
memory/
├── knowledge/          # 活跃知识（status: active 或 stale）
│   └── <domain>/
├── archive/            # 归档知识（不参与日常检索）
│   └── <domain>/
└── ...
```

## 分级免疫机制

并非所有知识都应受衰减影响：

| 类别 | 衰减策略 | 示例 |
|------|---------|------|
| 核心原则 | 免疫（不衰减） | 进化模型、设计哲学 |
| 框架知识 | 慢衰减（volatility=low） | SAGE、DGM 框架 |
| 行业趋势 | 快衰减（volatility=high） | 模型排名、新工具 |
| 工具使用 | 中衰减（volatility=medium） | API 用法、配置方法 |

## 对 evo-skill-creator 的实施建议

### 立即可做

1. **为现有 knowledge/ 文件补充元数据** — 通过 review 命令批量添加 YAML frontmatter
2. **创建 `memory/archive/` 目录结构** — 准备好归档空间
3. **在 review 命令中增加 memory 健康检查** — 可作为 backlog 任务

### 中期规划

4. **在 learn 命令中自动更新元数据** — 每次 learn 读取文件时更新 last_accessed
5. **在 go 命令中检查 stale 知识** — 如果使用了 stale 文件中的知识，提醒验证
6. **为子智能体的 SKILL.md 模板加入 memory 健康检查说明**

### 长期愿景

7. **自动压缩** — 文件超过阈值行数时，自动生成摘要版
8. **跨智能体过时同步** — 如果创建者的知识过时了，自动通知使用了相同知识的子智能体

## 与已有知识的连接

- **SAGE 遗忘曲线** → 本文的衰减模型直接基于 SAGE 的启示
- **上下文工程** → 过时检测是"选择与裁剪"支柱的具体实现
- **多 Agent 协同** → 置信度衰减和内存蒸馏是本文的上层需求
- **自动技能评估** → 过时检测本身可以作为知识管理维度的评估指标

## 参考来源

1. 2026 Agent Lifecycle Management (ALM) 行业实践
2. SM-2 算法（SuperMemo）— 间隔重复调度
3. FSRS (Free Spaced Repetition Scheduler) — 开源 SRS 算法
4. Ebbinghaus 遗忘曲线 — R = e^(-t/S)
5. "Archive-Never-Delete" 原则 — AI Agent 内存管理最佳实践
6. Tiered Memory with TTL — 分层内存 TTL 模式
7. YAML Frontmatter 元数据标准 — Markdown 知识文件管理


path: memory/knowledge/agent-design/karpathy-loop-autonomous-experimentation-2026.md
content: # Karpathy Loop — 自主实验循环（2026年3月）

> 来源：Fortune 报道（2026-03-17）
> 学习时间：2026-03-29
> 类别：Agent 自我改进机制
> 波动性：medium（实验循环是稳定机制，但具体实现会演进）

## 核心发现

Andrej Karpathy（前 OpenAI 研究员）展示的自主 Agent 在 **2 天内运行了 700 个实验**，这是 AI 自我改进领域的重要里程碑。

## Karpathy Loop 的核心机制

### 1. 高速实验循环

- **实验速度**：700 实验 / 2 天 = **350 实验/天** ≈ **15 实验/小时**
- **对比人类**：人类研究员通常需要数周才能完成几十个实验
- **速度优势**：Agent 的实验速度是人类的 **100-1000 倍**

### 2. 自主实验流程

```
假设生成 → 实验设计 → 执行实验 → 结果评估 → 知识更新 → 新假设
    ↑                                                              ↓
    └──────────────────────── 循环 ────────────────────────────────┘
```

### 3. 关键能力要求

1. **自动假设生成** — Agent 能基于现有知识生成新假设
2. **实验自动化** — 无需人工干预即可执行实验
3. **自动评估** — 能够自动判断实验成功/失败及原因
4. **知识自动沉淀** — 将实验结果转化为可复用的知识

## 对 AI 未来发展的启示

### 1. 进化速度的本质是实验速度

- **传统进化**：依赖人工反馈，速度受限于人类响应时间
- **Karpathy Loop**：完全自主循环，速度仅受限于计算资源
- **结论**：自动化实验循环是实现快速进化的关键

### 2. 评估是瓶颈

- **无评估 = 盲目进化**：没有自动评估，无法支撑高频实验
- **评估质量决定进化方向**：错误的评估会导致进化偏离目标
- **多维度评估**：需要从多个维度评估实验结果（性能、成本、安全性等）

### 3. 知识沉淀是进化的基础

- **实验 → 知识**：每个实验都应产生可复用的知识
- **知识 → 假设**：已有知识是生成新假设的基础
- **闭环增强**：知识越多，假设质量越高，进化越快

## 与我们的自我进化模型的对比

### 我们的现状

| 维度 | 我们的实现 | Karpathy Loop | 差距 |
|------|-----------|--------------|------|
| 实验触发 | 手动（review 命令） | 自动循环 | **大** |
| 实验速度 | 低（依赖人工触发） | 高（350/天） | **大** |
| 评估机制 | 主观评价 | 自动评估 | **大** |
| 知识沉淀 | 手动写入 knowledge/ | 自动沉淀 | **中** |
| 假设生成 | 依赖 scan/learn | 自动生成 | **中** |

### 我们的优势

1. **人类监督** — 避免进化偏离目标
2. **知识可读性** — 文件系统级 memory 人类可直接阅读
3. **灵活性** — 可根据场景调整进化策略

### 我们的差距

1. **缺少自动实验循环** — 依赖人工触发 review
2. **缺少自动评估** — 完全依赖主观评价
3. **实验速度慢** — 无法支撑高频迭代

## 改进方向

### 短期（立即可做）

1. **在 review 命令中增加"效果评估"步骤** — 量化评估升级效果
2. **设计实验记录格式** — 记录每次 review 的假设、执行、结果
3. **建立评估指标库** — 为不同类型的改进定义评估指标

### 中期（需要设计）

1. **实现半自动实验循环** — review 命令自动触发，但需人工确认
2. **设计自动评估框架** — 基于多维度指标自动评估改进效果
3. **实验历史分析** — 分析历史实验，识别成功模式

### 长期（探索方向）

1. **完全自动化的 Karpathy Loop** — 无需人工干预的自主实验循环
2. **多 Agent 协同实验** — 多个子智能体并行实验，加速进化
3. **元学习** — Agent 学习"如何更好地实验"

## 关键结论

1. **实验速度是进化速度的上限** — 要快速进化，必须提高实验频率
2. **自动评估是自主进化的前提** — 没有自动评估，无法实现 Karpathy Loop
3. **知识沉淀是进化的基础** — 每个实验都应产生可复用的知识
4. **人类监督仍然重要** — 完全自主的循环需要强大的安全机制

## 与已有知识的关联

- **Meta-Agent 递归改进**（memory/knowledge/agent-design/meta-agent-recursive-improvement.md）— Karpathy Loop 是递归改进的具体实现
- **自我巩固机制**（memory/knowledge/agent-design/self-consolidation-mechanism.md）— 实验结果需要通过自我巩固转化为技能
- **Agent Observability**（memory/knowledge/agent-design/agent-observability-taxonomy-2026.md）— 可观测性是自动评估的基础

## 参考资料

- Fortune: "'The Karpathy Loop': Former OpenAI researcher's autonomous agents ran 700 experiments in 2 days—and gave a glimpse of where AI is heading" (2026-03-17)


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)