1. 从“堆人力”到“堆智能体”我看到的B端健康服务转折点去年下半年我参与了一个体检连锁机构的数字化项目。客户市场部经理在项目启动会上说了一句话我到现在印象都很深“同样的‘体检前注意事项’问题坐席一天要回答上百遍健康顾问根本没时间服务真正需要深度咨询的客户。”这句话基本概括了B端健康服务的老大难——知识割裂、重复劳动、人力错配。也就是从那一刻起我们团队决定把“HealthAgent开放平台”这个方向推向实战用AI把健康领域的B端服务价值重新捋一遍。HealthAgent开放平台做的事情简单说就是面向体检中心、保险科技公司、药企数字化部门、健康管理公司这类B端客户输出一整套AI智能体能力。它不是一个封闭的APP也不是一个只能聊天的机器人外壳而是通过开放API、低代码配置台、多渠道嵌入SDK让企业把既有业务系统与AI能力对接起来重构“用户提问—服务响应—业务办理”的完整链路。这篇文章我会把平台从设计到落地的完整逻辑讲清楚包括架构分层、场景建模、知识库搭建、模型评测、上线避坑以及我在多个B端项目中踩过的实打实的坑。如果你正在评估“要不要给自家健康业务引入AI智能体”或者已经引入但效果不理想这篇文章应该能给你一些比官方文档更真实的参考。1.1 痛点解剖知识散落、渠道割裂、高价值服务被淹没我们先说痛点因为不理解痛点就去谈AI架构很容易做出一个“技术上很酷、业务上没用”的东西。我接触过的B端健康服务企业普遍存在三种典型情况。第一种是知识散落。体检套餐文档在运营部、医生排班表在门诊部、售后政策在客服部客户问一个问题坐席要打开三四个系统才能答全。这些知识本身是有的只是没有结构化、没有统一入口。第二种是渠道割裂。电话、企业微信、小程序、线下门店各跑一套用户在小程序问过的问题转到电话坐席又要重新描述一遍体验断档数据也断档。第三种是人力错配。一线坐席每天处理的大量咨询中真正需要专业判断的可能不到两成其余都是重复性、标准化问题。而高净值客户或疑难病例需要资深健康顾问深聊时顾问往往已经被琐碎问答占满了。HealthAgent平台的首要目标就是把这三种乱象拆开处理知识统一进知识库渠道统一接同一套Agent服务重复问题由智能体直接消化低置信度问题自动转人工。B端客户关心的是降本增效但他们更关心“AI到底能不能接住真实流量”这就需要平台在架构上先站得住。1.2 平台的核心承诺把专家经验变成可编排的智能资产很多人把“接入AI”理解成调一个聊天接口这是最大误解。健康领域的B端服务尤其是涉及体检报告解读、慢病随访、保险核保咨询的场景要求的是“确定性可解释可审计”。同一个问题不同坐席因为经验不同可能给出不同答案在AI平台上这是不可接受的。HealthAgent开放平台的做法是把企业已有的业务规则、专家话术、知识文档、服务流程拆解成结构化的“意图—槽位—知识—策略”四件套再通过多智能体协作执行。这样专家经验就不再是存在于个别老员工脑子里的隐性知识而是变成可编排、可复用、可审计的智能资产。举个例子。某保险科技公司的健康增值服务里用户问“我有甲状腺结节能买你们这个重疾险吗”。传统坐席可能要问半天才能给出保险侧的建议。在HealthAgent平台上意图识别Agent先判断“这是核保咨询”槽位抽取Agent提取“甲状腺结节”和“重疾险”知识检索Agent去拉取该产品的核保手册和既往话术策略引擎再根据规则决定“直接给出方向性建议”还是“触发转人工核保师”。每一步都有迹可循出了问题能回溯到具体环节。这才是B端客户真正想要的“AI赋能”——不是取代人而是把人从重复劳动里解放出来把专家经验放大成组织级的服务能力。2. HealthAgent的平台骨架三层设计决定了交付效率HealthAgent开放平台在架构上分三层对接层、智能体层、数据层。这三层看起来不复杂但每一层的设计决策都直接影响“接一个新客户要多久”“跑一个新场景要改哪些东西”。2.1 对接层接口优先而不是替换系统B端集成最怕的一件事是客户问“要不要把我们的核心系统换掉”。在健康行业很多体检机构和保险公司还在用老旧的业务系统让他们为了上AI做数据迁移项目基本就黄了。所以对接层的设计原则是接口优先适配一切。我们做了三套对接方式。第一套是REST API适合客户自己有开发团队通过HTTP接口直接调用Agent服务业务系统把用户输入传进来平台把结构化响应结果回传。第二套是消息队列对接适合对响应实时性要求不那么苛刻的场景比如慢病随访的定时触达通过MQ把随访任务发给Agent批量处理。第三套是多渠道SDK我们在H5、小程序、企业微信侧都封装了现成的嵌入组件客户前端只需要几行代码就能挂上对话窗口。这里有个容易被低估的细节回调机制。Agent识别到“需要转人工”或“需要创建工单”时必须能主动通知客户业务系统。我们的做法是注册回调地址Agent把转人工理由、用户意图、关键槽位、对话摘要一起推给工单系统坐席接手时不用重新问一遍基本信息。2.2 智能体层多Agent协作而不是一个“大杂烩”模型健康场景的对话真实用户的话术千奇百怪。有人问“我最近总犯困该查什么”有人直接发一段血压数值截图还有人发语音说“我妈65了想给她做个全面检查”。如果把这些全部丢给一个大模型让它自由发挥你得到的将是一个“什么都懂一点什么都不靠谱”的聊天机器。HealthAgent平台的做法是按职能拆分智能体每个智能体干一件明确的事意图识别Agent判断用户这次过来想干什么是咨询、预约、改期、查报告还是投诉。槽位抽取Agent从对话中提取结构化字段比如年龄、性别、症状、预算、时间。知识问答Agent负责从企业知识库检索信息并组织回答只回答知识覆盖范围内的问题。业务指令Agent对接客户系统完成具体操作比如提交预约、查询订单状态。转人工协调Agent当置信度不足或触发安全规则时负责交接和会话摘要。这些智能体通过一个上下文管理器协同工作。会话过程中产生的用户身份、历史意图、已抽取槽位都会写入会话状态供各个Agent共享。比如用户先说“我想做体检”接着问“多少钱”跟随其后的“多少钱”不会丢失前文语境否则每个问题都会被当成新问题处理对话体验就会碎成渣。2.3 数据层健康知识库不是扔几份PDF进去就完事数据层是HealthAgent平台最容易翻车的部分也是我特别想展开讲的一层。很多项目第一步就是收集文档然后把文档一股脑丢给RAG结果上线后发现回答质量毫无着落——问题不在于大模型不够强而在于知识库没有“建立结构”。健康领域的知识库至少分三类。第一类是静态文档比如体检项目说明书、套餐价格表、常见问题FAQ这类适合做向量化切分和相似度检索。第二类是结构化业务数据比如医生排班表、套餐条目、库存情况这类适合用数据库查询而不是放向量库。第三类是动态规则比如“什么症状组合下建议转诊”“哪些药品名称不能直接推荐”这类适合做成规则引擎配置而不是让大模型自己判断。在HealthAgent的数据层中三类知识分库存储向量数据库负责语义检索结构化数据库负责精确查询规则引擎负责策略判定。当用户问“你们周六能做胃肠镜吗”平台的实际处理过程是意图识别为“预约咨询”槽位抽取得到“胃肠镜”和“周六”先走规则引擎确认支持周期再走向量库检索套餐说明最后把两者合成自然语言回答。如果只靠RAG检索大概率会把“能不能做”和“怎么做”两个问题混在一起。数据隔离和隐私保护也在这一层落地。每个B端客户拥有独立的租户空间检索范围严格限定在当前租户的知识库内模型推理时不允许跨租户取数。在项目交付中我们要求客户在生产环境关闭历史对话的明文落盘日志手机号、身份证号等敏感字段落库前必须完成脱敏。3. 从0到1跑通一个真实场景体检套餐智能推荐完整拆解讲完架构接下来落到一个具体场景把完整建模、配置、上线过程走一遍。我用的是我们为某体检连锁机构做的“体检套餐智能推荐”案例。这个场景非常典型用户量大、问题重复度高、业务规则清晰、效果容易度量。3.1 第一步把业务需求翻译成“意图—槽位—策略”体检套餐推荐表面上是一个问答场景实际拆开看非常复杂。用户可能想给自己买套餐可能想给父母买可能单位有体检福利预算可能身体有特定症状要专项筛查还可能是就想知道“最贵的套餐到底贵在哪”。我们和客户业务部门开了三次工作坊把所有可能的产品问题列成清单最终归纳为六个主意图套餐咨询、比价推荐、预约改期、报告解读、发票咨询、人工投诉。每个意图下面再定义需要抽取的槽位比如套餐咨询至少要抽“年龄”要判断是否有对应年龄段的套餐、“性别”部分专项项目存在性别限制、“症状描述”用于推荐专项筛查、“预算范围”用于推荐档位。策略部分是最关键的。我们坚持一条原则推荐结果必须来自企业白名单而不是大模型自由生成。客户把现有套餐和适用人群整理成一张决策表我们把这套规则翻译成平台内的推荐策略。Agent在推荐时只能在候选套餐集合中挑选并给出推荐理由。这条原则帮我们绕开了“模型推荐了一个根本不存在的体检套餐”这种致命错误。3.2 第二步知识库构建和提示词配置的实操细节知识库这部分我们做了三件事。第一件是套餐文档的向量化切分。每个套餐单独成一个知识条目标题包含套餐名和核心卖点正文分成“适用人群”“项目列表”“价格”“注意事项”几个语义块。切分时我建议按语义块切不要机械地按字数切否则检索时容易把套餐信息和价格信息割裂开来。第二件是高频问题清单整理。我们从旧客服系统里导出了近半年的对话记录人工标注了约200多条高频问答全部录入FAQ库。这一步非常笨重但对效果提升极大因为用户真实问法往往不在官方文档里。第三件是提示词模板。我给一个参考示例健康场景里建议把角色约束、数据来源、回答边界写清楚你是某体检中心的智能健康顾问。你的任务是根据用户描述推荐合适的体检套餐。 回答时必须满足以下要求 1. 只能推荐知识库中存在的套餐禁止编造套餐名称和价格。 2. 回答需要给出推荐理由如适用年龄、症状覆盖、性价比。 3. 当用户描述涉及明显疾病症状时不给出诊断结论只建议选择对应专项筛查并提醒咨询医生。 4. 用户没有提供年龄、性别、预算等关键信息时先提问补充不要直接猜测。 5. 保持简洁控制在150字以内。参考参数值temperature建议设置成0.2到0.3之间太大会编造太小会机械重复实测0.3在推荐场景效果较好。检索的TopK建议5到8个太多了相关信息会被噪声冲淡。最大输出长度不用给太大健康问答追求的是简练准确。3.3 第三步多渠道嵌入与转人工工单流转集成方式上这个客户当时有三种渠道要进行对接小程序内嵌H5、企业微信客服侧边栏、呼叫中心坐席辅助。小程序和企微走的是SDK接入呼叫中心那边比较特殊坐席并不是直接把AI对话给用户看而是在接听电话时实时把用户的话转文本喂给Agent再由Agent把检索到的答案显示在坐席工作台由坐席决定怎么说。这种“AI辅助坐席”模式在B端健康服务里非常实用。有些客户担心AI直接面对C端用户风险太高那就先从内部辅助开始让AI先做人肉知识库数据跑通了再逐步开放直连模式。转人工的流转逻辑要提前设计好。我们的规则是意图识别置信度低于0.6、用户明确提出“我要找人工”、出现情绪化表达、以及触发高危敏感词时一律转人工。转人工时系统自动生成一张工单包含用户基本信息、会话摘要、已抽取槽位、推荐倾向坐席接手后能立刻进入有效服务不用让用户把问题再描述一遍。3.4 踩坑实录首版上线失败的根因与修复这个项目首版上线后第一周在线会话解决率只有51%数据和预想差距很大。复盘下来有三个问题。第一个问题正是前面提到的自由生成。虽然我们在提示词里写了“只能推荐知识库中存在的套餐”但偶发情况下模型仍然会组合出“名字很像但实际不存在”的套餐因为模型没有严格数学意义上执行白名单的能力。修复方式是加了一层后处理校验模型输出前先与候选套餐ID做匹配匹配失败就重新生成或转人工。第二个问题是槽位抽取漏项。用户说“我有点胖想减肥做个全面检查”槽位抽取Agent没有提取出“体重管理需求”导致推荐结果偏向常规体检忽略了体脂率、肝脏超声这些项目。我们后来增加了一组症状词表把“胖”“减肥”“肚子大”等日常描述映射到“体重管理”筛选项这个问题才解决。第三个问题是不懂拒绝。用户问“我最近胸痛会不会是心脏病”Agent竟然尝试给出一套推测。这是健康场景的大忌。我们补了一条硬规则涉及胸痛、呼吸困难、持续出血等紧急症状时Agent不能做任何判断必须直接建议尽快就医或拨打急救电话并同时触发转人工。修复后一周在线会话解决率从51%提升到76%人工坐席的重复问答压力明显下降。这个案例说明B端健康AI项目调试的重点其实不在“模型聪明不聪明”而在“业务边界划得清不清楚”。4. 慢病随访场景里最棘手的三个工程问题体检套餐推荐是相对“轻”的场景慢病随访要重得多。我们和一个做糖尿病管理数字化服务的团队合作过他们需要AI给出院患者定期做随访问用药情况、血糖记录、饮食运动习惯。从这次合作里我提炼出三个被反复问到的工程问题每个都值得单独说完。4.1 语音口语化与“答非所问”的兜底机制随访场景下用户回复有两个特点一是大量使用语音输入夹杂方言口音和口语废词二是经常答非所问你问“最近空腹血糖是多少”他说“我最近睡得不太好”。HealthAgent平台的处理流程是先做文本规范化把口语转成简洁的书面表达再做意图识别。但更关键的是置信度阈值设定。我们内部把意图置信度分成三档0.8以上直接执行0.6到0.8之间进入澄清式追问——比如“您是说最近睡眠不太好对吗那空腹血糖这个数值我们稍后再补充一下好吗”低于0.6则转人工。这套机制的核心思路是“宁可不答不要乱答”。特别要提醒的是别把“患者拒绝随访”识别成“没听懂”。用户说“我不想查了”“你们别老打电话”这是拒绝不是语义理解失败。我们在意图清单里专门加了“拒绝随访”意图一旦识别到就停止追问标记为“无意向用户”并降低后续触达频率。4.2 随访计划调整为什么不能把决策权交给大模型项目初期客户提出的需求是“让AI根据患者回复自动调整随访计划”。这个需求听着合理但仔细推敲就会发现风险巨大。随访计划的调整涉及医学判断比如血糖连续超标几天要不要转诊药物副作用描述到什么程度需要停药提醒这些决策不能依赖概率性的模型输出。我们最终的方案是分层处理AI Agent只负责信息采集和自然语言理解把患者的回答转成结构化字段计划调整一律由后端规则引擎做确定性决策Agent再把决策结果翻译成给患者看的自然语言话术。以血糖异常为例规则引擎的逻辑是“连续三天空腹血糖高于7.0且未预约复诊则生成复诊提醒”。系统判定后Agent再说“根据您最近三天的血糖记录空腹血糖连续高于7.0建议您尽快预约一次复诊我可以帮您查看最近有哪些空余号源。”如果让大模型自己做决策它可能会用模棱两可的话术应付过去而规则引擎保证了医疗建议的严肃性和可追溯性。4.3 健康数据隐私租户隔离、脱敏与授权链路随访场景涉及大量的个人健康数据这是整个平台合规压力最大的一块。工程上我们落地了四个措施。第一是租户级隔离。每个B端客户的数据存储在独立逻辑空间索引、缓存、备份全部按租户分片模型推理请求上下文里携带租户标识检索模块强制过滤。第二是传输和落库加密。对话内容和结构化结果在传输层用TLS加密落库时对敏感字段做字段级加密日志系统里直接禁止保存明文手机号和身份证号。第三是敏感信息脱敏。在对话进入Agent之前先经过脱敏模块把手机号、姓名、住址等识别出来替换成占位符这样即使模型生成的内容被截图外泄也不会直接暴露用户隐私。第四是授权与告知链路。健康数据的使用必须在用户授权范围内在人机对话启动时明确告知数据用途。我们把这个做成了硬编码流程客户无法通过配置关掉从平台层面保证底线。5. 模型评估与上线最后一公里比“答得对不对”更重要的是什么很多团队把AI平台上线当成一次模型部署模型一发布就觉得大功告成。在B端健康场景里这只是开始。真正决定项目生死的是评估体系是否完整、安全边界是否可靠、发布流程是否可控。5.1 健康场景评测集要覆盖标准问法、干扰问法和边界问法准确率是基本功但只盯准确率远远不够。我们构建了一套适合健康场景的三层评测样本。第一层是标准问答把知识库里所有FAQ和业务规则转成问答对验证模型能否覆盖核心业务。第二层是干扰问法同一个问题换各种不同表达方式比如“查癌该做啥”“想做全身检查有什么推荐”“我妈55了体检买哪个”验证槽位抽取和意图识别的鲁棒性。第三层是边界问法这是最容易暴露问题的部分。例如“喝了这个药能喝酒吗”“套餐能报销吗”“这个检查能查出癌症吗”这类涉及用药、报销、重疾判断的敏感问题评测重点不是答案多好而是“有没有越界”。每轮版本更新前我们都用固定评测集做一次全量回归记录准确率、答非所问率、拒绝率、转人工率、超时率五个核心指标。某个版本如果显著提升了准确率但转人工率也大幅上升这不算成功说明模型变了“更谨慎”但业务承担不了这个代价。5.2 安全兜底和高危话术敏感词触发转人工的工程实现健康领域有一类话术是绝对不能碰的诊断结论、用药建议、免责承诺。哪怕模型在大多数情况下答得很好只在一句话上出现严重越界客户都会直接叫停项目。我们的做法是在对话出口再加一道硬性过滤层不信任模型自觉。过滤层包含敏感词库和兜底策略当输出命中处方药名、疾病诊断句式、生死承诺等敏感特征时拒绝输出原文本替换成安全话术库里的固定语句同时触发转人工。安全话术都要由客户业务团队审核后写入库不能是平台方拍脑袋编的。紧急症状场景更要激进一点。识别到“胸痛”“呼吸困难”“持续出血”等关键词Agent直接中止正常对话流程输出紧急处置指引并标记高风险事件通知客户值班人员。这些规则会被放在规则引擎里优先级最高不允许被提示词覆盖。5.3 灰度发布和客户验收让业务人员一起看效果B端项目上线最大的风险是“在测试环境表现好一到生产就崩”。我们现在的标准流程是灰度发布先开放5%的真实流量跑48小时看延迟和转人工率是否正常再逐步扩大到30%、60%、100%。延迟这边有几个健康业务场景特有的坑。体检套餐推荐出现高并发往往在早晨8点到10点因为大家习惯上班前刷一下小程序约体检。慢病随访的高峰则在晚间7点到9点。容量评估需要按峰值而不是平均数算我们早期吃过这个亏扩容后又缩回来后来固定按峰值预留40%余量。客户验收环节我强烈建议不要让技术人员单方面验收。我们经常组织客户运营人员、一线坐席代表、平台技术团队三方一起看回放对话重点看那些“算法觉得答得很好、业务觉得根本不对”的案例。运营人员能看到“AI没有强调客户最关心的价格折扣”坐席能看到“AI的语调和客户期望不符”这些问题在纯指标评测里完全发现不了。健康服务的最终裁判是人的体感不是模型的F1分数。6. 复盘与经验B端健康AI平台项目最值得记住的三件事项目做到后期我越来越确认一个判断健康领域的B端AI开放平台真正的护城河不在模型参数而在Know-how沉淀和平台化方法论。最后分享几个我认为对其他想复刻这条路的团队有价值的复盘结论。6.1 平台化的价值在于复利而不是一次性交付我们接第一个健康类客户时从需求调研到上线花了将近三个月其中大量时间耗在梳理业务规则和整理知识库上。做第二个同类客户时因为把套餐推荐、问答、转人工这些模块沉淀成了标准模板交付周期缩短到六周。再做到第三个客户只需要配置差异化的套餐字段和话术即可上线。这就是平台和“定制项目”最大的区别定制交付的成果沉淀在文档里下次用到还要从零开始开放平台的成果沉淀在平台配置和模板里每次交付都为下一次铺路。健康B端市场极度垂直细分每个细分场景花三个月定制是烧不起的只有把共性能力抽象成模块才能规模化。6.2 知识库建设是业务工程不是技术工程客户必须深度参与不少客户以为买了平台丢几份PDF就能出效果这是认知上的最大偏差。负责的知识库要能用至少需要三类角色参与业务专家负责审核答案的准确性、运营人员负责维护高频问答、客服主管负责把关话术风格和合规边界。我们后来在项目里专门要求客户设立一个“知识运营小组”哪怕只有一两个人兼职也行。每周在平台里新增知识条目、标记错误回答、更新套餐信息。一个AI系统上线三个月后效果是变好还是变差很大程度取决于有没有这样一个小组持续喂养。6.3 对想复制这条路的人三个建议第一个建议是先选一个高频刚需场景做成样板间而不是铺开做十个场景。样板间最有说服力能在一个场景里把模型效果、稳定性、运营机制全部跑通再复制到其他场景。第二个建议是把确定性交给规则引擎把模糊性交给大模型。凡是涉及医疗决策、安全边界、业务硬规则的地方一律用规则引擎锁死凡是开放式的自然语言理解、信息整理、表达生成交给模型。把两者的边界划清楚系统才抗风险。第三个建议是建立日志驱动的迭代闭环。上线之后每周看一次“未识别语句Top30”和“转人工原因分布”。这两个列表是最真实的产品需求清单比任何调研都准确。排着队把列表里的高频问题解决掉效果提升会非常明显。说句实话健康B端项目比一般AI项目要累得多因为你的每次输出都可能影响一个真实用户的健康决策。但恰恰因为这样这类项目做出来后价值感和壁垒都是很高的。我个人体会是把平台架构搭扎实、把业务规则盯死、把运营闭环打通B端客户最终会认可这是一次真正能复用的服务能力升级而不只是又多了一个跟风上线的玩具。
