使用 Step Functions 和 Amazon Bedrock AgentCore 实现医疗编码自动化
内容提要
文章介绍如何用AWS Step Functions与Amazon Bedrock AgentCore实现医疗编码自动化：由工作流引擎负责顺序执行与审批，AI代理仅在单个步骤内做有限判断。流程按成本递增设计，先查安全黑名单，再进行精确匹配，仅对需要判断的术语调用代理，并按代理置信度阈值决定自动编码或转人工。该设计强调可审计性与确定性，避免将整个流程交给模型。
延伸解读
确定性工作流与有界代理的分工
文章强调将整个流程交给代理会导致执行路径依赖模型推理，难以审查和重放。因此，Step Functions 负责顺序、审批和路由，代理仅在单个步骤内做有限判断。这种分工使合规审查员能直接阅读状态机定义来理解执行路径，而不依赖代理的运行时推理。对于安全关键的医疗编码，这种可审计性至关重要。
成本递增的升级策略与安全控制
流程按成本递增设计：先查安全黑名单，再进行精确匹配，仅对未命中的术语调用代理。黑名单在模型调用前执行，是无法被提示词绕过的硬控制，且零成本。在示例中，12个术语有5个在前两步完成，超过三分之一的工作量无需调用模型。这种设计将昂贵且非确定性的LLM调用限制在真正需要判断的少数案例上。
基于代理置信度的路由与阈值校准
文章指出，基于检索相似度路由是错误的，因为相似度可能将明显正确的拼写错误和模糊表述的排序颠倒。因此，代理报告自身对所选编码的置信度，工作流根据固定阈值（如0.90自动编码）决定后续。但代理置信度在重复运行中会在一定区间内波动，接近阈值的案例可能时而自动编码时而转人工。建议测试时断言所选编码而非精确分数，并将阈值设置得低于0.90以留出余量。
检索质量与生产化注意事项
文章提醒，检索质量是代理能力的上限：如果正确术语未被检索返回，代理无法选择它。示例中“flutters in my chest sometimes”本应编码为Palpitations，但向量搜索将其排在第19位，导致代理选择了Cardiac flutter。生产环境应使用混合检索（如词汇搜索或同义词扩展）并基于自身数据校准阈值。此外，示例仅用于演示，生产前需用已知正确数据集验证并测量编码精确度和错误自动编码率。
Q&A
医疗编码自动化中，为什么不让AI代理控制整个工作流？
因为将整个工作流交给代理会使运行时路径成为模型推理的属性，难以审查和重放。文章强调应由工作流引擎负责顺序执行和审批，代理仅在单个有界步骤内进行判断，从而保持确定性、可审计性。
这个医疗编码方案是如何按成本递增顺序处理术语的？
流程先检查安全黑名单（如“HAEMORRHAGE”等过于宽泛的术语），命中则直接转人工；然后进行不区分大小写的精确匹配和同义词匹配，仅当匹配到唯一代码时自动编码；只有未命中时才调用AI代理进行语义搜索和判断。这样大部分术语在前两步以低成本解决。
为什么路由阈值要基于代理置信度而不是检索相似度？
检索相似度可能错误排序案例：例如拼写错误“migrane”与“Migraine”文本差异大导致相似度低，但编码明确；而“flutters in my chest sometimes”与“Cardiac flutter”共享更多词导致相似度高，但编码不确定。因此方案让代理报告自身置信度（分三档），工作流再根据置信度阈值（如0.90自动编码、0.70-0.90转人工、低于0.70留开）进行路由。
代理如何利用研究上下文来区分模糊术语？请举例说明。
代理通过get_study_info工具获取研究方案的自由文本描述，仅返回文本而非代码。例如“cramps”在肿瘤研究中被编码为“肌肉痉挛”（得分0.92自动编码），而在反流研究中被编码为“腹痛”（得分0.85转人工），因为研究背景不同。
写回步骤如何防止代理编造不存在的代码？
写回前会检查所选代码是否存在于目标字典和版本中。提示词要求代理不得编造代码，此检查强制执行。如果代码不存在，术语将保持开放并记录原因。但该检查无法验证代码是否来自搜索结果，需通过AgentCore Observability查看工具调用。
这个方案适合哪些场景？有哪些局限性？
适合执行路径需独立于模型推理可审查、大部分工作负载确定性、仅少数需判断、且“转人工”是一等结果的场景，如医疗摘要、病例叙述、实验室测试编码、理赔分诊等。局限性包括：不适合开放式对话；检索质量限制代理（如“palpitations”未被检索到则无法选择）；代理置信度分数在多次运行中可能波动，需在测试中断言所选代码而非精确分数，并设置低于0.90的阈值余量。
