Token导航 LogoToken导航TokenDH.com
研究检索需要联网clawhub未标认证来源可访问clear审计通过

technical-research技术研究

Agent Skill

technical-research 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

11,332

周安装

454

GitHub Stars

公开资料未说明

下载量

3,668
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:technical-research(技术研究)
来源仓库:https://github.com/linshengli/technical-research
安装命令:
openclaw skills install technical-research
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install technical-research

简介

对技术领域进行系统化深度调研并输出完整MD报告。

  • 覆盖概念剖析、行业情报、方案对比与整合四个维度。
  • 集成GitHub实时数据抓取,支持技术选型与竞品分析。
  • 需联网获取最新资料,确保信息时效性。technical-research 属于研究检索类 Skill,可作为该场景下的辅助能力补充。
  • 输出结果仅供参考,实际应用前应交叉验证关键事实。

SKILL.md

name
technical-research
description
|

技术领域深度调研

对任意技术领域进行结构化、可复现的深度调研,产出四个维度的专业报告和一份精华总结。

适用场景

  • 技术选型前的全面调研
  • 新领域快速入门
  • 竞品/方案横向对比
  • 团队内部技术分享素材准备

用法

调研 {技术领域}

示例:调研 Agent Memory 机制调研 RAG 技术调研 向量数据库


调研框架

一次完整调研包含四个维度 + 最终整合,按依赖关系分为两个层级:

第一层(独立维度,可同时开展):
  ├── 概念剖析  —— 技术原理和架构的深度理解
  ├── 行业情报  —— 最新开源项目、论文、博客的信息收集
  └── 方案对比  —— 多种实现方案的横向评估

第二层(依赖第一层的结果):
  ├── 精华整合  —— 将三份报告浓缩为可传播的总结
  └── 最终整合  —— 将所有内容(三个维度 + 精华整合)合并为一份完整 md 文件

以下逐一定义每个维度的目标、方法和输出规范。


维度一:概念剖析

目标

建立对目标技术的深层理解——不仅知道"是什么",还要理解"为什么这样设计"和"如何实现"。

输出规范

1. 定义澄清(约 200 字)

  • 通行定义:该领域最被广泛接受的定义
  • 常见误解:至少列出 3 个容易混淆的认知偏差
  • 边界辨析:与相邻概念(易混淆技术)的核心区别

2. 核心架构

使用 ASCII 图呈现系统架构,标注各组件的职责和数据流向:

┌──────────────────────────────────────┐
│         {领域} 系统架构               │
├──────────────────────────────────────┤
│  输入 → [处理层] → [存储层] → [输出层] │
│           ↓          ↓                │
│        [辅助组件]  [监控组件]          │
└──────────────────────────────────────┘

每个组件附带一句话说明其功能。

3. 数学形式化(3-5 个公式)

用 LaTeX 公式描述核心机制,覆盖以下方面:

  • 核心算法的数学定义
  • 关键性能指标的计算方式
  • 效率/成本的量化模型

公式应当反映技术本质,而非堆砌符号。每个公式附带一行自然语言解释。

4. 实现逻辑(Python 伪代码)

class CoreSystem:
    """核心类,体现该领域的关键抽象"""
    def __init__(self, config):
        self.component_a = ...  # 说明职责
        self.component_b = ...  # 说明职责

    def core_operation(self, input):
        """核心操作,体现关键算法逻辑"""
        intermediate = self.component_a.process(input)
        result = self.component_b.transform(intermediate)
        return result

伪代码应当体现架构思想,而非纠缠于实现细节。

5. 性能指标

指标典型目标值测量方式说明
延迟< X ms端到端基准测试...
吞吐> Y req/s负载测试...
准确率> Z%标准评测集...
............

6. 扩展性与安全性

  • 水平扩展:如何通过增加节点提升容量
  • 垂直扩展:单节点的优化上限
  • 安全考量:该领域特有的安全风险和防护要点
  • ...

维度二:行业情报

目标

收集该领域最新的开源项目、学术论文和技术博客,建立对当前生态的全景认知。

数据新鲜度要求

所有情报数据必须标注来源和日期。使用以下脚本模板进行实时信息整理:

GitHub 项目整理

必须使用 WebSearch/WebFetch 工具获取最新 GitHub 数据,不能依赖训练数据中的过时信息。

搜索策略(使用 WebSearch 执行以下查询):

"{topic} github stars 2025 2026"
"best {topic} open source libraries github"
"awesome {topic} github"
"site:github.com {topic} stars"

对搜索结果中发现的重要项目,使用 WebFetch 访问其 GitHub 页面,获取以下实时数据:

  • 当前 Stars 数量
  • 最近提交日期
  • 项目描述和核心功能
  • 技术栈信息

筛选标准:

  • 最近 6 个月有活跃提交
  • Stars > 1000(优先)或 > 500(补充)
  • 官方维护或知名团队维护

学术论文整理

必须使用 WebSearch/WebFetch 工具获取最新数据 搜索查询模板:

"site:arxiv.org {topic} {current_year-5} {current_year}"
"{topic} NeurIPS OR ICML OR ACL OR AAAI {current_year-5}"

技术博客整理

必须使用 WebSearch/WebFetch 工具获取最新数据 搜索查询模板:

"{topic} tutorial best practices {current_year}"
"{topic} medium.com OR dev.to {current_year-5} {current_year}"

输出规范

1. GitHub 热门项目(15+ 个)

项目Stars核心功能技术栈最后更新链接

2. 关键论文(12 篇)

选择策略(按优先级):

  1. 影响力优先:被引次数高、GitHub 实现多、社区讨论热
  2. 时效性次之:近两年的最新研究
  3. 来源权威:顶级会议 > arXiv 顶会投稿 > arXiv 预印本
  4. ...

推荐比例:

  • 经典高影响力论文(奠基性工作):约 40%
  • 最新 SOTA 论文(前沿进展):约 60%
论文作者/机构年份会议/期刊核心贡献影响力指标链接

3. 系统化技术博客(10 篇)

选择标准:

  • 内容深度:系列文章、深度教程、架构解析(排除碎片化新闻)
  • 作者权威:官方团队博客、知名专家、一线工程师实践
  • 语言平衡:英文约 70%,中文约 30%

英文推荐来源:OpenAI Blog、Google AI Blog、Anthropic Blog、LangChain Blog、个人专家(Eugene Yan、Chip Huyen、Sebastian Raschka 等)

中文推荐来源:大厂技术博客(美团、阿里、字节等)、知乎专栏、机器之心、PaperWeekly ...

博客标题作者/来源语言类型核心内容日期链接

4. 技术演进时间线

按时间顺序列出该领域的关键里程碑事件,标注事件、发起方和影响。


维度三:方案对比

目标

对该领域的主流实现方案进行系统化横向对比,给出可操作的选型建议。

输出规范

1. 历史发展时间线

{年份} ─┬─ {技术/事件} → {对行业的影响}
{年份} ─┼─ {技术/事件} → {对行业的影响}
{年份} ─┼─ {技术/事件} → {对行业的影响}
{年份} ─┴─ 当前状态:{一句话总结}

2. N 种方案横向对比(5-7 种)

方案原理优点(3+)缺点(3+)适用场景成本量级

每个方案的优缺点至少各列 3 条,避免泛泛而谈。

3. 技术细节对比

维度方案A方案B方案C方案D方案E
性能
易用性
生态成熟度
社区活跃度
学习曲线

4. 选型建议

场景推荐方案核心理由预估月成本
小型项目/原型验证
中型生产环境
大型分布式系统

选型建议应当基于当年最新的技术趋势和生态状况。


精华整合

目标

将三份维度报告浓缩为可快速传播的精华内容。精华整合依赖前三个维度的输出。

输出规范

1. The One 公式

用一个"悖论式等式"概括该领域的核心本质:

$$ \ ext{领域} = \underbrace{\ ext{核心组件1}}_{\ ext{功能}} + \underbrace{\ ext{核心组件2}}_{\ ext{功能}} - \underbrace{\ ext{核心损耗}}_{\ ext{说明}} $$

这个公式的目的是帮助读者用一个心智模型记住整个领域。

2. 一句话解释

用费曼技巧写一句话,让非技术背景的人也能理解该领域是做什么的。

3. 核心架构图

输入 → [层1] → [层2] → [层3] → 输出
        ↓       ↓       ↓
      指标1   指标2   指标3

4. STAR 总结

部分内容要求字数
Situation(背景+痛点)行业现状和核心挑战100-150 字
Task(核心问题)技术要解决的关键问题和约束80-120 字
Action(主流方案)技术演进的关键阶段和核心突破120-180 字
Result(效果+建议)当前成果、现存局限、实操建议80-120 字

5. 理解确认问题

提出 1 个能检验是否真正理解该领域的问题,并给出参考答案。


最终整合

目标

将所有内容(三个维度报告 + 精华整合)合并为一份完整的 Markdown 文件: ${topic}-research.md。不裁剪内容,完整保留所有部分。

整合规范

最终输出文件按以下结构组织:

# {topic} 深度调研报告

> 调研日期:{date}
> 调研主题:{topic}

---

## 第一部分:概念剖析

{完整的概念剖析报告内容,原样保留}

---

## 第二部分:行业情报

{完整的行业情报报告内容,原样保留}

---

## 第三部分:方案对比

{完整的方案对比报告内容,原样保留}

---

## 第四部分:精华整合

{完整的精华整合内容,包括 The One 公式、一句话解释、核心架构图、STAR 总结、理解确认问题}

注意事项:

  • 不裁剪内容:四个部分的内容完整合并,不删减任何部分
  • 各部分之间使用 --- 分隔线隔开
  • 保持原始报告中的所有表格、代码块、图表

输出文件结构

research/{topic}/
├── 00-索引.md              # 文件导航和执行统计
├── 01-完整调研报告.md       # 全部维度报告合集
├── 02-The-All-in-One.md     # 精华整合
├── 03-STAR-总结.md          # STAR 方法论总结
├── {topic}-concept.md       # 概念剖析报告
├── {topic}-intel.md         # 行业情报报告
├── {topic}-analysis.md      # 方案对比报告
└── {topic}-research.md      # 【最终整合】包含全部四个部分的完整单文件

对每个文件检验是否存在是否符合整合规范,确保所有内容完整保留,如果内容缺失,需要及时提醒用户并要求重新生成。 research/{topic} 目录存放面向读者的最终产出 + 各维度的原始报告,便于后续引用和增量更新。{topic}-research.md 是最终的一站式完整文件。


质量标准

  1. 数据新鲜度:情报维度的所有数据必须标注来源和日期,优先使用近两年的信息
  2. 内容完整性:每份报告生成后需验证字符数 > 100,确认包含有效内容
  3. 格式规范性:所有报告使用 Markdown 格式,表格对齐、代码块标注语言
  4. 总字数:全部产出合计约 6000 字以上
  5. 可操作性:选型建议需包含具体场景和成本估算,而非笼统的"各有优缺点"

*版本:4.0 | 类型:知识流程版*

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

91.36%
按下载量换算3,351

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills