知识库不等于方法库，Agent 还需要可执行技能

用开源 Agent 技能提升医疗与生命科学 AI 推理

一、问题：模型「知道」指南却用错方法

2.1 核心痛点：方法论鸿沟（methodology gap）

文章开篇给出一个非常具体的失败示例：让 Agent 按 ACMG/AMP 标准分类一个 TP53 错义变异（missense variant）。Agent 会：

1. 引用正确的框架（它确实「知道」ACMG/AMP 分类标准）；
2. 但误用证据类别（misapply evidence categories，例如把中等强度证据当强证据用）；
3. 跳过人群频率阈值（skip population frequency thresholds，即不查/不按 gnomAD 等人群数据库的频率界值走流程）；
4. 幻觉出计算预测分数（hallucinate computational predictor scores，即编造 REVEL/CADD 之类 in-silico 预测器的数值）。

2.2 为什么危险：「静默失败」（silent failures）

"Outputs look correct but apply wrong criteria, with regulatory and patient safety consequences." 中译：输出看起来正确，却用错了标准，会带来监管与患者安全后果。

文章强调这类失败是静默的——输出格式漂亮、术语正确、引用像模像样，非专家看不出错。它波及四类场景：

• 变异解读（variant interpretation）：错误的致病性分类直接影响临床报告；
• 理赔裁决（claims adjudication）：错误的规则应用导致拒付/误付；
• 临床试验设计（clinical trial design）：方法学错误埋入方案；
• 影像分析（imaging analysis）：处理顺序/参数错误引入系统性偏倚。

2.3 问题的本质

模型在训练数据和系统提示词里都「见过」指南，但指南是陈述性知识；从业者真正依赖的是程序性知识——先查什么、按什么顺序判断、阈值是多少、什么情况下推翻前一步。这个差距不是靠加大提示词或换更大模型就能补齐的，这正是本文方案要解决的。

二、方案总览：38 个技能 / 11 个领域 / Agent Skills 开放标准

3.1 技能是什么

HCLS Agent Skills 集合中的每个技能是一份结构化 Markdown 文档（SKILL.md），把领域决策程序编码为 AI Agent 可以在推理时通过「渐进式披露」（progressive disclosure）消费的格式——即 Agent 不需要一次性装载全部内容，而是按查询触发相关技能、按需加载相应章节。

3.2 遵循开放标准

• 遵循 Agent Skills 开放标准（agentskills.io）；
• 每个技能在 YAML frontmatter 中声明触发条件（triggers）、依赖（dependencies）与元数据（metadata）；
• frontmatter 之后的正文包含：决策框架、参数表、代码模式（code patterns）、验证标准（validation criteria）。

3.3 规模与许可

"Skills are auditable, portable, and straightforward to maintain." 中译：技能是可审计的、可移植的、且易于维护。

三、SKILL.md 结构与 YAML frontmatter 字段

博客正文对 SKILL.md 结构的描述是：YAML frontmatter 声明触发条件、依赖和元数据，正文承载决策框架、参数表、代码模式与验证标准。下面以仓库中真实存在的 genomic-variant-interpretation/SKILL.md（MIT-0 开源文件）的 frontmatter 为结构性示例，逐字段中文解释（仅截取字段骨架，不整段复制内容）：

---
name: genomic-variant-interpretation
description: Reason about germline and somatic variant classification
  using ACMG/AMP 2015 ... Triggers include "ACMG", "variant
  classification", "pathogenic", "VUS", "ClinVar", "gnomAD", ...
usage: Invoke when classifying variants, applying ACMG criteria, ...
version: 1.0.0
tags: [skill, category:reasoning, genomics, variant-interpretation, acmg, hcls]
---

各字段含义（中文解释）：

frontmatter 之后的正文结构（以该推理技能为例，概述其章节骨架）：

1. Overview（概述）：声明「这是一个 reasoning skill，只编码决策框架、不运行工具不生成代码」，并交代两大标准——ACMG/AMP 2015（胚系变异）与 AMP/ASCO/CAP 2017（体细胞变异，按临床可操作性分层 I—IV），特别指出「混淆这两套框架是最常见的解读错误，先选对框架再应用」；
2. Usage（使用时机）：列举应触发本技能的具体任务（分类变异、判断某条 ACMG 准则是否适用、调和冲突证据、解读 VUS、负责任地使用 in-silico 预测分数、发布前复核分类草稿），并要求按决策框架顺序走、引用具体准则代码（如 "PM2_Supporting"）而非模糊表述（如「人群中罕见」）；
3. Response Format（回复格式）：规定输出结构——先给结论（≤3 句），再给引用具体准则/阈值的论证，最后列注意事项；用表格做对比；目标 200—400 词；
4. Core Concepts / Decision Framework（核心概念与决策框架）：如 ACMG/AMP 五级分类表（P/LP/VUS/LB/B，含临床含义，明确 VUS「不可用于临床处置」）、28 条证据准则按强度分级（PVS/PS/PM/PP 与 BA/BS/BP）等。

这体现了博客所说的技能正文四要素：决策框架、参数表、代码模式、验证标准，且每一条判据都是人类可读的 Markdown——「可审计」指的就是这一点：决策依据不藏在模型权重里。

四、reasoning skills vs pipeline skills

仓库把 38 个技能分成双分类，这是最重要的设计概念之一：

5.1 Reasoning skills（推理型技能）

• 编码内容：方法论与决策框架，指导 Agent「怎么想」；
• 示例：genomic-variant-interpretation——完整编码 ACMG/AMP 分类框架，包括：
• 证据类别（evidence categories，即 PVS/PS/PM/PP、BA/BS/BP 的分级适用规则）；
• 人群频率阈值（population frequency thresholds，如按 gnomAD 频率过滤）；
• 计算预测器 cutoff（computational predictor cutoffs，如 REVEL/CADD/SpliceAI 的判读界值）。
• 正好逐条对治第二节里 TP53 示例的三种错误（误用证据类别、跳过频率阈值、幻觉预测分数）。

5.2 Pipeline skills（流水线型技能）

• 编码内容：工具专属命令、经过验证的参数、可产出可运行工件（runnable artifacts）的代码模板，指导 Agent「怎么做」；
• 示例：variant-calling——提供：
• GATK4 HaplotypeCaller 命令（含正确的注释组 annotation groups）；
• VQSR tranche 敏感度目标（变异质量分 recalibration 的阈值口径）；
• Mutect2 tumor-normal 配对配置（体细胞变异检测）。

5.3 双分类的意义

"This dual taxonomy gives agents both the judgment to make correct decisions and the technical precision to execute them." 中译：这套双分类让 Agent 既有做对判断的「判断力」，又有精确执行的「技术精度」。

后文（第十节）还会呼应：推理型技能适合用决策树 + 编号流程来写，流水线型技能的价值主要在参数表 + 版本相关的坑（version-specific gotchas）。

五、skills 与 RAG、fine-tuning 的区别

文章用一段专门把 Agent Skills 与另外两条「领域专精化」路线区分开：

6.1 vs RAG（检索增强生成）

• RAG 的做法：从建了索引的文档里检索有限段落来增强回答生成；
• Skills 的做法：编码的是决策程序本身和错误条件（the decision procedure and error conditions itself）——不是「找到相关的一段话」，而是「给出完整的判断流程：先查什么、阈值多少、什么情况算错」。
• 直白理解：RAG 给 Agent「参考资料」，Skills 给 Agent「操作规程」。参考资料可能检索不到关键段、也可能检索到了但 Agent 仍不会按正确顺序用；操作规程直接规定流程与判据。

6.2 vs Fine-tuning（微调）

• Skills 不是微调：它们是结构化提示词（structured prompts），基于用户查询中的触发模式按上下文激活（activate contextually based on trigger patterns）；
• 更新方式对比：年度医保政策变化、新的实验判据，改一个文本文件即可生效，不需要重训模型。

6.3 三个区别性属性

1. 可审计（auditable）：每条决策判据都是人类可读的 Markdown，不藏在模型权重里——对受监管行业尤其重要；
2. 可移植（portable）：同一份技能跨 20 多个服务工作（文中点名 Amazon Bedrock AgentCore、AWS Strands Agents SDK、Kiro、Amazon Quick Desktop、Claude Code、OpenAI Codex 等），无需逐个定制；
3. 易维护（straightforward to maintain）：文本文件级修改，版本可管理。

此外「渐进式披露」是控制上下文成本的关键机制：不是把 38 个技能全塞进上下文，而是按触发词选择性加载相关技能（第八节的多智能体架构进一步放大了这一点）。

六、安装步骤

7.1 前置条件（Prerequisites）

需要以下任一受支持的环境：

• Kiro 或 Kiro CLI：交互式使用技能 + 多智能体编排；
• AWS Strands Agents SDK + Amazon Bedrock 基础模型访问权限；
• AgentCore harness（Amazon Bedrock AgentCore 的能力之一），配合已有的 agent 实现；
• Amazon Quick Desktop：图形界面管理技能；
• 或者你自选的编码 Agent harness，如 Claude Code、OpenAI Codex。

另需：Python 3.10+（配合 uv）、Git（用于克隆仓库）。

7.2 安装路径

① 克隆仓库：

git clone https://github.com/awslabs/hcls-agent-skills.git
cd hcls-agent-skills

② 只装技能（不带 agent 配置）——用通用的 skills CLI：

npx skills add awslabs/hcls-agent-skills

③ Kiro：install.sh 脚本会同时安装技能和一个预配置的、已装配这些技能的 agent；该 agent 自动做技能路由，无需按名字手动调用单个技能。

• 运行 ./install.sh --target kiro，然后在 Kiro CLI 里用 /agent hcls 切换；
• 多智能体模式：./install.sh --target kiro --mode multiagent，然后使用 /agent hcls-multiagent。

④ AWS Strands Agents SDK：在 Python 代码里直接加载技能：

from strands import Agent
from strands.skills import AgentSkills

agent = Agent(
    model=model_id,
    skills=AgentSkills(skills="./skills/"),
)

⑤ Amazon Bedrock AgentCore：按 AgentCore 文档中的 Skills 指南，把 agent skills 添加到 AgentCore 托管的 agent；AgentCore 提供托管、自动扩缩容、安全边界与可观测性。

⑥ Amazon Quick Desktop：运行 ./install.sh --target quick-desktop 查看在图形界面添加技能的完整说明；或按 Amazon Quick 文档中的 Skills 页面操作。

7.3 三种部署形态（Solution walkthrough 总起）

装好之后，文章演示三种部署模式：

1. 最简：单 Agent（Quick Desktop）；
2. 多智能体编排（Kiro CLI）——解决上下文工程挑战；
3. 生产部署（Strands SDK on Amazon Bedrock AgentCore）。

Quick Desktop 单 Agent 形态：装好技能后无需额外配置，Agent 根据查询中的触发模式自动激活相关技能。例子：问「把 E11.9 编码改成 E11.42 对 RAF（风险调整系数）有什么影响？」会触发 risk-adjustment 技能，Agent 给出具体 HCC 映射、层级归并（hierarchy resolution）和量化的 RAF 差值，而不是泛泛的「建议复核病历」。技能是选择性激活的——只有相关技能被触发，帮助输出保持聚焦准确。（此处配有一段演示视频：Quick Desktop 中 risk-adjustment 技能被动态加载回答 RAF 编码问题。）

Kiro CLI 多智能体形态：这是着墨最多的架构讨论——

• 问题一：把全部 38 个技能加载进单个 Agent 上下文约消耗 8 万（~80K）token。大上下文模型能装下，但产生上下文工程挑战：Agent 每次查询都要从 38 个技能里选对子集，无关技能内容会争夺注意力；
• 问题二：显式调用（如 /risk-adjustment）虽然精确，但要求提问前就知道该用哪个技能——这恰恰是技能本想弥补的专业知识鸿沟；
• 解法：Kiro CLI 多智能体架构。一个轻量协调者 agent（coordinator，不加载任何技能）做意图分类，把查询路由给 8 个领域专家 agent（domain specialists），每个专家只加载自己领域的技能（每个约 1.5 万（~15K）token）。协调者管路由，专家管领域推理；
• 此处有一张图表：「Kiro CLI 多智能体架构中八个领域专家 agent 及各自分配的技能」对照表（图片未复制；内容即 8 个专家与技能的分派关系）；
• 配置方式：JSON agent 配置文件。仓库里有 coordinator agent 配置（含路由逻辑，agents/multiagent/kiro/hcls-multiagent.json）和专家 agent 配置示例（展示领域技能如何挂到专家上，hcls-drug-discovery.json）；
• 配套演示视频：Kiro CLI 在代码库中用多智能体路由 + 动态技能激活回答一个复杂的药物老药新用（drug repurposing）问题。

Strands SDK 形态：SDK 原生支持技能加载，可自建多专家 agent。示例代码（节选骨架）：分别定义 genomics_agent（加载 ./skills/genomics/）与 imaging_agent（加载 ./skills/imaging/），再用 MultiAgentOrchestrator 做协调路由，示例查询是「用 ACMG 标准分类 NM_000546.6:c.743G>A（TP53）」。

部署到 AgentCore：本地跑通后可上生产。除了把技能嵌进 Strands agent 代码，还可以在环境级别配置技能，让运行在该 harness 里的 agent 都能用。AgentCore harness 提供托管、自动扩缩容、安全边界、可观测性，无需自己管基础设施。

七、三个 worked use cases

三个用例都取自其评估提示集（drawn from our evaluation prompt set），每个用例都按「场景 → 用户可能的模糊提示 → 无技能时的表现 → 有技能时触发了哪些技能、做了哪四步」的结构展开。

8.1 用例一：药物发现——评估罕见纤维化疾病的老药新用候选

场景：一家生物技术公司团队研究特发性肺纤维化（IPF）的老药新用，想评估已上市药物中哪些能通过受体激酶 TGFBR1（ALK5）调节 TGF-β1 信号通路。实际研究工作需要：查询药物-基因相互作用数据库、按证据强度给候选排序、评估作用机制与 IPF 病理生理的重叠度、结合已有安全性数据判断可转化性。

用户可能的模糊提示（示例）：「我在研究 TGFBR1 作为 IPF 治疗靶点。有没有值得老药新用的已上市药物？最强的候选是哪个，临床转化有多现实？」

无技能时：Agent 给出一份泛泛的文献综述，罗列已知 TGFBR1 抑制剂，但没有结构化排序标准、没有证据层级、没有可转化性评估框架。

有技能时：触发 drug-repurposing 和 translational-research 两个技能，Agent 依次做到：

1. 应用 DGIdb 查询框架：相互作用类型按优先级排（inhibitor > modulator > binder），来源数据库优先 ChEMBL、DrugBank，压过低置信度来源；
2. 用结构化证据层级给候选排序：直接靶点结合证据 > 通路级证据 > 表型关联证据，并把「已有适应症相关性」作为修正因子；
3. 评估作用机制重叠：把 TGFBR1 抑制映射到 IPF 的关键病理过程——成纤维细胞向肌成纤维细胞转化（fibroblast-to-myofibroblast transition）、上皮-间质转化（EMT）、细胞外基质沉积（ECM deposition）；
4. 用 T0→T1 标准评估临床可转化性：考察原适应症的既有安全性数据、治疗窗兼容性、临床前纤维化模型与人类疾病的一致性。

结论：技能链把「表面化回答」变成「结构化的、有监管意识的、带量化证据排序的评估」。

8.2 用例二：医疗理赔运营——搭建 CMS-HCC 风险调整流水线

场景：一家拥有 12,000 名会员的 Medicare Advantage（联邦医疗保险优势计划）保险公司，需要基于 ICD-10 诊断理赔数据、用 CMS-HCC Model V28 系数计算风险调整系数（RAF）分数。流水线必须：应用 ICD-10-to-HCC 交叉映射表（crosswalk）、正确做疾病层级归并（hierarchy resolution）、含人口学调整地计算会员级最终风险分。

用户可能的提示（示例，设定为初级分析师）：「我们是有 12,000 名会员的 Medicare Advantage 计划，ICD-10 诊断理赔在 PostgreSQL 里（member_diagnoses 和 member_demographics 两张表）。给我搭一个计算当前支付年度会员级 RAF 分数的流水线。」

无技能时：Agent 产出一个「看似合理但不完整」的流水线，常见错误：完全漏掉层级归并；用过时的 V24 系数；或先求和再归并（会虚增分数）。

有技能时：触发 risk-adjustment 和 claims-billing-rules 两个技能，Agent 依次做到：

1. 生成正确 SQL：诊断码关联 ICD-10-to-HCC crosswalk 表，并在测量年度内去重，确保每个会员的每个 HCC 只计一次；
2. 正确实现 V28 层级归并：HCC 18（伴慢性并发症的糖尿病）取代 HCC 19（不伴并发症的糖尿病）；HCC 326（CKD 5 期）取代 HCC 327（CKD 4 期）——防止在多个特异度层级上重复计分；
3. 正确的人口学分段：先把会员归类为 community（社区）、institutional（机构）或 dual-eligible（双重资格）人群，做年龄/性别调整，然后再对 HCC 系数求和；
4. 主动解释为什么跳过层级归并是错的：会在多个特异度层级重复计病，系统性虚增 RAF 分数，在 CMS RADV 审计下形成审计责任。

结论：技能支撑产出「经得起审计的」（audit-defensible）RAF 分数，而不是会触发 CMS RADV 审计发现的虚高估计。

8.3 用例三：医学影像研究——T1 加权 MRI 的 VBM 预处理

场景：一项纳入 45 名健康成人的神经影像研究，需要为基于体素的形态学分析（VBM）搭建标准 T1w 预处理流水线。原始 DICOM 已转为 NIfTI。流水线必须以正确顺序完成：重定向（reorient）、偏置场校正（bias field correction）、去颅骨（skull-strip）、配准到 MNI152 空间，且参数要适配健康成人大脑、运行在 FSL/ANTs 混合环境。

用户可能的提示（示例）：「我有 45 例健康成人 T1w 扫描，要做 VBM 分析的预处理。用 FSL 和 ANTs 给我搭个流水线。」

无技能时：Agent 给出「大致合理」的流水线，但可能：把偏置场校正排到去颅骨之后（会污染脑掩膜）、使用不当阈值、或遗漏失败模式检测策略。

有技能时：触发 radiology-preprocessing 和 imaging-study-design 两个技能，Agent 依次做到：

1. 给出正确顺序并说明理由：先重定向到标准空间 → 偏置场校正必须在去颅骨之前 → 用适配健康成人的参数做脑提取 → 最后配准到 MNI152 模板；
2. 解释这个关键顺序依赖：若未先做偏置校正，脑边界处的信号强度不均匀会让去颅骨算法切除过多或过少组织，在颞叶和额叶区域尤其明显；
3. 提供完整 bash 脚本：每一步带错误检查，并输出可供人工目检中间结果的质控（QC）产物；
4. 记录每一步的失败模式：方向元数据错误、表面线圈附近的残余信号阴影、提取阈值过松导致颈部组织混入、老年被试脑室边界处的配准失败。

结论：技能抓住了那个会给 VBM 分析引入系统性偏倚的顺序依赖。

8.4 三个用例的共性模式

每个用例都是「两个技能联动」（推理型 + 领域规则型），且价值都体现在四点：流程顺序正确、阈值/版本正确、主动解释错误后果、给出可执行产物。过渡句指出：用例展示了技能对 Agent 行为的定性重塑，但「到底好多少」需要定量回答——引出下一节评估。

八、评估设计与结果

9.1 评估设计

• 方法：成对评估（pairwise evaluation），共 410 条领域提示 = 380 条单技能（single-skill）+ 30 条跨技能（cross-skill）；
• 两套 agent harness 配置（同一套提示各跑一遍）：

1. Kiro CLI：使用 Auto 模型（由 Kiro 自动为任务选最优模型）；agent 可用 thinking 工具和文件读取操作；
2. Strands Agents SDK：Agent(model=BedrockModel(...), callback_handler=None)，模型显式固定为 Claude Sonnet 4.6；技能条件额外加载 AgentSkills(skills="./skills/") 插件；

• 对称性：think 工具在两个条件（有/无技能）中对称提供，避免工具差异混淆结论；
• 对比条件：baseline agent（无任何技能） vs skilled agent（全部 38 个技能经渐进式加载可用）；
• 配置代码见仓库 eval/execute.py。

9.2 评分维度与 judge 模型

由 LLM judge 按 5 个维度打分（0—100 分制）：

• Judge 模型：Amazon Bedrock 上的 Claude Opus 4.7；完整评分提示词在仓库 eval/judge.py。

9.3 为什么用胜率 + 效应量，而不是原始分差

文中指出 LLM judge 存在分数压缩（score compression）现象：分数聚集在某个区间，原始分差（如 +1.5）难以解读。因此报告两个主指标：

1. 胜率（Win Rate, WR）：技能条件得分高于 baseline 的提示占比——直观、对分数压缩稳健；
2. Cohen's d 效应量：均值差除以合并标准差，衡量提升相对自然波动有多大。通用解读：0.2 = 小、0.5 = 中、0.8 = 大。

9.4 总体结果

整体上，技能在两套 harness 中赢得 69.5%—85.9% 的 head-to-head 对比（开头与结论中概括为 70—86%）：

关键解读：

• 技能在两套配置中都提升了 critical thinking、actionability、scientific accuracy；
• 最强信号在 critical thinking——证实技能的主要贡献是方法论性的：教 Agent 用哪个框架、质疑哪些假设、标注哪些局限，而非补充模型已有的事实内容。

9.5 按 baseline 强度分层：越弱的地方帮助越大

"agent skills help the most when the base agent struggles the most" 中译：基础 Agent 最吃力的地方，恰恰是 agent 技能帮助最大的地方。

• Baseline 回答质量与技能收益的 Pearson 相关系数：Kiro CLI 为 −0.59，Strands agent 为 −0.61（负相关 = baseline 越差、收益越大）；
• 按 baseline 总分把提示分为弱 / 中 / 强三档。大多数提示落在中档，技能收益明显；强档（模型本来就答得好）收益边际化；弱档是基础 Agent 吃力的场景，横跨多个领域（临床数据、医疗运营、基因组学），典型特征是多步骤监管流程或模型只能「近似」而非精确应用的小众方法论。

Kiro CLI 分档结果：

Strands agent 分档结果：

但强档结论并非绝对：文中明确指出，跨领域推理技能（cross-domain reasoning skills）在 baseline 高达 90.2 的强档提示上仍取得 80% 胜率——说明设计良好的方法论框架，只要教的是模型自己不会主动应用的决策程序，就能在整个质量谱系上持续增值。

9.6 方差缩减：一致性提升

技能还降低了各领域内全部样本提示的评分标准差。例子：Kiro CLI 中，临床数据（clinical-data）领域 judge 评分的标准差从 6.8 降到 3.3，缩减 51%。含义：技能让输出更一致、更贴合技能中编码的知识与框架。博客强调：在受监管的 HCLS 工作流中，一致性与平均质量同等重要，方差缩减本身就是有意义的收益（表内「最大方差缩减」Kiro −61.9%、Strands −52.1% 即此口径）。

完整评估方法、提示与原始结果见仓库的 evaluation technical report（eval/TECHNICAL_REPORT.md）。

九、如何自定义与扩展自己的技能

以上结果针对仓库自带的 38 个技能；你的团队可能需要不同阈值、额外协议或全新领域覆盖。仓库提供三份指南：

1. CUSTOMIZING.md：修改、扩展、从零创建技能的实操工作流，包括把组织特有规则（如 LCD 编码、formulary step therapy 处方集阶梯治疗、内部协议）加入既有技能；
2. SKILL_DESIGN_GUIDE.md：基于证据的高效技能写作模式——决策树、阈值表、gotcha 清单（易错点列表）、回复格式章节，以及与高评估胜率相关的结构特征；
3. QUALITY_CHECKLIST.md：合并前质量检查清单，覆盖 frontmatter、结构、内容质量与测试要求。

10.1 自定义流程

1. 复制相关 SKILL.md；
2. 修改决策阈值、加入组织专属协议、删除不相关章节；
3. 按设计指南组织新内容——推理型技能受益于决策树和编号流程；流水线型技能的价值主要来自参数表和版本相关的 gotcha。

10.2 用配套评估框架测试你的修改

先生成贴合团队真实工作流的评估提示，再跑评估框架：

uv venv --python 3.12 && source .venv/bin/activate
uv pip install -e ".[dev]"
# 为每个技能生成 30 条评估提示
python eval/generate_prompts.py --count 30
# 针对你修改后的技能跑成对评估
python -m eval.run --skills ./my-custom-skills/ --parallel 2
python eval/build_review.py
open eval/results/review.html

• 产出物 review.html 是一个评估仪表盘：包含评分、领域分解、每次评估的提示与回复（配有演示视频）；
• 评估输出的是成对对比：你修改后的技能相对 baseline 是否改进了回复，并带与前文相同口径的分维度拆解；
• 做好的新领域技能可按 contribution guide（CONTRIBUTING.md）回馈开源集合。

10.3 清理（Clean up）

技能是本地文件，不创建任何 AWS 资源，示例无需清理。唯一例外：若把 Strands agent 部署到了 Amazon Bedrock AgentCore harness，需按 AgentCore 文档的 Clean up 步骤删除已部署的 agent 资源。

十、局限性与免责声明

需要先说明：这篇博客没有独立的「局限性/免责声明」章节，以下是从博客各处归纳出的、其自己承认或明显蕴含的边界：

1. 评估环境是合成的：三个 worked use cases 明确「取自评估提示集」，即构造的评估场景，不是真实临床/理赔生产环境的部署案例；评估结论（胜率、效应量）反映的是评估环境下的成对比较，不能直接等同于真实业务效果，更不构成临床验证。任何用于真实 HCLS 决策的产出，仍应由具备资质的领域专业人员复核——这与文中反复出现的「审计责任」「监管后果」「患者安全」语境一致。
2. 依赖 LLM judge：评分由 Claude Opus 4.7 担任 judge，且博客自己指出 LLM judge 存在分数压缩现象，所以才改用胜率 + Cohen's d 口径；judge 本身的偏差未被消除。
3. 强 baseline 档收益边际化甚至为负：Kiro CLI 强档差值为 −0.3、胜率 55%；Strands 强档差值 +0.0、胜率 54%——模型本来就会做对的题，技能几乎不加分。博客补充「强档结论并非绝对」（跨领域推理技能在 90.2 baseline 上仍有 80% 胜率），但整体规律是技能的价值集中在中弱档与多步骤监管流程类问题。
4. 结果绑定具体配置：胜率区间 70—86% 明确「随 agent harness 设置不同而变」（Kiro Auto 模型 69.5% vs 固定 Claude Sonnet 4.6 的 Strands 85.9%），换模型/换 harness 数字会变，不应脱离口径引用。
5. 评估只覆盖仓库自带的 38 个技能：自定义技能的效果需要用自己的提示集重新跑评估，博客提供了工具但不担保结果。
6. 上下文成本真实存在：全量 38 技能约 80K token，多智能体分治后每专家仍约 15K token——技能不是零成本的，规模化时需要做上下文工程。

原文链接：https://aws.amazon.com/blogs/machine-learning/improving-hcls-ai-reasoning-with-open-source-agent-skills PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/improving-hcls-ai-reasoning-with-open-source-agent-skills