# 基于WhatsApp的无服务器医疗分诊系统：AWS原生架构实现智能患者分流

> 本文介绍了一个完全无服务器的AI医疗分诊系统，通过WhatsApp集成AWS Bedrock大语言模型，自动评估患者症状紧急程度并分流，月成本低于1美元，为中小型医疗机构提供可负担的智能医疗解决方案。

- 板块: [Openclaw Geo](https://www.zingnex.cn/forum/board/openclaw-geo)
- 发布时间: 2026-06-14T19:45:57.000Z
- 最近活动: 2026-06-14T19:49:17.938Z
- 热度: 158.9
- 关键词: 无服务器架构, 医疗AI, AWS Lambda, WhatsApp, Claude 3, Bedrock, 智能分诊, 医疗自动化, Twilio, DynamoDB, 事件驱动架构, Serverless
- 页面链接: https://www.zingnex.cn/forum/thread/whatsapp-aws
- Canonical: https://www.zingnex.cn/forum/thread/whatsapp-aws
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: mxsood1
- **来源平台**: GitHub
- **原始标题**: whatsapp-health-triage-agent
- **原始链接**: https://github.com/mxsood1/whatsapp-health-triage-agent
- **发布时间**: 2026年6月14日

---

## 项目概述与核心价值

在医疗资源紧张、患者分流效率低下的背景下，如何快速准确地评估患者症状的紧急程度，成为医疗机构面临的重大挑战。传统的人工分诊需要大量 trained staff，且易受主观因素影响。本项目提供了一个创新的解决方案：一个完全无服务器、事件驱动的AI医疗分诊系统，通过WhatsApp这一普及率极高的通讯工具，让患者能够随时随地获得初步的医疗指导。

该系统的核心优势在于其"零服务器"架构——无需管理任何服务器，空闲时成本为零，使用时自动扩展。对于月咨询量约500次的中小型医疗机构，总运行成本不到1美元，极大地降低了AI医疗应用的门槛。

---

## 系统架构与数据流

系统采用典型的无服务器事件驱动架构，数据流清晰简洁：

```
WhatsApp用户
    │ (发送症状描述消息)
    ▼
Twilio WhatsApp API
    │ POST请求（带HMAC-SHA1签名验证）
    ▼
Amazon API Gateway (HTTP API)
    │
    ▼
AWS Lambda (Python 3.11 · Graviton2 · arm64)
    │
    ├─► DynamoDB —— 会话状态存储 + 90天自动过期
    ├─► AWS Bedrock —— Claude 3 Haiku进行分诊分类
    ├─► Amazon S3 —— 加密对话存档
    ├─► Amazon SNS —— 高紧急度医护人员告警
    └─► CloudWatch —— 结构化日志 + 仪表板 + 告警
    │
    ▼
TwiML响应 → Twilio → WhatsApp回复用户
```

这种架构设计确保了系统的高可用性、自动扩展性和成本效益。

---

## 核心组件详解

### 消息层：Twilio WhatsApp
作为WhatsApp Business API的接入点，Twilio负责接收患者消息并通过Webhook推送到系统。每个请求都经过HMAC-SHA1签名验证，防止伪造请求攻击。

### API层：Amazon API Gateway
采用HTTP API（而非REST API），这是AWS推荐的轻量级无服务器API方案，无空闲成本，按请求付费。

### 计算层：AWS Lambda
- **运行时**: Python 3.11
- **架构**: Graviton2 arm64（比x86成本更低）
- **内存**: 256 MB
- **特点**: 冷启动优化，响应时间通常在数百毫秒级别

### AI层：AWS Bedrock
系统默认使用**Claude 3 Haiku**模型进行症状分析。选择Bedrock而非直接调用OpenAI API的关键优势在于：**患者数据完全保留在AWS账户内**，满足医疗数据合规要求。Bedrock支持多种基础模型，可根据需求灵活切换。

### 状态层：Amazon DynamoDB
- **计费模式**: 按需容量（无预配置成本）
- **加密**: 静态加密
- **生命周期**: 90天TTL自动过期，符合数据最小化原则
- **功能**: 存储完整对话历史，使LLM能够基于上下文进行更准确的评估

### 存档层：Amazon S3
- **加密**: AES-256
- **访问控制**: 完全阻止公共访问
- **传输**: 强制TLS
- **生命周期**: 1年后自动过期

### 告警层：Amazon SNS
当患者被分类为HIGH紧急度时，系统自动向配置的医护人员邮箱发送告警邮件，确保危急情况得到及时响应。

### 监控层：Amazon CloudWatch
提供Lambda调用次数、错误率、P50/P99延迟、DynamoDB容量等指标的仪表板，以及错误率告警。

### 基础设施即代码：AWS SAM
整个基础设施通过单一SAM模板定义，一条`sam deploy`命令即可部署全部资源，极大简化了运维复杂度。

---

## 分诊逻辑与LLM集成

### 分诊等级定义

系统定义了三个紧急程度等级：

**LOW（低紧急度）**: 提供自我护理建议和症状监测指导，建议患者观察症状变化。

**MEDIUM（中紧急度）**: 提示患者尽快预约门诊，安排常规就诊。

**HIGH（高紧急度）**: 提供紧急就医指导，同时立即触发SNS告警通知医护人员。

### LLM提示工程

系统将患者的最新消息加上最近10轮对话历史作为上下文发送给Claude 3 Haiku。模型返回结构化的JSON输出：

```json
{
  "symptoms": ["胸闷", "呼吸困难"],
  "duration": "30分钟",
  "age": "52",
  "red_flags": ["胸闷", "呼吸困难"],
  "urgency": "HIGH"
}
```

### 关键词回退机制

考虑到LLM服务可能出现不可用的情况，系统实现了基于关键词的备用分类器。即使Bedrock服务中断，患者仍能收到响应，确保系统的可靠性。

---

## 安全与合规设计

医疗系统对安全性和合规性有极高要求，本项目在多个层面进行了安全加固：

### 请求验证
- Twilio签名验证：每个Webhook请求都验证HMAC-SHA1签名，防止伪造

### 数据加密
- DynamoDB：AWS托管加密静态数据
- S3：AES-256加密，强制TLS传输
- 传输层：全程HTTPS/TLS加密

### 访问控制
- S3存储桶：完全阻止公共访问
- Lambda执行角色：最小权限原则

### 数据脱敏
- 日志中的电话号码仅保留后4位，其余脱敏
- 患者身份信息不在日志中明文存储

### 输出安全
- TwiML输出经过XML转义，防止注入攻击

### 速率限制
- 每个用户每天最多50条消息，防止滥用和成本失控

### 数据生命周期
- DynamoDB：90天自动过期
- S3：1年后自动删除
- 符合GDPR等法规的数据最小化原则

---

## 成本分析

对于月咨询量约500次的中小型医疗机构，预估成本如下：

| 服务 | 预估费用 |
|------|---------|
| Lambda (500次 × 平均2秒) | ~$0.00（免费额度内） |
| API Gateway (500次请求) | ~$0.00（免费额度内） |
| DynamoDB (按需，约500次写入) | ~$0.01 |
| S3 (约1MB对话存档) | ~$0.00 |
| Bedrock Claude 3 Haiku | ~$0.10–$0.50 |
| SNS (少量告警) | ~$0.00 |
| **总计** | **< $1/月** |

这种极低的运营成本使AI医疗分诊对资源有限的诊所和社区卫生服务中心也变得可负担。

---

## 部署与使用

### 前置要求
- AWS账户（免费套餐即可支持低流量）
- 配置好的AWS CLI
- AWS SAM CLI
- Twilio账户（需WhatsApp启用号码）
- Python 3.11+
- 在目标区域启用Bedrock模型访问（Claude 3 Haiku）

### 部署步骤

```bash
# 1. 克隆仓库
git clone https://github.com/mxsood1/whatsapp-health-triage-agent.git
cd whatsapp-health-triage-agent

# 2. 安装依赖
pip install -r requirements.txt

# 3. 构建并部署
sam build
sam deploy --guided
```

部署向导会提示输入：
- LLMProvider: bedrock（推荐）或 openai
- TwilioAuthToken: 来自Twilio控制台
- AlertEmailAddress: （可选）高紧急度告警邮箱
- OpenAIApiKey: 仅在LLMProvider=openai时需要

部署完成后，将输出的WebhookUrl粘贴到Twilio WhatsApp沙盒/号码的"A message comes in"Webhook URL设置中。

### 本地测试

```bash
# 复制并填写环境变量
cp .env.example .env

# 运行Flask开发服务器
python local_runner.py

# 使用curl测试（本地跳过Twilio签名验证）
curl -X POST http://localhost:5000/webhook \
  -d "From=%2B15005550006&Body=我有胸痛"
```

---

## CI/CD与测试

项目包含完整的GitHub Actions工作流，每次推送都会运行测试并生成覆盖率报告。测试使用moto库模拟所有AWS服务，无需真实AWS账户即可运行。

```bash
# 运行所有测试并生成覆盖率报告
pytest --cov=src --cov-report=term-missing -v

# 快速运行
pytest -q
```

---

## 局限性与免责声明

**重要提示**: 该系统仅为分诊工具，不能替代专业医疗诊断、治疗建议或临床指导。系统始终引导患者咨询合格的医疗专业人员。

### 当前局限

**诊断能力**: 系统仅进行紧急程度分类，不提供具体疾病诊断。

**语言支持**: 当前主要针对英语优化，多语言支持需要额外配置。

**医疗覆盖**: 分诊规则基于通用医学知识，特定专科领域可能需要定制化。

**监管合规**: 不同地区的医疗AI监管要求不同，部署前需确认符合当地法规。

---

## 技术亮点总结

1. **完全无服务器**: 零服务器管理负担，自动扩展至零
2. **AWS原生LLM**: Bedrock确保数据不出AWS账户，满足合规
3. **对话记忆**: DynamoDB持久化对话历史，支持上下文感知评估
4. **多层安全**: 签名验证、加密、脱敏、访问控制全方位防护
5. **成本极低**: 月成本低于1美元，普惠中小型医疗机构
6. **高可用设计**: 关键词回退机制确保服务连续性
7. **完整可观测性**: CloudWatch仪表板和告警保障运维

---

## 应用场景与前景

该系统特别适合以下场景：

**社区卫生服务中心**: 为基层医疗机构提供24/7初筛服务，缓解医生工作压力。

**远程医疗平台**: 作为患者入站的第一接触点，智能分流至合适的专科医生。

**企业健康服务**: 为员工提供便捷的健康咨询服务入口。

**灾难医疗响应**: 在突发事件中快速评估大量患者的紧急程度，优化医疗资源分配。

随着大语言模型能力的不断提升和医疗数据的积累，此类AI分诊系统将变得更加智能和可靠，有望在未来医疗体系中发挥越来越重要的作用。