97 added, 67 removed. Audit A to A.
---
name: systematic-optimization
description: |
- 系统化优化流程：发现问题→量化→根因→机制方案→业界调研→归纳→实施→验证实装→度量闭环。核心原则：规则存在≠被执行，机制优先于建议；拒绝临时补丁，追求大局观；优化必须可度量。
- 用于用户要求"优化""改进""复盘""为什么反复出问题""效率低/token 浪费/防御过度"等系统性改进场景，或接手反复失败的任务时。
+ 系统化问题解决与优化流程（领域无关）：量化基线→全量列问题→根因分类→结构性方案（拒绝临时补丁）→借鉴同类方案→归纳取舍→展示计划确认实施→实施→验证生效→度量闭环。核心原则：规则/流程存在≠被执行，能落到"无法绕过的机制"就不写建议；优化必须可度量。
+ 用于用户要求"优化""改进""复盘""为什么反复出问题""效率低/成本高/质量差/总是复发"等任何领域的系统性改进，或接手反复失败的任务时。
不用于单点小修复（用 minimal-implementation）；不用于只读审查不出方案的场景。
---
- # 系统化优化流程（Systematic Optimization）
+ # 系统化问题解决与优化流程（Systematic Problem-Solving & Optimization）
- > 来源：2026-08-24 对"严格好论文榜"长任务会话的完整优化实践（9 个悬挂 supervisor、44 分钟无看门狗 Deep diving、214 万 token 输入、24 次上下文压缩）。这次实践暴露的核心教训：**规则存在 ≠ 被执行**，优化必须落到"无法绕过的机制"而不是再写一条建议。
+ > 方法骨架与业界经典问题解决法同构（见文末对照表），本 skill 在经典流程上补充了两次实践沉淀的关键增量：**量化先行**（第 0 步）与**约束分层**（第 5 步）——后者回答"为什么改了还会复发"：方案若落在"靠人遵守"的约定层，就必然复发。
## 触发边界
- - 用户说"优化 / 改进 / 复盘 / 为什么反复出问题 / 效率是不是低 / 有没有浪费 token / 防御是不是过度"；
- - 接手一个反复失败或长期停滞的任务；
+ - 用户说"优化 / 改进 / 复盘 / 为什么反复出问题 / 效率是不是低 / 成本是不是高 / 质量是不是差 / 总在重复犯同一个错"；
+ - 接手一个反复失败或长期停滞的任务/流程/系统；
- 审查发现同一类问题反复出现（反模式重演）。
- ## 流程（八步）
+ ## 流程（九步）
### 第 0 步：证据先行，量化基线
**没有数字的"问题"是感觉。** 先量化再下结论：
- - 从日志/转录/数据提取：事件数、工具调用分布、等待次数、轮询次数、时间线 gap、token 统计（输入/输出比）、上下文压缩次数、行数/文件变化；
- - 用时间戳重建时间线，找"长时间无产出"的段（如 44 分钟 WAIT→GET 循环）；
- - 建立优化前的基线数字，供第 7 步对比。
+ - 从日志、监控、账单、转录、数据中提取指标：频次、时长、成本、等待时间、失败率、资源消耗、重复次数；
+ - 用时间线重建事件流，找"长时间无产出/高消耗"的段；
+ - 建立优化前的基线数字（第 8 步同口径对比用）。
+ - 反例：不量化就下结论（"好像很慢""感觉浪费"）→ 无法证明改进，也无法定位根因。
### 第 1 步：发现所有问题（全量列举）
- - 不修修补补，先把问题**全部**列出来（挂起、轮询、纠偏、方向丢失、token 浪费、效率低……）；
- - 每个问题标注证据（哪个事件/哪段日志/哪个数字）；
- - 区分表象与真问题（"9 个悬挂 supervisor"是表象，真问题是"收尾无机制"）。
+ - 不修修补补，先把问题**全部**列出（悬挂、空转、重复、超支、返工、错误率……）；
+ - 每个问题标注证据（哪段日志/哪个数字/哪个事件）；
+ - 区分表象与真问题：表象是症状，真问题是"缺什么机制导致症状反复出现"。
### 第 2 步：寻找根因（分类定位）
根因分三类，处理方式不同：
| 根因类型 | 特征 | 对策 |
|---|---|---|
- | 缺规则 | 规则库没有该条目 | 补规则 |
- | 有规则没执行 | 规则存在但执行者/管理者没遵守 | 加执行点自查（skill 自查清单） |
- | **执行无法强制** | 规则靠"记得遵守"，没有拦截机制 | **改平台/工具层做强制约束（唯一真正根治）** |
+ | 缺约束 | 根本没有对应的规则/流程/检查 | 补约束 |
+ | 有约束不执行 | 规则/流程存在但当事人没遵守 | 加执行点检查（checklist、门禁） |
+ | **无法强制执行** | 约束靠"记得遵守"，没有系统拦截 | **改系统/工具/平台层做强制约束（唯一真正根治）** |
- 典型：本次根因是第三类——"及时关闭 supervisor"规则早已存在，但收尾依赖人工记忆，没有 broker 层自动回收。
+ 判定方法：对每个问题问"约束存在吗？存在但没执行吗？为什么没执行——是不知道、忘了、还是没法强制？"。第三类是复发问题的常见真根因：**规则写在哪不重要，规则拦不拦得住才重要**。
- ### 第 3 步：寻找解决方案（机制优先，拒绝临时）
+ ### 第 3 步：寻找解决方案（结构性优先，拒绝临时）
- 每提出一个方案先问：**这是临时方案还是机制方案？**
+ 每提出一个方案先问：**这是临时方案还是结构性方案？**
- - 临时方案：手动清理 9 个悬挂 supervisor、这次注意点、下次记得……（会复发）
- - 机制方案：broker 自动回收闲置 supervisor、interrupt 预算上限、参数必填门禁……（无法绕过）
+ - 临时方案：手动清理一次、这次注意点、下次记得、特例处理……（会复发）
+ - 结构性方案：自动回收、预算上限、参数必填、流程节点拦截……（系统无法绕过）
- **追求大局观**：不从单个问题出发打补丁，而是看"这一类问题"缺什么机制。临时方案只用于止血，必须伴随机制方案。
+ **追求大局观**：不从单个问题打补丁，而是看"这一类问题"缺什么结构性机制。临时方案只用于止血，必须伴随结构性方案，否则问题必然复发。
- ### 第 4 步：网上找相同问题解决方案
+ ### 第 4 步：借鉴同类问题的已知解法
- - 先定义问题域，再搜索（关键词来自根因，如 "agent orchestration supervisor lifecycle zombie"）；
- - 用已有通道：内置 web_search 不可用时，走 CLI worker 搜索（`queue_cli_request` + `request_result`，见 agent-switchboard-ops examples）；
- - 只回收结构化结果 + 来源 URL，不灌脏网页；
- - 业界对照表：机制名 | 框架 | 实现方式 | URL。
+ - 先定义问题域，再检索（关键词来自根因；来源：文献、业界方案、开源项目、其他领域类比、内部历史案例）；
+ - 只回收结构化结果（机制名 | 出处 | 实现方式 | 链接/引用），不堆砌原文；
+ - 对照表：机制 | 出处 | 实现 | 来源。
### 第 5 步：归纳成为最终方案（取舍）
- - 业界方案对照本系统约束，标注哪些能移植、哪些不能、怎么改造（如 OpenAI Agents SDK 的 max_turns → 本系统的 interrupt 预算；Temporal 终态状态机 → 惰性 zombie 检测）；
- - 最终方案必须包含：机制落点（哪个文件/哪个工具）、行为变化（什么条件下拒绝/回收）、可验证的验收点（返回什么新字段）；
- - 决定哪些优化值得做（成本/收益），不做过度防御。
+ - 借鉴方案对照本系统/本场景约束：哪些能移植、哪些不能、怎么改造；
+ - 最终方案必须包含：落点（改哪里）、行为变化（什么条件下触发什么）、可验证的验收点（可观测的字段/指标/行为）；
+ - 按成本/收益取舍，不做过度设计（防御过多本身也是问题）。
- **约束分层（本步必做，逐方案标注）**：每个方案必须标注它属于哪个约束层，只有"平台/代码层"才算机制化：
+ **约束分层（本步必做，逐方案标注）**——回答"这方案会不会复发"：
- | 约束层 | 例子 | 可靠性 | 判定 |
+ | 约束层 | 含义 | 可靠性 | 判定 |
|---|---|---|---|
- | 平台/代码层 | broker 参数门禁、自动回收、预算上限 | ✅ 强制（无法绕过） | 真机制 |
- | 执行点自查 | skill 自查清单、回合结束检查 | ⚠️ 依赖"记得查" | 半机制，需观察 |
- | 文档/规则层 | skill 里的"应当""禁止"条款 | ❌ **经常不执行** | 弱约束，不算方案 |
+ | 系统层 | 平台/代码/工具层强制执行（参数门禁、自动回收、硬校验） | ✅ 无法绕过 | 真方案 |
+ | 流程层 | 流程节点检查、checklist、审批门 | ⚠️ 依赖执行者"记得查" | 半方案，需观察 |
+ | 约定层 | 文档、规范、培训里的"应当/禁止" | ❌ **经常不执行** | 弱约束，不算方案 |
- **文档层不执行是经验事实，不是假设**：2026-08-24 实证——WAIT→GET 禁令写入 skill 并被会话加载后，下一次调用依然夹用；"及时关闭 supervisor"规则存在数月，9 个 supervisor 仍悬挂。因此：
+ **约定层不执行是经验事实，不是假设**（实证：禁令写入文档并被当事人看过，下一次照旧违反；"及时处理"规则存在数月，问题照样悬挂）。因此：
- - 写入文档的规则 = 弱约束，必须显式标注"未强制，待观察"；
- - 如果该规则对应的问题**反复出现**，就必须升级到平台/代码层（第 3 类根因），不能停留在文档层；
- - 方案清单里，文档层条目不得自称"已解决"，只能算"已记录"。
+ - 约定层条目必须显式标注"未强制，待观察"，不得自称"已解决"；
+ - 若该问题**反复出现**，就必须升级到系统层，不能停留在约定层；
+ - 半方案（流程层）要设观察期和升级触发条件：N 次复发即升级。
- ### 第 6 步：实施
+ ### 第 6 步：展示计划，确认实施（决策门）
- - 按 minimal-implementation：最小正确改动 + 可复核验证证据；
- - 新机制必须配测试（防回归）；
- - 全部门禁（validate_repo、quality_report、回归测试、diff check）。
+ **方案在实施前必须过一次决策门。** 把第 5 步归纳的最终方案以紧凑、可决策的形式呈现给用户/决策方：
- ### 第 7 步：验证实装（三件套，缺一不可）
+ - **要改什么**：方案清单（每条含：落点、行为变化、约束层、成本/收益）；
+ - **不改什么**：非目标（明确排除的相邻内容，防止实施时范围蔓延）；
+ - **风险**：主要风险与回滚方式；
+ - **验收标准**：第 7 步生效验证的可观察判据；
+ - **等待确认**：明确请求确认（同意 / 调整 / 驳回）后才进入实施。
- **文件改了 ≠ 已生效。** 检查运行时链路：
+ 规则：
- 1. **文件 hash**：改动确实写盘；
- 2. **运行时加载**：skill 是否同步到加载目录（`~/.dsh/skills`）、进程是否重启加载新代码（Python 进程 import 旧代码不会自动更新）；
- 3. **行为观察**：实际调用一次，确认新行为出现（如新字段 `zombie_reclaimed`、新错误 `interrupt_budget_exceeded`）。
+ - 决策方在场（交互会话）→ 必须展示并等待确认，不得跳过；
+ - 决策方不在场（纯自动 goal 轮次）→ 按既定授权执行，但**涉及删除、全局配置、外部系统、权限变更的高风险改动仍须停下等待人工确认**；执行时在报告中说明"已按既定授权实施，高风险项已留待人工确认"；
+ - 被驳回/要求调整 → 回到第 3-5 步修订方案后重新展示，不直接实施。
- ### 第 8 步：度量闭环（对比基线）
+ ### 第 7 步：实施
- - 用第 0 步的同一指标重新量化：token 消耗、调用次数、空转时长、supervisor 悬挂数；
- - 确认改进真实发生（不是自我感觉）；
- - 若未改进，回到第 2 步重新找根因。
+ - 最小正确改动（不顺手重构、不扩大范围）；
+ - 新机制必须配回归保护（测试/复验），防止下次改动破坏；
+ - 跑完相关检查（构建、测试、校验、lint），全部通过才算实施完成。
+ ### 第 8 步：验证生效（三件套，缺一不可）
+
+ **改动落地 ≠ 已生效。** 检查生效链路：
+
+ 1. **物证**：改动确实写入目标（文件 hash / 配置生效 / 版本号）；
+ 2. **加载**：运行中的系统确实加载了新内容（重启/热加载/部署确认——旧进程不会自动用新代码/新配置）；
+ 3. **行为观察**：实际触发一次，确认新行为出现（新字段、新报错、新拦截、指标变化）。
+
+ ### 第 9 步：度量闭环（对比基线）
+
+ - 用第 0 步的同一指标重新量化，确认改进真实发生（不是自我感觉）；
+ - 若未改进，回到第 2 步重新找根因——可能根因找错了，或方案落在约定层没生效；
+ - 记录观察期与复发触发条件（尤其半方案）。
+
## 核心原则
- 1. **规则存在 ≠ 被执行**：能落到机制（参数门禁、自动回收、预算上限）就不写建议；
- 2. **临时方案必须伴随机制方案**：否则问题复发；
+ 1. **约束存在 ≠ 被执行**：能落到系统层（硬校验、自动回收、预算上限）就不写建议；
+ 2. **临时方案必须伴随结构性方案**：否则问题复发；
3. **量化优先**：每个问题带数字，每个优化带前后对比；
- 4. **验证实装三件套**：hash → 加载 → 行为，缺一不可；
- 5. **不重复造轮子**：先找业界方案再设计；
- 6. **文档层不执行**：文档/规则层条目必须标注"未强制，待观察"；同一问题反复出现即升级到平台/代码层，不停留在文档层。
+ 4. **验证生效三件套**：物证 → 加载 → 行为，缺一不可；
+ 5. **不重复造轮子**：先检索同类问题的已知解法再设计；
+ 6. **约定层不执行**：约定层条目标注"未强制，待观察"；同一问题反复出现即升级到系统层。
## 输出契约
- 优化完成报告：
+ 问题解决/优化完成报告：
```text
基线（第 0 步数字）
问题清单（全量，带证据）
- 根因分类（缺规则/没执行/无法强制）
- 方案（临时 + 机制，机制落点与行为变化；每个方案标注约束层：平台/代码 | 执行点 | 文档）
- 业界对照（机制 | 框架 | URL）
- 实施（文件/测试/门禁）
- 实装验证（hash / 加载 / 行为观察）
+ 根因分类（缺约束/不执行/无法强制）
+ 方案（临时 + 结构性；每个方案标注约束层：系统 | 流程 | 约定）
+ 借鉴对照（机制 | 出处 | 来源）
+ 计划确认（要改什么 / 不改什么 / 风险与回滚 / 验收标准 / 决策结果：同意|调整|驳回）
+ 实施（改动/回归保护/检查结果）
+ 生效验证（物证 / 加载 / 行为观察）
度量对比（优化前 vs 优化后）
- 文档层条目单独列出并标注"未强制，待观察"（不得自称已解决）
+ 约定层条目单独列出并标注"未强制，待观察"（不得自称已解决）
```
+ ## 与经典方法论的关系
+
+ 本流程骨架与业界经典方法同构，本 skill 的增量在**量化先行**与**约束分层**：
+
+ | 本流程 | DMAIC（六西格玛） | 丰田八步法 | PDCA |
+ |---|---|---|---|
+ | 第 0-1 步 量化+列问题 | Measure / Define | 明确问题 | Plan（现状把握） |
+ | 第 2 步 根因 | Analyze | 根因分析 | Plan（原因分析） |
+ | 第 3-5 步 方案+取舍 | Improve | 对策 | Plan→Do |
+ | 第 6 步 展示计划确认实施 | Improve（决策门/Gate Review） | 决策确认 | Plan→Do（批准后执行） |
+ | 第 7-8 步 实施+验证 | Improve / Control | 实施与效果确认 | Do→Check |
+ | 第 9 步 度量闭环 | Control | 标准化与横展 | Act |
+
## 与相邻 skill 的分工
- - `minimal-implementation`：单点小改的执行纪律；本 skill 管"系统性优化"全流程；
- - `execution-discipline`：执行层不空转；本 skill 管"优化方法论"；
+ - `minimal-implementation`：单点小改的执行纪律；本 skill 管"系统性解决问题"全流程；
+ - `execution-discipline`：执行层不空转；本 skill 管"方法论"；
- `decision-gates`：决策正确性；本 skill 第 5 步的取舍可叠加使用。
- 相关示例见 `examples/`。
+ 相关示例见 `examples/`（示例为 agent 运维领域实例，方法适用于任何领域）。