医疗 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):RUNNING="RUNNING"WAITING_APPROVAL="WAITING_APPROVAL"APPROVED="APPROVED"REJECTED="REJECTED"COMPLETED="COMPLETED"@dataclassclassAgentTask:task_id:struser_id:strtask_type:strinput_text:strdraft_output:Optional[str]=Nonestatus:TaskStatus=TaskStatus.RUNNING risk_score:float=0.0audit_logs:List[Dict]=field(default_factory=list)classApprovalQueue:def__init__(self):self.queue:Dict[str,AgentTask]={}defsubmit(self,task:AgentTask):task.status=TaskStatus.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):task=self.queue.get(task_id)ifnottask:raiseValueError("task not found in approval queue")ifdecision=="approve":task.status=TaskStatus.APPROVEDelifdecision=="reject":task.status=TaskStatus.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:score=0.2iftask_typein["external_sync","formal_record"]:score+=0.5if"不确定"indraft_outputor"需要确认"indraft_output:score+=0.3returnmin(score,1.0)defrun_workflow(user_id:str,task_type:str,input_text:str):task=AgentTask(task_id=str(uuid.uuid4()),user_id=user_id,task_type=task_type,input_text=input_text)task.draft_output=mock_agent_generate(input_text)task.risk_score=evaluate_risk(task.task_type,task.draft_output)approval_queue=ApprovalQueue()# 示例规则：风险分超过 0.6 时进入人工审批# 真实项目应由医疗专业人员和机构规范确认规则iftask.risk_score>=0.6:approval_queue.submit(task)returntask,approval_queue task.status=TaskStatus.COMPLETEDreturntask,approval_queueif__name__=="__main__":task,queue=run_workflow(user_id="u001",task_type="formal_record",input_text="用户提交了一段需要整理的医学资料文本")print(task.status)print(task.risk_score)iftask.status==TaskStatus.WAITING_APPROVAL:reviewed=queue.review(task.task_id,reviewer="reviewer_01",decision="approve",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文档翻译】。