1. 项目缘起当医疗AI需要“离线”思考最近在折腾一个挺有意思的项目核心目标听起来有点绕但直白点说就是想做一个能在本地医院、诊所甚至个人电脑上跑起来的“医疗智能体”。这个智能体不是那种需要联网调用大模型的聊天机器人而是能真正处理结构化医疗数据、完成一些临床辅助任务的“本地专家”。为什么会有这个需求我接触过不少医疗信息化团队他们普遍面临一个困境一方面AI辅助诊断、临床决策支持CDS的需求很迫切另一方面医疗数据的隐私和安全红线又碰不得。把患者敏感的电子健康记录EHR数据上传到云端去处理这在绝大多数合规场景下都是天方夜谭。所以“本地化部署”就成了一个硬性前提。但问题随之而来本地部署的模型尤其是基于大语言模型LLM的智能体在处理像FHIRFast Healthcare Interoperability Resources这种高度结构化、逻辑关系复杂的医疗数据时常常表现得像个“知识渊博的健忘症患者”——它知道很多医学知识但面对一份具体的患者FHIR数据包却经常搞不清“主诉”、“现病史”、“实验室检查结果”之间的时序和逻辑关联做出一些前后矛盾甚至危险的推理。我这次项目的标题Empowering Locally Deployable Medical Agent via State Enhanced Logical Skills for FHIR-based Clinical Tasks就精准地戳中了这个痛点。它的核心是为本地可部署的医疗智能体赋予一种“状态增强的逻辑技能”让它能更好地理解和处理基于FHIR的临床任务。这里的“状态”State和“逻辑技能”Logical Skills是关键。你可以把“状态”理解为智能体对当前任务、对话历史、以及已处理数据的一个动态记忆和上下文理解而“逻辑技能”则是它基于这个状态进行推理、判断、执行具体操作比如从FHIR数据中提取特定信息、判断是否符合某个临床路径的能力。这个项目不是要训练一个全新的医学大模型而是要在现有开源或轻量化模型的基础上构建一套增强其“逻辑大脑”的框架和方法论。2. 拆解核心挑战FHIR数据与LLM的“水土不服”要理解为什么需要“状态增强的逻辑技能”我们得先看看让医疗AI在本地“跑起来”到底难在哪里。最大的障碍来自于数据格式和任务复杂性。2.1 FHIR医疗数据的“乐高积木”FHIR不是一种简单的数据表格它是一套由HL7国际组织制定的医疗信息交换标准。你可以把它想象成一套高度规范化的“乐高积木”系统。每一种医疗信息比如一个病人Patient、一次就诊Encounter、一项观察Observation如血压值、一条诊断Condition、一份用药请求MedicationRequest都被定义成一种标准的“资源”Resource。每个资源有固定的结构就像乐高积木的凸点和凹槽通过特定的字段如subject引用病人code定义观察类型相互链接。例如一份简单的患者数据可能包含一个Patient资源包含ID、姓名、出生日期。一个Encounter资源记录本次就诊其subject字段指向那个Patient。几个Observation资源记录血压、血糖它们的subject指向Patientencounter指向本次Encountercode字段用LOINC或SNOMED CT标准码标明是“血压”还是“血糖”。一个Condition资源记录诊断“高血压”其subject指向Patientevidence字段可能引用那几个血压Observation作为依据。这种结构化的好处是机器可读、可交换。但对LLM来说它是一堆嵌套的JSON对象关系隐藏在字段引用中缺乏自然语言描述中那种直接的因果和时间线索。2.2 LLM在本地处理FHIR的典型困境当我们把一个未经增强的LLM比如一个7B或13B参数量的开源模型部署在本地并让它处理FHIR数据时通常会遇到以下几类问题上下文丢失与幻觉LLM的注意力机制在处理长序列一份完整的FHIR Bundle可能包含数十个资源时对于早期出现的信息记忆会衰减。它可能会记得病人有“高血压”诊断但忘了这个诊断所依据的血压测量值具体是多少、是什么时候测的。更糟糕的是它可能基于不完整的记忆“幻觉”出不存在的数据或关系。逻辑推理链条断裂临床任务往往是多步骤的。例如“评估该糖尿病患者本次就诊的血糖控制情况并给出用药调整建议”。这需要a) 识别患者所有相关的血糖观测值包括空腹、餐后、糖化血红蛋白b) 按时间排序评估趋势c) 结合当前的用药方案MedicationRequestd) 根据临床指南进行逻辑推理。原生LLM容易在步骤间丢失状态无法形成连贯的推理链。无法执行精确操作任务可能要求“提取最近一次肝功能检查中ALT和AST的值”。这需要智能体准确理解“最近一次”、“肝功能检查”、“ALT”、“AST”这些概念在FHIR资源中的对应关系Observation.code,Observation.effectiveDateTime并执行类似数据库查询的精确操作。纯文本生成的LLM不擅长这种确定性的信息检索。资源与计算限制本地部署的模型规模有限无法承载过于复杂的思维链CoT。我们需要设计更高效的状态管理和逻辑触发机制用有限的“算力”做更精准的“思考”。这些困境的根源在于通用的LLM是一个强大的“模式匹配与文本生成器”但不是一个内建了持久化工作记忆和确定性逻辑操作能力的“智能体”。我们的项目就是要为它补上这两块短板。3. 架构核心“状态增强”与“逻辑技能”如何实现“状态增强的逻辑技能”不是一个模糊的概念它需要一套可工程化的架构。在我的实现中它主要包含三个核心组件状态管理模块、技能工具箱和决策调度器。整个智能体的工作流程类似于一个拥有短期记忆和专用工具包的医生助理。3.1 状态管理模块智能体的“工作记忆白板”这是实现“状态增强”的关键。我们不能让LLM自己用隐藏层去记忆一切而是需要为它提供一个外部的、结构化的记忆体。我设计的状态State通常是一个动态更新的JSON对象包含以下层次{ “session_id”: “任务会话标识” “current_goal”: “当前要完成的顶级任务如‘评估糖尿病控制’” “processed_fhir_resources”: { “Patient”: [patient_resource_1], “Observation”: [obs_resource_1, obs_resource_2, ...], “Condition”: [...], // ... 按资源类型分类缓存已提取和解析的资源 }, “extracted_facts”: [ {“fact”: “患者张三男58岁” “source”: “Patient/123”, “confidence”: 1.0}, {“fact”: “2023-10-26 空腹血糖 7.8 mmol/L” “source”: “Observation/abc”, “confidence”: 1.0}, {“fact”: “诊断2型糖尿病2022年确诊” “source”: “Condition/def”, “confidence”: 1.0} // 从FHIR资源中提炼出的关键事实断言 ], “inference_history”: [ {“step”: 1, “action”: “提取所有血糖相关Observation” “result”: “找到3条记录” “state_snapshot”: “...”}, {“step”: 2, “action”: “按时间排序” “result”: “最近一次为今日空腹血糖7.8” “state_snapshot”: “...”} // 记录推理步骤和中间结果用于回溯和解释 ], “dialogue_context”: [] // 如果涉及多轮对话记录对话历史 }这个状态对象在任务开始时初始化随着智能体每一步的操作而更新。LLM在每一步决策时都会接收到这个完整的或部分摘要后的状态作为上下文。这就相当于给了LLM一个“工作记忆白板”它可以把重要的中间结果“写”在上面避免遗忘。注意状态的设计需要权衡。存储过多细节会挤占宝贵的上下文窗口存储过少又会导致记忆丢失。我的经验是extracted_facts提取的事实和inference_history推理历史是最关键的部分。前者用自然语言浓缩了原始数据后者保证了推理过程的透明和可回溯。3.2 技能工具箱封装好的“逻辑技能”“逻辑技能”在这里被具体化为一系列可调用、可组合的函数或工具。每个技能都对应一个明确的、可重复的临床数据处理或推理子任务。它们不是由LLM生成文本而是执行确定性的操作。我的技能工具箱通常包括FHIR查询技能给定资源类型和搜索参数如code‘血糖’ patient‘123’ date‘最近一年’从提供的FHIR Bundle或本地数据库中检索出匹配的资源列表。这个技能封装了FHIR REST API或本地JSON查询的逻辑。事实提取技能输入一个FHIR资源如一个Observation输出结构化的自然语言描述如“2023-10-26 空腹血糖 7.8 mmol/L”。这通常可以用模板或轻量级规则实现不一定需要LLM。时序排序技能给出一组带有时间戳的资源如多个Observation按时间先后排序。临床逻辑判断技能这是一类更复杂的技能。例如“判断血糖控制水平”技能输入一组按时间排序的血糖值根据指南如ADA标准判断是“控制良好”、“控制一般”还是“控制不佳”。这个技能内部可能封装了一个简单的规则引擎或一个小型决策树。报告生成技能根据当前状态中的extracted_facts和inference_history生成一段结构化的临床摘要或建议。每个技能都有明确定义的输入通常来自当前状态、输出会更新状态和描述用自然语言告诉LLM这个技能是干什么的。LLM的角色从“什么都自己干”转变为“根据当前状态和任务决定调用哪个技能并生成正确的调用参数”。3.3 决策调度器LLM作为“大脑”与“调度员”这是连接LLM、状态和技能的枢纽。其工作流程是一个循环感知决策调度器将当前的任务目标、状态摘要、可用的技能列表及其描述组合成一个提示词Prompt提交给本地部署的LLM。规划与决策LLM分析提示决定下一步该做什么。它可能输出两种结果调用技能{action: call_skill, skill_name: extract_blood_glucose_observations, parameters: {patient_id: 123, lookback_period: P1Y}}更新任务/结束{action: update_goal, new_goal: 分析血糖趋势}或{action: final_answer, answer: 患者血糖控制不佳建议...}执行调度器解析LLM的输出。如果是调用技能则从工具箱中找到对应技能传入参数执行。技能执行后会返回结果并自动更新状态管理模块例如将新提取的事实加入extracted_facts将本次操作记录到inference_history。循环更新后的状态连同原始任务再次形成提示词交给LLM进行下一轮决策。直到LLM决定输出最终答案或任务无法继续。这个架构的精妙之处在于它将LLM的强项理解复杂意图、进行高层规划与确定性程序的强项精确查询、逻辑计算、状态持久化结合了起来。LLM专注于“该做什么”而具体的“怎么做”交给了可靠的技能去执行。4. 实战演练构建一个糖尿病管理智能体理论说再多不如看实战。假设我们要构建一个本地部署的智能体用于处理糖尿病患者随访数据的FHIR Bundle并完成“评估本次血糖控制情况”的任务。4.1 环境准备与模型选型首先我们需要一个可以在本地运行的轻量级LLM。考虑到性能和精度平衡我选择了Qwen2.5-7B-Instruct的4位量化版本GGUF格式。它在7B这个尺寸上展现了不错的指令遵循和推理能力并且通过llama.cpp或Ollama等工具可以轻松在消费级GPU甚至高性能CPU上运行。# 示例使用Ollama在本地运行假设已有对应模型 ollama run qwen2.5:7b # 或者使用 llama-cpp-python 库在代码中集成 from llama_cpp import Llama llm Llama(model_path./qwen2.5-7b-instruct-q4_0.gguf, n_ctx4096, verboseFalse)技能工具箱的实现我使用Python的fhir.resources库来解析和操作FHIR数据并用简单的函数来封装各个技能。# 示例一个简单的FHIR查询技能 from fhir.resources.observation import Observation from datetime import datetime, timedelta import json def skill_query_observations(fhir_bundle, resource_type, patient_id, code_system, code_value, lookback_daysNone): 从FHIR Bundle中查询特定患者的观察项。 observations [] for entry in fhir_bundle.entry: if entry.resource.resource_type resource_type: obs entry.resource # 检查患者匹配 if obs.subject.reference ! fPatient/{patient_id}: continue # 检查编码匹配 (简化示例实际需处理CodeableConcept) if hasattr(obs, code) and obs.code.coding: for coding in obs.code.coding: if coding.system code_system and coding.code code_value: # 检查时间范围 if lookback_days: obs_date datetime.fromisoformat(obs.effectiveDateTime.replace(Z, 00:00)) if obs_date datetime.now() - timedelta(dayslookback_days): continue observations.append(obs) return observations4.2 任务执行全流程拆解现在我们启动智能体输入任务“评估患者ID-123的近期血糖控制情况”。假设我们有一个包含该患者近一年数据的FHIR Bundle。第一轮循环状态初始化current_goal “评估患者ID-123的近期血糖控制情况”其他为空。调度器提示LLM提示词包含目标、空状态、技能列表如“query_observations: 根据患者ID和检验代码查询观察项”、“extract_facts: 从观察项中提取关键事实”、“assess_control: 根据血糖值评估控制水平”。LLM决策LLM分析后决定第一步需要获取血糖数据。它输出{action: call_skill, skill_name: query_observations, parameters: {patient_id: 123, code_system: http://loinc.org, code_value: 2339-0, lookback_days: 90}}2339-0是LOINC中“葡萄糖[质量/体积] 在血清或血浆中”的代码代表血糖执行与状态更新调度器调用skill_query_observations从Bundle中找出近90天所有血糖Observation。结果比如3条记录被添加到processed_fhir_resources[‘Observation’]中。同时在inference_history中记录“步骤1查询到患者123近90天血糖观测值3条”。第二轮循环调度器提示LLM这次提示词包含了更新后的状态特别是inference_history和processed_fhir_resources摘要。LLM决策LLM看到已有数据决定下一步是提炼关键信息。它输出{action: call_skill, skill_name: extract_facts, parameters: {resource_type: Observation, keys: [effectiveDateTime, valueQuantity]}}执行与状态更新extract_facts技能遍历那3条Observation生成如下的自然语言事实存入extracted_facts1. 2023-10-01 空腹血糖 6.5 mmol/L 2. 2023-10-15 餐后2h血糖 10.2 mmol/L 3. 2023-10-26 空腹血糖 7.8 mmol/L历史记录更新。第三轮循环LLM决策LLM看到具体数值决定进行临床评估。它输出{action: call_skill, skill_name: assess_blood_glucose_control, parameters: {glucose_facts: [/* 上面三条事实 */]}}执行与状态更新assess_blood_glucose_control技能内部根据预设规则例如空腹血糖7.0或餐后10.0即为控制不佳进行计算。它返回结果“血糖控制不佳近3次测量中有2次超标”。这个结果作为新的事实加入extracted_facts。第四轮循环LLM决策LLM看到评估结果已完成当前目标已达成决定生成最终答案。它输出{action: final_answer, answer: 根据患者ID-123近90天的血糖记录2023-10-01空腹6.5 mmol/L 2023-10-15餐后10.2 mmol/L 2023-10-26空腹7.8 mmol/L评估其血糖控制不佳。建议加强生活方式干预或复诊调整治疗方案。}任务结束调度器输出最终答案流程终止。在整个过程中LLM始终在“状态”的引导下进行决策每一步操作都通过“技能”可靠地执行并将结果固化到“状态”中。这使得它能够完成一个需要多步记忆和逻辑判断的复杂任务。4.3 关键配置与调优心得提示词工程是灵魂给LLM的提示词必须清晰定义角色、任务格式、可用技能和状态结构。我常用的模板是你是一个医疗AI助手通过调用工具来处理FHIR数据。你的目标{current_goal}。 当前已知状态{state_summary}。 你可以使用以下工具 - 工具A: 描述。输入格式{...}。输出{...}。 - 工具B: ... 请根据当前目标和状态决定下一步行动。你必须输出一个严格的JSON对象只包含action和相应的参数如skill_name, parameters。如果任务完成输出final_answer。 可能的行动call_skill, update_goal, final_answer。需要反复调试确保LLM能稳定输出可解析的JSON。状态摘要的艺术不能每次都把完整的、庞大的状态JSON塞给LLM。需要设计一个“摘要函数”从完整状态中提取最关键的信息给LLM做决策比如只显示最近几步的inference_history和最重要的几条extracted_facts。这能有效节省上下文长度。技能的原子性与可靠性每个技能应该只做一件事并做好。技能内部的逻辑要尽可能确定和健壮避免把模糊推理丢给技能本身。如果技能执行失败如未找到数据必须返回明确的错误信息并更新状态让LLM能据此调整策略例如放宽查询条件。错误处理与回退机制LLM可能会输出无法解析的JSON或调用不存在的技能。调度器必须有健壮的错误捕获和重试机制。例如当解析失败时可以将错误信息连同原始提示再次发给LLM要求其纠正。通常设置最多3次重试。5. 效能评估与未来演进方向部署这样一个系统后如何评估其好坏单纯的“答案正确率”不够因为临床任务非常复杂。我主要从三个维度评估任务完成度对于给定的FHIR临床任务如信息提取、简单判断智能体能否在有限的循环步骤内输出一个明确的、与任务相关的答案它是否会陷入死循环或输出无关内容推理可解释性inference_history是否清晰记录了每一步的决策和结果当输出一个结论时我们能否根据状态回溯看到它是基于哪些数据、通过了哪些步骤得出的这对于医疗场景的信任至关重要。资源效率完成一个典型任务平均需要调用多少次LLM即循环次数每次LLM调用的响应时间如何整体任务耗时是否在可接受范围内如数秒内从我目前的实验来看通过“状态增强的逻辑技能”架构一个7B级别的本地模型在多项结构化临床任务如用药清单生成、异常指标筛查、随访报告摘要上的完成度和可靠性显著高于直接使用相同模型进行端到端的问答。它减少了幻觉提高了处理复杂逻辑任务的能力。当然这只是一个起点。这个框架还有很大的演进空间更复杂的技能链当前技能是平铺的。未来可以引入“子任务”技能允许技能调用其他技能形成更复杂的层次化任务分解。状态的自学习与优化目前状态结构是预设的。能否让智能体在运行中自主决定哪些信息值得存入长期状态extracted_facts这需要引入轻量级的强化学习或启发式规则。与本地知识库结合除了处理输入的FHIR Bundle智能体能否在状态中关联查询本地的临床指南知识库如以向量数据库形式存储使推理更有依据多模态扩展FHIR标准也支持包含医学影像的引用。未来可以集成视觉技能让智能体能处理影像报告甚至分析影像本身需要专门的视觉模型。这个项目的核心价值在于它提供了一种务实的技术路径。在完全依赖一个“全能”且合规的医疗大模型还不现实的今天通过将问题分解用“状态”管理记忆用“技能”封装确定性逻辑我们能让一个中等规模、可本地部署的模型在特定领域如基于FHIR的临床任务中表现出接近甚至超越其本身能力的、可靠且可解释的智能行为。这为在严格隐私要求下的医疗场景应用AI打开了一扇切实可行的窗。 本地化医疗AI智能体：基于状态增强与逻辑技能处理FHIR临床数据
1. 项目缘起当医疗AI需要“离线”思考最近在折腾一个挺有意思的项目核心目标听起来有点绕但直白点说就是想做一个能在本地医院、诊所甚至个人电脑上跑起来的“医疗智能体”。这个智能体不是那种需要联网调用大模型的聊天机器人而是能真正处理结构化医疗数据、完成一些临床辅助任务的“本地专家”。为什么会有这个需求我接触过不少医疗信息化团队他们普遍面临一个困境一方面AI辅助诊断、临床决策支持CDS的需求很迫切另一方面医疗数据的隐私和安全红线又碰不得。把患者敏感的电子健康记录EHR数据上传到云端去处理这在绝大多数合规场景下都是天方夜谭。所以“本地化部署”就成了一个硬性前提。但问题随之而来本地部署的模型尤其是基于大语言模型LLM的智能体在处理像FHIRFast Healthcare Interoperability Resources这种高度结构化、逻辑关系复杂的医疗数据时常常表现得像个“知识渊博的健忘症患者”——它知道很多医学知识但面对一份具体的患者FHIR数据包却经常搞不清“主诉”、“现病史”、“实验室检查结果”之间的时序和逻辑关联做出一些前后矛盾甚至危险的推理。我这次项目的标题Empowering Locally Deployable Medical Agent via State Enhanced Logical Skills for FHIR-based Clinical Tasks就精准地戳中了这个痛点。它的核心是为本地可部署的医疗智能体赋予一种“状态增强的逻辑技能”让它能更好地理解和处理基于FHIR的临床任务。这里的“状态”State和“逻辑技能”Logical Skills是关键。你可以把“状态”理解为智能体对当前任务、对话历史、以及已处理数据的一个动态记忆和上下文理解而“逻辑技能”则是它基于这个状态进行推理、判断、执行具体操作比如从FHIR数据中提取特定信息、判断是否符合某个临床路径的能力。这个项目不是要训练一个全新的医学大模型而是要在现有开源或轻量化模型的基础上构建一套增强其“逻辑大脑”的框架和方法论。2. 拆解核心挑战FHIR数据与LLM的“水土不服”要理解为什么需要“状态增强的逻辑技能”我们得先看看让医疗AI在本地“跑起来”到底难在哪里。最大的障碍来自于数据格式和任务复杂性。2.1 FHIR医疗数据的“乐高积木”FHIR不是一种简单的数据表格它是一套由HL7国际组织制定的医疗信息交换标准。你可以把它想象成一套高度规范化的“乐高积木”系统。每一种医疗信息比如一个病人Patient、一次就诊Encounter、一项观察Observation如血压值、一条诊断Condition、一份用药请求MedicationRequest都被定义成一种标准的“资源”Resource。每个资源有固定的结构就像乐高积木的凸点和凹槽通过特定的字段如subject引用病人code定义观察类型相互链接。例如一份简单的患者数据可能包含一个Patient资源包含ID、姓名、出生日期。一个Encounter资源记录本次就诊其subject字段指向那个Patient。几个Observation资源记录血压、血糖它们的subject指向Patientencounter指向本次Encountercode字段用LOINC或SNOMED CT标准码标明是“血压”还是“血糖”。一个Condition资源记录诊断“高血压”其subject指向Patientevidence字段可能引用那几个血压Observation作为依据。这种结构化的好处是机器可读、可交换。但对LLM来说它是一堆嵌套的JSON对象关系隐藏在字段引用中缺乏自然语言描述中那种直接的因果和时间线索。2.2 LLM在本地处理FHIR的典型困境当我们把一个未经增强的LLM比如一个7B或13B参数量的开源模型部署在本地并让它处理FHIR数据时通常会遇到以下几类问题上下文丢失与幻觉LLM的注意力机制在处理长序列一份完整的FHIR Bundle可能包含数十个资源时对于早期出现的信息记忆会衰减。它可能会记得病人有“高血压”诊断但忘了这个诊断所依据的血压测量值具体是多少、是什么时候测的。更糟糕的是它可能基于不完整的记忆“幻觉”出不存在的数据或关系。逻辑推理链条断裂临床任务往往是多步骤的。例如“评估该糖尿病患者本次就诊的血糖控制情况并给出用药调整建议”。这需要a) 识别患者所有相关的血糖观测值包括空腹、餐后、糖化血红蛋白b) 按时间排序评估趋势c) 结合当前的用药方案MedicationRequestd) 根据临床指南进行逻辑推理。原生LLM容易在步骤间丢失状态无法形成连贯的推理链。无法执行精确操作任务可能要求“提取最近一次肝功能检查中ALT和AST的值”。这需要智能体准确理解“最近一次”、“肝功能检查”、“ALT”、“AST”这些概念在FHIR资源中的对应关系Observation.code,Observation.effectiveDateTime并执行类似数据库查询的精确操作。纯文本生成的LLM不擅长这种确定性的信息检索。资源与计算限制本地部署的模型规模有限无法承载过于复杂的思维链CoT。我们需要设计更高效的状态管理和逻辑触发机制用有限的“算力”做更精准的“思考”。这些困境的根源在于通用的LLM是一个强大的“模式匹配与文本生成器”但不是一个内建了持久化工作记忆和确定性逻辑操作能力的“智能体”。我们的项目就是要为它补上这两块短板。3. 架构核心“状态增强”与“逻辑技能”如何实现“状态增强的逻辑技能”不是一个模糊的概念它需要一套可工程化的架构。在我的实现中它主要包含三个核心组件状态管理模块、技能工具箱和决策调度器。整个智能体的工作流程类似于一个拥有短期记忆和专用工具包的医生助理。3.1 状态管理模块智能体的“工作记忆白板”这是实现“状态增强”的关键。我们不能让LLM自己用隐藏层去记忆一切而是需要为它提供一个外部的、结构化的记忆体。我设计的状态State通常是一个动态更新的JSON对象包含以下层次{ “session_id”: “任务会话标识” “current_goal”: “当前要完成的顶级任务如‘评估糖尿病控制’” “processed_fhir_resources”: { “Patient”: [patient_resource_1], “Observation”: [obs_resource_1, obs_resource_2, ...], “Condition”: [...], // ... 按资源类型分类缓存已提取和解析的资源 }, “extracted_facts”: [ {“fact”: “患者张三男58岁” “source”: “Patient/123”, “confidence”: 1.0}, {“fact”: “2023-10-26 空腹血糖 7.8 mmol/L” “source”: “Observation/abc”, “confidence”: 1.0}, {“fact”: “诊断2型糖尿病2022年确诊” “source”: “Condition/def”, “confidence”: 1.0} // 从FHIR资源中提炼出的关键事实断言 ], “inference_history”: [ {“step”: 1, “action”: “提取所有血糖相关Observation” “result”: “找到3条记录” “state_snapshot”: “...”}, {“step”: 2, “action”: “按时间排序” “result”: “最近一次为今日空腹血糖7.8” “state_snapshot”: “...”} // 记录推理步骤和中间结果用于回溯和解释 ], “dialogue_context”: [] // 如果涉及多轮对话记录对话历史 }这个状态对象在任务开始时初始化随着智能体每一步的操作而更新。LLM在每一步决策时都会接收到这个完整的或部分摘要后的状态作为上下文。这就相当于给了LLM一个“工作记忆白板”它可以把重要的中间结果“写”在上面避免遗忘。注意状态的设计需要权衡。存储过多细节会挤占宝贵的上下文窗口存储过少又会导致记忆丢失。我的经验是extracted_facts提取的事实和inference_history推理历史是最关键的部分。前者用自然语言浓缩了原始数据后者保证了推理过程的透明和可回溯。3.2 技能工具箱封装好的“逻辑技能”“逻辑技能”在这里被具体化为一系列可调用、可组合的函数或工具。每个技能都对应一个明确的、可重复的临床数据处理或推理子任务。它们不是由LLM生成文本而是执行确定性的操作。我的技能工具箱通常包括FHIR查询技能给定资源类型和搜索参数如code‘血糖’ patient‘123’ date‘最近一年’从提供的FHIR Bundle或本地数据库中检索出匹配的资源列表。这个技能封装了FHIR REST API或本地JSON查询的逻辑。事实提取技能输入一个FHIR资源如一个Observation输出结构化的自然语言描述如“2023-10-26 空腹血糖 7.8 mmol/L”。这通常可以用模板或轻量级规则实现不一定需要LLM。时序排序技能给出一组带有时间戳的资源如多个Observation按时间先后排序。临床逻辑判断技能这是一类更复杂的技能。例如“判断血糖控制水平”技能输入一组按时间排序的血糖值根据指南如ADA标准判断是“控制良好”、“控制一般”还是“控制不佳”。这个技能内部可能封装了一个简单的规则引擎或一个小型决策树。报告生成技能根据当前状态中的extracted_facts和inference_history生成一段结构化的临床摘要或建议。每个技能都有明确定义的输入通常来自当前状态、输出会更新状态和描述用自然语言告诉LLM这个技能是干什么的。LLM的角色从“什么都自己干”转变为“根据当前状态和任务决定调用哪个技能并生成正确的调用参数”。3.3 决策调度器LLM作为“大脑”与“调度员”这是连接LLM、状态和技能的枢纽。其工作流程是一个循环感知决策调度器将当前的任务目标、状态摘要、可用的技能列表及其描述组合成一个提示词Prompt提交给本地部署的LLM。规划与决策LLM分析提示决定下一步该做什么。它可能输出两种结果调用技能{action: call_skill, skill_name: extract_blood_glucose_observations, parameters: {patient_id: 123, lookback_period: P1Y}}更新任务/结束{action: update_goal, new_goal: 分析血糖趋势}或{action: final_answer, answer: 患者血糖控制不佳建议...}执行调度器解析LLM的输出。如果是调用技能则从工具箱中找到对应技能传入参数执行。技能执行后会返回结果并自动更新状态管理模块例如将新提取的事实加入extracted_facts将本次操作记录到inference_history。循环更新后的状态连同原始任务再次形成提示词交给LLM进行下一轮决策。直到LLM决定输出最终答案或任务无法继续。这个架构的精妙之处在于它将LLM的强项理解复杂意图、进行高层规划与确定性程序的强项精确查询、逻辑计算、状态持久化结合了起来。LLM专注于“该做什么”而具体的“怎么做”交给了可靠的技能去执行。4. 实战演练构建一个糖尿病管理智能体理论说再多不如看实战。假设我们要构建一个本地部署的智能体用于处理糖尿病患者随访数据的FHIR Bundle并完成“评估本次血糖控制情况”的任务。4.1 环境准备与模型选型首先我们需要一个可以在本地运行的轻量级LLM。考虑到性能和精度平衡我选择了Qwen2.5-7B-Instruct的4位量化版本GGUF格式。它在7B这个尺寸上展现了不错的指令遵循和推理能力并且通过llama.cpp或Ollama等工具可以轻松在消费级GPU甚至高性能CPU上运行。# 示例使用Ollama在本地运行假设已有对应模型 ollama run qwen2.5:7b # 或者使用 llama-cpp-python 库在代码中集成 from llama_cpp import Llama llm Llama(model_path./qwen2.5-7b-instruct-q4_0.gguf, n_ctx4096, verboseFalse)技能工具箱的实现我使用Python的fhir.resources库来解析和操作FHIR数据并用简单的函数来封装各个技能。# 示例一个简单的FHIR查询技能 from fhir.resources.observation import Observation from datetime import datetime, timedelta import json def skill_query_observations(fhir_bundle, resource_type, patient_id, code_system, code_value, lookback_daysNone): 从FHIR Bundle中查询特定患者的观察项。 observations [] for entry in fhir_bundle.entry: if entry.resource.resource_type resource_type: obs entry.resource # 检查患者匹配 if obs.subject.reference ! fPatient/{patient_id}: continue # 检查编码匹配 (简化示例实际需处理CodeableConcept) if hasattr(obs, code) and obs.code.coding: for coding in obs.code.coding: if coding.system code_system and coding.code code_value: # 检查时间范围 if lookback_days: obs_date datetime.fromisoformat(obs.effectiveDateTime.replace(Z, 00:00)) if obs_date datetime.now() - timedelta(dayslookback_days): continue observations.append(obs) return observations4.2 任务执行全流程拆解现在我们启动智能体输入任务“评估患者ID-123的近期血糖控制情况”。假设我们有一个包含该患者近一年数据的FHIR Bundle。第一轮循环状态初始化current_goal “评估患者ID-123的近期血糖控制情况”其他为空。调度器提示LLM提示词包含目标、空状态、技能列表如“query_observations: 根据患者ID和检验代码查询观察项”、“extract_facts: 从观察项中提取关键事实”、“assess_control: 根据血糖值评估控制水平”。LLM决策LLM分析后决定第一步需要获取血糖数据。它输出{action: call_skill, skill_name: query_observations, parameters: {patient_id: 123, code_system: http://loinc.org, code_value: 2339-0, lookback_days: 90}}2339-0是LOINC中“葡萄糖[质量/体积] 在血清或血浆中”的代码代表血糖执行与状态更新调度器调用skill_query_observations从Bundle中找出近90天所有血糖Observation。结果比如3条记录被添加到processed_fhir_resources[‘Observation’]中。同时在inference_history中记录“步骤1查询到患者123近90天血糖观测值3条”。第二轮循环调度器提示LLM这次提示词包含了更新后的状态特别是inference_history和processed_fhir_resources摘要。LLM决策LLM看到已有数据决定下一步是提炼关键信息。它输出{action: call_skill, skill_name: extract_facts, parameters: {resource_type: Observation, keys: [effectiveDateTime, valueQuantity]}}执行与状态更新extract_facts技能遍历那3条Observation生成如下的自然语言事实存入extracted_facts1. 2023-10-01 空腹血糖 6.5 mmol/L 2. 2023-10-15 餐后2h血糖 10.2 mmol/L 3. 2023-10-26 空腹血糖 7.8 mmol/L历史记录更新。第三轮循环LLM决策LLM看到具体数值决定进行临床评估。它输出{action: call_skill, skill_name: assess_blood_glucose_control, parameters: {glucose_facts: [/* 上面三条事实 */]}}执行与状态更新assess_blood_glucose_control技能内部根据预设规则例如空腹血糖7.0或餐后10.0即为控制不佳进行计算。它返回结果“血糖控制不佳近3次测量中有2次超标”。这个结果作为新的事实加入extracted_facts。第四轮循环LLM决策LLM看到评估结果已完成当前目标已达成决定生成最终答案。它输出{action: final_answer, answer: 根据患者ID-123近90天的血糖记录2023-10-01空腹6.5 mmol/L 2023-10-15餐后10.2 mmol/L 2023-10-26空腹7.8 mmol/L评估其血糖控制不佳。建议加强生活方式干预或复诊调整治疗方案。}任务结束调度器输出最终答案流程终止。在整个过程中LLM始终在“状态”的引导下进行决策每一步操作都通过“技能”可靠地执行并将结果固化到“状态”中。这使得它能够完成一个需要多步记忆和逻辑判断的复杂任务。4.3 关键配置与调优心得提示词工程是灵魂给LLM的提示词必须清晰定义角色、任务格式、可用技能和状态结构。我常用的模板是你是一个医疗AI助手通过调用工具来处理FHIR数据。你的目标{current_goal}。 当前已知状态{state_summary}。 你可以使用以下工具 - 工具A: 描述。输入格式{...}。输出{...}。 - 工具B: ... 请根据当前目标和状态决定下一步行动。你必须输出一个严格的JSON对象只包含action和相应的参数如skill_name, parameters。如果任务完成输出final_answer。 可能的行动call_skill, update_goal, final_answer。需要反复调试确保LLM能稳定输出可解析的JSON。状态摘要的艺术不能每次都把完整的、庞大的状态JSON塞给LLM。需要设计一个“摘要函数”从完整状态中提取最关键的信息给LLM做决策比如只显示最近几步的inference_history和最重要的几条extracted_facts。这能有效节省上下文长度。技能的原子性与可靠性每个技能应该只做一件事并做好。技能内部的逻辑要尽可能确定和健壮避免把模糊推理丢给技能本身。如果技能执行失败如未找到数据必须返回明确的错误信息并更新状态让LLM能据此调整策略例如放宽查询条件。错误处理与回退机制LLM可能会输出无法解析的JSON或调用不存在的技能。调度器必须有健壮的错误捕获和重试机制。例如当解析失败时可以将错误信息连同原始提示再次发给LLM要求其纠正。通常设置最多3次重试。5. 效能评估与未来演进方向部署这样一个系统后如何评估其好坏单纯的“答案正确率”不够因为临床任务非常复杂。我主要从三个维度评估任务完成度对于给定的FHIR临床任务如信息提取、简单判断智能体能否在有限的循环步骤内输出一个明确的、与任务相关的答案它是否会陷入死循环或输出无关内容推理可解释性inference_history是否清晰记录了每一步的决策和结果当输出一个结论时我们能否根据状态回溯看到它是基于哪些数据、通过了哪些步骤得出的这对于医疗场景的信任至关重要。资源效率完成一个典型任务平均需要调用多少次LLM即循环次数每次LLM调用的响应时间如何整体任务耗时是否在可接受范围内如数秒内从我目前的实验来看通过“状态增强的逻辑技能”架构一个7B级别的本地模型在多项结构化临床任务如用药清单生成、异常指标筛查、随访报告摘要上的完成度和可靠性显著高于直接使用相同模型进行端到端的问答。它减少了幻觉提高了处理复杂逻辑任务的能力。当然这只是一个起点。这个框架还有很大的演进空间更复杂的技能链当前技能是平铺的。未来可以引入“子任务”技能允许技能调用其他技能形成更复杂的层次化任务分解。状态的自学习与优化目前状态结构是预设的。能否让智能体在运行中自主决定哪些信息值得存入长期状态extracted_facts这需要引入轻量级的强化学习或启发式规则。与本地知识库结合除了处理输入的FHIR Bundle智能体能否在状态中关联查询本地的临床指南知识库如以向量数据库形式存储使推理更有依据多模态扩展FHIR标准也支持包含医学影像的引用。未来可以集成视觉技能让智能体能处理影像报告甚至分析影像本身需要专门的视觉模型。这个项目的核心价值在于它提供了一种务实的技术路径。在完全依赖一个“全能”且合规的医疗大模型还不现实的今天通过将问题分解用“状态”管理记忆用“技能”封装确定性逻辑我们能让一个中等规模、可本地部署的模型在特定领域如基于FHIR的临床任务中表现出接近甚至超越其本身能力的、可靠且可解释的智能行为。这为在严格隐私要求下的医疗场景应用AI打开了一扇切实可行的窗。