诊疗场景里的 Agent 很容易被包装成“自动诊断系统”但从工程落地看更稳妥的方向是流程助手整理信息、补齐材料、触发规则、记录过程、辅助医务人员完成复杂工作流。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议文中所有规则均为示例真实项目必须由医疗专业人员和机构规范确认。问题背景诊疗 Agent 的落点不只是模型能力医疗健康应用开发者在设计 Agent 时通常会遇到三个问题模型能否理解用户输入、系统如何控制输出边界、出了问题能否追溯责任链。诊断替代要求系统直接给出医学判断这不仅依赖模型还涉及数据完整性、机构流程、人员授权、质量控制和合规审计。相比之下流程助手的目标更明确把散落在不同系统和对话中的信息结构化把可重复的步骤自动化把需要人工确认的节点显式暴露出来。一个更合理的诊疗 Agent MVP可以先覆盖以下环节采集主诉、既往信息、检查资料等非结构化输入按机构模板生成结构化摘要检查必填字段是否缺失根据示例规则提示是否需要人工复核或升级处理记录每一步输入、模型输出、人工修改和策略命中结果这里的关键不是让 Agent “下结论”而是让它成为 workflow engine、policy engine、LLM API 和 audit log 之间的胶水层。技术目标与边界把 Agent 设计成可控节点流程助手型 Agent 的核心目标可以拆成四类。第一是状态管理。诊疗流程不是一次问答而是多轮、多角色、多系统参与的状态机。系统需要知道当前处于“信息采集”“资料核对”“摘要生成”“人工确认”还是“归档”阶段。第二是策略约束。LLM 输出天然具有不确定性因此不能把关键动作直接交给模型自由决定。升级规则、字段完整性检查、敏感输出拦截都应放在可配置的 policy engine 中。第三是人工确认。涉及诊疗相关判断的内容应进入人工确认节点。Agent 可以生成待确认摘要、列出缺失信息和冲突信息但不应绕过授权人员。第四是审计追踪。每次模型调用、提示词版本、输入数据摘要、策略命中、人工修改都要写入审计日志。没有审计链系统很难在真实环境中排查问题。一个简化架构如下User Input | v Workflow Engine | -- Data Normalizer | -- LLM API: summarize / extract / rewrite | -- Policy Engine: 示例规则校验 | -- Human Review Queue | v Audit Log Case State Store这个设计把 LLM 放在“生成和整理”位置而不是放在“最终决策”位置。对于工程团队来说这种边界更容易测试、灰度、回滚和解释。工程实现路径用状态机组织诊疗流程助手下面用 Python 写一个最小可运行示例演示如何把用户输入、LLM 摘要、示例规则和审计日志串起来。这里不会调用真实医疗系统也不会生成诊断建议只展示流程编排方式。fromdataclassesimportdataclass,fieldfromdatetimeimportdatetimefromtypingimportDict,List,AnydataclassclassAuditEvent:time:strcase_id:strstep:strdetail:Dict[str,Any]dataclassclassCaseState:case_id:strstage:strcollectingraw_text:strsummary:Dict[str,Any]field(default_factorydict)flags:List[str]field(default_factorylist)audit_logs:List[AuditEvent]field(default_factorylist)classAuditLogger:defwrite(self,state:CaseState,step:str,detail:Dict[str,Any]):state.audit_logs.append(AuditEvent(timedatetime.utcnow().isoformat(),case_idstate.case_id,stepstep,detaildetail))classMockLLMClient:defextract_summary(self,raw_text:str)-Dict[str,Any]:# 示例真实项目应替换为受控提示词、模型网关、脱敏与超时处理return{chief_complaint:raw_text[:80],history_provided:既往inraw_textor病史inraw_text,document_provided:报告inraw_textor检查inraw_text,agent_note:仅为流程整理摘要需人工确认}classPolicyEngine:defevaluate(self,summary:Dict[str,Any])-List[str]:flags[]# 示例规则真实项目应由医疗专业人员和机构规范确认ifnotsummary.get(history_provided):flags.append(缺少既往信息进入人工补充确认)# 示例规则真实项目应由医疗专业人员和机构规范确认ifnotsummary.get(document_provided):flags.append(缺少相关资料提示上传或人工核对)returnflagsclassDiagnosisWorkflowAssistant:def__init__(self):self.llmMockLLMClient()self.policyPolicyEngine()self.auditAuditLogger()defrun(self,state:CaseState,user_text:str)-CaseState:state.raw_textuser_text self.audit.write(state,input_received,{length:len(user_text)})state.summaryself.llm.extract_summary(user_text)state.stagesummarizedself.audit.write(state,summary_generated,state.summary)state.flagsself.policy.evaluate(state.summary)state.stagehuman_review_requiredifstate.flagselseready_for_reviewself.audit.write(state,policy_evaluated,{flags:state.flags})returnstateif__name____main__:workflowDiagnosisWorkflowAssistant()caseCaseState(case_idcase-20260520-0900)resultworkflow.run(case,用户描述近期不适希望整理就诊前信息。已有部分检查报告但未提供既往病史。)print(当前阶段:,result.stage)print(结构化摘要:,result.summary)print(流程提示:,result.flags)print(审计日志条数:,len(result.audit_logs))这个 Demo 的重点有三个。第一LLM 只负责摘要抽取不负责诊断判断。第二策略判断独立于 LLM可测试、可版本化、可由机构配置。第三所有关键节点都有审计日志后续可以接入 Elasticsearch、OpenSearch、ClickHouse 或对象存储。为什么流程助手比诊断替代更适合当前阶段从工程风险看诊断替代系统需要解决输入真实性、上下文完整性、模型稳定性、责任边界和持续质控。任何一个环节薄弱都会影响系统可信度。流程助手的输入输出更容易定义。例如“把用户描述转为结构化摘要”“提示缺失字段”“生成待确认清单”“记录人工修改前后差异”这些任务可以写测试用例也可以用人工标注样本评估准确率。从系统集成看医疗健康场景常常存在多个业务系统Agent 更适合做跨系统流程协调。例如从用户会话中抽取信息调用内部接口查询资料状态再把缺失项交给人工队列。这个过程中Agent 的价值来自任务编排而不是替代专业判断。从上线策略看流程助手支持渐进式发布。可以先只读不写只生成摘要不触发动作再进入人工确认模式最后对低风险、强规则的步骤做自动化。诊断替代则很难用同样方式平滑灰度因为输出本身就带有高风险决策含义。落地时要重点处理的四个工程问题第一提示词版本管理。所有 Prompt 都应有版本号并写入审计日志。模型升级、提示词调整、输出格式变化都需要可回溯。第二策略引擎不要写死在提示词里。示例规则可以由 YAML、JSON 或数据库配置并由后端服务执行。LLM 可以解释文本但流程状态变更应由确定性代码控制。第三人工确认界面要保留差异。系统生成摘要后医务人员或授权人员修改了哪些字段、删除了哪些内容、补充了哪些说明都应记录。第四异常路径要明确。LLM 超时、输出 JSON 解析失败、策略服务不可用、审计日志写入失败都不能让流程静默继续。医疗健康类系统宁可降级到人工处理也不应在关键日志缺失时继续自动流转。可以用下面的原则约束实现Agent 不直接输出诊断、治疗、分诊或用药建议所有风险分层和升级规则都是可配置示例需由机构确认高影响动作必须进入人工确认节点模型输出必须经过结构校验和策略校验审计日志失败时触发降级或阻断结论先做可审计的流程能力再谈更复杂的智能化Agent诊疗当前更适合做流程助手原因不是模型“不够聪明”而是诊疗系统需要清晰边界、稳定流程和可追溯责任链。把 Agent 放在信息整理、流程协同、缺失项提示和审计记录位置工程风险更可控也更容易产生实际效率收益。如果要启动类似项目建议先从一个窄流程开始定义状态机、接入 LLM 摘要、配置示例规则、建设人工确认页和审计日志。等流程质量、数据质量和机构规范都稳定后再逐步扩大 Agent 的自动化范围。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。
Agent+诊疗为什么现在更适合做流程助手，而不是诊断替代者
发布时间：2026/5/20 11:42:38
诊疗场景里的 Agent 很容易被包装成“自动诊断系统”但从工程落地看更稳妥的方向是流程助手整理信息、补齐材料、触发规则、记录过程、辅助医务人员完成复杂工作流。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议文中所有规则均为示例真实项目必须由医疗专业人员和机构规范确认。问题背景诊疗 Agent 的落点不只是模型能力医疗健康应用开发者在设计 Agent 时通常会遇到三个问题模型能否理解用户输入、系统如何控制输出边界、出了问题能否追溯责任链。诊断替代要求系统直接给出医学判断这不仅依赖模型还涉及数据完整性、机构流程、人员授权、质量控制和合规审计。相比之下流程助手的目标更明确把散落在不同系统和对话中的信息结构化把可重复的步骤自动化把需要人工确认的节点显式暴露出来。一个更合理的诊疗 Agent MVP可以先覆盖以下环节采集主诉、既往信息、检查资料等非结构化输入按机构模板生成结构化摘要检查必填字段是否缺失根据示例规则提示是否需要人工复核或升级处理记录每一步输入、模型输出、人工修改和策略命中结果这里的关键不是让 Agent “下结论”而是让它成为 workflow engine、policy engine、LLM API 和 audit log 之间的胶水层。技术目标与边界把 Agent 设计成可控节点流程助手型 Agent 的核心目标可以拆成四类。第一是状态管理。诊疗流程不是一次问答而是多轮、多角色、多系统参与的状态机。系统需要知道当前处于“信息采集”“资料核对”“摘要生成”“人工确认”还是“归档”阶段。第二是策略约束。LLM 输出天然具有不确定性因此不能把关键动作直接交给模型自由决定。升级规则、字段完整性检查、敏感输出拦截都应放在可配置的 policy engine 中。第三是人工确认。涉及诊疗相关判断的内容应进入人工确认节点。Agent 可以生成待确认摘要、列出缺失信息和冲突信息但不应绕过授权人员。第四是审计追踪。每次模型调用、提示词版本、输入数据摘要、策略命中、人工修改都要写入审计日志。没有审计链系统很难在真实环境中排查问题。一个简化架构如下User Input | v Workflow Engine | -- Data Normalizer | -- LLM API: summarize / extract / rewrite | -- Policy Engine: 示例规则校验 | -- Human Review Queue | v Audit Log Case State Store这个设计把 LLM 放在“生成和整理”位置而不是放在“最终决策”位置。对于工程团队来说这种边界更容易测试、灰度、回滚和解释。工程实现路径用状态机组织诊疗流程助手下面用 Python 写一个最小可运行示例演示如何把用户输入、LLM 摘要、示例规则和审计日志串起来。这里不会调用真实医疗系统也不会生成诊断建议只展示流程编排方式。fromdataclassesimportdataclass,fieldfromdatetimeimportdatetimefromtypingimportDict,List,AnydataclassclassAuditEvent:time:strcase_id:strstep:strdetail:Dict[str,Any]dataclassclassCaseState:case_id:strstage:strcollectingraw_text:strsummary:Dict[str,Any]field(default_factorydict)flags:List[str]field(default_factorylist)audit_logs:List[AuditEvent]field(default_factorylist)classAuditLogger:defwrite(self,state:CaseState,step:str,detail:Dict[str,Any]):state.audit_logs.append(AuditEvent(timedatetime.utcnow().isoformat(),case_idstate.case_id,stepstep,detaildetail))classMockLLMClient:defextract_summary(self,raw_text:str)-Dict[str,Any]:# 示例真实项目应替换为受控提示词、模型网关、脱敏与超时处理return{chief_complaint:raw_text[:80],history_provided:既往inraw_textor病史inraw_text,document_provided:报告inraw_textor检查inraw_text,agent_note:仅为流程整理摘要需人工确认}classPolicyEngine:defevaluate(self,summary:Dict[str,Any])-List[str]:flags[]# 示例规则真实项目应由医疗专业人员和机构规范确认ifnotsummary.get(history_provided):flags.append(缺少既往信息进入人工补充确认)# 示例规则真实项目应由医疗专业人员和机构规范确认ifnotsummary.get(document_provided):flags.append(缺少相关资料提示上传或人工核对)returnflagsclassDiagnosisWorkflowAssistant:def__init__(self):self.llmMockLLMClient()self.policyPolicyEngine()self.auditAuditLogger()defrun(self,state:CaseState,user_text:str)-CaseState:state.raw_textuser_text self.audit.write(state,input_received,{length:len(user_text)})state.summaryself.llm.extract_summary(user_text)state.stagesummarizedself.audit.write(state,summary_generated,state.summary)state.flagsself.policy.evaluate(state.summary)state.stagehuman_review_requiredifstate.flagselseready_for_reviewself.audit.write(state,policy_evaluated,{flags:state.flags})returnstateif__name____main__:workflowDiagnosisWorkflowAssistant()caseCaseState(case_idcase-20260520-0900)resultworkflow.run(case,用户描述近期不适希望整理就诊前信息。已有部分检查报告但未提供既往病史。)print(当前阶段:,result.stage)print(结构化摘要:,result.summary)print(流程提示:,result.flags)print(审计日志条数:,len(result.audit_logs))这个 Demo 的重点有三个。第一LLM 只负责摘要抽取不负责诊断判断。第二策略判断独立于 LLM可测试、可版本化、可由机构配置。第三所有关键节点都有审计日志后续可以接入 Elasticsearch、OpenSearch、ClickHouse 或对象存储。为什么流程助手比诊断替代更适合当前阶段从工程风险看诊断替代系统需要解决输入真实性、上下文完整性、模型稳定性、责任边界和持续质控。任何一个环节薄弱都会影响系统可信度。流程助手的输入输出更容易定义。例如“把用户描述转为结构化摘要”“提示缺失字段”“生成待确认清单”“记录人工修改前后差异”这些任务可以写测试用例也可以用人工标注样本评估准确率。从系统集成看医疗健康场景常常存在多个业务系统Agent 更适合做跨系统流程协调。例如从用户会话中抽取信息调用内部接口查询资料状态再把缺失项交给人工队列。这个过程中Agent 的价值来自任务编排而不是替代专业判断。从上线策略看流程助手支持渐进式发布。可以先只读不写只生成摘要不触发动作再进入人工确认模式最后对低风险、强规则的步骤做自动化。诊断替代则很难用同样方式平滑灰度因为输出本身就带有高风险决策含义。落地时要重点处理的四个工程问题第一提示词版本管理。所有 Prompt 都应有版本号并写入审计日志。模型升级、提示词调整、输出格式变化都需要可回溯。第二策略引擎不要写死在提示词里。示例规则可以由 YAML、JSON 或数据库配置并由后端服务执行。LLM 可以解释文本但流程状态变更应由确定性代码控制。第三人工确认界面要保留差异。系统生成摘要后医务人员或授权人员修改了哪些字段、删除了哪些内容、补充了哪些说明都应记录。第四异常路径要明确。LLM 超时、输出 JSON 解析失败、策略服务不可用、审计日志写入失败都不能让流程静默继续。医疗健康类系统宁可降级到人工处理也不应在关键日志缺失时继续自动流转。可以用下面的原则约束实现Agent 不直接输出诊断、治疗、分诊或用药建议所有风险分层和升级规则都是可配置示例需由机构确认高影响动作必须进入人工确认节点模型输出必须经过结构校验和策略校验审计日志失败时触发降级或阻断结论先做可审计的流程能力再谈更复杂的智能化Agent诊疗当前更适合做流程助手原因不是模型“不够聪明”而是诊疗系统需要清晰边界、稳定流程和可追溯责任链。把 Agent 放在信息整理、流程协同、缺失项提示和审计记录位置工程风险更可控也更容易产生实际效率收益。如果要启动类似项目建议先从一个窄流程开始定义状态机、接入 LLM 摘要、配置示例规则、建设人工确认页和审计日志。等流程质量、数据质量和机构规范都稳定后再逐步扩大 Agent 的自动化范围。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。
