Immutable. This exact content is served forever at /api/v1/blob/f8ee9459a9982c40.
--- name: evolution-proposal description: 把 evolution-inbox 中的审计异常条目转化为可评审的进化提案（规则/技能/插件/路由补丁）。先做系统化问题分析（量化基线→全量聚合→根因分类→优先级排序），再用便宜模型起草、前沿模型评审、人工批准后走既有门禁固化。用于处理 evolution_scan.js 产出的异常条目、复盘高频反模式、把会话经验固化为规则或技能改进。不用于单轮小修改和 L0 治理规则的直接修改（只产提案不越权固化）。 version: 0.3.0 triggers: - "evolution-inbox 中有新异常条目待处理" - "会话收到审计反模式信号（轮询/重试簇/token 热点/压缩风暴）需要根治" - "用户要求把近期会话经验固化为规则/技能/插件改进" not_for: - "单轮小修改（走 minimal-implementation）" - "不涉及进化对象的日常任务" - "直接修改 AGENTS.md 治理规则（L0 层只能人工发起，本技能只产提案）" depends_on: - task-mode-router - minimal-implementation - execution-discipline - systematic-optimization --- # 进化提案（Evolution Proposal） ## 核心规则 本机 Agent 体系已具备进化的全部要素（可变异对象、适应度函数、选择机制、固化管线），缺的是把审计发现转化为受控变异的提案环节。本技能就是那个转化器： 1. **只产提案，不直接改**：输出是可评审的变更提案（diff + 证据 + 验证命令 + 预期指标），固化必须过人工或既有门禁。 2. **证据驱动**：每条提案必须锚定 inbox 条目中的量化证据（retries=10 / pollCount=8 / inputTokens=2.5M），无证据不立项。 3. **先分析后提案**：进入提案前必须先做系统化问题分析（量化基线 → 全量聚合 → 根因分类 → 优先级排序），禁止"看到一条异常就提一条提案"的碎片化处理。 4. **根因分类决定对策**：沿用 systematic-optimization 的三类根因——缺约束（补约束）、有约束不执行（加执行点检查/门禁）、无法强制（升级到系统层机制）。**约定层不执行是经验事实，不是假设**：同一反模式反复出现必须升级方案。 5. **元规则隔离**：AGENTS.md 治理模块（L0）是选择算子本身，本技能永远不直接改它；如需变更 L0，只能作为"人工发起的独立变更"提议，由用户执行。 ## 适用范围与触发边界 **触发**（满足任一即启用本技能）： - `evolution-inbox`（`~/.agent-broker/topics/skills/evolution-inbox/workspace/inbox.jsonl`）存在 `status: "new"` 的条目； - 会话中出现已知反模式信号（无 wait 轮询、重试簇、token 热点、压缩风暴）并需要根治而非临时规避； - 用户明确要求"把最近的经验固化成规则/技能/插件改进"。 **不适用**： - 单轮小修改：直接改目标文件即可，不要套提案流程（经 task-mode-router 判级）； - 无需固化的临时问答； - L0 治理规则修改：只能由用户人工发起，本技能最多输出"建议变更内容"供用户决定。 ## 工作流程 ### 阶段 1：问题分析（Problem Analysis，完整九步） > 本阶段完整执行 systematic-optimization 第 0~5 步（量化→全量列问题→根因→方案→**联网借鉴**→归纳取舍）。**没有数字的"问题"是感觉**；**不借鉴同类已知解法的方案是闭门造车**。禁止跳过本阶段直接选条目提提案。 **步骤 1.1 量化基线（第 0 步）** 1. 读取 inbox 全部条目：`Get-Content ~/.agent-broker/topics/skills/evolution-inbox/workspace/inbox.jsonl`，按行解析 JSON。 2. 统计全量基线：总条目数、按 pattern 聚合的频次与占比（如 `poll 26/390 = 6.7%`）、按 severity 分布、按 status 分布。 3. 对每个高频 pattern，统计时间分布（策略生效前/后，参考 `~/.dsh/AGENTS.md` 各模块生效时刻），判断是历史存量还是近期增量。 4. 记录基线数字（阶段 4 提案、固化后度量对比同口径使用）。 **步骤 1.2 全量列问题（第 1 步）** 1. 按 pattern 分组，每组标注：会话数、量化证据（次数/占比/极端值）、最严重代表条目（sessionId + 具体证据）。 2. 区分**表象与真问题**：表象是症状（如"这个会话轮询 305 次"），真问题是"缺什么机制导致这种症状反复出现"（如"监督等待阶段没有长轮询的硬约束"）。 **步骤 1.3 根因分类（第 2 步）** 对每个 pattern 判定根因类型（沿用 systematic-optimization 三类）： | 根因类型 | 特征 | 对策 | |---|---|---| | 缺约束 | 根本没有对应的规则/流程/检查 | 补约束（新增规则/技能/门禁） | | 有约束不执行 | 规则存在但执行者没遵守 | 加执行点检查（skill 硬约束、检测脚本、门禁） | | 无法强制 | 规则无法被强制执行 | 升级到系统层机制（插件/参数/自动检测） | 判定方法：问三个问题——约束存在吗？存在但没执行吗？为什么没执行（不知道/忘了/没法强制）？第三类"无法强制"是复发问题的常见真根因：**规则写在哪不重要，规则拦不拦得住才重要**。 **步骤 1.4 寻找解决方案（第 3 步，结构性优先）** 每提出一个方案先问：**这是临时方案还是结构性方案？** - 临时方案：手动清理、这次注意、下次记得（会复发）； - 结构性方案：自动检测、硬校验、参数门禁、系统拦截（无法绕过）； - 临时方案只用于止血，必须伴随结构性方案，否则问题必然复发。 **步骤 1.5 联网借鉴同类已知解法（第 4 步，必做）** 1. 先定义问题域，关键词取自根因（如 "agent polling anti-pattern" / "event-driven agent wait" / "long-running task supervision"）。 2. 用异步队列（`queue_cli_request`/`queue_codex_request`）+ 单次 `request_result(wait=60~120)` 发起联网检索（本机 web_search 余额不足时走 CLI 通道），**2~3 个极窄探针**（≤100 字、结构化输出）。 3. 只回收结构化结果：`机制名 | 出处 | 实现方式 | 来源`，不堆砌原文。 4. 产出借鉴对照表（机制 | 出处 | 实现 | 来源），写入问题分析摘要。 **步骤 1.6 归纳取舍（第 5 步）** 1. 借鉴方案对照本机场景约束：哪些能移植、哪些不能、怎么改造。 2. 最终方案必须标注**约束分层**（系统层/流程层/约定层，见 systematic-optimization 第 5 步）；约定层条目标注"未强制，待观察"，不得自称已解决；问题反复出现则升级到系统层。 3. 按成本/收益取舍，不做过度设计。 **步骤 1.7 优先级排序（收敛）** 1. 按「影响面 × 频率 × 可改进空间」给 pattern 排序；同根因的多个 pattern 合并为一个问题集。 2. 本轮只选 **1~2 个问题集**进入提案（避免一次提案过多导致评审失焦）。 3. 将选中问题集涉及的全部 inbox 条目标记 `status: "processing"`（写回 inbox 对应行，记录 `proposedBy`）。 4. 产出**问题分析摘要**（见输出契约），与提案文档一并落盘。 ### 阶段 2：根因深挖与补丁起草（变异算子，用便宜模型） 1. 对选中问题集，结合本机已有规则（`~/.dsh/AGENTS.md` 8 模块 + 既有 skills）复核阶段 1 的根因分类，确认是**新反模式**、**已知规则的回归**还是**执行不达标**。 2. 复用现有工具辅助定位（不重复造轮子）： - 重试簇 → `dsh-retry-analysis.js`（provider × failure code × 消息簇）； - token 热点 → `dsh-token-summary.js`（模型/项目/任务类型画像）； - 轮询 → 直接查会话日志中 `request_status`/`job_list` 的调用序列。 3. 起草补丁内容（变异算子）：针对根因，产出**最小化**的规则/技能/插件/路由改动，遵循 minimal-implementation；**明确标注补丁落在哪一层**（系统层/流程层/约定层，见 systematic-optimization 第 5 步约束分层），若根因是"有约束不执行"且问题反复出现，方案必须升级到流程层以上。 ### 阶段 3：评审（选择算子，前沿模型） 1. 本地静态预检：如果提案涉及技能包，先跑 `quality_report.py --strict` 和 `validate_repo.py --strict`；涉及 DSH 配置先跑 `dsh-config-sync --check`。 2. 前沿模型评审（可选用 switchboard）：把提案 + 证据 + 影响面发给前沿模型（如 `queue_cli_request` + `request_result`），要求给出 PASS / REJECT / 修改建议。 3. 成本与风险自检：估算改动引入的额外 token 成本；检查是否触碰 Non-Goals（如不该动的文件、不该改的元规则）。 ### 阶段 4：产出提案（输出契约） 输出结构（写入 `.agent-broker/topics/skills/evolution-inbox/proposals/<yyyy-mm-dd>-<n>.md`）： ```markdown # 进化提案 #<n>：<标题> - 来源条目：inbox 行 <序号>（sessionId、pattern、severity） - 反模式：<模式名> <量化证据> - 问题分析摘要：<基线数字 + 根因分类 + 是否回归> - 根因：<一句根因判断 + 根因类型> - 变更对象：<L1 技能 | L2 插件/preset | L3 路由参数 | L0 元规则[仅建议]> - 变更内容：<具体 diff 或改动描述 + 约束分层> - 影响面：<受影响文件、行为、成本> - 验证命令：<git diff --check + validate_repo --strict + quality_report --strict + 其他> - 预期指标：<可测量的改进目标，如重试率下降 X%、轮询次数归零> - 风险与回滚：<风险点 + 回滚方式> - 评审状态：PENDING（等待人工批准） ``` ### 阶段 5：交接（不越权固化） 1. 把问题分析摘要 + 提案路径 + 提案摘要交给用户/决策层，等人工批准。 2. **禁止**自行应用 L0/L1 变更；用户批准后由用户或按既有流程执行固化（git 门禁 + 版本号 bump + 跨设备同步）。 3. 固化完成后，将 inbox 对应条目标记 `status: "applied"`（或 `"rejected"` 并附原因），保持 inbox 可审计。 ## 输出契约 - 每次处理产出**问题分析摘要** + **提案文档**两份产物： - 问题分析摘要（`proposals/<date>-<n>-analysis.md`）：基线数字、pattern 聚合表、根因分类表、**借鉴对照表（机制|出处|实现|来源，来自联网检索）**、方案取舍（含约束分层）、优先级排序、本轮选择的问题集； - 提案文档（`proposals/<date>-<n>.md`）：来源证据、根因、变更对象、具体内容、影响面、验证命令、预期指标、风险回滚、评审状态； - 提案必须包含：来源证据、根因（含根因类型）、变更对象、具体内容（含约束分层）、影响面、验证命令、预期指标、风险回滚、评审状态； - 问题分析摘要的借鉴对照表**不得为空**——凡产出提案必经联网借鉴步骤（第 1.5 步），无借鉴则提案不成立； - inbox 条目状态流转：`new → processing → applied | rejected`，全程可审计。 ## 验证 本技能自身的验收标准： 1. 用一条真实 inbox 条目走完全流程（问题分析九步→根因深挖→评审→提案→交接），产出问题分析摘要 + 提案文档； 2. 问题分析摘要包含量化基线（pattern 频次/占比/时间分布）、根因分类、**联网借鉴对照表（非空）**，不是"凭感觉选一条"； 3. 提案中的验证命令全部可执行且不修改仓库（`--check`/`--strict` 只读）； 4. 全程未修改 L0 治理规则、未越权应用变更； 5. 提案与摘要文件通过 `git diff --check` 无空白错误。