医疗 Agentic AI 到底成熟了吗？一篇综述带你看懂架构、证据与落地路径

CSDN 发布建议：分类：人工智能、医疗科技；标签：Agentic AI、AI Agent、医疗人工智能、LLM、多智能体、临床决策支持。

本文基于 Collaco 等发表于 npj Digital Medicine 的范围综述《The role of agentic artificial intelligence in healthcare: a scoping review》整理。文中涉及的研究数量、准确率和试验结果均来自该综述；架构图、代码和落地建议是面向工程实践的二次抽象，不是论文原始实现。

摘要

“Agentic AI”正在从概念讨论进入医疗产品设计，但它和普通聊天机器人、生成式 AI、传统预测模型究竟有什么区别？现有系统是否已经可以独立做临床决策？

这篇 2026 年的范围综述给出了一个谨慎的答案：医疗 Agentic AI 已经展示出自主执行、目标驱动和主动调用工具的能力，但证据仍处在早期阶段。研究者从 PubMed、Embase、Cochrane、Scopus 和 Google Scholar 检索了 984 条记录，最终只有 7 项研究符合纳入标准；其中只有 1 项随机对照试验，且 6 项研究尚未进入真实临床工作流。

因此，当前更准确的定位不是“可以替代医生的自主系统”，而是“能够在明确边界内协同完成多步任务的临床智能组件”。

一、先把几个概念分清楚

可以把医疗 AI 看成一条从“被动计算”走向“主动协作”的连续谱：

综述采用了一个很实用的最低判定标准：一个系统至少需要同时具备以下三个特征，才纳入 Agentic AI 范畴。

1. 自主运行（Autonomous operation）：不需要人持续逐步点击或提示。
2. 目标驱动（Goal-directed behavior）：根据目标观察结果、调整策略，而不是简单响应输入。
3. 动作发起或工具调用（Action initiation / tool invocation）：可以主动调用 API、数据库、检索器或业务软件，把推理结果接入工作流。

自适应学习、长期记忆、多智能体协作和高级推理可以提高系统的“智能体程度”，但不是最低门槛。也就是说，一个单智能体系统只要具备上述三点，也可能属于 Agentic AI；反过来，采用了多智能体框架，也不代表它已经具备长期自主进化能力。

二、Agentic AI 在医疗场景中是怎样工作的

从工程视角看，一个 Agentic AI 系统通常由“目标、感知、规划、工具、验证和治理”几部分组成：

flowchart LR
    H[医生或业务人员定义目标] --> P[感知与数据整理]
    P --> R[规划器/推理器]
    R --> D{需要调用工具?}
    D -->|是| T[检索器、模型、EHR/FHIR API、计算工具]
    T --> V[结果验证与风险检查]
    V --> R
    D -->|否| A{是否需要人工批准?}
    A -->|是| C[人工复核/修改/拒绝]
    A -->|否| O[生成可执行输出]
    C --> O
    O --> L[写入审计日志并返回临床工作流]

这里有一个容易被忽略的边界：“能生成答案”不等于“能完成任务”。例如，影像模型输出“疑似肺结节”属于推理结果；如果系统还能检索既往影像、比较时间序列、调用专科模型、生成待审核报告并把任务派给指定角色，才体现了更强的 Agentic 特征。

三、综述中的 7 个代表性系统

下表将论文纳入的研究按场景压缩成一张工程师容易阅读的地图。准确率等数字是原研究报告值，不能直接理解为跨医院、跨人群的临床性能。

这些结果说明了两件事：第一，Agentic AI 已经能够把检索、推理、计算和工作流编排串起来；第二，单个原型的优秀指标并不能推出“医疗 Agentic AI 已经成熟”。

四、从研究原型到系统设计：一份最小工程骨架

下面是一段简化的 Python 伪代码，用来表达“规划 - 工具调用 - 验证 - 人工批准 - 审计”的基本控制面。它不是论文代码，也不连接真实医疗系统；真实部署必须补齐身份认证、权限控制、脱敏、故障转移和合规审查。

from dataclasses import dataclass, field
from typing import Any, Callable


@dataclass
class Action:
    tool: str
    args: dict[str, Any]
    risk: str                 # low / medium / high
    rationale: str


@dataclass
class AgentState:
    goal: str
    context: dict[str, Any]
    step: int = 0
    audit: list[dict[str, Any]] = field(default_factory=list)


def run_agent(
    state: AgentState,
    planner: Callable[[AgentState], Action | None],
    tools: dict[str, Callable[..., Any]],
    approve: Callable[[Action], bool],
    max_steps: int = 6,
) -> dict[str, Any]:
    """工程化示例：所有外部动作都经过策略检查并记录审计信息。"""
    while state.step < max_steps:
        action = planner(state)
        if action is None:
            return {"status": "done", "context": state.context,
                    "audit": state.audit}

        if action.tool not in tools:
            raise ValueError(f"unknown tool: {action.tool}")

        # 高风险动作不允许模型自行放行。
        if action.risk == "high" and not approve(action):
            state.audit.append({"step": state.step, "action": action.tool,
                                "status": "rejected"})
            return {"status": "needs_human_review", "audit": state.audit}

        result = tools[action.tool](**action.args)
        state.audit.append({"step": state.step, "action": action.tool,
                            "risk": action.risk, "status": "success"})
        state.context[f"tool_result_{state.step}"] = result
        state.step += 1

    return {"status": "max_steps_reached", "audit": state.audit}

这段骨架体现了几个重要设计原则：

• 工具白名单：代理只能调用注册过的工具，避免任意访问数据库或网络。
• 风险分级：查询病历和修改治疗计划不应使用同一套放行策略。
• 可中止：达到最大步数、异常或上下文不完整时，应停止并转人工，而不是无限循环。
• 结构化审计：记录调用了什么工具、使用了哪些参数、结果是什么、谁批准了动作。
• 输出与执行分离：模型可以生成建议，但真正改变临床数据或治疗参数的动作必须经过业务策略层。

五、为什么“准确率高”仍然不能直接上线

综述对纳入研究进行了偏倚评估：唯一的随机对照试验存在一些偏倚担忧；6 项非随机研究的总体偏倚风险从中等到严重/关键不等。常见问题包括样本量小、没有对照组、使用模拟或结构化数据，以及缺少真实临床验证。

医疗工作流还有一些 Agentic AI 特有的风险：

1. 协作失配：多个代理如果共享上下文不完整，可能产生互相矛盾的建议。
2. 幻觉与错误链路：单个错误的检索结果可能被后续代理当作事实继续放大。
3. 延迟和成本：固定、可预测的任务使用传统自动化往往更快、更容易验证。
4. 不可解释和不可审计：临床人员需要知道建议为什么产生、依据哪些数据、经过了哪些步骤。
5. 数据和安全：EHR、影像和组学数据涉及敏感个人信息，工具调用扩大了攻击面。
6. 责任边界：系统越能主动执行动作，就越需要明确谁拥有最终决策权以及如何追责。

因此，放疗剂量、用药剂量、危急值处置等高风险任务不能仅凭离线准确率放行。对这些任务，稳定的传统模型或固定规则流水线可能仍然更适合；Agentic AI 更适合那些确实需要多步推理、跨系统协调和动态计划的场景。

六、建议采用的评估指标

在开发阶段，建议把“模型能力”与“系统能力”分开评估：

特别要避免只报告“某个数据集上的准确率”。Agentic AI 的核心风险往往发生在模型输出之后：检索错了没有、工具参数对不对、计划是否越权、失败后是否及时停机，这些都应进入验收标准。

七、面向医院和研发团队的渐进式落地路径

结合综述提出的“从概念验证走向真实临床环境”的方向，可以采用以下顺序：

1. 影子模式：系统只读数据并生成建议，不影响现有决策；先收集错误类型、延迟和人工修改记录。
2. 只读协作：允许调用检索、计算和报告草拟工具，但禁止写回关键临床字段。
3. 强制人工批准：对分诊、告警升级、治疗计划等动作设置明确的审批点和回退方案。
4. 低风险自动化：在边界清晰、可逆、容易监控的任务中扩大自主范围。
5. 多中心验证：使用真实世界数据、较长随访和不同人群，评估模型漂移与泛化能力。

基础设施方面，综述特别提到遗留 EHR、GPU 能力不足和数据管道碎片化是常见阻碍。FHIR API、混合云或边缘计算、联邦学习、数据匿名化和差分隐私，都是值得在架构阶段预留的能力。对于高风险或自适应系统，还需要结合适用的医疗器械监管、隐私法规和变更控制机制；不能把“模型自动更新”当成普通软件发布。

结语

这篇综述最有价值的地方，不是证明 Agentic AI 在医疗领域已经成功，而是帮我们划清了现阶段的边界：它已经能做自主规划、工具调用和多代理协作，但绝大多数证据仍来自小样本、模拟环境或计算实验。

真正可用的医疗 Agentic AI，需要同时满足三条线：技术上能完成多步任务，临床上能在真实人群中带来可重复的收益，治理上能让每次行动都可解释、可审计、可撤销。对研发团队来说，优先建设风险分级、人工接管、审计日志和持续监测，往往比继续堆叠更多代理更重要。

参考文献：Collaco BG, et al. The role of agentic artificial intelligence in healthcare: a scoping review. npj Digital Medicine, 2026, 9:345. DOI: 10.1038/s41746-026-02517-5

本文仅用于技术交流，不构成医疗建议，也不应作为临床决策依据。