医疗 Agent 落地时开发者最容易低估的不是模型调用而是人工介入点、审批链路、审计日志和异常回退。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议文中所有阈值、风险分层和升级规则均为示例真实项目必须由医疗专业人员和机构规范确认。问题背景为什么全自动 Agent 在医疗场景很容易失控在普通办公自动化里Agent 自动读取输入、调用工具、生成结果、执行动作通常可以通过“失败重试”解决大部分问题。但医疗健康相关系统面对的是更高敏感度的数据、更复杂的责任边界以及更严格的留痕要求。以“医学资料整理 Agent”为例它可能要完成资料读取、术语标准化、摘要生成、风险提示、人工确认、结果归档等步骤。模型可以提升处理效率但不应该默认拥有最终执行权。尤其当输出会影响后续人工判断、科研记录或业务流程时系统必须知道什么时候停下来等待人。一个更稳妥的医疗 Agent不是把人排除在流程外而是把人设计进流程里。技术目标把 Human-in-the-loop 做成系统能力Human-in-the-loop 不应只是页面上加一个“确认”按钮而应该成为工作流引擎中的一类状态。建议至少满足四个目标。第一流程可暂停。Agent 遇到不确定、高风险或规则冲突时可以进入WAITING_APPROVAL状态而不是继续自动执行。第二审批可追踪。谁在什么时候看到了什么输入、模型给出了什么建议、人工如何修改都要进入审计日志。第三结果可回退。人工驳回后流程应支持重新生成、切换模型、降级到规则流程或者终止任务。第四行为可观测。系统需要监控待审批堆积量、平均审批时长、模型输出被修改比例、异常升级次数等指标。一个简化架构可以表示为User Request | Workflow Engine | Agent Planner ---- Tool Executor | Risk Evaluator | ---------------------- | approval required ? | ---------------------- | yes | no Approval Queue Auto Continue | Human Reviewer | Approve / Revise / Reject | Audit Log Result Store工作流设计人工介入点应该放在哪里人工介入点不是越多越安全。过多审批会让系统变慢开发者最后可能绕开流程过少审批又会把责任压给模型。比较实用的做法是按流程节点设置“可配置拦截器”。常见介入点包括输入阶段用户上传资料是否包含敏感信息是否缺少必要上下文。计划阶段Agent 是否选择了高影响动作例如写入正式记录或触发外部系统。生成阶段输出是否包含不确定表述、引用缺失、与规则冲突的内容。执行阶段是否需要人工确认后才能归档、发送或同步。异常阶段工具调用失败、模型响应超时、结果置信度不足时进入人工队列。这里的关键是把“是否需要人工介入”做成策略而不是写死在业务代码里。策略可以来自机构规则、用户角色、任务类型、数据敏感度和模型输出特征。一个最小可运行的审批队列示例下面用 Python 写一个极简示例演示 Agent 任务如何在工作流中暂停、进入审批队列并记录审计日志。代码只展示工程机制不包含任何医学判断逻辑。fromdataclassesimportdataclass,fieldfromenumimportEnumfromdatetimeimportdatetimefromtypingimportList,Dict,OptionalimportuuidclassTaskStatus(str,Enum):RUNNINGRUNNINGWAITING_APPROVALWAITING_APPROVALAPPROVEDAPPROVEDREJECTEDREJECTEDCOMPLETEDCOMPLETEDdataclassclassAgentTask:task_id:struser_id:strtask_type:strinput_text:strdraft_output:Optional[str]Nonestatus:TaskStatusTaskStatus.RUNNING risk_score:float0.0audit_logs:List[Dict]field(default_factorylist)classApprovalQueue:def__init__(self):self.queue:Dict[str,AgentTask]{}defsubmit(self,task:AgentTask):task.statusTaskStatus.WAITING_APPROVAL self.queue[task.task_id]task self._audit(task,SYSTEM,SUBMIT_APPROVAL,{risk_score:task.risk_score})defreview(self,task_id:str,reviewer:str,decision:str,comment:str):taskself.queue.get(task_id)ifnottask:raiseValueError(task not found in approval queue)ifdecisionapprove:task.statusTaskStatus.APPROVEDelifdecisionreject:task.statusTaskStatus.REJECTEDelse:raiseValueError(decision must be approve or reject)self._audit(task,reviewer,decision.upper(),{comment:comment})returntaskdef_audit(self,task:AgentTask,actor:str,action:str,detail:Dict):task.audit_logs.append({time:datetime.utcnow().isoformat(),actor:actor,action:action,detail:detail})defmock_agent_generate(input_text:str)-str:returnf根据输入资料生成的结构化摘要草稿{input_text[:40]}...defevaluate_risk(task_type:str,draft_output:str)-float:score0.2iftask_typein[external_sync,formal_record]:score0.5if不确定indraft_outputor需要确认indraft_output:score0.3returnmin(score,1.0)defrun_workflow(user_id:str,task_type:str,input_text:str):taskAgentTask(task_idstr(uuid.uuid4()),user_iduser_id,task_typetask_type,input_textinput_text)task.draft_outputmock_agent_generate(input_text)task.risk_scoreevaluate_risk(task.task_type,task.draft_output)approval_queueApprovalQueue()# 示例规则风险分超过 0.6 时进入人工审批# 真实项目应由医疗专业人员和机构规范确认规则iftask.risk_score0.6:approval_queue.submit(task)returntask,approval_queue task.statusTaskStatus.COMPLETEDreturntask,approval_queueif__name____main__:task,queuerun_workflow(user_idu001,task_typeformal_record,input_text用户提交了一段需要整理的医学资料文本)print(task.status)print(task.risk_score)iftask.statusTaskStatus.WAITING_APPROVAL:reviewedqueue.review(task.task_id,reviewerreviewer_01,decisionapprove,comment示例审批通过)print(reviewed.status)print(reviewed.audit_logs)这个示例里evaluate_risk只是占位规则不能被理解为医疗风险判断。真实系统应把规则引擎、权限系统、机构配置和人工复核流程分离避免把关键规则散落在 Agent 提示词或业务分支中。审计日志不要只记录最终答案医疗 Agent 的审计日志建议至少覆盖五类信息。第一类是输入快照包括任务类型、用户角色、数据来源和脱敏状态。第二类是模型行为包括模型版本、提示词版本、工具调用参数和生成时间。第三类是策略判断包括命中的审批规则、示例风险分、是否升级人工。第四类是人工操作包括审批人、修改内容、驳回原因。第五类是系统状态包括重试、超时、降级和异常堆栈。审计日志的设计原则是“能复盘”。当用户质疑结果、内部排查异常或系统升级模型版本时团队需要知道当时发生了什么而不是只能看到一个最终文本。回退机制审批不是终点驳回后要能继续流转人工审批的常见误区是只设计通过路径没有设计驳回路径。实际项目中驳回原因可能包括输入不足、生成内容偏离任务、引用缺失、格式不符合要求、需要补充资料等。建议为驳回设置明确状态机WAITING_APPROVAL | -- APPROVED - CONTINUE_EXECUTION | -- REJECTED - REGENERATE / REQUEST_MORE_INPUT / TERMINATE | -- REVISED - HUMAN_EDITED_RESULT - CONTINUE_EXECUTION如果人工只是轻微修改可以将状态标记为REVISED并记录修改差异。如果问题较大则进入重新生成或补充输入。对于连续失败的任务应触发降级策略例如转为人工处理队列而不是让 Agent 无限重试。可观测性用指标判断人机协同是否有效Human-in-the-loop 会引入等待时间因此需要监控它是否真的提升了系统质量。建议从工程侧观察以下指标。审批队列长度可以反映人工资源是否不足。平均审批时长可以判断流程是否卡顿。模型输出被修改比例可以反映生成质量和提示词稳定性。驳回率可以暴露任务定义不清或工具调用错误。高风险任务自动通过率则用于检查策略是否过松。这些指标不能直接代表医学质量但能帮助研发团队发现流程瓶颈。更进一步可以按任务类型、模型版本、审批规则版本进行分组分析定位是哪一类任务最容易触发人工介入。取舍分析什么时候自动什么时候停下来医疗 Agent 的架构重点不是拒绝自动化而是控制自动化边界。低影响、可重复、可撤销的任务适合自动执行例如格式转换、字段提取、草稿生成、重复性校验。高影响、不可轻易撤销、涉及正式记录或外部同步的任务更适合设置人工确认。在工程实现上可以采用三层策略默认自动低风险任务直接完成但仍保留日志。条件审批命中示例规则后进入审批队列。强制人工特定任务类型始终需要人工确认。这种分层能让系统既有吞吐量又不会把所有责任交给模型。对于医疗健康相关项目最终规则应由专业人员、合规要求和机构流程共同确认。结论医疗 Agent 的产品力会体现在流程设计里医疗 Agent 的落地难点正在从“能不能调用大模型”转向“能不能把模型放进可靠流程”。Human-in-the-loop 不是阻碍自动化而是让自动化具备可控边界、责任链路和复盘能力。如果你正在设计医疗健康相关 Agent建议先画出状态机再写模型提示词先定义审批、审计和回退再追求更高的自动执行率。下一步可以把审批策略配置化引入工作流引擎、规则引擎和可观测性看板让人机协同成为系统的基础能力。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。
医疗 Agent 的价值会越来越取决于 Human-in-the-loop 设计，而不是盲目追求全自动
医疗 Agent 落地时开发者最容易低估的不是模型调用而是人工介入点、审批链路、审计日志和异常回退。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议文中所有阈值、风险分层和升级规则均为示例真实项目必须由医疗专业人员和机构规范确认。问题背景为什么全自动 Agent 在医疗场景很容易失控在普通办公自动化里Agent 自动读取输入、调用工具、生成结果、执行动作通常可以通过“失败重试”解决大部分问题。但医疗健康相关系统面对的是更高敏感度的数据、更复杂的责任边界以及更严格的留痕要求。以“医学资料整理 Agent”为例它可能要完成资料读取、术语标准化、摘要生成、风险提示、人工确认、结果归档等步骤。模型可以提升处理效率但不应该默认拥有最终执行权。尤其当输出会影响后续人工判断、科研记录或业务流程时系统必须知道什么时候停下来等待人。一个更稳妥的医疗 Agent不是把人排除在流程外而是把人设计进流程里。技术目标把 Human-in-the-loop 做成系统能力Human-in-the-loop 不应只是页面上加一个“确认”按钮而应该成为工作流引擎中的一类状态。建议至少满足四个目标。第一流程可暂停。Agent 遇到不确定、高风险或规则冲突时可以进入WAITING_APPROVAL状态而不是继续自动执行。第二审批可追踪。谁在什么时候看到了什么输入、模型给出了什么建议、人工如何修改都要进入审计日志。第三结果可回退。人工驳回后流程应支持重新生成、切换模型、降级到规则流程或者终止任务。第四行为可观测。系统需要监控待审批堆积量、平均审批时长、模型输出被修改比例、异常升级次数等指标。一个简化架构可以表示为User Request | Workflow Engine | Agent Planner ---- Tool Executor | Risk Evaluator | ---------------------- | approval required ? | ---------------------- | yes | no Approval Queue Auto Continue | Human Reviewer | Approve / Revise / Reject | Audit Log Result Store工作流设计人工介入点应该放在哪里人工介入点不是越多越安全。过多审批会让系统变慢开发者最后可能绕开流程过少审批又会把责任压给模型。比较实用的做法是按流程节点设置“可配置拦截器”。常见介入点包括输入阶段用户上传资料是否包含敏感信息是否缺少必要上下文。计划阶段Agent 是否选择了高影响动作例如写入正式记录或触发外部系统。生成阶段输出是否包含不确定表述、引用缺失、与规则冲突的内容。执行阶段是否需要人工确认后才能归档、发送或同步。异常阶段工具调用失败、模型响应超时、结果置信度不足时进入人工队列。这里的关键是把“是否需要人工介入”做成策略而不是写死在业务代码里。策略可以来自机构规则、用户角色、任务类型、数据敏感度和模型输出特征。一个最小可运行的审批队列示例下面用 Python 写一个极简示例演示 Agent 任务如何在工作流中暂停、进入审批队列并记录审计日志。代码只展示工程机制不包含任何医学判断逻辑。fromdataclassesimportdataclass,fieldfromenumimportEnumfromdatetimeimportdatetimefromtypingimportList,Dict,OptionalimportuuidclassTaskStatus(str,Enum):RUNNINGRUNNINGWAITING_APPROVALWAITING_APPROVALAPPROVEDAPPROVEDREJECTEDREJECTEDCOMPLETEDCOMPLETEDdataclassclassAgentTask:task_id:struser_id:strtask_type:strinput_text:strdraft_output:Optional[str]Nonestatus:TaskStatusTaskStatus.RUNNING risk_score:float0.0audit_logs:List[Dict]field(default_factorylist)classApprovalQueue:def__init__(self):self.queue:Dict[str,AgentTask]{}defsubmit(self,task:AgentTask):task.statusTaskStatus.WAITING_APPROVAL self.queue[task.task_id]task self._audit(task,SYSTEM,SUBMIT_APPROVAL,{risk_score:task.risk_score})defreview(self,task_id:str,reviewer:str,decision:str,comment:str):taskself.queue.get(task_id)ifnottask:raiseValueError(task not found in approval queue)ifdecisionapprove:task.statusTaskStatus.APPROVEDelifdecisionreject:task.statusTaskStatus.REJECTEDelse:raiseValueError(decision must be approve or reject)self._audit(task,reviewer,decision.upper(),{comment:comment})returntaskdef_audit(self,task:AgentTask,actor:str,action:str,detail:Dict):task.audit_logs.append({time:datetime.utcnow().isoformat(),actor:actor,action:action,detail:detail})defmock_agent_generate(input_text:str)-str:returnf根据输入资料生成的结构化摘要草稿{input_text[:40]}...defevaluate_risk(task_type:str,draft_output:str)-float:score0.2iftask_typein[external_sync,formal_record]:score0.5if不确定indraft_outputor需要确认indraft_output:score0.3returnmin(score,1.0)defrun_workflow(user_id:str,task_type:str,input_text:str):taskAgentTask(task_idstr(uuid.uuid4()),user_iduser_id,task_typetask_type,input_textinput_text)task.draft_outputmock_agent_generate(input_text)task.risk_scoreevaluate_risk(task.task_type,task.draft_output)approval_queueApprovalQueue()# 示例规则风险分超过 0.6 时进入人工审批# 真实项目应由医疗专业人员和机构规范确认规则iftask.risk_score0.6:approval_queue.submit(task)returntask,approval_queue task.statusTaskStatus.COMPLETEDreturntask,approval_queueif__name____main__:task,queuerun_workflow(user_idu001,task_typeformal_record,input_text用户提交了一段需要整理的医学资料文本)print(task.status)print(task.risk_score)iftask.statusTaskStatus.WAITING_APPROVAL:reviewedqueue.review(task.task_id,reviewerreviewer_01,decisionapprove,comment示例审批通过)print(reviewed.status)print(reviewed.audit_logs)这个示例里evaluate_risk只是占位规则不能被理解为医疗风险判断。真实系统应把规则引擎、权限系统、机构配置和人工复核流程分离避免把关键规则散落在 Agent 提示词或业务分支中。审计日志不要只记录最终答案医疗 Agent 的审计日志建议至少覆盖五类信息。第一类是输入快照包括任务类型、用户角色、数据来源和脱敏状态。第二类是模型行为包括模型版本、提示词版本、工具调用参数和生成时间。第三类是策略判断包括命中的审批规则、示例风险分、是否升级人工。第四类是人工操作包括审批人、修改内容、驳回原因。第五类是系统状态包括重试、超时、降级和异常堆栈。审计日志的设计原则是“能复盘”。当用户质疑结果、内部排查异常或系统升级模型版本时团队需要知道当时发生了什么而不是只能看到一个最终文本。回退机制审批不是终点驳回后要能继续流转人工审批的常见误区是只设计通过路径没有设计驳回路径。实际项目中驳回原因可能包括输入不足、生成内容偏离任务、引用缺失、格式不符合要求、需要补充资料等。建议为驳回设置明确状态机WAITING_APPROVAL | -- APPROVED - CONTINUE_EXECUTION | -- REJECTED - REGENERATE / REQUEST_MORE_INPUT / TERMINATE | -- REVISED - HUMAN_EDITED_RESULT - CONTINUE_EXECUTION如果人工只是轻微修改可以将状态标记为REVISED并记录修改差异。如果问题较大则进入重新生成或补充输入。对于连续失败的任务应触发降级策略例如转为人工处理队列而不是让 Agent 无限重试。可观测性用指标判断人机协同是否有效Human-in-the-loop 会引入等待时间因此需要监控它是否真的提升了系统质量。建议从工程侧观察以下指标。审批队列长度可以反映人工资源是否不足。平均审批时长可以判断流程是否卡顿。模型输出被修改比例可以反映生成质量和提示词稳定性。驳回率可以暴露任务定义不清或工具调用错误。高风险任务自动通过率则用于检查策略是否过松。这些指标不能直接代表医学质量但能帮助研发团队发现流程瓶颈。更进一步可以按任务类型、模型版本、审批规则版本进行分组分析定位是哪一类任务最容易触发人工介入。取舍分析什么时候自动什么时候停下来医疗 Agent 的架构重点不是拒绝自动化而是控制自动化边界。低影响、可重复、可撤销的任务适合自动执行例如格式转换、字段提取、草稿生成、重复性校验。高影响、不可轻易撤销、涉及正式记录或外部同步的任务更适合设置人工确认。在工程实现上可以采用三层策略默认自动低风险任务直接完成但仍保留日志。条件审批命中示例规则后进入审批队列。强制人工特定任务类型始终需要人工确认。这种分层能让系统既有吞吐量又不会把所有责任交给模型。对于医疗健康相关项目最终规则应由专业人员、合规要求和机构流程共同确认。结论医疗 Agent 的产品力会体现在流程设计里医疗 Agent 的落地难点正在从“能不能调用大模型”转向“能不能把模型放进可靠流程”。Human-in-the-loop 不是阻碍自动化而是让自动化具备可控边界、责任链路和复盘能力。如果你正在设计医疗健康相关 Agent建议先画出状态机再写模型提示词先定义审批、审计和回退再追求更高的自动执行率。下一步可以把审批策略配置化引入工作流引擎、规则引擎和可观测性看板让人机协同成为系统的基础能力。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。
