ln-812-optimization-researcher

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

ln-812-optimization-researcher

类型： L3 工作节点
类别： 8XX 优化

研究竞争基准、行业标准，以及针对分析器识别出的瓶颈的解决方案。为执行器生成按优先级排序的假设。

---

概览

方面	详情
输入	分析器提供的性能图谱（实际测量值：基线指标、各步骤耗时、瓶颈分类、优化提示）
输出	行业基准、候选解决方案、按优先级排序的假设（H1..H7）
模式	研究优先：竞争对手 → 行业 → 本地代码库 → 解决方案 → 假设

---

工作流

阶段： 竞争分析 → 针对瓶颈的专项研究 → 本地代码库检查 → 假设生成 → 研究报告

---

阶段 1：竞争分析

必须阅读： 加载 references/research_tool_fallback.md，了解 MCP 工具优先级链。

目标

确定此类操作达到何种水平才算「优秀」。如果用户未提供目标，则定义目标指标。

研究查询

目标	查询模板	工具
行业基准	"{domain} API response time benchmark {year}"	WebSearch
竞争对手性能	"{competitor_type} {operation} latency"	WebSearch
标准预期	"acceptable response time for {operation_type}"	WebSearch
特定框架的指导	"{framework} {operation} performance best practices"	Context7 / Ref

输出

字段	说明
industry_benchmark	此类操作的预期性能范围
competitor_approaches	顶尖系统的解决方法（2-3 个示例）
recommended_target	建议的目标指标（如果用户未指定）
target_metrics	各指标的定量目标（见下文）
sources	所有研究发现对应的 URL 和日期

目标指标研究

对于 performance_map.baseline 中的每项指标，研究其定量目标：

指标	查询模板	工具
wall_time_ms	"{domain} API response time benchmark {year}"	WebSearch
cpu_time_ms	"{framework} handler CPU time benchmark"	WebSearch
memory_peak_mb	"{domain} API memory usage benchmark {year}"	WebSearch
http_round_trips	"{domain} API call count optimization best practice"	WebSearch
io_bytes	"{domain} file processing throughput benchmark"	WebSearch

输出格式：

target_metrics:
  wall_time_ms:
    value: 500
    source: "industry benchmark: translation APIs p95 200-500ms"
    confidence: HIGH
  http_round_trips:
    value: 2
    source: "best practice: batch API reduces N calls to 1-2"
    confidence: HIGH
  memory_peak_mb:
    value: 128
    source: "similar workload: 64-128MB typical"
    confidence: MEDIUM

置信度等级： HIGH = 找到有来源支持的基准，MEDIUM = 根据最佳实践推导，LOW = 根据一般指导估算。仅包含分析器基线中存在的指标。

---

阶段 2：针对瓶颈的专项研究

必须阅读： 加载 research_query_templates.md，获取各类型瓶颈对应的查询模板。

研究策略

根据分析器给出的主要瓶颈类型：

瓶颈类型	研究重点
架构	批处理、流水线、并行处理、DataLoader 模式
I/O-网络	连接池、HTTP/2、多路复用、缓存
I/O-数据库	查询优化、索引、预加载、批量操作
I/O-文件	流式处理、异步 I/O、内存映射文件
CPU	算法替代方案、向量化、计算缓存、开源软件替代
缓存	驱逐策略、缓存键设计、失效策略、分层缓存、预热
外部	缓存层、熔断器、回退策略、服务提供商替代方案

研究流程

FOR each top bottleneck (max 3):
  1. Select query templates from research_query_templates.md
  2. Execute research chain: Context7 → Ref → WebSearch (per research_tool_fallback.md)
  3. Collect solution approaches with expected impact
  4. Note technology prerequisites (libraries, infrastructure)

解决方案评估

字段	描述
solution	方法名称／描述
source	来源（URL、文档章节）
expected_impact	预估改进幅度（例如，“N＝9 时减少 9 倍”）
complexity	低／中／高
prerequisites	所需条件（库、基础设施、API 支持）
feasibility	HIGH／MEDIUM／LOW——根据前提条件是否具备

---

第 3 阶段：本地代码库检查

在推荐外部解决方案之前，先检查代码库是否已具备相关能力：

检查项	方法
客户端类中的批量方法	在客户端／服务类中搜索 batch、bulk、multi
缓存基础设施	搜索 redis、memcache、cache、@cached、lru_cache
连接池配置	在配置中搜索 pool_size、max_connections、pool
异步变体	搜索方法名称中的 async_、aio、Async 前缀／后缀
未使用的配置	查看客户端／服务配置中的 batch_size、max_connections 参数

对可行性的影响

发现	影响
存在批量 API，但未使用	可行性 = HIGH，复杂度 = LOW
存在缓存基础设施，但此路径未配置使用	可行性 = HIGH，复杂度 = LOW-MEDIUM
不具备现有能力，需要新增库	可行性 = MEDIUM，复杂度 = MEDIUM-HIGH
需要更改基础设施	可行性 = LOW，复杂度 = HIGH

---

第 4 阶段：生成假设（3-7 个）

假设来源（按优先级排序）

优先级	来源
1	本地代码库检查（未使用的现有能力——风险最低）
2	研究发现（业界已验证的模式）
3	性能分析器提供的优化提示

假设格式

字段	描述
id	H1、H2、……H7
description	要更改什么，以及如何更改
bottleneck_addressed	所针对的时间图瓶颈（步骤引用）
expected_impact	预估改进百分比或倍数
complexity	低／中／高
risk	低／中／高
files_to_modify	需要更改的文件列表
dependencies	此假设依赖的其他假设（例如，“H2 需要 H1”）
conflicts_with	如果此假设奏效，哪些假设将不再需要

偏差检查（定稿前必须执行）

偏差	检查方式	示例
移除偏差	对每个“移除 X”的假设，生成配对的“优化 X”替代方案	“移除对齐” → 同时提出“优化对齐配置”
行业偏差	“业界不使用 X” ≠ “我们不需要 X”。检查：我们的产品是否需要它？	“CAT 工具跳过对齐”，但我们的用户需要它来保证质量
过早下结论	“X 很慢” ≠ “X 不对”。慢可能意味着实现不佳，而不是方法错误	对齐耗时 5.9 秒 → 可能是算法不合适，而不是功能本身有问题

**规则：**每个“移除功能”的假设都必须有配对的“优化功能”假设。

修复层级（必须按顺序执行）

按修复层级排列假设。必须始终优先尝试较高层级：

层级	示例	优先级
1. 配置	matching_methods="i"、pool_size=10	最高——优先尝试
2. 基础设施	添加缓存层、扩展服务
3. 框架	使用框架功能（批量 API、内置缓存）
4. 应用代码	重构算法、添加优化
5. 移除功能	移除功能	最低——仅作最后手段

**警示：**如果优先级最高的假设属于第 4—5 层，请重新检查：是否遗漏了第 1—3 层的解决方案？从根本原因开始应用 5 Whys 进行验证。

排序规则

按以下顺序排序：fix_level ASC, expected_impact DESC, complexity ASC, risk ASC。

**冲突检测：**如果 H1（批量 API）解决了 N+1 问题，H3（并行调用）就不再需要。标记 H3.conflicts_with = ["H1"]。

**依赖检测：**如果 H2（缓存预取）基于 H1（批量 API）构建，标记 H2.dependencies = ["H1"]。

---

第 5 阶段：研究报告

报告结构

research_result:
  industry_benchmark:
    metric: "response_time"
    expected_range: "200-500ms"
    source: "..."
  recommended_target: 500          # ms — alias for target_metrics.wall_time_ms.value
  target_metrics:                  # per-metric quantitative targets
    wall_time_ms: { value: 500, source: "...", confidence: HIGH }
    http_round_trips: { value: 2, source: "...", confidence: HIGH }
    memory_peak_mb: { value: 128, source: "...", confidence: MEDIUM }
  competitor_analysis:
    - name, approach, metric, source
  solution_candidates:
    - solution, source, expected_impact, complexity, feasibility
  hypotheses:
    - id, description, bottleneck_addressed, expected_impact, complexity, risk,
      files_to_modify, dependencies, conflicts_with
  local_codebase_findings:
    - "Batch API exists: AlignmentClient.batch_align() — accepts up to 50 pairs"
    - "Redis configured but not used for alignment cache"
  research_sources:
    - url, date, relevance

---

计划模式

只读工作器——所有阶段仅使用 MCP 研究工具（Ref、Context7、WebSearch）和代码分析。在计划模式下通过 Skill() 正常执行。

---

错误处理

错误	恢复方式
所有研究工具均失败	使用内置知识，并声明：“未核实外部来源”
未找到竞争性基准	跳过行业基准，并注明“未找到基线——采用通用指南”
无法生成假设	返回空列表——由协调器决定下一步
本地代码库检查未发现任何内容	仅根据外部研究结果继续

---

参考资料

• research_query_templates.md — 各类瓶颈对应的查询模板
• references/research_tool_fallback.md — MCP 研究工具优先级链

---

运行时摘要产物

**必须阅读：**加载 references/coordinator_summary_contract.md

输出一个 optimization-worker 摘要封装。

托管模式：

• ln-810 传递确定性的 runId 和准确的 summaryArtifactPath
• 将摘要写入提供的 summaryArtifactPath

独立模式：

• 省略 runId 和 summaryArtifactPath
• 写入 .hex-skills/runtime-artifacts/runs/{run_id}/optimization-worker/ln-812--{identifier}.json

完成定义

• 已完成竞争分析（行业基准、竞争对手方案）
• 已针对每项基线指标研究目标指标（数值、来源、置信度）
• 已定义目标指标（由用户提供或根据研究得出）
• 已通过 MCP 工具链研究特定瓶颈的解决方案
• 已检查本地代码库中现有但未使用的功能
• 已生成 3-7 个假设，并按预期影响排序
• 已识别假设之间的依赖和冲突
• 已准备好包含来源的研究报告
• 已将优化研究产物写入共享位置

---

**版本：**2.0.0 **最后更新：**2026-03-14