@clawhub-hellohushuai-16863937a5
根据产品名称查询对应标准硬件资源评估要点,智能对比用户提供内容是否完整并返回缺失项或确认完整。
---
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()
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,...
---
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
}大模型服务器资源评估。用于医疗行业大模型应用场景的算力资源需求评估和测算,根据门诊/住院诊疗量和大模型应用场景数推导GPU算力需求。使用场景:用户询问大模型算力评估、AI服务器资源配置、GPU算力需求测算等。
---
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. **存储规划**:
- 数据盘大小根据数据留存年限调整
- 备份服务器磁盘 = 产品数量 × 单产品数据量