1. 项目概述当Agentic AI走进三甲医院门诊“优化门诊流程”几乎是每家大型医院管理层的年度KPI但真正能啃下这块硬骨头的方案却寥寥无几。传统的IT系统升级往往陷入“流程电子化”的怪圈——把纸质表格变成电子表格把排队叫号搬到屏幕上但患者“三长一短”挂号排队时间长、候诊时间长、取药时间长、看病时间短的核心痛点依然存在。医生和护士则被困在大量的文书录入、信息核对和重复沟通中疲惫不堪。去年我有幸深度参与了一个标杆性项目为国内某顶尖三甲医院设计并落地了一套基于Agentic AI智能体人工智能的门诊流程优化系统。这不是一个简单的聊天机器人或者导诊问答而是一个由多个专业AI智能体协同工作的“虚拟门诊运营团队”。项目上线后门诊患者平均滞留时间缩短了40%医生文书工作时间减少了近30%患者满意度调查中“流程清晰便捷”项的得分提升了惊人的35个百分点。这一切的起点并非多么高深的算法而是一门被称为“提示工程架构”的艺术与科学的结合。很多人把提示工程理解为“怎么向ChatGPT提问更有效”这实在是大材小用了。在真实的产业级应用中提示工程是构建可靠、可控、可扩展AI系统的基石它决定了智能体能否理解复杂的医疗场景、能否做出合规的决策、能否像经验丰富的分诊护士一样精准工作。今天我就以这个医院项目为蓝本拆解一个完整的提示工程架构师是如何思考、设计和落地的。2. 核心需求与挑战拆解门诊不是聊天室在动手写一行提示词之前我们必须像产品经理一样深入门诊的每一个角落理解这里真正的“战场”是什么。2.1 业务场景的复杂性远超想象门诊流程看似线性挂号-候诊-看诊-检查-取药-离院实则是一个充满并发、中断和异常处理的动态网络。一个来看高血压的老年患者可能同时有糖尿病病史正在服用多种药物本次主诉是头晕但沟通中发现他最近睡眠也很差。这要求我们的系统至少能处理以下几类任务精准分诊与预问诊根据患者主诉和基础信息快速匹配到正确的科室是神经内科、心血管内科还是耳鼻喉科并提前收集结构化病史。就诊过程辅助在医生面诊时实时将医患对话转为结构化病历自动提取关键症状、体征和医嘱减轻医生录入负担。智能导引与宣教根据医生开具的检查单或处方为患者生成个性化的、图文并茂的后续步骤指引如“请先到三楼东区抽血抽血后无需等待可直接去二楼做心脏彩超预计等待时间约25分钟”和用药/康复指导。异常情况预警与处理识别患者描述中的危急值如“胸痛持续不缓解”或医嘱中的潜在冲突如新开药物与患者已知过敏史冲突并启动预警流程。2.2 技术层面的核心挑战面对上述业务传统的规则引擎或简单的大模型调用会立刻败下阵来。我们面临的挑战是系统性的上下文管理之困一个患者的就诊旅程可能跨越数小时涉及多个智能体分诊助手、病历助手、导引助手协作。如何让后续的智能体“记住”之前发生的所有事情比如分诊时患者说“头晕一周”病历助手就不能再问“您哪里不舒服”。这需要一套精密的“记忆”与“状态”传递机制。工具使用的精确性智能体需要调用医院内部系统如HIS医院信息系统、LIS检验系统、PACS影像系统。调用哪个API参数是什么比如“开一个血常规检查”智能体必须能精确生成调用HIS.create_lab_order(patient_id, test_codeCBC)的指令而不是模糊地说“请系统开个验血单子”。合规与安全的极端要求医疗领域容错率极低。智能体的每一句回复、每一个建议都必须严谨、可追溯且绝不能产生“幻觉”即编造不存在的医疗信息。同时患者隐私数据PHI必须在任何环节都得到保护不能泄露给未经授权的第三方模型或服务。性能与成本的平衡门诊高峰期并发咨询量可能巨大。智能体需要快速响应同时每次调用大模型都产生成本上下文越长成本越高。我们需要在体验、准确性和经济性之间找到最佳平衡点。这些挑战最终都指向了对“提示工程”的更高维度理解——它不再是单次的提问技巧而是设计一套让多个AI智能体能够可靠、安全、高效协作的架构。这就是“提示工程架构师”的价值所在。3. 架构设计构建门诊AI“虚拟团队”我们的核心设计思想是“术业有专攻协同作战”。与其训练一个包罗万象的“超级AI医生”既不现实也不安全不如组建一个由多个专项智能体组成的虚拟团队每个智能体都通过精心设计的“角色提示词”和“工作流程”来履行职责。3.1 智能体角色定义与系统提示词设计系统提示词是智能体的“岗位说明书”和“行为准则”这是提示工程架构的核心。我们为每个智能体设计了高度结构化、边界清晰的提示词。1. 分诊调度智能体这个智能体扮演“预检分诊护士”的角色目标是快速分类和引导。# 角色与目标 你是一名经验丰富的三甲医院预检分诊护士。你的核心任务是根据患者的初步描述将其引导至最合适的门诊科室并完成初步信息采集。 # 能力与约束 - 你只能询问为了完成分诊所必需的信息主要症状、部位、持续时间、加重缓解因素、既往相关病史。 - 你**严禁**提供任何诊断意见、治疗建议或药物推荐。 - 你必须严格遵守分诊规则库见下文工具。 - 你的语气应专业、清晰、富有同理心。 # 工作流程 1. 问候并表明身份。 2. 依次询问核心分诊问题。 3. 调用triage_rules_engine工具根据输入获取推荐科室和紧急程度。 4. 告知患者推荐科室、原因及后续步骤如“根据您的描述建议您挂【心血管内科】门诊。因为持续性胸痛需要优先排除心脏问题。您可以通过自助机或手机APP挂号挂号后请到三楼候诊。” # 工具 你可以使用以下工具 - triage_rules_engine(symptom, duration, ...): 输入症状信息返回推荐科室代码、科室名称及紧急程度1-5级。设计要点通过“严禁诊断”的强约束确保合规将核心判断逻辑剥离到外部工具规则引擎让大模型专注于自然的问诊对话和解释而非记忆复杂的医学规则这大大降低了幻觉风险。2. 病历文书辅助智能体这个智能体扮演“实习医生”的角色负责将医患自由对话转化为结构化病历。# 角色与目标 你是门诊医生的文书助手。你的任务是在医患对话过程中实时提取关键信息填充结构化电子病历SOAP格式并识别潜在的信息缺失或矛盾。 # 工作流程 1. 实时监听或接收转录文本医患对话。 2. 针对当前对话片段提取并更新以下结构化字段 - 主观(S): 患者主诉、现病史、既往史、个人史。 - 客观(O): 生命体征、体格检查发现需明确标注为“医生提及”或“患者自述”。 - 评估(A): 自动归纳当前讨论中的关键问题列表如“1. 高血压控制情况评估2. 头晕原因待查”**但不包含诊断结论**。 - 计划(P): 提取医生提及的检查、治疗或随访计划。 3. 识别信息缺口当发现关键信息缺失时如现病史缺少“诱因”在输出中友好标注“【待确认】”。 4. 输出为清晰的JSON格式供HIS系统接口调用。 # 重要原则 - 绝对忠实于对话原文不 extrapolate外推任何未提及的信息。 - 对于诊断性语句只记录“医生提到可能为XX”不自作主张。 - 所有体格检查发现必须注明来源。设计要点采用SOAP这一临床广泛接受的结构使输出可直接被医生审阅和使用。强调“注明来源”和“识别缺口”这是建立医生信任的关键——AI是辅助而非替代。3. 用药安全与导引智能体这个智能体在医生开立处方或检查后激活扮演“药师”和“导诊员”的双重角色。# 角色与目标 你是患者用药安全的守护者和就诊流程的向导。基于医生开具的处方和检查单你的目标是 1. 生成患者能看懂的个性化用药指导和注意事项。 2. 生成最优的后续检查/取药流程导引。 3. 进行实时安全核查。 # 工作流程与工具 1. 接收输入患者基本信息、药品清单含用法用量、检查项目清单。 2. 调用安全核查工具链 - check_drug_allergy(patient_id, drug_list): 核对过敏史。 - check_drug_interaction(drug_list): 核查药物相互作用。 - check_renal_dose_adjustment(drug, patient_creatinine): 核查肾功能调整如需要。 3. 若核查通过生成两份输出 - **用药指导**用口语化、分点说明每种药怎么吃、何时吃、可能有什么常见副作用、忘记吃了怎么办。 - **流程导引**结合医院实时排队系统数据通过get_queue_status工具获取规划最优顺序。例如“1. 请先到门诊药房2号窗口缴费取药当前排队3人2. 取药后到三楼检验科抽血排队约15分钟3. 抽血后可到一楼放射科登记胸部CT已为您预约下午3点档期。” 4. 若核查不通过立即触发预警输出标准预警信息给护士站屏幕。设计要点将专业性强的安全核查交给专用工具这些工具背后是权威的药品知识库大模型则发挥其强大的自然语言生成能力将专业信息转化为温情、清晰的患者指引。同时通过集成实时数据提供动态的、真正有用的导引而非静态的楼层指示图。3.2 智能体间的协同与上下文传递架构单个智能体能力再强如果彼此孤立也无法形成合力。我们采用了基于“事件总线”和“共享上下文存储”的协同架构。以患者会话为核心的上下文管理系统为每一次患者就诊创建一个唯一的session_id。所有发生在该会话中的交互——分诊记录、预问诊信息、医患对话片段、开具的医嘱——都被结构化地存储在一个“共享上下文存储”中技术上可采用向量数据库关系型数据库的组合。智能体的激活与上下文注入智能体并非一直在线。它们由特定事件触发。例如当患者完成分诊进入候诊队列时“病历文书辅助智能体”被激活。它启动时会从共享存储中获取该患者本次就诊的所有已有信息如分诊主诉作为其系统提示词的一部分动态注入。这确保了信息的连续性避免了患者重复陈述。通过工具调用实现硬交接智能体间的协作不依赖于模糊的自然语言传递。例如“分诊智能体”在结束时会调用一个update_visit_context工具将确定的科室、紧急程度和采集到的关键病史写入共享存储。这个工具调用成功的事件会触发下一个智能体的初始化。这种基于API的硬交接比让AI在对话中说“我把情况告诉下一个同事”要可靠得多。这个架构的核心思想是用工程化的、确定性的方式来管理AI的不确定性。每个智能体的职责被严格限定它们之间的信息和责任通过设计良好的数据接口和事件流来传递而不是依赖大模型自己去“联想”和“概括”。4. 核心实现提示词工程与工具链的深度集成有了架构接下来就是如何让每个智能体“乖乖听话”精准地使用工具并输出稳定可靠的结果。这里充满了细节与技巧。4.1 结构化输出与函数调用Function Calling的强制约束大模型生成自由文本很容易但要让其输出机器可读、格式严格统一的内容需要技巧。我们大量使用了JSON Schema来定义输出格式并通过函数调用Function Calling机制来“框定”AI的行为。以“病历文书辅助智能体”提取“现病史”为例我们不希望它生成一段自由文本而是希望得到结构化数据{ chief_complaint: 头晕, duration: 3天, onset: 突发, aggravating_factors: 起床时加重, relieving_factors: 休息后稍缓解, associated_symptoms: [恶心, 无视物旋转] }为了实现这一点我们在该智能体的工具列表中定义了一个update_soap_subjective函数其输入参数就是一个符合上述结构的JSON Schema。在提示词中我们明确指令“请将提取的信息通过调用update_soap_subjective工具进行提交”。模型为了调用这个工具就必须生成符合预定格式的数据。这比在提示词中说“请输出JSON”要有效和稳定得多因为函数调用机制是大模型原生支持、经过专门优化的能力。实操心得定义工具函数时参数描述description至关重要。例如duration字段的描述应写为“症状持续的总时间长度如‘3天’、‘2小时’”而不仅仅是“持续时间”。清晰的描述能极大提升大模型填充参数的准确性。4.2 动态上下文构建与压缩策略随着对话进行上下文会越来越长。将整个就诊历史都塞给大模型既不经济成本高也可能导致模型性能下降关键信息被淹没。我们采用了分层级的动态上下文构建策略核心会话记忆只保留最近3-5轮医患对话的原始文本保证短期连贯性。结构化摘要将更早的对话或从对话中提取出的结构化信息如已确认的病史、已开具的检查以摘要形式存储。例如“患者已确认有高血压病史5年平日服用‘氨氯地平’自述控制尚可。10分钟前医生已开具‘血常规’、‘心电图’检查。”工具调用结果缓存对于智能体通过工具查询到的、不常变动的信息如药品说明书摘要、科室位置信息将其结果缓存起来。当下次需要时直接在提示词中注入“根据知识库某药常用于...”而不是再次触发工具调用和生成冗长的结果文本。基于意图的上下文检索当智能体需要历史信息时不是一股脑全喂给它而是先用一个简单的分类器判断当前意图例如“患者是在询问检查结果吗”然后从向量数据库中检索与当前意图最相关的历史片段注入上下文。这套组合拳下来每次调用大模型所携带的上下文都能保持在高效、经济的范围内同时又不丢失关键信息。4.3 工具链的设计与安全保障工具是智能体连接现实世界的“手”和“眼”。在医院场景下工具链的设计首要考虑的是安全与审计。工具权限最小化每个智能体仅被授予完成其职责所必需的最小工具权限。分诊智能体只能调用规则引擎和读科室信息绝对没有权限调用开具处方或查看完整病历的工具。工具结果的标准化与验证所有工具返回的结果都必须是结构化的、可解析的。对于关键操作如任何写操作工具内部必须实现业务逻辑校验和二次确认。例如create_prescription工具在接到AI请求后内部会再次核对药品剂量是否在安全范围内、医生工号是否有权限等。完整的审计日志每一次工具调用无论成功失败都必须记录完整的日志谁哪个智能体、对应哪个患者会话、在何时、调用了什么工具、输入参数是什么、返回结果是什么。这为事后的问题追溯、流程优化和合规审计提供了不可篡改的依据。“人机回环”设计对于高风险或关键决策点工具设计必须包含“人机回环”。例如当用药安全智能体检测到潜在的严重药物相互作用时它调用的工具不是直接阻止而是generate_alert_for_pharmacist生成一条预警发送给药师工作站由药师进行最终审核。AI是辅助和预警而不是绕过人类专业人员的自动决策。5. 效果评估、迭代与避坑指南项目上线不是终点而是开始。我们建立了一套持续评估和迭代的机制。5.1 多维度的评估体系我们不仅仅看技术指标如响应时间、API调用成功率更关注业务指标和体验指标业务效率指标患者平均在院时间、分诊准确率与最终就诊科室对比、医生病历文书完成时间。AI质量指标工具调用准确率智能体在需要时是否调用了正确的工具参数填充是否准确我们通过日志分析来计算。信息提取准确率与召回率随机抽样医患对话录音对比AI提取的结构化病历与人工标注的黄金标准计算精确率提取的信息是否正确和召回率是否漏掉了关键信息。幻觉率在AI生成的任何文本中如患者导引是否存在虚构的、无来源的信息这是一个需要人工抽查的关键安全指标。用户体验指标通过埋点和简短问卷收集患者和医生对AI交互的满意度、清晰度、帮助性评分。5.2 持续迭代的闭环基于上述评估数据我们形成了快速的迭代闭环问题发现通过审计日志发现病历助手在提取“疼痛性质”时经常将“胀痛”和“酸痛”混淆。根因分析回顾提示词发现描述不够精确。同时检查训练数据发现语料中这两种描述的区分度不够。提示词优化将提示词中相关的部分修改为“疼痛性质需严格区分胀痛通常描述一种内部充盈、发紧的感觉酸痛多与肌肉疲劳、乳酸堆积相关常描述为肌肉深部的酸软感。如不确定请输出‘【待确认】’。”工具增强考虑引入一个专门的pain_descriptor_classifier微调小模型或规则库让智能体在遇到模糊描述时先调用此工具进行标准化再将结果填入病历。A/B测试与上线将优化后的智能体部署到小流量分支对比关键指标确认有效后全量发布。5.3 实战中踩过的坑与心得不要追求“万能智能体”早期我们尝试让一个智能体做所有事结果提示词变得极其复杂效果很差且难以调试。拆分成专注的智能体后每个提示词都简单、清晰效果和稳定性大幅提升。高内聚、低耦合的软件设计原则在AI智能体架构中同样适用。医生要的是“助手”不是“学生”最初版本的病历助手会在信息缺失时不断追问医生“这个症状的诱因是什么”。这严重干扰了医生的问诊节奏引起反感。后来我们调整为“静默记录”模式只在界面侧边栏用非侵入性的方式标注“【待确认】”由医生在问诊间隙或结束后自行补充。AI的交互设计必须符合用户的工作流而不是反过来。数据质量是天花板智能体的表现严重依赖其接触到的数据。我们花在清洗和标注历史医患对话录音文本上的时间比写提示词的时间多得多。特别是医学表述的标准化同一种病有十几种说法和实体识别药品名、检查名、科室名必须下苦功夫。没有高质量的数据再精巧的提示工程也是空中楼阁。安全是底线必须“双保险”任何涉及患者安全或写操作的工具调用都必须有至少一层独立于大模型逻辑的校验。例如AI建议的用药剂量必须经过医院药学知识库系统的二次校验AI生成的导引路径必须与医院的实时调度系统进行碰撞检测。永远不要完全信任AI的输出要用系统性的规则和流程为其兜底。成本监控至关重要大模型调用成本会随着使用量快速增长。必须建立细粒度的成本监控分析每个会话、每个智能体的平均token消耗识别是否有上下文膨胀、无效重复调用等问题。动态上下文压缩和结果缓存是我们控制成本最有效的手段。这个项目让我深刻体会到提示工程架构师的角色更像是一个AI时代的系统架构师兼产品经理。他不仅需要理解大模型的能力与局限更要深谙业务领域的细节与约束然后用工程化的思维将不确定的AI能力组装成确定性的、可靠的业务系统。医疗场景只是开始这套以“角色智能体工具链上下文工程”为核心的方法论对于金融、法律、客服等任何需要专业知识、严谨流程和高可靠性的领域都有着巨大的应用潜力。真正的价值不在于让AI变得多“智能”而在于让它变得多“可靠”和“有用”。
1. 项目概述当Agentic AI走进三甲医院门诊“优化门诊流程”几乎是每家大型医院管理层的年度KPI但真正能啃下这块硬骨头的方案却寥寥无几。传统的IT系统升级往往陷入“流程电子化”的怪圈——把纸质表格变成电子表格把排队叫号搬到屏幕上但患者“三长一短”挂号排队时间长、候诊时间长、取药时间长、看病时间短的核心痛点依然存在。医生和护士则被困在大量的文书录入、信息核对和重复沟通中疲惫不堪。去年我有幸深度参与了一个标杆性项目为国内某顶尖三甲医院设计并落地了一套基于Agentic AI智能体人工智能的门诊流程优化系统。这不是一个简单的聊天机器人或者导诊问答而是一个由多个专业AI智能体协同工作的“虚拟门诊运营团队”。项目上线后门诊患者平均滞留时间缩短了40%医生文书工作时间减少了近30%患者满意度调查中“流程清晰便捷”项的得分提升了惊人的35个百分点。这一切的起点并非多么高深的算法而是一门被称为“提示工程架构”的艺术与科学的结合。很多人把提示工程理解为“怎么向ChatGPT提问更有效”这实在是大材小用了。在真实的产业级应用中提示工程是构建可靠、可控、可扩展AI系统的基石它决定了智能体能否理解复杂的医疗场景、能否做出合规的决策、能否像经验丰富的分诊护士一样精准工作。今天我就以这个医院项目为蓝本拆解一个完整的提示工程架构师是如何思考、设计和落地的。2. 核心需求与挑战拆解门诊不是聊天室在动手写一行提示词之前我们必须像产品经理一样深入门诊的每一个角落理解这里真正的“战场”是什么。2.1 业务场景的复杂性远超想象门诊流程看似线性挂号-候诊-看诊-检查-取药-离院实则是一个充满并发、中断和异常处理的动态网络。一个来看高血压的老年患者可能同时有糖尿病病史正在服用多种药物本次主诉是头晕但沟通中发现他最近睡眠也很差。这要求我们的系统至少能处理以下几类任务精准分诊与预问诊根据患者主诉和基础信息快速匹配到正确的科室是神经内科、心血管内科还是耳鼻喉科并提前收集结构化病史。就诊过程辅助在医生面诊时实时将医患对话转为结构化病历自动提取关键症状、体征和医嘱减轻医生录入负担。智能导引与宣教根据医生开具的检查单或处方为患者生成个性化的、图文并茂的后续步骤指引如“请先到三楼东区抽血抽血后无需等待可直接去二楼做心脏彩超预计等待时间约25分钟”和用药/康复指导。异常情况预警与处理识别患者描述中的危急值如“胸痛持续不缓解”或医嘱中的潜在冲突如新开药物与患者已知过敏史冲突并启动预警流程。2.2 技术层面的核心挑战面对上述业务传统的规则引擎或简单的大模型调用会立刻败下阵来。我们面临的挑战是系统性的上下文管理之困一个患者的就诊旅程可能跨越数小时涉及多个智能体分诊助手、病历助手、导引助手协作。如何让后续的智能体“记住”之前发生的所有事情比如分诊时患者说“头晕一周”病历助手就不能再问“您哪里不舒服”。这需要一套精密的“记忆”与“状态”传递机制。工具使用的精确性智能体需要调用医院内部系统如HIS医院信息系统、LIS检验系统、PACS影像系统。调用哪个API参数是什么比如“开一个血常规检查”智能体必须能精确生成调用HIS.create_lab_order(patient_id, test_codeCBC)的指令而不是模糊地说“请系统开个验血单子”。合规与安全的极端要求医疗领域容错率极低。智能体的每一句回复、每一个建议都必须严谨、可追溯且绝不能产生“幻觉”即编造不存在的医疗信息。同时患者隐私数据PHI必须在任何环节都得到保护不能泄露给未经授权的第三方模型或服务。性能与成本的平衡门诊高峰期并发咨询量可能巨大。智能体需要快速响应同时每次调用大模型都产生成本上下文越长成本越高。我们需要在体验、准确性和经济性之间找到最佳平衡点。这些挑战最终都指向了对“提示工程”的更高维度理解——它不再是单次的提问技巧而是设计一套让多个AI智能体能够可靠、安全、高效协作的架构。这就是“提示工程架构师”的价值所在。3. 架构设计构建门诊AI“虚拟团队”我们的核心设计思想是“术业有专攻协同作战”。与其训练一个包罗万象的“超级AI医生”既不现实也不安全不如组建一个由多个专项智能体组成的虚拟团队每个智能体都通过精心设计的“角色提示词”和“工作流程”来履行职责。3.1 智能体角色定义与系统提示词设计系统提示词是智能体的“岗位说明书”和“行为准则”这是提示工程架构的核心。我们为每个智能体设计了高度结构化、边界清晰的提示词。1. 分诊调度智能体这个智能体扮演“预检分诊护士”的角色目标是快速分类和引导。# 角色与目标 你是一名经验丰富的三甲医院预检分诊护士。你的核心任务是根据患者的初步描述将其引导至最合适的门诊科室并完成初步信息采集。 # 能力与约束 - 你只能询问为了完成分诊所必需的信息主要症状、部位、持续时间、加重缓解因素、既往相关病史。 - 你**严禁**提供任何诊断意见、治疗建议或药物推荐。 - 你必须严格遵守分诊规则库见下文工具。 - 你的语气应专业、清晰、富有同理心。 # 工作流程 1. 问候并表明身份。 2. 依次询问核心分诊问题。 3. 调用triage_rules_engine工具根据输入获取推荐科室和紧急程度。 4. 告知患者推荐科室、原因及后续步骤如“根据您的描述建议您挂【心血管内科】门诊。因为持续性胸痛需要优先排除心脏问题。您可以通过自助机或手机APP挂号挂号后请到三楼候诊。” # 工具 你可以使用以下工具 - triage_rules_engine(symptom, duration, ...): 输入症状信息返回推荐科室代码、科室名称及紧急程度1-5级。设计要点通过“严禁诊断”的强约束确保合规将核心判断逻辑剥离到外部工具规则引擎让大模型专注于自然的问诊对话和解释而非记忆复杂的医学规则这大大降低了幻觉风险。2. 病历文书辅助智能体这个智能体扮演“实习医生”的角色负责将医患自由对话转化为结构化病历。# 角色与目标 你是门诊医生的文书助手。你的任务是在医患对话过程中实时提取关键信息填充结构化电子病历SOAP格式并识别潜在的信息缺失或矛盾。 # 工作流程 1. 实时监听或接收转录文本医患对话。 2. 针对当前对话片段提取并更新以下结构化字段 - 主观(S): 患者主诉、现病史、既往史、个人史。 - 客观(O): 生命体征、体格检查发现需明确标注为“医生提及”或“患者自述”。 - 评估(A): 自动归纳当前讨论中的关键问题列表如“1. 高血压控制情况评估2. 头晕原因待查”**但不包含诊断结论**。 - 计划(P): 提取医生提及的检查、治疗或随访计划。 3. 识别信息缺口当发现关键信息缺失时如现病史缺少“诱因”在输出中友好标注“【待确认】”。 4. 输出为清晰的JSON格式供HIS系统接口调用。 # 重要原则 - 绝对忠实于对话原文不 extrapolate外推任何未提及的信息。 - 对于诊断性语句只记录“医生提到可能为XX”不自作主张。 - 所有体格检查发现必须注明来源。设计要点采用SOAP这一临床广泛接受的结构使输出可直接被医生审阅和使用。强调“注明来源”和“识别缺口”这是建立医生信任的关键——AI是辅助而非替代。3. 用药安全与导引智能体这个智能体在医生开立处方或检查后激活扮演“药师”和“导诊员”的双重角色。# 角色与目标 你是患者用药安全的守护者和就诊流程的向导。基于医生开具的处方和检查单你的目标是 1. 生成患者能看懂的个性化用药指导和注意事项。 2. 生成最优的后续检查/取药流程导引。 3. 进行实时安全核查。 # 工作流程与工具 1. 接收输入患者基本信息、药品清单含用法用量、检查项目清单。 2. 调用安全核查工具链 - check_drug_allergy(patient_id, drug_list): 核对过敏史。 - check_drug_interaction(drug_list): 核查药物相互作用。 - check_renal_dose_adjustment(drug, patient_creatinine): 核查肾功能调整如需要。 3. 若核查通过生成两份输出 - **用药指导**用口语化、分点说明每种药怎么吃、何时吃、可能有什么常见副作用、忘记吃了怎么办。 - **流程导引**结合医院实时排队系统数据通过get_queue_status工具获取规划最优顺序。例如“1. 请先到门诊药房2号窗口缴费取药当前排队3人2. 取药后到三楼检验科抽血排队约15分钟3. 抽血后可到一楼放射科登记胸部CT已为您预约下午3点档期。” 4. 若核查不通过立即触发预警输出标准预警信息给护士站屏幕。设计要点将专业性强的安全核查交给专用工具这些工具背后是权威的药品知识库大模型则发挥其强大的自然语言生成能力将专业信息转化为温情、清晰的患者指引。同时通过集成实时数据提供动态的、真正有用的导引而非静态的楼层指示图。3.2 智能体间的协同与上下文传递架构单个智能体能力再强如果彼此孤立也无法形成合力。我们采用了基于“事件总线”和“共享上下文存储”的协同架构。以患者会话为核心的上下文管理系统为每一次患者就诊创建一个唯一的session_id。所有发生在该会话中的交互——分诊记录、预问诊信息、医患对话片段、开具的医嘱——都被结构化地存储在一个“共享上下文存储”中技术上可采用向量数据库关系型数据库的组合。智能体的激活与上下文注入智能体并非一直在线。它们由特定事件触发。例如当患者完成分诊进入候诊队列时“病历文书辅助智能体”被激活。它启动时会从共享存储中获取该患者本次就诊的所有已有信息如分诊主诉作为其系统提示词的一部分动态注入。这确保了信息的连续性避免了患者重复陈述。通过工具调用实现硬交接智能体间的协作不依赖于模糊的自然语言传递。例如“分诊智能体”在结束时会调用一个update_visit_context工具将确定的科室、紧急程度和采集到的关键病史写入共享存储。这个工具调用成功的事件会触发下一个智能体的初始化。这种基于API的硬交接比让AI在对话中说“我把情况告诉下一个同事”要可靠得多。这个架构的核心思想是用工程化的、确定性的方式来管理AI的不确定性。每个智能体的职责被严格限定它们之间的信息和责任通过设计良好的数据接口和事件流来传递而不是依赖大模型自己去“联想”和“概括”。4. 核心实现提示词工程与工具链的深度集成有了架构接下来就是如何让每个智能体“乖乖听话”精准地使用工具并输出稳定可靠的结果。这里充满了细节与技巧。4.1 结构化输出与函数调用Function Calling的强制约束大模型生成自由文本很容易但要让其输出机器可读、格式严格统一的内容需要技巧。我们大量使用了JSON Schema来定义输出格式并通过函数调用Function Calling机制来“框定”AI的行为。以“病历文书辅助智能体”提取“现病史”为例我们不希望它生成一段自由文本而是希望得到结构化数据{ chief_complaint: 头晕, duration: 3天, onset: 突发, aggravating_factors: 起床时加重, relieving_factors: 休息后稍缓解, associated_symptoms: [恶心, 无视物旋转] }为了实现这一点我们在该智能体的工具列表中定义了一个update_soap_subjective函数其输入参数就是一个符合上述结构的JSON Schema。在提示词中我们明确指令“请将提取的信息通过调用update_soap_subjective工具进行提交”。模型为了调用这个工具就必须生成符合预定格式的数据。这比在提示词中说“请输出JSON”要有效和稳定得多因为函数调用机制是大模型原生支持、经过专门优化的能力。实操心得定义工具函数时参数描述description至关重要。例如duration字段的描述应写为“症状持续的总时间长度如‘3天’、‘2小时’”而不仅仅是“持续时间”。清晰的描述能极大提升大模型填充参数的准确性。4.2 动态上下文构建与压缩策略随着对话进行上下文会越来越长。将整个就诊历史都塞给大模型既不经济成本高也可能导致模型性能下降关键信息被淹没。我们采用了分层级的动态上下文构建策略核心会话记忆只保留最近3-5轮医患对话的原始文本保证短期连贯性。结构化摘要将更早的对话或从对话中提取出的结构化信息如已确认的病史、已开具的检查以摘要形式存储。例如“患者已确认有高血压病史5年平日服用‘氨氯地平’自述控制尚可。10分钟前医生已开具‘血常规’、‘心电图’检查。”工具调用结果缓存对于智能体通过工具查询到的、不常变动的信息如药品说明书摘要、科室位置信息将其结果缓存起来。当下次需要时直接在提示词中注入“根据知识库某药常用于...”而不是再次触发工具调用和生成冗长的结果文本。基于意图的上下文检索当智能体需要历史信息时不是一股脑全喂给它而是先用一个简单的分类器判断当前意图例如“患者是在询问检查结果吗”然后从向量数据库中检索与当前意图最相关的历史片段注入上下文。这套组合拳下来每次调用大模型所携带的上下文都能保持在高效、经济的范围内同时又不丢失关键信息。4.3 工具链的设计与安全保障工具是智能体连接现实世界的“手”和“眼”。在医院场景下工具链的设计首要考虑的是安全与审计。工具权限最小化每个智能体仅被授予完成其职责所必需的最小工具权限。分诊智能体只能调用规则引擎和读科室信息绝对没有权限调用开具处方或查看完整病历的工具。工具结果的标准化与验证所有工具返回的结果都必须是结构化的、可解析的。对于关键操作如任何写操作工具内部必须实现业务逻辑校验和二次确认。例如create_prescription工具在接到AI请求后内部会再次核对药品剂量是否在安全范围内、医生工号是否有权限等。完整的审计日志每一次工具调用无论成功失败都必须记录完整的日志谁哪个智能体、对应哪个患者会话、在何时、调用了什么工具、输入参数是什么、返回结果是什么。这为事后的问题追溯、流程优化和合规审计提供了不可篡改的依据。“人机回环”设计对于高风险或关键决策点工具设计必须包含“人机回环”。例如当用药安全智能体检测到潜在的严重药物相互作用时它调用的工具不是直接阻止而是generate_alert_for_pharmacist生成一条预警发送给药师工作站由药师进行最终审核。AI是辅助和预警而不是绕过人类专业人员的自动决策。5. 效果评估、迭代与避坑指南项目上线不是终点而是开始。我们建立了一套持续评估和迭代的机制。5.1 多维度的评估体系我们不仅仅看技术指标如响应时间、API调用成功率更关注业务指标和体验指标业务效率指标患者平均在院时间、分诊准确率与最终就诊科室对比、医生病历文书完成时间。AI质量指标工具调用准确率智能体在需要时是否调用了正确的工具参数填充是否准确我们通过日志分析来计算。信息提取准确率与召回率随机抽样医患对话录音对比AI提取的结构化病历与人工标注的黄金标准计算精确率提取的信息是否正确和召回率是否漏掉了关键信息。幻觉率在AI生成的任何文本中如患者导引是否存在虚构的、无来源的信息这是一个需要人工抽查的关键安全指标。用户体验指标通过埋点和简短问卷收集患者和医生对AI交互的满意度、清晰度、帮助性评分。5.2 持续迭代的闭环基于上述评估数据我们形成了快速的迭代闭环问题发现通过审计日志发现病历助手在提取“疼痛性质”时经常将“胀痛”和“酸痛”混淆。根因分析回顾提示词发现描述不够精确。同时检查训练数据发现语料中这两种描述的区分度不够。提示词优化将提示词中相关的部分修改为“疼痛性质需严格区分胀痛通常描述一种内部充盈、发紧的感觉酸痛多与肌肉疲劳、乳酸堆积相关常描述为肌肉深部的酸软感。如不确定请输出‘【待确认】’。”工具增强考虑引入一个专门的pain_descriptor_classifier微调小模型或规则库让智能体在遇到模糊描述时先调用此工具进行标准化再将结果填入病历。A/B测试与上线将优化后的智能体部署到小流量分支对比关键指标确认有效后全量发布。5.3 实战中踩过的坑与心得不要追求“万能智能体”早期我们尝试让一个智能体做所有事结果提示词变得极其复杂效果很差且难以调试。拆分成专注的智能体后每个提示词都简单、清晰效果和稳定性大幅提升。高内聚、低耦合的软件设计原则在AI智能体架构中同样适用。医生要的是“助手”不是“学生”最初版本的病历助手会在信息缺失时不断追问医生“这个症状的诱因是什么”。这严重干扰了医生的问诊节奏引起反感。后来我们调整为“静默记录”模式只在界面侧边栏用非侵入性的方式标注“【待确认】”由医生在问诊间隙或结束后自行补充。AI的交互设计必须符合用户的工作流而不是反过来。数据质量是天花板智能体的表现严重依赖其接触到的数据。我们花在清洗和标注历史医患对话录音文本上的时间比写提示词的时间多得多。特别是医学表述的标准化同一种病有十几种说法和实体识别药品名、检查名、科室名必须下苦功夫。没有高质量的数据再精巧的提示工程也是空中楼阁。安全是底线必须“双保险”任何涉及患者安全或写操作的工具调用都必须有至少一层独立于大模型逻辑的校验。例如AI建议的用药剂量必须经过医院药学知识库系统的二次校验AI生成的导引路径必须与医院的实时调度系统进行碰撞检测。永远不要完全信任AI的输出要用系统性的规则和流程为其兜底。成本监控至关重要大模型调用成本会随着使用量快速增长。必须建立细粒度的成本监控分析每个会话、每个智能体的平均token消耗识别是否有上下文膨胀、无效重复调用等问题。动态上下文压缩和结果缓存是我们控制成本最有效的手段。这个项目让我深刻体会到提示工程架构师的角色更像是一个AI时代的系统架构师兼产品经理。他不仅需要理解大模型的能力与局限更要深谙业务领域的细节与约束然后用工程化的思维将不确定的AI能力组装成确定性的、可靠的业务系统。医疗场景只是开始这套以“角色智能体工具链上下文工程”为核心的方法论对于金融、法律、客服等任何需要专业知识、严谨流程和高可靠性的领域都有着巨大的应用潜力。真正的价值不在于让AI变得多“智能”而在于让它变得多“可靠”和“有用”。
