Agent+体检报告：从指标解读到复查提醒，哪些能力最有真实需求

体检报告 Agent 不应只做“上传报告后回答几句话”的一次性问答，更有价值的是把报告解析、指标解释、风险提示、复查提醒串成可追踪流程。本文从工程实现角度拆解一个简化链路，示例仅用于技术架构说明，不提供诊断、治疗、分诊或用药建议；所有阈值、风险分层和提醒规则都应由医疗专业人员与机构规范确认。

1. 先拆真实需求：Agent 到底要做什么

在体检报告场景里，用户上传的通常是 PDF、图片或拍照截图。开发者面对的问题不是“让大模型读一段文本”，而是如何稳定拿到结构化指标，并让系统知道下一步该做什么。

一个更贴近业务的 Agent 至少需要四类能力：

• 报告解析：从 OCR 文本中抽取项目名、结果值、单位、参考范围。
• 指标解释：把“偏高、偏低、临界”等状态转成用户能理解的说明。
• 规则匹配：根据可配置规则生成提示等级和复查建议。
• 计划跟踪：将复查时间、提醒渠道、用户确认状态写入任务系统。

这里的 Agent 更像“流程编排器”，LLM 只是其中一个组件。指标识别、规则判断、提醒任务都应尽量显式化，避免把所有逻辑藏进 Prompt。

2. 技术目标与边界

本文实现一个最小可运行方案：

• OCR 输入：假设已经得到报告文本，实际项目可接入 PaddleOCR、云 OCR 或院内 OCR 服务。
• 后端接口：FastAPI 提供报告提交接口。
• 规则引擎：用 YAML/JSON 配置示例规则。
• LLM API：负责生成自然语言解释，但不直接决定提醒等级。
• 复查计划：生成结构化任务，后续可接消息队列、短信或 App Push。

架构可以表示为：

注意：示例中的“异常”“关注”“复查”等均为产品流程标签，不代表医学结论。真实项目中，规则来源、文案审核、用户告知和责任边界都需要纳入合规流程。

3. 数据结构：先把体检指标标准化

体检报告解析的第一步不是调用大模型，而是定义稳定的数据结构。不同机构的报告格式差异很大，但后端最好收敛到统一 Schema。

frompydanticimportBaseModelfromtypingimportOptional,ListclassLabItem(BaseModel):name:strvalue:floatunit:Optional[str]=Noneref_low:Optional[float]=Noneref_high:Optional[float]=Nonestatus:Optional[str]=NoneclassFollowUpPlan(BaseModel):item_name:strlevel:strsuggested_days:intreason:strclassReportResult(BaseModel):items:List[LabItem]followups:List[FollowUpPlan]summary:str

这里不建议只保存 OCR 原文。后续要做趋势对比、提醒去重、人工复核、用户授权导出，都依赖结构化字段。

4. 指标抽取：OCR 后用规则兜底

生产环境中，OCR 文本常见问题包括换行错位、单位丢失、参考范围被拆开。可以先用正则处理高频格式，再把低置信度片段交给人工校验或 LLM 辅助抽取。

下面是一个简化抽取函数，适用于类似“项目 结果 单位 参考下限-参考上限”的文本行：

importrefromtypingimportListdefparse_lab_items(ocr_text:str)->List[LabItem]:items=[]pattern=re.compile(r"(?P<name>[\u4e00-\u9fa5A-Za-z0-9（）()]+)\s+"r"(?P<value>\d+\.?\d*)\s*"r"(?P<unit>[A-Za-z/%μmolL\.]*)\s+"r"(?P<low>\d+\.?\d*)\s*[-~]\s*(?P<high>\d+\.?\d*)")forlineinocr_text.splitlines():match=pattern.search(line.strip())ifnotmatch:continuevalue=float(match.group("value"))low=float(match.group("low"))high=float(match.group("high"))ifvalue<low:status="low"elifvalue>high:status="high"else:status="normal"items.append(LabItem(name=match.group("name"),value=value,unit=match.group("unit")orNone,ref_low=low,ref_high=high,status=status))returnitems

这段代码的目标是演示链路，不是覆盖所有报告格式。实际项目建议记录每个字段的来源位置、OCR 置信度和解析版本，便于问题追踪。

5. 规则引擎：让复查提醒可配置

体检报告 Agent 的关键需求不是“说得像医生”，而是“规则可解释、可审计、可调整”。例如某个指标偏离参考范围时，系统可以生成“建议关注并在指定时间内复查”的任务，但规则必须是示例化、可配置的。

RULES=[{"item":"示例指标A","when":"high","level":"attention","suggested_days":30,"reason":"示例规则：结果高于报告参考上限，建议按机构规则确认是否需要复查"},{"item":"示例指标B","when":"low","level":"attention","suggested_days":60,"reason":"示例规则：结果低于报告参考下限，需结合机构规范生成提醒"}]defmatch_followup_rules(items:List[LabItem])->List[FollowUpPlan]:plans=[]foriteminitems:forruleinRULES:ifitem.name==rule["item"]anditem.status==rule["when"]:plans.append(FollowUpPlan(item_name=item.name,level=rule["level"],suggested_days=rule["suggested_days"],reason=rule["reason"]))returnplans

如果规则变复杂，可以引入 durable-rules、json-rules-engine，或把规则放入数据库并增加版本号。对于医疗健康场景，建议保留“规则命中日志”，包括输入指标、命中规则、规则版本、生成时间。

6. LLM 放在哪里：生成解释，不替代规则

LLM 适合做自然语言整理，例如把多个指标状态组织成用户可读的摘要。但不建议让 LLM 直接决定复查周期或风险等级。更稳妥的方式是：规则引擎输出结构化结果，LLM 只基于这些结果生成说明，并明确提示用户以专业人员解读为准。

defbuild_prompt(items:List[LabItem],plans:List[FollowUpPlan])->str:item_lines=[f"-{i.name}:{i.value}{i.unitor''}, 状态={i.status}, 参考范围={i.ref_low}-{i.ref_high}"foriinitems]plan_lines=[f"-{p.item_name}: 等级={p.level}, 示例复查天数={p.suggested_days}, 原因={p.reason}"forpinplans]returnf""" 你是健康报告产品中的说明文本生成组件。 请基于结构化数据生成简洁说明，不提供诊断、治疗、分诊或用药建议。 所有复查建议都应表述为“示例提醒”或“需按机构规则确认”。 指标：{chr(10).join(item_lines)}规则命中的提醒：{chr(10).join(plan_lines)}"""

这类 Prompt 要求模型“不要越界”。同时，后端仍要做输出审核，比如过滤绝对化表达、治疗建议、药物建议等。

7. FastAPI 串起完整链路

下面用一个接口演示从 OCR 文本到解释摘要与复查计划的流程。LLM 调用位置用函数占位，接入时可替换为具体 API。

fromfastapiimportFastAPIfrompydanticimportBaseModel app=FastAPI()classReportRequest(BaseModel):user_id:strocr_text:strdefcall_llm(prompt:str)->str:# 生产环境替换为真实 LLM API，并加入超时、重试、审计日志return"这是基于示例规则生成的报告说明。请结合机构规范和专业人员意见确认后续安排。"@app.post("/reports/analyze",response_model=ReportResult)defanalyze_report(req:ReportRequest):items=parse_lab_items(req.ocr_text)followups=match_followup_rules(items)prompt=build_prompt(items,followups)summary=call_llm(prompt)returnReportResult(items=items,followups=followups,summary=summary)

测试时可以先用手工构造 OCR 文本跑通主流程，再逐步替换真实 OCR、消息队列和提醒服务。建议为每次分析生成report_id，避免用户重复上传导致提醒任务重复创建。

8. 工程踩坑与扩展点

第一个坑是单位和参考范围不一致。不同机构可能使用不同单位，规则匹配前应做单位标准化，不能简单按字符串比较。

第二个坑是报告项目命名不统一。同一个项目可能有全称、简称、括号说明，建议维护项目别名表，并对命中的别名记录原始名称。

第三个坑是提醒任务不可追踪。复查提醒至少需要状态机，例如created、scheduled、sent、confirmed、cancelled，否则用户反馈和运营复盘都很困难。

第四个坑是 LLM 输出不可控。可以把 LLM 生成内容分为“用户说明”和“内部备注”，用户侧只展示经过规则约束和安全审核的文本。

9. 结论

体检报告 Agent 的真实需求不只是“解释指标”，而是把报告解析、规则匹配、解释生成和复查提醒做成闭环。工程上建议用结构化数据和可配置规则承担核心决策逻辑，让 LLM 负责表达和总结，并在全链路保留审计记录。

下一步可以继续补齐三块能力：接入真实 OCR、建设指标别名与单位换算表、把复查计划接入任务队列和用户通知系统。只要边界清晰、规则可追踪，这类 Agent 才更容易从 Demo 走向可维护的医疗健康应用。

本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。