tmp5joqbrci

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

体检报告类 Agent 的价值，不在于把报告内容“改写得更像人话”，而在于把 OCR、指标结构化、规则匹配、解释生成和复查提醒串成可追踪流程。本文只讨论技术架构和工程流程示例，不提供诊断、治疗、分诊或用药建议；文中阈值、风险分层和提醒规则均为示例，真实项目必须由医疗专业人员和机构规范确认。

业务问题：体检报告 Agent 到底要解决什么

开发体检报告解读功能时，常见需求会被压缩成一句话：用户上传报告，AI 给出解释。但落到工程实现，会拆成几类更具体的问题。

第一，报告来源不统一。用户可能上传图片、扫描 PDF 或手机拍照截图，页面布局、单位、参考范围写法都不稳定。系统不能直接把整页文本扔给 LLM，否则容易出现指标遗漏、单位误读和上下文混淆。

第二，用户关心的不只是“这项指标是什么意思”。更真实的产品路径是：哪些指标需要关注、与历史记录相比有没有变化、是否需要复查、什么时候提醒、提醒文案如何避免制造恐慌。

第三，医疗健康场景需要可解释和可审计。Agent 每一步最好能留下输入、输出和规则命中记录，便于人工复核、问题定位和后续迭代。

因此，一个实用的体检报告 Agent，至少要具备四个能力：结构化抽取、指标标准化、示例规则匹配、复查计划生成。LLM 更适合放在“解释生成”和“交互问答”层，而不是替代全部判断逻辑。

目标架构：把一次问答改成可编排流程

可以把链路设计为 5 个节点：

每个节点的输入输出都应结构化。比如 OCR 输出原始文本，解析层输出ReportItem，规则层输出RuleHit，提醒层输出FollowUpPlan。这样做的关键不是“架构漂亮”，而是便于测试：同一份结构化报告，可以反复验证规则、提示词和提醒策略。

推荐的后端技术栈可以比较朴素：

• OCR：接入已有 OCR 服务或自建模型，本文用接口占位
• API：FastAPI 负责上传和任务编排
• 规则引擎：先用 Python 配置化规则，后续再迁移到数据库或 Drools 类系统
• LLM API：只生成解释性文本，不直接输出医疗决策
• 存储：保存报告结构化结果、规则命中、提醒任务和审计日志

数据建模：先定义指标对象，再谈 Agent

体检报告解析最容易踩坑的地方，是没有统一指标模型。不同机构可能把“空腹血糖”写成不同名称，单位也可能不同。建议先定义内部标准字段，再做别名映射。

下面是一个简化版 FastAPI 示例，演示从结构化指标到规则命中和复查计划生成。示例规则仅用于工程说明，不代表医学标准。

fromtypingimportList,Optionalfromdatetimeimportdate,timedeltafromfastapiimportFastAPIfrompydanticimportBaseModel app=FastAPI(title="Health Report Agent Demo")classReportItem(BaseModel):name:strstd_name:strvalue:floatunit:strref_range:Optional[str]=NoneclassRuleHit(BaseModel):std_name:strlevel:strreason:straction_hint:strclassFollowUpPlan(BaseModel):std_name:strremind_date:date message:strclassReportRequest(BaseModel):user_id:stritems:List[ReportItem]RULES=[{"std_name":"fasting_glucose","min":3.9,"max":6.1,"level":"attention","followup_days":30,"explain":"示例规则：该指标超出配置参考范围，建议按机构规范确认是否需要复查。"},{"std_name":"total_cholesterol","min":0,"max":5.2,"level":"attention","followup_days":60,"explain":"示例规则：该指标高于配置上限，可提示用户关注生活方式记录并咨询专业人员。"}]defmatch_rules(items:List[ReportItem])->List[RuleHit]:hits=[]foriteminitems:forruleinRULES:ifitem.std_name!=rule["std_name"]:continueifitem.value<rule["min"]oritem.value>rule["max"]:hits.append(RuleHit(std_name=item.std_name,level=rule["level"],reason=rule["explain"],action_hint="该提示不构成诊断建议，真实项目需按机构规则确认。"))returnhitsdefbuild_followups(hits:List[RuleHit])->List[FollowUpPlan]:plans=[]forhitinhits:rule=next(rforrinRULESifr["std_name"]==hit.std_name)plans.append(FollowUpPlan(std_name=hit.std_name,remind_date=date.today()+timedelta(days=rule["followup_days"]),message=f"{hit.std_name}存在关注项，可在配置周期后提醒用户复查或咨询专业人员。"))returnplans@app.post("/report/analyze")defanalyze_report(req:ReportRequest):hits=match_rules(req.items)plans=build_followups(hits)return{"user_id":req.user_id,"rule_hits":hits,"follow_up_plans":plans,"disclaimer":"本接口仅为技术流程示例，不提供诊断、治疗、分诊或用药建议。"}

请求示例：

curl-XPOST http://127.0.0.1:8000/report/analyze\-H"Content-Type: application/json"\-d'{ "user_id": "u_1001", "items": [ { "name": "空腹血糖", "std_name": "fasting_glucose", "value": 6.8, "unit": "mmol/L", "ref_range": "3.9-6.1" } ] }'

LLM 放在哪里：解释文本可以生成，规则不宜黑盒化

在这个场景里，LLM 适合承担三类任务。

第一是把结构化结果转成用户能理解的解释。例如“该指标是什么”“为什么需要关注”“下次复查前可以记录哪些信息”。提示词中应明确禁止输出诊断结论、治疗方案和用药建议。

第二是多轮追问。用户可能问“为什么我去年正常今年异常”，这时应从历史结构化数据里检索变化趋势，再让 LLM 组织语言，而不是让模型凭空判断。

第三是报告摘要。摘要应基于规则命中结果生成，避免模型自行选择重点。工程上可以把rule_hits作为上下文输入，并要求模型逐条引用。

一个简化提示词可以这样设计：

你是体检报告解释助手，只能基于输入的结构化指标和规则命中结果进行说明。 不得提供诊断、治疗、分诊或用药建议。 所有复查周期均来自系统配置的示例规则，需提示用户以医疗专业人员或机构规范为准。 输入： {rule_hits} {follow_up_plans} 输出： 1. 需要关注的指标 2. 通俗解释 3. 复查提醒说明 4. 免责声明

复查提醒：从文案生成到任务系统

复查提醒不是简单生成一句话，还需要任务系统支持。建议至少保存以下字段：

• user_id：用户标识
• report_id：报告标识
• std_name：标准指标名
• remind_date：提醒日期
• status：待发送、已发送、已取消
• rule_version：规则版本
• created_by：系统规则或人工确认

这里的rule_version很重要。规则一旦调整，历史提醒不能静默改变，否则后续审计会很困难。若项目有人工复核环节，可以把高关注级别的提醒先进入待确认队列，再由具备资质的人员确认是否触发。

工程踩坑：体检报告 Agent 最容易失真在哪里

OCR 错误是第一类问题。小数点、单位、箭头符号、上下限范围都容易识别错。建议在解析后加入数值合法性校验，例如同一指标单位不匹配时进入人工复核队列。

别名映射是第二类问题。同一指标在不同报告中名称差异较大，维护alias -> std_name词典比直接依赖 LLM 更稳定。LLM 可以辅助召回候选名称，但最终映射应可审计。

规则版本是第三类问题。不要把规则散落在提示词里，最好放在配置文件、数据库或规则服务中，并记录命中原因。提示词只负责表达，不负责生成规则。

提醒频率是第四类问题。健康提醒如果过密，会造成打扰；如果过松，又失去产品价值。建议把提醒策略做成用户可配置，并支持取消、延后和关闭。

结论：真实需求在“持续管理链路”，不是单次解读

Agent+体检报告的工程重点，是把报告解析、指标标准化、示例规则匹配、解释生成和复查提醒做成稳定链路。LLM 能提升可读性和交互体验，但规则、审计、版本和提醒任务仍然需要传统工程能力托底。

如果要继续扩展，可以优先补三件事：历史报告趋势对比、规则配置后台、人工复核工作台。上线前务必让医疗专业人员确认规则与文案边界，并在产品中清晰声明：系统仅提供健康信息管理与技术辅助，不替代专业医疗判断。

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