公共部门组织的邮箱常常不是“沟通工具”，而是事实上的业务入口：居民咨询、内部审批、供应商文件、紧急事件通报都会先进入共享邮箱。来源文章展示了一种用 Amazon Bedrock 驱动的生成式 AI 方案，把邮件自动分类、提取关键信息并按优先级排序，减少人工扫信箱的时间。
邮件管理最难的不是分类，而是判断下一步
传统规则引擎适合处理明确模式，例如主题包含“发票”就打上财务标签，发件人来自某个域名就归入内部邮件。但公共部门邮箱里的真实邮件更复杂：
- 同一类请求可能有很多写法，比如“路灯坏了”“街区照明故障”“夜间道路不亮”。
- 优先级不总在标题里，正文里可能藏着“今天下午前需要回复”“影响居民安全”等信号。
- 邮件经常混合多个意图，例如咨询政策的同时附带投诉材料。
Amazon Bedrock 的价值在于可以调用基础模型理解自然语言，把邮件转成结构化结果：类别、紧急程度、摘要、建议处理队列、是否需要人工复核。这里的重点不是让模型“替人拍板”，而是让模型先做一轮可审计的预处理。
一个可落地的处理链路
可以这样实践一个最小版本：
- 邮件进入共享邮箱或邮件系统。
- 后端服务读取新邮件的主题、正文、发件人、时间和附件元数据。
- 调用 Amazon Bedrock，让模型返回 JSON 结构。
- 根据 JSON 更新工单、邮件标签或队列优先级。
- 对高风险、不确定或涉及敏感事项的邮件交给人工确认。
在公共部门场景里，建议一开始就把“可解释字段”纳入输出，例如 reason 和 confidence。这样业务人员看到的不只是“高优先级”，还能看到模型为什么这么判断。
可以这样实践：用 Bedrock 给邮件打标签
下面示例使用 Python 和 AWS SDK 调用 Amazon Bedrock Runtime。运行前需要替换 AWS 区域、模型 ID，并确保当前环境已经配置好 AWS 凭证。示例中的模型 ID 仅作为可改造占位，请按你所在区域可用的 Bedrock 模型调整。
import json
import boto3
REGION = "us-east-1"
MODEL_ID = "anthropic.claude-3-haiku-20240307-v1:0"
bedrock = boto3.client("bedrock-runtime", region_name=REGION)
email = {
"from": "resident@example.gov",
"subject": "Street light outage near school entrance",
"body": "The lights near the north entrance of Lincoln School have been out for two nights. Parents are worried because children arrive before sunrise. Please handle this urgently.",
"received_at": "2026-07-08T08:15:00Z"
}
prompt = f"""
You classify public sector mailbox messages.
Return only valid JSON with these fields:
- category: one of [public_safety, infrastructure, finance, procurement, hr, general_inquiry, complaint, other]
- priority: one of [low, normal, high, urgent]
- summary: one sentence
- recommended_queue: short routing label
- confidence: number from 0 to 1
- reason: short explanation
Email:
From: {email['from']}
Subject: {email['subject']}
Received at: {email['received_at']}
Body: {email['body']}
"""
request_body = {
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 500,
"temperature": 0,
"messages": [
{
"role": "user",
"content": [{"type": "text", "text": prompt}]
}
]
}
response = bedrock.invoke_model(
modelId=MODEL_ID,
body=json.dumps(request_body)
)
payload = json.loads(response["body"].read())
text = payload["content"][0]["text"]
classification = json.loads(text)
print(json.dumps(classification, indent=2))
安装依赖并运行：
python -m venv .venv
source .venv/bin/activate
pip install boto3
export AWS_PROFILE=your-profile
python classify_email.py
你可以把输出接到工单系统或邮件标签系统。例如，当 priority 是 urgent 且 confidence >= 0.8 时自动进入“今日处理”队列；当 confidence < 0.6 时进入人工复核队列。
生产环境里要补上的护栏
邮件数据往往包含个人信息、案件材料、合同内容或安全事件细节，不能只看模型效果。落地时至少要考虑这些边界：
- 权限边界：只让处理服务读取必要邮箱和必要字段，不要把全域邮箱权限交给一个服务账号。
- 数据最小化：如果附件内容不影响分类，就先只传附件名、类型、大小等元数据。
- 结构化输出校验：模型返回的 JSON 必须经过 schema 校验，不能直接信任。
- 人工复核机制：紧急、安全、法律、采购等敏感类别应保留人工确认。
- 审计日志：记录输入摘要、模型版本、分类结果、置信度和后续动作，方便追溯。
一个简单的 JSON Schema 可以这样写：
{
"type": "object",
"required": ["category", "priority", "summary", "recommended_queue", "confidence", "reason"],
"properties": {
"category": {
"type": "string",
"enum": ["public_safety", "infrastructure", "finance", "procurement", "hr", "general_inquiry", "complaint", "other"]
},
"priority": {
"type": "string",
"enum": ["low", "normal", "high", "urgent"]
},
"summary": { "type": "string", "maxLength": 300 },
"recommended_queue": { "type": "string", "maxLength": 80 },
"confidence": { "type": "number", "minimum": 0, "maximum": 1 },
"reason": { "type": "string", "maxLength": 300 }
}
}
采用建议：先从低风险队列开始
不要一上来就让 AI 改变所有邮件流转规则。更稳妥的路径是选一个高量、低风险、分类标准相对清晰的共享邮箱，先做“建议模式”：模型只生成分类和优先级，人工仍然决定最终动作。等到准确率、误判类型和业务接受度稳定后，再逐步自动化标签、路由和工单创建。
判断是否可以扩大范围时，可以用这份检查清单：
- 是否有明确的类别和优先级定义？
- 是否记录了模型版本、提示词版本和分类结果？
- 低置信度邮件是否会自动进入人工复核？
- 是否知道错误分类会造成什么业务影响？
- 是否有回滚到人工规则或传统规则引擎的方案？
Amazon Bedrock 适合承担“读懂邮件并生成结构化建议”的部分，但组织仍然要设计权限、审计、复核和责任边界。把这些工程约束放在一开始，邮箱自动化才不会变成另一个难以解释的黑箱。