OpenClaw医疗技能实战：从规则引擎到可审计智能体

1. 为什么 OpenClaw 会成为医疗技能落地的关键一环这两年提到 OpenClaw不少人第一反应是又一个自动化框架。但真正把它用进医疗场景之后我的看法变了——它不是一个简单的任务调度器而是一套能把技能这件事标准化、可复用、可审计的完整体系。医疗领域最缺的不是模型不是算力而是把流程固化成技能的工程能力。我自己是在一个模拟项目中开始尝试的某跨平台系统需要把患者入院评估、护理记录生成、用药提醒、随访话术这几件事全部交给一个智能体来完成。最开始团队里争论很大有人说直接用大模型 API 写 Prompt 就行有人说干脆用传统规则引擎。最后是 OpenClaw 让我们把两边都放下了——它提供了一套介于纯规则和纯模型之间的中间层让医疗流程中的每一步都可以被定义成技能既能调用模型又能调用外部工具还能记录完整的调用链。这条路径解决了一个很现实的问题医疗场景里光有模型输出是远远不够的你还需要知道它为什么这么输出、依据了什么、走了哪条逻辑路径。OpenClaw 的技能机制天然适合做这件事。我在这篇文章里会把从零搭建医疗技能包的完整过程写出来包括技能拆解、知识点挂载、工具注册、异常兜底、效果验证这些环节都是实际操作中一步步趟出来的经验。2. 医疗技能的本质拆解先搞懂技能到底是什么2.1 技能、工具和模型之间的关系在动手写第一个技能之前我建议你先在脑子里把三个概念的分工理清楚。这个搞不明白后面写出来的技能大概率是四不像。OpenClaw 里的技能Skill是一个自包含的能力单元它包含三样东西技能描述告诉智能体什么时候该用这个技能、执行逻辑具体的处理步骤、资源依赖用到的 Prompt 模板、知识库、外部工具。工具Tool则是技能调用外部能力时的那只手比如查药品库的接口、算剂量的小程序、读写患者档案的函数。模型Model负责的是语言理解和生成它本身不知道什么时候该用什么工具全靠技能描述来触发。这个关系就像医生看病技能是诊疗路径工具是检查设备模型是医生的脑子。路径决定什么时候需要做什么检查检查设备返回数据脑子基于数据做判断。如果你把这三层搅在一起——比如在技能描述里写了大量业务逻辑或者在执行逻辑里硬编码模型输出——后面维护起来会非常痛苦。2.2 一个医疗技能的标准目录结构我推荐的技能目录结构是这样的每个技能都独立成文件夹互不污染skills/ ├── medication_check/ │ ├── SKILL.md # 技能描述场景、触发条件、前置检查 │ ├── main.py # 主执行逻辑 │ ├── prompts/ │ │ ├── interaction_check.md │ │ └── allergy_review.md │ ├── resources/ │ │ ├── high_risk_drug_list.json │ │ └── interaction_rules.yaml │ └── tests/ │ └── test_cases.json这套结构的好处有几点SKILL.md 是给智能体看的使用说明书它决定了智能体在遇到什么样的问题时会产生调用这个技能的意向main.py 是真正干活的入口prompts 和 resources 分离让你改一个提示词不需要动代码tests 目录里放预定义的测试用例做回归验证时特别有用。这里我想特别提一个容易犯的错很多人把 SKILL.md 写得特别手舞足蹈为了吸引智能体的注意力在一句话里堆了十几个关键词。实测下来这反而有害因为技能匹配时是语义相似度触发的描述越精炼、边界越清晰触发准确率越高。我现在的写法是该技能仅用于 X 类场景不处理 Y 类情况用排除法框定边界比用一堆同义词去勾引模型更可靠。2.3 技能粒度的控制拆到什么程度才算合理技能粒度是另一个让我反复纠结过的问题。一开始我把患者全流程管理做成了一个大技能里面塞了评估、记录、提醒、随访所有功能结果智能体经常在一个技能里乱跳——本来只是查个用药禁忌结果把随访话术也生成了一堆。后来我参照了医疗流程本身的天然边界把技能拆成了四个独立单元入院评估技能负责采集主诉、病史、过敏信息产出结构化评估结果护理记录生成技能接收评估结果按模板生成护理记录草稿用药安全技能查相互作用、过敏交叉核对、高危药品警示随访计划技能基于评估结果生成随访频率和话术要点拆完之后效果立竿见影。触发准确率提升了而且每个技能的 Prompt 上下文更短模型输出的稳定性也更好。一个技能干一件事这句话虽然听起来简单但在医疗这种强流程领域它对应的是临床上单病种单路径的思维。你在拆技能的时候多问问自己这一步在真实医疗流程里是不是一个独立环节如果是就值得拆出来。3. 首个医疗技能的完整搭建用药相互作用检查3.1 为什么要选这个场景作为起点用药相互作用检查是我建议优先做的场景原因有两个。第一它边界清晰——输入是药品清单输出是有无冲突不需要处理太多开放式的语言理解问题第二它价值密度高——一次性可以覆盖技能描述编写、知识库挂载、规则判定、模型兜底这四个核心环节做通一个其他技能就是换皮。我们先看输入输出定义。技能输入是一个患者当前的用药清单每项包含药品名、剂量、给药途径输出是三类信息明确的相互作用附证据、潜在风险提示需要人工复核、安全的组合。这个定义一开始就要写清楚因为它直接决定后面 SKILL.md 和 main.py 怎么写。3.2 把医学规则沉淀成机器可判定的格式用药相互作用的核心知识来自药品说明书和临床指南。这里有个非常关键的设计决策这些规则是用硬编码判定还是让模型临场判断我的答案是能写死的规则全部写死。原因很简单医疗场景不允许模型的发挥。阿莫西林和丙磺舒的相互作用是写入指南的不需要大模型重新推理更容不得它差不多觉得有风险。所以我这边的做法是把规则整理成 YAML 格式的决策文件interactions: - drug_a: acyclovir drug_b: probenecid effect: probenecid reduces renal clearance of acyclovir severity: high action: alert_doctor_do_not_coadminister - drug_a: clarithromycin drug_b: simvastatin effect: increased risk of myopathy and rhabdomyolysis severity: high action: suggest_dose_reduction_and_monitoring规则文件里每一条包含四个字段药物对、效应描述、严重程度分级、建议动作。这个格式的好处是便于人工审核——医生团队可以一行一行地看、一行一行地批不管底层用了什么模型规则本身是可以被逐条签名确认的。对一个医疗系统来说这一点要命地重要。真正的难点在于药品名归一化。同一个药在不同数据源里可能叫不同名字比如对乙酰氨基酚和扑热息痛、Acetaminophen和Paracetamol。我最后的方案是在技能内部先做一个别名映射步骤把所有输入药品名转成标准代码如 ATC 编码再做相互作用匹配。这一层是清洗数据的功夫虽然不显眼但它是整个技能稳定性的基座。3.3 主执行逻辑的分步实现main.py 的执行逻辑我按责任链的方式来组织。每到一个环节要么直接出结果要么转给下一个处理器def run_medication_check(medication_list: list) - dict: # 第一步规范化输入识别标准药品编码 normalized normalize_drug_names(medication_list) # 第二步走规则引擎快速命中已知的相互作用 rule_hits match_interaction_rules(normalized) # 第三步对未命中的药物组合交给模型做辅助判断 llm_hits llm_auxiliary_review(normalized) if needs_llm_review(rule_hits) else [] # 第四步汇总结果附上置信度和人工复核标记 return build_report(rule_hits, llm_hits)这里要重点说一下为什么第三步不做全量模型兜底。一开始我的版本是先跑模型、再用规则校验结果不仅慢还经常出现模型脑补出不存在的相互作用。后来调换了顺序先规则后模型而且只有规则没覆盖到的组合才进模型。这样一来已知风险是确定性的未知风险是提示性的整个输出结构非常干净。在需要模型介入的部分Prompt 也要做约束。我不会问你看看这两个药有没有问题这样问模型太容易给出不确定的答案。我把它框成选择题基于给定的药物相互作用知识库判断以下药物组合 - A. 存在明确相互作用对应规则编号 RX-001 - B. 存在潜在相互作用需要人工复核 - C. 未发现相互作用 - D. 规则库中无此组合记录请说明依据 只输出选项和依据不输出泛泛而谈的用药建议。用这种决策题而不是论述题的方式模型的不确定性大幅下降输出内容也更适合直接进入的报告结构。顺便说一句模型在这里不是权威它是规则引擎的补充外脑这个定位必须从一开始就摆正。3.4 结果报告的数据结构设计技能最终的产出是一份结构化报告。我把它设计成 JSON 模式方便后续直接渲染到界面或归档到病历系统{ skill_id: medication_check, input: [amoxicillin, probenecid], output: { definite_interactions: [ {drugs: [amoxicillin, probenecid], severity: moderate, evidence: DX-012, recommendation: 建议间隔2小时服用并监测疗效} ], potential_interactions: [], cleared_combinations: [], needs_human_review: false }, trace_id: 7f3a9c1e2b8d44a6 }trace_id 是给每个调用请求生成的唯一标识目的就是为了事后审计。医疗场景里你永远不知道哪一次的调用结果会被复查或者被拿出来讨论所以一切的输入输出和内部处理路径都必须通过 trace_id 串起来。我甚至会把每次调用时用的规则文件版本、模型版本都记录下来。4. SKILL.md 编写的实战经验让智能体在正确时机出手4.1 描述文本的正向定义 反向排除写法SKILL.md 是整个技能包跟智能体交互的接口它的质量直接决定触发准不准。我踩过最大的坑是技能描述写得太宽泛导致智能体碰到什么医疗问题都来调用这个技能结果很多场景里答非所问。现在我的写法统一是正向定义 反向排除。正向定义告诉智能体这个技能擅长什么反向排除告诉智能体什么情况下不要用这个技能。举个实际的例子# 技能用药相互作用检查 ## 使用场景 - 当需要评估两种或多种药物联合使用时是否存在相互作用风险 - 当患者新增一种处方药而当前用药清单中含有长期服用的慢性病药物 - 当医生要求对当前用药方案进行安全性复核 ## 不要使用此技能 - 药物过敏反应请使用过敏交叉核对技能 - 药物剂量计算请使用剂量计算技能 - 单纯的药品说明书查询请使用药品信息查询工具这套写法跑了一周之后触发准确率提升非常明显。核心原因在于语言模型在做意图路由时本质上是在有限的候选技能里做语义匹配。你给它越清晰的边界信号它越容易做出正确选择。反过来全是赞美的描述——本技能功能强大、覆盖面广、适用于多种场景——在模型眼里跟没说一样它没法学。4.2 技能版本和失效管理医疗技能是会被更新替换的新的相互作用被发现、旧的规则被修正、新的指南发布。SKILL.md 里必须带版本信息并且还要带生效日期和失效日期字段version: 2.3.1 effective_date: 2024-11-01 retired_date: 2025-05-01 supersedes: 2.3.0我一开始没做这个后来在一次规则更新后旧技能被旧数据污染了因为没有版本识别智能体死活不肯切到新版本。加上版本字段之后技能包的管理就清晰很多而且这个字段还能在 trace 记录里看到——某个判断到底是基于哪个版本的规则做出的这在复盘的时候是硬性需求。4.3 技能的冷启动和优先级排序当智能体同时面临多个技能候选时它需要一套优先级逻辑。OpenClaw 的机制是让智能体根据描述自行决定但不意味着我们不能在 SKILL.md 里加暗示。我通常会在描述的最后写一行本技能的优先级priority: high这里我不建议所有技能都写 high。如果一个系统里所有技能的优先级都是高的那等于没有优先级。我的习惯是涉及患者安全的技能如用药相互作用、过敏核对优先级最高涉及文档生成的技能优先级中等涉及运营效率的技能优先级最低。用优先级对技能进行分级本质上是在构建一个医疗安全第一的决策逻辑序。这个思路做出来后在团队内部讨论时也得到了临床顾问的认可——它跟临床分诊的逻辑非常接近。5. 医疗知识库的挂载与动态更新机制5.1 知识库和技能到底该谁服务谁这个问题表面上看很简单知识库当然是技能的下游资源。但实际操作中很多人的知识库和技能完全是两套独立系统技能只负责调用接口知识库更新对技能运行毫无感知。这种方式在医疗场景里不可接受因为规则变了技能产出的结果可能立即就过时而技能本身完全不知道。我在项目里采用的是知识库驱动技能的模式知识库是主源技能是消费者。知识库每次更新都会带上新的 schema 版本技能在启动时校验自己的版本和知识库版本是否匹配不匹配就进入降级模式——只返回知识库中不受影响的部分结果并在报告中明确标注当前技能使用的知识库版本较旧部分规则可能未生效。这个机制帮我挡住过一个大麻烦有一次知识库更新里加了一条新的高警示药物清单如果技能没有版本校验旧的调用结果会继续用旧清单后果可能是致命的。版本校验这个事我强烈建议每个医疗技能都做。5.2 知识更新流程与人工审核的衔接医疗知识更新的来源通常是新药上市、说明书修订、临床指南更新、药物警戒报告。这些来源不是一个技术团队能自行判断的必须有临床专业人员参与。我把流程设计成这样医学编辑把新规则写成标准 YAML提交到规则库的待审区临床审核人员逐条确认确认后规则进入已审区技能包打包时只引用已审区的规则版本上线前跑一遍回归测试集确认真实病例样本中新旧结果差异在可控范围这里面最容易被技术团队低估的是第四步。你以为知识库更新就是换个文件实际上新规则可能对历史病例有不同的判定结果。所以每次更新我都要把线上已有的测试用例集完整跑一遍标注出所有结果发生变化的样本让临床团队确认这种变化是合理的。这不是可有可无的流程是医疗 AI 上线的基本功。5.3 少量知识的硬编码与海量知识的检索增强如何配合另一个经验是知识库不一定全部走向量检索。有些知识是核心硬规则比如高危药品的相互作用有些知识是参考辅助信息比如某药品的详细药理学文档。我的分配原则是核心硬规则直接打包进技能包里用规则引擎处理不走向量检索参考辅助信息放向量库里通过 RAG检索增强生成方式调用原因是核心硬规则的判定结果直接决定患者安全必须确定性优先参考辅助信息的输出只是为医生提供背景可以容忍一定的不确定性。这也符合医疗决策中的风险分层逻辑——重要的东西不允许概率性错误。6. 把外部医疗工具接进技能从接口到容错6.1 工具注册的标准化输入输出契约医疗技能不是孤岛它必须得跟外部系统交互。比如拉取患者的检验数据、写回护理记录、推送随访任务到护士站。这些外部交互在 OpenClaw 里都是通过工具来完成的。首要问题是定义好每个工具的输入输出契约。我拿患者档案读取工具举例。输入是一个患者唯一标识和需要读取的字段列表输出是 JSON 结构的患者档案切片。这个契约要写得很细连字段类型都定义清楚。因为技能本身的 main.py 是直接消费这个输出的如果输出格式不稳定技能的判定逻辑就会被带跑。tools: patient_profile_reader: input: patient_id: {type: string, required: true} fields: {type: list[string], required: true} output: patient_profile: {type: object, schema_version: 1.0} error_handling: patient_not_found: {default: null, notify: true} data_fetch_timeout: {default: retry_3s, max_retries: 2}6.2 拉数据的失败策略宁可报错不要编造在医疗场景里数据拉取失败时必须有一套明确的失败策略。我的原则非常明确宁可返回数据不可用结果也绝不让模型编造数据。因为编造数据在医疗里带来的损害是灾难性的。具体操作是在技能的执行逻辑里增加一个状态位如果患者档案读取工具返回失败则整个技能直接停止在结果报告中标一个DATA_UNAVAILABLE状态同时向操作者发送一条明确的通知告知需要人工介入。我还加了一个隔板机制工具调用失败超过两次就熔断五分钟防止雪崩效应把外部系统压垮。这里面还有一个隐蔽的坑外部工具偶尔会返回半可用数据比如患者档案里过敏史字段为空。这种情况下不能简单地视为无过敏因为可能是数据录入缺失也可能是真的没有过敏。我在报告里会把这类字段标记成unknown而不是none。这个细节不处理一次治疗决策就可能因此失真。6.3 工具的权限与审计谁调用了什么、为什么调用医疗工具还有一个重要维度是权限和审计。不是所有技能都有权限访问所有数据也不是什么调用都能无痕发生。我在工具层做了两层控制首先是行级权限控制比如护理记录生成技能只能读取患者的基本信息和护理评估字段不能读取患者的完整检验结果用药相互作用技能可以读取用药清单但不能读取费用数据。这个控制在工具定义文件里写好技能加载时就绑定权限。其次是全链路审计每个工具调用都会生成审计日志包括调用技能 ID、调用时间、读取的字段、返回的数据量、操作者身份。这个日志会和 trace_id 关联一旦出现医疗纠纷或不良事件审计日志就是还原现场的唯一依据。我也建议把这个审计日志定期做异地快照防止主存储故障造成审计数据丢失。7. 模型调参与 Prompt 工程的医疗化改造7.1 医疗场景下的大模型选型考量技能运行过程中核心的语言理解任务仍然是交给大模型的。选型上我给大家一个实际经验不要盲目追最强模型。医疗场景里优先要考虑的是稳定性、可重复调用成本、对长上下文的处理能力以及最重要的遵循指令的能力。比如我做技能里的护理记录草稿生成要求模型严格按模板输出不能自作主张加内容。实测下来一些追求创造性的模型在这种任务上反而容易发挥过头——模板没写完就自己临场发挥。反而是遵循指令能力更强的模型哪怕能力总值稍低一点在这个场景下表现得更好。这类模型在输出格式控制和不做不该做的事两个方面往往更可靠。7.2 Prompt 模板的字段化与示例固化作为医疗技能Prompt 不能每写一个功能就临时编一段。我把 Prompt 拆成三个固定字段系统角色定义模型的角色边界如你是用药安全审核助手只负责输出药物相互作用评估任务上下文注入患者相关信息、当前技能的执行状态输出约束定义输出格式、必须包含的字段、禁止出现的内容输出约束是我加得最多的部分。比如在护理记录生成技能中我会明确写不得包含主观判断性词语如患者情绪低落如需描述请引用患者原话或客观观察。这条约束在医疗里很重要的因为护理记录是法定文书主观推断会造成后续责任认定的问题。还要提一下 few-shot 示例。我在模板里通常放两到三个真实脱敏示例让模型知道标准答案长什么样。实测下来few-shot 对医疗文本的格式稳定性的提升远大于堆砌更多的描述性指令。示例比指令更有效这是我在多次调参后得到的结论。7.3 温度、Token限制和其他关键参数模型参数里对医疗任务影响最直接的几个是温度、Top-p、Max Tokens 以及禁止输出标记。温度我基本固定为 0 或 0.1不要求创造性输出哪怕输出句式单调一点也没关系。Top-p 同样调低防止模型在关键字段上高概率选取非预期词。Max Tokens 要仔细设。护理记录草稿这类任务Token 数不足会导致输出被截断而截断处恰好可能是关键信息。我会在技能里预计算期望输出长度的上限然后给模型留下 20% 的裕量并在输出约束里加一句输出长度必须控制在 800 字以内。如果模型输出超限宁可提示输出过长请精简也不要让它硬截断。还有一个冷门的点输出里头要禁止出现换行符以外的空白字符重复因为在医疗报告里异常多的空格或者制表符会影响后续的结构化解析。这些问题看着小到了数据清洗环节就变成大坑。8. 避坑实录我在真实调用链上踩过的五个坑8.1 坑一药品名简称导致的匹配失效有一次在用药相互作用验证时一个病例里患者用药清单写着阿莫系统完全没识别出来。排查后发现这个是医生在录入时常用的缩写而技能里的别名表没有收录阿莫这个缩略写法。问题根源是数据录入侧的自由文本和技能内部的标准代码之间的鸿沟。解决办法是在技能入口加了一层别名归一化代理内置了几百个常见药品的简称、别名、通用名映射同时接了一个模糊匹配的兜底匹配不到时先返回未识别而不是静默跳过。另外把未识别的药品名单独列到报告的需要人工确认区不直接拉入规则判定。这个小改动之后技能在真实数据上的召回率显著提升。8.2 坑二知识库更新后旧规则仍在线上运行这个坑前面提到过知识库更新了但技能没有触达新版本结果旧规则还在跑。根因是技能包在构建时锁定了知识库快照而知识库更新以后没有触发技能包的重新构建。我后来在 CI 流水线里加了一个钩子知识库一更新所有依赖它的技能包自动触发重建并强制跑一轮回归测试。任何不一致都会以构建失败的形式暴露出来而不是悄悄带病上线。8.3 坑三模型在无证据情况下强行输出安全结论这是一个非常危险的表现。模型在判断两个药物相互作用时如果知识库里没有记录它可能会基于自己预训练时见过的一些零散信息直接给出安全的结论。这种无证据却自信的输出在医疗场景里是绝对不允许出现的。对策是在 Prompt 里明确加了一句如果知识库中没有直接证据你必须输出unknown而不是安全。同时在技能层做了一个后置校验对输出的安全性结论如果对应的证据ID字段为空就把整条结论改成数据不足需要人工复核。模型推理结果再也不能越过规则校验直接输出这是安全底线。8.4 坑四技能并行调用导致的外部系统超载初版技能设计时所有技能都在收到请求后同时触发。某次模拟高峰期运行时护理记录生成、用药相互作用检查、随访计划这几个技能同时调用患者档案读取工具把后端打崩了。排查后定位到问题就是并行调用缺少限流机制。解决办法是引入了信号量控制限制同一时间最多运行 3 个医疗技能实例超出时排队等待。同时在工具调用侧添加了超时和重试策略。实测之后高峰期的系统吞吐不但没下降反而因为避免了抖动整体稳定性提升了许多。8.5 坑五输出格式嵌套过深导致下游解析失败技能产出的 JSON 报告在初期嵌套层数非常深。后来下游的展示系统在解析这套 JSON 时频繁报错才发现问题出在嵌套结构上。深层嵌套不仅让解析脆弱还让新增字段变得极其痛苦——所有下游消费者都要跟着改。最后我把报告结构拍平了所有输出字段都放在两级以内用扁平结构加前缀区分的写法。比如interactions.rule_hit改成rule_hitinteractions.llm_review改成llm_review_with_reason。这套扁平化设计在下游开发时省了巨量的沟通成本值得你在设计技能输出时早期就考虑进去。9. 医疗技能的可解释性与安全审计设计9.1 每一步都留下为什么医疗场景的可解释性不只是为了过审更是为了实际使用中的可信任度。医生对系统的信任建立在不透明输出之上会越来越低。我给技能包设计了一套决策链记录机制每次运行技能核心判定步骤都会记录决策依据。用药相互作用技能里如果命中了规则 RX-001那么决策链里会记录命中的规则编号、药物的标准编码、判定结果如果走了模型辅助判断决策链里会记录当时的 Prompt 摘要、模型输出原文、后置校验结果。这些记录最终全部进入 trace 系统。任何人拿到一份报告都能够从报告底部回溯到完整的决策链条。这个能力在医疗场景里就是循证的技术化落地。9.2 技能变更时的审批与回滚技能不是只写一次就放那儿不管的。每一个版本的发布都应视作一次医疗流程变更。我的操作是每个技能目录里都放一个 CHANGELOG.md记录变更历史并且发布前必须由医疗内容审核角色确认。这个角色在真实团队里是临床专家或药师来承担技术团队只能申请发布不能单独发布。当新版技能上线后发现异常我需要能一键回滚到上一版本。实现方式是在技能包管理平台里保留最近五个版本的历史包并支持按版本切换运行。回滚不是简单地换文件因为知识库版本、工具接口可能也跟着变所以回滚操作时会自动做依赖一致性检查。不然回滚到旧技能版本配着新知识库往往会出现更隐蔽的错配。9.3 与电子病历系统对接时的数据合规注意最后说一下电子病历对接。技能输出如果要写回电子病历系统必须经过接口层的字段映射校验确保没有把技能内部字段硬塞进病历字段。我在项目里给每个技能维护了一张输出字段-病历字段映射表逐字段确认含义、单位、可空性。这个映射表由技术和临床双方共同签字确认任何字段含义的调整都必须走重签流程。另外所有从电子病历拉的数据、写回的数据都走专用的加密通道日志里不允许出现患者明文身份信息必要字段在存储前做脱敏处理。这个事不能省医疗数据合规不是产品特性是底线。10. 从单个技能到多技能协作编排层的关键设计10.1 多技能之间如何共享上下文当你有多个技能以后最自然的下一步是让它们协作。比如一个患者入院后先跑入院评估技能然后评估结果喂给护理记录生成技能同时用药相互作用技能也要拿到评估中的用药清单。这意味着技能之间需要一套共享的上下文机制。我采用的方案是在编排层维护一个患者会话状态对象。这个对象随患者 ID 标识承载评估结果、用药清单、护理计划等中间数据。每个技能执行时从会话对象中读取自己需要的字段处理完再把自己产出的字段写回对象。这种内存中的会话状态实现简单但要注意并发访问问题。好在 OpenClaw 提供的会话管理机制能帮我处理大部分并发冲突。10.2 技能编排的优先级冲突处理多个技能同时被触发时总会有冲突。比如某患者同时需要用药相互作用的评估和随访计划生成但系统资源只够跑一个。我使用的编排规则是安全优先 时效优先与患者当前用药安全直接相关的技能优先执行其他可以稍后执行的技能排队。一个具体的经验是编排层不能把所有决策都交给大模型因为大模型对时效性的理解很差。我在编排层用硬编码规则设定优先级矩阵模型只负责生成内容不负责决定谁先跑。这个分离设计让整个系统在复杂环境下仍然可控。10.3 编排中的错误传播与隔离编排还有一个让人头疼的问题是错误传播。假设用药相互作用技能因为外部工具超时挂了如果编排层处理不当后续的随访计划生成也会跟着失败甚至整个患者会话状态被污染。我的做法是给每个技能调用包一层编译隔离盒——技能执行中抛出的异常只在其内部记录不影响其他技能调用。同时把失败技能的输出状态标记为failed其他技能读取会话对象时如果发现某个依赖字段来自失败技能会进入降级处理分支而不是直接报错。这套机制让编排层面的稳定性整体提升了一个量级。11. 验证与回归医疗技能上线前必须做的事11.1 构建你自己的金标测试集医疗技能上线前最可靠的质量底线是有一个金标测试集。我从早期就开始积累这个集合包含了真实脱敏病例并针对每个病例配好预期输出。预期输出由临床人员逐条标注确认不依赖模型也不依赖工程师的直觉。这个金标测试集里我会覆盖三类用例正常路径合法输入直接得到标准输出、边界路径缺字段、空列表、未知药品名、异常路径外部工具超时、知识库版本不匹配、输入包含非法字符。每类至少覆盖五个样本测集整体数量不宜太少否则变异覆盖度不足。11.2 模型升级前的兼容性回归大模型厂商升级模型是很常见的事但直接切新版本往往会引发一连串的兼容性问题。我的做法是在模型升级前先跑一轮完整的金标回归测试专门比较新旧模型在技能产出的规范性上的差异。实测中新模型在格式遵循上往往没问题但在内容不越界上经常出幺蛾子——比如主动添加了模板里没有的字段。遇到这种情况我的选择不是立刻回滚也不是简单切换而是针对新模型的特性微调技能里的 Prompt 约束把易越界的字段在输出约束里明确写禁止输出。这种微调按经验大概需要一到两轮迭代之后再跑回归通过就可以正式切换。11.3 线上小流量灰度与可观测性所有冒烟测试都通过之后我更倾向做一轮线上灰度。在灰度阶段只有 5% 的请求会走新技能其余走旧逻辑。同时我会开启完整 trace 和审计比较新旧技能在同样输入下的输出差异。灰度期的核心指标不是输出好不好而是异常率有没有上升、响应时间有没有恶化、资源消耗有没有超标。这些指标全部稳定在合理区间之后才把灰度比例逐步拉高到 50%、100%。即使灰度反馈好我也保留在 100% 灰度后 48 小时内随时回滚的能力直到确认旧技能完全没有回归风险。12. 医疗技能的发展空间这是我接下来要往前推的方向医疗技能做到现在已经不只是智能体自动化流程这么简单。我的下一步是把技能体系跟更细粒度的临床路径结合起来让技能能在不同的科室、不同的患者群体之间做配置化适配。同时在技能的知识库侧增加持续从真实反馈中学习的能力——注意不是让模型学而是让规则库和模板在人工确认后自动沉淀不把未经确认的推断写进规则。如果你是从零开始做医疗技能我的建议是从最小的确定性技能做起先把安全边界、审计链路、回归测试这些基础设施搭稳再慢慢往复杂技能扩展。这个顺序不能反。医疗场景错不起慢一点稳一点反而是最快的路径。