hellohushuai

---
name: get-resource-element
description: 根据输入的产品名称，查询对应产品的硬件资源评估要点是否满足。Use when: (1) 需要验证产品硬件资源评估要点是否完整，(2) 对比已提供的评估要点与标准要求的差异，(3) 查询产品对应的标准单产品硬件资源测算文件中的评估要点。支持产品线：CDSS 系统、VTE 系统、病历质控系统、单病种系统、智医助理 - 基层人工智能辅助诊疗系统。
---

# Get Resource Element - 评估要点对比技能

本技能用于根据产品名称查询对应的标准评估要点，并对比已提供的评估要点是否完整。

## 核心功能

1. **解析需求** - 从输入中提取产品名称和已提供的评估要点
2. **查询知识库** - 根据产品名称定位 `kb/<产品目录>/<产品>-标准单产品硬件资源测算.md` 文件
3. **提取评估要点** - 从文件中提取"服务器资源评估输入项"部分的所有要点
4. **对比分析** - 将已提供的评估要点与所需要点进行智能匹配对比
5. **返回结果** - 满足则返回 `ok`，不满足则返回缺少的评估要点列表

## 使用流程

### 步骤 1: 解析输入

从用户输入中提取：
- **产品名称**: 如"病历质控系统"、"CDSS 系统"等
- **已提供的评估要点**: 用户已经提供的评估要点列表

示例输入：
```
产品：病历质控系统
已提供评估要点：
- 年门诊人次 10 万
- 年出院人次 5000
```

### 步骤 2: 查询产品文件

根据产品名称在知识库中查找对应文件：
- 遍历 `kb/` 目录下的所有子目录
- 查找包含产品名称的目录
- 定位该目录下的 `*标准单产品硬件资源测算.md` 文件

文件命名规则：`<产品简称>-标准单产品硬件资源测算.md`

### 步骤 3: 提取评估要点

从文件中提取"服务器资源评估输入项"章节的所有编号列表项。

示例（病历质控系统）：
1. 年门诊人次
2. 年出院人次
3. 医护人员总数

### 步骤 4: 对比评估要点

使用 `scripts/compare_elements.py` 脚本进行对比：
- 标准化处理（去除空格、统一大小写）
- 支持部分匹配（如"年门诊人次"匹配"年门诊人次 10 万"）
- 识别满足和缺失的要点

### 步骤 5: 返回结果

**满足时**:
```
ok
```

**不满足时**:
```
缺少的评估要点：医护人员总数
```

## 脚本使用

### compare_elements.py

**位置**: `scripts/compare_elements.py`

**输入** (JSON 格式):
```json
{
  "product": "病历质控系统",
  "provided_elements": ["年门诊人次 10 万", "年出院人次 5000"],
  "kb_dir": "/Users/hushuai/.openclaw/workspace-ClinicalManager/kb"
}
```

**输出** (JSON 格式):

满足时：
```json
{
  "status": "ok",
  "message": "ok",
  "details": {
    "satisfied": ["年门诊人次", "年出院人次"],
    "missing": [],
    "is_complete": true
  }
}
```

不满足时：
```json
{
  "status": "missing",
  "message": "缺少的评估要点：医护人员总数",
  "details": {
    "satisfied": ["年门诊人次", "年出院人次"],
    "missing": ["医护人员总数"],
    "is_complete": false
  }
}
```

**执行方式**:
```bash
python3 scripts/compare_elements.py '<input_json>'
```

## 支持的产品线

- CDSS 系统
- VTE 系统
- 病历质控系统
- 单病种系统
- 智医助理 - 基层人工智能辅助诊疗系统

## 示例

### 示例 1: 评估要点完整

**用户输入**:
```
帮我检查一下病历质控系统的评估要点是否完整：
- 年门诊人次：10 万
- 年出院人次：5000
- 医护人员总数：200 人
```

**处理流程**:
1. 解析出产品：病历质控系统
2. 解析出已提供要点：年门诊人次、年出院人次、医护人员总数
3. 查询文件：`kb/病历质控系统/病历质控 - 标准单产品硬件资源测算.md`
4. 提取所需要点：年门诊人次、年出院人次、医护人员总数
5. 对比结果：全部满足

**输出**:
```
ok
```

### 示例 2: 评估要点缺失

**用户输入**:
```
检查 CDSS 系统的评估要点，目前有：
- 年门诊人次 15 万
```

**处理流程**:
1. 解析出产品：CDSS 系统
2. 解析出已提供要点：年门诊人次
3. 查询文件：`kb/CDSS 系统/CDSS-标准单产品硬件资源测算.md`
4. 提取所需要点：年门诊人次、年出院人次、医护人员总数
5. 对比结果：缺少 2 项

**输出**:
```
缺少的评估要点：年出院人次、医护人员总数
```

## 注意事项

1. **产品名称匹配**: 支持模糊匹配，如"病历质控"可匹配"病历质控系统"
2. **评估要点匹配**: 支持部分匹配，如"年门诊人次"可匹配"年门诊人次 10 万"
3. **知识库路径**: 默认为 `/Users/hushuai/.openclaw/workspace-ClinicalManager/kb`，可通过 `kb_dir` 参数自定义
4. **文件格式**: 产品文件必须是 Markdown 格式，且包含"## 服务器资源评估输入项"章节

FILE:scripts/compare_elements.py
#!/usr/bin/env python3
"""
评估要点对比脚本

功能：
1. 读取产品对应的标准单产品硬件资源测算文件
2. 提取所需的评估要点
3. 对比提供的评估要点与所需评估要点
4. 返回对比结果
"""

import os
import re
import sys
import json
from pathlib import Path


def find_product_file(product_name: str, kb_dir: str) -> str:
    """
    根据产品名称查找对应的标准单产品硬件资源测算文件
    
    Args:
        product_name: 产品名称（如：病历质控系统、CDSS 系统等）
        kb_dir: 知识库目录路径
    
    Returns:
        文件路径，如果未找到返回 None
    """
    # 遍历 kb 目录下的所有子目录
    kb_path = Path(kb_dir)
    if not kb_path.exists():
        return None
    
    # 查找包含产品名称的目录
    for subdir in kb_path.iterdir():
        if subdir.is_dir() and product_name in subdir.name:
            # 在该目录下查找标准单产品硬件资源测算文件
            for file in subdir.glob("*标准单产品硬件资源测算.md"):
                return str(file)
    
    return None


def extract_required_elements(file_path: str) -> list:
    """
    从文件中提取所需的评估要点
    
    Args:
        file_path: 文件路径
    
    Returns:
        评估要点列表
    """
    required_elements = []
    
    try:
        with open(file_path, 'r', encoding='utf-8') as f:
            content = f.read()
        
        # 提取"服务器资源评估输入项"部分的内容
        match = re.search(r'## 服务器资源评估输入项\s*\n(.*?)(?=\n##|\Z)', content, re.DOTALL)
        if match:
            section = match.group(1)
            # 提取编号列表项
            items = re.findall(r'^\d+\.\s*(.+?)$', section, re.MULTILINE)
            required_elements.extend(items)
        
        # 清理空白字符
        required_elements = [item.strip() for item in required_elements if item.strip()]
        
    except Exception as e:
        print(f"Error reading file: {e}", file=sys.stderr)
        return []
    
    return required_elements


def compare_elements(required: list, provided: list) -> dict:
    """
    对比所需评估要点和已提供的评估要点
    
    Args:
        required: 所需评估要点列表
        provided: 已提供评估要点列表
    
    Returns:
        对比结果字典
    """
    # 标准化处理（去除空格、统一大小写等）
    required_normalized = [item.strip().lower() for item in required]
    provided_normalized = [item.strip().lower() for item in provided]
    
    missing_elements = []
    satisfied_elements = []
    
    for req in required:
        req_norm = req.strip().lower()
        found = False
        for prov in provided:
            prov_norm = prov.strip().lower()
            # 检查是否匹配（支持部分匹配）
            if req_norm in prov_norm or prov_norm in req_norm:
                found = True
                break
        
        if found:
            satisfied_elements.append(req)
        else:
            missing_elements.append(req)
    
    return {
        "satisfied": satisfied_elements,
        "missing": missing_elements,
        "is_complete": len(missing_elements) == 0
    }


def main():
    """
    主函数
    
    输入格式（JSON）:
    {
        "product": "产品名称",
        "provided_elements": ["已提供的评估要点 1", "已提供的评估要点 2", ...],
        "kb_dir": "知识库目录路径（可选，默认为 workspace/kb）"
    }
    
    输出格式（JSON）:
    {
        "status": "ok" | "missing",
        "message": "ok" 或 缺少的评估要点信息,
        "details": {
            "satisfied": [...],
            "missing": [...],
            "is_complete": true/false
        }
    }
    """
    if len(sys.argv) < 2:
        print(json.dumps({
            "error": "Please provide input JSON as argument"
        }, ensure_ascii=False))
        sys.exit(1)
    
    try:
        input_data = json.loads(sys.argv[1])
    except json.JSONDecodeError as e:
        print(json.dumps({
            "error": f"Invalid JSON input: {str(e)}"
        }, ensure_ascii=False))
        sys.exit(1)
    
    product = input_data.get("product", "")
    provided_elements = input_data.get("provided_elements", [])
    kb_dir = input_data.get("kb_dir", "/Users/hushuai/.openclaw/workspace-ClinicalManager/kb")
    
    if not product:
        print(json.dumps({
            "error": "Product name is required"
        }, ensure_ascii=False))
        sys.exit(1)
    
    # 查找产品文件
    file_path = find_product_file(product, kb_dir)
    if not file_path:
        print(json.dumps({
            "error": f"Could not find resource file for product: {product}"
        }, ensure_ascii=False))
        sys.exit(1)
    
    # 提取所需评估要点
    required_elements = extract_required_elements(file_path)
    if not required_elements:
        print(json.dumps({
            "error": f"No required elements found in file: {file_path}"
        }, ensure_ascii=False))
        sys.exit(1)
    
    # 对比评估要点
    result = compare_elements(required_elements, provided_elements)
    
    # 输出结果
    if result["is_complete"]:
        output = {
            "status": "ok",
            "message": "ok",
            "details": result
        }
    else:
        missing_str = "、".join(result["missing"])
        output = {
            "status": "missing",
            "message": f"缺少的评估要点：{missing_str}",
            "details": result
        }
    
    print(json.dumps(output, ensure_ascii=False))


if __name__ == "__main__":
    main()

---
name: apple-mail-search
description: "Apple Mail search on macOS with fast metadata and full body lookup. Use for finding messages in Mail.app by subject/sender/recipient/date, opening messages, and reading full body text. "
homepage: https://clawdhub.com/gumadeiras/apple-mail-search-safe
repository: https://github.com/gumadeiras/fruitmail-cli
metadata: {"clawdbot":{"emoji":"📧","requires":{"bins":["fruitmail"]},"install":[{"id":"node","kind":"node","package":"apple-mail-search-cli","bins":["fruitmail"],"label":"Install fruitmail CLI (npm)"}]}}
---

# Fruitmail (Fast & Safe)

Fast SQLite-based search for Apple Mail.app with full body content support.

## Installation

```bash
npm install -g apple-mail-search-cli
```

## Usage

```bash
# Complex search
fruitmail search --subject "invoice" --days 30 --unread

# Search by sender
fruitmail sender "@amazon.com"

# List unread emails
fruitmail unread

# Read full email body (supports --json)
fruitmail body 94695

# Open in Mail.app
fruitmail open 94695

# Database stats
fruitmail stats
```

## Commands

| Command | Description |
|---------|-------------|
| `search` | Complex search with filters |
| `sender <query>` | Search by sender email |
| `unread` | List unread emails |
| `body <id>` | Read full email body (AppleScript) |
| `open <id>` | Open email in Mail.app |
| `stats` | Database statistics |

## Search Options

```
--subject <text>   Search subject lines
--days <n>         Last N days
--unread           Only unread emails
--limit <n>        Max results (default: 20)
--json             Output as JSON
--copy             Copy DB before query (safest mode)
```

## Examples

```bash
# Find bank statements from last month
fruitmail search --subject "statement" --days 30

# Get unread emails as JSON
fruitmail unread --json | jq '.[] | .subject'

# Find emails from Amazon
fruitmail sender "@amazon.com" --limit 50
```

## Performance

| Method | Time for 130k emails |
|--------|---------------------|
| AppleScript (full iteration) | 8+ minutes |
| SQLite (this tool) | **~50ms** |

## Technical Details

- **Database:** `~/Library/Mail/V{9,10,11}/MailData/Envelope Index`
- **Query method:** SQLite (read-only) + AppleScript (body content)
- **Safety:** Read-only mode prevents modification; optional `--copy` mode available

## Notes

- **macOS only** — queries Apple Mail.app's local database
- **Read-only** — can search/read but cannot compose/send
- **To send emails:** Use the `himalaya` skill (IMAP/SMTP)

## Source

https://github.com/gumadeiras/fruitmail-cli

FILE:_meta.json
{
  "ownerId": "kn70v8jresmqyagktg0erwmp217z59ky",
  "slug": "apple-mail-search-safe",
  "version": "5.0.4",
  "publishedAt": 1771448906692
}

---
name: ai-resource-master
description: 大模型服务器资源评估。用于医疗行业大模型应用场景的算力资源需求评估和测算，根据门诊/住院诊疗量和大模型应用场景数推导GPU算力需求。使用场景：用户询问大模型算力评估、AI服务器资源配置、GPU算力需求测算等。
---

# AI大模型服务器资源评估

本技能用于评估医疗行业大模型应用场景的算力资源需求，根据门诊/住院诊疗量和大模型应用场景推导GPU算力需求。

## 评估流程

### 第一步：收集必要信息

如果用户未提供以下信息，必须询问：

**必备信息：**
1. **地区门诊年诊疗次数**（单位：万人次/年）
2. **地区住院年诊疗次数**（单位：万人次/年）
3. **大模型应用场景列表**（从以下选项中选择）

**可选信息：**
- 各场景覆盖率（如无提供，使用默认值）
- 计划使用的GPU型号（如无提供，默认按910B3显卡测算）

### 第二步：场景定义与参数

#### 大模型应用场景列表

| 场景名称 | 类型 | 单次占用时间 | 默认覆盖范围 |
|---------|------|-------------|-------------|
| 知识问答 | 对话 | 24秒/次 | 按需配置 |
| 问诊 | 对话 | 24秒/次 | 按需配置 |
| 报告解读 | 对话 | 24秒/次 | 门诊5% |
| 导医导诊 | 对话 | 24秒/次 | 门诊30% |
| 病史采集 | 对话 | 24秒/次 | 按需配置 |
| AI陪诊 | 对话 | 24秒/次 | 按需配置 |
| 智能随访 | 对话 | 24秒/次 | 按需配置 |
| 病历生成-门诊 | 生成 | 30秒/次 | 门诊100% |
| 病历生成-住院 | 生成 | 50秒/次 | 住院100% |
| 辅助诊断 | 分析 | 50秒/次 | 门诊100% |
| 病历质控-门诊 | 质控 | 40秒/次 | 门诊100% |
| 病历质控-住院 | 质控 | 60秒/次 | 住院100% |
| 诊疗推荐-门诊 | 推荐 | 30秒/次 | 门诊100% |
| 诊疗推荐-住院 | 推荐 | 40秒/次 | 住院100% |
| 报告解读-专用 | 分析 | 20秒/次 | 门诊5% |
| 患者画像提取 | 分析 | 120秒/次 | 门诊+住院100% |

#### 场景分类说明

**对话类场景**（单次24秒）：
- 知识问答、问诊、报告解读（对话类）
- 导医导诊、病史采集
- AI陪诊、智能随访

**生成类场景**：
- 病历生成-门诊：30秒/次
- 病历生成-住院：50秒/次

**分析类场景**：
- 辅助诊断：50秒/次
- 病历质控-门诊：40秒/次
- 病历质控-住院：60秒/次
- 诊疗推荐-门诊：30秒/次
- 诊疗推荐-住院：40秒/次
- 报告解读-专用：20秒/次
- 患者画像提取：120秒/次

### 第三步：算力推导公式

#### 日均调用量计算

日门诊量 = 年门诊量（万人次）× 10000 ÷ 365
日住院量 = 年住院量（万人次）× 10000 ÷ 365

#### 单场景占用时间计算

某场景日占用时间（秒）= 日调用量 × 单次占用时间（秒）
某场景日占用时间（小时）= 日占用时间（秒）÷ 3600

#### 总占用时间汇总

总占用时间（小时）= 所有场景占用时间之和

### 第四步：算力资源配置

#### 默认配置参数（910B3显卡）

- 每卡并发路数：10路
- 单卡日处理时间：10路 × 8小时 = 80小时/卡/日

#### 显卡需求计算

总显卡需求（卡）= 总占用时间（小时）÷ 80小时/卡

#### 一体机配置（华为一体机）

- 单台一体机卡数：8卡
- 一体机台数 = 总显卡需求 ÷ 8，向上取整

#### 总算力计算（可选）

如用户需要总算力（P）：
- 单台华为一体机（8卡910B3）算力：2.5P
- 总算力 = 一体机台数 × 2.5P

## 输出格式规范

### 格式要求

1. 使用普通文档格式，**不要使用数学公式**
2. **不要使用表格**，正常分行描述
3. 输出结构清晰，层次分明

### 标准输出模板

```
X. 算力资源
X.X 区域大模型算力资源需求评估
X.X.X 模型引擎处理能力测算

服务场景需求背景：
XX地区年均门诊量约XXXX万人次，住院人数约XX万人次。主要服务场景包括：XXX、XXX、XXX等。

日均调用量测算：

（1）场景一名称
- 覆盖率：XX%
- 日调用量：X.XX万次
- 占用时间：X.XX万×XX秒=XXX万秒≈XXX.X小时

（2）场景二名称
- 覆盖率：XX%
- 日调用量：X.XX万次
- 占用时间：X.XX万×XX秒=XXX万秒≈XXX.X小时

[继续列出所有场景...]

X.X.X 总占用时间汇总

各场景占用时间累加：
XXX.X + XXX.X + ... = XXXX.X小时

X.X.X 算力资源配置

- 单卡处理能力（XX显卡）：
 - 每卡支持X路并发
 - 单卡日处理时间：X×X = XX小时

- 总显卡需求：
 - XXXX.X小时/XX小时≈XX.X卡
 - 实例配置：XX.X/X≈X.X 台一体机
 - 向上取整 X台一体机

- 总算力（如需要）：
 - 单台一体机（X卡）提供X.XP算力
 - X台×X.XP=XX.XP
```

## 执行步骤

1. **信息收集**：确认用户提供门诊/住院年诊疗量、选择的大模型场景
2. **数据计算**：按公式计算日调用量、各场景占用时间
3. **资源推导**：计算显卡需求、一体机台数
4. **格式化输出**：按标准模板生成算力评估报告

## 参考文档

详细的推导参数和示例请参考：
- [references/calculation-params.md](references/calculation-params.md) - 计算参数详细说明
- [references/example-output.md](references/example-output.md) - 输出示例

FILE:_meta.json
{
  "ownerId": "kn734em93x2rcppfhv0j8f55bh82c6e1",
  "slug": "ai-resource-master",
  "version": "1.0.1",
  "publishedAt": 1773977431365
}
FILE:references/calculation-params.md
# 大模型算力计算参数

## 单场景时间参数

### 对话类场景

所有对话类场景统一按24秒/次计算：

- 知识问答：24秒/次
- 问诊：24秒/次
- 报告解读（对话类）：24秒/次
- 导医导诊：24秒/次
- 病史采集：24秒/次
- AI陪诊：24秒/次
- 智能随访：24秒/次

### 生成类场景

- 病历生成-门诊：30秒/次
- 病历生成-住院：50秒/次

### 分析类场景

- 辅助诊断：50秒/次
- 病历质控-门诊：40秒/次
- 病历质控-住院：60秒/次
- 诊疗推荐-门诊：30秒/次
- 诊疗推荐-住院：40秒/次
- 报告解读-专用：20秒/次
- 患者画像提取：120秒/次

## 默认覆盖率

### 门诊相关场景

- 辅助诊断：100%门诊患者
- 病历质控-门诊：100%门诊患者
- 诊疗推荐-门诊：100%门诊患者
- 病历生成-门诊：100%门诊患者
- 导医导诊：30%门诊患者（估算值）
- 报告解读：5%门诊患者

### 住院相关场景

- 病历质控-住院：100%住院患者
- 诊疗推荐-住院：100%住院患者
- 病历生成-住院：100%住院患者

### 全场景覆盖

- 患者画像提取：100%门诊 + 100%住院患者

## GPU配置参数

### 910B3显卡

- 每卡并发路数：10路
- 单卡日处理时间：10路 × 8小时 = 80小时

### 华为一体机

- 单台卡数：8卡
- 单台算力：2.5P（FP16）

## 计算公式汇总

### 基础数据

日门诊量 = 年门诊量（万人次）× 10000 ÷ 365
日住院量 = 年住院量（万人次）× 10000 ÷ 365

### 单场景计算

日调用量 = 日患者量 × 覆盖率
日占用时间（秒）= 日调用量 × 单次时间（秒）
日占用时间（小时）= 日占用时间（秒） ÷ 3600

### 资源需求

总占用时间 = 所有场景占用时间之和
总显卡需求 = 总占用时间 ÷ 单卡日处理能力
一体机台数 = 总显卡需求 ÷ 单台卡数，向上取整
总算力 = 一体机台数 × 单台算力

FILE:references/example-output.md
# 输出示例

## 示例一：完整版算力评估报告

以下是一个包含多个场景的算力评估报告示例：

```
1. 算力资源
1.1 自贡区域大模型算力资源需求评估
1.1.1 模型引擎处理能力测算

服务场景需求背景：
自贡地区年均门诊量约2000万人次，住院人数按照门诊量的3%估算约为60万人次。主要服务场景包括：导医导诊、病史采集、AI陪诊、智能随访、辅诊、病历生成与质控等。

日均调用量测算：

（1）辅助诊断
- 覆盖率：100%门诊患者
- 日调用量：5.48万次
- 占用时间：5.48万×50s=274万秒≈761.1小时

（2）病历质控-门诊
- 覆盖率：100%门诊患者
- 日调用量：5.48万次
- 占用时间：5.48万×40s=219.2万秒≈608.9小时

（3）病历质控-住院
- 覆盖率：100%住院患者
- 日调用量：0.16万次（按60万住院/年计算）
- 占用时间：0.16万×60s=9.6万秒≈26.7小时
- 总质控时间：608.9+26.7=635.6小时

（4）导医导诊（对话类场景）
- 覆盖率：按30%门诊患者使用
- 日调用量：5.48万×30%≈1.64万次
- 占用时间：1.64万×24s=39.36万秒≈109.3小时

（5）病历生成-门诊
- 覆盖率：100%门诊患者
- 日调用量：5.48万次
- 占用时间：5.48万×30s=164.4万秒≈456.7小时

（6）病历生成-住院
- 覆盖率：100%住院患者
- 日调用量：0.16万次
- 占用时间：0.16万×50s=8万秒≈22.2小时

（7）诊疗推荐-门诊
- 覆盖率：100%门诊患者
- 日调用量：5.48万次
- 占用时间：5.48万×30s=164.4万秒≈456.7小时

（8）报告解读
- 覆盖率：按5%门诊患者使用
- 日调用量：5.48万×5%≈0.27万次
- 占用时间：0.27万×20s=5.4万秒≈15小时

1.1.2 总占用时间汇总

各场景占用时间累加：
761.1 + 635.6 + 109.3 + 456.7 + 22.2 + 456.7 + 15 = 2456.6小时

1.1.3 算力资源配置

- 单卡处理能力（910B3显卡）：
 - 每卡支持10路并发
 - 单卡日处理时间：10×8=80小时

- 总显卡需求：
 - 2456.6小时/80小时≈30.7卡
 - 实例配置：30.7/8≈3.8台华为一体机
 - 向上取整4台一体机

- 总算力：
 - 单台华为一体机（8卡）提供2.5P算力
 - 4台×2.5P=10P
```

## 示例二：简化版

当只需要计算特定几个场景时：

```
1. 算力资源
1.1 XX区域大模型算力资源需求评估
1.1.1 模型引擎处理能力测算

服务场景需求背景：
XX地区年均门诊量约500万人次，住院人数约15万人次。主要服务场景包括：辅助诊断、病历生成。

日均调用量测算：

（1）辅助诊断
- 覆盖率：100%门诊患者
- 日调用量：1.37万次
- 占用时间：1.37万×50s=68.5万秒≈190.3小时

（2）病历生成-门诊
- 覆盖率：100%门诊患者
- 日调用量：1.37万次
- 占用时间：1.37万×30s=41.1万秒≈114.2小时

（3）病历生成-住院
- 覆盖率：100%住院患者
- 日调用量：0.04万次
- 占用时间：0.04万×50s=2万秒≈5.6小时

1.1.2 总占用时间汇总

各场景占用时间累加：
190.3 + 114.2 + 5.6 = 310.1小时

1.1.3 算力资源配置

- 单卡处理能力（910B3显卡）：
 - 每卡支持10路并发
 - 单卡日处理时间：10×8=80小时

- 总显卡需求：
 - 310.1小时/80小时≈3.9卡
 - 实例配置：3.9/8≈0.5台华为一体机
 - 向上取整1台一体机
```

## 关键提示

1. 每个场景都要明确列出：覆盖率、日调用量、占用时间
2. 同类场景可以合并计算（如门诊质控和住院质控）
3. 最终显卡数量必须向上取整
4. 一体机台数根据显卡总数计算，同样需要向上取整

---
name: resource-master
description: 根据知识库中的服务器资源测算文档进行服务器资源评估和汇总。使用场景：用户询问医疗产品项目的服务器资源配置、硬件资源测算、资源汇总等。支持多产品整合评估。
---

# Resource Master - 服务器资源评估技能

## 核心流程

### 1. 知识库路由判断
知识库目录（位于 workspace 内）：`kb/`
1. 根据用户问题中的产品名称，选择需要查询的知识文档（不超过 10 个）
2. 优先获取 `{产品名}-标准单产品硬件资源测算.md` 文件（文件路径没有空格，如有需要去除）

### 2. 输入参数校验

根据知识文件内容，检查用户输入是否包含硬件资源测算所需的所有输入项（去重），涉及数字和汉字混合的，转换成数字（例如：50万 转换成500000）。如缺失，提醒用户补充：

**常见输入项：**
- 医院名称/项目规模
- 年门诊量（人次）
- 年住院量（人次）
- 医护人员数量
- 配置产品列表（如 CDSS、病历质控、VTE 等）

### 3. 单产品资源评估

为每个产品创建独立的硬件资源评估表，格式如下：

| 序号 | 服务器用途 | 服务器类型 | CPU 类型 | CPU(核) | 内存 (GB) | 操作系统版本 | 系统盘类型 | 系统盘（G） | 数据盘类型 | 数据盘（GB） | 台数 | 备注 |
|:----:|-----------|-----------|---------|:-------:|:---------:|-------------|-----------|:---------:|-----------|:-----------:|:----:|-----|

**回答末尾必须标注来源路径**：`kb/.../*.md`

### 4. 资源汇总与合并

根据以下汇总逻辑整合多产品资源：

#### 可合并的服务器类型

| 服务器类型 | 合并策略 | 最大数量 | 配置原则 |
|-----------|---------|---------|---------|
| 数据库服务器 | 不同产品的数据库服务器可合并（监管平台的数据库服务器不做合并） | 3 台 | **数量根据产品数量决定**，采用最高配置 |
| 数据对接平台/数据采集 | 可合并 | 2 台 | 采用最高配置 |
| MDM 服务器 | 可合并 | 2 台 | 采用最高配置 |
| 日志平台服务器 | 可合并 | 1-2 台 | 采用最高配置 |
| 前置机 (nginx) | 可合并 | 2 台 | 采用最高配置 |
| 中间件 (RocketMQ/Redis/Nacos) | 所有产品共享集群 | 6 台 | 采用最高配置 |
| 备份服务器 | 统一冷备 | 1 台 | 根据产品数量调整磁盘 |
| 聆枢平台服务器和AI能力平台服务器 | **必须合并**，合并后命名为**聆枢平台服务器** | 2 台 | 采用最高配置 |
| 运维机 | 根据产品数量决定 | <5 产品=1 台，5-10 产品=2 台，>10 产品=3 台 | - |

#### 大规模医院特殊规则
**当产品数 > 1时**，合并策略调整如下：
- **前置机**：从 1 台调整为 **2 台**
- **数据库服务器**：从 1 台调整为 **2 台**
**当产品数 > 2时**，合并策略调整如下：
- **中间件服务器**：调整为 **3 台**
**当年门诊量 > 300 万人次时**，合并策略调整如下：
- **数据对接平台**：从 1 台调整为 **2 台**
- **MDM 服务器**：从 1 台调整为 **2 台**
- **数据库服务器**：从 2 台调整为 **3 台**
- **中间件服务器**：调整为 **6 台**

#### 独立部署的服务器类型

- **应用服务器**：各产品业务应用建议独立部署

#### 高可用要求

如用户要求高可用：每个应用服务器从 1 台调整为 2 台

### 5. 输出格式

#### 业务规模分析

| 指标 | 数值 |
|------|------|
| 年门诊量 | XX 万人次 |
| 年住院量 | XX 万人次 |
| 医护人员 | XX 人 |
| 配置产品 | 产品 A、产品 B... |

#### 单产品硬件资源评估

为每个产品输出独立的评估表（见上方表格格式）

#### 汇总结果

输出整合后的服务器资源清单表格（格式同单产品评估表）

#### 资源统计

| 类别 | 数量 | CPU | 内存 | 存储 |
|------|------|------|------|------|
| 总计 | XX 台 | XX 核 | XXG | XX TB |

#### 整合前后对比（如适用）

| 指标 | 整合前 | 整合后 | 节省 |
|------|--------|--------|------|
| 虚拟机数量 | XX 台 | XX 台 | ↓ XX% |
| CPU 总量 | XX 核 | XX 核 | ↓ XX% |
| 内存总量 | XXG | XXG | ↓ XX% |

#### 建议和注意事项

根据具体情况给出建议，常见要点：

1. **高可用部署**：如需高可用，应用服务器需从 1 台调整为 2 台
2. **数据库隔离**：不同产品通过实例隔离，根据业务量调整配置
3. **中间件共享**：RocketMQ/Redis/Nacos 集群共享，最多 6 台
4. **存储规划**：备份服务器磁盘根据产品数量和数据量调整
5. **网络隔离**：建议将数据库、应用、前置机分置于不同网段
6. **扩展预留**：当前配置适用于标准业务量，如日均访问超阈值需重新评估

## 参考文档

如需详细的硬件资源测算模板，可参考：
- `references/hardware-template.md` - 硬件资源测算标准模板

## 示例

**用户输入：**
> 龙华医院，年门诊 200 万人次，年住院人次在 10 万次，医护人员 2000 人。配置产品 CDSS、病历质控和 VTE。请评估资源

**返回格式：**
1. 业务规模分析表
2. 单产品硬件资源评估（CDSS、病历质控、VTE 各一张表）
3. 汇总结果表
4. 资源统计表
5. 整合前后对比表
6. 建议和注意事项
7. 来源标注：`kb/xunfei/.../*.md`

FILE:_meta.json
{
  "ownerId": "kn734em93x2rcppfhv0j8f55bh82c6e1",
  "slug": "resource-master",
  "version": "1.0.5",
  "publishedAt": 1773977375901
}
FILE:.clawhub/origin.json
{
  "version": 1,
  "registry": "https://clawhub.ai",
  "slug": "resource-master",
  "installedVersion": "1.0.5",
  "installedAt": 1773988869550
}

FILE:references/hardware-template.md
# 硬件资源测算标准模板

## 标准表格格式

| 序号 | 服务器用途 | 服务器类型 | CPU 类型 | CPU(核) | 内存 (GB) | 操作系统版本 | 系统盘类型 | 系统盘（G） | 数据盘类型 | 数据盘（GB） | 台数 | 备注 |
|:----:|-----------|-----------|---------|:-------:|:---------:|-------------|-----------|:---------:|-----------|:-----------:|:----:|-----|
| 1 | 应用服务器 | 虚拟机 | X86 | 8 | 32 | 龙蜥 8.8 | 系统盘 | 100 | 数据盘 | 500 | 1 | 业务组件、RocketMQ |
| 2 | 数据库服务器 | 虚拟机 | X86 | 16 | 48 | 龙蜥 8.8 | 系统盘 | 100 | 数据盘 | 1024 | 1 | 业务主数据库、Redis |

## 常见服务器类型配置参考

### 应用服务器
- **CPU**: 8-32 核
- **内存**: 32-48GB
- **系统盘**: 100GB
- **数据盘**: 500GB
- **用途**: 业务组件、中间件

### 数据库服务器
- **CPU**: 8-32 核
- **内存**: 32-96GB
- **系统盘**: 100GB
- **数据盘**: 1024-2048GB（根据数据留存时间）
- **用途**: 主数据库、缓存

### 中间件服务器
- **CPU**: 8-32 核
- **内存**: 32GB
- **系统盘**: 100GB
- **数据盘**: 500GB
- **用途**: RocketMQ/Redis/Nacos

### 前置机
- **CPU**: 4 核
- **内存**: 8GB
- **系统盘**: 100GB
- **数据盘**: 200GB
- **用途**: nginx、数据对接

### 日志平台服务器
- **CPU**: 8 核
- **内存**: 16GB
- **系统盘**: 100GB
- **数据盘**: 1024GB
- **用途**: 日志收集与分析

### 备份服务器
- **CPU**: 8 核
- **内存**: 16GB
- **系统盘**: 100GB
- **数据盘**: 2048GB+（根据产品数量调整）
- **用途**: 统一冷备

### 运维机
- **CPU**: 4 核
- **内存**: 8GB
- **系统盘**: 100GB
- **数据盘**: 200GB
- **用途**: 运维管理

## 操作系统标准

- **操作系统**: 龙蜥 8.8
- **服务器类型**: 虚拟机
- **CPU 类型**: X86

## 配置调整原则

1. **业务量调整**:
   - 年门诊量 > 200 万人次：适当提升 CPU 和内存配置
   - 年住院量 > 10 万人次：适当提升数据库存储配置

2. **产品数量调整**:
   - 中间件服务器：最多 6 台，所有产品共享
   - 运维机：<5 产品=1 台，5-10 产品=2 台，>10 产品=3 台

3. **高可用要求**:
   - 应用服务器从 1 台调整为 2 台
   - 数据库服务器考虑主从架构

4. **存储规划**:
   - 数据盘大小根据数据留存年限调整
   - 备份服务器磁盘 = 产品数量 × 单产品数据量