Agentic 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_code='CBC')的指令，而不是模糊地说“请系统开个验血单子”。 - 合规与安全的极端要求：医疗领域容错率极低。智能体的每一句回复、每一个建议都必须严谨、可追溯，且绝不能产生“幻觉”（即编造不存在的医疗信息）。同时，患者隐私数据（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变得多“智能”，而在于让它变得多“可靠”和“有用”。