企业官网建设流程全解析

1. 为什么医疗Agentic AI比普通对话AI更难监控

先说一个我实际踩过的坑。之前我维护过一个面向患者的分诊类对话系统，最初用传统的意图识别加槽位填充架构，效果还算稳定。后来项目升级，把架构改成了Agentic AI，也就是让大模型自己决定调用哪个工具、先查哪份资料、什么时候给结论。上线前我在测试环境跑了上百条用例，感觉一切正常。结果灰度一开，第二天就出了问题——同一句“我最近头晕，还有点恶心”，有的会话走了血压查询，有的会话去检索脑部疾病知识，还有的直接给了一个泛泛的就医建议，三条路径的结果完全对不上。

这个问题的本质在于：普通对话AI是“单跳”的，用户问一句，模型答一句，输入和输出之间基本可控。Agentic AI是多跳的，模型内部要经历“理解意图 → 拆解任务 → 选工具 → 读结果 → 再推理 → 给答案”的完整链路。链路上任何一环发生漂移，最终结果都会偏。而且医疗场景对结果的正确性要求极高，一个错误的转诊建议、一个漏掉的危险信号，代价不是多花几分钟，而是可能延误病情。

所以做医疗Agentic AI系统，性能监控和提示调整是一体两面的事。监控不光是看延迟和Token消耗，还要看每一跳的质量；提示调整也不光是改改措辞，而是要保证整个Agent在约束范围内稳定飞行。这篇文章我把我实际用过的监控指标、采集方案、调整策略和踩坑经验完整写一遍，适合正在做或准备做医疗Agentic AI系统的提示工程师、算法工程师和技术负责人参考。

2. 医疗Agentic AI的系统结构里，哪些环节最容易失控

要谈监控和调整，先得把Agentic AI在医疗场景下的结构拆清楚。不同厂家的实现细节不一样，但核心骨架基本一致，大致可以分为四层。

2.1 规划层：大模型决定子目标拆解

规划层是Agent的“大脑”。它接收用户的原始诉求，比如“我父亲有糖尿病史，最近总是手脚发麻，应该挂什么科？”然后规划层需要把这个诉求拆成若干子任务：“查糖尿病常见并发症”、“查手脚发麻相关的神经病变信息”、“结合病史给出分诊建议”。这个拆解过程完全依赖大模型的语义理解能力。

最容易失控的地方在于子目标拆分得过粗或过细。拆得过粗，比如直接跳过并发症检索就去给建议，结果会缺乏依据；拆得过细，比如把“查手脚发麻相关疾病”拆成五个query一次一次查，又会拖慢响应速度、增加API成本。监控时需要重点看每个Agent会话的“一跳平均耗时”和“工具调用次数分布”，如果发现大量会话的工具调用次数超过了预设上限，就要怀疑规划层的拆解逻辑出了问题。

2.2 工具层：医疗知识库、病历系统、药品数据库的调用

工具层是Agent能力的边界。医疗Agent和通用Agent最大的差异就在这里：通用Agent的工具大多是搜索引擎、计算器、天气接口，失败了大不了重试一次；医疗Agent的工具往往涉及病历查询、检验指标解读、药品相互作用查询，这些工具的数据结构复杂、返回字段多、权限控制严格，调用失败的概率远高于普通工具。

在实际项目中，我们最头疼的是病历查询接口。不同科室的病历字段命名不一致，有的写“主诉”，有的写“病情描述”。大模型生成的查询参数偶尔会把字段名张冠李戴，导致接口返回空结果。这类问题表面上看是接口文档不清晰，根子上是提示词里没有给Agent明确的字段映射规则。

2.3 记忆层：多轮对话的上下文管理

Agentic AI系统通常会把用户历史对话、当前会话中的中间推理结果、以及工具返回的长文本结果都塞进上下文。医疗场景有一个特殊问题：病历和检验报告文本特别长，如果不做提炼直接全量塞给大模型，很快就把上下文窗口撑爆，或者让模型分不清主次。

记忆层失控的典型表现是“遗忘关键信息”。比如用户在第一轮说了“我对青霉素过敏”，到第五轮Agent推荐药物时把这句忘了，给出含青霉素成分的建议。这种问题靠监控不是总能发现，因为单看回复流畅度根本看不出来，必须针对关键过敏史做专门的提示词约束，并在链路中设定“重要信息必须保留”的规则。

2.4 输出层：最终回复的生成与安全校验

输出层决定Agent用什么样的语气、格式和内容回复用户。医疗场景对输出层有硬性要求：不能给出确诊式表述、不能推荐具体用药剂量、必须建议线下就诊。这些约束都要写在系统提示词里，但大模型偶尔还是会“越界”。

我用过的一个版本，系统提示里明明写了“禁止给出具体用药剂量”，结果模型还是回了句“建议口服布洛芬200毫克”。这不是模型不听话，而是因为提示词的约束被埋在了一段很长的工具返回内容之后，模型的注意力被工具结果带偏了。输出层监控的意义就在这里：及时发现越界，快速定位是提示词位置的问题还是模型本身的问题。

3. 性能监控要抓的六个核心指标，以及它们为什么重要

监控指标体系的设计逻辑，应该跟着“链路质量”走，而不是只盯着系统资源。以下六个指标是我实践下来觉得最实用的，按重要程度从高到低排列。

3.1 意图漂移率：任务执行是否偏离用户真实诉求

这是医疗Agent最该盯的指标，也是很多团队忽略的指标。意图漂移指的是Agent在执行链路的过程中，逐渐偏离了用户的原始意图，最后给了一个“正确但没有用”的回答。

举个例子，用户问“孩子发烧三天了，需要去医院吗？”正确的链路应该优先判断发热时长、伴随症状，然后给出就医决策建议。但某个版本里，Agent在检索知识库时被“儿童退烧药”相关的内容带偏，最后花大量篇幅讲药物选择，反而没有直接回答“要不要去医院”这个核心问题。我们用了一组人工标注的验证集，专门测这类场景，发现意图漂移率一度高达百分之十几——这意味着十次咨询里至少有一次答非所问，对医疗场景来说完全不可接受。

意图漂移率的计算方式是：抽样近期真实会话，由医生或资深医学编辑判断Agent最终给出的结论是否覆盖了用户的核心诉求。抽样比例建议不低于每日会话量的百分之二，而且要保证覆盖不同科室和不同复杂度的问题。

3.2 工具调用失败率与重试次数：链路稳定性的晴雨表

工具调用失败本身不是灾难，灾难是失败之后Agent的“自救能力”不足。我们在日志里会记录每一次工具调用的状态码、返回长度、耗时，以及调用失败后Agent是否自动切换了备用方案。

监控数据表明，工具调用失败率高往往不是接口抖动，而是提示词生成的参数格式不稳定。我们对接过一个药品查询接口，要求传入药品通用名，但Agent经常把商品名传进去，导致大量查不到记录。后来我们在提示词里加了“先做药品名词归一化再查询”的步骤，失败率从百分之七降到了百分之一点五以下。这个教训说明：监控数据不能只看数值，要把失败样本拉出来看根因，大多数情况下根因都出在提示词，而不在系统资源。

3.3 链路步数分布：判断规划层是否过度拆解

链路步数指一个完整会话中Agent调用工具的总次数。正常的分诊咨询，合理的工具调用次数在二到五次之间；如果超过六次，回复的准确率反而会下降，因为每多一跳就多一次累积误差的机会。

我们监控过上线初期的数据，发现百分之十二的会话工具调用次数达到了八次以上。拉出日志一看，Agent在反复检索同一个知识库的不同条目，每次只拿到一小段内容，拼起来才够用。这就是典型的规划层拆解过细，解决方案是在系统提示词里限制“同一个知识库最多检索两次，若两次未获得足够信息，基于已有信息直接回答并标注不确定项”。这个约束加上去之后，百分之九十以上的会话都能在五次以内完成链路。

3.4 内容一致性评分：同一问题多次回答的结果是否前后矛盾

内容一致性是医疗Agent特有的监控维度。普通对话系统回答不一致顶多让人吐槽，医疗场景回答不一致有潜在风险。患者上午问了一遍，下午换个账号再问一遍，得到的建议完全不同，这会严重影响用户信任。

我们用两种方式衡量一致性。一种是离线评测：准备一百对“相似问题对”，比如“高血压患者可以吃柚子吗”和“长期吃降压药的人能喝柚子汁吗”，看模型给出的建议方向是否一致。另一种是在线监控：记录同一用户短期内重复咨询同一问题的会话，对比两次回复中的关键建议点，比如是否推荐就医、是否提醒禁忌。

一致性评分低于百分之九十的时候，通常意味着提示词里缺乏强制性的决策框架，Agent每次都在“自由发挥”。这种情况下不是靠调temperature能解决的，必须在提示词里给一个标准的决策分支结构。

3.5 危险内容越界率：是否出现确诊诊断或用药剂量建议

危险内容越界是医疗Agent最不可触碰的红线。我们内部定义了三类禁止输出：禁止给出确定性诊断、禁止给出具体用药方案、禁止用绝对化语气描述病情预后。监控方案是采用规则加模型的二层过滤：第一层用正则和关键词规则快速拦截，第二层用一个小模型做语义级别的判断。

越界率的基准线应当设置为零点五个百分点以下。一旦超过这个线，不应该只做提示词微调，而是要直接暂停该提示词版本的外放流量。这里要特别提醒一句：不要过度依赖大模型的安全对齐能力，你永远不知道它在某个工具返回结果的强烈暗示下会不会冲动输出，该加的硬校验一定要加。

3.6 响应延迟与Token消耗：用户体验和成本的双重约束

延迟和Token消耗放在最后，不是因为不重要，而是因为它们是结果指标，不是原因指标。链路步数多了延迟自然高，工具返回的结果文本过长Token消耗自然大。

我习惯把Token消耗拆成三块来看：输入token、输出token、工具返回token。实践中发现，工具返回token常常占总量的百分之六十以上，这才是成本大头。优化思路是限制工具返回的字段数量，或者让Agent把工具结果先做摘要再传入后续步骤。比如病历接口返回二十个字段，提示词里规定“仅提取与本次主诉相关的字段”，Token消耗能直接减少三分之一。

4. 监控落地搭建：用一套轻量的日志与追踪框架打通链路观测

说到落地，很多团队其实不缺监控工具，缺的是把Agent链路的每一步“串起来”的能力。我建议不要一上来就追求大而全的可观测平台，先用一套轻量方案跑起来，验证指标体系的合理性，再去扩展。

4.1 链路追踪的字段设计与日志埋点

我给Agent的每一次完整会话分配一个“会话唯一标识”，链路中的每一步都带上这个标识，记录五类信息：当前节点名称（比如“意图识别”、“工具调用-病历查询”）、输入内容摘要、输出内容摘要、耗时、状态码。

日志埋点的位置有三个必须覆盖：规划层完成子目标拆解之后、每次工具调用返回之后、最终回复生成之后。这三个位置是链路质量的关键观察点，缺一个都会导致问题定位困难。比如前面说的“字段名张冠李戴导致病历查询失败”，如果只记录最终回复而不记录工具调用参数，你永远不知道是哪一步出了问题。

4.2 采样策略与在线评测的平衡

全量日志记录所有会话不现实，一方面成本高，另一方面无关会话占大量存储。我的做法是双轨采样：随机抽百分之五的会话做全链路明细日志，另外对触发特定条件的会话（比如工具调用失败、回复包含危险内容、用户明确表达不满）做全量记录。

这样设计的好处是：既能通过全链路日志去复盘典型问题，又不用为每一笔正常会话承担存储成本。离线评测环节，我们每天从采样日志里抽一百条，让医学标注人员判断“最终回复是否可接受”，并把标注结果回传作为意图漂移率和内容一致性评分的数据基础。

4.3 告警规则：延迟和失败之外，更要盯“质量类”指标

告警规则不能只设延迟和失败率，医疗场景下更要重视质量类指标。我在实践中的告警配置大致如下面这张表：

需要说明的是，质量类指标的告警不适合用“十分钟内超过阈值就报警”的短窗口方式，因为人工抽样的周期相对较长，短窗口会造成频繁误报。我们采用的方案是四小时滑动窗口，窗口内如果意图漂移率超过百分之八，就自动给值班人员发通知，并且把触发窗口期的会话清单一起带上，方便直接定位问题会话。

5. 提示调整的五种打法：按问题层次对症下药

监控发现了问题，提示词也要跟着改。但改提示词不是拍脑袋改几句，而是要按问题的层次，选择对应的调整策略。我总结了五种打法，覆盖从数据层到链路层的完整范围。

5.1 数据层调整：给Agent提供更清晰的结构化知识

一部分“提示越界”的问题，根源不在提示词文本本身，而是给模型的知识材料太杂乱。比如知识库返回的文章里既有专业医学内容又有科普段落，模型会倾向于采用更口语化的科普表述，容易丢掉严谨性。

针对这种问题，我会在知识库返回字段里增加一个“信息来源类型”的标记，并提示Agent：优先参考临床指南类来源，其次才是科普类内容，两者结论不一致时，要在回复里向用户说明差异。这个调整不改变任何一句提示指令，只是优化了数据侧的结构，效果却很明显，引用了非权威来源的比例在两周内下降了四成。

5.2 结构层调整：给输出加一个可校验的格式模板

医疗场景对输出格式有较高要求：先亮结论，再给依据，最后是行动建议。但大模型默认的输出习惯往往是把依据写在前面，结论藏在最后，用户读起来很累。

我的做法是在系统提示词里给一个结构模板，规定输出必须包含三个段落，分别叫做“初步判断”、“依据说明”和“就医建议”，并且每一段都有字数上限。模板类约束在执行层面效果很好，因为它把开放式任务变成了结构式任务，模型的生成难度降低了，输出的稳定性也就上来了。唯一要注意的是，模板不能定得太细，否则会出现同一套话术复用的机械感，反而影响用户信任度。

5.3 指令层调整：把模糊要求改写为明确禁止与允许

很多越界输出源于指令太模糊。比如“请给出专业建议”这句话，模型的理解因人而异，有的模型认为给出确诊诊断也算专业建议，有的则认为应该委婉建议就医。

正确做法是把模糊要求改写成明确的允许项和禁止项。不要写“请确保回答安全”，要写“禁止给出确定性诊断，禁止推荐具体药物剂量”；不要写“结合患者情况作答”，要写“若患者年龄小于十二岁或大于六十五岁，须优先建议线下就诊”。明确指令的收益是立竿见影的，危险内容越界率通常能在一轮调整内下降一半以上。

5.4 链路层调整：给Agent加一个“先查后答”的强制约束

医疗Agent最怕的情况之一是“不查就答”。用户问了一个复杂问题，Agent凭自己的知识储备直接开答，没有调用任何工具。这种回复看起来有时还挺合理，但一旦遇到超出模型知识边界的冷门病种或新药，错误率就会大幅升高。

链路层调整是在规划阶段增加一条强制约束：“涉及疾病判断、用药建议、就诊科室推荐三类请求，必须先完成至少一次工具调用，禁止直接基于模型内部知识作答。”在实际运行时，我们还会在代码层面做校验：如果最终回复属于上述三类请求，但链路日志中没有任何工具调用记录，就自动触发回退，要求Agent补充检索后重新生成。

5.5 示例层调整：用好few-shot让模型快速对齐输出风格

有时候规则都写清楚了，模型还是不够稳定，这时候就得靠示例来“手把手教”。我会在提示词里固定挂着一组经过设计的示例对，每个示例对包含一个用户提问和一个标注了结构格式的回复样本，样本内容要覆盖高频场景的代表性问题。

示例的选择比数量更重要。我见过有人挂二十个示例，效果反而不如五个精心设计的示例。原因是示例之间如果存在微小逻辑冲突，模型会更困惑。我建议只挂五个以内示例，覆盖“一般咨询、紧急症状、慢性病随访、药物相互作用、拒绝回答边界”这五个典型场景，每个示例的回复格式保持一致，让模型能从示例中自行归纳输出风格。

6. 一个完整案例：从指标报警到提示修订的闭环操作

前面讲了一堆方法和指标，我拿一个真实处理过的案例把整个流程串起来，这样你会有更直观的印象。

6.1 报警触发：内容一致性评分异常下跌

某个周二下午，监控系统报警，内容一致性评分从平时的百分之九十五掉到了百分之七十八。我按流程拉出了触发窗口期的会话清单，开始逐条核对。

对比发现，问题集中在“高血压患者用药咨询”这个分类下。用户问“我血压有点高，之前吃的药能继续吃吗”，Agent有时候回答“建议先测量血压并记录一周再咨询医生”，有时候却直接说“硝苯地平类药品原则上可以继续服用，但需要注意监测”。两条回复的口径差异非常大，后者明显踩了“推荐用药方案”的越界红线。

6.2 根因定位：规划层在子目标拆解时漏掉关键一环

进一步看链路日志，两条回复走了完全不同的规划路径。合规的那条路径是先调用“病历查询”确认患者既往用药记录，再调用“用药安全知识库”查相互作用，最后才生成建议；越界的那条路径只调用了“用药安全知识库”就直奔结果，跳过了“确认患者具体情况”这一步。

根因清楚了：某个改动在系统提示词里把“用药咨询类问题须先查询患者用药史”这个前置条件从规划层提示移到了输出层提示。规划层没有这个约束，自然会在拆解时漏掉关键步骤。这就是典型的“提示词改动引发链路漂移”，单测模型能力根本发现不了，只有靠线上指标监控才能暴露。

6.3 调整方案：把约束放回原来的位置

修复方案很朴素：把“用药咨询必须先查患者用药史”加回到规划层的系统提示词中，并且在记忆层的上下文规则里增加一条“患者既往用药史是后续所有建议的前置依据，若上下文中已存在，不得重复查询；若不存在，必须先查询”。同时，示例层里增加了一个专门针对此类场景的正反示例。

修改完成后先在沙盒环境回放那批问题会话，一致性评分回到百分之九十四。灰度一天后再看线上指标，用药咨询类的越界率从百分之一点八降到了百分之零点三，链路步数分布也恢复了正常。

6.4 复盘沉淀：把一次修复固化为可复用的经验

每次处理完问题，我会写一份简短的复盘纪要，核心内容包括三部分：触发指标是什么、根因在哪一层、修复动作落到哪类打法里。这些纪要会汇成一个内部知识库，下次遇到类似报警，可以直接按图索骥。

比如这个案例就被归入了“规划层约束丢失”的典型问题清单，类似情况还包括：意图识别节点没有强约束“疾病疑问句必须先检索”、输出节点没有强约束“涉及急诊症状须提及线下就诊”。每条清单都附有对应的修复模板，团队其他人拿到报警信息后可以直接套用。

7. 几条红线提醒：医疗Agent的提示调整不能碰的边界

关于医疗Agent的提示调整，最后想单独说说那些不能碰的红线。这些红线有的来自监管要求，有的来自行业惯例，有的纯粹是实际踩坑换来的教训。

第一条，不要在提示词里试图绕过“不能替代医生诊断”的核心表述。别觉得这句话是套话。做产品的人往往想让Agent显得更有用、更像一个“AI医生”，于是用隐晦的方式让模型输出确诊倾向。比如把“不要给出确定性诊断”改成“基于现有资料，给出倾向性判断”，这实际上是在消解安全约束，一旦出事，产品责任和技术责任都躲不开。

第二条，不要在一个会话里无限增加子任务。我见过有人在调整时，为了让回复覆盖率更高，在提示词里加了一大堆“同时需要考虑维生素、微量元素、运动、心理……”等维度的要求。结果模型为了覆盖所有维度，把关键问题的深度反而牺牲掉了。医疗咨询的核心逻辑应该是“优先回答用户最关心的问题，再视情况补充其他建议”，而不是“面面俱到地输出一片论文”。

第三条，不要依赖少数几条测试样本的通过来确认提示词改好了。提示调整必须配合监控数据来验证，没有指标佐证的调整，一律视为无效改动。我在项目中曾经为了修复一个开环问题，连续改了四个版本，每个版本看起来在样例集上都表现很好，结果放线上又出现新的问题，最后才发现是验证集覆盖度太低，根本没有包含工具调用失败时的回退场景。

医疗Agent的提示工程，本质上不是“写一段好提示”，而是“设计一套能在复杂链路中自我约束的规则系统”。监控是这套系统的反馈回路，调整是控制信号。两者循环往复，系统才会越来越稳。