1. 项目概述：当Agentic AI遇见医疗健康

最近和几位在医疗科技领域深耕的朋友交流，大家不约而同地提到了一个词：Agentic AI。这个词在技术社区里热度很高，但真正把它落地到像医疗这样高门槛、高风险的垂直领域，挑战和机遇都异常鲜明。作为一个长期关注提示工程与系统架构的从业者，我恰好深度参与了一个探索Agentic AI在医疗健康领域应用潜力的研究项目。这个项目不是要打造一个颠覆性的诊断工具，而是聚焦于一个更基础、也更关键的问题：如何构建一个能够理解复杂医疗语境、安全合规地组织信息，并最终提供个性化健康建议的智能体系统架构。

简单来说，我们研究的核心是“生态影响”，这包括了技术栈的选型、数据流的合规设计、提示工程的特殊化处理，以及最终系统与现有医疗工作流、患者体验乃至行业规范产生的互动与改变。医疗领域的数据敏感、决策责任重大、专业术语壁垒高，这些特性决定了通用的AI智能体框架在这里几乎寸步难行。我们的工作，就是从提示工程架构师的角度出发，拆解这些挑战，并设计一套可落地、可评估的解决方案。如果你对如何将前沿的AI能力安全、有效地注入到严肃行业感兴趣，或者你正在面临类似的多模态、高合规性系统设计难题，那么这次案例分享中的思路、踩过的坑和验证过的模式，或许能给你带来一些直接的参考。

2. 核心架构设计思路：从“提示”到“上下文工程”的跃迁

当我们谈论医疗领域的AI时，第一个跳出来的约束词往往是“安全”和“合规”。这直接影响了我们的架构起点。传统的提示工程（Prompt Engineering）往往侧重于单次交互中如何“问得好”，让大模型“答得准”。但在医疗场景下，单点精准远远不够。一个关于“胸痛”的查询，其背后需要的上下文可能包括用户过往的心电图历史、最近的血脂报告、家族病史、甚至生活作息变化。因此，我们的架构核心思想发生了根本转变：从优化单次提示（Prompt），升级为设计持续、动态、结构化的上下文工程（Context Engineering）。

2.1 为什么是“上下文工程”而非“提示工程”？

在医疗健康领域，信息是高度关联且随时间演进的。一个孤立的症状描述价值有限。我们的系统需要像一个经验丰富的全科医生一样，具备“病历思维”，能够主动关联和调用相关的历史信息。这就是上下文工程要解决的问题：它是一套系统化的方法，用于采集、筛选、组织、更新和注入与大模型交互相关的背景信息。

例如，当用户询问“我最近头晕，可能是什么原因？”时，一个基于简单提示工程的系统可能会直接基于这句话生成一些可能性。而我们的上下文工程驱动系统则会自动执行以下动作：1）检索用户档案中是否有高血压、低血糖病史；2）检查最近是否有记录新的用药（尤其是可能引起眩晕的）；3）关联用户最近一周的睡眠和运动数据；4）甚至询问一两个关键补充问题（如“头晕是突然发作还是持续性的？”）。所有这些动作，都是为了在最终向大模型发起请求前，构建一个丰满、相关、结构化的“上下文包”。这个“上下文包”与核心问题一起，构成了真正有效的“超级提示”。这种设计，使得AI智能体具备了初步的“主动思考”和“信息关联”能力，这正是Agentic AI中“Agentic”（能动性）的体现。

2.2 系统分层架构解析

为了实现上述思路，我们设计了一个清晰的分层架构，将责任分离，让每一层专注解决一类问题。

第一层：数据接入与标准化层。这是所有工作的基石。医疗数据来源五花八门：可穿戴设备（心率、步数）、电子健康记录（EHR）系统的结构化数据（化验单）、用户手动输入的非结构化文本（症状描述）、甚至影像报告。这一层的核心任务是“翻译”和“清洗”。我们为每种数据源定义了适配器（Adapter），将原始数据转换为统一的内部数据模型（Schema）。例如，将不同品牌手环的“心率异常”警报，映射为标准化的“心血管事件-心动过速-轻度”事件对象，并附带时间戳、置信度和数据源标签。标准化是后续所有智能操作的前提。

第二层：上下文构建与管理层。这是系统的“大脑”所在，也是上下文工程的核心。它接收标准化后的数据流，并维护一个动态的“患者上下文图谱”。这个图谱不是简单的数据堆砌，而是一个基于医学知识本体（例如SNOMED CT、ICD编码的简化子集）的关联网络。节点代表实体（如“患者”、“药物阿司匹林”、“诊断高血压”），边代表关系（如“服用”、“导致”、“伴有”）。当新数据流入时，系统会尝试将其与图谱中的现有节点进行链接，更新关系强度或创建新节点。这一层还负责根据当前对话意图（由意图识别模块提供），从庞大的图谱中裁剪出最相关的一个子图，作为本次交互的“上下文切片”。这个过程需要复杂的相关性排序和隐私过滤算法。

第三层：智能体协调与提示组装层。这一层承载具体的任务执行逻辑。它包含多个 specialized 的智能体（Agent），例如“诊断推理Agent”、“用药咨询Agent”、“生活方式建议Agent”。协调器（Orchestrator）根据用户query的意图，分派给一个或多个智能体执行。每个智能体收到任务和“上下文切片”后，会依据其预设的“思维链”（Chain-of-Thought）模板，将结构化上下文、医学知识规则（硬约束）和用户问题，组装成一个最终发送给大语言模型（LLM）的精密提示。这里的提示工程，体现在为每个智能体设计高效、可靠、抗提示注入的模板上。

第四层：大模型接口与安全护栏层。这一层是实际调用LLM API的地方。除了常规的调用，更重要的是集成了一系列“安全护栏”（Safety Guardrails）。这些护栏包括：输出格式验证（确保回答是JSON格式的建议列表，而非自由文本诊断）、内容安全过滤（过滤掉任何提供具体剂量或绝对化诊断的表述）、引用溯源（要求LLM将其推论关联到上下文图谱中的具体数据点）。任何不符合护栏规则的输出都会被拦截，触发重试或降级到人工审核流程。

第五层：输出生成与行动层。将LLM返回的结构化建议，转化为用户友好的自然语言、可视化图表（如趋势图），或生成具体的行动项（如“建议预约心内科门诊，并携带最近三个月的心电图报告”）。对于某些闭环场景，还可以触发预定义的工作流，如生成一份标准的健康报告草稿。

这个分层架构的关键优势在于解耦和可审计。数据流清晰，每一层的输入输出都可以被记录和检查，这对于满足医疗行业的合规性要求（如可解释性）至关重要。

3. 关键技术实现细节与实操要点

有了架构蓝图，接下来就是填充血肉。在这个过程中，几个关键技术的选型和实现细节决定了系统的成败。

3.1 医疗知识本体与上下文图谱的构建

我们并没有从头构建一个完整的医学知识图谱，那是一个浩大的工程。相反，我们采用了“轻量本体+数据驱动扩展”的策略。

• 轻量本体：我们选取了SNOMED CT中与常见慢性病（如高血压、糖尿病）、常用药物、常见症状和实验室检查相关的核心概念，构建了一个包含约5000个节点和十几类关系（如is_a，caused_by，treated_by）的本体库。这为数据标准化和关联提供了基础框架。
• 数据驱动扩展：系统在运行中，会自动识别用户数据中频繁出现但未在本体中定义的术语（通过LLM进行术语归一化识别），并将其暂存为“候选节点”。定期由医学背景的专家进行审核，决定是否将其正式纳入本体，或映射到现有节点。这使得系统能适应用户群体的特定习惯用语。

图谱的存储和查询我们选择了Neo4j图数据库。它的Cypher查询语言非常直观，能高效地表达诸如“查找用户所有服用中的、可能与头晕副作用相关的药物”这样的复杂关联查询。一个简单的查询示例如下：

MATCH (p:Patient {id: $userId})-[:TAKES]->(m:Medication) MATCH (m)-[:HAS_SIDE_EFFECT]->(se:SideEffect) WHERE se.name CONTAINS 'dizziness' OR se.name CONTAINS 'vertigo' RETURN m.name, se.name, se.frequency

这种查询能力，是传统关系型数据库难以简洁实现的，它为上下文切片提供了强大的支撑。

3.2 动态上下文切片与相关性计算

这是上下文工程中最具挑战性的部分。当用户问“我的血糖控制得怎么样？”时，系统需要从图谱中提取所有与“血糖”相关的信息：近期的血糖测量值、糖化血红蛋白（HbA1c）记录、相关的饮食和运动记录、当前使用的降糖药等。但同时，不能无脑地塞入所有历史数据，需要判断哪些是“相关”的。

我们的策略是“多信号融合排序”：

1. 语义相关性：使用嵌入模型（如text-embedding-ada-002）将用户query和图谱中每个实体的描述文本转化为向量，计算余弦相似度。
2. 时间衰减性：医疗信息具有时效性。一周前的血糖值比一年前的更重要。我们设计了一个指数衰减函数，给近期数据更高的权重。
3. 医学路径相关性：基于临床指南，定义强关联关系。例如，当query关于“血糖”时，“胰岛素”和“碳水化合物摄入”的权重会被预先调高。
4. 用户交互反馈：如果用户曾对某类信息（如“运动数据”）表示过“不重要”，则在后续相关query中降低其权重。

最终，每个候选实体会得到一个综合得分，我们选取Top-K个实体及其关联边，构成本次交互的上下文切片。这个切片会以结构化的形式（如JSON或特定格式的文本）传递给下游的智能体。

3.3 智能体提示模板设计与思维链引导

每个智能体都有一个精心设计的提示模板，这是提示工程技艺的集中体现。模板不仅仅是静态文本，而是包含变量插值、条件逻辑和思维链引导的“程序”。

以“生活方式建议Agent”为例，其提示模板的核心结构如下：

你是一位专业的健康管理师。请基于以下用户健康上下文，为用户提供具体、可操作的生活方式改进建议。 ## 用户健康上下文 {context_slice_json_summary} ## 用户当前问题 {user_query} ## 你的任务与约束 1. 你的建议必须严格基于上述上下文，不得虚构上下文不存在的信息。 2. 建议需聚焦在饮食、运动、睡眠、压力管理这四个方面。 3. 每条建议必须具体。例如，不应说“多运动”，而应说“建议每周进行至少150分钟的中等强度有氧运动，如快走或游泳，可分5次进行”。 4. 每条建议需注明其依据的来源上下文（例如：“根据您过去一周平均睡眠不足6小时的情况...”）。 5. 绝对禁止提供任何具体的药物剂量调整建议。若涉及用药，一律建议“咨询医生或药师”。 6. 输出格式为JSON数组，每个对象包含“area”（领域）、“suggestion”（建议）、“rationale”（依据）三个字段。 ## 请按以下步骤思考（此部分为思维链，可帮助模型推理）： 步骤一：分析上下文，识别与生活方式相关的关键健康指标和风险因素（如BMI超标、睡眠时间短、压力自评高）。 步骤二：将每个风险因素映射到饮食、运动、睡眠、压力管理的具体改进方向上。 步骤三：为每个改进方向构思1-2条最紧迫、最可行的具体行动建议。 步骤四：为每条建议在上下文中找到支持性数据点作为依据。 步骤五：将上述结果按要求的JSON格式组织输出。

这个模板融合了角色设定、上下文注入、任务指令、硬性约束、输出格式规范和思维链引导。其中，思维链（Chain-of-Thought）的加入，能显著提升大模型推理的可靠性和一致性，尤其对于需要多步逻辑推导的医疗建议生成至关重要。

实操心得：提示模板不是一蹴而就的。我们采用了“编写-测试-迭代”的循环。我们会准备一批覆盖典型和边缘场景的测试用例，用不同的模板变体进行测试，评估输出的安全性、相关性和实用性。评估不仅靠人工，也引入了自动化指标，如“约束违反率”（输出中违反硬性约束的比例）和“引用准确率”（模型声称的依据是否真实存在于上下文中）。

4. 安全、合规与评估体系的构建

在医疗领域，没有安全和合规，一切技术都是空中楼阁。我们将这两者内嵌到了系统设计的每一个环节。

4.1 多层次安全护栏设计

安全护栏是系统的“免疫系统”，我们将其分为三层：

• 输入层护栏：对用户输入进行敏感词过滤和意图分类。识别出诸如“帮我开点止痛药”、“我是不是得了癌症”这类高风险查询，直接引导至标准话术（如“关于药物和诊断，请务必咨询专业医生”），或转入人工客服通道。
• 处理层护栏：在智能体调用LLM前后设置检查点。调用前，对组装好的提示进行扫描，确保没有意外的提示注入或隐私泄露（如不小心插入了其他用户的信息）。调用后，对LLM的输出进行严格解析和验证：
  • 格式验证：是否符合预定义的JSON Schema？
  • 内容安全过滤：是否包含了绝对化的诊断词（如“你就是得了XX病”）？是否出现了具体的药物剂量和用法？是否做出了无法由上下文支持的推断？
  • 溯源验证：输出中声称的“依据”，是否能在提供的上下文切片中找到对应的数据点？我们开发了一个简单的字符串匹配和语义相似度结合的方法来验证这一点。
• 输出层护栏：最终向用户呈现信息前，在所有生成文本的显著位置添加固定免责声明，例如“本建议基于您提供的信息生成，不能替代专业医疗诊断和治疗方案，请谨慎参考，如有疑问请咨询医生。”

4.2 数据隐私与合规性考量

我们严格遵循“数据最小化”和“目的限定”原则。

• 匿名化与假名化：所有用于模型训练和推理的用户数据，在进入系统处理管道前，都会进行去标识化处理。用户ID被替换为系统内部的假名ID。
• 本地化处理与联邦学习探索：对于涉及核心健康数据的推理，我们探索了模型轻量化并在可信边缘设备（如医院内部服务器）运行的可能性，避免原始数据传出。对于需要聚合数据优化模型的场景，则研究采用联邦学习框架，让模型参数移动而非数据移动。
• 完整的审计日志：系统记录每一次用户交互的完整链路：原始输入、构建的上下文切片、发送给LLM的提示、LLM的原始回复、安全护栏的检查结果、最终输出。这为事后追溯、责任界定和系统优化提供了不可篡改的依据。

4.3 如何评估一个医疗AI智能体的好坏？

评估是迭代的指南针。我们建立了多维度的评估体系，分为离线评估和在线评估。

• 离线评估（技术效能）：
  • 上下文检索准确率：人工标注一批query对应的“理想上下文”，评估系统自动构建的上下文切片与“理想上下文”的重合度（采用F1分数）。
  • 建议安全性与合规性：使用包含大量边界案例的测试集，统计输出违反安全护栏的比例。
  • 建议临床合理性：聘请医学专家组成评审小组，对系统输出的建议进行盲审打分（1-5分），评估其医学上的合理性和实用性。
• 在线评估（用户体验与影响）：
  • 用户满意度调查（CSAT）：在交互后推送简短的评分。
  • 行为转化率：系统给出的建议（如“记录一周饮食”），用户后续是否真的在App中执行了相关操作？
  • A/B测试：对比使用智能体建议的用户组和对照组（接收通用健康资讯），在长期健康指标自我报告改善率、用户留存率等关键指标上是否有显著正向差异。

这套评估体系让我们能客观地衡量系统价值，而非仅仅停留在技术炫技层面。我们发现，初期用户对“个性化”和“关联上下文”的能力感知最强，满意度提升明显；而长期留存则更依赖于建议的“可操作性”和“实际带来的健康益处感知”。

5. 项目实施中的挑战与实战心得

回顾整个项目，从技术验证到原型开发，再到小范围试点，一路走来挑战重重，也积累了不少实战经验。

挑战一：医疗数据的“脏”与“异”。现实中的数据远比我们想象的混乱。用户手动输入的症状描述充满口语化和错别字（如“头昏”和“头晕”）；不同设备的数据频率和精度天差地别；甚至存在矛盾数据（如手环显示深度睡眠良好，但用户自述失眠）。我们的应对策略是建立强大的数据清洗和置信度管理模块。对于矛盾数据，系统会标注冲突，并在生成建议时倾向于引用置信度更高的来源（如临床检验报告高于手环数据），同时可能会在输出中温和地提示数据存在不一致。

挑战二：大模型的“幻觉”与不确定性。即便有了丰富的上下文和严格的护栏，LLM偶尔仍会产生“幻觉”，比如捏造一个不存在的药物相互作用。我们除了加强护栏，还引入了“不确定性量化”机制。对于模型推理中关键但置信度不高的环节，我们在输出中会明确标注其不确定性。例如，建议可能表述为“有部分迹象提示可能与睡眠不足有关，但证据尚不充分，建议优先关注并记录您的睡眠模式以进一步确认。” 这种坦诚的表达方式，反而增加了用户的信任感。

挑战三：与现有医疗工作流的融合。医生和护士已经非常繁忙，他们不需要一个增加负担的“玩具”。我们的智能体定位是“助理”和“赋能者”。例如，系统可以自动整理患者近期的居家监测数据，生成一份包含关键趋势和异常提示的摘要报告，供医生在面诊前快速了解情况。我们将系统输出设计成易于整合到现有电子病历（EHR）系统的格式（如HL7 FHIR标准兼容的片段），降低接入门槛。

核心心得一：在医疗领域，“不做错”比“做得聪明”优先级更高。这意味着系统设计必须极度保守。任何没有足够证据支持的建议，宁可不说，或者说“信息不足，建议进一步观察或咨询医生”。将安全边际设置得足够宽，是赢得用户（无论是患者还是医生）长期信任的基础。

核心心得二：提示工程在复杂系统中，已演变为“系统提示工程”。它不再是与ChatGPT对话的艺术，而是涉及数据管道、知识表示、逻辑编排、安全策略等一系列组件的系统工程。架构师需要统筹全局，确保从数据源头到最终输出的整个链条，都在为“生成安全、有用、可信的回应”这一目标服务。

核心心得三：迭代的速度取决于评估的粒度。建立一个快速、自动化、多维度（安全、有用、可用）的评估流水线，比盲目优化模型或提示更重要。它能让你迅速知道每一次改动是让系统变得更好还是更糟。

这个项目目前仍在持续迭代中。我们看到，Agentic AI在医疗健康领域的生态影响正在慢慢显现：它正在改变健康信息的组织方式，从被动记录转向主动关联；它正在重塑人机交互模式，从简单的问答转向持续的、上下文丰富的对话式陪伴；它也在推动行业思考，如何为这类新型智能系统建立相应的评估标准和监管框架。作为架构师，我们的工作就是在这片充满希望但也布满荆棘的新领域，小心翼翼地铺设第一条轨道，确保列车能够安全、平稳地驶向真正有价值的未来。这条路很长，但每一步都值得。